-
Notifications
You must be signed in to change notification settings - Fork 419
Test commitment broadcast during different stages of a splice #4068
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?
Test commitment broadcast during different stages of a splice #4068
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
👋 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. |
While we did consider the pending HTLCs when generating the signatures, we did not include them in the resulting `commitment_signed` message sent because we assumed it was only used within a dual-funding context where there are no pending HTLCs.
This ensures a valid commitment transaction is broadcast according to the different stages of a splice: 1. Negotiated but unconfirmed 2. Confirmed but not locked 3. Locked
When adding support for emitting these events in the channel monitor, we only covered the case where one of the splice transaction candidates confirmed. We also need to emit an event when none of them can confirm due to a commitment transaction confirming (and no longer under reorg risk) for the pre-splice funding.
527c78a
to
7456483
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files
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 @jkczyz! This PR has been waiting for your review. |
1 similar comment
🔔 1st Reminder Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review. |
🔔 2nd Reminder Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review. |
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.
Code changes LGTM, I'll leave @jkczyz to review the tests in more detail.
OnchainEvent::FundingSpendConfirmation { commitment_tx_to_counterparty_output, .. } => { | ||
self.funding_spend_confirmed = Some(entry.txid); | ||
self.confirmed_commitment_tx_counterparty_output = commitment_tx_to_counterparty_output; | ||
if self.alternative_funding_confirmed.is_none() && !self.pending_funding.is_empty() { |
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.
nit: && !self.pending_funding.is_empty()
not needed
OnchainEvent::FundingSpendConfirmation { commitment_tx_to_counterparty_output, .. } => { | ||
self.funding_spend_confirmed = Some(entry.txid); | ||
self.confirmed_commitment_tx_counterparty_output = commitment_tx_to_counterparty_output; | ||
if self.alternative_funding_confirmed.is_none() && !self.pending_funding.is_empty() { |
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.
When would we get this event when self.alternative_funding_confirmed
is Some
? Is there some re-org case that could cause this?
This also caught a bug where we weren't including signatures for pending HTLCs in the initial
commitment_signed
for the splice.Depends on #4054.