Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fraud Proofs #152

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Fraud Proofs #152

Changes from 4 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
d3bff9d
Added initial TLVs for all fraud proofs, need to add explination, req…
nkohen Mar 3, 2021
d79b7e6
Added exposition and explinations
nkohen Mar 3, 2021
b8a6a2a
Some clarifications
nkohen Mar 4, 2021
325b949
Responded to Tibo's review
nkohen Mar 4, 2021
f2fdbdd
Responded to Antoine's review
nkohen Mar 11, 2021
1f1bb2e
Fixed phrasing around aggregate attestations
nkohen Mar 16, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
154 changes: 154 additions & 0 deletions FraudProofs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,154 @@
# Fraud Proofs

## Introduction

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

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

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

then oracle attestation proofs would be as simple as wrapping the publicly broadcast oracle messages,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open to what others think though

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


#### Version 0 `oracle_attestation_proof`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


1. type: ??? (`oracle_attestation_proof_v0`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to pick type

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`]

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.
nkohen marked this conversation as resolved.
Show resolved Hide resolved
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

The most straightforward kind of oracle fraud occurs when an oracle attests to a false event outcome,
Tibo-lg marked this conversation as resolved.
Show resolved Hide resolved
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`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to pick type

2. data:
* [`oracle_attestation_proof`:`oracle_attestation_proof`]
* [`string`:`fraud_claim`]

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

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`]

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`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

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`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to pick type

2. data:
* [`oracle_attestation_proof`:`oracle_attestation_proof_1`]
* [`oracle_attestation_proof`:`oracle_attestation_proof_2`]

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to pick type

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`]

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.

## Authors

Nadav Kohen <[email protected]>

![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).