BOLT 4: rename to avoid the term "blinding" unless we're actually doi…

…ng blinding

We are handed an ephemeral key (E_i) to derive a shared secret, which derives
both the blinding tweak for the onion, *and* the key to decrypt the encrypted_recipient_data.

But we call it "blinding", which is confusing!  How about we call it "path_key"?

1. update_add_htlc_tlv's "blinding_point.blinding" -> "blinded_path.path_key"
2. payload's "current_blinding_point" -> "current_path_key"
3. blinded_path's "blinding" -> "first_path_key".
4. encrypted_data_tlv's "next_blinding_override.blinding" -> "next_path_key_override.path_key"

This sweep found other changes:
1. Writer of the TLV `payload`: simply refer here to Route Blinding requirements which
   says how to uset the `blinded_path` if we have one (and gets it right on the two
   ways to use current_blinding_point).
2. Refer concretely to `blinded_path` (a type) rather than "blinded route" (a concept).
3. Use the term `encrypted_recipient_data` everywhere for consistency, and `encrypted_data_tlv` once it's decrypted.
4. Note explictly that you can't use the "next_path_key_override" if the prior node doesn't support route blinding.
5. Header "Blinding Ephemeral Keys" -> "Blinding Ephemeral Onion Keys" to avoid confusion with blinded paths!
6. When using `reply_path` for onion messages, simply refer to the Route Blinding requirements.

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

02-peer-protocol.md

@@ -1975,9 +1975,9 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
 
 1. `tlv_stream`: `update_add_htlc_tlvs`
 2. types:
-    1. type: 0 (`blinding_point`)
+    1. type: 0 (`blinded_path`)
     2. data:
-        * [`point`:`blinding`]
+        * [`point`:`path_key`]
 
 #### Requirements
 
@@ -2015,7 +2015,7 @@ A sending node:
     - MUST set `id` to 0.
   - MUST increase the value of `id` by 1 for each successive offer.
   - if it is relaying a payment inside a blinded route:
-    - MUST set `blinding_point` (see [Route Blinding](04-onion-routing.md#route-blinding))
+    - MUST set `path_key` (see [Route Blinding](04-onion-routing.md#route-blinding))
 
 `id` MUST NOT be reset to 0 after the update is complete (i.e. after `revoke_and_ack` has
 been received). It MUST continue incrementing instead.
@@ -2040,7 +2040,7 @@ A receiving node:
   - if other `id` violations occur:
     - MAY send a `warning` and close the connection, or send an
       `error` and fail the channel.
-  - MUST decrypt `onion_routing_packet` as specified in [Onion Decryption](04-onion-routing.md#onion-decryption) using `payment_hash` as `associated_data` (and `blinding` if specified).
+  - MUST decrypt `onion_routing_packet` as specified in [Onion Decryption](04-onion-routing.md#onion-decryption) using `payment_hash` as `associated_data` (and `path_key` if specified).
   - If that fails, or the payload is not a valid `payload` TLV:
     - MUST report the failure to the origin node as described in [Returning Errors](04-onion-routing.md#returning-errors)
   - MUST follow the requirements for processing the payload under [Failure Messages](04-onion-routing.md#failure-messages)
@@ -2127,14 +2127,14 @@ A node:
     - MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or
 `update_fail_malformed_htlc`.
   - When failing an incoming HTLC:
-    - If `current_blinding_point` is set in the onion payload and it is not the
+    - If `current_path_key` is set in the onion payload and it is not the
       final node:
       - MUST send an `update_fail_htlc` error using the `invalid_onion_blinding`
         failure code for any local or downstream errors.
       - SHOULD use the `sha256_of_onion` of the onion it received.
       - MAY use an all zero `sha256_of_onion`.
       - SHOULD add a random delay before sending `update_fail_htlc`.
-    - If `blinding_point` is set in the incoming `update_add_htlc`:
+    - If `path_key` is set in the incoming `update_add_htlc`:
       - MUST send an `update_fail_malformed_htlc` error using the
         `invalid_onion_blinding` failure code for any local or downstream errors.
       - SHOULD use the `sha256_of_onion` of the onion it received.