Specify Client-Side Oracle Validation #120
There are no files selected for viewing
| 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 | ||
|
There was a problem hiding this comment. Isn't it also authenticated before There was a problem hiding this comment. IIUC your question, your suggesting that a DLC client could pre-authenticated events as soon as they're publicly announced by an oracle but before they're proposed as a contract by a counterparty ? I think so, added a MAY likewise : Beyond the really slight perf improvement, it might also avoid to fetch |
||
| 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` | ||
|
There was a problem hiding this comment. is this really a MUST and not a SHOULD? Above you say "SHOULD fetch any There was a problem hiding this comment. Above is a SHOULD NOT ? If you already know the If you don't know the If this If this Do you have another flow in mind ? Note, you might have a size issue on your keyring, but for now let's shrug about tricky DoS. That's a good remark, clarified with new requirements. |
||
| - 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. | ||
|
|
||
|
There was a problem hiding this comment. probably also worth mentioning that valid announcements are required in generating fraud proofs in the case of fraud later on. |
||
| # `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. | ||
|
Comment on lines
+90
to
+92
There was a problem hiding this comment. I don't really follow this part. Do you mean an unrequested There was a problem hiding this comment. It's all depend of we propagate messages in this p2p settings. If it's something similar to tx-relay on the base layer, you do have an inventory-getdata-tx messages sequence. If the inventory is already known by receiver you won't emit a getdata to save on bandwidth/CPU. If it's something like Lightning gossips, without any announcement, effectively this requirement would be a blocker to process attestations. So yeah I agree, I think that's a small mitigation against DoS assuming our p2p network fits the first model. Likely to early as a reasoning 😅 |
||
|
|
||
| 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/). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also recommend a encrypted & authenticated channel so they have less of chance of being man-in-the-middle'd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also should we add recommendations of where to obtain the oracle's keys? ie directly from oracle vs oracle explorer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I think rn we don't have specific communication protocols for oracle discovery, you might have
Even if you answer "What's a good oracle to me ?", you still have to find the list of such "good" oracles without them being hidden or unknown from you, or if you have some central repo avoiding this one becoming a bait ?
First, how do you ensure that the pubkey you're opening a E&A transport with is really owned by the entity you expect to talk with ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the point of an authenticated channel to receive oracle information if the oracle announcements (and attestations) are themselves authenticated.
I think it's up to the users who they trust more, and I don't really see a technical rational for choosing one over the other? (and thus I don't think we should recommend anything, at least at this stage).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be good to heartbeat your connections with a oracle to detect any kind of oracle censorship attempt. Wouldn't achieve its effect with unauthenticated channel. Though such heartbeat might not be great to preserve your privacy toward the oracle, trade-off...
Once we have lazyness/fraud proofs we might have some kind of scoring and selection engine? But overall agree too early for now..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah not great for privacy, and I don't really see a big upside. If you get censored there is not much you can do I think? And if there is something you can do, you should be able to do it even if you detect it only at maturation time if you setup a long enough refund time lock.
Yes we might. But still I personally feel it will be up to the users which scoring or selection engine they'd want to chose, or if they just trust an oracle more than those. I think what I'm saying is that such considerations might not have their place in the specifications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First we should dissociate oracle censorship from bitcoin p2p censorship. They may overlap or not. Secondly, you might have redundant communication channels, only enabled in case of emergency (including worst-case scenario sending a mail to a human operator to get involved). And if it's a tx-relay censorship, it might be hard to dissociate from a congestioned mempool...
That said, no a worry to address those issues now.