[dlc-dev] Fraud Proofs for V0
Thibaut Le Guilly
thibaut at cryptogarage.co.jp
Wed Feb 24 01:42:07 CET 2021
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/20210224/d1d7e859/attachment.htm>
More information about the dlc-dev
mailing list