Authors Melvin Carvalho optional draft
Disclaimer: this is an early draft and should be considered v0.0.0, use xxzap in testing, so it is not indexed. Final version should probably used OP_PUSHNUM and OP_PUSHBYTES TBD. That said the spec is ready for experimentation and feedback.
This proposal outlines a method for implementing simple on-chain zaps between Nostr users using Taproot addresses. The proposal includes specifications for both regular zaps and negative zaps (antizaps).
The ability to send zaps (micro-transactions) on-chain between Nostr users can enhance the functionality of the platform by enabling quick, easy, and decentralized financial interactions. Introducing antizaps allows for the reversal or adjustment of previous zaps.
When Alice (A) zaps Bob (B) 100000 satoshis for a note N, assuming both A and B have Nostr/Taproot addresses, the transaction would be structured as follows:
Note: that taproot address and npub are interchangable addresses with a different prefix. Sats are transferred to a UTXO the nsec can unlock.
Inputs:
A: 200200 satoshis
Outputs:
OP_RETURN: 80 bytes (640 bits) containingzap (7a6170) + version=1 (31) + type=[pn] (706e) + [NoteID] + [message]B: 100000 satoshisA: 100000 satoshis (change - fee)
The OP_RETURN output format is a work-in-progress (WIP) and would need further specification or improvements.
If NoteID is empty you are just zapping the npub nostr user.
Change can be respent back to Alice, or to a change address if preferred.
In addition to regular zaps, the proposal includes negative zaps (antizaps), which can reverse or modify previous zaps. While a zap is an upvote with a payment. An antizap is a downvote with a payment. In an antizap the payment must either be burnt or sent to a neutral party.
Format:
version + type + ID + message
Where type values are defined as:
- Regular zap
- Antizap
- Higher characters reserved for future use (e.g. e=event)
- First 3 bytes: zap all lower case (use xzap/xxzap for testing so it doesnt not get indexed)
- 2 bytes: version + type (see below)
- 32 bytes: noteID -- binary, this could be shortened with a firstbits style index, in future
- remaining bytes: message "Thanks for the share"
Total bytes: 80
- magic string zap: 3 bytes : hex 7a6170
- Version = 1 : 1 byte : hex = 31
- Type = "p" zap a nostr pubkey : 1 byte : hex = 70
- Type = "n" zap a nostr note : 1 byte : hex = 6e
- Type = antizaps : 1 byte : capitalize the type e.g. P,N
Burn addresses for anti zaps have not yet been specified and should be considered experimental at this point
1BitcoinEaterAddressDontSendf59kuE is an example of one in use, and could be used for test purposes. Though a taproot address would be better.
It is also possible to burn coins by spending them to an OP_RETURN
- The
OP_RETURNfield will carry zap information, including a version number, a unique NoteID, and an optional message. - Proper specifications and standards for encoding and decoding zap information in
OP_RETURNneed to be established. - The mechanism for verifying and processing antizaps must be defined to ensure they accurately reverse or adjust the intended zaps without abuse.
- Develop a comprehensive specification for the
OP_RETURNfield, including encoding rules and error handling. - Establish security measures to prevent misuse of zaps and antizaps.
- Create tools and libraries to facilitate the integration of zaps and antizaps into Nostr clients.
- Zaps should be indexed to give fast updates and high score tables.
- Anonymous zaps can be done using a zapping agent.
- Allow this to work with subkeys.
- Use silent payments for added privacy
- It might be an idea to push a magic number onto the script as first byte of the OP_RETURN as a synonym for OP_ZAP
- suggest OP_15 or OP_16 as the last number pushes, leaning towards 16 right now
- TBD