WIP Oracle validation

Closes #97

Oracle-Validation.md

@@ -0,0 +1,102 @@
+# 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:
+- SHOULD NOT fetch `oracle_public_key` if it's not already a member of client oracle keyring
+- 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_key`:
+    - MUST reject the `offer_dlc`
+
+## 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 lazy or malicious
+oracles. Authenticating event also prevent entering in a DLC position for which the event won't
+be signed, and thus losing timevalue of collaterals.
+
+# `oracle_attestation` Authentication
+
+## Requirements
+
+A node:
+- if an `oracle_attestation` has not been requested by the DLC client:
+   - MUST reject the `oracle_attestation`, even if message is valid
+- 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 reject the `oracle_attestation`
+- if the range of `signatures` is not valid against the nonces committed in the accepted announcement
+   - MUST reject 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.
+
+TODO: `oracle_attestation` should be signed against `oracle_public_key` to prevent forging of invalid `oracle_attestation` by an attacker ?
+
+# Authors
+
+Antoine Riard <[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/).