lightningd: lock in the mined RBF inflight, not the latest one - #9374
Open
ksedgwic wants to merge 2 commits into
Open
lightningd: lock in the mined RBF inflight, not the latest one#9374ksedgwic wants to merge 2 commits into
ksedgwic wants to merge 2 commits into
Conversation
When a block containing a non-tip inflight's funding tx was processed, dual_funding_found set the channel's scid right away, but the channel's funding fields were only updated to the mined inflight once block catch-up completed (opening_depth_cb, via the blockdepth watches). A peer reconnecting inside that window reestablished against channel_current_inflight() -- the latest inflight -- with the scid already set, so dualopend sent channel_ready and the channel locked in a funding tx that was never mined: its last_tx spends a nonexistent outpoint, and the two peers disagree about the channel's funding. Record the mined inflight on the channel as soon as its block is seen, and make peer_restart_dualopend reestablish with the inflight matching the recorded funding when the scid is already set. Fixes: ElementsProject#9373 Changelog-Fixed: Protocol: dual-funding: reconnecting during block catch-up could lock in a channel with the latest RBF candidate rather than the one that was actually mined.
test_rbf_non_last_mined occasionally fails in CI when the peer reconnects while the node is still catching up on blocks (ElementsProject#9373). Reproduce that window deterministically: stall the fetch of the block after the funding block via the bitcoind proxy, so the node has seen the funding confirm but cannot finish catching up, then reconnect. Without the previous commit, this locks in the never-mined latest inflight on every run.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fixes #9373.
If a non-tip RBF inflight is the one that gets mined, and the peer reconnects while we are still catching up on blocks, we locked the channel in with the tip inflight -- which was never mined. Full sequence in the issue.
Two commits:
lightningd: record the mined inflight on the channel as soon as its block is processed (dual_funding_found), rather than waiting for catch-up to finish; and make peer_restart_dualopend reestablish with the inflight matching the recorded funding when the scid is already set, rather than assuming the latest one.
pytest: deterministic regression test. It stalls the block fetch after the funding block via the bitcoind proxy, holding the catch-up window open, then reconnects. Without the previous commit this locks in the never-mined tip inflight on every run; with it, the mined one.