8 files changed, 409 insertions, 19 deletions

diff --git a/01.md b/01.md
index 80ee792..c1e3748 100644
--- a/01.md
+++ b/01.md
@@ -14,7 +14,7 @@ Each user has a keypair. Signatures, public key, and encodings are done accordin
 
 The only object type that exists is the `event`, which has the following format on the wire:
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -22,7 +22,7 @@ The only object type that exists is the `event`, which has the following format
   "kind": <integer between 0 and 65535>,
   "tags": [
     [<arbitrary string>...],
-    ...
+    // ...
   ],
   "content": <arbitrary string>,
   "sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
@@ -58,17 +58,16 @@ To prevent implementation differences from creating a different event ID for the
 
 Each tag is an array of strings of arbitrary size, with some conventions around them. Take a look at the example below:
 
-```json
+```jsonc
 {
-  ...,
   "tags": [
     ["e", "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "wss://nostr.example.com"],
     ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca"],
     ["a", "30023:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:abcd", "wss://nostr.example.com"],
     ["alt", "reply"],
-    ...
+    // ...
   ],
-  ...
+  // ...
 }
 ```
 
@@ -125,7 +124,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "ids": <a list of event ids>,
   "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
   "kinds": <a list of a kind numbers>,
-  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of event pubkeys etc>,
+  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
   "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
   "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
   "limit": <maximum number of events relays SHOULD return in the initial query>
diff --git a/30.md b/30.md
index 5a6f84d..c2f8bb0 100644
--- a/30.md
+++ b/30.md
@@ -6,7 +6,7 @@ Custom Emoji
 
 `draft` `optional`
 
-Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form:
+Custom emoji may be added to **kind 0**, **kind 1**, **kind 7** ([NIP-25](25.md)) and **kind 30315** ([NIP-38](38.md)) events by including one or more `"emoji"` tags, in the form:
 
 ```
 ["emoji", <shortcode>, <image-url>]
diff --git a/47.md b/47.md
index c6540d5..9033847 100644
--- a/47.md
+++ b/47.md
@@ -17,7 +17,7 @@ This NIP describes a way for clients to access a remote Lightning wallet through
 * **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
 
 ## Theory of Operation
- 1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 1. **Users** who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
  
  2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
  
@@ -36,6 +36,7 @@ The info event should be a replaceable event that is published by the **wallet s
 a plaintext string with the supported commands, space-separated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
 
 Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
+Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
 
 The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
 
@@ -108,7 +109,8 @@ Request:
 {
     "method": "pay_invoice",
     "params": {
-        "invoice": "lnbc50n1..." // bolt11 invoice
+        "invoice": "lnbc50n1...", // bolt11 invoice
+        "amount": 123, // invoice amount in msats, optional
     }
 }
 ```
@@ -117,7 +119,7 @@ Response:
 ```jsonc
 {
     "result_type": "pay_invoice",
-    "result": { 
+    "result": {
         "preimage": "0123456789abcdef..." // preimage of the payment
     }
 }
@@ -126,6 +128,278 @@ Response:
 Errors:
 - `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
 
+### `multi_pay_invoice`
+
+Description: Requests payment of multiple invoices.
+
+Request:
+```jsonc
+{
+    "method": "multi_pay_invoice",
+    "params": {
+        "invoices": [
+          {"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
+          {"id":"3da52c32a1", "invoice": "lnbc50n1..."},
+        ],
+    }
+}
+```
+
+Response:
+
+For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
+response event contains an `d` tag with the id of the invoice it is responding to, if no id was given, then the
+payment hash of the invoice should be used.
+
+```jsonc
+{
+    "result_type": "multi_pay_invoice",
+    "result": {
+        "preimage": "0123456789abcdef..." // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `pay_keysend`
+
+Request:
+```jsonc
+{
+    "method": "pay_keysend",
+    "params": {
+        "amount": 123, // invoice amount in msats, required
+        "pubkey": "03...", // payee pubkey, required
+        "preimage": "0123456789abcdef...", // preimage of the payment, optional
+        "tlv_records: [ // tlv records, optional
+            {
+                "type": 5482373484, // tlv type
+                "value": "0123456789abcdef" // hex encoded tlv value
+            }
+        ]
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "pay_keysend",
+    "result": {
+        "preimage": "0123456789abcdef...", // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `multi_pay_keysend`
+
+Description: Requests multiple keysend payments.
+
+Has an array of keysends, these follow the same semantics as `pay_keysend`, just done in a batch
+
+Request:
+```jsonc
+{
+    "method": "multi_pay_keysend",
+    "params": {
+        "keysends": [
+          {"id": "4c5b24a351", pubkey": "03...", "amount": 123},
+          {"id": "3da52c32a1", "pubkey": "02...", "amount": 567, "preimage": "abc123..", "tlv_records": [{"type": 696969, "value": "77616c5f6872444873305242454d353736"}]},
+        ],
+    }
+}
+```
+
+Response:
+
+For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
+response event contains an `d` tag with the id of the keysend it is responding to, if no id was given, then the
+pubkey should be used.
+
+```jsonc
+{
+    "result_type": "multi_pay_keysend",
+    "result": {
+        "preimage": "0123456789abcdef..." // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+### `make_invoice`
+
+Request:
+```jsonc
+{
+    "method": "make_invoice",
+    "params": {
+        "amount": 123, // value in msats
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "expiry": 213 // expiry in seconds from time invoice is created, optional
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "make_invoice",
+    "result": {
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "invoice": "string", // encoded invoice, optional
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage, optional if unpaid
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+### `lookup_invoice`
+
+Request:
+```jsonc
+{
+    "method": "lookup_invoice",
+    "params": {
+        "payment_hash": "31afdf1..", // payment hash of the invoice, one of payment_hash or invoice is required
+        "invoice": "lnbc50n1..." // invoice to lookup
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "lookup_invoice",
+    "result": {
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+        "invoice": "string", // encoded invoice, optional
+        "description": "string", // invoice's description, optional
+        "description_hash": "string", // invoice's description hash, optional
+        "preimage": "string", // payment's preimage, optional if unpaid
+        "payment_hash": "string", // Payment hash for the payment
+        "amount": 123, // value in msats
+        "fees_paid": 123, // value in msats
+        "created_at": unixtimestamp, // invoice/payment creation time
+        "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+        "settled_at": unixtimestamp, // invoice/payment settlement time, optional if unpaid
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+    }
+}
+```
+
+Errors:
+- `NOT_FOUND`: The invoice could not be found by the given parameters.
+
+### `list_transactions`
+
+Lists invoices and payments. If `type` is not specified, both invoices and payments are returned.
+The `from` and `until` parameters are timestamps in seconds since epoch. If `from` is not specified, it defaults to 0.
+If `until` is not specified, it defaults to the current time. Transactions are returned in descending order of creation
+time.
+
+Request:
+```jsonc
+{
+    "method": "list_transactions",
+    "params": {
+        "from": 1693876973, // starting timestamp in seconds since epoch (inclusive), optional
+        "until": 1703225078, // ending timestamp in seconds since epoch (inclusive), optional
+        "limit": 10, // maximum number of invoices to return, optional
+        "offset": 0, // offset of the first invoice to return, optional
+        "unpaid": true, // include unpaid invoices, optional, default false
+        "type": "incoming", // "incoming" for invoices, "outgoing" for payments, undefined for both
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "list_transactions",
+    "result": {
+        "transactions": [
+            {
+               "type": "incoming", // "incoming" for invoices, "outgoing" for payments
+               "invoice": "string", // encoded invoice, optional
+               "description": "string", // invoice's description, optional
+               "description_hash": "string", // invoice's description hash, optional
+               "preimage": "string", // payment's preimage, optional if unpaid
+               "payment_hash": "string", // Payment hash for the payment
+               "amount": 123, // value in msats
+               "fees_paid": 123, // value in msats
+               "created_at": unixtimestamp, // invoice/payment creation time
+               "expires_at": unixtimestamp, // invoice expiration time, optional if not applicable
+               "settled_at": unixtimestamp, // invoice/payment settlement time, optional if unpaid
+               "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc.
+           }
+        ],
+    },
+}
+```
+
+### `get_balance`
+
+Request:
+```jsonc
+{
+    "method": "get_balance",
+    "params": {
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "get_balance",
+    "result": {
+        "balance": 10000, // user's balance in msats
+    }
+}
+```
+
+### `get_info`
+
+Request:
+```jsonc
+{
+    "method": "get_info",
+    "params": {
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "get_info",
+    "result": {
+            "alias": "string",
+            "color": "hex string",
+            "pubkey": "hex string",
+            "network": "string", // mainnet, testnet, signet, or regtest
+            "block_height": 1,
+            "block_hash": "hex string",
+            "methods": ["pay_invoice", "get_balance", "make_invoice", "lookup_invoice", "list_transactions", "get_info"], // list of supported methods for this connection
+    }
+}
+```
+
 ## Example pay invoice flow
 
 0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually.
diff --git a/49.md b/49.md
new file mode 100644
index 0000000..becc586
--- /dev/null
+++ b/49.md
@@ -0,0 +1,112 @@
+
+NIP-49
+======
+
+Private Key Encryption
+----------------------
+
+`draft` `optional`
+
+This NIP defines a method by which clients can encrypt (and decrypt) a user's private key with a passphrase.
+
+Symmetric Encryption Key derivation
+-----------------------------------
+
+PASSPHRASE = read from the user
+
+LOG\_N = Let the user or implementer choose one byte representing a power of 2 (e.g. 18 represents 262,144) which is used as the number of rounds for scrypt. Larger numbers take more time and more memory, and offer better protection:
+
+    | LOG\_N | MEMORY REQUIRED | APPROX TIME ON FAST COMPUTER |
+    |--------|-----------------|----------------------------- |
+    | 16     | 64 MiB          | 100 ms                       |
+    | 18     | 256 MiB         |                              |
+    | 20     | 1 GiB           | 2 seconds                    |
+    | 21     | 2 GiB           |                              |
+    | 22     | 4 GiB           |                              |
+
+SALT = 16 random bytes
+
+SYMMETRIC_KEY = scrypt(passphrase=PASSPHRASE, salt=SALT, log\_n=LOG\_N, r=8, p=1)
+
+The symmetric key should be 32 bytes long.
+
+This symmetric encryption key is temporary and should be zeroed and discarded after use and not stored or reused for any other purpose.
+
+
+Encrypting a private key
+------------------------
+
+The private key encryption process is as follows:
+
+PRIVATE\_KEY = User's private (secret) secp256k1 key as 32 raw bytes (not hex or bech32 encoded!)
+
+KEY\_SECURITY\_BYTE = one of:
+
+*  0x00 - if the key has been known to have been handled insecurely (stored unencrypted, cut and paste unencrypted, etc)
+*  0x01 - if the key has NOT been known to have been handled insecurely (stored unencrypted, cut and paste unencrypted, etc)
+ * 0x02 - if the client does not track this data
+
+ASSOCIATED\_DATA = KEY\_SECURITY\_BYTE
+
+NONCE = 24 byte random nonce
+
+CIPHERTEXT = XChaCha20-Poly1305(
+    plaintext=PRIVATE\_KEY,
+    associated_data=ASSOCIATED\_DATA,
+    nonce=NONCE,
+    key=SYMMETRIC\_KEY
+)
+
+VERSION\_NUMBER = 0x02
+
+CIPHERTEXT_CONCATENATION = concat(
+    VERSION\_NUMBER,
+    LOG\_N,
+    SALT,
+    NONCE,
+    ASSOCIATED\_DATA,
+    CIPHERTEXT
+)
+
+ENCRYPTED\_PRIVATE\_KEY = bech32_encode('ncryptsec', CIPHERTEXT\_CONCATENATION)
+
+The output prior to bech32 encoding should be 91 bytes long.
+
+The decryption process operates in the reverse.
+
+
+Test Data
+---------
+
+The following encrypted private key:
+
+`ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p`
+
+When decrypted with password='nostr' and log_n=16 yields the following hex-encoded private key:
+
+`3501454135014541350145413501453fefb02227e449e57cf4d3a3ce05378683`
+
+The reverse process is non-deterministic due to the random nonce.
+
+Discussion
+----------
+
+### On Key Derivation
+
+Passwords make poor cryptographic keys. Prior to use as a cryptographic key, two things need to happen:
+
+1. An encryption key needs to be deterministically created from the password such that is has a uniform functionally random distribution of bits, such that the symmetric encryption algorithm's assumptions are valid, and
+2. A slow irreversible algorithm should be injected into the process, so that brute-force attempts to decrypt by trying many passwords are severely hampered.
+
+These are achieved using a password-based key derivation function. We use scrypt, which has been proven to be maximally memory hard and which several cryptographers have indicated to the author is better than argon2 even though argon2 won a competition in 2015.
+
+### On the symmetric encryption algorithm
+
+XChaCha20-Poly1305 is typically favored by cryptographers over AES and is less associated with the U.S. government.  It (or it's earlier variant without the 'X') is gaining wide usage, is used in TLS and OpenSSH, and is available in most modern crypto libraries.
+
+Recommendations
+---------
+
+It is not recommended that users publish these encrypted private keys to nostr, as cracking a key may become easier when an attacker can amass many encrypted private keys.
+
+It is recommended that clients zero out the memory of passwords and private keys before freeing that memory.
diff --git a/52.md b/52.md
index 5ac116b..f35d904 100644
--- a/52.md
+++ b/52.md
@@ -38,7 +38,7 @@ The list of tags are as follows:
 The following tags are deprecated:
 * `name` name of the calendar event. Use only if `title` is not available.
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
@@ -99,7 +99,7 @@ The list of tags are as follows:
 The following tags are deprecated:
 * `name` name of the calendar event. Use only if `title` is not available.
 
-```json
+```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
diff --git a/72.md b/72.md
index c0fffff..4bafce0 100644
--- a/72.md
+++ b/72.md
@@ -12,7 +12,7 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 `kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals.
 
-```json
+```jsonc
 {
   "created_at": <Unix timestamp in seconds>,
   "kind": 34550,
@@ -42,14 +42,14 @@ The goal of this NIP is to create moderator-approved public communities around a
 
 Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval.
 
-```json
+```jsonc
 {
   "kind": 1,
   "tags": [
     ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
   ],
   "content": "hello world",
-  ...
+  // ...
 }
 ```
 
@@ -59,7 +59,7 @@ Community management clients MAY filter all mentions to a given `kind:34550` eve
 
 The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
 
-```json
+```jsonc
 {
   "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
   "kind": 4550,
@@ -70,7 +70,7 @@ The post-approval event MUST include `a` tags of the communities the moderator i
     ["k", "<post-request-kind>"]
   ],
   "content": "<the full approved event, JSON-encoded>",
-  ...
+  // ...
 }
 ```
 
diff --git a/96.md b/96.md
index d8ea105..3ebbef8 100644
--- a/96.md
+++ b/96.md
@@ -273,7 +273,7 @@ The `server` should reject deletes from users other than the original uploader.
 It should be noted that more than one user may have uploaded the same file (with the same hash). In this case, a delete must not really delete the file but just remove the user's `pubkey` from the file owners list (considering the server keeps just one copy of the same file, because multiple uploads of the same file results
 in the same file hash).
 
-The successfull response is a 200 OK one with just basic JSON fields:
+The successful response is a 200 OK one with just basic JSON fields:
 
 ```
 {
diff --git a/README.md b/README.md
index cf3827e..9ce96fc 100644
--- a/README.md
+++ b/README.md
@@ -57,6 +57,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-46: Nostr Connect](46.md)
 - [NIP-47: Wallet Connect](47.md)
 - [NIP-48: Proxy Tags](48.md)
+- [NIP-49: Private Key Encryption](49.md)
 - [NIP-50: Search Capability](50.md)
 - [NIP-51: Lists](51.md)
 - [NIP-52: Calendar Events](52.md)
@@ -94,6 +95,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `42`          | Channel Message            | [28](28.md)              |
 | `43`          | Channel Hide Message       | [28](28.md)              |
 | `44`          | Channel Mute User          | [28](28.md)              |
+| `1021`        | Bid                        | [15](15.md)              |
+| `1022`        | Bid confirmation           | [15](15.md)              |
 | `1040`        | OpenTimestamps             | [03](03.md)              |
 | `1063`        | File Metadata              | [94](94.md)              |
 | `1311`        | Live Chat Message          | [53](53.md)              |
@@ -136,6 +139,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30015`       | Interest sets              | [51](51.md)              |
 | `30017`       | Create or update a stall   | [15](15.md)              |
 | `30018`       | Create or update a product | [15](15.md)              |
+| `30019`       | Marketplace UI/UX          | [15](15.md)              |
+| `30020`       | Product sold as an auction | [15](15.md)              |
 | `30023`       | Long-form Content          | [23](23.md)              |
 | `30024`       | Draft Long-form Content    | [23](23.md)              |
 | `30030`       | Emoji sets                 | [51](51.md)              |