Broadcast holder commitment for currently confirmed funding #3939
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
wpaulino
force-pushed
the
splice-funding-commitment-broadcast
branch
from
a783444 to
a8ae4b7
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3939 +/- ##
==========================================
- Coverage 89.02% 88.66% -0.37%
==========================================
Files 168 167 -1
Lines 121831 122072 +241
Branches 121831 122072 +241
==========================================
- Hits 108457 108232 -225
- Misses 10970 11497 +527
+ Partials 2404 2343 -61
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! This PR has been waiting for your review. |
|
👋 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. |
wpaulino
force-pushed
the
splice-funding-commitment-broadcast
branch
from
a8ae4b7 to
86b53fa
Compare
wpaulino
force-pushed
the
splice-funding-commitment-broadcast
branch
from
86b53fa to
48629c7
Compare
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.
If we don't, it's possible that an alternative funding transaction confirms instead of the one that was locked and we're not able to broadcast a holder commitment to recover our funds. Note that if another funding transaction confirms other than the latest zero conf negotiated one, then we must force close the channel, as commitment updates are only made for the latest zero conf negotiated funding transaction as it's considered "locked"
wpaulino
force-pushed
the
splice-funding-commitment-broadcast
branch
from
48629c7 to
60d97d0
Compare
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
|
|
||
| mem::swap(&mut self.funding, &mut new_funding); | ||
| mem::swap(&mut self.funding, new_funding); |
There was a problem hiding this comment.
The mem::swap function requires two mutable references, but new_funding is being passed by value here. This will cause a compilation error. The correct syntax should be:
mem::swap(&mut self.funding, &mut *new_funding);Since new_funding is an Option<&mut FundingScope>, you need to dereference it first with * and then take a mutable reference to the dereferenced value.
| mem::swap(&mut self.funding, new_funding); | |
| mem::swap(&mut self.funding, &mut *new_funding); |
Spotted by Diamond
Is this helpful? React 👍 or 👎 to let us know.
| OnchainEvent::AlternativeFundingConfirmation {} => { | ||
| // An alternative funding transaction has irrevocably confirmed and we're no | ||
| // longer allowing monitor updates, so promote the `FundingScope` now. | ||
| debug_assert!(self.no_further_updates_allowed()); |
There was a problem hiding this comment.
I'm confused, we push an OnchainEvent::AlternativeFundingConfirmation without checking this, so I don't think this is universally true? Were you intending to only push one if the channel is closed (in which case how do we keep track of a splice that has one confirmation?) or not (in which case we need to remove this assertion and, I think, track the alternative funding confirmation forever in a new field (or set the expiry of an AlternativeFundingConfirmation to never, which we can do as well).
There was a problem hiding this comment.
I'm confused, we push an OnchainEvent::AlternativeFundingConfirmation without checking this, so I don't think this is universally true?
It's done in the following commit, I just applied the fixup to the wrong commit when I added this.
Were you intending to only push one if the channel is closed (in which case how do we keep track of a splice that has one confirmation?) or not (in which case we need to remove this assertion and, I think, track the alternative funding confirmation forever in a new field (or set the expiry of an AlternativeFundingConfirmation to never, which we can do as well).
There's a new variable alternative_funding_confirmed that tracks the confirmed funding txid. The AlternativeFundingConfirmation is just an event used to promote the confirmed scope once the monitor isn't allowing updates anymore, otherwise we rely on the RenegotiatedFundingLocked monitor update.
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
A splice's
FundingScopecan only be promoted once aChannelMonitorUpdateStep::RenegotiatedFundingLockedis applied, or if the monitor is no longer accepting updates, once the splice transaction is no longer under reorg risk. Because of this, our currentFundingScopemay not reflect the latest confirmed state in the chain. Before making a holder commitment broadcast, we must check whichFundingScopeis currently confirmed to ensure that it can propagate throughout the network.