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: error if the final outgoing_ctlv_value is unexpected.

Browse Source 
Not doing this check means an inconsistency in behaviour, which could
theoretically allow a hop to probe: if the next hop is the last, it might
not care, but if it's not it will return an error.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-03-30 14:51:22 +10:30 committed by Olaoluwa Osuntokun
parent 809ad65ea0
commit 1a496d1941
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
04-onion-routing.md
View File

@ -174,9 +174,13 @@ Field Description:
Inclusion of this field allows a node to both authenticate the information
specified by the original sender and the paramaters of the HTLC forwarded,
and ensure the original sender is using the current `cltv-expiry-delta` value.
If there is no next hop, `cltv-expiry-delta` is zero.
If the values don't correspond, then the HTLC should be failed+rejected as
this indicates the incoming node has tampered with the intended HTLC
values, or the origin has an obsolete `cltv-expiry-delta` value.
The node MUST be consistent in responding to an unexpected
`outgoing_cltv_value` whether it is the final hop or not, to avoid
leaking that information.
Nodes forwarding HTLC's MUST construct the outgoing HTLC as specified within
@ -603,6 +607,13 @@ If the `cltv-expiry` is too low, the final node MUST fail the HTLC:
1. type: 17 (`final_expiry_too_soon`)
If the `outgoing_cltv_value` does not match the `ctlv-expiry` of the
HTLC at the final hop:
1. type: 18 (`final_incorrect_cltv_expiry`)
2. data:
* [4:cltv-expiry]
### Receiving Failure Codes
A node MUST ignore any extra bytes in `failuremsg`.