Cleaner handling of HTLC settlement during force-close#3090
Merged
Conversation
t-bast
force-pushed
the
refactor-htlc-settlement-during-force-close
branch
from
75a7e9e to
b228d9d
Compare
t-bast
force-pushed
the
refactor-htlc-settlement-during-force-close
branch
2 times, most recently
from
d672691 to
a33fb78
Compare
When an HTLC settles downstream while the upstream channel is closing, this allows us to either publish HTLC-success transactions for which we were missing the preimage (if the downstream HTLC was fulfilled) or stop watching the HTLC output (if the downstream HTLC was failed). We previously re-computed every closing transaction in that case, which was confusing and useless. We now explicitly handle those two cases and only republish the HTLC-success transactions that become available, if any. We also change the default feerate used for `claim-htlc-txs`: we used a high feerate in the channel actor, which meant we would skip small HTLCs that weren't economical to spend at that high feerate. But the feerate is actually set inside the tx-publisher actor based on the HTLC expiry, which may happen many blocks after the beginning of the force-close, in which case the feerate may have changed a lot. We now use the minimum feerate in the channel actor to ensure we don't skip HTLCs and let the tx-publisher actor handle RBF.
This is something we should have added a long time ago to help the closing tests be more readable. Better late than never!
t-bast
force-pushed
the
refactor-htlc-settlement-during-force-close
branch
from
a33fb78 to
1f9fe78
Compare
sstone
approved these changes
Jun 2, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an HTLC settles downstream while the upstream channel is closing, this allows us to either publish HTLC-success transactions for which we were missing the preimage (if the downstream HTLC was fulfilled) or stop watching the HTLC output (if the downstream HTLC was failed).
We previously re-computed every closing transaction in that case, which was confusing and useless (and also made the tests very verbose, because we had to ignore all the transactions and watches that were duplicates). We now explicitly handle those two cases and only republish the HTLC-success transactions that become available, if any.
We also change the default feerate used for
claim-htlc-txs: we used a high feerate in the channel actor, which meant we would skip small HTLCs that weren't economical to spend at that high feerate. But the feerate is actually set inside the tx-publisher actor based on the HTLC expiry, which may happen many blocks after the beginning of the force-close, in which case the feerate may have changed a lot. We now use the minimum feerate in the channel actor to ensure we don't skip HTLCs and let the tx-publisher actor handle RBF.