1 files changed, 10 insertions, 10 deletions
diff --git a/61.md b/61.md
index fd11d3e..5ef7f68 100644
--- a/61.md
+++ b/61.md
@@ -8,19 +8,19 @@ Nutzaps
 A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
-# High-level flow
+## High-level flow
 Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
-## Alice nutzaps Bob
+### Alice nutzaps Bob
 1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
 2. She mints a token at that mint (or swaps some tokens she already had in that mint) P2PK-locked to the pubkey Bob has listed in his `kind:10019`.
 3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
-## Bob receives the nutzap
+### Bob receives the nutzap
 1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
 2. Bob's client swaps the token into his wallet.
-# Nutzap informational event
+## Nutzap informational event
 ```jsonc
 {
    "kind": 10019,
@@ -39,7 +39,7 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
 * `mint`: mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
 * `pubkey`: Public key that MUST be used to P2PK-lock receiving nutzaps -- implementations MUST NOT use the target user's main Nostr public key. This public key corresponds to the `privkey` field encrypted in a user's [nip-60](60.md) _wallet event_.
-## Nutzap event
+### Nutzap event
 Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the public key the recipient indicated in their `kind:10019` event.
 Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).
@@ -66,13 +66,13 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
  * `p` is the Nostr identity public key of nutzap recipient.
  * `e` is the event that is being nutzapped, if any.
-# Sending a nutzap
+## Sending a nutzap
 * The sender fetches the recipient's `kind:10019`.
 * The sender mints/swaps ecash on one of the recipient's listed mints.
 * The sender P2PK-locks to the recipient's specified public key in their `kind:10019`
-# Receiving nutzaps
+## Receiving nutzaps
 Clients should REQ for nutzaps:
 * Filtering with `#u` for mints they expect to receive ecash from.
@@ -84,7 +84,7 @@ Clients should REQ for nutzaps:
 Upon receiving a new nutzap, the client should swap the tokens into a wallet the user controls, either a [NIP-60](60.md) wallet, their own LN wallet or anything else.
-## Updating nutzap-redemption history
+### Updating nutzap-redemption history
 When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nutzap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
 Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
@@ -106,7 +106,7 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
 Events that redeem a nutzap SHOULD be published to the sender's [NIP-65](65.md) "read" relays.
-## Verifying a Cashu Zap
+### Verifying a Cashu Zap
 When listing or counting zaps received by any given event, observer clients SHOULD:
 * check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
