Skip to content

Introduce RenegotiatedFunding monitor update variant #3822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

wpaulino
Copy link
Contributor

@wpaulino wpaulino commented Jun 2, 2025

This is a new ChannelMonitorUpdateStep variant intended to be used whenever a new funding transaction for the channel has been negotiated via the InteractiveTxConstructor. This commit primarily focuses on its use for splices, but future work will expand where needed to support RBFs (both for the initial dual funding transaction, and splice transactions).

To draw a parallel to channel open, we generally want to have the commitment transactions negotiated for the funding transaction and committed to the respective ChannelMonitor before attempting to sign the funding transaction itself. This monitor update fulfills this need for a newly negotiated splice; it includes both the new holder and counterparty commitment transactions, and the new set of applicable ChannelTransactionParameters. Once the monitor update has been applied to the monitor and persisted, we allow the release of our tx_signatures for the splice transaction to wait for its confirmation.

Depends on #3774.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jun 2, 2025

👋 I see @TheBlueMatt was un-assigned.
If you'd like another reviewer assignemnt, please click here.

@wpaulino wpaulino requested a review from jkczyz June 2, 2025 23:53
Copy link

codecov bot commented Jun 3, 2025

Codecov Report

Attention: Patch coverage is 23.61111% with 165 lines in your changes missing coverage. Please review.

Project coverage is 89.62%. Comparing base (db165ad) to head (a94ac4c).

Files with missing lines Patch % Lines
lightning/src/chain/channelmonitor.rs 13.21% 151 Missing ⚠️
lightning/src/chain/chainmonitor.rs 6.66% 13 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3822      +/-   ##
==========================================
- Coverage   89.74%   89.62%   -0.13%     
==========================================
  Files         164      164              
  Lines      133079   133290     +211     
  Branches   133079   133290     +211     
==========================================
+ Hits       119437   119459      +22     
- Misses      10960    11141     +181     
- Partials     2682     2690       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ldk-reviews-bot
Copy link

👋 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 wpaulino force-pushed the renegotiated-funding-monitor-update branch from 6c78591 to ac8c8c5 Compare June 9, 2025 00:35
@wpaulino wpaulino requested a review from jkczyz June 9, 2025 00:35
@tankyleo tankyleo self-requested a review June 9, 2025 19:55
Copy link
Contributor

@tankyleo tankyleo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass in channel monitor

@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from ac8c8c5 to 5f0709f Compare June 10, 2025 18:58
@wpaulino wpaulino requested a review from TheBlueMatt June 10, 2025 18:58
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Contributor

@tankyleo tankyleo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stared at the code again today, picked up nits on the way.

@@ -1677,7 +1677,33 @@ impl<SP: Deref> Channel<SP> where
res
},
ChannelPhase::Funded(mut funded_channel) => {
let res = funded_channel.commitment_signed(msg, logger).map(|monitor_update_opt| (None, monitor_update_opt));
#[cfg(splicing)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sheesh, is it too late to make this a new damn message? We now have three totally separate handling logic for commitment_signed, and this one doesn't even make any sense - we're receiving a single commitment_signed but we actually need two if we were in a normal state...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sheesh, is it too late to make this a new damn message?

Probably not? Would be a trivial thing to change, but it would basically be a copy of the commitment_signed message.

this one doesn't even make any sense - we're receiving a single commitment_signed but we actually need two if we were in a normal state...

I'm not following, what do you mean by "normal state"? This is handling the case where we haven't finished negotiating a splice transaction. We expect a single commitment_signed to be exchanged for the alternative commitments at the current commitment number. After the negotiation finishes, if we're expecting a batch and they didn't send it, we'll fail the channel. If we're not expecting a batch and they did send it, we'll also fail the channel.

pending_splice_funding, &self.holder_commitment_point, msg, logger,
)?;

