nip60/61 updates.

1 files changed, 28 insertions, 23 deletions

diff --git a/60.md b/60.md
index 8117412..23b56ac 100644
--- a/60.md
+++ b/60.md
@@ -1,5 +1,9 @@
-# NIP-60
-## Cashu Wallet
+NIP-60
+======
+
+Cashu Wallets
+-------------
+
 `draft` `optional`
 
 This NIP defines the operations of a cashu-based wallet.
@@ -22,19 +26,18 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
 {
     "kind": 37375,
     "content": nip44_encrypt([
-        [ "balance", "100", "sat" ],
-        [ "privkey", "hexkey" ] // explained in NIP-61
+        [ "privkey", "hexkey" ],
+        [ "name", "my shitposting wallet" ],
+        [ "description", "a wallet for my day-to-day shitposting" ],
+        [ "mint", "https://mint1" ]
+        // optionally "mint" and "unit" could go here
     ]),
     "tags": [
         [ "d", "my-wallet" ],
-        [ "mint", "https://mint1" ],
         [ "mint", "https://mint2" ],
         [ "mint", "https://mint3" ],
-        [ "name", "my shitposting wallet" ],
-        [ "unit", "sat" ],
-        [ "description", "a wallet for my day-to-day shitposting" ],
-        [ "relay", "wss://relay1" ],
-        [ "relay", "wss://relay2" ],
+        [ "unit", "sat" ]
+        // optionally "name" and "description" could go here
     ]
 }
 ```
@@ -44,14 +47,13 @@ The wallet event is an addressable event `kind:37375`.
 Tags:
 * `d` - wallet ID.
 * `mint` - Mint(s) this wallet uses -- there MUST be one or more mint tags.
-* `relay` - Relays where the wallet and related events can be found. -- one ore more relays SHOULD be specified. If missing, clients should follow [[NIP-65]].
 * `unit` - Base unit of the wallet (e.g. "sat", "usd", etc).
 * `name` - Optional human-readable name for the wallet.
 * `description` - Optional human-readable description of the wallet.
 * `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.
-* `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.
+* `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.
 
-Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content` field.
+The client or user MAY decide to put some tags either inside the encrypted `.content` or under the public `.tags`, `name` and `description`, for example. However, `d` MUST always be a public tag, and `mint` and `unit` must be public if the user intends to receive [NIP-61](61.md) nutzaps.
 
 ### Deleting a wallet event
 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.
@@ -67,6 +69,7 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
     "content": nip44_encrypt({
         "mint": "https://stablenut.umint.cash",
         "proofs": [
+            // one or more proofs in the default cashu format
             {
                 "id": "005c2502034d4f12",
                 "amount": 1,
@@ -74,8 +77,8 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
                 "C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
             }
         ],
-        // tokens that were destroyed in the creation of this token
-        "del": [ "token-id-1" ]
+        // tokens that were destroyed in the creation of this token (helps on wallet state transitions)
+        "del": [ "token-event-id-1", "token-event-id-2" ]
     }),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ]
@@ -84,13 +87,15 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
 ```
 
  * `a` an optional tag linking the token to a specific wallet.
- * `.content` is a [[NIP-44]] encrypted payload:
+ * `.content` is a [NIP-44](44.md) encrypted payload:
    * `mint`: The mint the proofs belong to.
    * `proofs`: unecoded proofs
    * `del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.
 
 ### Spending proofs
-When one or more proofs of a token are spent, the token event should be [[NIP-09]]-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.
+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).
+
+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.
 
 ## Spending History Event
 Clients SHOULD publish `kind:7376` events to create a transaction history when their balance changes.
@@ -115,14 +120,14 @@ Clients SHOULD publish `kind:7376` events to create a transaction history when t
 Clients MUST add `e` tags to create references of destroyed and created token events along with the marker of the meaning of the tag:
 * `created` - A new token event was created.
 * `destroyed` - A token event was destroyed.
-* `redeemed` - A [[NIP-61]] nutzap was redeemed.
+* `redeemed` - A [NIP-61](61.md) nutzap was redeemed.
 
-All tags can be [[NIP-44]] encrypted. Clients SHOULD leave `e` tags with a `redeemed` marker unencrypted.
+like on Wallet events, clients or users may choose to encrypt all tags except for `a` tags and `e` tags with a `redeemed` marker unencrypted.
 
 Multiple `e` tags can be added to a `kind:7376` event.
 
 # Flow
-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]] relays.
+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.
 
 ## Fetch wallet and token list
 From those relays, the client should fetch wallet and token events.
@@ -130,7 +135,7 @@ From those relays, the client should fetch wallet and token events.
 `"kinds": [37375, 7375], "authors": ["<my-pubkey>"]`
 
 ## Fetch proofs
-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.
+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.
 
 ## Spending token
 If Alice spends 4 sats from this token event
@@ -192,9 +197,9 @@ Her client:
 ```
 
 ## Redeeming a quote (optional)
-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]] matching the expiration of the bolt11 received from the mint; this signals to relays when they can safely discard these events.
+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 pending).
 
-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.
+However, application developers SHOULD use local state when possible and only publish this event when it makes sense in the context of their application.
 
 ```jsonc
 {