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.
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.
A node:
- MUST persist its keyring across restart/shutdown.
- SHOULD fetch any
oracle_public_key
advertised by a "good reputation" oracle.
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 happens at offer_dlc
reception, thus verifying binding between an event and an
oracle.
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
- MUST reject the
- if
oracle_event
signature is not valid against theoracle_public_ke
:- MUST reject the
offer_dlc
- MUST reject the
- MAY pre-validate
oracle_event
signature against theoracle_public_key
at the time of its publication
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.
A node:
- if an announcement for this
event_id
hasn't been previously accepted OR announcement'soracle_public_key
and attestation'soracle_public_key
are not equal:- MUST ignore the
oracle_attestation
- MUST ignore the
- if the range of
signatures
is not valid against the nonces committed in the accepted announcement:- MUST ignore the
oracle_attestation
- MUST ignore the
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.
Antoine Riard antoine.riard@gmail.com
This work is licensed under a Creative Commons Attribution 4.0 International License.