mirror of
https://github.com/aljazceru/dlcspecs.git
synced 2025-12-17 06:14:23 +01:00
104 lines
4.7 KiB
Markdown
104 lines
4.7 KiB
Markdown
# 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 <antoine.riard@gmail.com>
|
|
|
|
|
|
<br>
|
|
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
|