Skip to content
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

Implement accepting dual-funded channels without contributing #3137

Merged
merged 15 commits into from
Nov 20, 2024

Conversation

dunxen
Copy link
Contributor

@dunxen dunxen commented Jun 20, 2024

We split this out from #2302 for easier review and to address the common non-public API parts of the V2 channel establishment implementation.

This will allow the holder to be an acceptor, but not initiator of V2 channels. We also don't expose an API for contributing to an inbound channel.

The functionality to initiate V2 channels and fund inbound channels forms part of #2302.

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 3 times, most recently from b981cd7 to 0caf60e Compare June 20, 2024 16:14
@dunxen dunxen marked this pull request as ready for review June 20, 2024 16:27
@dunxen dunxen mentioned this pull request Jun 20, 2024
4 tasks
@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 0caf60e to 44821af Compare June 24, 2024 16:55
@codecov-commenter
Copy link

codecov-commenter commented Jun 24, 2024

Codecov Report

Attention: Patch coverage is 60.06849% with 583 lines in your changes missing coverage. Please review.

Project coverage is 89.29%. Comparing base (4322b19) to head (8b0f4b5).

Files with missing lines Patch % Lines
lightning/src/ln/channelmanager.rs 47.67% 227 Missing and 21 partials ⚠️
lightning/src/ln/channel.rs 59.73% 162 Missing and 18 partials ⚠️
lightning/src/ln/interactivetxs.rs 49.16% 150 Missing and 3 partials ⚠️
lightning/src/ln/dual_funding_tests.rs 99.02% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3137      +/-   ##
==========================================
- Coverage   89.69%   89.29%   -0.41%     
==========================================
  Files         129      130       +1     
  Lines      105437   106910    +1473     
  Branches   105437   106910    +1473     
==========================================
+ Hits        94573    95464     +891     
- Misses       8117     8665     +548     
- Partials     2747     2781      +34     

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

Copy link
Contributor

@optout21 optout21 left a comment

Choose a reason for hiding this comment

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

Looks great, mostly localized code improvements suggested.

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/mod.rs Outdated Show resolved Hide resolved
@optout21
Copy link
Contributor

As I see, the dual_funding cfg flag has been removed (not a problem)

@optout21
Copy link
Contributor

Looks to me that #2989 is in fact included in this PR (good!)

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 4 times, most recently from 0db700b to 7dceedd Compare July 3, 2024 09:44
@dunxen dunxen requested review from optout21 and TheBlueMatt and removed request for optout21 July 3, 2024 09:51
optout21
optout21 previously approved these changes Jul 3, 2024
lightning/src/events/mod.rs Outdated Show resolved Hide resolved
@dunxen dunxen requested a review from jkczyz July 4, 2024 15:02
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.

Some initial comments, sorry this took so long to get back to.

lightning/src/events/mod.rs Show resolved Hide resolved
lightning/src/events/mod.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
if chan.interactive_tx_signing_session.is_some() {
let monitor = try_chan_phase_entry!(self,
chan.commitment_signed_initial_v2(&msg, best_block, &self.signer_provider, &&logger), chan_phase_entry);
if let Ok(persist_status) = self.chain_monitor.watch_channel(chan.context.get_funding_txo().unwrap(), monitor) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

If the persist status is pending we need to handle the later stuff in monitor_updating_restored. Really the whole contents of the block here should be in monitor_updating_restored.

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved
Copy link
Contributor Author

@dunxen dunxen left a comment

Choose a reason for hiding this comment

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

Thanks @TheBlueMatt, for review and some good points raised. I'll address these ASAP ❤️

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 7dceedd to 64c35f4 Compare July 10, 2024 16:05
@dunxen
Copy link
Contributor Author

dunxen commented Jul 10, 2024

Still working on remaining initial feedback.

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 64c35f4 to a46da5a Compare July 11, 2024 14:55
@TheBlueMatt
Copy link
Collaborator

No rush, let me know when you want another pass.

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 2 times, most recently from 0613f64 to 93896c4 Compare July 16, 2024 10:36
1. InteractiveTxConstructorArgs is introduced to act as a single, more
   readable input to InteractiveTxConstructor::new().
2. Various documentation updates.
@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 90a4695 to cd26443 Compare November 18, 2024 13:20
Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

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

LGTM. @TheBlueMatt Could you take a look?

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from cd26443 to 984862e Compare November 18, 2024 18:17
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.

Made it most of the way through. I think basically all the comments here can be addressed in a followup, so will get through the rest hopefully soon so we can land it. In the mean time, feel free to squash fixups and fix any of the smaller comments here you want in the process.

lightning/src/ln/channelmanager.rs Show resolved Hide resolved
lightning/src/ln/channel.rs Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
HandleTxCompleteResult(Ok(tx_complete))
}

