forked from discreetlogcontracts/dlcspecs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Closes discreetlogcontracts#97
- Loading branch information
Showing
1 changed file
with
103 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,103 @@ | ||
| # Client-Side Oracle Validation | ||
|
|
||
| # Table of Contents | ||
|
|
||
| * [Abstract](#abstract) | ||
| * [General Requirements](#general-requirements) | ||
| * [Oracle-Discovery](#oracle-discovery) | ||
| * [Oracle-Validation](#oracle-validation) | ||
|
|
||
|
|
||
| ## Abstract | ||
|
|
||
| The DLC protocol relies on trust-minimized oracles mapping real-world events to signatures, those ones | ||
| then confidentially re-mapped by participants to a range of contract outcomes. A participant expected | ||
| execution of the DLC is thus function of the oracle well-behaving as announced before event | ||
| realization. In this current protocol version, oracle behavior is assumed to be trusted. This level | ||
| of trust is expressed by the client oracle selection policy, and should faithfully reflect user | ||
| oracle preferences. | ||
|
|
||
| Oracle signature usage requires confidence that the associated `oracle_public_key` is owned by the | ||
| correct remote subject (person, system or organization). The ownership is asserted by having the | ||
| client verifying a signature which is bound to an identity anchor (domain name, LN node pubkey, ...). | ||
| The evaluation of identity anchor correctness is beyond the scope of this protocol. A DLC client may | ||
| use this identity anchor as a descriptor for a reputation system. | ||
|
|
||
| # Oracle Discovery | ||
|
|
||
| Actually, no oracle discovery protocol support is mandated. The following requirements are generic | ||
| requirements, which should be swayed from only if protocol has higher built-in privacy mechanisms. | ||
|
|
||
| ## Requirements | ||
|
|
||
| A node: | ||
| * MUST persist its keyring across restart/shutdown. | ||
| * SHOULD fetch any `oracle_public_key` advertised by a "good reputation" oracle. | ||
|
|
||
| ## Rationale | ||
|
|
||
| A DLC client should desynchronize any oracle pubkey fetching from DLC contract setting, otherwise | ||
| the fetched entity may deduce an usage of oracle upcoming events. By fetching any `oracle_public_key` | ||
| available, a DLC client is hindering better potential oracle usage among a wider anonymous set. | ||
| "Good-reputation" is enforced by the client oracle selection policy and its definition is beyond this | ||
| current specification. | ||
|
|
||
| # `oracle_announcement` Authentication | ||
|
|
||
| [`oracle_announcement`](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Oracle.md#oracle-announcements) | ||
| authentication happens at `offer_dlc` reception, thus verifying binding between an event and an | ||
| oracle. | ||
|
|
||
| ## Requirements | ||
|
|
||
| A node: | ||
| - if the `oracle_public_key` is already a member of client oracle keyring: | ||
| - SHOULD NOT fetch the public key again | ||
| - otherwise: | ||
| - SHOULD fetch the public key | ||
| - if `oracle_public_key` has not been accepted by client oracle selection policy: | ||
| - MUST reject the `offer_dlc` | ||
| - if `oracle_event` signature is not valid against the `oracle_public_ke`: | ||
| - MUST reject the `offer_dlc` | ||
| - MAY pre-validate `oracle_event` signature against the `oracle_public_key` at the time of its publication | ||
|
|
||
| ## Rationale | ||
|
|
||
| Fetching `oracle_public_key` at `offer_dlc` is a privacy leak vector for the message receiver. | ||
| Assuming oracle keys fetching is done through some privacy-preserving channel, if the DLC | ||
| counterparty can trigger communications through this channel it might hinder DLC client anonymity | ||
| toward the oracle. | ||
|
|
||
| Rejecting announcement for which the `oracle_public_key` hasn't been accepted by client oracle | ||
| selection policy and announcement hasn't been authenticated prevent usage of malicious oracles. | ||
| Authenticating the event also prevents entering in a DLC position where the oracle never intends | ||
| to make the attestation, and thus losing the timevalue of the collateral. Valid announcements | ||
| are also a building block of fraud proofs. | ||
|
|
||
| # `oracle_attestation` Authentication | ||
|
|
||
| ## Requirements | ||
|
|
||
| A node: | ||
| - if an announcement for this `event_id` hasn't been previously accepted OR announcement's `oracle_public_key` and attestation's `oracle_public_key` are not equal: | ||
| - MUST ignore the `oracle_attestation` | ||
| - if the range of `signatures` is not valid against the nonces committed in the accepted announcement: | ||
| - MUST ignore the `oracle_attestation` | ||
|
|
||
| ## Rationale | ||
|
|
||
| Rejecting unrequested `oracle_attestation` prevents attestations injection by an attacker to discover | ||
| other oracles actually consumed by this DLC client. Accepting unrequested _valid_ `oracle_attestation` | ||
| and broadcasting a CET transaction on the p2p network are observable behaviors revealing DLC presenve | ||
| for the corresponding event and oracle. | ||
|
|
||
| Authenticating the `oracle_attestation` against a previously accepted announcement prevent CPU DoS | ||
| against a DLC client feeded with expensive-to-validate messages. | ||
|
|
||
| # Authors | ||
|
|
||
| Antoine Riard <[email protected]> | ||
|
|
||
|  | ||
| <br> | ||
| This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). |