Introduce RenegotiatedFundingLocked monitor update variant #3894
Conversation
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.
|
👋 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?
| @@ -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?
| 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>?
| // 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?
|
👋 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. |
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.