NIP-88: DLC oracle announcement/attestation event kinds#1681
NIP-88: DLC oracle announcement/attestation event kinds#1681conduition wants to merge 5 commits into
Conversation
tvolk131
left a comment
tvolk131
left a comment
There was a problem hiding this comment.
Thanks for putting this together! One nitpick, otherwise LGTM!
| // optional, if this is a numeric attestation for an asset pair | ||
| ["n", "BTC"], | ||
| ["n", "USD"] |
There was a problem hiding this comment.
Is it beneficial to include this in kind-89 since you can look up the kind-88 announcement using the e tag to get the same data? The use-case for querying announcements by asset pair makes sense, but I don't see the value in being able to query for attestations by asset pair.
There was a problem hiding this comment.
I thought about this as well, but i believe @vitorpamplona wants to use these attestations for displaying current asset prices to users in GUI based on their "trusted oracle" list.
While technically you could do a two-step process as you say - first look up the announcement, then search for the corresponding attestation - it is easier and more efficient to look up attestations by asset, especially if the current price is all you care about.
Otherwise, you'd need to parse the announcements, find one that is supposed to have matured recently, and then find its corresponding attestation event.
There was a problem hiding this comment.
Ahh makes sense, thanks for the explanation!
joemphilips
left a comment
joemphilips
left a comment
There was a problem hiding this comment.
This is great. And I want to use this as well.
I left several comments.
| } | ||
| ``` | ||
|
|
||
| The `content` field must be the base64-encoding of a binary-serialized [`oracle_annoucement` object](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md#the-oracle_annoucement-type). |
There was a problem hiding this comment.
nit: typo: oracle_annoucement -> oracle_announcement.
Same for the linked URL.
|
|
||
| Oracles are responsible for choosing how to manage their attestation keypair(s). Oracle announcements and attestations embed their own copies of the oracle's BIP340 attestation public key. Oracles should ideally never change their attestation key pair between events, but they _may_ choose to migrate their attestation key, or use different keys for different types of events if they desire. Clients are responsible for choosing secure policies regarding which oracle attestation keys to trust and use. | ||
|
|
||
| **By default, all clients must accept announcement/attestation signatures issued by the oracle's Nostr key.** This requirement allows oracles to fall back on using their Nostr key pair if managing multiple keys is unnecessary, or if their existing attestation key(s) become unusable. |
There was a problem hiding this comment.
How should users know which keypair is Oracle's nostr key?
IIUC kind:88 does not assure that the event (Nostr event, not an event in DLC context) was created by the Oracle.
IMHO, this problem should be fixed by either
- Always assume that NIP88-compliant oracles must use the same key for both DLC and Nostr.
- Add another required tag "signature" to
kind:88event. Signature by Oracle's DLC key, which signs to the same thing to the "sig" field. This can be optional in the case Nostr key and DLC key are the same. - Add another event kind just to link the Oracle's DLC key and Oracle's Nostr key
I think 2 is the simplest
There was a problem hiding this comment.
Actually, this (the mechanism to tie attestation key and nostr key) is necessary only when we want the fallback mechanism. But (as I said it in the comment below), this mechanism itself should be removed so we don't need to have another tag field.
There was a problem hiding this comment.
I couldn't resolve this thread, so please resolve it if you can
|
|
||
| Oracles are responsible for choosing how to manage their attestation keypair(s). Oracle announcements and attestations embed their own copies of the oracle's BIP340 attestation public key. Oracles should ideally never change their attestation key pair between events, but they _may_ choose to migrate their attestation key, or use different keys for different types of events if they desire. Clients are responsible for choosing secure policies regarding which oracle attestation keys to trust and use. | ||
|
|
||
| **By default, all clients must accept announcement/attestation signatures issued by the oracle's Nostr key.** This requirement allows oracles to fall back on using their Nostr key pair if managing multiple keys is unnecessary, or if their existing attestation key(s) become unusable. |
There was a problem hiding this comment.
I think "must" is too strong here.
What if Oracle's Nostr key got compromised?
What if an Oracle intentionally signs to two outcomes, one with the Nostr key and one with the DLC key?
IMHO, we should not include the fallback mechanism in here to make the spec simpler.
We should always assume the Oracle key and the Nostr key are independent. Users can just use the same key for both Nostr and DLC if they are reckless.
|
|
||
| This NIP describes two event kinds, `88` and `89`, for [Discreet Log Contract (DLC)](https://bitcoinops.org/en/topics/discreet-log-contracts/) oracles to publish their announcements and attestations over Nostr. Clients can consume these signed events to create conditional payment contracts which fulfill differently based on the oracles' attestations. | ||
|
|
||
| ## Format |
There was a problem hiding this comment.
nit: I think it is better to mention that this NIP is for DLC v0. DLC might update to V1 in the future, but we can have another NIP in that case.
In this way, clients can avoid fetching a new version of DLC that they cannot understand.
|
I'm happy to take after this PR. If the author does not mind. |
create_announcement_event_with_metadata emits optional title and description tags on the kind-88 oracle announcement event per NIP-88 (nostr-protocol/nips#1681); kormir-wasm create_enum_event threads them through. The original create_announcement_event delegates with no metadata for backward compatibility.
|
Hi, thanks for offering! Please go ahead, I have since shifted my time towards other areas |
3 participants
This is meant to be a scope-reduced version of #919 to allow Discreet Log Contract (DLC) oracle announcements and attestations to be published over Nostr. I've omitted the DLC offer/accept/encrypted messages that are in #919 and instead i'm focusing only on oracle gossip messages, so that oracles can start using Nostr as an interoperable publishing medium for attestation data.
More info about DLCs in general here.
There is upstream work still going on and I don't think we should standardize some of the messages in #919 because the current DLC specs imply the use of ECDSA signatures, without aggregation. The oracle messages though are about as efficient as we can expect them to be, and as oracles form the foundation of a DLC ecosystem they should be prioritized.
Some open questions for those who might find this these events useful: