[dlc-dev] Fraud Proofs for V0

[Chris Stewart]

Realized I just sent this to Antoine, and not the entire list. Oops

>Let's assume some structured event about Chicago wheat price has a generic
hardship outcome, vaguely defined by event policy i.e "if heavy rain in
Ohio, us, Olivia will sign the hardship outcome". Whether "heavy rain" is
correct and well-qualified will be super hard to evaluate automatically and
better there to refer to a human.

In my head, I think there are similarities between this problem and the
programming language wars between dynamic and static typing. On one side
you have the dynamic typing people that just "want to test it out, or build
a proof of concept and not have the compiler be in their way" whereas folks
in the static typing camp want "guarantees about correctness, instant
feedback throughout the codebase when a change is made".

At the end of the day, I think tooling is the best way to promote healthy
oracle specifications rather than trying to get this "correct" at the
protocol level. As the market matures, we will _hopefully_ see very
rigorous unambiguous oracle announcements, but that might be
counterproductive in the nascent stages of DLC where just want people to
try things out.

One thing we should encourage is attesting to public events that others can
audit to verify the accuracy of the attestation, so there at least be a
reputation hit if someone isn't attesting honestly. For instance, I
attested to the Coinbase BTC/USD market price being less than $50,000
USD[1]. Anyone that was subscribing to the coinbase market data feed, or
has access to historical market data sets can verify this.

If this was done with a private event, you have little recourse and have to
blindly trust the oracle even more so than is required in the DLC protocol.

[1] -
https://oracle.suredbits.com/event/b56e01611ca3b6bc7f6a91ad4ae8828f33671f1d58f8ac7848e5050f7c54d0b6

On Sun, Feb 28, 2021 at 1:51 PM Antoine Riard via dlc-dev <
dlc-dev at mailmanlists.org> wrote:

> Hi list,
>
> I share the belief that oracle trustworthiness is an important topic but I
> think the discussion should be better bounded before to proceed on any
> fraud proof proposal. Outcome correctness is currently ill-defined, it's
> pretty straightforward to understand in case of binary outcome, but far
> harder to evaluate when it's a numeric outcome or some sophisticated event
> with unary outcome.
>
> Let's assume some structured event about Chicago wheat price has a generic
> hardship outcome, vaguely defined by event policy i.e "if heavy rain in
> Ohio, us, Olivia will sign the hardship outcome". Whether "heavy rain" is
> correct and well-qualified will be super hard to evaluate automatically and
> better there to refer to a human.
>
> On the contrary, equivocation is easier to define as some
> cryptographic-provable property.
>
> Further, I'm concerned with aggregate proofs, aren't such proof easy to
> game with some covert laziness, where Olivia doesn't publish its
> attestation to let Oliver equivocate by making his secret ? I would go
> first to scratch publication proofs, otherwise laziness sounds a loophole
> in fraud-or-equivocation proof security.
>
> W.r.t to frauds propagated on a p2p network, I would be concerned about
> fraud processing being dependent on previous interactions with an oracle
> for which the proof is verified. Like having the key part of your oracle
> keying. Might be better to have proofs pinned on some bulletin boards
> fetched by the client.
>
> Glad to talk about it at the next meeting!
>
> Cheers,
> Antoine
>
> 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/20210302/7b42f1b8/attachment.htm>