Offers

.aspell.en.pws

@@ -410,6 +410,14 @@ quiesce
 quiescing
 SomeThing
 onionmsg
+unrequested
+Merkle
+whitespace
+TLVs
+LnLeaf
+LnNonce
+LnBranch
+payinfo
 griefing
 unspendable
 pkh

01-messaging.md

@@ -251,9 +251,17 @@ The following convenience types are also defined:
 * `channel_id`: a 32-byte channel_id (see [BOLT #2](02-peer-protocol.md#definition-of-channel-id))
 * `sha256`: a 32-byte SHA2-256 hash
 * `signature`: a 64-byte bitcoin Elliptic Curve signature
+* `bip340sig`: a 64-byte bitcoin Elliptic Curve Schnorr signature as per [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
 * `point`: a 33-byte Elliptic Curve point (compressed encoding as per [SEC 1 standard](http://www.secg.org/sec1-v2.pdf#subsubsection.2.3.3))
 * `short_channel_id`: an 8 byte value identifying a channel (see [BOLT #7](07-routing-gossip.md#definition-of-short-channel-id))
+* `sciddir_or_pubkey`: either 9 or 33 bytes referencing or identifying a node, respectively
+    * if the first byte is 0 or 1, then an 8-byte `short_channel_id` follows for a total of 9 bytes
+        * 0 for the first byte indicates this refers to `node_id_1` in the `channel_announcement` for `short_channel_id`
+        * 1 for the first byte indicates this refers to `node_id_2` in the `channel_announcement` for `short_channel_id`
+          (see [BOLT #7](07-routing-gossip.md#the-channel_announcement-message)
+    * if the first byte is 2 or 3, then the value is a 33-byte `point`
 * `bigsize`: a variable-length, unsigned integer similar to Bitcoin's CompactSize encoding, but big-endian.  Described in [BigSize](#appendix-a-bigsize-test-vectors).
+* `utf8`: a byte as part of a UTF-8 string.  A writer MUST ensure an array of these is a valid UTF-8 string, a reader MAY reject any messages containing an array of these which is not a valid UTF-8 string.
 
 ## Setup Messages
 

04-onion-routing.md

@@ -245,8 +245,8 @@ leaking its position in the route.
 The creator of `encrypted_recipient_data` (usually, the recipient of payment):
 
   - MUST create `encrypted_data_tlv` for each node in the blinded route (including itself).
-  - MUST include `encrypted_data_tlv.short_channel_id` and `encrypted_data_tlv.payment_relay` for each non-final node.
-  - MUST NOT include `encrypted_data_tlv.next_node_id`.
+  - MUST include `encrypted_data_tlv.payment_relay` for each non-final node.
+  - MUST include exactly one of `encrypted_data_tlv.short_channel_id` or `encrypted_data_tlv.next_node_id` for each non-final node.
   - MUST set `encrypted_data_tlv.payment_constraints` for each non-final node and MAY set it for the final node:
     - `max_cltv_expiry` to the largest block height at which the route is allowed to be used, starting
        from the final node's chosen `max_cltv_expiry` height at which the route should expire, adding 
@@ -440,7 +440,7 @@ intermediary nodes could simply claim the remaining ones.
 
 1. subtype: `blinded_path`
 2. data:
-   * [`point`:`first_node_id`]
+   * [`sciddir_or_pubkey`:`first_node_id`]
    * [`point`:`first_path_key`]
    * [`byte`:`num_hops`]
    * [`num_hops*blinded_path_hop`:`path`]
@@ -1510,14 +1510,23 @@ even, of course!).
     1. type: 4 (`encrypted_recipient_data`)
     2. data:
         * [`...*byte`:`encrypted_recipient_data`]
+    1. type: 64 (`invoice_request`)
+    2. data:
+        * [`tlv_invoice_request`:`invreq`]
+    1. type: 66 (`invoice`)
+    2. data:
+        * [`tlv_invoice`:`inv`]
+    1. type: 68 (`invoice_error`)
+    2. data:
+        * [`tlv_invoice_error`:`inverr`]
 
 #### Requirements
 
 The creator of `encrypted_recipient_data` (usually, the recipient of the onion):
 
   - MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding).
-  - MUST NOT include `short_channel_id`, `payment_relay` or `payment_constraints` in any `encrypted_data_tlv`
-  - MUST include `encrypted_data_tlv.next_node_id` for each non-final node.
+  - MUST NOT include `payment_relay` or `payment_constraints` in any `encrypted_data_tlv`
+  - MUST include either `next_node_id` or `short_channel_id` in the `encrypted_data_tlv` for each non-final node.
   - MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding).
 
 The writer:
@@ -1558,7 +1567,13 @@ The reader:
   - if the `encrypted_data_tlv` contains `path_id`:
     - MUST ignore the message.
   - otherwise:
-    - SHOULD forward the message using `onion_message` to the next peer indicated by `next_node_id`.
+    - if `next_node_id` is present:
+      - the *next peer* is the peer with that node id.
+    - otherwise, if `short_channel_id` is present and corresponds to an announced short_channel_id or a local alias for a channel:
+      - the *next peer* is the peer at the other end of that channel.
+    - otherwise:
+      - MUST ignore the message.
+    - SHOULD forward the message using `onion_message` to the *next peer*.
     - if it forwards the message:
       - MUST set `path_key` in the forwarded `onion_message` to the next `path_key` as calculated in [Route Blinding](#route-blinding).
 - otherwise (it is the final node):