Fraud Proofs by nkohen · Pull Request #152 · discreetlogcontracts/dlcspecs

nkohen · 2021-03-03T22:11:01Z

Introduces oracle fraud proofs!

…uirements, and rationales

Tibo-lg

Looks good! Just some minor comments

ariard

Just achieve a first parse. I feel this proposal would benefit a lot to have :

basic security games to define new security notions like laziness, equivocation, invalidity, falseness
fully specify proving/verifying algorithms for each kind of proof (like we're doing for #114)
describe state machine for onchain/offchain interactivity (like we've done for #87)

Let me know what you think about it.

ariard · 2021-03-05T21:53:02Z

+attested to a specific outcome, which can then be used with other information to prove fraud.
+
+In theory, it would be best if DLC oracles could deliver their announcements and attestations
+using some form of broadcast channel, but in practice it is expected that oracle messages will


I would rather say anonymous network. Note, I'm not sure how you dissociate broadcast channel from P2P means in this sentence.

Maybe say that p2p propagation of oracles events is left for future spec efforts ?

Also "that oracle messages will often times be received". Is that an english sentence ?

I would rather say anonymous network. Note, I'm not sure how you dissociate broadcast channel from P2P means in this sentence.

The distinction I'm trying to make is between a twitter-like model where you can't easily tweet and have it appear different to different people as opposed to a more P2P setting where it is easier to lie to certain kinds of nodes "in private" and the much more private interaction of a REST API.

I changed the wording a little to say "public broadcast channel" and "certain P2P means."

Maybe say that p2p propagation of oracles events is left for future spec efforts ?

Doesn't really seem relevant here

Also "that oracle messages will often times be received". Is that an english sentence ?

often times has been changed to oftentimes but otherwise, I think so?

ariard · 2021-03-05T21:58:22Z

+using some form of broadcast channel, but in practice it is expected that oracle messages will
+often times be received by users via APIs and other more private and P2P means.
+
+If DLC oracle broadcast channels did exist in such a way that oracles could not commit fraud privately,


I see what you mean by broadcast channel. I think what we want is a strong primitive than broadcast channel, which is proof-of-publication. At least different in the sense of protocol participants joining the network in the future can still authenticate the proofs and with some expectations on the censorship-resistance property.

Isn't that essentially what the entire Proof of Oracle Attestation section is devoted to? proof-of-publication?

ariard · 2021-03-05T22:09:16Z

+often times be received by users via APIs and other more private and P2P means.
+
+If DLC oracle broadcast channels did exist in such a way that oracles could not commit fraud privately,
+then oracle attestation proofs would be as simple as wrapping the publicly broadcast oracle messages,


Better to say "If DLC oracle broadcast channels did exist, oracle attestation proofs would be wrapped as a publicly broadcast oracle message and as such oracles could not commit fraud privately".

If we made mandatory to publish attestation (lazyness==fraud) I think oracles couldn't cheat by restraining themselves from broadcast.

Better to say "If DLC oracle broadcast channels did exist, oracle attestation proofs would be wrapped as a publicly broadcast oracle message and as such oracles could not commit fraud privately".

This was more confusing to me than what is there right now, oracle attestation proofs wrap oracle messages, not the other way around? And it seems weird to mention that you can't commit fraud privately after as it is that fact which causes the wrapping to be valid, not the other way around though I'll admit this is a lesser problem than the first point.

Open to what others think though

ariard · 2021-03-05T22:12:12Z

+but practically speaking oracles have the ability to cheat without broadcasting fraudulent attestations publicly.
+
+Luckily, enough information is leaked to cheated DLC participants on-chain that they can still
+always generate proofs which show that a fraudulent oracle attestation must exist.


I think this point is only restrained to equivocation ? Invalid attestation won't allow to build a valid onchain transaction.

W.r.t to falseness, I think this is the same if it's published through an attestation or directly leaked onchain. It's more a "client-side" notion without a cryptographic definition.

Invalid attestation won't allow to build a valid onchain transaction.

Ah right, I change the wording to make this a more conditional sentence.

W.r.t to falseness, I think this is the same if it's published through an attestation or directly leaked onchain. It's more a "client-side" notion without a cryptographic definition.

This is incorrect, if you are using more than one nonce (due to numeric outcomes, multiple oracles, or both) then you will never be able to recover oracle attestations from on-chain information as you only have access to aggregate attestations.

ariard · 2021-03-05T22:33:05Z

+The `oracle_announcements` and `oracle_outcomes` are used to compute a signature point `S` corresponding to an anticipation of
+these oracles attesting to these outcomes.
+This signature point is used to validate that `aggregate_oracle_attestation*G = S` which proves that there must exist an attestation
+from each of the oracles in `oracle_announcements` of their corresponding outcome in `oracle_outcomes`.


I think you should define oracles_outcome. Even if it's signature, where does it come from ? Likely you should write an onchain section.

"A DLC client discovering a CET spending funding output without an adaptor secret it's aware of:
* MUST build an oracle_attestation_proof"

added a "definition" of "the strings signed by the oracles."

As for having an actual "on-chian section" I think that is likely out-of-scope for this PR and maybe even of v0 (although I'd be open to having this be created before v0 was out, just not likely a high priority).

ariard · 2021-03-05T22:34:29Z

+If `num_oracles = 1`, then the `aggregate_oracle_attestation` is directly equal to the attestation released by the one oracle. 
+As such, if one has access directly to an oracle's attestation, then this proof should use `num_oracles = 1`.
+
+The `oracle_announcements` and `oracle_outcomes` are used to compute a signature point `S` corresponding to an anticipation of


Can you explain how the computation is done or point to another part of the spec where it's described ?

Made this issue for adding a good place to link to (also has the description if you're curious): #156

ariard · 2021-03-05T22:53:37Z

+Luckily, enough information is leaked to cheated DLC participants on-chain that they can still
+always generate proofs which show that a fraudulent oracle attestation must exist.
+
+#### Version 0 `oracle_attestation_proof`


What about oracle_revoked_attestation_proof ? By broadcasting onchain an adaptor secret in contradiction with a known, authenticated oracle_attestation, the oracle did revoke such attestation.

I like how it can be compared to the Lightning model. There a honest participant will prove to the blockchain that a _commitment state) is invalid by publishing a previously-known revocation secret.

In the DLC model, substitute the invalid commitment state by the adaptor secret representing an outcome and the revocation secret by the oracle_announcement.

I wasn't able to understand what you were suggesting here, is what you're describing not exactly what an equivocation proof is?

ariard · 2021-03-05T23:03:55Z

+   * [`oracle_attestation_proof`: `oracle_attestation_proof`]
+
+This type simply consists of an `oracle_attestation_proof` proving that a specific oracle attested to
+a specific `oracle_outcome` where this outcome is not allowed by that oracle's `oracle_announcement`.


Again, can you define what's an oracle_outcome and from where it's discovered :) ?

ariard · 2021-03-05T23:11:54Z

+An important thing to keep in mind is that in the case of invalid attestations, there are no concerns related
+to recovering the `oracle_outcome` from on-chain information because there are no CETs or adaptor
+signatures built for such an outcome.
+In other words, this kind of fraud is only detectable and only important if the `oracle_outcome` is known


Shouldn't this say if the oracle_outcome is valid but the corresponding oracle_announcement is unknown ?

No. If the announcement is not known then there is no feasible way to prove fraud or attestation of any kind because you don't even know what keys are let alone messages, not really sure what it would mean for an oracle_announcement to be unknown and for anything in this document to matter.

What is being said here is that if you know the oracle_announcement and oracle_outcome and that outcome is not in the announcement then you can prove fraud, but if you don't know the oracle_outcome then you can't know that a given message is an attestation of anything because without knowledge of the outcome it is just a random 32 bytes.

benthecarman · 2021-03-11T16:44:29Z

+
+#### Version 0 `oracle_attestation_proof`
+
+1. type: ??? (`oracle_attestation_proof_v0`)


Need to pick type

benthecarman · 2021-03-11T16:49:49Z

+
+#### Version 0 `false_oracle_attestation_claim`
+
+1. type: ??? (`false_oracle_attestation_claim_v0`)


need to pick type

benthecarman · 2021-03-11T16:50:37Z

+
+#### Version 0 `oracle_equivocation_proof`
+
+1. type: ??? (`oracle_equivocation_proof_v0`)


need to pick type

benthecarman · 2021-03-11T16:50:41Z

+
+#### Version 1 `oracle_equivocation_proof`
+
+1. type: ??? (oracle_equivocation_proof_v1)


need to pick type

Tibo-lg · 2021-03-17T20:54:03Z

I realized that with the new attestation scheme there is another possible kind of fraud from oracles, which is to produce two different announcements. I don't think this is covered here?

Christewart · 2022-04-12T22:52:16Z

Does this have two implementations ? cc @Tibo-lg @nkohen @matthewjablack @benthecarman (I need to look into bitcoin-s, but maybe ben/nadav know)

Tibo-lg · 2022-04-13T05:48:00Z

Does this have two implementations ? cc @Tibo-lg @nkohen @matthewjablack @benthecarman (I need to look into bitcoin-s, but maybe ben/nadav know)

I don't have it implemented on my side at least.

nkohen added 2 commits March 3, 2021 03:04

Added initial TLVs for all fraud proofs, need to add explination, req…

d3bff9d

…uirements, and rationales

Added exposition and explinations

d79b7e6

nkohen added enhancement New feature or request oracle design application-layer labels Mar 3, 2021

nkohen added this to the v0.1 milestone Mar 3, 2021

Tibo-lg reviewed Mar 4, 2021

View reviewed changes

Comment thread FraudProofs.md Outdated

Comment thread FraudProofs.md Outdated

Comment thread FraudProofs.md

Comment thread FraudProofs.md Outdated

nkohen added 2 commits March 4, 2021 01:23

Some clarifications

b8a6a2a

Responded to Tibo's review

325b949

nkohen force-pushed the fraud-proofs branch from 91b5c3f to 325b949 Compare March 4, 2021 08:42

Tibo-lg approved these changes Mar 4, 2021

View reviewed changes

ariard reviewed Mar 5, 2021

View reviewed changes

ariard mentioned this pull request Mar 10, 2021

Specify Client-Side Oracle Validation #120

Merged

Responded to Antoine's review

f2fdbdd

benthecarman reviewed Mar 11, 2021

View reviewed changes

Fixed phrasing around aggregate attestations

1f1bb2e


		#### Version 0 `oracle_attestation_proof`

		1. type: ??? (`oracle_attestation_proof_v0`)


		#### Version 0 `false_oracle_attestation_claim`

		1. type: ??? (`false_oracle_attestation_claim_v0`)


		#### Version 0 `oracle_equivocation_proof`

		1. type: ??? (`oracle_equivocation_proof_v0`)


		#### Version 1 `oracle_equivocation_proof`

		1. type: ??? (oracle_equivocation_proof_v1)

Conversation

nkohen commented Mar 3, 2021

Uh oh!

Tibo-lg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ariard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tibo-lg commented Mar 17, 2021

Uh oh!

Christewart commented Apr 12, 2022

Uh oh!

Tibo-lg commented Apr 13, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants