[dlc-dev] Fraud Proofs for V0

[Antoine Riard]

Hi list,

I share the belief that oracle trustworthiness is an important topic but I
think the discussion should be better bounded before to proceed on any
fraud proof proposal. Outcome correctness is currently ill-defined, it's
pretty straightforward to understand in case of binary outcome, but far
harder to evaluate when it's a numeric outcome or some sophisticated event
with unary outcome.

Let's assume some structured event about Chicago wheat price has a generic
hardship outcome, vaguely defined by event policy i.e "if heavy rain in
Ohio, us, Olivia will sign the hardship outcome". Whether "heavy rain" is
correct and well-qualified will be super hard to evaluate automatically and
better there to refer to a human.

On the contrary, equivocation is easier to define as some
cryptographic-provable property.

Further, I'm concerned with aggregate proofs, aren't such proof easy to
game with some covert laziness, where Olivia doesn't publish its
attestation to let Oliver equivocate by making his secret ? I would go
first to scratch publication proofs, otherwise laziness sounds a loophole
in fraud-or-equivocation proof security.

W.r.t to frauds propagated on a p2p network, I would be concerned about
fraud processing being dependent on previous interactions with an oracle
for which the proof is verified. Like having the key part of your oracle
keying. Might be better to have proofs pinned on some bulletin boards
fetched by the client.

Glad to talk about it at the next meeting!

Cheers,
Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210228/668a18f4/attachment.htm>