Test commitment broadcast during different stages of a splice #4068
Conversation
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
This commit addresses an overlap of state between `InteractiveTxSigningSession` and `ChannelState::FundingNegotiated`. The signing session already tracks whether both holder and counterparty `tx_signatures` have been produced, so tracking the state duplicatively at the `ChannelState` level is unnecessary.
Once a channel open has become locked (i.e., we've entered `ChannelState::ChannelReady`), the channel is intended to remain within this state for the rest of its lifetime until shutdown. Previously, we had assumed a channel being spliced would go through the `ChannelState` lifecycle again starting from `NegotiatingFunding` but skipping `AwaitingChannelReady`. This inconsistency departs from what we strive to achieve with `ChannelState` and also makes the state of a channel harder to reason about. This commit ensures a channel undergoing a splice remains in `ChannelReady`, clearing the quiescent flag once the negotiation is complete. Dual funding is unaffected by this change as the channel is being opened and we want to maintain the same `ChannelState` lifecycle.
We plan to reuse it for dual-funding/splicing, and those require standard SegWit inputs only.
This guarantees we get a unique txid when calling `provide_anchor_reserves` successively as we're immediately mining (and therefore advancing the chain) the transaction after creating it.
This adds a new test for both splice-in and splice-out in favor of maintaining the existing test. Helpers have been added to DRY up a lot of the logic necessary for driving the splice state machine forward.
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
|
👋 Thanks for assigning @jkczyz as a reviewer! |
jkczyz
reviewed
Sep 12, 2025
Comment on lines
+6189
to
+6192
| debug_assert_eq!( | ||
| htlc_signatures.is_empty(), | ||
| self.channel_state.is_interactive_signing() | ||
| ); |
There was a problem hiding this comment.
This is causing test_splice_in and test_splice_out to fail.
|
👋 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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This also caught a bug where we weren't including signatures for pending HTLCs in the initial
commitment_signedfor the splice.Depends on #4054.