[dlc-dev] Fraud Proofs for V0

[Lloyd Fournier]

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/20210222/f14b7e8d/attachment.htm>