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

BOLT7: Add shadow route extension in the recommendations

Browse Source 
This is a recommendation to fuzz the CLTV on the HTLCs such that nodes
along the route have a harder time identifying the intended
recipient. We can either add a random offset or we can start a random
walk from the intended recipient and create a shadow route extension.

Closes #185
This commit is contained in:
Christian Decker 2017-07-11 12:26:26 +02:00
parent 964527158e
commit 170cb318a1
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
07-routing-gossip.md
View File

@ -413,6 +413,12 @@ need to be considered: the `cltv_expiry_delta` contributes to the time that fund
will be unavailable on worst-case failure. The tradeoff between these
two is unclear, as it depends on the reliability of nodes.
If a route is computed by simply routing to the intended recipient, summing up the `cltv_expiry_delta`s, then nodes along the route may guess their position in the route.
Knowing the CLTV of the HTLC and the surrounding topology with the `cltv_expiry_delta`s gives an attacker a way to guess the intended recipient.
Therefore it is highly suggested to add a random offset to the CLTV that the intended recipient will receive, bumping all CLTVs along the route.
In order to create a plausible offset the sender MAY start a limited random walk on the graph, starting from the intended recipient, sum the `cltv_expiry_delta`s, and then use the sum as the offset.
This effectively creates a _shadow route extension_ to the actual route, providing better protection against this kind of attack than simply picking a random offset.
Other more advanced considerations involve diversity of routes to
avoid single points of failure and detection, and channel balance
of local channels.