-
Notifications
You must be signed in to change notification settings - Fork 419
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
base: main
Are you sure you want to change the base?
Broadcast holder commitment for currently confirmed funding #3939
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
a783444
to
a8ae4b7
Compare
Codecov Report❌ Patch coverage is
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
👋 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. |
a8ae4b7
to
86b53fa
Compare
86b53fa
to
48629c7
Compare
48629c7
to
60d97d0
Compare
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
582ad71
to
511fdc8
Compare
🔔 3rd Reminder Hey @jkczyz! This PR has been waiting for your review. |
@@ -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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(..) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.
511fdc8
to
9051703
Compare
A splice's
FundingScope
can only be promoted once aChannelMonitorUpdateStep::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 currentFundingScope
may not reflect the latest confirmed state in the chain. Before making a holder commitment broadcast, we must check whichFundingScope
is currently confirmed to ensure that it can propagate throughout the network.