mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

Allow using short_channel_id in onion messages

Browse Source 
Offers may contain blinded paths to allow for greater recipient privacy.
However, they come at a cost of increased QR code size as each hop
requires a 33-byte `point` for the `next_node_id`. Allow using
`short_channel_id` instead, which only requires 8 bytes.

Still allow for use of `next_node_id` for cases where the blinded path
may not involve channel counterparties or for long-lived offers, which
may outlive the given channels.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Jeffrey Czyz 2024-09-24 18:00:51 +09:30 committed by Rusty Russell
parent b26da74abf
commit 86ba089de7
1 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
04-onion-routing.md
View File

@ -245,8 +245,8 @@ leaking its position in the route.
The creator of `encrypted_recipient_data` (usually, the recipient of payment):
- MUST create `encrypted_data_tlv` for each node in the blinded route (including itself).
- MUST include `encrypted_data_tlv.short_channel_id` and `encrypted_data_tlv.payment_relay` for each non-final node.
- MUST NOT include `encrypted_data_tlv.next_node_id`.
- MUST include `encrypted_data_tlv.payment_relay` for each non-final node.
- MUST include exactly one of `encrypted_data_tlv.short_channel_id` or `encrypted_data_tlv.next_node_id` for each non-final node.
- MUST set `encrypted_data_tlv.payment_constraints` for each non-final node and MAY set it for the final node:
- `max_cltv_expiry` to the largest block height at which the route is allowed to be used, starting
from the final node's chosen `max_cltv_expiry` height at which the route should expire, adding
@ -1516,8 +1516,8 @@ even, of course!).
The creator of `encrypted_recipient_data` (usually, the recipient of the onion):
- MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding).
- MUST NOT include `short_channel_id`, `payment_relay` or `payment_constraints` in any `encrypted_data_tlv`
- MUST include `encrypted_data_tlv.next_node_id` for each non-final node.
- MUST NOT include `payment_relay` or `payment_constraints` in any `encrypted_data_tlv`
- MUST include either `next_node_id` or `short_channel_id` in the `encrypted_data_tlv` for each non-final node.
- MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding).
The writer:
@ -1558,7 +1558,13 @@ The reader:
- if the `encrypted_data_tlv` contains `path_id`:
- MUST ignore the message.
- otherwise:
- SHOULD forward the message using `onion_message` to the next peer indicated by `next_node_id`.
- if `next_node_id` is present:
- the *next peer* is the peer with that node id.
- otherwise, if `short_channel_id` is present and corresponds to an announced short_channel_id or a local alias for a channel:
- the *next peer* is the peer at the other end of that channel.
- otherwise:
- MUST ignore the message.
- SHOULD forward the message using `onion_message` to the *next peer*.
- if it forwards the message:
- 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):