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

BOLT 4: move Route Blinding section up a level, and put blinded_path type there.

Browse Source 
It's currently buried in the onion message section, but it applies to payments too.

We now have a separate sub-section for the encrypted_data_tlv definition.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2024-07-17 10:41:35 +09:30
parent 3fffab3b88
commit 14ebb445e6
1 changed files with 60 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
04-onion-routing.md
View File

@ -51,6 +51,7 @@ A node:
* [Payload Format](#payload-format)
* [Basic Multi-Part Payments](#basic-multi-part-payments)
* [Route Blinding](#route-blinding)
* [Inside encrypted_recipient_data: encrypted_data_tlv](Inside-encrypted_recipient_data-encrypted_data_tlv)
* [Accepting and Forwarding a Payment](#accepting-and-forwarding-a-payment)
* [Payload for the Last Node](#payload-for-the-last-node)
* [Non-strict Forwarding](#non-strict-forwarding)
@ -435,7 +436,20 @@ otherwise meets the amount criterion (eg. some other failure, or
invoice timeout), however if it were to fulfill only some of them,
intermediary nodes could simply claim the remaining ones.
### Route Blinding
## Route Blinding
1. subtype: `blinded_path`
2. data:
* [`point`:`first_node_id`]
* [`point`:`first_path_key`]
* [`byte`:`num_hops`]
* [`num_hops*onionmsg_hop`:`path`]
1. subtype: `onionmsg_hop`
2. data:
* [`point`:`blinded_node_id`]
* [`u16`:`enclen`]
* [`enclen*byte`:`encrypted_recipient_data`]
Nodes receiving onion packets may hide their identity from senders by
"blinding" an arbitrary amount of hops at the end of an onion path.
@ -460,40 +474,7 @@ the introduction point, set `next_path_key_override` inside the
`encrypted_data_tlv` on the hop prior to the introduction point to the
initial blinding point, and have it sent to the introduction node.
The `encrypted_data` is a TLV stream, encrypted for a given blinded node, that
may contain the following TLV fields:
1. `tlv_stream`: `encrypted_data_tlv`
2. types:
1. type: 1 (`padding`)
2. data:
* [`...*byte`:`padding`]
1. type: 2 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
1. type: 4 (`next_node_id`)
2. data:
* [`point`:`node_id`]
1. type: 6 (`path_id`)
2. data:
* [`...*byte`:`data`]
1. type: 8 (`next_path_key_override`)
2. data:
* [`point`:`path_key`]
1. type: 10 (`payment_relay`)
2. data:
* [`u16`:`cltv_expiry_delta`]
* [`u32`:`fee_proportional_millionths`]
* [`tu32`:`fee_base_msat`]
1. type: 12 (`payment_constraints`)
2. data:
* [`u32`:`max_cltv_expiry`]
* [`tu64`:`htlc_minimum_msat`]
1. type: 14 (`allowed_features`)
2. data:
* [`...*byte`:`features`]
#### Requirements
### Requirements
A recipient $`N_r`$ creating a blinded route $`N_0 \rightarrow N_1 \rightarrow ... \rightarrow N_r`$ to itself:
@ -552,7 +533,7 @@ The final recipient:
- MUST ignore the message if the `path_id` does not match the blinded route it
created
#### Rationale
### Rationale
Route blinding is a lightweight technique to provide recipient anonymity.
It's more flexible than rendezvous routing because it simply replaces the public
@ -599,6 +580,48 @@ set `payment_constraints.max_cltv_expiry` to restrict the lifetime of a blinded
route and reduce the risk that an intermediate node updates its fees and rejects
payments (which could be used to unblind nodes inside the route).
### Inside `encrypted_recipient_data`: `encrypted_data_tlv`
The `encrypted_data` is a TLV stream, encrypted for a given blinded node, that
may contain the following TLV fields:
1. `tlv_stream`: `encrypted_data_tlv`
2. types:
1. type: 1 (`padding`)
2. data:
* [`...*byte`:`padding`]
1. type: 2 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
1. type: 4 (`next_node_id`)
2. data:
* [`point`:`node_id`]
1. type: 6 (`path_id`)
2. data:
* [`...*byte`:`data`]
1. type: 8 (`next_path_key_override`)
2. data:
* [`point`:`path_key`]
1. type: 10 (`payment_relay`)
2. data:
* [`u16`:`cltv_expiry_delta`]
* [`u32`:`fee_proportional_millionths`]
* [`tu32`:`fee_base_msat`]
1. type: 12 (`payment_constraints`)
2. data:
* [`u32`:`max_cltv_expiry`]
* [`tu64`:`htlc_minimum_msat`]
1. type: 14 (`allowed_features`)
2. data:
* [`...*byte`:`features`]
#### Rationale
Encrypted recipient data is created by the final recipient to give to the
payer, containing instructions for the node on how to handle the message. It's used
in both payment onions and onion messages onions. See [Route Blinding](#route-blinding).
# Accepting and Forwarding a Payment
Once a node has decoded the payload it either accepts the payment locally, or forwards it to the peer indicated as the next hop in the payload.
@ -1475,19 +1498,6 @@ even, of course!).
2. data:
* [`...*byte`:`encrypted_recipient_data`]
1. subtype: `blinded_path`
2. data:
* [`point`:`first_node_id`]
* [`point`:`first_path_key`]
* [`byte`:`num_hops`]
* [`num_hops*onionmsg_hop`:`path`]
1. subtype: `onionmsg_hop`
2. data:
* [`point`:`blinded_node_id`]
* [`u16`:`enclen`]
* [`enclen*byte`:`encrypted_recipient_data`]
#### Requirements
The creator of `encrypted_recipient_data` (usually, the recipient of the onion):