You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 60.md
+36-62Lines changed: 36 additions & 62 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
-
# NIP-60
2
-
## Cashu Wallet
1
+
NIP-60
2
+
======
3
+
4
+
Cashu Wallets
5
+
-------------
6
+
3
7
`draft``optional`
4
8
5
9
This NIP defines the operations of a cashu-based wallet.
@@ -13,48 +17,28 @@ The purpose of this NIP is:
13
17
This NIP doesn't deal with users' *receiving* money from someone else, it's just to keep state of the user's wallet.
14
18
15
19
# High-level flow
16
-
1. A user has a `kind:37375` event that represents a wallet.
20
+
1. A user has a `kind:17375` event that represents a wallet.
17
21
2. A user has `kind:7375` events that represent the unspent proofs of the wallet. -- The proofs are encrypted with the user's private key.
18
22
3. A user has `kind:7376` events that represent the spending history of the wallet -- This history is for informational purposes only and is completely optional.
19
23
20
24
## Wallet Event
21
25
```jsonc
22
26
{
23
-
"kind":37375,
27
+
"kind":17375,
24
28
"content":nip44_encrypt([
25
-
[ "balance", "100", "sat" ],
26
-
[ "privkey", "hexkey" ] // explained in NIP-61
27
-
]),
28
-
"tags": [
29
-
[ "d", "my-wallet" ],
29
+
[ "privkey", "hexkey" ],
30
30
[ "mint", "https://mint1" ],
31
-
[ "mint", "https://mint2" ],
32
-
[ "mint", "https://mint3" ],
33
-
[ "name", "my shitposting wallet" ],
34
-
[ "unit", "sat" ],
35
-
[ "description", "a wallet for my day-to-day shitposting" ],
36
-
[ "relay", "wss://relay1" ],
37
-
[ "relay", "wss://relay2" ],
38
-
]
31
+
[ "mint", "https://mint2" ]
32
+
]),
33
+
"tags": []
39
34
}
40
35
```
41
36
42
-
The wallet event is an addressable event `kind:37375`.
37
+
The wallet event is an replaceable event `kind:17375`.
43
38
44
39
Tags:
45
-
*`d` - wallet ID.
46
40
*`mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
47
-
*`relay` - Relays where the wallet and related events can be found. -- one or more relays SHOULD be specified. If missing, clients should follow [NIP-65](65.md).
48
-
*`unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
49
-
*`name` - Optional human-readable name for the wallet.
50
-
*`description` - Optional human-readable description of the wallet.
51
-
*`balance` - Optional best-effort balance of the wallet that can serve as a placeholder while an accurate balance is computed from fetching all unspent proofs.
52
-
*`privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's nostr private key** -- This is only used when receiving funds from others, described in NIP-61.
53
-
54
-
Any tag, other than the `d` tag, can be [NIP-44](44.md) encrypted into the `.content` field.
55
-
56
-
### Deleting a wallet event
57
-
Due to addressable event being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
41
+
*`privkey` - Private key used to unlock P2PK ecash. MUST be stored encrypted in the `.content` field. **This is a different private key exclusively used for the wallet, not associated in any way to the user's Nostr private key** -- This is only used for receiving [NIP-61](61.md) nutzaps.
58
42
59
43
## Token Event
60
44
Token events are used to record unspent proofs.
@@ -67,30 +51,29 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
// tokens that were destroyed in the creation of this token
78
-
"del": [ "token-id-1" ]
62
+
// tokens that were destroyed in the creation of this token (helps on wallet state transitions)
63
+
"del": [ "token-event-id-1", "token-event-id-2" ]
79
64
}),
80
-
"tags": [
81
-
[ "a", "37375:<pubkey>:my-wallet" ]
82
-
]
65
+
"tags": []
83
66
}
84
67
```
85
68
86
-
*`a` an optional tag linking the token to a specific wallet.
87
-
*`.content` is a [[NIP-44]] encrypted payload:
69
+
*`.content` is a [NIP-44](44.md) encrypted payload:
88
70
*`mint`: The mint the proofs belong to.
89
71
*`proofs`: unecoded proofs
90
72
*`del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.
91
73
92
-
### Spending proofs
93
-
When one or more proofs of a token are spent, the token event should be [NIP-09](09.md)-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
74
+
When one or more proofs of a token are spent, the token event should be [NIP-09](09.md)-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event (the change output should include a `del` field).
75
+
76
+
The `kind:5`_delete event_ created in the [NIP-09](09.md) process MUST have a tag `["k", "7375"]` to allow easy filtering by clients interested in state transitions.
94
77
95
78
## Spending History Event
96
79
Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
@@ -100,17 +83,16 @@ Clients SHOULD publish `kind:7376` events to create a transaction history when t
100
83
"kind":7376,
101
84
"content":nip44_encrypt([
102
85
[ "direction", "in" ], // in = received, out = sent
*`direction` - The direction of the transaction; `in` for received funds, `out` for sent funds.
113
-
*`a` - The wallet the transaction is related to.
114
96
115
97
Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
116
98
*`created` - A new token event was created.
@@ -119,18 +101,17 @@ Clients MUST add `e` tags to create references of destroyed and created token ev
119
101
120
102
All tags can be [NIP-44](44.md) encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
121
103
122
-
Multiple `e` tags can be added to a `kind:7376` event.
104
+
Multiple `e` tags can be added, and should be encrypted, except for tags with the `redeemed` marker.
123
105
124
106
# Flow
125
107
A client that wants to check for user's wallets information starts by fetching `kind:10019` events from the user's relays, if no event is found, it should fall back to using the user's [NIP-65](65.md) relays.
126
108
127
109
## Fetch wallet and token list
128
110
From those relays, the client should fetch wallet and token events.
While the client is fetching (and perhaps validating) proofs it can use the optional `balance` tag of the wallet event to display a estimate of the balance of the wallet.
134
115
135
116
## Spending token
136
117
If Alice spends 4 sats from this token event
@@ -147,9 +128,7 @@ If Alice spends 4 sats from this token event
When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [NIP-40](40.md)matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
170
+
When creating a quote at a mint, an event can be used to keep the state of the quote ID, which will be used to check when the quote has been paid. These events should be created with an expiration tag [NIP-40](40.md) of 2 weeks (which is around the maximum amount of time a Lightning payment may be in-flight).
196
171
197
-
Application developers are encouraged to use local state when possible and only publish this event when it makes sense in the context of their application.
172
+
However, application developers SHOULD use local state when possible and only publish this event when it makes sense in the context of their application.
A Nut Zap is a P2PK cashu token where the payment itself is the receipt.
4
+
Nutzaps
5
+
-------
6
+
7
+
`draft``optional`
8
+
9
+
A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
5
10
6
11
# High-level flow
7
12
Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
8
13
9
14
## Alice nutzaps Bob
10
15
1. Alice fetches event `kind:10019` from Bob to see the mints Bob trusts.
11
-
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`.
12
17
3. She publishes a `kind:9321` event to the relays Bob indicated with the proofs she minted.
13
18
14
19
## Bob receives the nutzap
@@ -29,65 +34,57 @@ Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.
29
34
}
30
35
```
31
36
32
-
`kind:10019` is an event that is useful for others to know how to send money to the user.
33
-
34
-
*`relay` - Relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
35
-
*`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.
36
-
*`pubkey` - Pubkey that SHOULD be used to P2PK-lock receiving nutzaps. If not present, clients SHOULD use the pubkey of the recipient. This is explained in Appendix 1.
37
+
*`kind:10019` is an event that is useful for others to know how to send money to the user.
38
+
*`relay`: relays where the user will be reading token events from. If a user wants to send money to the user, they should write to these relays.
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_.
37
41
38
42
## Nutzap event
39
-
Event `kind:9321` is a nutzap event published by the sender, p-tagging the recipient. The outputs are P2PK-locked to the pubkey the recipient indicated in their `kind:10019` event or to the recipient pubkey if the `kind:10019` event doesn't have a explicit pubkey.
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.
40
44
41
-
Clients MUST prefix the pubkey they p2pk-lock with `"02"` (for nostr<>cashu pubkey compatibility).
45
+
Clients MUST prefix the public key they P2PK-lock with `"02"` (for nostr<>cashu compatibility).
[ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nut zap
56
+
[ "p", "e9fbced3a42dcf551486650cc752ab354347dd413b307484e4fd1818ab53f991" ], // recipient of nutzap
55
57
]
56
58
}
57
59
```
58
60
59
61
*`.content` is an optional comment for the nutzap
60
-
*`amount` is a shorthand for the combined amount of all outputs. -- Clients SHOULD validate that the sum of the amounts in the outputs matches.
61
-
*`unit` is the base unit of the amount.
62
-
*`proof` is one ore more proofs p2pk-locked to the pubkey the recipient specified in their `kind:10019` event.
63
-
*`u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
64
-
*`e` zero or one event that is being nutzapped.
65
-
*`p` exactly one pubkey, specifying the recipient of the nutzap.
66
-
67
-
WIP: Clients SHOULD embed a DLEQ proof in the nutzap event to make it possible to verify nutzaps without talking to the mint.
62
+
*`.tags`:
63
+
*`proof` is one ore more proofs P2PK-locked to the public key the recipient specified in their `kind:10019` event and including a DLEQ proof.
64
+
*`u` is the mint the URL of the mint EXACTLY as specified by the recipient's `kind:10019`.
65
+
*`p` is the Nostr identity public key of nutzap recipient.
66
+
*`e` is the event that is being nutzapped, if any.
68
67
69
68
# Sending a nutzap
70
69
71
70
* The sender fetches the recipient's `kind:10019`.
72
71
* The sender mints/swaps ecash on one of the recipient's listed mints.
73
-
* The sender p2pk locks to the recipient's specified pubkey in their `kind:10019`
72
+
* The sender P2PK-locks to the recipient's specified public key in their `kind:10019`
74
73
75
74
# Receiving nutzaps
76
75
77
-
Clients should REQ for nut zaps:
76
+
Clients should REQ for nutzaps:
78
77
* Filtering with `#u` for mints they expect to receive ecash from.
79
78
* this is to prevent even interacting with mints the user hasn't explicitly signaled.
80
79
* Filtering with `since` of the most recent `kind:7376` event the same user has created.
81
-
* this can be used as a marker of the nut zaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
82
-
83
-
Clients MIGHT choose to use some kind of filtering (e.g. WoT) to ignore spam.
80
+
* this can be used as a marker of the nutzaps that have already been swaped by the user -- clients might choose to use other kinds of markers, including internal state -- this is just a guidance of one possible approach.
Upon receiving a new nut zap, the client should swap the tokens into a wallet the user controls, either a [[NIP-60]] wallet, their own LN wallet or anything else.
84
+
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.
88
85
89
86
## Updating nutzap-redemption history
90
-
When claiming a token the client SHOULD create a `kind:7376` event and `e` tag the original nut zap 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.
87
+
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.
91
88
92
89
Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
93
90
@@ -96,7 +93,7 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
96
93
"kind":7376,
97
94
"content":nip44_encrypt([
98
95
[ "direction", "in" ], // in = received, out = sent
99
-
[ "amount", "1", "sat" ],
96
+
[ "amount", "1" ],
100
97
[ "e", "<7375-event-id>", "relay-hint", "created" ] // new token event that was created
101
98
]),
102
99
"tags": [
@@ -107,26 +104,19 @@ Multiple `kind:9321` events can be tagged in the same `kind:7376` event.
107
104
}
108
105
```
109
106
110
-
Events that redeem a nutzap SHOULD be published to the sender's [[NIP-65]] relays.
107
+
Events that redeem a nutzap SHOULD be published to the sender's [NIP-65](65.md) "read" relays.
111
108
112
109
## Verifying a Cashu Zap
113
-
* Clients SHOULD check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
114
-
* Clients SHOULD check that the token is locked to the pubkey the user has listed in their `kind:10019`.
110
+
When listing or counting zaps received by any given event, observer clients SHOULD:
115
111
116
-
## Final Considerations
112
+
* check that the receiving user has issued a `kind:10019` tagging the mint where the cashu has been minted.
113
+
* check that the token is locked to the pubkey the user has listed in their `kind:10019`.
114
+
* look at the `u` tag and check that the token is issued in one of the mints listed in the `kind:10019`.
115
+
* locally verify the DLEQ proof of the tokens being sent.
117
116
118
-
1. Clients SHOULD guide their users to use NUT-11 (P2PK) compatible-mints in their `kind:10019` event to avoid receiving nut zaps anyone can spend
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.
119
118
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
121
2. Clients SHOULD normalize and deduplicate mint URLs as described in NIP-65.
121
-
122
-
3. A nut zap MUST be sent to a mint the recipient has listed in their `kind:10019` event or 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.
123
-
124
-
## Appendix 1: Alternative P2PK pubkey
125
-
Clients might not have access to the user's private key (i.e. NIP-07, NIP-46 signing) and, as such, the private key to sign cashu spends might not be available, which would make spending the P2PK incoming nutzaps impossible.
126
-
127
-
For this scenarios clients can:
128
-
129
-
* add a `pubkey` tag to the `kind:10019` (indicating which pubkey senders should P2PK to)
130
-
* store the private key in the `kind:37375` event in the nip44-encrypted `content` field.
131
-
132
-
This is to avoid depending on NIP-07/46 adaptations to sign cashu payloads.
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.
0 commit comments