From d42b4e2ab69c625f56e8daa0dae48c917098ea1f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Tue, 2 Apr 2019 08:59:42 -0400 Subject: [PATCH] BOLT2: rephrase cltv_expiry_delta text about accepting HTLCs 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. --- 02-peer-protocol.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index e377f3f..1d9f683 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -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: