[dlc-dev] Fraud Proofs for V0

Nadav Kohen nadavk25 at gmail.com
Tue Feb 23 08:51:04 CET 2021


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/20210223/4d413ad0/attachment.htm>


More information about the dlc-dev mailing list