-
Notifications
You must be signed in to change notification settings - Fork 421
Track funding tx channelmonitor #4109
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
base: main
Are you sure you want to change the base?
Track funding tx channelmonitor #4109
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4109 +/- ##
==========================================
+ Coverage 88.62% 88.69% +0.07%
==========================================
Files 179 180 +1
Lines 134704 135781 +1077
Branches 134704 135781 +1077
==========================================
+ Hits 119375 120431 +1056
- Misses 12568 12585 +17
- Partials 2761 2765 +4
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:
|
/// `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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
236e01f
to
6d4f901
Compare
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
/// 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), |
There was a problem hiding this comment.
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] |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
a257c8e
to
61d9c28
Compare
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? |
sorry, what do you mean by this? @TheBlueMatt |
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. |
@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); |
There was a problem hiding this comment.
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.
3db3230
to
9bd2ccc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new fixup looks good. Please feel free to squash fixups and clean up the git commit messages/history.
claimable_outpoints.append(&mut new_outpoints); | ||
watch_outputs.append(&mut new_outputs); | ||
// Only generate claims if we haven't already done so (e.g., in transactions_confirmed). | ||
if claimable_outpoints.is_empty() && watch_outputs.is_empty() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit maybe just the first.
if claimable_outpoints.is_empty() && watch_outputs.is_empty() { | |
if claimable_outpoints.is_empty() { |
9bd2ccc
to
860ba2d
Compare
Adds `is_manual_broadcast` and `funding_seen_onchain` flags to track whether the channel uses manual funding broadcasts and whether we've seen the funding tx confirm. This enables deferring holder commitment broadcasts until after the funding tx is actually broadcast. For example, in LSPS2 with client_trusts_lsp=true, the LSP may defer broadcasting the funding tx until the client claims an HTLC, so we need to avoid broadcasting commitments that reference outputs that don't exist yet.
Marks funding_seen_onchain when we see the funding tx confirm.
Don't queue holder commitment broadcasts until funding is confirmed, unless explicitly overridden via broadcast_latest_holder_commitment_txn. Attempting to broadcast commitments before funding confirms would fail mempool validation since the funding output doesn't exist yet.
860ba2d
to
9890bf9
Compare
ok, all squashed and history cleaned up with improved messages one last small fixup to review @TheBlueMatt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to squash, the changes themselves LGTM.
} | ||
|
||
#[test] | ||
fn test_manual_broadcast_skips_commitment_until_funding_seen() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW it might have been easier to write these as functional tests, which I generally personally prefer as they demonstrate the overall behavior rather than specific unit tests. It doesn't matter too much tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, doing so would avoid a lot of the boilerplate here
For manually-broadcast funding, we can't track claimable outputs until the funding tx is actually onchain. Otherwise we'd try to claim outputs that don't exist yet.
Sets should_broadcast_commitment=true when funding confirms. Since we skip the initial broadcast when funding_seen_onchain is false, we need to queue it once funding actually hits the chain.
Tests that holder commitment broadcasts are properly deferred until funding confirms, and that the full manual-funding flow works correctly.
9890bf9
to
400730f
Compare
if !self.funding_seen_onchain && (txid == self.funding.funding_txid() || | ||
self.pending_funding.iter().any(|f| f.funding_txid() == txid)) | ||
{ | ||
self.funding_seen_onchain = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason we're not doing this in transactions_confirmed
instead?
self.generate_claimable_outpoints_and_watch_outputs(None); | ||
claimable_outpoints.append(&mut claimables); | ||
watch_outputs.append(&mut outputs); | ||
if !self.is_manual_broadcast || self.funding_seen_onchain { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just check this inside generate_claimable_outpoints_and_watch_outputs
instead?
} | ||
|
||
#[test] | ||
fn test_manual_broadcast_skips_commitment_until_funding_seen() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, doing so would avoid a lot of the boilerplate here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my side, mod the pending comments from other reviewers.
/// observed on-chain, unless `require_funding_seen` is `false`. This prevents attempting to | ||
/// broadcast unconfirmable holder commitment transactions before the funding is visible. | ||
/// See also | ||
/// [`crate::chain::channelmonitor::ChannelMonitor::broadcast_latest_holder_commitment_txn`]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Instead of having this huge doc-link, we'd usually just link to ChannelMonitor::broadcast_latest_holder_commitment_txn
and create a corresponding footnote below.
if !self.funding_seen_onchain && (txid == self.funding.funding_txid() || | ||
self.pending_funding.iter().any(|f| f.funding_txid() == txid)) | ||
{ | ||
self.funding_seen_onchain = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to reset this in case of a reorg, i.e., in transactions_unconfirmed
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #3838 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #3838 (comment)
Ah, right, I knew I saw a related comment somewhere. Mind adding a comment (or two) in the code explaining that and why we're fine with it never being unset? FWIW, the current behavior might be okay for the current use case, but if someone would ever reuse the flag for some other application they might be surprised to find it's not unset if there's a reorg.
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still lgtm, at least once the pending comments are addressed. Feel free to immediately squash when you do so, I think.
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