You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit clarifies some parts of the code on which we regularly have
questions during pull requests.
We also add a test for an edge case in shutdown that was correctly handled,
but not properly tested, to ensure non-regression.
Copy file name to clipboardExpand all lines: eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala
+4-3
Original file line number
Diff line number
Diff line change
@@ -267,9 +267,10 @@ object Commitments {
267
267
* @return either Left(failure, error message) where failure is a failure message (see BOLT #4 and the Failure Message class) or Right(new commitments, updateAddHtlc)
// our counterparty needs a reasonable amount of time to pull the funds from downstream before we can get refunded (see BOLT 2 and BOLT 11 for a calculation and rationale)
271
-
valminExpiry=CltvExpiry(blockHeight)
272
-
if (cmd.cltvExpiry <= minExpiry) {
270
+
// we must ensure we're not relaying htlcs that are already expired, otherwise the downstream channel will instantly close
271
+
// NB: we add a 3 blocks safety to reduce the probability of running into this when our bitcoin node is slightly outdated
272
+
valminExpiry=CltvExpiry(blockHeight +3)
273
+
if (cmd.cltvExpiry < minExpiry) {
273
274
returnLeft(ExpiryTooSmall(commitments.channelId, minimum = minExpiry, actual = cmd.cltvExpiry, blockCount = blockHeight))
274
275
}
275
276
// we don't want to use too high a refund timeout, because our funds will be locked during that time if the payment is never fulfilled
0 commit comments