Consider currently confirmed FundingScope when claiming commitments #3980
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
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.
Once a commitment transaction confirms, we may have outputs to claim. To determine whom the commitment transaction belongs to, we generally compare its `txid` against what we know be ours and the counterparty's. This, however, relies on being able to match on the expected `FundingScope`, such that we can produce the necessary output claims. Since a commitment transaction confirming implies that the funding transaction it spends has also confirmed, we rely on `alternative_funding_confirmed` to obtain the corresponding `FundingScope`.
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3980 +/- ##
==========================================
- Coverage 88.93% 88.79% -0.14%
==========================================
Files 174 174
Lines 123842 124445 +603
Branches 123842 124445 +603
==========================================
+ Hits 110142 110507 +365
- Misses 11254 11437 +183
- Partials 2446 2501 +55
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:
|
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.
Once a commitment transaction confirms, we may have outputs to claim. To determine whom the commitment transaction belongs to, we generally compare its
txidagainst what we know be ours and the counterparty's. This, however, relies on being able to match on the expectedFundingScope, such that we can produce the necessary output claims. Since a commitment transaction confirming implies that the funding transaction it spends has also confirmed, we rely onalternative_funding_confirmedto obtain the correspondingFundingScope.Depends on #3939.