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

[Thibaut Le Guilly]

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/15ac80ef/attachment.htm>