let counterparty_commitment_tx = self.context.build_commitment_transaction(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bleh, we already build the commitment tx in validate_commitment_signed, lets not do it again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to build both, validate_commitment_signed builds the holder one, this builds the counterparty one

@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from 5f0709f to 689d0c1 Compare June 11, 2025 17:04
@wpaulino wpaulino requested a review from TheBlueMatt June 12, 2025 17:23
@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from 689d0c1 to 4a38fd2 Compare June 13, 2025 17:20
@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @TheBlueMatt @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from 4a38fd2 to b274f78 Compare June 16, 2025 17:13
for (alternative_htlc, (htlc, _)) in
alternative_htlcs.iter().zip(htlcs_with_sources.iter_mut())
{
debug_assert!(htlc.transaction_output_index.is_some());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for these

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The transaction_output_index.is_some() checks are more of an internal assertion, since there's a guarantee that CommitmentTransaction::nondust_htlcs returns HTLCs with their indices populated. The is_data_equal check should definitely return an error though.

debug_assert!(alternative_htlc.transaction_output_index.is_some());
debug_assert!(alternative_htlc.is_data_equal(htlc));
htlc.transaction_output_index = alternative_htlc.transaction_output_index;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we further check that all alternative htlcs that were not considered have no output index?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative HTLCs (coming from the alternative counterparty commitment transaction) are non-dust only. The other HTLC data is coming from counterparty_claimable_outpoints which has already gone through validation.

@TheBlueMatt
Copy link
Collaborator

Needs rebase, it seems.

@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from b274f78 to a201837 Compare June 17, 2025 17:38
@wpaulino wpaulino requested review from TheBlueMatt and tankyleo and removed request for jkczyz June 17, 2025 17:39
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically LGTM

msg,
logger,
)?;
let counterparty_commitment_tx = self
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We just built the commitment tx in validate_commitment_signed, let's not re-build it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're not the same transaction, one is the holder and the other the counterparty

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, okay this could use some comments, I think. So when we go to splice we (a) negotiate the new funding, then (b) exchange commitment_signed messages, then (c) exchange our new-funding-tx signatures.

AFAIU, the intent is that we'll update both the local and remote commitment txn after we receive the peer's commitment_signed at the end of (b), with a monitor update blocker preventing us from going to (c). This saves the extra monitor update when sending the commitment_signed at the start of (b). But ultimately we should have a comment, IMO, describing that the commitment_signed we sent at the top of (b) and the commitment we generate here are guaranteed to be identical (because we pause the state machine until we finish (c), I imagine?)

This is a new `ChannelMonitorUpdateStep` variant intended to be used
whenever a new funding transaction for the channel has been negotiated
via the `InteractiveTxConstructor`. This commit primarily focuses on its
use for splices, but future work will expand where needed to support
RBFs (both for the initial dual funding transaction, and splice
transactions).

To draw a parallel to channel open, we generally want to have the
commitment transactions negotiated for the funding transaction and
committed to the respective `ChannelMonitor` before attempting to sign
the funding transaction itself. This monitor update fulfills this need
for a newly negotiated splice; it includes both the new holder
and counterparty commitment transactions, and the new set of applicable
`ChannelTransactionParameters`. Once the monitor update has been applied
to the monitor and persisted, we allow the release of our
`tx_signatures` for the splice transaction to wait for its confirmation.
@wpaulino wpaulino force-pushed the renegotiated-funding-monitor-update branch from a201837 to a94ac4c Compare June 18, 2025 01:55
@wpaulino wpaulino requested a review from TheBlueMatt June 18, 2025 01:56
@TheBlueMatt
Copy link
Collaborator

TheBlueMatt commented Jun 18, 2025

LGTM, I think, modulo the comment request above @jkczyz or @tankyleo can take a look now.

@TheBlueMatt TheBlueMatt removed their request for review June 18, 2025 14:39
Copy link
Contributor

@tankyleo tankyleo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code all LGTM pending Matt's last unresolved comment above.

@jkczyz would you be able to take a look at channel.rs on this PR ? Code makes sense to me, but not as confident with the p2p splicing dance :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants