From 79f3d0f3e3187f26f61902cfc2c5469e3edd75dd Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Wed, 10 Jul 2024 10:22:32 +0930 Subject: [PATCH 1/5] BOLT 4: remove obsolete references to `realm` This was from the legacy onion, and is no longer present. Signed-off-by: Rusty Russell --- 04-onion-routing.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index d6c68563d..e56c3b816 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -1097,10 +1097,6 @@ lightning implementations serialized this without the `0x0102` message type. The following `failure_code`s are defined: -1. type: PERM|1 (`invalid_realm`) - -The `realm` byte was not understood by the processing node. - 1. type: NODE|2 (`temporary_node_failure`) General temporary failure of the processing node. @@ -1287,8 +1283,6 @@ An _erring node_: - SHOULD select the first error it encounters from the list above. An _erring node_ MAY: - - if the `realm` byte is unknown: - - return an `invalid_realm` error. - if the per-hop payload in the onion is invalid (e.g. it is not a valid tlv stream) or is missing required information (e.g. the amount was not specified): - return an `invalid_onion_payload` error. From 1761ad524e28b2d43580750e1af5bb912cf205b2 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 11 Jul 2024 10:25:13 +0930 Subject: [PATCH 2/5] BOLT 4: Generalize and create proper requirements for onion decryption There's currently a *description* of how to decrypt an onion, and some requirements in forwarding. But it also applies to onion messages, so: 1. Turn the description into actual enumerated requirements. 2. Ensure the description covers both payload and messaging onions. 3. Include both methods to apply the blinding tweak. 4. Leave the actual handling of the extracted payload (payment vs messaging onion) to those specific sections (e.g. reporting failure) Signed-off-by: Rusty Russell --- 04-onion-routing.md | 122 +++++++++++++++++++++----------------------- 1 file changed, 58 insertions(+), 64 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index e56c3b816..1f77f1a5e 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -57,7 +57,7 @@ A node: * [Shared Secret](#shared-secret) * [Blinding Ephemeral Keys](#blinding-ephemeral-keys) * [Packet Construction](#packet-construction) - * [Packet Forwarding](#packet-forwarding) + * [Onion Decryption](#onion-decryption) * [Filler Generation](#filler-generation) * [Returning Errors](#returning-errors) * [Failure Messages](#failure-messages) @@ -855,76 +855,70 @@ func NewOnionPacket(paymentPath []*btcec.PublicKey, sessionKey *btcec.PrivateKey } ``` -# Packet Forwarding +# Onion Decryption -This specification is limited to `version` `0` packets; the structure -of future versions may change. +There are two kinds of `onion_packet` we use: +1. `onion_routing_packet` in `update_add_htlc` for payments, which contains a `payload` TLV (see [Adding an HTLC](02-peer-protocol.md#adding-an-htlc-update_add_htlc)) +2. `onion_message_packet` on `onion_message` for messages, which contains a `onionmsg_tlv` TLV (see [Onion Messages](#onion-messages) -Upon receiving a packet, a processing node compares the version byte of the -packet with its own supported versions and aborts the connection if the packet -specifies a version number that it doesn't support. -For packets with supported version numbers, the processing node first parses the -packet into its individual fields. - -Next, the processing node computes the shared secret using the private key -corresponding to its own public key and the ephemeral key from the packet, as -described in [Shared Secret](#shared-secret). - -The above requirements prevent any hop along the route from retrying a payment -multiple times, in an attempt to track a payment's progress via traffic -analysis. Note that disabling such probing could be accomplished using a log of -previous shared secrets or HMACs, which could be forgotten once the HTLC would -not be accepted anyway (i.e. after `outgoing_cltv_value` has passed). Such a log -may use a probabilistic data structure, but it MUST rate-limit commitments as -necessary, in order to constrain the worst-case storage requirements or false -positives of this log. - -Next, the processing node uses the shared secret to compute a _mu_-key, which it -in turn uses to compute the HMAC of the `hop_payloads`. The resulting HMAC is then -compared against the packet's HMAC. - -Comparison of the computed HMAC and the packet's HMAC MUST be -time-constant to avoid information leaks. - -At this point, the processing node can generate a _rho_-key. - -The routing information is then deobfuscated, and the information about the -next hop is extracted. -To do so, the processing node copies the `hop_payloads` field, appends 1300 `0x00`-bytes, -generates `2*1300` pseudo-random bytes (using the _rho_-key), and applies the result, using `XOR`, to the copy of the `hop_payloads`. -The first few bytes correspond to the bigsize-encoded length `l` of the `hop_payload`, followed by `l` bytes of the resulting routing information become the `hop_payload`, and the 32 byte HMAC. -The next 1300 bytes are the `hop_payloads` for the outgoing packet. - -A special `hmac` value of 32 `0x00`-bytes indicates that the currently processing hop is the intended recipient and that the packet should not be forwarded. - -If the HMAC does not indicate route termination, and if the next hop is a peer of the -processing node; then the new packet is assembled. Packet assembly is accomplished -by blinding the ephemeral key with the processing node's public key, along with the -shared secret, and by serializing the `hop_payloads`. -The resulting packet is then forwarded to the addressed peer. +Those sections specify the `associated_data` to use, the `blinding` (if any), the extracted payload format and handling (including how to determine the next peer, if any), and how to handle errors. The processing itself is identical. ## Requirements -The processing node: - - if the ephemeral public key is NOT on the `secp256k1` curve: - - MUST abort processing the packet. - - MUST report a route failure to the origin node. - - if the packet has previously been forwarded or locally redeemed, i.e. the - packet contains duplicate routing information to a previously received packet: - - if preimage is known: +A reader: + - if `version` is not 0: + - MUST abort processing the packet and fail. + - if `public_key` is not a valid pubkey: + - MUST abort processing the packet and fail. + - if the onion is for a payment: + - if `hmac` has previously been received: + - if the preimage is known: - MAY immediately redeem the HTLC using the preimage. - otherwise: - - MUST abort processing and report a route failure. - - if the computed HMAC and the packet's HMAC differ: - - MUST abort processing. - - MUST report a route failure. - - if the `realm` is unknown: - - MUST drop the packet. - - MUST signal a route failure. - - MUST address the packet to another peer that is its direct neighbor. - - if the processing node does not have a peer with the matching address: - - MUST drop the packet. - - MUST signal a route failure. + - MUST abort processing the packet and fail. + - if `blinding` is specified: + - Calculate the `blinding_ss` as ECDH(`blinding`, `node-privkey`) + - Either: + - Tweak `public_key` by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$ + - or (equivalently): + - Tweak its own `node-privkey` below by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$ + - Derive the shared secret `ss` as ECDH(`public_key`, `node-privkey`) (see [Shared Secret](#shared-secret)) + - Derive `mu` as $`HMAC256(\text{"mu"}, ss)`$ (see [Key Generation](#key-generation)). + - Derive the HMAC as $`HMAC256(mu, hop_payloads || associated_data)`$ + - MUST use a constant time comparison of the computed HMAC and `hmac`. + - If the computed HMAC and `hmac` differ: + - MUST abort processing the packet and fail. + - Derive `rho` as $`HMAC256(\text{"rho"}, ss)`$ (see [Key Generation](#key-generation)). + - Derive `bytestream` of twice the length of `hop_payloads` using `rho` (see [Pseudo Random Byte Stream](pseudo-random-byte-stream)). + - Set `unwrapped_payloads` to the XOR of `hop_payloads` and `bytestream` + - Remove a `bigsize` from the front of `unwrapped_payloads` as `payload_length`. If that is malformed: + - MUST abort processing the packet and fail. + - If the `payload_length` is less than two: + - MUST abort processing the packet and fail. + - If there are fewer than `payload_length` bytes remaining in `unwrapped_payloads`: + - MUST abort processing the packet and fail. + - Remove `payload_length` bytes from the front of `unwrapped_payloads`, as the current `payload`. + - If there are fewer than 32 bytes remaining in `unwrapped_payloads`: + - MUST abort processing the packet and fail. + - Remove 32 bytes as `next_hmac` from the front of `unwrapped_payloads`. + - If `unwrapped_payloads` is smaller than `hop_payloads`: + - MUST abort processing the packet and fail. + - If `next_hmac` is not all-zero (not the final node): + - Derive `blinding_tweak` as $`SHA256(public_key || ss)`$ (see [Blinding Ephemeral Keys](#blinding-ephemeral-keys)) + - SHOULD forward an onion to the next peer with: + - `version` set to 0 + - `public_key` set to the incoming `public_key` multiplied by `blinding_tweak` + - `hop_payloads` set to the `unwrapped_payloads`, truncated to the incoming `hop_payloads` size + - `hmac` set to `next_hmac` + - If it cannot forward: + - MUST fail. + - Otherwise (all-zero `next_hmac`): + - This is the final destination of the onion. + + +## Rationale + +In the case where blinded paths are used, the sender did not actually encrypt this onion for our node_id, but for a tweaked version: we can derive the tweak used from `blinding` which is given alongside the onion. Then we either tweak our node private key the same way to decrypt the onion, or tweak to the onion ephemeral key which is mathematically equivalent. # Filler Generation From 47d9ccec7c80fc16ed70981461385761ae049622 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 11 Jul 2024 10:26:13 +0930 Subject: [PATCH 3/5] BOLT 2, BOLT 4: refer to the onion decryption section in update_add_htlc/onion message requirements. This ties it together, saying what to use as associated data, blinding, and what to do on failure. Signed-off-by: Rusty Russell --- 02-peer-protocol.md | 7 +++++-- 04-onion-routing.md | 5 +++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 488b0b8bb..225c65872 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2040,8 +2040,11 @@ A receiving node: - if other `id` violations occur: - MAY send a `warning` and close the connection, or send an `error` and fail the channel. - - if `blinding_point` is provided: - - MUST use the corresponding blinded private key to decrypt the `onion_routing_packet` (see [Route Blinding](04-onion-routing.md#route-blinding)) + - MUST decrypt `onion_routing_packet` with `associated_data` set to `payment_hash`, and using `blinding` (if present) as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract a `payload`. + - If decryption fails, the result is not a valid `payload` TLV, or it contains unknown even types: + - MUST respond with an error as detailed in [Failure Messages](04-onion-routing.md#failure-messages) + - Otherwise: + - MUST follow the requirements for the reader of `payload` in [Payload Format](04-onion-routing.md#payload-format) The `onion_routing_packet` contains an obfuscated list of hops and instructions for each hop along the path. It commits to the HTLC by setting the `payment_hash` as associated data, i.e. includes the `payment_hash` in the computation of HMACs. diff --git a/04-onion-routing.md b/04-onion-routing.md index 1f77f1a5e..079578f2e 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -1519,8 +1519,9 @@ The reader: - SHOULD accept onion messages from peers without an established channel. - MAY rate-limit messages by dropping them. -- MUST read the `encrypted_recipient_data` using `blinding` as required in [Route Blinding](#route-blinding). - - MUST ignore the message if that considers the message invalid. +- MUST decrypt `onion_message_packet` using an empty `associated_data`, and `blinding`, as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract an `onionmsg_tlv`. +- If decryption fails, the result is not a valid `onionmsg_tlv`, or it contains unknown even types: + - MUST ignore the message. - if `encrypted_data_tlv` contains `allowed_features`: - MUST ignore the message if: - `encrypted_data_tlv.allowed_features.features` contains an unknown feature bit (even if it is odd). From 5193cbb44229669485f9e7ae7c9a52396e5fa833 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 11 Jul 2024 12:06:34 +0930 Subject: [PATCH 4/5] BOLT 2, 4: rename `blinding` to `path_key`. Sure, it's used to derive a secret for blinding, but it's also used to derive the key for encrypted_recipient_data. It's not used as a blinding factor *directly*. Signed-off-by: Rusty Russell --- 02-peer-protocol.md | 14 ++++--- 04-onion-routing.md | 96 ++++++++++++++++++++++----------------------- 2 files changed, 56 insertions(+), 54 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 225c65872..2ae0d0747 100644 --- a/02-peer-protocol.md +++ b/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,9 @@ 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` with `associated_data` set to `payment_hash`, and using `blinding` (if present) as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract a `payload`. + - MUST decrypt `onion_routing_packet` as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract a `payload`. + - MUST use `path_key` (if specified). + - MUST use `payment_hash` as `associated_data`. - If decryption fails, the result is not a valid `payload` TLV, or it contains unknown even types: - MUST respond with an error as detailed in [Failure Messages](04-onion-routing.md#failure-messages) - Otherwise: @@ -2128,14 +2130,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_point` 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_point` 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. diff --git a/04-onion-routing.md b/04-onion-routing.md index 079578f2e..ba500db3b 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -55,7 +55,7 @@ A node: * [Payload for the Last Node](#payload-for-the-last-node) * [Non-strict Forwarding](#non-strict-forwarding) * [Shared Secret](#shared-secret) - * [Blinding Ephemeral Keys](#blinding-ephemeral-keys) + * [Blinding Ephemeral Onion Keys](#blinding-ephemeral-onion-keys) * [Packet Construction](#packet-construction) * [Onion Decryption](#onion-decryption) * [Filler Generation](#filler-generation) @@ -204,9 +204,9 @@ This is formatted according to the Type-Length-Value format defined in [BOLT #1] 1. type: 10 (`encrypted_recipient_data`) 2. data: * [`...*byte`:`encrypted_data`] - 1. type: 12 (`current_blinding_point`) + 1. type: 12 (`current_path_key`) 2. data: - * [`point`:`blinding`] + * [`point`:`path_key`] 1. type: 16 (`payment_metadata`) 2. data: * [`...*byte`:`payment_metadata`] @@ -262,7 +262,7 @@ The writer of the TLV `payload`: - For every node inside a blinded route: - MUST include the `encrypted_recipient_data` provided by the recipient - For the first node in the blinded route: - - MUST include the `blinding_point` provided by the recipient in `current_blinding_point` + - MUST include the `path_key` provided by the recipient in `current_path_key` - If it is the final node: - MUST include `amt_to_forward`, `outgoing_cltv_value` and `total_amount_msat`. - The value set for `outgoing_cltv_value`: @@ -288,15 +288,15 @@ The writer of the TLV `payload`: The reader: - If `encrypted_recipient_data` is present: - - If `blinding_point` is set in the incoming `update_add_htlc`: - - MUST return an error if `current_blinding_point` is present. - - MUST use that `blinding_point` as the blinding point for decryption. + - If `path_key` is set in the incoming `update_add_htlc`: + - MUST return an error if `current_path_key` is present. + - MUST use that `path_key` as `path_key` for decryption. - Otherwise: - - MUST return an error if `current_blinding_point` is not present. - - MUST use that `current_blinding_point` as the blinding point for decryption. + - MUST return an error if `current_path_key` is not present. + - MUST use that `current_path_key` as the `path_key` for decryption. - SHOULD add a random delay before returning errors. - MUST return an error if `encrypted_recipient_data` does not decrypt using the - blinding point as described in [Route Blinding](#route-blinding). + `path_key` as described in [Route Blinding](#route-blinding). - If `payment_constraints` is present: - MUST return an error if: - the expiry is greater than `encrypted_recipient_data.payment_constraints.max_cltv_expiry`. @@ -308,20 +308,20 @@ The reader: - `encrypted_recipient_data` contains both `short_channel_id` and `next_node_id`. - the payment uses a feature not included in `encrypted_recipient_data.allowed_features.features`. - If it is not the final node: - - MUST return an error if the payload contains other tlv fields than `encrypted_recipient_data` and `current_blinding_point`. + - MUST return an error if the payload contains other tlv fields than `encrypted_recipient_data` and `current_path_key`. - MUST return an error if `encrypted_recipient_data` does not contain either `short_channel_id` or `next_node_id`. - MUST return an error if `encrypted_recipient_data` does not contain `payment_relay`. - MUST use values from `encrypted_recipient_data.payment_relay` to calculate `amt_to_forward` and `outgoing_cltv_value` as follows: - `amt_to_forward = ((amount_msat - fee_base_msat) * 1000000 + 1000000 + fee_proportional_millionths - 1) / (1000000 + fee_proportional_millionths)` - `outgoing_cltv_value = cltv_expiry - payment_relay.cltv_expiry_delta` - If it is the final node: - - MUST return an error if the payload contains other tlv fields than `encrypted_recipient_data`, `current_blinding_point`, `amt_to_forward`, `outgoing_cltv_value` and `total_amount_msat`. + - MUST return an error if the payload contains other tlv fields than `encrypted_recipient_data`, `current_path_key`, `amt_to_forward`, `outgoing_cltv_value` and `total_amount_msat`. - MUST return an error if `amt_to_forward`, `outgoing_cltv_value` or `total_amount_msat` are not present. - MUST return an error if `amt_to_forward` is below what it expects for the payment. - MUST return an error if incoming `cltv_expiry` < `outgoing_cltv_value`. - MUST return an error if incoming `cltv_expiry` < `current_block_height` + `min_final_cltv_expiry_delta`. - Otherwise (it is not part of a blinded route): - - MUST return an error if `blinding_point` is set in the incoming `update_add_htlc` or `current_blinding_point` is present. + - MUST return an error if `path_key` is set in the incoming `update_add_htlc` or `current_pass` is present. - MUST return an error if `amt_to_forward` or `outgoing_cltv_value` are not present. - if it is not the final node: - MUST return an error if: @@ -438,7 +438,7 @@ Nodes receiving onion packets may hide their identity from senders by "blinding" an arbitrary amount of hops at the end of an onion path. When using route blinding, nodes find a route to themselves from a given -"introduction node" and initial "blinding point". They then use ECDH with +"introduction node" and initial "path key". They then use ECDH with each node in that route to create a "blinded" node ID and an encrypted blob (`encrypted_data`) for each one of the blinded nodes. @@ -450,10 +450,10 @@ part of the route to "unblind" the next node and correctly forward the packet. Note that there are two ways for the sender to reach the introduction point: one is to create a normal (unblinded) payment, and place the -initial blinding point in `current_blinding_point` along with the +initial blinding point in `current_path_key` along with the `encrypted_data` in the onion payload for the introduction point to start the blinded path. The second way is to create a blinded path to -the introduction point, set `next_blinding_override` inside the +the introduction point, set `next_path_key_override` inside the `encrypted_data_tlv` on the hop prior to the introduction point to the initial blinding point, and have it sent to the introduction node. @@ -474,9 +474,9 @@ may contain the following TLV fields: 1. type: 6 (`path_id`) 2. data: * [`...*byte`:`data`] - 1. type: 8 (`next_blinding_override`) + 1. type: 8 (`next_path_key_override`) 2. data: - * [`point`:`blinding`] + * [`point`:`path_key`] 1. type: 10 (`payment_relay`) 2. data: * [`u16`:`cltv_expiry_delta`] @@ -502,25 +502,25 @@ A recipient $`N_r`$ creating a blinded route $`N_0 \rightarrow N_1 \rightarrow . - $`ss_i = SHA256(e_i * N_i) = SHA256(k_i * E_i)$` (ECDH shared secret known only by $`N_r`$ and $`N_i`$) - $`B_i = HMAC256(\text{"blinded\_node\_id"}, ss_i) * N_i`$ (blinded `node_id` for $`N_i`$, private key known only by $`N_i`$) - $`rho_i = HMAC256(\text{"rho"}, ss_i)`$ (key used to encrypt the payload for $`N_i`$ by $`N_r`$) - - $`e_{i+1} = SHA256(E_i || ss_i) * e_i`$ (blinding ephemeral private key, only known by $`N_r`$) - - $`E_{i+1} = SHA256(E_i || ss_i) * E_i`$ (NB: $`N_i`$ MUST NOT learn $`e_i`$) + - $`e_{i+1} = SHA256(E_i || ss_i) * e_i`$ (ephemeral private path key, only known by $`N_r`$) + - $`E_{i+1} = SHA256(E_i || ss_i) * E_i`$ (`path_key`. NB: $`N_i`$ MUST NOT learn $`e_i`$) - MAY replace $`E_{i+1}`$ with a different value, but if it does: - - MUST set `encrypted_data_tlv[i].next_blinding_override` to `$E_{i+1}$` + - MUST set `encrypted_data_tlv[i].next_path_key_override` to `$E_{i+1}$` - MAY store private data in `encrypted_data_tlv[r].path_id` to verify that the route is used in the right context and was created by them - SHOULD add padding data to ensure all `encrypted_data_tlv[i]` have the same length - MUST encrypt each `encrypted_data_tlv[i]` with ChaCha20-Poly1305 using the corresponding `rho_i` key and an all-zero nonce to produce `encrypted_recipient_data[i]` - MUST communicate the blinded node IDs $`B_i`$ and `encrypted_recipient_data[i]` to the sender - MUST communicate the real node ID of the introduction point $`N_0`$ to the sender -- MUST communicate the first blinding ephemeral key $`E_0`$ to the sender +- MUST communicate the first `path_key` $`E_0`$ to the sender A reader: -- If it receives `blinding_point` ($`E_i`$) from the prior peer: +- If it receives `path_key` ($`E_i`$) from the prior peer: - MUST use $`b_i`$ instead of its private key $`k_i`$ to decrypt the onion. Note that the node may instead tweak the onion ephemeral key with $`HMAC256(\text{"blinded\_node\_id}", ss_i)`$ which achieves the same result. - Otherwise: - - MUST use $`k_i`$ to decrypt the onion, to extract `current_blinding_point` ($`E_i`$). + - MUST use $`k_i`$ to decrypt the onion, to extract `current_path_key` ($`E_i`$). - MUST compute: - $`ss_i = SHA256(k_i * E_i)`$ (standard ECDH) - $`b_i = HMAC256(\text{"blinded\_node\_id"}, ss_i) * k_i`$ @@ -530,11 +530,11 @@ A reader: decrypted fields to locate the next node - If the `encrypted_data` field is missing or cannot be decrypted: - MUST return an error -- If `encrypted_data` contains a `next_blinding_override`: - - MUST use it as the next blinding point instead of $`E_{i+1}`$ +- If `encrypted_data` contains a `next_path_key_override`: + - MUST use it as the next `path_key` instead of $`E_{i+1}`$ - Otherwise: - - MUST use $`E_{i+1}`$ as the next blinding point -- MUST forward the onion and include the next blinding point in the lightning + - MUST use $`E_{i+1}`$ as the next `path_key` +- MUST forward the onion and include the next `path_key` in the lightning message for the next node The final recipient: @@ -562,8 +562,8 @@ the onion and the `encrypted_data` payload. Protocols that use route blinding must specify how this value is propagated between nodes. When concatenating two blinded routes generated by different nodes, the -last node of the first route needs to know the first `blinding_point` of the -second route: the `next_blinding_override` field must be used to transmit this +last node of the first route needs to know the first `path_key` of the +second route: the `next_path_key_override` field must be used to transmit this information. The final recipient must verify that the blinded route is used in the right @@ -683,7 +683,7 @@ during packet forwarding, the hop uses the ephemeral public key and its own node ID private key. Because of the properties of ECDH, they will both derive the same value. -# Blinding Ephemeral Keys +# Blinding Ephemeral Onion Keys In order to ensure multiple hops along the route cannot be linked by the ephemeral public keys they see, the key is blinded at each hop. The blinding is @@ -861,7 +861,7 @@ There are two kinds of `onion_packet` we use: 1. `onion_routing_packet` in `update_add_htlc` for payments, which contains a `payload` TLV (see [Adding an HTLC](02-peer-protocol.md#adding-an-htlc-update_add_htlc)) 2. `onion_message_packet` on `onion_message` for messages, which contains a `onionmsg_tlv` TLV (see [Onion Messages](#onion-messages) -Those sections specify the `associated_data` to use, the `blinding` (if any), the extracted payload format and handling (including how to determine the next peer, if any), and how to handle errors. The processing itself is identical. +Those sections specify the `associated_data` to use, the `path_key` (if any), the extracted payload format and handling (including how to determine the next peer, if any), and how to handle errors. The processing itself is identical. ## Requirements @@ -876,8 +876,8 @@ A reader: - MAY immediately redeem the HTLC using the preimage. - otherwise: - MUST abort processing the packet and fail. - - if `blinding` is specified: - - Calculate the `blinding_ss` as ECDH(`blinding`, `node-privkey`) + - if `path_key` is specified: + - Calculate the `blinding_ss` as ECDH(`path_key`, `node-privkey`) - Either: - Tweak `public_key` by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$ - or (equivalently): @@ -904,7 +904,7 @@ A reader: - If `unwrapped_payloads` is smaller than `hop_payloads`: - MUST abort processing the packet and fail. - If `next_hmac` is not all-zero (not the final node): - - Derive `blinding_tweak` as $`SHA256(public_key || ss)`$ (see [Blinding Ephemeral Keys](#blinding-ephemeral-keys)) + - Derive `blinding_tweak` as $`SHA256(public_key || ss)`$ (see [Blinding Ephemeral Onion Keys](#blinding-ephemeral-onion-keys)) - SHOULD forward an onion to the next peer with: - `version` set to 0 - `public_key` set to the incoming `public_key` multiplied by `blinding_tweak` @@ -918,7 +918,7 @@ A reader: ## Rationale -In the case where blinded paths are used, the sender did not actually encrypt this onion for our node_id, but for a tweaked version: we can derive the tweak used from `blinding` which is given alongside the onion. Then we either tweak our node private key the same way to decrypt the onion, or tweak to the onion ephemeral key which is mathematically equivalent. +In the case where blinded paths are used, the sender did not actually encrypt this onion for our node_id, but for a tweaked version: we can derive the tweak used from `path_key` which is given alongside the onion. Then we either tweak our node private key the same way to decrypt the onion, or tweak to the onion ephemeral key which is mathematically equivalent. # Filler Generation @@ -1034,7 +1034,7 @@ The association between the forward and return packets is handled outside of this onion routing protocol, e.g. via association with an HTLC in a payment channel. -Error handling for HTLCs with `blinding_point` is particularly fraught, +Error handling for HTLCs with `path_key` is particularly fraught, since differences in implementations (or versions) may be leveraged to de-anonymize elements of the blinded path. Thus the decision turn every error into `invalid_onion_blinding` which will be converted to a normal @@ -1265,9 +1265,9 @@ An error occurred within the blinded path. ### Requirements An _erring node_: - - if `blinding_point` is set in the incoming `update_add_htlc`: + - if `path_key` is set in the incoming `update_add_htlc`: - MUST return an `invalid_onion_blinding` error. - - 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 return an `invalid_onion_blinding` error. - otherwise: @@ -1289,9 +1289,9 @@ An _erring node_ MAY: - return a `required_node_feature_missing` error. A _forwarding node_ MUST: - - if `blinding_point` is set in the incoming `update_add_htlc`: + - if `path_key` is set in the incoming `update_add_htlc`: - return an `invalid_onion_blinding` error. - - 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: - return an `invalid_onion_blinding` error. - otherwise: @@ -1436,7 +1436,7 @@ For consistency, all onion messages use [Route Blinding](#route-blinding). 1. type: 513 (`onion_message`) (`option_onion_messages`) 2. data: - * [`point`:`blinding`] + * [`point`:`path_key`] * [`u16`:`len`] * [`len*byte`:`onion_message_packet`] @@ -1457,7 +1457,7 @@ For consistency, all onion messages use [Route Blinding](#route-blinding). The `onionmsg_tlv` itself is a TLV: an intermediate node expects an `encrypted_data` which it can decrypt into an `encrypted_data_tlv` -using the `blinding` which it is handed along with the onion message. +using the `path_key` which it is handed along with the onion message. Field numbers 64 and above are reserved for payloads for the final hop, though these are not explicitly refused by non-final hops (unless @@ -1475,7 +1475,7 @@ even, of course!). 1. subtype: `blinded_path` 2. data: * [`point`:`first_node_id`] - * [`point`:`blinding`] + * [`point`:`first_path_key`] * [`byte`:`num_hops`] * [`num_hops*onionmsg_hop`:`path`] @@ -1505,7 +1505,7 @@ The writer: - MUST NOT set fields other than `encrypted_recipient_data`. - For the final node's `onionmsg_tlv`: - if the final node is permitted to reply: - - MUST set `reply_path` `blinding` to the initial blinding factor for the `first_node_id` + - MUST set `reply_path` `path_key` to the initial path key for the `first_node_id` - 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 `blinded_node_id` to the blinded node id to encrypt the onion hop for. @@ -1519,7 +1519,7 @@ The reader: - SHOULD accept onion messages from peers without an established channel. - MAY rate-limit messages by dropping them. -- MUST decrypt `onion_message_packet` using an empty `associated_data`, and `blinding`, as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract an `onionmsg_tlv`. +- MUST decrypt `onion_message_packet` using an empty `associated_data`, and `path_key`, as described in [Onion Decryption](04-onion-routing.md#onion-decryption) to extract an `onionmsg_tlv`. - If decryption fails, the result is not a valid `onionmsg_tlv`, or it contains unknown even types: - MUST ignore the message. - if `encrypted_data_tlv` contains `allowed_features`: @@ -1534,7 +1534,7 @@ The reader: - otherwise: - SHOULD forward the message using `onion_message` to the next peer indicated by `next_node_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). + - 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): - if `path_id` is set and corresponds to a path the reader has previously published in a `reply_path`: - if the onion message is not a reply to that previous onion: @@ -1547,7 +1547,7 @@ The reader: - if it wants to send a reply: - MUST create an onion message using `reply_path`. - MUST send the reply via `onion_message` to the node indicated by - the `first_node_id`, using `reply_path` `blinding` to send + the `first_node_id`, using `reply_path` `path_key` to send along `reply_path` `path`. From dd27d4dd1746db788c86b5bcfe22f740ab520a86 Mon Sep 17 00:00:00 2001 From: t-bast Date: Wed, 17 Jul 2024 10:35:52 +0930 Subject: [PATCH 5/5] Clean-up nits This commit doesn't change the logic at all, it simply: - removes `realm` from onion test vector - cleans-up markdown formatting and indents - fixes typos and missing parenthesis - consistently uses `_` instead of `-` for field names - fixes math formatting (including changes from #1169 and #1158) --- 02-peer-protocol.md | 4 +- 04-onion-routing.md | 59 ++++++++++---------- bolt04/blinded-onion-message-onion-test.json | 18 +++--- bolt04/blinded-payment-onion-test.json | 16 +++--- bolt04/onion-error-test.json | 10 ++-- bolt04/route-blinding-test.json | 8 +-- 6 files changed, 57 insertions(+), 58 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 2ae0d0747..27b01fe04 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -2130,14 +2130,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_path_key_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 `path_key_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. diff --git a/04-onion-routing.md b/04-onion-routing.md index ba500db3b..c5a157d9f 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -321,7 +321,7 @@ The reader: - MUST return an error if incoming `cltv_expiry` < `outgoing_cltv_value`. - MUST return an error if incoming `cltv_expiry` < `current_block_height` + `min_final_cltv_expiry_delta`. - Otherwise (it is not part of a blinded route): - - MUST return an error if `path_key` is set in the incoming `update_add_htlc` or `current_pass` is present. + - MUST return an error if `path_key` is set in the incoming `update_add_htlc` or `current_path_key` is present. - MUST return an error if `amt_to_forward` or `outgoing_cltv_value` are not present. - if it is not the final node: - MUST return an error if: @@ -495,20 +495,20 @@ may contain the following TLV fields: A recipient $`N_r`$ creating a blinded route $`N_0 \rightarrow N_1 \rightarrow ... \rightarrow N_r`$ to itself: - MUST create a blinded node ID $`B_i`$ for each node using the following algorithm: - - $`e_0 /leftarrow {0;1}^256`$ ($`e_0`$ SHOULD be obtained via CSPRG) + - $`e_0 \leftarrow \{0;1\}^{256}`$ ($`e_0`$ SHOULD be obtained via CSPRNG) - $`E_0 = e_0 \cdot G`$ - For every node in the route: - let $`N_i = k_i * G`$ be the `node_id` ($`k_i`$ is $`N_i`$'s private key) - - $`ss_i = SHA256(e_i * N_i) = SHA256(k_i * E_i)$` (ECDH shared secret known only by $`N_r`$ and $`N_i`$) + - $`ss_i = SHA256(e_i * N_i) = SHA256(k_i * E_i)`$ (ECDH shared secret known only by $`N_r`$ and $`N_i`$) - $`B_i = HMAC256(\text{"blinded\_node\_id"}, ss_i) * N_i`$ (blinded `node_id` for $`N_i`$, private key known only by $`N_i`$) - $`rho_i = HMAC256(\text{"rho"}, ss_i)`$ (key used to encrypt the payload for $`N_i`$ by $`N_r`$) - $`e_{i+1} = SHA256(E_i || ss_i) * e_i`$ (ephemeral private path key, only known by $`N_r`$) - $`E_{i+1} = SHA256(E_i || ss_i) * E_i`$ (`path_key`. NB: $`N_i`$ MUST NOT learn $`e_i`$) - MAY replace $`E_{i+1}`$ with a different value, but if it does: - - MUST set `encrypted_data_tlv[i].next_path_key_override` to `$E_{i+1}$` + - MUST set `encrypted_data_tlv[i].next_path_key_override` to $`E_{i+1}`$ - MAY store private data in `encrypted_data_tlv[r].path_id` to verify that the route is used in the right context and was created by them - SHOULD add padding data to ensure all `encrypted_data_tlv[i]` have the same length -- MUST encrypt each `encrypted_data_tlv[i]` with ChaCha20-Poly1305 using the corresponding `rho_i` key and an all-zero nonce to produce `encrypted_recipient_data[i]` +- MUST encrypt each `encrypted_data_tlv[i]` with ChaCha20-Poly1305 using the corresponding $`rho_i`$ key and an all-zero nonce to produce `encrypted_recipient_data[i]` - MUST communicate the blinded node IDs $`B_i`$ and `encrypted_recipient_data[i]` to the sender - MUST communicate the real node ID of the introduction point $`N_0`$ to the sender - MUST communicate the first `path_key` $`E_0`$ to the sender @@ -518,7 +518,7 @@ A reader: - If it receives `path_key` ($`E_i`$) from the prior peer: - MUST use $`b_i`$ instead of its private key $`k_i`$ to decrypt the onion. Note that the node may instead tweak the onion ephemeral key with - $`HMAC256(\text{"blinded\_node\_id}", ss_i)`$ which achieves the same result. + $`HMAC256(\text{"blinded\_node\_id"}, ss_i)`$ which achieves the same result. - Otherwise: - MUST use $`k_i`$ to decrypt the onion, to extract `current_path_key` ($`E_i`$). - MUST compute: @@ -557,7 +557,7 @@ keys of the nodes in the route with random public keys while letting senders choose what data they put in the onion for each hop. Blinded routes are also reusable in some cases (e.g. onion messages). -Each node in the blinded route needs to receive `E_i` to be able to decrypt +Each node in the blinded route needs to receive $`E_i`$ to be able to decrypt the onion and the `encrypted_data` payload. Protocols that use route blinding must specify how this value is propagated between nodes. @@ -570,7 +570,7 @@ The final recipient must verify that the blinded route is used in the right context (e.g. for a specific payment) and was created by them. Otherwise a malicious sender could create different blinded routes to all the nodes that they suspect could be the real recipient and try them until one accepts the -message. The recipient can protect against that by storing `E_r` and the +message. The recipient can protect against that by storing $`E_r`$ and the context (e.g. a `payment_hash`), and verifying that they match when receiving the onion. Otherwise, to avoid additional storage cost, it can put some private context information in the `path_id` field (e.g. the `payment_preimage`) and @@ -617,7 +617,7 @@ sent across. Nodes implementing non-strict forwarding are able to make real-time assessments of channel bandwidths with a particular peer, and use the channel that is -locally-optimal. +locally-optimal. For example, if the channel specified by `short_channel_id` connecting A and B does not have enough bandwidth at forwarding time, then A is able use a @@ -857,9 +857,10 @@ func NewOnionPacket(paymentPath []*btcec.PublicKey, sessionKey *btcec.PrivateKey # Onion Decryption -There are two kinds of `onion_packet` we use: +There are two kinds of `onion_packet` we use: + 1. `onion_routing_packet` in `update_add_htlc` for payments, which contains a `payload` TLV (see [Adding an HTLC](02-peer-protocol.md#adding-an-htlc-update_add_htlc)) -2. `onion_message_packet` on `onion_message` for messages, which contains a `onionmsg_tlv` TLV (see [Onion Messages](#onion-messages) +2. `onion_message_packet` in `onion_message` for messages, which contains an `onionmsg_tlv` TLV (see [Onion Messages](#onion-messages)) Those sections specify the `associated_data` to use, the `path_key` (if any), the extracted payload format and handling (including how to determine the next peer, if any), and how to handle errors. The processing itself is identical. @@ -871,26 +872,26 @@ A reader: - if `public_key` is not a valid pubkey: - MUST abort processing the packet and fail. - if the onion is for a payment: - - if `hmac` has previously been received: - - if the preimage is known: - - MAY immediately redeem the HTLC using the preimage. - - otherwise: - - MUST abort processing the packet and fail. + - if `hmac` has previously been received: + - if the preimage is known: + - MAY immediately redeem the HTLC using the preimage. + - otherwise: + - MUST abort processing the packet and fail. - if `path_key` is specified: - - Calculate the `blinding_ss` as ECDH(`path_key`, `node-privkey`) + - Calculate the `blinding_ss` as ECDH(`path_key`, `node_privkey`). - Either: - - Tweak `public_key` by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$ + - Tweak `public_key` by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$. - or (equivalently): - - Tweak its own `node-privkey` below by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$ - - Derive the shared secret `ss` as ECDH(`public_key`, `node-privkey`) (see [Shared Secret](#shared-secret)) + - Tweak its own `node_privkey` below by multiplying by $`HMAC256(\text{"blinded\_node\_id"}, blinding\_ss)`$. + - Derive the shared secret `ss` as ECDH(`public_key`, `node_privkey`) (see [Shared Secret](#shared-secret)). - Derive `mu` as $`HMAC256(\text{"mu"}, ss)`$ (see [Key Generation](#key-generation)). - - Derive the HMAC as $`HMAC256(mu, hop_payloads || associated_data)`$ + - Derive the HMAC as $`HMAC256(mu, hop\_payloads || associated\_data)`$. - MUST use a constant time comparison of the computed HMAC and `hmac`. - If the computed HMAC and `hmac` differ: - MUST abort processing the packet and fail. - Derive `rho` as $`HMAC256(\text{"rho"}, ss)`$ (see [Key Generation](#key-generation)). - Derive `bytestream` of twice the length of `hop_payloads` using `rho` (see [Pseudo Random Byte Stream](pseudo-random-byte-stream)). - - Set `unwrapped_payloads` to the XOR of `hop_payloads` and `bytestream` + - Set `unwrapped_payloads` to the XOR of `hop_payloads` and `bytestream`. - Remove a `bigsize` from the front of `unwrapped_payloads` as `payload_length`. If that is malformed: - MUST abort processing the packet and fail. - If the `payload_length` is less than two: @@ -904,22 +905,20 @@ A reader: - If `unwrapped_payloads` is smaller than `hop_payloads`: - MUST abort processing the packet and fail. - If `next_hmac` is not all-zero (not the final node): - - Derive `blinding_tweak` as $`SHA256(public_key || ss)`$ (see [Blinding Ephemeral Onion Keys](#blinding-ephemeral-onion-keys)) + - Derive `blinding_tweak` as $`SHA256(public\_key || ss)`$ (see [Blinding Ephemeral Onion Keys](#blinding-ephemeral-onion-keys)). - SHOULD forward an onion to the next peer with: - - `version` set to 0 - - `public_key` set to the incoming `public_key` multiplied by `blinding_tweak` - - `hop_payloads` set to the `unwrapped_payloads`, truncated to the incoming `hop_payloads` size - - `hmac` set to `next_hmac` + - `version` set to 0. + - `public_key` set to the incoming `public_key` multiplied by `blinding_tweak`. + - `hop_payloads` set to the `unwrapped_payloads`, truncated to the incoming `hop_payloads` size. + - `hmac` set to `next_hmac`. - If it cannot forward: - MUST fail. - Otherwise (all-zero `next_hmac`): - This is the final destination of the onion. - ## Rationale -In the case where blinded paths are used, the sender did not actually encrypt this onion for our node_id, but for a tweaked version: we can derive the tweak used from `path_key` which is given alongside the onion. Then we either tweak our node private key the same way to decrypt the onion, or tweak to the onion ephemeral key which is mathematically equivalent. - +In the case where blinded paths are used, the sender did not actually encrypt this onion for our `node_id`, but for a tweaked version: we can derive the tweak used from `path_key` which is given alongside the onion. Then we either tweak our node private key the same way to decrypt the onion, or tweak to the onion ephemeral key which is mathematically equivalent. # Filler Generation diff --git a/bolt04/blinded-onion-message-onion-test.json b/bolt04/blinded-onion-message-onion-test.json index f66660cc7..fe5191ed1 100644 --- a/bolt04/blinded-onion-message-onion-test.json +++ b/bolt04/blinded-onion-message-onion-test.json @@ -6,12 +6,12 @@ "hops": [ { "alias": "Alice", - "comment": "Alice->Bob: note next_blinding_override to match that give by Dave for Bob", - "blinding_secret": "6363636363636363636363636363636363636363636363636363636363636363", + "comment": "Alice->Bob: note next_path_key_override to match that give by Dave for Bob", + "path_key_secret": "6363636363636363636363636363636363636363636363636363636363636363", "tlvs": { "next_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", - "next_blinding_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", - "blinding_override_secret": "0101010101010101010101010101010101010101010101010101010101010101" + "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", + "path_key_override_secret": "0101010101010101010101010101010101010101010101010101010101010101" }, "encrypted_data_tlv": "04210324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c0821031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", "ss": "c04d2a4c518241cb49f2800eea92554cb543f268b4c73f85693541e86d649205", @@ -26,7 +26,7 @@ { "alias": "Bob", "comment": "Bob->Carol", - "blinding_secret": "0101010101010101010101010101010101010101010101010101010101010101", + "path_key_secret": "0101010101010101010101010101010101010101010101010101010101010101", "tlvs": { "next_node_id": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007", "unknown_tag_561": "123456" @@ -44,7 +44,7 @@ { "alias": "Carol", "comment": "Carol->Dave", - "blinding_secret": "f7ab6dca6152f7b6b0c9d7c82d716af063d72d8eef8816dfc51a8ae828fa7dce", + "path_key_secret": "f7ab6dca6152f7b6b0c9d7c82d716af063d72d8eef8816dfc51a8ae828fa7dce", "tlvs": { "padding": "0000000000", "next_node_id": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991" @@ -62,7 +62,7 @@ { "alias": "Dave", "comment": "Dave is final node, hence path_id", - "blinding_secret": "5de52bb427cc148bf23e509fdc18012004202517e80abcfde21612ae408e6cea", + "path_key_secret": "5de52bb427cc148bf23e509fdc18012004202517e80abcfde21612ae408e6cea", "tlvs": { "padding": "", "path_id": "deadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0ffeedeadbeefbadc0", @@ -82,8 +82,8 @@ }, "route": { "comment": "The resulting blinded route Alice to Dave.", - "introduction_node_id": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619", - "blinding": "031195a8046dcbb8e17034bca630065e7a0982e4e36f6f7e5a8d4554e4846fcd99", + "first_node_id": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619", + "first_path_key": "031195a8046dcbb8e17034bca630065e7a0982e4e36f6f7e5a8d4554e4846fcd99", "hops": [ { "blinded_node_id": "02d1c3d73f8cac67e7c5b6ec517282d5ba0a52b06a29ec92ff01e12decf76003c1", diff --git a/bolt04/blinded-payment-onion-test.json b/bolt04/blinded-payment-onion-test.json index 97406fb1f..aa6c5b6cc 100644 --- a/bolt04/blinded-payment-onion-test.json +++ b/bolt04/blinded-payment-onion-test.json @@ -14,8 +14,8 @@ }, "blinded_route": { "comment": "This section contains a blinded route that the sender will use for his payment, usually obtained from a Bolt 12 invoice.", - "introduction_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", - "blinding": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", + "first_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", + "first_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", "hops": [ { "alias": "Bob", @@ -57,7 +57,7 @@ "pubkey": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", "payload": "740a4fcd7b00ff9c09ed28102b210ac73aa12d63e90852cebc496c49f57c499a2888b49f2e72b19446f7e60a818aa2938d8c625415b992b8928a7321edb8f7cea40de362bed082ad51acc6156dca5532fb680c21024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", "tlvs": { - "current_blinding_point": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", + "current_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", "encrypted_recipient_data": { "padding": "0000000000000000000000000000000000000000000000000000000000000000", "short_channel_id": "0x0x1", @@ -83,7 +83,7 @@ "tlvs": { "encrypted_recipient_data": { "short_channel_id": "0x0x2", - "next_blinding_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", + "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", "payment_relay": { "cltv_expiry_delta": 75, "fee_proportional_millionths": 150, @@ -158,25 +158,25 @@ "alias": "Bob", "onion": "000280caa47c2a0ea677f6a77529e46caa04212153a8d5f829bee1e7339b17e2e2a9a3461d10472364a4ff12344beb6df96fb0c38ec47d1e956ddff5a665190fcca5ed02c3a3903fd8bbd4a4b95b197867c378b67b08f0624cfe80734ba512869c0fa22099beb1f6f1ea325b07ce7449736d7ffad79178b428d8ea2d7bc6578f12dbd788ef933f3b5ba352797c41f6786c3820c96726acf8bddf2cfa5d9c617d2b0bd5ab7b93f7964c98f44cf47db8422f47d11100236a29579f1cafcd38bd979814e1d2bf6d625edf50e1e21bfaf6268e3180dd7aafd3892da281c6dd53c1c366d0fdaf670b6ad84a38d6e8a3f4a80d132d686fd3b7443bc2250023bdb9303190f74c9220481cf99da30b5ec2bdb5a49028f5014e3eaeaa48429a0c78ebd3bb7c7d582c22b7d547cd269f0c4490373a81bf92687e73dac2075b4bda189ce0be225f5f510655e37a6e724a1415bede0a076b92a882cc2a82878ba67aaedf71454eb42b7f8638df8e21d5f708006e5112e2dc0a4afbcfed9f2c7959be812853ca8e313fbc99a0f38f1ee4479c96ccb836632b0808401db159bd2637f7a664013241e4664e994a0a9a3940115a702c60381e66d291e1ade1be2802e1226e311e3201a7c9682b6bc4354caff3d439adb1dfee53ad3fb3dd5e169d64796853bb323129f41213b166a7cac00f728c3e33bd7e59aa2ac0d1341cdb1532b507a0f446e51022a882ac16405442347b70f78c9b6e122f8e70096a4fae4c0405db5b869e0b7b59b09519c4dbf4d4980483906e837da0bee93f668ffaad37d6a4764211a02f95ad2dc2d942c198796741c20a3baf8efb5a53bd9c1a0148318d60a97d0013ab63269097ea295d62c1426d064f0b31c02e74a348ee0509998e701069f5a1e0c1086aed38d2ec87da69fb57a992d88ace3b4a16b0960f5a94936e2e684a9926cf4f911969a2a5d31fed0c7616d30197848253170e51274278873b11f3f5cc1b04b14aa5812524e4d86cbf08306c2aa671288324d7a009b2be533b1d7d0ce6defeeb630b86a9655f1e6424fcb559ed67457c115fba0d0719374802ea68fab299fd3f273be86fa3d2e7456020db2f47c6ec16c21ce6ec65de495e20af1941a5dcd65d910c1cb93f22e1318c173c645c81aed681c9704a8a541ac3d6ff604f46d0260468acbfec1b771b9eb8cd49a2124468dae786571895a569aae18438eaee6343ab2634823119fa2439634645d12e3b4a748b9cc0398b8416a834eb5d9e5cf619bbfaba4894d1c574c738caf530d0862f4cc75eb52bd3921d2d9edb09940edb1e3776423b0046d870ccdcc5d61f72e0440b97a93eeef21fb246a779d339be301a5971400749d6cc9911dfbf9de8ae86fac83c860fdd0e2bfa40af37c99d50e50fd6e5ae86597a201112ed404042b55e132f243dec481a2adc1d5e4b71e1efdea806ea900b2907ce877742d5ecf700ff3640f737863d0dd7207e462ee8d0e17d52047a88ae7446f419560d23968bf64957949e36953155b0ac2511c66be2890b4036329a21e132efb635297a64431899e0c351e50c6682c9b4d79b5d122466d02cd84f206369417d9c194a9349d3c631d72eb7857a9cd542906fc02ad6cdcf9bcf25ace3d826b6623fa5164351e14d3f0de5c8445a2ba3aae26595d0e31c3e307c1d56d4274f61f056145c1b8d6880872b9b10a8bfa4a923cad2edbcf5c50eba48936ed2bcc0be60eb721a74b46704aaae5ad24e2797852195dfacbb30a777d33b63d4dc4f35cfbe5e88fd1944c55a54fd53581446ea061ad29f4671da819ad7488c5dfc700f5f7a1b2af0d6a6e9d9ffc570a6d3209614ab4dc43728f3f0cd7eb4ce36ccd98936bbcbd32627384434bd01e9c0f93b2a5173fba184685e19b9af78afe876aa4e4b4242382b293133771d95a2bd83fa9c62", "node_privkey": "4242424242424242424242424242424242424242424242424242424242424242", - "next_blinding": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0" + "next_path_key": "034e09f450a80c3d252b258aba0a61215bf60dda3b0dc78ffb0736ea1259dfd8a0" }, { "alias": "Carol", "onion": "000288b48876fb0dc0d7375233ccaf2910dc0dc81ba52e5a7906f00d75e0d58dbd4bb7c2714870529410735f0951e72cbe981e2e167c0d8f3de33a36e39e78465aea2acad1e23c78b6fd342d63e37d214c912b4a0be344618f779138edc1b42a5ca3218ca2fea4be427f6cd0d387160db2bf6c2ba8e82941c8cf3626bd6bed7187f633012ef49df38f6b12963cb639e9eed1b9d269dcebcbd0b25287aa536ec85e7320b02e193122199a745ccbaaebd37f5d4b71f52f9b50feeb793eeef56924a046bc5e7003f6253e0284a8d3fe2e42c3564050f1e753cd32cc258ac0ffa6e05eecad5ba1286f78252e60dd884a65405ab673a85ba52adfa65c1086d4bb37ba2e0848adb2b04379775ad798492b14e8997f30ffa9cf5d432bdf5b246fce008fd876399beed827db58195f4f6192f6ff4ec63cb17fdcb497cb7aec26846a71dd8dca02fc3bb14dd7231a4d62a981bec54b71eb20331096dfa214a0ff4489ee96db663826ae8c850e9f06baa52a47b8eb576363f97e742aab2dc616acc6e74588e1d2ac16694febc90abaf5b1c684163c0e615a68d32633f01934adc8c6bf91fa3fd7aad033b7596d60402494e45e2c1632c40f7bfbd88a81a896a1d28ed6338c83e1eeaa467945d59998eb456c95f94bf1892e8f326ec2d5e0196b7073f106febc6ab8ca5bcc23f77ffc819bc1b5debce418ccc7d8391bbf33bceee6110beba170121bd99f54c956e64970bdab31227b03ee0ea3f01fbd9bd74015f6f82d04fab072e8f85f4370d09f41ee3e48eb959767bd989abb4eea42c4daa0437a7f747d7f9b70eb87b9f9b0b6f283b8205912601a432999b8869fd9fe5bad3572edac24da7184f9298f21ff60923db277264d29c846dd2f228f6fc53b6b60364237de64773f803f174ed10229c374f603ccc5fd3a62cb413ffe6f5630dc646bb33f231b2350537ec39e5d3f2fe1a1cb019ed0b18ad14019cad27afcca8ad70387ca110394c0432774f1aa1fa404b2e086c84a55388d3bd102501c78ef925cce89d76fa04c3f20f2d1f0ce507ac8b37b7913e3949ba12bbc5a4f6bac37c2415622d365bc8b83709a28e3d46f3850c89a3ff4d027fef6e3e4ce5c6c85f663c7eaec3c9730106fb82f53249a905533cfabee812aae51965b24b42f7ab471967bc8e73354e69141ee26a1f03684d5fb9c256a34de8257210e0390dd3962db521ae0a3bdab28300610ab2a634b699e5f092da5a061609ef6414bd805c8171f54ad6f285fb64ce0becca0b61188badcf8ef21190dad629e3fb3e89f55ebba829919540ebf5f8ae4283836d3c9133c1ca3365f6b9394916730411650686e0c2ab9c53b6cda9efdd5cfcb53ba9b6962bb6aa49d0a83a87460b60a9c7d2643ee99afe652883795f14014ec5df61b1e30c041c1fa6487f3c82f1ded5f83ffbef5017e197b7fb77be3b36e284a15e57d45bf9316dcaf97eb78ee4642b731ba05c5063bce1333fab4af6da97c80a96ee599b4df823efbedc250c0abba9783da7ddf2414b2a4774ff2880a7dc6791103e18b8631e39743cf9e87aed71700daa5dc72fdae520324741f92ea3d510ff555dea5e45f15cda87272d4559a12d4777680acb06993840e3c748da82c16cae556015fb2acd0335da11a3388575394048ab71199793ab706abc9d68add2075d79a5cc0f779845ee8b98951be61fd293d6c15b9d4653935bf17cf50bd31f8b79e60dba0e7fd6864754fd94262485a4f65e7eb3e1922f51b1a4dd2b4fd2c20d94d1213fbe90bd603dfc7e15176382e3ce0f43f980d44d23bf3c57f54a15f42c171a8f2511e28ac178c6f01396e50397a57ffb09c5e6c315bd3ae7983577c1a0386c6d5d9a2223438e321b0fedfdee58fa452d57dc11a256834bb49ac9deeec88e4bf563c7340f44a240caec941c7e50f09cf", "node_privkey": "4343434343434343434343434343434343434343434343434343434343434343", - "next_blinding": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f" + "next_path_key": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f" }, { "alias": "Dave", "onion": "0003f25471c0f2ff549a7fd7859100306bb6c294c209f34c77f782897f184b967c498efc246bdb8e060a6d1cf8dd0d4d732e33311fb96c9e9f1274005fa3d08b41704a1b7224c6300a7caead7baa0a8263eba2e0de6956ee8e4a1958264f47e4cf20d194eb576f5bd249ee4fece563f80fd76dc3eaca8f956188406d83195752b5c90c4b2a5e7ac3a8d5c62b17b551aff48ef6842a7e9326832c9a4a2fd415011150a9e71beb901fd9747bac8add1c694b612730dc86b5b19a0bbbc675947a953316e3303d7b30c182f94def9206671edac9a3ec3e52d28fc28247a1c73ab751bf61c82c3950f617e758f79bd0ba294defb20466eaf1e801462046baad3aec3e5b8868a7b037f23d73a47a7e74c77107334f37388cff863e452820c61d89728fa75c84bc7cdfc06dcdd1911f5f803353926d073efd65251380e174913aae03318ea5b6f0ec83998c55ab99bef62803ea2da9f6d1ea892b90efc4f8ffb685a5201a781da2e6ac5923645638c9709ae32171a00c0cd3d8c7eedfb06b4eedc7d3e566987e2e3805a038f21d78ded5d6c7137a5e8e592f3180ee4d5f4e1289176f67fc38690d0958bc82e240b72b10577f340f1e14b8633f0b6d9729ff4618be2a972400a015a871ba33be70335f652a8d70f2bd32421d6ac2af781d667dad787d6aef4505a15d046579e46eebe757444cffca6d0610f0dd36a7ce57af969bd0c3f7006298ef406a25f689daf58f875d44d2423ebf195b503f11c37c506ea6abe50a463f7bb5e9b964604d832724de768513f6b38bf71715e1feea8a6e86797788d487146891564919da1372016ed8f08c7fcbff66a4a65a3d0fcd8e3daac6eba41f5d65ef2d8075364a9e78b3a273549f6eac4abb72e912e237990367e0d43e89945f8ac3907be5a6c662139485a50cb5ce3f0ba08586c39f6c515368ec3f91b72295f1b7a73a9df322ae9a45d363d6c616be3300083764cbdee31221f25a318f095feacb09f957c96db30fccca47a0215b576c3ed925a0bad05d6400abe318c11f36628c387a4ee38832182cd44b3cd48e5422c1f1e3b57218dfe72c611f5415127720e60f6e2400607e61841b76de1704bcbeb0daf1377ccb2253916de2b6d490bb71ba0a44fea2e94f2423d723934557d5905e01b2b80232a884e258d46dc92ea11e0818d0ece5b914f02049866e151801ab8c9aea155479b354dc91151fb9ba43277458f9760dd859faaa139e3b9ab36a1dbc36a93ef2c90598b20cb30ef3c4f23a2d6178b4d1da668fb328a25d84d30a132d9f2a6a988cbe2e5c2be01cb6db4b4725a50d6cdacf5fb083e7d650a25bec1407fbc047d26076c7596429a29606ad527e97ef0824ad6c1b05831a3e5b71c63a528918a3301cdd4061fc1fcce3da601961f2602a2b002ac8404125c2d52666263858a923e197efcda873c32d86897352e4f2264ad6a1b48acc0fe78ff55cb442cb2bb5fa2880810e1d00aa0247057fb80b7ed36cf9647af41b44ee4a63ee2d6f652526404572520a7d2d9dcde4e62df0c3be89f8471550594cdd16a51a9cacc58729c092c68506162fe65edc2314055d389f724ced189d826a546b5c4d08a43d977b3cf033de5760b71a7cc38ee5851592031aafb467a89b3b6c7ed67b15d44c48d6baedce3e95e08ec7c55038f3eba90ccb900895734f0fb7efe54961ce493369cc56416898a9bed7c2482871c15a7f1eb5ed17c33657fc31333539c2dfb59461af09e7049228113b5c9feea5a6e9959c18c51b19c90995afb9c76f2c0c820964cd7989c993a73925818a656c6a18dcd1a1e3782b2eae06dd5a41250ec2d1c203626ab9920c1673339eff04b1eb0cab85ef5909f571f9b83cdf21697c9f5cfa1c76e7bca955510e2126b3bb989a4ac21cf948f965e48bc363d2997437797b4f770e8b65", "node_privkey": "4444444444444444444444444444444444444444444444444444444444444444", - "next_blinding": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a" + "next_path_key": "03e09038ee76e50f444b19abf0a555e8697e035f62937168b80adf0931b31ce52a" }, { "alias": "Eve", "onion": "0002ef43c4dfe9aee14248c445406ac7980474ce106c504d9025f57963739130adfd06eb26201baee8866af2d1b7a7ab26595349dad002af0590193aaa8f400ab394f5994ec831aeeecb64421c566e3556cbdd7e7e50deb1fc49fd5e007308ab6494415514abff978899623f9b6065ca1e243bb78170118e8b8c8b53b750b59cc1ec017d167adbb3aabab7c2d84fbf94f5d827239f4c2b9d2c3cfe68fe5641f25e386202a4b6edff2a71e700229df7230c8ca31bd5588f04799e9640c9c20a47cba713f3cc5ad3202e14bb520880f2a8409d8e7835cae21b48a651c2d47fe6af785889ab98f1416f6e4ad67a66ae681e9a8828bad3f9b6890221c4a7ec80531d6b63eb30843f613ce644795bc8bcee60e8f7b36f3fd04de762f103c52efaf36a2f3bbbaac482d6271dc4180c10bcc076c04d06ea7fd8fb6a647e0e10523b05da2d89e4139fb55c2315cd01bdcbd57587fef8442d7ff5620630fd2d2e79739d90be811bf2cba60415d6cba2cea14ba1859f3122cd905c4e12e3e2a1ab6fab54b2ec40e434626e2d3c3195c02c82a8bd64d226c2328ac72ca12197d9908eaf54333717448ce6ed73adc0ac05e2ee1d735131d87918beb8995993dc8f63fe10f2c8eba2be7ab8bb44d9f78f59ef3e4c180bd75e4eef2381450c6f0480d543997305f1d07815993b5aca8d88d474966d9abec93bb069a16aa2da75b87f94576e01d08a17d3e0e3d0370f010733a7d7affb12cdf94c259a62607fce71003535c4727305de5ff7bba3840922844b3a45f62c29715fccf440517ef121450f6962396fba9b07036d085582405dcae6ee95964b66bc7c85b8d02d90091500db3cebf6de584f86b7b55335a8c9aa26381b00747f055cc458a2cadfccf9c29702bf941447beaca6583cca09492a57d4b03b2ca00dbaf41dfd6a9b249381626a7debe475735a7e39e77a363eccf14669046f656cc09ad448da8d8b545e6a604f46dc481786d09a94c63cf23f49ba367d2929466364dbce2a8ffce3dadf8f4cef8a56e1fefa1a3304a953fe83018e57d8a95694b02d994fea2630a9a3d5f1e2f6d6142d503ec4152871f7122d7e566a03261f554639e7a759e0e73846f71d5cace37d91336fc9ca9396bf64ca2cf45fa2db779b3b5c63b04f1c0c1fb79fdfcf5a82b0202df934ae1720a7ce1e047cbec3f82737b50168c974f4623cacce87e3f5bd5232caca7956d28ffedcf11ac5998662c5f6b13c6126584ca2e894d3fcbad4d130bbe22e88a135e0020cdd43853e0b3af3800e9544854d211e873cf68ab683578d501d69ec5dc7fce42ac436d58243880c1b88227b0681c6c9dd8a8ad0793202b15ab63b787b748e258da3e68d0e649fc4ac081a71de8adbc891c113d5f722686b6ac4ed9e3cc247bc4a4643416f480627e9de20f7307f434a499f5c6951c2e8b3ff51d455bf65ceb5ee3dee47b968ac2642e13d8a68f903b73627c2e75788fecca5836371a908eea4f1ea44db2315bc185f77e478efeaaa4da2da13fe7aeaa79ed1d04876a8b2b7b333c5de8c4c9a50274c2eb7b9bd2a3630c57173174781fc9785235f830cefa1c82080eaffdef257f18eedc9ddfd25a696a11a3dc56cd836be72f5f4a2cbb6316d5d3b1ad91a7ec7d877f28d2c29a5525b0b24362699281b0e3b48f38caf1085045fe9089f9e6fb29e4b47aa4cecf68c9bf72073469bd9beeea5e88bfe554cb6a81231149ba7fe7784c154fd8b0f9179ecdf1e9fd5c2939ec1ab16df9cbe9359101ebce933d4f65d3f66f87afaecfe9c046b52f4878b6c430329df7bd879fba8864fcbd9b782bf545734699b9b5a66b466dcedc0c9368803b5b0f1232950cef398ad3e057a5db964bd3e5c8a5717b30b41601a4f11ad63afe404cb6f1e8ea5fd7a8e085b65ca5136146febf4d47928dcc9a9e0", "node_privkey": "4545454545454545454545454545454545454545454545454545454545454545", - "next_blinding": "038fc6859a402b96ce4998c537c823d6ab94d1598fca02c788ba5dd79fbae83589" + "next_path_key": "038fc6859a402b96ce4998c537c823d6ab94d1598fca02c788ba5dd79fbae83589" } ] } diff --git a/bolt04/onion-error-test.json b/bolt04/onion-error-test.json index 7d416b4d7..ddb1edf7a 100644 --- a/bolt04/onion-error-test.json +++ b/bolt04/onion-error-test.json @@ -5,31 +5,31 @@ "failure_message": "2002", "hops": [ { - "realm": 0, + "version": 0, "pubkey": "02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619", "hop_shared_secret": "53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66", "ammag_key": "3761ba4d3e726d8abb16cba5950ee976b84937b61b7ad09e741724d7dee12eb5" }, { - "realm": 0, + "version": 0, "pubkey": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", "hop_shared_secret": "a6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae", "ammag_key": "59ee5867c5c151daa31e36ee42530f429c433836286e63744f2020b980302564" }, { - "realm": 0, + "version": 0, "pubkey": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007", "hop_shared_secret": "3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc", "ammag_key": "1bf08df8628d452141d56adfd1b25c1530d7921c23cecfc749ac03a9b694b0d3" }, { - "realm": 0, + "version": 0, "pubkey": "032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991", "hop_shared_secret": "21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d", "ammag_key": "cd9ac0e09064f039fa43a31dea05f5fe5f6443d40a98be4071af4a9d704be5ad" }, { - "realm": 0, + "version": 0, "pubkey": "02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145", "hop_shared_secret": "b5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328", "um_key": "4da7f2923edce6c2d85987d1d9fa6d88023e6c3a9c3d20f07d3b10b61a78d646", diff --git a/bolt04/route-blinding-test.json b/bolt04/route-blinding-test.json index c69cc72be..4dbfde321 100644 --- a/bolt04/route-blinding-test.json +++ b/bolt04/route-blinding-test.json @@ -34,12 +34,12 @@ "blinded_node_id": "03da173ad2aee2f701f17e59fbd16cb708906d69838a5f088e8123fb36e89a2c25" }, { - "comment": "Notice the next_blinding_override tlv in Carol's payload, indicating that Bob concatenated his route with another blinded route starting at Dave.", + "comment": "Notice the next_path_key_override tlv in Carol's payload, indicating that Bob concatenated his route with another blinded route starting at Dave.", "alias": "Carol", "node_id": "027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007", "tlvs": { "short_channel_id": "0x0x1105", - "next_blinding_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", + "next_path_key_override": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f", "payment_relay": { "cltv_expiry_delta": 48, "fee_proportional_millionths": 100, @@ -117,8 +117,8 @@ }, "route": { "comment": "This section contains the resulting blinded route, which can then be used inside onion messages or payments.", - "introduction_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", - "blinding": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", + "first_node_id": "0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c", + "first_path_key": "024d4b6cd1361032ca9bd2aeb9d900aa4d45d9ead80ac9423374c451a7254d0766", "hops": [ { "blinded_node_id": "03da173ad2aee2f701f17e59fbd16cb708906d69838a5f088e8123fb36e89a2c25",