-
Notifications
You must be signed in to change notification settings - Fork 374
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
Implement accepting dual-funded channels without contributing #3137
Conversation
b981cd7
to
0caf60e
Compare
0caf60e
to
44821af
Compare
Codecov ReportAttention: Patch coverage is
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. |
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 great, mostly localized code improvements suggested.
As I see, the |
Looks to me that #2989 is in fact included in this PR (good!) |
0db700b
to
7dceedd
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.
Some initial comments, sorry this took so long to get back to.
lightning/src/ln/channelmanager.rs
Outdated
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) { |
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.
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
.
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.
Thanks @TheBlueMatt, for review and some good points raised. I'll address these ASAP ❤️
7dceedd
to
64c35f4
Compare
Still working on remaining initial feedback. |
64c35f4
to
a46da5a
Compare
No rush, let me know when you want another pass. |
0613f64
to
93896c4
Compare
1. InteractiveTxConstructorArgs is introduced to act as a single, more readable input to InteractiveTxConstructor::new(). 2. Various documentation updates.
90a4695
to
cd26443
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.
LGTM. @TheBlueMatt Could you take a look?
cd26443
to
984862e
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.
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.
HandleTxCompleteResult(Ok(tx_complete)) | ||
} | ||
|
||
fn funding_tx_constructed<L: Deref>( |
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 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
.
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.
Just note that we'll still want this as a function since it's called by signer_unblocked
for async signing.
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 #3411
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.
Fair, still good to consolidate logic in channel.rs
where possible.
@@ -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 |
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.
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.
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.
Removed in #3417.
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 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 |
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.
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).
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.
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.
0b75814
to
8b7505d
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.
Few more comments, got through the bulk of it. Basically the only issue(s) I think need fixing are the persistence of Channel
s 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 |
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.
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_complete
s 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.
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.
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.
pending_changelog/3137-accept-dual-funding-without-contributing.txt
Outdated
Show resolved
Hide resolved
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? |
8b7505d
to
dd190ae
Compare
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. |
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.
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.