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

LE GUILLY THIBAUT thibaut at cryptogarage.co.jp
Mon Feb 22 00:54:54 CET 2021

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

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.



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/20210222/0981ebd4/attachment.htm>

More information about the dlc-dev mailing list