[dlc-dev] Fraud Proofs for V0

[LE GUILLY THIBAUT]

> 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).

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.

> 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.

Thibaut

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/2e87ecb2/attachment.htm>