zaps.md

NIP-570: On-Chain Zaps and Anti-Zaps

Authors Melvin Carvalho optional draft

Summary

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).

Motivation

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.

Specification

Zap Transaction Format

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:

Inputs:

1. A: 200200 satoshis

Outputs:

1. OP_RETURN: 80 bytes (640 bits) containing zap (7a6170) + version=1 (31) + type=[pn] (706e) + [NoteID] + [message]
2. B: 100000 satoshis
3. A: 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.

Change can be respent back to Alice, or to a change address if preferred.

Negative Zaps (Antizaps)

In addition to regular zaps, the proposal includes negative zaps (antizaps), which can reverse or modify previous zaps.

Format: version + type + ID + message

Where type values are defined as:

1. Regular zap
2. Antizap
3. Higher numbers reserved for future use

OP_RETURN in details

• First 3 bytes: zap all lower case (use xzap, testzap etc. for testing so it doesnt not get indexed)
• 2 bytes: version + type
• 32 bytes: noteID -- 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

Implementation Notes

1. The OP_RETURN field will carry zap information, including a version number, a unique NoteID, and an optional message.
2. Proper specifications and standards for encoding and decoding zap information in OP_RETURN need to be established.
3. The mechanism for verifying and processing antizaps must be defined to ensure they accurately reverse or adjust the intended zaps without abuse.

Future Work

• Develop a comprehensive specification for the OP_RETURN field, 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.

References

• Zaps NIP-57

"Chance" should be "Change", and the antizap section could use some more meat on the bone.