Author: Kukks
New protocol design: Discrete Payments through Wabisabi coinjoins and Nostr ecnrypted communication
- Merchant creates invoice of 0.1BTC
- Merchant generates a unique key for invoice
- Merchant shows the pubkey of (2), a recommended nostr relay uri
- Customer generates a unique key for this invoice payment
- Customer posts an encrypted event addressed to pubkey of (3) with a message stating intent to pay invoice of 0.1BTC using a specific wabisabi coordinator
- Merchant replies with an encrypted event with acknowledgement (or rejects)
- Customer joins next round, adds inputs >0.1 BTC, gets credentials
- Customer reissues credentials, gets one credential of 0.1BTC
- Customer posts an encrypted event addressed to pubkey of (3) with the credential in a text format
- Merchant reissues credentials
- Merchant replies with an encrypted event with acknowledgement (or rejects)
- Round enters output registration stage
- Merchant registers outputs
- Round enters tx signing stage
- Merchant verifies output is there
- Merchant replies with an encrypted event stating payment is present in tx hash
- Customer verifies round tx equals hash
- Customer signs
Notes:
- a pseudo nostr relay will connect to multiple relays and retrieve all relelavnt events and aggregate. This will then serve them in a unified entrypoint, allowing users to not leak their ip to a dedicated nostr relay for private payments
- Customer specifies which coordinator to use, not tied to only one
- Merchant can provide own coins to same coinjoin to increase anonymity
- Can theoretically chain the payments to other hops within the same coinjoin, serves as a trustless, private layer 3 equivalent to ecash systems, without the custodians (but with a much stricter time horizon)
Receiver creates payment link bip21: bitcoin:address?amount=1&ws="npub1..." (BIP21)
Share payment link to Sender
Sender parses the
ws
value, extracting a public key (KEYRECEIVER1) and a set of relay urisSender creates a new ephemeral key (KEYSENDER1) and creates a dedicated tor circuit
Sender connects to nostr relays using previously created tor circuit
Sender sends a NIP4 event (EVT1) using key KEYSENDER1 as author, addressed to KEYRECEIVER1, with contents:
Receiver chooses a coordinator from list CHOSENCOORD
Receiver replies to EVT1 with a new event (EVT2), with contents:
Sender waits for a round to be present that has at least X minutes remaining in input registration, ROUNDX
Sender replies to EVT2 with a new event (EVT3), with contents:
Sender joins round ROUNDX, registers utxos and receives credentials, then reissues into 2 credentials: CREDENTIALPAY and CREDENTIALCHANGE
Sender replies to EVT3 with new event (EVT4) with contents:
Receiver joins round {ROUNDX}, reissues {CREDENTIALPAY}, registers additional UTXOs
When Round switches to ReadyToSign, RECEIVER sends a new event (EVT5) to Sender with contents:
Sender signs coinjoin
Receiver signs coinjoin
Receiver marks payment as received (but not settled)
On successful round and transaction confirmation, mark payment as settled