NIP-88: Discreet Log Contracts over Nostr

[benthecarman]

Still pretty heavy WIP but wanted to get it out there for other people's feedback in nostr and DLC communities.

Will be implementing this in: MutinyWallet/mutiny-node#888

[bennyhodl]

Would using NIP-44, if merged, be a better option?

Instead of having to generate child keys for different contracts?

[benthecarman]

Would using NIP-44, if merged, be a better option?

Instead of having to generate child keys for different contracts?

Tried to read through and it is just a bunch of python code. But yeah not having to derive individual keys for every contract would be a benefit

[staab]

NIP 44 is currently being audited, it should be done pretttty soon.

[erskingardner]

I'd be super curious to hear more about the use case you're planning on implementing in Mutiny (if you want to talk about it publicly). You mentioned betting and a marketplace for DLCs in the NIP draft. Is this mostly about wagers/bets with friends?

[benthecarman]

I'd be super curious to hear more about the use case you're planning on implementing in Mutiny (if you want to talk about it publicly). You mentioned betting and a marketplace for DLCs in the NIP draft. Is this mostly about wagers/bets with friends?

Yes, but can also be for financial things like creating pseudo stable coins

[tvolk131]

I'm working on a team that's building a bounty adjudication system using DLCs and we were already planning on using Nostr as the communication protocol so it's awesome to see this spec proposed! For our use-case, we need a way for a potential participant in a DLC to request that an oracle create a new event announcement that it can then use. The announcement would be for a particular bounty, and if the oracle created the announcement it would be signing up to adjudicate whether the bounty is completed in the future. Would it make sense to add some method of requesting an oracle to create an announcement for an event? I would guess there are other potential use-cases for such behavior.

[bennyhodl]

I'm working on a team that's building a bounty adjudication system using DLCs and we were already planning on using Nostr as the communication protocol so it's awesome to see this spec proposed! For our use-case, we need a way for a potential participant in a DLC to request that an oracle create a new event announcement that it can then use. The announcement would be for a particular bounty, and if the oracle created the announcement it would be signing up to adjudicate whether the bounty is completed in the future. Would it make sense to add some method of requesting an oracle to create an announcement for an event? I would guess there are other potential use-cases for such behavior.

Maybe having a discovery kind for Oracles? Or it could be similar NIP-11 that flags the API's that the Oracle could attest to.

[benthecarman]

I'm working on a team that's building a bounty adjudication system using DLCs and we were already planning on using Nostr as the communication protocol so it's awesome to see this spec proposed! For our use-case, we need a way for a potential participant in a DLC to request that an oracle create a new event announcement that it can then use. The announcement would be for a particular bounty, and if the oracle created the announcement it would be signing up to adjudicate whether the bounty is completed in the future. Would it make sense to add some method of requesting an oracle to create an announcement for an event? I would guess there are other potential use-cases for such behavior.

Tbh this sounds out of scope and more applicable to something like DVMs

[bennyhodl]

I don't think DLC messages should be ephemeral. It would cause issues of clients not being connected to completely miss messages.

I think that when an unseen event is received by a client it should request the event to be deleted with https://github.com/nostr-protocol/nips/blob/master/09.md and only be stored on the client side.

[benthecarman]

I don't think DLC messages should be ephemeral. It would cause issues of clients not being connected to completely miss messages.

Agreed, there isn't really a message type that works well for this however. What mutiny does for nwc would be ideal but this isn't standardized. What we do is store the event until it gets a reply from the correct pubkey.

I think that when an unseen event is received by a client it should request the event to be deleted with master/09.md and only be stored on the client side.

Most relays don't implement deletion AFIAK and isn't really reliable because someone can just rebroadcast the event, or it might be on another relay.

[benthecarman]

I don't think DLC messages should be ephemeral. It would cause issues of clients not being connected to completely miss messages.

I think that when an unseen event is received by a client it should request the event to be deleted with master/09.md and only be stored on the client side.

Changed to kind 8,888, just a normal event. I think this is best, then the user can just timestamp and sync dlc messages from their last known checkpoint.

[conduition]

The draft looks great! I'm personally looking forward to moving my oracle to Nostr. This would make DLCs far more easily consumable by clients.

This NIP combined with the ECash DLCs NUT could be extremely powerful.

@benthecarman Are you still working on this? If not I'd be happy to continue the effort.

[conduition]

Right here seems to be the perfect spot to insert a description of the DLC messages' structure and encoding. Assuming you meant it this way, we should add a link to the DLC specifications to be explicit about what the base64 contract details, or base64 oracle announcement concretely encode.

Suggested change

	they open their wallet. This allows for a more mobile-friendly DLC experience.
	they open their wallet. This allows for a more mobile-friendly DLC experience.
	DLC protocol messages are binary-serialized messages described concretely in
	[this document](https://github.com/discreetlogcontracts/dlcspecs/blob/master/Messaging.md).
	Whenever embedding DLC messages inside Nostr events (which are encoded as JSON), we serialize DLC messages in base64.

[conduition]

NIP04 describes how to encrypt text messages and assumes that text is UTF8-encoded already.

Since we're using base64(binary(dlc_message)) as event content elsewhere in this NIP, I think it would be wise to clarify exactly what encoding of the DLC message should be encrypted. Are we doing aes(key, binary(dlc_message)), or aes(key, base64(binary(dlc_message)))?

[conduition]

Oracle announcements also contain an event_id field, and so do oracle attestations. Announcement event IDs must be distinct from the Nostr kind:88 event IDs (due to the fact that the announcement is part of the preimage for the nostr event ID). This might cause some confusion.

Perhaps we should clarify that the e tag must be the Nostr event ID, not the announcement event ID, and that the e tag should be used to look up the Nostr event which embeds an oracle announcement.

One might want to enforce on the client that the oracle_attestation data embeds the same announcement event ID that you find by looking up the event indicated by the e tag. In pseudocode:

def validate_attestation_event(attestation_event):
  oracle_attestation = decode_attestation(attestation_event.content)
  announcement_event = nostr_event_lookup(attestation_event.tags.e)
  oracle_announcement = decode_announcement(announcement_event.content)
  assert oracle_announcement.event_id == oracle_attestation.event_id

[conduition]

PR to address the above concerns: benthecarman#1

[1440000bytes]

This NIP combined with cashubtc/nuts#128 could be extremely powerful.

This makes it useless for any real betting. Would only be limited to less than 100 people active on nostr using ecash who want to play with trusted users with some sats.

[conduition]

@1440000bytes This NIP doesn't try to tell clients how they should settle DLCs. Clients are free to use on-chain, off-chain, side-chain, or even cross-chain settlement layers to buy into and enforce DLCs. The purpose of this NIP is simply to standardize certain Nostr event kinds so that relays can be used as a discovery layer for DLC oracles, and as marketplaces for DLC offers, regardless of the settlement layer they wish to use.

[conduition]

This reminds me: @benthecarman what do you think of adding a settlement tag to the kind:30088 event to allow the offerer to specify which settlement layer implementations they support?

{
  "kind": 30088,
  "content": "base64 contract_info",
  "tags": [
    // ...
    [
      "settlement",
      "btc",
      "dlctix",
      "cashu:https://mint.minibits.cash/Bitcoin"
    ]
  ],
  // ...
}

[conduition]

@benthecarman I submitted a PR which adds title and description tags to the announcement event type