onion: make enctlvs compulsory, hence blinding compulsory.

Review by Matt Corallo picked this up, and he's right: it's simpler
and makes the sent onion message and reply less distinguishable.

The onion_message message number is increased, so we can try to
handle old and new at the same time (wish me luck!).

Also add padding option while we're here, and remove scids for simplicity.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

04-onion-routing.md

@@ -374,33 +374,31 @@ Onion messages have an onion with an alternate `hop_payload`
 format: a `bigsize` followed by a `onionmsg_payload`.  Note that there
 is no legacy format, thus a `bigsize` of 0 means no payload.
 
+An intermediate node expects an `enctlv` which it can decrypt using
+the `blinding` which it is handed along with the onion message.
+
 1. tlvs: `onionmsg_payload`
 2. types:
-    1. type: 4 (`next_node_id`)
-    2. data:
-        * [`point`:`node_id`]
-    1. type: 6 (`next_short_channel_id`)
-    2. data:
-        * [`short_channel_id`:`short_channel_id`]
     1. type: 8 (`reply_path`)
     2. data:
+        * [`point`:`first_node_id`]
         * [`point`:`blinding`]
         * [`...*onionmsg_path`:`path`]
     1. type: 10 (`enctlv`)
     2. data:
         * [`...*byte`:`enctlv`]
-    1. type: 12 (`blinding`)
-    2. data:
-        * [`point`:`blinding`]
 
 1. tlvs: `encmsg_tlvs`
 2. types:
+    1. type: 1 (`padding`)
+    2. data:
+        * [`...*byte`:`pad`]
     1. type: 4 (`next_node_id`)
     2. data:
         * [`point`:`node_id`]
-    1. type: 6 (`next_short_channel_id`)
+    1. type: 12 (`next_blinding`)
     2. data:
-        * [`short_channel_id`:`short_channel_id`]
+        * [`point`:`blinding`]
 
 1. subtype: `onionmsg_path`
 2. data:
@@ -412,41 +410,59 @@ is no legacy format, thus a `bigsize` of 0 means no payload.
 
 The writer:
 - For the non-final nodes' `onionmsg_payload`:
-  - MUST include exactly one of `next_short_channel_id`, `next_node_id`
-    or `enctlv` indicating the next node.
+  - MUST set `enctlv` to a valid `encmsg_tlvs` containing `next_node_id`.
+  - MUST encrypt `enctlv` as detailed in [Route Blinding][route-blinding].
+    `ChaChaPoly-1305` encryption using an all-zero nonce).
+  - MAY include `padding`.
 - For the final node's `onionmsg_payload`:
   - if the final node is permitted to reply:
     - MUST set `reply_path` `blinding` to the initial blinding factor for the `next_node_id`
-    - For the first `reply_path` `path`:
-      - MUST set `node_id` to the first node in the reply path.
-    - For the remaining `reply_path` `path`:
+    - MUST set `reply_path` `first_node_id` to the unblinded node id of the first node in the reply path.
+    - For every `reply_path` `path`:
       - MUST set `node_id` to the blinded node id to encrypt the onion hop for.
-    - Within `reply_path` `path`:
-      - MUST encrypt `enctlv` as detailed in (FIXME: reference to t-bast's blinded path section:
+      - MUST encrypt `enctlv` as detailed in [Route Blinding][route-blinding].
         `ChaChaPoly-1305` encryption using an all-zero nonce).
-      - MUST set `enctlv` to a valid `encmsg_tlvs` containing exactly one of either
-        `next_node_id` or `next_short_channel_id`.
+      - MUST set `enctlv` to a valid `encmsg_tlvs` containing at least
+        `next_node_id`.
   - otherwise:
     - MUST NOT set `reply_path`.
 
 The reader:
-- if `enctlv` is present:
-  - MUST extract the shared secret from the given `blinding` parameter and decrypt `enctlv`.
-  - MUST drop the message if `enctlv` is not a valid TLV.
-  - MUST use `next_short_channel_id` or `next_node_id` from `enctlv`.
-- Otherwise:
-  - MUST use `next_short_channel_id` or `next_node_id` from  `onionmsg_payload`.
-
 - if it is not the final node according to the onion encryption:
-  - if `next_short_channel_id` or `next_node_id` is found:
-    - SHOULD forward the message using `onion_message` to the indicated peer if possible.
+  - if `enctlv` is not present, or does not decrypt with the shared secret from the given `blinding` parameter:
+    - MUST drop the message.
+  - if the `enctlv` is not a valid TLV or does not contain `next_node_id`.
+    - MUST drop the message.
+  - otherwise:
+    - MUST ignore `padding`, if any.
+    - SHOULD forward the message using `onion_message` to the next peer indicated by `next_node_id`.
+    - If it forwards the message:
+      - if `blinding` is specified in the `enctlv`:
+         - MUST pass that as `blinding` in the `onion_message`
+      - otherwise:
+         - MUST pass `blinding` derived as in [Route Blinding][route-blinding] (i.e. `E(i+1) = H(E(i) || ss(i)) * E(i)`).
 
 - otherwise:
   - if it wants to send a reply:
     - MUST create an onion encoding using `reply_path`.
     - MUST send the reply via `onion_message` to the node indicated by
-        the first element of `reply_path` `path` using `reply_path` `blinding`.
+        the `first_node_id`, using `reply_path` `blinding` to send
+        along `reply_path` `path`.
+
+#### Rationale
+
+The chained-blinding-to-decrypt-enctlv scheme allows Alice to create a
+series of enctlv blobs for Bob, and ensure that a message received
+with the final blinding value for those envtlvs was in fact sent via
+that path.
+
+It is also difficult for Bob to determine the contents of the enctlv
+values, as there is no failure reply and any change will cause it to
+fail.
 
+Because `blinding` must be calculated forwards along the route, if you
+are given a path with a blinding, you need to set that manually inside
+the `enctlv` to prepend your own path.
 
 # Accepting and Forwarding a Payment
 
@@ -1282,6 +1298,7 @@ The following is an in-depth trace of an example of error message creation:
 [fips198]: http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
 [sec2]: http://www.secg.org/sec2-v2.pdf
 [rfc8439]: https://tools.ietf.org/html/rfc8439
+[routeblinding]: https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
 
 # Authors
 

07-routing-gossip.md

@@ -1138,17 +1138,11 @@ parameter which allows decryption of the `enctlv` field inside the
 
 ## The `onion_message` Message
 
-1. type: 385 (`onion_message`) (`option_onion_messages`)
+1. type: 387 (`onion_message`) (`option_onion_messages`)
 2. data:
+    * [`point`:`blinding`]
     * [`u16`:`len`]
     * [`len*byte`:`onionmsg`]
-    * [`onion_message_tlvs`:`onion_message_tlvs`]
-
-1. tlvs: `onion_message_tlvs`
-2. types:
-    1. type: 2 (`blinding`)
-    2. data:
-        * [`point`:`blinding`]
 
 ## Requirements
 
@@ -1165,6 +1159,13 @@ The reader:
 
 ## Rationale
 
+All onion messages are blinded, even though this overhead is not
+always necessary (33 bytes here, the 16-byte MAC for each enctlv in
+the onion).  This blinding allows nodes to use a path provided by
+others without knowing its contents.  Using it universally simplifies
+implementations a little, and makes it more difficult to distinguish
+onion messages.
+
 `len` allows larger messages to be sent than the standard 1300 bytes
 allowed for an HTLC onion, but this should be used sparingly as it is
 reduces anonymity set, hence the recommendation that it either look