[dlc-dev] DLC without pre-committed R values

[Goran]

Thanks for the clarification.
Yeah, I see now what's the problem. If oracle signs 2 messages, we now have
2 equations with 2 unknowns, which are solvable(over p1 and p2). While if k
is completely randomly chosen, after N message signatures, all we have is N
equations with N + 1 unknowns, which is not solvable.

On Wed, Nov 23, 2022 at 4:12 AM Lloyd Fournier <lloyd.fourn at gmail.com>
wrote:

> Hi Goran,
>
> Unfortunately these kinds of constructions are not secure. R must be
> indistinguishable from random for each attestation from the perspective of
> the users. It cannot be a product of p1 and some publicly known value. You
> can easily recover p2 from two attestations with the same p1 in this case.
>
> Fortunately we do have a new viable DLC style protocol that does not use R
> using BLS signatures. See [1,2].
>
> [1] https://mailmanlists.org/pipermail/dlc-dev/2022-August/000149.html
> [2] https://eprint.iacr.org/2022/499
>
> LL
>
> On Tue, 22 Nov 2022 at 19:15, Goran via dlc-dev <dlc-dev at mailmanlists.org>
> wrote:
>
>> Hello,
>>
>> I've been playing with DLC lately. Mainly with oracle implementation in
>> regard to perpetual contracts. And my biggest concern is the number of R
>> values needed to be pre-committed and to be saved by the oracle. If oracle
>> pre-commits to R-value where the contract is going to be resolved after a
>> longer time period (weeks, months) it is not a big issue. But in the case
>> of perpetual contracts, which are resolved every hour(or less), the number
>> of R values for an oracle and contract participants to store starts to grow
>> rapidly. Especially if besides price we are interested in open price,
>> closed price, RSI, EMA, etc. We could also be interested in 4h, 1D, or
>> weekly charts. Oracle has to precompute and publish R for each trading pair
>> (BTC/USD, EUR/LTC, etc...), for each price indicator (open, close, EMA,
>> RSI, etc...), for each time interval (1h, 4h, 1D, etc...), for each moment
>> in the time interval from the moment oracle is created to infinity. To
>> reduce storage impact oracle can publish R on demand, but in the case of
>> perpetual contracts, all R values have to be pre-committed and published at
>> least a couple of hours or a day ahead, so that contract participants can
>> create their CTEs on time. Also what do with old(already signed or not yet
>> signed events)? Delete or hold them for some time?
>>
>> The issue made me think. From the oracle and contract participants'
>> perspective, it would be nice if contract participants could calculate R
>> without contacting the oracle, but only the oracle can calculate k. (R =
>> k*G). My first idea was to use something like HD wallets from bitcoin, but
>> then I thought there might be something simpler.
>>
>> Rather than commit R for every possible (trading pair, price indicator,
>> time, digit, mantissa, exponent, ...) combination, oracle just commits to
>> two public keys (P1, P2) for all oracle events:
>>
>> P1 = p1 * G
>> P2 = p2 * G
>>
>> Only oracle knows p1 and p2.
>> p2 has the same role as the private key in the regular Schnorr signature.
>> p1 is used to generate k(and thus R). P2 is used to generate R by
>> contract participants.
>>
>> If we recall Schnorr singature is:
>>  s = k + hash(m || R) * p2
>> and a signature public key is:
>>  S = R + hash(m || R) * P2
>>
>> Now, we change R to depend on the message:
>>
>> k = hash(m || P2) * p1
>> R = hash(m || P2) * P1
>>
>> Only oracle can calculate k, but every contract participant can calculate
>> R for any message(and thus signature public key S for their CTEs) in
>> advance. Contract participants need to contact the oracle only for the
>> contract resolution. Oracle doesn't have to store any additional data
>> except two private keys.
>>
>> Every oracle has to publish which format of the messages they support,
>> for instance: "It was [cloudy|rainy|sunny] at yyyy-mm-dd hh:mm", "Closing
>> price of bitcoin at yyyy-mm-dd was greater than %d", etc...
>> When a contract resolution event is reached, participants will contact
>> the oracle with a message, matching oracle format, to sign. For instance:
>> "It was cloudy at 2022-11-11 12:00". Oracle will parse the message and if
>> the statement matches the oracle's knowledge of the event, the oracle will
>> sign the message. If the message is not in the correct format or the
>> statement is false, the oracle will not sign the message, and it will
>> return an error response.
>>
>>
>> What's lost?
>>
>> Because R is now calculated from the message, two different messages for
>> the same event will produce two different R values. This means that an
>> oracle can sign two different outcomes for the same event without revealing
>> its private key. Oracle revealing a private key, if it signs two different
>> outcomes is a nice feature, but in the case of DLC, it doesn't bring much.
>> At least I couldn't come up with a valid reason, what would be the benefit
>> to the oracle in signing two different outcomes. I could see a benefit in
>> signing the wrong outcome if one counterparty bribes the oracle, but not
>> two outcomes.
>>
>> With pre-committed R, an oracle can deposit some funds into an address
>> with a public key corresponding to the public key of the oracle. If oracle
>> signs two messages with the same R this private key is leaked, and anyone
>> will be able to collect those funds. Again, I don't think something like
>> this is a likely scenario. Because, if oracle is ready to sign two
>> different outcomes(for whatever reason), the first thing it will do is to
>> move those funds, and then sign two different R outcomes. Sure, contract
>> participants will be aware in advance that oracle is going rogue when those
>> funds are moved, but they can't do anything about it. All they can do
>> against the oracle is to publish the proof of double sign. Which is the
>> same as what contract participants without pre-committed R-value will do.
>> In both DLC implementations, with or without pre-committed R, contract
>> participants will publish two conflicting signed messages from the oracle
>> as proof of cheating. Also, it might be possible to write a CET, in such a
>> matter if multiple outcomes are signed contract is nullified, and thus
>> minimize the consequences of this scenario.
>>
>> I'm no expert in this field at all, and I might be missing something big
>> here. I'd love to hear what you think.
>>
>> Best Regards,
>> Goran
>>
>> dlc-dev mailing list
>> dlc-dev at mailmanlists.org
>> https://mailmanlists.org/mailman/listinfo/dlc-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20221123/488f9e6a/attachment-0001.htm>