Test channel reestablish during splice lifecycle #4079
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
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.
We may produce duplicate `FundingTransactionReadyForSigning` events if the user has processed an initial event but has not yet called back with `funding_transaction_signed` and a peer reconnection occurs. If the user also handles the duplicate events, any duplicate calls to `funding_transaction_signed` after an initial successful one would return an error. This doesn't make sense, as the API should remain idempotent, so we return early on any duplicate calls.
As per the spec requirement, this was already enforced throughout the happy case when a disconnection does not happen. If a disconnect would happen, we always naively cleared the flag without checking whether we did indeed exchange `tx_signatures`.
We only want to produce `tx_signatures` once we know that the monitor update (either the initial one for a dual-funded channel, or a `RenegotiatedFunding` one for a splice) has been persisted. If we haven't received the counterparty's `commitment_signed` yet, then the monitor update hasn't been created, leading us to pass the `!awaiting_monitor_update` condition and produce a holder `tx_signatures` message.
This test captures all the new spec requirements introduced for a splice to the channel reestablish flow.
|
👋 Thanks for assigning @jkczyz as a 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 includes a couple small bug fixes found along the way.