Introduce RenegotiatedFundingLocked monitor update variant #3894
Conversation
|
👋 Thanks for assigning @jkczyz as a reviewer! |
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 4th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 5th Reminder Hey @jkczyz! This PR has been waiting for your review. |
| @@ -12470,6 +12493,31 @@ where | |||
| } | |||
| } | |||
|
|
|||
| #[cfg(splicing)] | |||
| for (counterparty_node_id, channel_id, monitor_update) in monitor_updates { | |||
| let per_peer_state = self.per_peer_state.read().unwrap(); | |||
There was a problem hiding this comment.
Could take this lock once outside the loop. Or move this into the previous scope given we already have taken the read lock there?
There was a problem hiding this comment.
The lock is dropped on every call to handle_new_monitor_update below
lightning/src/ln/channel.rs
Outdated
| @@ -10371,25 +10402,47 @@ where | |||
| .iter_mut() | |||
| .find(|funding| funding.get_funding_txid() == Some(sent_funding_txid)) | |||
| { | |||
| // TODO: Do we need to do any of this after the channel is resumed? | |||
There was a problem hiding this comment.
Resumed meaning from being paused pending a ChannelMonitor persistence completing?
There was a problem hiding this comment.
Yeah, this was a stale TODO though
lightning/src/ln/channel.rs
Outdated
| self.context.latest_monitor_update_id += 1; | ||
| let monitor_update = ChannelMonitorUpdate { | ||
| update_id: self.context.latest_monitor_update_id, | ||
| updates: vec![ChannelMonitorUpdateStep::RenegotiatedFundingLocked { | ||
| funding_txid: funding_txo.unwrap().txid, | ||
| }], | ||
| channel_id: Some(self.context.channel_id()), | ||
| }; |
There was a problem hiding this comment.
Don't have a strong opinion, but to DRY this up should we do this as part of maybe_promote_splice_funding, returning Option<ChannelMonitorUpdate>?
There was a problem hiding this comment.
Cleaned it up a bit, let me know if this is what you had in mind
| // If an RBF happens and it confirms, this will no longer be accurate, so update it now | ||
| // if we know the RBF doesn't belong to a splice. | ||
| if !has_pending_splice | ||
| && self.first_confirmed_funding_txo == self.funding.funding_outpoint() |
There was a problem hiding this comment.
Is this second part of the condition necessary?
There was a problem hiding this comment.
Yeah, this is how we know that first_confirmed_funding_txo hasn't been updated yet.
|
👋 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
renegotiated-funding-locked-monitor-update
branch
from
cf88d1f to
00e8bb3
Compare
This is a new `ChannelMonitorUpdateStep` variant intended to be used whenever a new funding transaction that was negotiated and applied via the `RenegotiatedFunding` update reaches its intended confirmation depth and both sides of the channel exchange `channel_ready`/`splice_locked`. This commit primarily focuses on its use for splices, but future work will expand where needed to support RBFs for a dual funded channel. This monitor update ensures that the monitor can safely drop all prior commitment data since it is now considered invalid/unnecessary. Once the update is applied, only state for the new funding transaction is tracked going forward, until the monitor receives another `RenegotiatedFunding` update.
wpaulino
force-pushed
the
renegotiated-funding-locked-monitor-update
branch
from
00e8bb3 to
c1ead6a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3894 +/- ##
==========================================
- Coverage 89.65% 88.78% -0.88%
==========================================
Files 164 166 +2
Lines 134658 119528 -15130
Branches 134658 119528 -15130
==========================================
- Hits 120734 106120 -14614
+ Misses 11246 11075 -171
+ Partials 2678 2333 -345 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| let funding_promoted = chain_node_signer | ||
| .and_then(|(chain_hash, node_signer, user_config)| { | ||
| self.maybe_promote_splice_funding(node_signer, chain_hash, user_config, height, logger) | ||
| }); |
There was a problem hiding this comment.
I guess we'll never promote when unconfirming, so this should be fine.
| { | ||
| let funding = self | ||
| .pending_funding | ||
| .iter_mut() | ||
| .find(|funding| funding.get_funding_txid() == Some(splice_txid)) | ||
| .unwrap(); | ||
| promote_splice_funding!(self, funding); | ||
| } |
| let funding_txo = chan | ||
| .funding | ||
| .get_funding_txo() | ||
| .expect("Splice FundingScope should always have a funding_txo"); |
There was a problem hiding this comment.
I think we were trying to avoid accessing funding from ChannelManager. Should we continue to return the funding_txo? Then maybe we can avoid the boilerplate here? Possibly similarly in maybe_promote_splice_funding using a struct for the return type to avoid similar boilerplate at its call sites.
This is a new
ChannelMonitorUpdateStepvariant intended to be used whenever a new funding transaction that was negotiated and applied via theRenegotiatedFundingupdate reaches its intended confirmation depth and both sides of the channel exchangechannel_ready/splice_locked. This commit primarily focuses on its use for splices, but future work will expand where needed to support RBFs for a dual funded channel.This monitor update ensures that the monitor can safely drop all prior commitment data since it is now considered invalid/unnecessary. Once the update is applied, only state for the new funding transaction is tracked going forward, until the monitor receives another
RenegotiatedFundingupdate.