From 104e7f4b370fc5e43a8e99cce2afc48f0e5932a1 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 ed38d246f..8ede3a53a 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -262,6 +262,9 @@ This is a more flexible format, which avoids the redundant `short_channel_id` fi 2. data: * [`32*byte`:`payment_secret`] * [`tu64`:`total_msat`] + 1. type: 10 (`pub_key`) + 2. data: + * [`33*byte`:`pub_key`] ### Requirements @@ -271,10 +274,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 @@ -379,6 +388,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 @@ -398,7 +409,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 e0b1b5d15..2c90530ae 100644 --- a/09-features.md +++ b/09-features.md @@ -39,6 +39,7 @@ The Context column decodes as follows: | 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] | | 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_pubkey_routing` | Public key routing | IN | `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 c3ddd2f1f..43eea5b10 100644 --- a/11-payment-encoding.md +++ b/11-payment-encoding.md @@ -186,8 +186,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.