Skip to content

Broadcast holder commitment for currently confirmed funding #3939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

wpaulino
Copy link
Contributor

@wpaulino wpaulino commented Jul 17, 2025

A splice's FundingScope can only be promoted once a ChannelMonitorUpdateStep::RenegotiatedFundingLocked is applied, or if the monitor is no longer accepting updates, once the splice transaction is no longer under reorg risk. Because of this, our current FundingScope may not reflect the latest confirmed state in the chain. Before making a holder commitment broadcast, we must check which FundingScope is currently confirmed to ensure that it can propagate throughout the network.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jul 17, 2025

👋 Thanks for assigning @TheBlueMatt 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.

@wpaulino wpaulino removed the request for review from joostjager July 17, 2025 21:00
@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch from a783444 to a8ae4b7 Compare July 18, 2025 22:23
@wpaulino wpaulino requested a review from TheBlueMatt July 18, 2025 22:23
Copy link

codecov bot commented Jul 18, 2025

Codecov Report

❌ Patch coverage is 47.20812% with 104 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.84%. Comparing base (ecce268) to head (9051703).

Files with missing lines Patch % Lines
lightning/src/chain/channelmonitor.rs 43.40% 92 Missing and 11 partials ⚠️
lightning/src/chain/onchaintx.rs 93.33% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3939      +/-   ##
==========================================
- Coverage   88.93%   88.84%   -0.10%     
==========================================
  Files         174      174              
  Lines      123842   123983     +141     
  Branches   123842   123983     +141     
==========================================
+ Hits       110142   110150       +8     
- Misses      11254    11373     +119     
- Partials     2446     2460      +14     
Flag Coverage Δ
fuzzing 22.57% <21.31%> (-0.04%) ⬇️
tests 88.67% <47.20%> (-0.10%) ⬇️

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.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @TheBlueMatt! 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.

@ldk-reviews-bot
Copy link

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch from a8ae4b7 to 86b53fa Compare July 22, 2025 16:39
@wpaulino wpaulino requested a review from TheBlueMatt July 22, 2025 16:40
@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch from 86b53fa to 48629c7 Compare July 22, 2025 23:15
@jkczyz jkczyz self-requested a review July 23, 2025 18:18
@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch from 48629c7 to 60d97d0 Compare July 24, 2025 00:10
@wpaulino wpaulino requested a review from TheBlueMatt July 24, 2025 00:11
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @jkczyz! 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.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @jkczyz! 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.

@wpaulino wpaulino requested a review from TheBlueMatt July 29, 2025 01:09
@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch 3 times, most recently from 582ad71 to 511fdc8 Compare July 29, 2025 19:39
@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @jkczyz! 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.

@@ -4627,7 +4698,8 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
is_holder_tx = true;
log_info!(logger, "Got broadcast of latest holder commitment tx {}, searching for available HTLCs to claim", commitment_txid);
let holder_commitment_tx = &self.funding.current_holder_commitment_tx;
let res = self.get_broadcasted_holder_claims(holder_commitment_tx, height);
let res =
self.get_broadcasted_holder_claims(&self.funding, holder_commitment_tx, height);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't these (and the above reference to self.funding in the if) need to look at the funding confirmed? If we first confirm an alt funding, then close the channel, we will want to check against a commitment tx spending the new funding.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those changes are coming in a separate PR.

// We've just seen the counterparty commitment confirm, which conflicts
// with our holder commitment, so make sure we no longer attempt to
// broadcast it.
should_broadcast_commitment = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't this move out of the else? If we see a holder commitment tx confirm in the above case we'll call check_spend_holder_transaction which will build the required spends of the commitment tx and we don't need to broadcast manually either (and if the thing that confirmed is our previous (unrevoked) commitment tx we'll be trying to double-spend).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I hadn't considered a watchtower being able to broadcast as well.

if !retain && matches!(entry.event, OnchainEvent::AlternativeFundingConfirmation {})
&& self.holder_tx_signed
{
queue_new_commitment_claims = true;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't we need to queue new claims even if we've broadcasted without a AlternativeFundingConfirmation? I think in the case that (a) a new funding confirms, then (b) the channel closes (at which point we won't have an AlternativeFundingConfirmation because it only gets inserted when the funding confirms if we're closed then), then (c) we get a reorg of the new funding we need to broadcast but we wouldn't here.

Same in transaction_unconfirmed, and it might be nice to DRY that code up a bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, this is something I forgot to change after reworking AlternativeFundingConfirmation.

//- htlc update there as failure-trigger tx (revoked commitment tx, non-revoked commitment tx, HTLC-timeout tx) has been disconnected
//- maturing spendable output has transaction paying us has been disconnected
self.onchain_events_awaiting_threshold_conf.retain(|ref entry| entry.height < height);

let bounded_fee_estimator = LowerBoundedFeeEstimator::new(fee_estimator);
let conf_target = self.closure_conf_target();
self.onchain_tx_handler.block_disconnected(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't this happen after we call self.cancel_prev_commitment_claims? That way we aren't RBF bumping spends of something that doesn't exist (though its not entirely clear to me that its an issue, but easier to avoid). Same in transactions_unconfirmed and might be nice to DRY these up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, but I don't see a good way of DRYing this up very much.

debug_assert!(self.alternative_funding_confirmed.is_none());
self
.pending_funding
.drain(..)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks like it needs to handle multiple incomplete 0conf fundings too, though - we can accept one 0conf splice then another before either confirm, or accept another after the first only has 1 conf. We'd need to handle that here by only dropping some fundings...

I kinda feel like we should just drop the last commit and do it later, rather than trying to support it right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah right, the key aspect here is that the zero conf splices chain upon one another, unlike RBFs.

wpaulino added 2 commits July 30, 2025 11:27
Whether it's a splice, or a dual-funded RBF, we need to know which
funding transaction out of all of the negotiated ones is currently
confirmed in case we need to broadcast the holder commitment.
A `FundingScope` can only be promoted once a
`ChannelMonitorUpdateStep::RenegotiatedFundingLocked` is applied, or if
the monitor is no longer accepting updates, once the renegotiated
funding transaction is no longer under reorg risk. Because of this, our
current `FundingScope` may not reflect the latest confirmed state in the
chain. Before making a holder commitment broadcast, we must check which
`FundingScope` is currently confirmed to ensure that it can propogate
throughout the network.
@wpaulino wpaulino force-pushed the splice-funding-commitment-broadcast branch from 511fdc8 to 9051703 Compare July 30, 2025 18:27
@wpaulino wpaulino requested a review from TheBlueMatt July 30, 2025 18:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants