add option_pubkey_routing

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
 

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
 

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.