[dlc-dev] Fraud Proofs for V0

[Nadav Kohen]

Hi Thibaut,

First I want to say that I think that it would be nice to have a standard
fraud proof message for when users detect equivocation like you mention. I
will note that this will be a couple steps more complicated than simply
including one oracle announcement and two oracle attestations as we have to
support aggregate signature points some of which include other oracles too,
so what will be needed to claim an oracle said a specific thing happened is
any aggregate signature containing the fraudulent signature as a component,
a list of announcements corresponding to all oracles involved in this
aggregate signature, and some way of detailing exactly what each oracle
said in this aggregate signature so that the fraud proof verifier can check
the announcement signatures, then validate the aggregate signature against
the aggregate signature point which it can compute from the claimed outcome
and the announcements, after which the verifier can continue having
verified that a particular oracle attested to a particular outcome. This is
then done twice with two points and the contradiction is verified from
there. A meta-data string field may also be nice to include from a UX
perspective.

Since this is the work that is required, I would like to tentatively
propose another kind of fraud proof message which contains only a single
aggregate signature and a string field making the case that it is
fraudulent. As Thibaut mentions, this cannot be verified automatically by
client software and requires that a user import the proof manually, and
then review the string field's claims given all context by the software
(specifically the deserialized details from the announcement). While this
is an inferior kind of fraud verification, I think it may still be valuable
to have in some form because it would be nice to have some way to make
black-listing oracles more user friendly. I don't think this is a perfect
solution but I think it is better to have this than not to have it.

Furthermore, if we have this second kind of fraud proof then Thibaut's
equivocation fraud proof can be constructed simply as the combination of
two such smaller fraud proofs where the fraudulent attestation in question
correspond to the same announcement.

Interested in what others think about this topic :)

Best,
Nadav

On Wed, Feb 17, 2021 at 11:58 PM LE GUILLY THIBAUT <
thibaut at cryptogarage.co.jp> wrote:

> Hi list,
>
> As part of the V0 milestone we have a section about fraud proofs [1]. One
> difficulty with fraud proofs, is how to judge that some information signed
> by an Oracle is incorrect, and especially doing so in an automated manner
> and without relying on external parties (which would pretty much end up
> being some sort of oracle themselves?). While in the future it might be
> possible to engineer some nice solutions for this, I think it is important
> to keep a reasonable scope for V0. It seems to me that the simplest and
> easiest to verify type of proof that one could get is for the case where an
> oracle signs two different outcomes for a single event, as the set of two
> (or more) signatures could easily be processed and verified automatically
> by client software.
>
> So I just wanted to check whether this would seem acceptable to people, or
> if someone can think of other simple (enough) fraud proof that it would be
> reasonably to have specified and implemented for V0.
>
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/v0Milestone.md#simple-fraud-proofs
>
> Best,
>
> Thibaut
>
> 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/20210219/67fe3f53/attachment.htm>