mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-22 14:22:46 +01:00
Code Issues Projects Releases Wiki Activity

BOLT2: rephrase cltv_expiry_delta text about accepting HTLCs

Browse source 
Saying "the risk is only to the node *accepting* the HTLC" is confusing
because merely accepting an HTLC is risk-free.  The risk comes from
accepting *responsibility to route the payment*, i.e. offering an HTLC
of your own in the next channel on the path, where a too-small
difference in the HTLC values could end up with you cheated out of a
payment.

This revised paragraph hopefully makes that clearer.
This commit is contained in:
David A. Harding 2019-04-02 08:59:42 -04:00 • committed by Christian Decker
parent da71867c84
commit d42b4e2ab6
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
02-peer-protocol.md
View file

@ -670,10 +670,10 @@ the forwarding case (B). `min_final_cltv_expiry` is the minimum difference
between HTLC CLTV timeout and the current block height, for the
terminal case (C).
Note that if this value is too low for a channel, the risk is only to
the node *accepting* the HTLC, not the node offering it. For this
reason, the `cltv_expiry_delta` for the *outgoing* channel is used as
the delta across a node.
Note that a node is at risk if it accepts an HTLC in one channel and
offers an HTLC in another channel with too small of a difference between
the CLTV timeouts. For this reason, the `cltv_expiry_delta` for the
*outgoing* channel is used as the delta across a node.
The worst-case number of blocks between outgoing and
incoming HTLC resolution can be derived, given a few assumptions: