[dlc-dev] Fraud Proofs for V0

Thibaut Le Guilly thibaut at cryptogarage.co.jp
Mon Feb 22 01:52:13 CET 2021


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


More information about the dlc-dev mailing list