[Splicing] Tx negotiation during splicing #3736
Conversation
|
👋 Thanks for assigning @wpaulino as a reviewer! |
optout21
force-pushed
the
splice-dual-tx4
branch
from
7f6dfbd to
c3778bc
Compare
1 similar comment
1 similar comment
1 similar comment
1 similar comment
1 similar comment
1 similar comment
lightning/src/ln/channel.rs
Outdated
| @@ -2414,6 +2414,7 @@ pub(super) trait FundingTxConstructorV2<SP: Deref>: ChannelContextProvider<SP> w | |||
| fn begin_interactive_funding_tx_construction<ES: Deref>( | |||
| &mut self, signer_provider: &SP, entropy_source: &ES, holder_node_id: PublicKey, | |||
| change_destination_opt: Option<ScriptBuf>, | |||
| _is_splice: bool, prev_funding_input: Option<(TxIn, TransactionU16LenLimited)>, | |||
There was a problem hiding this comment.
Why do we need is_splice if prev_funding_input being set implies we are splicing?
There was a problem hiding this comment.
Because the prev. funding input is set only by the initiator, and this method is used on both side (initiator and acceptor).
There was a problem hiding this comment.
The funding input still needs to be passed through to the interactive constructor though so we can make sure the counterparty adds it when we're not the initiator and we can check it's the same as we expect.
There was a problem hiding this comment.
It is, everything will go through it after begin_interactive_funding_tx_construction
There was a problem hiding this comment.
Clarified: the previous funding as an input is a shared input, and the splice-acceptor side also has to be aware of it, it has to check that it is being added by the initiator. So it has to provided as a special shared input, which is added during negotiation by the initiator, and checked by the acceptor.
There was a problem hiding this comment.
I've tried to do it, but ran into a problem with the tests. Apparently on the acceptor side (v1 channel) the field funding.funding_transaction is never set.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3736 +/- ##
==========================================
+ Coverage 89.73% 90.28% +0.55%
==========================================
Files 159 160 +1
Lines 128910 132032 +3122
Branches 128910 132032 +3122
==========================================
+ Hits 115676 119207 +3531
+ Misses 10536 10172 -364
+ Partials 2698 2653 -45 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
optout21
force-pushed
the
splice-dual-tx4
branch
3 times, most recently
from
88d2e83 to
866368d
Compare
|
Ready for a new round of review. I have addressed the comments, applied most of them. There is still one to-do (update channel reserve values), that I will do, but the rest is ready for review. |
|
Ready for a new round of review. All pending and newly raised comments addressed. |
lightning/src/ln/channelmanager.rs
Outdated
| try_channel_entry!(self, peer_state, Err(ChannelError::Close(( | ||
| err.into(), | ||
| ClosureReason::HolderForceClosed { broadcasted_latest_txn: Some(false) }, | ||
| ))), chan_entry) |
There was a problem hiding this comment.
Is closing the channel here a spec requirement? Seems like we could just drop the message or send a warning.
| @@ -8649,9 +8980,20 @@ impl<SP: Deref> FundedChannel<SP> where | |||
| "Insufficient inputs for splicing; channel ID {}, err {}", | |||
| self.context.channel_id(), err, | |||
| )})?; | |||
| // Convert inputs | |||
| let mut funding_inputs = Vec::new(); | |||
| for (tx_in, tx, _w) in our_funding_inputs.into_iter() { | |||
There was a problem hiding this comment.
Let's just make our_funding_inputs an owned value
There was a problem hiding this comment.
Done, though an extra clone() is added in channelmanager.rs, due to optionally_notify closure.
There was a problem hiding this comment.
Hmm... that's unfortunate. It seems to stem form the fact that PersistenceNotifierGuard has an FnMut rather than an FnOnce. Might be able to fix that but probably better to save for a separate PR.
There was a problem hiding this comment.
Opened #3835 to fix the root issue.
optout21
force-pushed
the
splice-dual-tx4
branch
2 times, most recently
from
5a18b43 to
f1c280d
Compare
|
I have rearranged the commits in this PR (there were some reverted changes, many fixes, etc.), into these 4:
Otherwise, no change applied this time. (Note: the old commits are available on branch splice-dual-tx4-save) |
|
For reference, summary of NOT-included changes:
|
lightning/src/ln/channel.rs
Outdated
| pub our_funding_inputs: Vec<(TxIn, TransactionU16LenLimited)>, | ||
| /// Set when splice_ack has been processed (on the initiator side), | ||
| /// used to prevent processing of multiple splice_ack's. | ||
| awaiting_splice_ack: bool, |
There was a problem hiding this comment.
Un-resolving to see if this is a viable approach.
This is a simple rename, DualFundingContext to FundingNegotiationContext, to suggest that this is use not only in dual-funded channel open. Also rename the field dual_funding_context to funding_negotiation_context.
The begin_interactive_funding_tx_construction() method is extended with the prev_funding_input optional parameter, containing the previous funding transaction, which will be added to the negotiation as an input by the initiator.
Introduce struct NegotiatingChannelView to perform transaction negotiation logic, on top of both PendingV2Channel (dual-funded channel open) and FundedChannel (splicing).
Fill the logic for including transaction negotiation during splicing, implement the functions: splice_channel, splice_init, splice_ack, funding_tx_constructed. Also extend the test case test_v1_splice_in with the steps for funding negotiation during splicing.
In begin_interactive_funding_tx_construction(), rename is_outbound to is_initiator, to prevent confusion with earlier the role at channel open.
ChannelTransactionParameters: clone only unchanged members. Optimize checking twice for pending_splice in splice_ack.
Add Channel.as_negotiating_channel(), and use that to call into the 5 tx_*() methods, so those could be removed from Channel.
We had some discussion on #3741 (comment) and on the spec PR (lightning/bolts#1160 (comment)) about this. Turns out we need to make |
Instead, rely on the presense of the funding_scope and interactive_tx_constructor optional fields.
|
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
Simplify handling of pending_splice field check, get rid of one unwrap().
Getting closer :) As I see the changes needed:
In this PR or another one? Probably best would be to include these into this PR (causing some further processing time). |
Yeah, I think we need to do it in this PR. |
There was a problem hiding this comment.
When using fixup commits, please keep each one grouped under the relevant commit it should be applied to. You already have the context as to what commit the fix belongs to, and you won't have to reload that context when it's time to squash them (it also makes review easier).
| peer_state.pending_msg_events.push(MessageSendEvent::SendSpliceAck { | ||
| node_id: *counterparty_node_id, | ||
| msg: splice_ack_msg, | ||
| }); | ||
| } else { | ||
| return Err(MsgHandleErrInternal::send_err_msg_no_close("Channel is not funded, cannot be spliced".to_owned(), msg.channel_id)); | ||
| return Err(MsgHandleErrInternal::send_err_msg_no_close(format!("Channel is not funded, cannot be spliced"), msg.channel_id)); |
There was a problem hiding this comment.
We need to close the channel with Err(ChannelError::Close) to try_channel_entry!
| } else { | ||
| return Err(MsgHandleErrInternal::send_err_msg_no_close("Channel is not funded, cannot splice".to_owned(), msg.channel_id)); | ||
| return Err(MsgHandleErrInternal::send_err_msg_no_close(format!("Channel is not funded, cannot be spliced"), msg.channel_id)); |
| @@ -1385,7 +1387,10 @@ impl<SP: Deref> Channel<SP> where | |||
| pub fn unfunded_context_mut(&mut self) -> Option<&mut UnfundedChannelContext> { | |||
| match &mut self.phase { | |||
| ChannelPhase::Undefined => unreachable!(), | |||
| ChannelPhase::Funded(_) => { debug_assert!(false); None }, | |||
There was a problem hiding this comment.
Doesn't look like this needed to change
| Ok((commitment_signed, event)) | ||
| } | ||
| #[cfg(splicing)] | ||
| ChannelPhase::Funded(ref mut chan) => { |
There was a problem hiding this comment.
Looks like we can bypass this match by using Channel::as_negotiating_channel
| holder_pubkeys, | ||
| holder_selected_contest_delay: prev_funding.channel_transaction_parameters.holder_selected_contest_delay, | ||
| // The 'outbound' attribute may change, if the the splice is being initiated by the previous acceptor | ||
| is_outbound_from_holder: is_initiator, |
There was a problem hiding this comment.
This is now changing the meaning of is_outbound_from_holder, it should always represent the opener of the channel regardless of splicing.
| #[cfg(splicing)] | ||
| pub fn splice_init(&mut self, msg: &msgs::SpliceInit) -> Result<msgs::SpliceAck, ChannelError> { | ||
| pub fn splice_init_checks(&self, msg: &msgs::SpliceInit) -> Result<(), ChannelError> { |
There was a problem hiding this comment.
| pub fn splice_init_checks(&self, msg: &msgs::SpliceInit) -> Result<(), ChannelError> { | |
| pub fn validate_splice_init(&self, msg: &msgs::SpliceInit) -> Result<(), ChannelError> { |
| is_splice: true, | ||
| }; | ||
|
|
||
| // Start interactive funding negotiation. No extra input, as we are not the splice initiator |
| pending_splice.interactive_tx_constructor = None; | ||
| pending_splice.interactive_tx_signing_session = None; |
There was a problem hiding this comment.
Why are we doing this? Shouldn't they already be none?
|
|
||
| let post_channel_value = PendingSplice::compute_post_value(pre_channel_value, our_funding_contribution, their_funding_contribution); | ||
|
|
||
| let (our_funding_satoshis, their_funding_satoshis) = calculate_funding_values( |
There was a problem hiding this comment.
This needs a better name, it's quite ambiguous and error-prone what this is and how it should be used. It seems it's already being used incorrectly in below in FundingScope::for_splice, where we add it to the post_value_to_self_msat, but that value shouldn't include the previous funding amount.
|
|
||
| let splice_ack_msg = self.get_splice_ack(our_funding_contribution); | ||
|
|
||
| // Build NegotiatingChannelView lcoally, simmilar to Channel::as_renegotiating_channel() |
There was a problem hiding this comment.
Why can't we use FundedChannel::as_renegotiating_channel?
There was a problem hiding this comment.
This change was a result of #3736 (comment).
Implementation of transaction negotiation during splicing.
Builds on 3407 and 3443.
Funded(FundedChannel)is used throughout splicingFundedChannelandPendingV2Channelcan act as a transaction constructorPendingV2Channellogic is put behind a trait --FundingTxConstructorV2RenegotiatingScopeis used to store extra state during splicingFundingChannelcan act as aFundingTxConstructorV2, using the state fromRenegotiatingScope(if present)FundedChannelandFundingTxConstructorhas context(), context accessors are extracted into a common base trait,ChannelContextProvider(it is also shared byInitialRemoteCommitmentReceiver).(Also relevant: #3444)