dlcspecs/Oracle-Validation.md

Client-Side Oracle Validation

Table of Contents

• Abstract
• General Requirements
• Oracle-Discovery
• 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
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 antoine.riard@gmail.com

This work is licensed under a Creative Commons Attribution 4.0 International License.