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

Nadav Kohen nadavk25 at gmail.com
Wed Feb 24 07:25:48 CET 2021

Hey Thibaut,

I was also leaning towards option 1 for now for numeric.

For enumerated it is true that both approaches do result in the same set of
CETs. It is really a trade-off between direct simplicity on a per-DLC basis
(just enumerating the CETs) vs. something that has more reusable parts (you
can have the same meta-enum in two different DLCs and any reused oracles
can also have the same mappings). I don't have a strong opinion either way,
really more of an aesthetic/design decision.


On Tue, Feb 23, 2021 at 7:00 PM Thibaut Le Guilly <
thibaut at cryptogarage.co.jp> wrote:

> Hi Nadav,
> Thanks a lot for the clarification, it helps a lot!
> For numeric outcomes, now that I understand I actually think option 1 is
> the best. I don't think users should be able to specify a payout curve on a
> domain which is not covered by one of the oracles they pick. Having an
> oracle signing its max value should be something unexpected and with option
> 2 it feels like we would be handling it as something which is not. I don't
> have that strong of an opinion though tbh, but again I feel like option 1
> is closer to "keeping it simple".
> For enumerated outcomes, I understand a bit better, but I don't really
> understand what will be the difference between both in terms of creating
> adaptor signatures. Won't you have to build one for each possible
> combination anyway even with your meta-enum proposal (I feel I'm missing
> something though sorry).
> Thibaut
> On Tue, Feb 23, 2021 at 5:28 PM Nadav Kohen <nadavk25 at gmail.com> wrote:
>> 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 :)
>> Nadav
>> 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/20210224/e69f97c6/attachment.htm>

More information about the dlc-dev mailing list