fn funding_tx_constructed<L: Deref>(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can tx_complete just call this directly when required rather than having channelmanager.rs call tx_complete then call this based only on the return value of tx_complete? Would reduce the logic in channelmanager.rs.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just note that we'll still want this as a function since it's called by signer_unblocked for async signing.

Copy link
Contributor

Choose a reason for hiding this comment

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

See #3411

Copy link
Collaborator

Choose a reason for hiding this comment

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

Fair, still good to consolidate logic in channel.rs where possible.

lightning/src/ln/channel.rs Show resolved Hide resolved
@@ -9009,7 +9501,8 @@ impl<SP: Deref> Writeable for Channel<SP> where SP::Target: SignerProvider {
(47, next_holder_commitment_point, option),
(49, self.context.local_initiated_shutdown, option), // Added in 0.0.122
(51, is_manual_broadcast, option), // Added in 0.0.124
(53, funding_tx_broadcast_safe_event_emitted, option) // Added in 0.0.124
(53, funding_tx_broadcast_safe_event_emitted, option), // Added in 0.0.124
(55, self.context.next_funding_txid, option) // Added in 0.1.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yea, would be nice to remove this before we release and instead figure out the next_funding_txid field based on the funding transaction in the Channel and the current channel 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.

Removed in #3417.

Copy link
Contributor Author

@dunxen dunxen Nov 22, 2024

Choose a reason for hiding this comment

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

The follow-up PR #3423 should populate it on read.

@@ -9618,9 +10114,12 @@ impl<'a, 'b, 'c, ES: Deref, SP: Deref> ReadableArgs<(&'a ES, &'b SP, u32, &'c Ch

blocked_monitor_updates: blocked_monitor_updates.unwrap(),
is_manual_broadcast: is_manual_broadcast.unwrap_or(false),
// If we've sent `commtiment_signed` for an interactively constructed transaction
Copy link
Collaborator

Choose a reason for hiding this comment

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

Mmm, so really this is the "we were done with negotiation" flag in the channel_reestablish message. It does seem like we're missing some startup handling for this - basically we need to check on startup if the ChannelMonitor was persisted (implying we've sent our initial commitment_signed and thus we must not restart negotiation), but (a) it doesn't matter for inbound not-locally-funded channels and (b) maybe its fine just because the Channel will be dropped if its pre-ChannelMonitor (need a test/to check this, but I don't think so, since we mark the channel as funded in internal_tx_complete, at which point we'll persist the Channel even though it doesn't have a monitor yet).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah this was a mistake to mark it funded at that point. Only after receiving an initial commitment_signed and getting a monitor do we need to persist. I'll fix the states up in the follow-up.

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Show resolved Hide resolved
@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 3 times, most recently from 0b75814 to 8b7505d Compare November 19, 2024 13:14
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.

Few more comments, got through the bulk of it. Basically the only issue(s) I think need fixing are the persistence of Channels before we have a ChannelMonitor which is gonna cause issues on restart. It can be fixed in a followup, though. Still need to review the tests but I can do that after this lands.

"Dual-funded channels not supported".to_owned(),
msg.channel_id.clone())), counterparty_node_id);
// Note that we never need to persist the updated ChannelManager for an inbound
// tx_complete message - interactive transaction construction does not need to
Copy link
Collaborator

Choose a reason for hiding this comment

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

But don't we send signatures in response to tx_complete (if we already received the peer's tx_complete and we're supposed to send first)? More generally, once the tx_completes have been exchanged, don't we at that point want to be able to resume the channel after restart (which implies a persistence, and also some additional handling cause we will currently FC on channel on startup if there's no ChannelMonitor which we won't have yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After consecutive tx_complete exchange, we will only send then initial commitment_signed.

We will only send a tx_signatures once we've received an initial commitment_signed if we are up first to send tx_signatures. Once we've received a commitment_signed we persist.

I've fixed this in the follow-up I'll have up soon. No PR yet.

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Show resolved Hide resolved
@dunxen
Copy link
Contributor Author

dunxen commented Nov 19, 2024

Few more comments, got through the bulk of it. Basically the only issue(s) I think need fixing are the persistence of Channels before we have a ChannelMonitor which is gonna cause issues on restart. It can be fixed in a followup, though. Still need to review the tests but I can do that after this lands.

Thanks! Going to address a few more things you brought up throughout tonight and tomorrow morning for me and then I'll open an issue with remaining follow-ups. So unless something major prevents this from landing, we could land it tomorrow?

@dunxen dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 8b7505d to dd190ae Compare November 20, 2024 12:28
@dunxen
Copy link
Contributor Author

dunxen commented Nov 20, 2024

I've pushed up a few fixes. There are some nits that could be fixed here, but I'll include them in a followup to start unblocking other PRs.

@jkczyz, if CI and you are happy, we can go ahead and get this in when you're ready. Then I'll create the follow-up issue and tag it to make sure it's a blocker for next release.

@jkczyz
Copy link
Contributor

jkczyz commented Nov 20, 2024

I've pushed up a few fixes. There are some nits that could be fixed here, but I'll include them in a followup to start unblocking other PRs.

@jkczyz, if CI and you are happy, we can go ahead and get this in when you're ready. Then I'll create the follow-up issue and tag it to make sure it's a blocker for next release.

Sure, let's land this now and address the rest in follow-ups. Incremental mutants has been running for five hours, but no need to wait on it.

@jkczyz jkczyz merged commit 0c31021 into lightningdevkit:main Nov 20, 2024
16 of 19 checks passed
@dunxen dunxen deleted the 2024-06-non-public-API-v2-channels branch November 21, 2024 08:16
dunxen added a commit to dunxen/rust-lightning that referenced this pull request Nov 25, 2024
We want to remove this before release so that we can work on a way to
not persist this but rather get it from other persisted data and just
free up the TLV.

Note that the "added in 0.0.124" comment was incorrect as it was
actually added in lightningdevkit#3137 but the comment was stale so it's safe to remove.
@jkczyz jkczyz mentioned this pull request Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants