[dlc-dev] Support for non-corresponding multi-oracle DLCs

Nadav Kohen nadavk25 at gmail.com
Tue Feb 23 09:28:20 CET 2021

Hi Thibaut,

Thanks for the response, I'll try to present a couple examples that might
help clarify things.

As a toy example, say that you are using 2-of-3 (unsigned) numeric oracles,
Alice, Bob, and Carol, where Alice and Bob both have `num_digits = 7` but
Carol only has `num_digits = 6`.
Let's say that you and I enter into a DLC with 127,000 satoshis collateral
on the payout curve `offer_payout = outcome*1,000`.
Under either option, we build as if everyone had `num_digits = 6` but where
we add the prefix digit 0 for all Alice and Bob digit prefixes.
Then, after the normal CET set is built, we need to build CETs to cover the
cases where Alice and/or Bob sign a leading digit of 1 (outcome >= 64).
Under Option 1, we would simply have our payout curve defined only on the
`num_digits = 6` domain where the final value corresponds to `63 or more`.
Under Option 2, we would build CETs to actually cover the payout curve for
the entire domain (picked by the users, which can reach any number from 63
to 127) in the case that Alice and Bob agree, but in the case that they
disagree, we essentially don't have 2-of-3 protection because Carol offers
no protection other than that `outcome >= 63` so that either Alice's or
Bob's price can be used to execute.

As a toy example for enumerated events, say we are using 2-of-3
weather enum oracles, Alice, Bob, and Carol, where Alice and Bob both have
the enums ['sunny', 'cloudy', 'precipitation'] but Carol has the enum
['sunny', 'cloudy', 'raining', 'snowing', 'hailing'].
This seems to me like a situation we would want to be able to support
because it seems intuitively right that we should be able to build a
contract on the first enum and have valid execution include paths like
"Alice says precipitation and Carol says snowing."
As such this seems like something worth supporting and the two proposals
I've come up with are to either have a list [ { "Alice" : "sunny", "Bob" :
"sunny" }, ..., { "Bob" : "precipitation", "Carol" : "hailing" } ] (where
names will likely be replaced with indices or something) of all CETs that
need to be built or else we can construct a single meta-enum [ "sunny",
"cloudy", "precipitation" ] along with a map for each oracle's events to
this meta-enum (identity map for Alice and Bob in this example, and for
Carol it is sunny -> sunny, cloudy -> cloudy, and all others to
precipitation) and then build a contract (i.e. payouts) on top of this
meta-enum as you would for a single oracle.

Hope this clears things up, interested in your thoughts :)


On Sun, Feb 21, 2021 at 5:55 PM LE GUILLY THIBAUT <
thibaut at cryptogarage.co.jp> wrote:

> Hi Nadav,
> Regarding Numeric Oracle, I think option 2 is the best, but I must say
> that I don't really understand what option 1 is, in particular the second
> point. Do you have an example to clarify this? And for option 2, it's not
> really clear to me that there is a loss in security, in which sense do you
> mean that?
> For enumerated outcomes it's much less clear to me that this would be a
> desired feature and I don't really have an opinion on which one is best.
> Regards,
> Thibaut
> On Sat, Feb 20, 2021 at 6:22 AM Nadav Kohen via dlc-dev <
> dlc-dev at mailmanlists.org> wrote:
>> Hi all,
>> One of the outstanding items that needs to be resolved as part of the v0
>> milestone is support for multi-oracle DLCs where not all oracles involved
>> have exactly corresponding outcome sets [1]. Let us consider Numeric
>> outcome and Enumerated outcome oracles separately.
>> *Numeric Oracle Options*:
>> Differences can occur between numeric oracle outcome sets when oracles
>> have non-equal num_digits and/or non-equal bases.
>>    1. Use the smallest supported outcome set (intersection of all
>>    oracles' outcome sets).
>>       - Build CETs as usual but with extra prefixes where needed (such
>>       as leading zeros in the case that an oracle's num_digits is greater than
>>       the smallest num_digits).
>>       - Then separately build a set of CETs to cover all outcomes where
>>       the non-minimal oracles have more extreme outcomes than the minimal oracles.
>>    2. DLC participants specify contract bounds and accept a weakened
>>    security model in edge cases.
>>       - Build CETs as usual but using max/min value for oracles if we
>>       require something from them that is out-of-bounds.
>>       - Client software should clearly communicate what the loss in
>>       security is to the client when bounds exceed some of the oracle's support
>>       (noting that you are still better than the situation where you just ignore
>>       minimal oracles altogether because you validate that they are signing
>>       max/min value).
>>       - A benefit of this scheme is it still allows users to choose
>>       options 1 or 3 if they prefer.
>>    3. Use the largest possible supported outcome set (union of all
>>    oracles' outcome sets).
>>       - Constructed in the same way as option 2 if the largest possible
>>       bounds are chosen.
>> I think Option 2 is superior to Option 3 as they both require the same
>> amount of code to implement, but an argument could be made that Option 1 is
>> a little simpler to implement than Option 2 while Option 2 is strictly more
>> expressive than Option 1.
>> *Enumerated Oracle Options*:
>> Differences can occur between enum oracle outcome sets when oracles have
>> non-equal enumerations.
>>    1. Construct a meta-enumeration
>>       - Map each element of the meta-enumeration to all corresponding
>>       oracle-enum outcomes and then build a DLC around the meta-enumeration.
>>    2. Directly construct a list of all allowed/agreeing outcomes
>>    corresponding to the future set of CETs
>> I can't really think of many pros/cons/differences between these two
>> approaches other than that the former seems to be more portable than the
>> second.
>> I'd be really interested in what people think will be the best approach
>> for both of these cases before I start adding handling for these cases to
>> the specification and the code!
>> [1]
>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/v0Milestone.md#multi-oracle-support-for-non-corresponding-outcome-sets
>> Best,
>> Nadav
>> 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/mailman/private/dlc-dev/attachments/20210223/2a3f432b/attachment.htm>

More information about the dlc-dev mailing list