-
Notifications
You must be signed in to change notification settings - Fork 366
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 V2 channel establishment #2302
base: main
Are you sure you want to change the base?
Conversation
34b5cef
to
5bd6e42
Compare
5bd6e42
to
cc88119
Compare
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2302 +/- ##
==========================================
- Coverage 89.90% 89.70% -0.20%
==========================================
Files 121 121
Lines 99170 100033 +863
Branches 99170 100033 +863
==========================================
+ Hits 89159 89735 +576
- Misses 7408 7687 +279
- Partials 2603 2611 +8 ☔ View full report in Codecov by Sentry. |
cc88119
to
6de5a2d
Compare
6de5a2d
to
d155b0e
Compare
This isn't blocked on anything anymore, right? Is there anything you want early feedback on here? |
Technically blocked on interactive txs. But yeah, a few things I need to update before some conceptual/approach review here. |
Also now blocked on the 2077 fixups. |
d155b0e
to
c861c67
Compare
If this is blocked on review interactive txs on the spec-side, I can do a round here. Though dunno which PRs it’s blocked on. |
Oh sorry, I meant the interactive txs implementation. Jurvis had two sketches up in his fork and will be putting a PR together as per the first action item here: https://gist.github.com/jurvis/98215abd6fd392a3f2f0ded03c5c6fff. |
c861c67
to
335ab6f
Compare
@jurvis If you have a branch available for early conceptual review, happy to have a look and see how it scores compared to the specification, the ongoing changes in the mempool and LDK current interfaces :) |
@ariard we just finalised an approach for the TX constructor we are happy with so I’m working to put together a proof of concept rn for review. Should be ready in the next couple of days! |
Many thanks, left a couple of review feedback on the new poc PR. If Duncan or you can maintain a dual-funding / splicing issue like Wilmer is doing for anchor output, this is very welcome to coordinate review and pin feedback backlog. I’ll have a look on the gist too, have to catchup with spec first. |
335ab6f
to
6099dbf
Compare
6099dbf
to
e50d576
Compare
5bb4f00
to
ee08373
Compare
7b66c45
to
e0c9bbb
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.
So sorry this took a while to get back to.
lightning/src/ln/channel.rs
Outdated
@@ -3415,6 +3417,9 @@ pub(super) struct Channel<SP: Deref> where SP::Target: SignerProvider { | |||
pub context: ChannelContext<SP>, | |||
#[cfg(any(dual_funding, splicing))] | |||
pub dual_funding_channel_context: Option<DualFundingChannelContext>, | |||
/// The current interactive transaction construction session under negotiation. | |||
#[cfg(any(dual_funding, splicing))] | |||
interactive_tx_constructor: Option<InteractiveTxConstructor>, |
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.
Is this just for funding-RBF? Can we come up with a way to shove it in the AwaitingChannelReadyFlags
? Or do we intend to reuse this for splicing when we get there (and is that gonna work? Is there a way to have multiple splicing/RBFs in-flight at once?)
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.
It's for splicing too. There can only be one transaction under construction at any one time on a channel.
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.
Ah, alright. Is there any reason to think we'd want to be able to detect if its splicing/RBF in the future?
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.
There may be. I'll find out after we get a concrete splicing PR up :)
lightning/src/ln/channel.rs
Outdated
self.dual_funding_context_mut().funding_feerate_sat_per_1000_weight, | ||
holder_node_id, self.context().counterparty_node_id, self.is_initiator(), | ||
self.dual_funding_context_mut().funding_tx_locktime, | ||
self.dual_funding_context_mut().our_funding_inputs.clone(), funding_outputs, |
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.
It looks like this is the only place our_funding_inputs
is used. Instead of taking it by ref via the dual_funding_context, maybe we should instead take it as an arg to this method?
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.
So there's at least one case where our_funding_inputs
needs to be "stored" before calling the begin_interactive_funding_tx_construction
method, and that's for the initiator as inputs are provided upfront when creating the channel and then the begin_interactive_funding_tx_construction
method is only called after the initiator receives an accept_channel2
message.
I think one way of doing this would be to make our_funding_inputs
an Option
and then just take()
it here via the ref and in other places to avoid the clone.
e0c9bbb
to
a5afd20
Compare
Pushed some fixes for feedback. Working on remaining ones. |
a4730f8
to
6aa5161
Compare
6aa5161
to
18ec344
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.
Needs rebase on #3123
&self, channel_id: &ChannelId, counterparty_node_id: &PublicKey, transaction: Transaction | ||
) -> Result<(), APIError> { | ||
let witnesses: Vec<_> = transaction.input.into_iter().filter_map(|input| { | ||
if input.witness.is_empty() { None } else { Some(input.witness) } |
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.
We should fail if any inputs are non-segwit, right (and document it)? Otherwise the funding tx is malleable and we could lose funds.
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.
We do those checks upfront (or should) and during negotiation. This is just to extract the witnesses.
I'll have another look through and add some test cases at the channelmanager
level.
@@ -1174,7 +1200,7 @@ pub enum Event { | |||
/// The channel value of the requested channel. | |||
funding_satoshis: u64, | |||
/// Our starting balance in the channel if the request is accepted, in milli-satoshi. | |||
push_msat: u64, | |||
acceptor_funds: InboundChannelFunds, |
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.
What's the plan for landing this? We have public API changes (and associated documentation) here, but most of the logic is still cfg-flagged. Its not the end of the world but definitely a bit awkward...Does it make sense to land v2 establishment without the ability to fund the opening transaction so we can avoid all public API changes and then land the ability to negotiate in a separate PR? That would also neatly split this PR, though it would be some work to split it apart, I think?
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.
So, first being allowed to accept V2 channels without contributing (and then introducing the public API in the next PR for contributing)?
It's not too much work, and it does seem safer to land that a bit earlier than everything 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.
Do you plan on doing this in a new PR and rebasing this one or just doing it in this one?
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 thinking new PR to slim this one down. Then I'll rebase this one.
EDIT: The split seems to be going smoothly for now.
18ec344
to
365aac8
Compare
365aac8
to
9088894
Compare
Split out #3137 which should be easier to review and lower risk since it involves no contribution of funds. This PR will be rebased on that. |
This PR aims to do the following:
ChannelManager
to create and accept dual-funded channels.contribute_to_dual_funded_channels
if the user would like to contribute inputs to incoming dual-funded channels. In this case, these channels will need to be accepted manually, indicated by a newOpenChannelV2Request
event so that inputs can be provided. If the above flag is false (default), then no inputs will be contributed and the channel is accepted on the user's behalf gated by all the commonly enforced rules. Other policies and functionality to automate funding of incoming channels may be introduced in the future.