From d3bff9dc9d8d2de1392ee4b04115a6fd585a83ef Mon Sep 17 00:00:00 2001 From: nkohen Date: Wed, 3 Mar 2021 03:04:27 -0600 Subject: [PATCH 1/6] Added initial TLVs for all fraud proofs, need to add explination, requirements, and rationales --- FraudProofs.md | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 FraudProofs.md diff --git a/FraudProofs.md b/FraudProofs.md new file mode 100644 index 0000000..76b6b42 --- /dev/null +++ b/FraudProofs.md @@ -0,0 +1,80 @@ +# Fraud Proofs + +## Introduction + +TODO + +## Table of Contents + +* [Proof of Oracle Attestation](#proof-of-oracle-attestation) +* [Claim of False Oracle Attestation](#claim-of-false-oracle-attestation) +* [Proof of Invalid Oracle Attestation](#proof-of-invalid-oracle-attestation) +* [Proof of Oracle Equivocation](#proof-of-oracle-equivocation) +* [Authors](#authors) + +## Proof of Oracle Attestation + +TODO + +1. type: ??? (`oracle_attestation_proof_v0`) +2. data: + * [`u16`:`num_oracles`] + * [`num_oracles*oracle_announcement`:`oracle_announcements`] + * [`num_oracles*oracle_outcome`:`oracle_outcomes`] + * [`32*bytes`:`aggregate_oracle_attestation`] + * [`u16`:`oracle_index`] +3. subtype: `oracle_outcome` +4. data: + * [`nb_signatures*string`:`outcomes`] + +TODO + +## Claim of False Oracle Attestation + +TODO + +1. type: ??? (`false_oracle_attestation_claim_v0`) +2. data: + * [`oracle_attestation_proof`:`oracle_attestation_proof`] + * [`string`:`fraud_claim`] + +TODO + +## Proof of Invalid Oracle Attestation + +TODO + +1. type: ??? (`invalid_oracle_attestation_proof_v0`) +2. data: + * [`oracle_attestation_proof`: `oracle_attestation_proof`] + +TODO + +## Proof of Oracle Equivocation + +TODO + +1. type: ??? (`oracle_equivocation_proof_v0`) +2. data: + * [`oracle_attestation_proof`:`oracle_attestation_proof_1`] + * [`oracle_attestation_proof`:`oracle_attestation_proof_2`] + +TODO + +1. type: ??? (oracle_equivocation_proof_v1) +2. data: + * [`oracle_announcement`:`oracle_announcement`] + * [`nb_signatures*string`:`outcomes_1`] + * [`32*bytes`:`oracle_attestation_1`] + * [`nb_signatures*string`:`outcomes_2`] + * [`32*bytes`:`oracle_attestation_2`] + +TODO + +## Authors + +Nadav Kohen + +![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY") +
+This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). \ No newline at end of file From d79b7e63d644c0634eea8bc91b05f6d9c75a20b3 Mon Sep 17 00:00:00 2001 From: nkohen Date: Wed, 3 Mar 2021 16:09:28 -0600 Subject: [PATCH 2/6] Added exposition and explinations --- FraudProofs.md | 98 ++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 88 insertions(+), 10 deletions(-) diff --git a/FraudProofs.md b/FraudProofs.md index 76b6b42..7779f88 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -2,19 +2,47 @@ ## Introduction -TODO +In the Discreet Log Contract oracle model, oracles act as oblivious public entities while +their users act privately. + +Due to DLC oracles' public nature, should they ever commit fraudulent acts such as spreading +false, invalid, or conflicting attestations, their fraud should be easily and compactly provable +and publicly verifiable. +After all, oracle fraud comes in the form of an unforgeable attestation of false or invalid events, +or else in the form of multiple conflicting unforgeable attestations. + +This document specifies a standard format for serializing fraud proofs as well as specifying their verification. ## Table of Contents * [Proof of Oracle Attestation](#proof-of-oracle-attestation) + * [Version 0 `oracle_attestation_proof`](#version-0-oracle_attestation_proof) * [Claim of False Oracle Attestation](#claim-of-false-oracle-attestation) + * [Version 0 `false_oracle_attestation_claim` ](#version-0-false_oracle_attestation_claim) * [Proof of Invalid Oracle Attestation](#proof-of-invalid-oracle-attestation) + * [Version 0 `invalid_oracle_attestation_proof`](#version-0-invalid_oracle_attestation_proof) * [Proof of Oracle Equivocation](#proof-of-oracle-equivocation) + * [Version 0 `oracle_equivocation_proof`](#version-0-oracle_equivocation_proof) + * [Version 1 `oracle_equivocation_proof`](#version-1-oracle_equivocation_proof) * [Authors](#authors) ## Proof of Oracle Attestation -TODO +The fundamental building block of DLC oracle fraud proofs is a proof that a specific oracle +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 +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, +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. + +#### Version 0 `oracle_attestation_proof` 1. type: ??? (`oracle_attestation_proof_v0`) 2. data: @@ -27,39 +55,84 @@ TODO 4. data: * [`nb_signatures*string`:`outcomes`] -TODO +The most important piece of this proof is the `aggregate_oracle_attestation` which is recoverable from +on-chain information as the difference between the broadcast CET's signature and its corresponding adaptor signature. +In the case that one has access directly to the `oracle_attestation` in question, then this can be used in place of an aggregate. + +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`. + +Finally, this proof references a specific oracle by `oracle_index` which is the index in `oracle_announcements` and `oracle_outcomes` +corresponding to the referenced oracle's announcement and outcome to which they attested. ## Claim of False Oracle Attestation -TODO +The most straightforward kind of oracle fraud occurs when an oracle attests to a false event outcome, +meaning that the attested-to outcome is not what truly occurred in the real world. + +Unfortunately, there is no general and automatic way to validate a claim of this kind of fraud as there +is often times some amount of subjectivity involved or at the very least validation must compare what +the oracle said to the real world, a process which usually requires manual human labor. + +As such, this specification only provides a standard format for making such claims which is generally +intended for use with other external infrastructure. +That said, it is possible for DLC client software to accept the manual importing of these claims after +which user's can be taken through manual validation step-by-step. +Such a process can serve as a manual means of black-listing oracle keys. + +#### Version 0 `false_oracle_attestation_claim` 1. type: ??? (`false_oracle_attestation_claim_v0`) 2. data: * [`oracle_attestation_proof`:`oracle_attestation_proof`] * [`string`:`fraud_claim`] -TODO +This message consists of an `oracle_attestation_proof` showing that a specific oracle attested to +a specific message and a `fraud_claim` explaining why this attestation is fraudulent. ## Proof of Invalid Oracle Attestation -TODO +The next simplest form of fraud is if an oracle attests using some outcome outside of its announced +and committed to outcome set from its `oracle_announcement`. + +Unlike false attestations, this kind of fraud can be automatically validated by client software. + +#### Version 0 `invalid_oracle_attestation_proof` 1. type: ??? (`invalid_oracle_attestation_proof_v0`) 2. data: * [`oracle_attestation_proof`: `oracle_attestation_proof`] -TODO +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`. + +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 +as otherwise the invalid attestation is essentially an encrypted message and such an attestation is just +a random 32 bytes that cannot be proven to even be an attestation at all. ## Proof of Oracle Equivocation -TODO +Another form of oracle fraud for which there exists a straightforward automatic validation is equivocation. +Equivocation is when an oracle attests to multiple messages for the same event. + +Validation in this case simply requires validating that both attestations exist using `oracle_attestation_proof`s. + +#### Version 0 `oracle_equivocation_proof` 1. type: ??? (`oracle_equivocation_proof_v0`) 2. data: * [`oracle_attestation_proof`:`oracle_attestation_proof_1`] * [`oracle_attestation_proof`:`oracle_attestation_proof_2`] -TODO +The most general kind of oracle equivocation proof is simply the combination of two `oracle_attestation_proof`s +for the same `oracle_announcement` but for different `oracle_outcome`s. + +#### Version 1 `oracle_equivocation_proof` 1. type: ??? (oracle_equivocation_proof_v1) 2. data: @@ -68,8 +141,13 @@ TODO * [`32*bytes`:`oracle_attestation_1`] * [`nb_signatures*string`:`outcomes_2`] * [`32*bytes`:`oracle_attestation_2`] + * [`32*bytes`:`oracle_private_key`] + +This second kind of oracle equivocation proof is specialized and compressed (when compared to the other version) +to be optimized for equivocation proofs where the prover has direct access to non-aggregate `oracle_attestation`s. -TODO +This proof has the added feature of containing the `oracle_private_key` (which is computed from the announcement +and the two attestations). ## Authors From b8a6a2aa918b3c8035ee3d26f950facf5cf763f4 Mon Sep 17 00:00:00 2001 From: nkohen Date: Thu, 4 Mar 2021 01:23:38 -0600 Subject: [PATCH 3/6] Some clarifications --- FraudProofs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FraudProofs.md b/FraudProofs.md index 7779f88..5e31f4a 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -7,7 +7,7 @@ their users act privately. Due to DLC oracles' public nature, should they ever commit fraudulent acts such as spreading false, invalid, or conflicting attestations, their fraud should be easily and compactly provable -and publicly verifiable. +and verifiable from public information. After all, oracle fraud comes in the form of an unforgeable attestation of false or invalid events, or else in the form of multiple conflicting unforgeable attestations. @@ -57,7 +57,7 @@ always generate proofs which show that a fraudulent oracle attestation must exis The most important piece of this proof is the `aggregate_oracle_attestation` which is recoverable from on-chain information as the difference between the broadcast CET's signature and its corresponding adaptor signature. -In the case that one has access directly to the `oracle_attestation` in question, then this can be used in place of an aggregate. +In the case that one has access directly to an oracle's attestation, then this can be used as the aggregate. 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. From 325b9496d674038bfaf63d6a3569c28ad5646f67 Mon Sep 17 00:00:00 2001 From: nkohen Date: Thu, 4 Mar 2021 02:41:18 -0600 Subject: [PATCH 4/6] Responded to Tibo's review --- FraudProofs.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/FraudProofs.md b/FraudProofs.md index 5e31f4a..016a595 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -6,8 +6,7 @@ In the Discreet Log Contract oracle model, oracles act as oblivious public entit their users act privately. Due to DLC oracles' public nature, should they ever commit fraudulent acts such as spreading -false, invalid, or conflicting attestations, their fraud should be easily and compactly provable -and verifiable from public information. +false, invalid, or conflicting attestations, their fraud should be provable and verifiable from public information. After all, oracle fraud comes in the form of an unforgeable attestation of false or invalid events, or else in the form of multiple conflicting unforgeable attestations. @@ -57,7 +56,8 @@ always generate proofs which show that a fraudulent oracle attestation must exis The most important piece of this proof is the `aggregate_oracle_attestation` which is recoverable from on-chain information as the difference between the broadcast CET's signature and its corresponding adaptor signature. -In the case that one has access directly to an oracle's attestation, then this can be used as the aggregate. +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 these oracles attesting to these outcomes. @@ -141,14 +141,10 @@ for the same `oracle_announcement` but for different `oracle_outcome`s. * [`32*bytes`:`oracle_attestation_1`] * [`nb_signatures*string`:`outcomes_2`] * [`32*bytes`:`oracle_attestation_2`] - * [`32*bytes`:`oracle_private_key`] This second kind of oracle equivocation proof is specialized and compressed (when compared to the other version) to be optimized for equivocation proofs where the prover has direct access to non-aggregate `oracle_attestation`s. -This proof has the added feature of containing the `oracle_private_key` (which is computed from the announcement -and the two attestations). - ## Authors Nadav Kohen From f2fdbdd302a373604d515c95a61eb204479044e8 Mon Sep 17 00:00:00 2001 From: nkohen Date: Thu, 11 Mar 2021 01:58:12 -0600 Subject: [PATCH 5/6] Responded to Antoine's review --- FraudProofs.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/FraudProofs.md b/FraudProofs.md index 016a595..5968d62 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -31,15 +31,16 @@ The fundamental building block of DLC oracle fraud proofs is a proof that a spec 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 -often times be received by users via APIs and other more private and P2P means. +using some form of public broadcast channel, but in practice it is expected that oracle messages +will oftentimes be received by users via APIs and other more private and certain 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, 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. +Luckily in the case that anyone loses funds due to a fraudulently unlocked CET, enough information is leaked +to the 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` @@ -59,8 +60,14 @@ on-chain information as the difference between the broadcast CET's signature and 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 -these oracles attesting to these outcomes. +The `oracle_outcomes`, which are the strings signed by the oracles, are either known directly from an `oracle_attestation` +message (in the `outcome` field(s)), or they can be computed from an on-chain CET by using one's (decrypted) signature along +with their adaptor signature to compute the `aggregate_oracle_attestation` which can be used to search the space of all +possible `oracle_outcomes` by comparing `aggregate_oracle_attestation*G` to the adaptor point corresponding to any +given `oracle_outcomes`. + +The `oracle_announcements` and `oracle_outcomes` are used by a verifier 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`. From 1f1bb2e441f4d4a266077c3210fae114865236f9 Mon Sep 17 00:00:00 2001 From: nkohen Date: Tue, 16 Mar 2021 01:39:19 -0500 Subject: [PATCH 6/6] Fixed phrasing around aggregate attestations --- FraudProofs.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/FraudProofs.md b/FraudProofs.md index 5968d62..799af3f 100644 --- a/FraudProofs.md +++ b/FraudProofs.md @@ -57,7 +57,8 @@ oracle attestation must exist. The most important piece of this proof is the `aggregate_oracle_attestation` which is recoverable from on-chain information as the difference between the broadcast CET's signature and its corresponding adaptor signature. -If `num_oracles = 1`, then the `aggregate_oracle_attestation` is directly equal to the attestation released by the one oracle. +If `num_oracles = 1`, then the `aggregate_oracle_attestation` is directly equal to the aggregate of the attestations released +by the one oracle, so that if it is an enumerated outcome this is directly equal to the attestation released by the enum oracle. As such, if one has access directly to an oracle's attestation, then this proof should use `num_oracles = 1`. The `oracle_outcomes`, which are the strings signed by the oracles, are either known directly from an `oracle_attestation`