[dlc-dev] Fraud Proofs for V0

[Nadav Kohen]

Hey all,

I have formalized my proposal for fraud proofs:
https://github.com/discreetlogcontracts/dlcspecs/pull/152

Feedback welcome!

Best,
Nadav

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

> Hi Nadav,
>
> Regarding serialization:
>
> I guess I don't have any strong feeling against having a generic fraud
> proof message, though I feel it does make equivocation proofs more
> difficult to represent and process IMHO (unless we define a separate format
> for them that is composed of two generic proofs, but then we don't really
> have a single generic format anymore).
>
> Regarding aggregate proofs and just fraud proofs in general:
>
> I'm sure the actual function to compute the proof itself from on chain
> information is not that difficult to implement (even though IIRC it's
> rather computationally intensive). My main concern is that in order to make
> it usable and useful, it also requires quite some work around user
> interaction and interaction with the rest of the system (at least on my
> side). And unless you are actually going to release something on the
> Suredbit oracle explorer (and maybe specify how such a proof should be
> handled by such third party entity so that others can implement similar
> systems) by the time we want to release a V0, it's still quite unclear what
> we can do with such a proof once it has been generated. And so even though
> it might not be a huge amount of work to support (but still not trivial),
> if all that it gives is the ability to generate a proof with which the user
> can do nothing, I don't see it as something very important to v0.
>
> I note that this is only my opinion, and if most people want to include
> that in v0 so be it. I think it also depends on what "releasing V0" means.
> If it just means having things specified but not implemented or only
> supported by a single implementation/system, then we can probably include a
> lot of things. But if it means supported and compatible across
> multiple implementations then it might be good to cut things that don't
> bring actual functionalities to users. My vision is the latter but maybe
> that is something that we should discuss during our next meeting so
> everybody can share their opinion.
>
> Best,
>
> Thibaut
>
> On Tue, Feb 23, 2021 at 4:51 PM Nadav Kohen <nadavk25 at gmail.com> wrote:
>
>> Hey guys,
>>
>> > It's quite unclear to me where this proof would come from, and why the
>> user would import it. If the user is already convinced that the oracle
>> misbehaved, they can just blacklist the oracle themselves, not sure what
>> importing a proof does. And my concern with something that couldn't be
>> verified automatically is that it's cheap to just release a fraud proof
>> message all the time, making it difficult to assess which are genuine and
>> which are just spam.
>>
>> The goal of having a standard format for reporting fraud is so that it
>> will make it *easier* for users to be convinced that an oracle
>> misbehaves. You could imagine having someone post one of these standardized
>> fraud proofs to the Suredbits oracle explorer for example and then if a DLC
>> user is convinced that this does represent fraud, they can download the
>> standardized message and paste/import it into their DLC client which would
>> then independently validate the sigs and show the validated data and ask
>> for confirmation, after which the DLC client would add the oracle to a
>> blacklist and could even keep the fraud proof around so that if the user is
>> ever given an offer using the blacklisted oracle they can not only display
>> something nice to the user reminding them of what the fraud was but they
>> can even give this fraud proof to the counterparty in an offer rejection
>> message.
>>
>> All in all I agree that it is a somewhat tricky thing to have fraud proof
>> handling due to its generally non-automatic (i.e. manual) nature but I
>> don't think that invalidates the utility of having a standardized message
>> serialization, and while it is true that I could generate frivolous fraud
>> proofs at will, this is only actually an issue in a P2P setting (e.g. where
>> fraud proofs are gossipped) and should be handled there independently as
>> just another DoS/spam vector (where one solution is simply don't gossip
>> these things).
>>
>> Furthermore, since this piece of work is essentially needed in order to
>> create the compound fraud proofs which can be automatically verified
>> (equivocation) I figured that it would be reasonable to add to the spec.
>>
>> > "Aggregate" signatures are not sound and not suitable for fraud proofs
>> without the proof of knowledge (i.e. signature) on R at the moment I think.
>> > Whether aggregate attestations are included in v0 I leave completely up
>> to you guys but wanted to just point this out.
>> > Single oracle signatures are obviously sound and represent a fraud
>> proof in of themselves like you said.
>>
>> Thanks for noting this Lloyd, this is totally right we will need to
>> include the proofs of knowledge noting that this should be handled in the
>> oracle announcement in my vision of this.
>>
>> I personally think it is important to include these aggregate
>> attestations in v0 as this is a necessary piece of multi-nonce (numeric) as
>> well as multi-oracle DLCs.
>>
>> > At the moment I was only thinking about having fraud proofs that
>> contain directly oracle signatures, I think I somehow understand what you
>> have in mind, but I'm not sure it's realistic (or reasonable to expect) to
>> have that specified and implemented for v0.
>>
>> While this makes sense if we model oracles as having public broadcast
>> channels, in reality this is never really the case and they always could
>> have private back-channels. As such I think it is important to have a fraud
>> proof which can be constructed from on-chain information alone without the
>> requirement that you have access directly to the fraudulent oracle
>> signatures.
>>
>> Furthermore I disagree that this is not a realistic piece of work for v0
>> because (judging from my implementation anyway) there is no real extra work
>> to be done to make this happen that isn't already being done. Given oracle
>> signatures, DLC client implementations must compute the associated
>> aggregate outcome and its signature point, and given a
>> counterparty-broadcasted on-chain CET, bitcoin-s computes this same
>> aggregate information as well by searching the space of all (aggregate)
>> adaptor secrets against the CET signature used on-chain (with the
>> optimization of using the CET output values to narrow this down). Happy to
>> link to code if anyone is interested feel free to DM me for it :)
>> I'm not seeing what work is introduced here that isn't already done just
>> without a standard serialization of a message describing these things in
>> the case of fraud.
>>
>> Looking forward to hearing your responses :)
>>
>> - Nadav
>>
>>
>> On Sun, Feb 21, 2021 at 6:52 PM Thibaut Le Guilly <
>> thibaut at cryptogarage.co.jp> wrote:
>>
>>> Ah missed that thanks for the clarification :)
>>>
>>> Thibaut
>>>
>>> On Mon, Feb 22, 2021 at 9:48 AM Lloyd Fournier <lloyd.fourn at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 22 Feb 2021 at 11:26, LE GUILLY THIBAUT <
>>>> thibaut at cryptogarage.co.jp> wrote:
>>>>
>>>>>
>>>>> > As I have mentioned to Nadav in DM unless you provide a proof of
>>>>> knowledge on R in the announcement I don't think the fraud proof is sound.
>>>>> i.e. just because you have an aggregate s that should include a `s` share
>>>>> from a particular oracle doesn't mean the oracle actually contributed their
>>>>> share. It is currently *not* safe to combine `s` values from oracles.
>>>>>
>>>>> At the moment I was only thinking about having fraud proofs that
>>>>> contain directly oracle signatures, I think I somehow understand what you
>>>>> have in mind, but I'm not sure it's realistic (or reasonable to expect) to
>>>>> have that specified and implemented for v0.
>>>>>
>>>>>
>>>> I am replying to Nadav's specific wording:
>>>>
>>>> > 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.
>>>>
>>>> "Aggregate" signatures are not sound and not suitable for fraud proofs
>>>> without the proof of knowledge (i.e. signature) on R at the moment I think.
>>>> Whether aggregate attestations are included in v0 I leave completely up
>>>> to you guys but wanted to just point this out.
>>>> Single oracle signatures are obviously sound and represent a fraud
>>>> proof in of themselves like you said.
>>>>
>>>> LL
>>>>
>>>>
>>>>> On Mon, Feb 22, 2021 at 9:07 AM Lloyd Fournier <lloyd.fourn at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, 20 Feb 2021 at 07:11, Nadav Kohen via dlc-dev <
>>>>>> dlc-dev at mailmanlists.org> wrote:
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> This makes more sense to me. It covers both equivocation and giving a
>>>>>> single wrong outcome.
>>>>>>
>>>>>> As I have mentioned to Nadav in DM unless you provide a proof of
>>>>>> knowledge on R in the announcement I don't think the fraud proof is sound.
>>>>>> i.e. just because you have an aggregate s that should include a `s` share
>>>>>> from a particular oracle doesn't mean the oracle actually contributed their
>>>>>> share. It is currently *not* safe to combine `s` values from oracles.
>>>>>>
>>>>>> Will get to proving it is secure with PoK on R this week hopefully.
>>>>>>
>>>>>> LL
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210303/8b0cda9f/attachment.htm>