Skip to content

Conversation

martinsaposnic
Copy link
Contributor

@martinsaposnic martinsaposnic commented Sep 23, 2025

Closes #3591

As part of the client_trusts_lsp LSPS2 work, we decided to move the channelmonitor logic into a new PR so the other part could get merged

This comment is not yet done #3838 (comment), hence this was created as draft

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 23, 2025

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@TheBlueMatt TheBlueMatt added this to the 0.2 milestone Sep 23, 2025
Copy link

codecov bot commented Sep 23, 2025

Codecov Report

❌ Patch coverage is 99.27798% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.68%. Comparing base (aa813a2) to head (9bd2ccc).
⚠️ Report is 33 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/chain/channelmonitor.rs 99.45% 1 Missing and 2 partials ⚠️
lightning/src/ln/channel.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4109      +/-   ##
==========================================
+ Coverage   88.62%   88.68%   +0.06%     
==========================================
  Files         179      180       +1     
  Lines      134704   135770    +1066     
  Branches   134704   135770    +1066     
==========================================
+ Hits       119375   120412    +1037     
- Misses      12568    12588      +20     
- Partials     2761     2770       +9     
Flag Coverage Δ
fuzzing 21.77% <53.06%> (+<0.01%) ⬆️
tests 88.53% <99.27%> (+0.07%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

/// `true` when absent during upgrade so holder broadcasts aren't gated unexpectedly.
funding_seen_onchain: bool,
/// Tracks whether manual-broadcasting was requested before the funding transaction appeared on-chain.
manual_broadcast_pending: bool,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

original comment from @TheBlueMatt #3838 (comment)

Hmm, I feel like we can just use holder_tx_signed rather than adding a new bool.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@TheBlueMatt how do I prevent queue_latest_holder_commitment_txn_for_broadcast from being called multiple times? holder_tx_signed is never set to false, so not sure how could I prevent it

Copy link
Collaborator

Choose a reason for hiding this comment

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

ISTM we could call queue_latest_holder_commitment_txn_for_broadcast when we set funding_seen_onchain if holder_tx_signed is true? That should make it called only once cause we can use funding_seen_onchain indirectly to control it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

would this be ok? 6d4f901

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! 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.

@martinsaposnic martinsaposnic force-pushed the track-funding-tx-channelmonitor branch from 236e01f to 6d4f901 Compare September 25, 2025 16:13
@martinsaposnic martinsaposnic marked this pull request as ready for review September 25, 2025 16:14
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Did a first pass, changes look good so far I think.

Mind cleaning up the commit history to a) include a proper title/description for each feature commit b) maybe move the 'track funding transaction' and 'account for manual broadcast' parts into two different feature commits.

pending_funding: Vec<FundingScope>,

/// True if this channel was configured for manual funding broadcasts. Monitors written by
/// versions prior to introducing the flag will load with `false` until a new update persists it.
Copy link
Contributor

Choose a reason for hiding this comment

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

Please be more specific on the version here and below, as it also gives us a hint when we can assume the new behavior and delete the comment/potentially old code.

Suggested change
/// versions prior to introducing the flag will load with `false` until a new update persists it.
/// versions prior to LDK 0.2 will load with `false` until a new update persists it.

(32, pending_funding, optional_vec),
(33, htlcs_resolved_to_user, option),
(34, alternative_funding_confirmed, option),
(35, is_manual_broadcast, option),
Copy link
Contributor

Choose a reason for hiding this comment

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

Those could be simplified by reading with (default_value, X).

/// transactions that cannot be confirmed until the funding transaction is visible.
///
/// [`Event::BumpTransaction`]: crate::events::Event::BumpTransaction
#[rustfmt::skip]
Copy link
Contributor

Choose a reason for hiding this comment

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

Mind dropping this rustfmt::skip in a separate (prefactor) commit while we're here?


if self.is_manual_broadcast && !funding_seen_before && self.funding_seen_onchain && self.holder_tx_signed
{
self.queue_latest_holder_commitment_txn_for_broadcast(
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a bit confused - why do we queue the broadcast here immediately? Should we only do this if should_broadcast_commitment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch. this was a silly mistake. I'm working on a fix but can't find the right answer. if I do

if self.is_manual_broadcast && !funding_seen_before && self.funding_seen_onchain && self.holder_tx_signed
{
    should_broadcast_commitment = true;
}

and not return immediately then it enqueues txs twice so tests fail. I'm working on it

// the funding transaction on-chain, do not queue any transactions.
if require_funding_seen && self.is_manual_broadcast && !self.funding_seen_onchain {
log_info!(logger, "Not broadcasting holder commitment for manual-broadcast channel before funding appears on-chain");
return;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we want to set holder_tx_signed and push the monitor event here. Basically, we should always call generate_claimable_outpoints_and_watch_outputs but we can skip actually passing them to the onchain_tx_handler, similar to what you did elsewhere.

@martinsaposnic martinsaposnic force-pushed the track-funding-tx-channelmonitor branch from a257c8e to 61d9c28 Compare September 26, 2025 16:18
@TheBlueMatt
Copy link
Collaborator

Feel free to squash, I think this is mostly there. Looks like CI is failing and can you write a commit message for the commit?

@martinsaposnic
Copy link
Contributor Author

can you write a commit message for the commit?

sorry, what do you mean by this? @TheBlueMatt

@TheBlueMatt
Copy link
Collaborator

Err, sorry, write commit messages for all the commits. Your commits currently only have titles (and many of them are too long). The subject line should be no longer than ~70 chars, followed by description of why and what was done, as well as anything that might be surprising to someone reading the commit in 5 years. See https://cbea.ms/git-commit/ for more info.

@martinsaposnic
Copy link
Contributor Author

@TheBlueMatt @tnull what do you think about the last fixup? I'm really not sure about the solution here, and I want your ack before I squash&rebase&rewrite the commit message

watch_outputs.append(&mut outputs);
// Only generate claims immediately if block_confirmed
// won't also generate them to avoid duplicate registrations.
let should_broadcast = self.should_broadcast_holder_commitment_txn(logger);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmmm, yea, it does seem a bit strange to check if block_confirmed will do something and disable an important step if it will. But then if block_confirmed changes this code will be automatically broken without touching this code. Rather, ISTM block_confirmed needs to check if we already broadcasted before broadcasting.

… skip passing it to onchain_tx_handler on queue_latest_holder_commitment_txn_for_broadcast
…instead mark it as should_broadcast_commitment for later queueing
@martinsaposnic martinsaposnic force-pushed the track-funding-tx-channelmonitor branch from 3db3230 to 9bd2ccc Compare October 2, 2025 08:59
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.

Track funding transaction confirmation in ChannelMonitor
4 participants