Define a mechanism for looking up an offer from a user/domain pair

.aspell.en.pws

@@ -388,6 +388,14 @@ IFDUP
 sats
 anysegwit
 onionmsg
+unrequested
+Merkle
+whitespace
+TLVs
+LnLeaf
+LnNonce
+LnBranch
+payinfo
 griefing
 unspendable
 pkh

01-messaging.md

@@ -243,9 +243,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

@@ -243,7 +243,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 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:
     - `max_cltv_expiry` to the largest block height at which the route is allowed to be used, starting
     from the final node and adding `encrypted_data_tlv.payment_relay.cltv_expiry_delta` at each hop.
@@ -1472,10 +1473,32 @@ 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`]
+    1. type: 70 (`offer_request`)
+    2. data:
+        * [`u8`:`name_len`]
+        * [`name_len*byte`:`name`]
+        * [`u8`:`domain_len`]
+        * [`name_len*byte`:`domain`]
+    1. type: 72 (`offer_response`)
+    2. data:
+        * [`u8`:`name_len`]
+        * [`name_len*byte`:`name`]
+        * [`u8`:`domain_len`]
+        * [`name_len*byte`:`domain`]
+        * [`tlv_offer`:`offer`]
 
 1. subtype: `blinded_path`
 2. data:
-   * [`point`:`first_node_id`]
+   * [`sciddir_or_pubkey`:`first_node_id`]
    * [`point`:`blinding`]
    * [`byte`:`num_hops`]
    * [`num_hops*onionmsg_hop`:`path`]
@@ -1532,7 +1555,8 @@ 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`.
+    - SHOULD forward the message using `onion_message` to the next peer indicated by either `next_node_id`
+      or the channel counterparty with `short_channel_id`.
     - if it forwards the message:
       - MUST set `blinding` in the forwarded `onion_message` to the next blinding as calculated in [Route Blinding](#route-blinding).
 - otherwise (it is the final node):