Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Public key-based routing (Feature **NEEDS NUMBER***) #814

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Public key-based routing (Feature **NEEDS NUMBER***) #814

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 14 additions & 2 deletions 04-onion-routing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about outgoing_node_id?
I already have added this field in the trampoline proposal (I believe also with TLV type 10) so I'm interested in getting it spec-ed anyway :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that it is a good idea to have two unapproved prs reference each other. Suppose this PR would be approved first, then renaming the field is easy enough and won't change the wire protocol.

2. data:
* [`33*byte`:`pub_key`]

### Requirements

Expand All @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand Down
1 change: 1 addition & 0 deletions 09-features.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
6 changes: 4 additions & 2 deletions 11-payment-encoding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down