@@ -116,7 +116,7 @@ When listing or counting zaps received by any given event, observer clients SHOU
 All these checks can be done offline (as long as the observer has the receiver mints' keyset and their `kind:10019` event), so the process should be reasonably fast.
-## Final Considerations
+### Final Considerations
 1. Clients SHOULD guide their users to use NUT-11 (P2PK) and NUT-12 (DLEQ proofs) compatible-mints in their `kind:10019` event to avoid receiving nutzaps anyone can spend.
 2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
 3. A nutzap event MUST include proofs in one of the mints the recipient has listed in their `kind:10019` and published to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.

diff --git a/61.md b/61.md index fd11d3e..5ef7f68 100644 --- a/61.md +++ b/61.md
@@ -8,19 +8,19 @@ Nutzaps
8		8
9	A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.	9	A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
10		10
11	# High-level flow	11	## High-level flow
12	Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.	12	Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
13		13
14	## Alice nutzaps Bob	14	### Alice nutzaps Bob
15	1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.	15	1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
16	2. She mints a token at that mint (or swaps some tokens she already had in that mint) P2PK-locked to the pubkey Bob has listed in his `kind:10019`.	16	2. She mints a token at that mint (or swaps some tokens she already had in that mint) P2PK-locked to the pubkey Bob has listed in his `kind:10019`.
17	3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.	17	3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
18		18
19	## Bob receives the nutzap	19	### Bob receives the nutzap
20	1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.	20	1. At some point, Bob's client fetches `kind:9321` events p-tagging him from his relays.
21	2. Bob's client swaps the token into his wallet.	21	2. Bob's client swaps the token into his wallet.
22		22
23	# Nutzap informational event	23	## Nutzap informational event
24	```jsonc	24	```jsonc
25	{	25	{
26	"kind": 10019,	26	"kind": 10019,
@@ -39,7 +39,7 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
39	* `mint`: mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.	39	* `mint`: mints the user is explicitly agreeing to use to receive funds on. Clients SHOULD not send money on mints not listed here or risk burning their money. Additional markers can be used to list the supported base units of the mint.
40	* `pubkey`: Public key that MUST be used to P2PK-lock receiving nutzaps -- implementations MUST NOT use the target user's main Nostr public key. This public key corresponds to the `privkey` field encrypted in a user's [nip-60](60.md) _wallet event_.	40	* `pubkey`: Public key that MUST be used to P2PK-lock receiving nutzaps -- implementations MUST NOT use the target user's main Nostr public key. This public key corresponds to the `privkey` field encrypted in a user's [nip-60](60.md) _wallet event_.
41		41
42	## Nutzap event	42	### Nutzap event
43	Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the public key the recipient indicated in their `kind:10019` event.	43	Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the public key the recipient indicated in their `kind:10019` event.
44		44
45	Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).	45	Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).
@@ -66,13 +66,13 @@ Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu
66	* `p` is the Nostr identity public key of nutzap recipient.	66	* `p` is the Nostr identity public key of nutzap recipient.
67	* `e` is the event that is being nutzapped, if any.	67	* `e` is the event that is being nutzapped, if any.
68		68
69	# Sending a nutzap	69	## Sending a nutzap
70		70
71	* The sender fetches the recipient's `kind:10019`.	71	* The sender fetches the recipient's `kind:10019`.
72	* The sender mints/swaps ecash on one of the recipient's listed mints.	72	* The sender mints/swaps ecash on one of the recipient's listed mints.
73	* The sender P2PK-locks to the recipient's specified public key in their `kind:10019`	73	* The sender P2PK-locks to the recipient's specified public key in their `kind:10019`
74		74
75	# Receiving nutzaps	75	## Receiving nutzaps
76		76
77	Clients should REQ for nutzaps:	77	Clients should REQ for nutzaps:
78	* Filtering with `#u` for mints they expect to receive ecash from.	78	* Filtering with `#u` for mints they expect to receive ecash from.
@@ -84,7 +84,7 @@ Clients should REQ for nutzaps:
84		84
85	Upon receiving a new nutzap, the client should swap the tokens into a wallet the user controls, either a [NIP-60](60.md) wallet, their own LN wallet or anything else.	85	Upon receiving a new nutzap, the client should swap the tokens into a wallet the user controls, either a [NIP-60](60.md) wallet, their own LN wallet or anything else.
86		86
87	## Updating nutzap-redemption history	87	### Updating nutzap-redemption history
88	When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nutzap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.	88	When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nutzap event. This is to record that this token has already been claimed (and shouldn't be attempted again) and as signaling to the recipient that the ecash has been redeemed.
89		89
90	Multiple `kind:9321` events can be tagged in the same `kind:7376` event.	90	Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
@@ -106,7 +106,7 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
106		106
107	Events that redeem a nutzap SHOULD be published to the sender's [NIP-65](65.md) "read" relays.	107	Events that redeem a nutzap SHOULD be published to the sender's [NIP-65](65.md) "read" relays.
108		108
109	## Verifying a Cashu Zap	109	### Verifying a Cashu Zap
110	When listing or counting zaps received by any given event, observer clients SHOULD:	110	When listing or counting zaps received by any given event, observer clients SHOULD:
111		111
112	* check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.	112	* check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
@@ -116,7 +116,7 @@ When listing or counting zaps received by any given event, observer clients SHOU
116		116
117	All these checks can be done offline (as long as the observer has the receiver mints' keyset and their `kind:10019` event), so the process should be reasonably fast.	117	All these checks can be done offline (as long as the observer has the receiver mints' keyset and their `kind:10019` event), so the process should be reasonably fast.
118		118
119	## Final Considerations	119	### Final Considerations
120	1. Clients SHOULD guide their users to use NUT-11 (P2PK) and NUT-12 (DLEQ proofs) compatible-mints in their `kind:10019` event to avoid receiving nutzaps anyone can spend.	120	1. Clients SHOULD guide their users to use NUT-11 (P2PK) and NUT-12 (DLEQ proofs) compatible-mints in their `kind:10019` event to avoid receiving nutzaps anyone can spend.
121	2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.	121	2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
122	3. A nutzap event MUST include proofs in one of the mints the recipient has listed in their `kind:10019` and published to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.	122	3. A nutzap event MUST include proofs in one of the mints the recipient has listed in their `kind:10019` and published to the NIP-65 relays of the recipient, failure to do so may result in the recipient donating the tokens to the mint since the recipient might never see the event.