Skip to content

Conversation

TheBlueMatt
Copy link
Collaborator

While nodes are generally supposed to validate commitment transactions after the commitent_signed and not while HTLCs are being added/removed, we don't. This can make a commitment update where we use HTLC balance claimed with a fulfill to send new HTLCs, which is perfectly valid, being rejected. While we shouldn't currently generate any such commitments, we might want to in the future, and on the off-chance that we do, or where such a commitment would result in a dust threshold overrun, its always safter to add new HTLCs to a commitment only after we've removed any HTLCs we're going to remove, which we do here.

While nodes are generally supposed to validate commitment
transactions after the `commitent_signed` and not while HTLCs are
being added/removed, we don't. This can make a commitment update
where we use HTLC balance claimed with a fulfill to send new HTLCs,
which is perfectly valid, being rejected. While we shouldn't
currently generate any such commitments, we might want to in the
future, and on the off-chance that we do, or where such a
commitment would result in a dust threshold overrun, its always
safter to add new HTLCs to a commitment only after we've removed
any HTLCs we're going to remove, which we do here.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 18, 2025

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Copy link

codecov bot commented Sep 18, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.61%. Comparing base (07bf08b) to head (ccb0443).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4086   +/-   ##
=======================================
  Coverage   88.60%   88.61%           
=======================================
  Files         176      176           
  Lines      132086   132070   -16     
  Branches   132086   132070   -16     
=======================================
- Hits       117041   117032    -9     
+ Misses      12376    12368    -8     
- Partials     2669     2670    +1     
Flag Coverage Δ
fuzzing 21.94% <100.00%> (+0.37%) ⬆️
tests 88.45% <0.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@@ -3065,6 +3062,9 @@ where
for msg in update_fail_malformed_htlcs {
self.enqueue_message(&mut *peer, msg);
}
for msg in update_add_htlcs {
self.enqueue_message(&mut *peer, msg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't verified this, but for this to work I assume we would have to consider the balance of those already-claimed-but-not-yet-committed HTLCs as part of our sendable balance when we attempt to send the new HTLC (via send_htlc) in the first place, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For us to take advantage of it, yes. But there's also a possibility we hit some non-spec limit a peer has, eg a dust exposure limit, which this marginally reduces the chance of as well.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tankyleo! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants