From e27f165b6a3725c254b696a0f22c92477a952215 Mon Sep 17 00:00:00 2001 From: Joost Jager Date: Tue, 3 Nov 2020 14:51:51 +0100 Subject: [PATCH] add option_pubkey_routing --- 04-onion-routing.md | 16 ++++++++++++++-- 09-features.md | 1 + 11-payment-encoding.md | 6 ++++-- 3 files changed, 19 insertions(+), 4 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index 4cb24080f..c57e61278 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -263,6 +263,9 @@ It is formatted according to the Type-Length-Value format defined in [BOLT #1](0 2. data: * [`32*byte`:`payment_secret`] * [`tu64`:`total_msat`] + 1. type: 10 (`pub_key`) + 2. data: + * [`33*byte`:`pub_key`] ### Requirements @@ -272,10 +275,16 @@ The writer: - For every node: - MUST include `amt_to_forward` and `outgoing_cltv_value`. - For every non-final node: - - MUST include `short_channel_id` + - If `option_pubkey_routing`: + - MUST NOT include `short_channel_id` + - MUST include `pub_key` + - If not `option_pubkey_routing`: + - MUST include `short_channel_id` + - MUST NOT include `pub_key` - MUST NOT include `payment_data` - For the final node: - MUST NOT include `short_channel_id` + - MUST NOT include `pub_key` - if the recipient provided `payment_secret`: - MUST include `payment_data` - MUST set `payment_secret` to the one provided @@ -380,6 +389,8 @@ nodes A and B, the HTLC can be forwarded across any channel connecting A and B. Failure to adhere will result in the receiver being unable to decrypt the next hop in the onion packet. +If `pub_key` is specified, forwarding can only be non-strict. + ### Rationale In the event that two peers have multiple channels, the downstream node will be @@ -399,7 +410,8 @@ A and B. Non-strict forwarding allows nodes to make use of private channels connecting them to the receiving node, even if the channel is not known in the public -channel graph. +channel graph. When `option_pubkey_routing` is used, no channel point information +needs to be leaked through invoice route hints at all. ### Recommendation diff --git a/09-features.md b/09-features.md index ea37b8b5e..9eb7f0292 100644 --- a/09-features.md +++ b/09-features.md @@ -40,6 +40,7 @@ The Context column decodes as follows: | 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) | | 20/21 | `option_anchor_outputs` | Anchor outputs | IN | `option_static_remotekey` | [BOLT #3](03-transactions.md) | | 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful]| +| 26/27 | `option_pubkey_routing` | Public key routing | IN9 | `var_onion_optin` | [BOLT #4](04-onion-routing.md#tlv-payload-format) | ## Requirements diff --git a/11-payment-encoding.md b/11-payment-encoding.md index 40d16a6d4..ab13b4039 100644 --- a/11-payment-encoding.md +++ b/11-payment-encoding.md @@ -187,8 +187,10 @@ A writer: - MUST include at least one `r` field. - `r` field MUST contain one or more ordered entries, indicating the forward route from a public node to the final destination. - - Note: for each entry, the `pubkey` is the node ID of the start of the channel; - `short_channel_id` is the short channel ID field to identify the channel; and + - Note: for each entry, the `pubkey` is the node ID of the start of the channel. + `short_channel_id` is the short channel ID field to identify the channel. If the routing node + supports `option_pubkey_routing`, `short_channel_id` may be set to all zeroes to + keep the channel point information private. `fee_base_msat`, `fee_proportional_millionths`, and `cltv_expiry_delta` are as specified in [BOLT #7](07-routing-gossip.md#the-channel_update-message). - MAY include more than one `r` field to provide multiple routing options.