[Splicing] Tx negotiation during splicing #3736
Conversation
As multiple traits contain a context -- InitialRemoteCommitmentReceiver, FundingTxConstructor -- the context part is extracted into a separate new base trait, called ChannelContextProvider.
PendingV2Channel struct can do transaction negotiation operations, but now behind a trait, so that FundingChannel is also do that, and inherit some common logic.
FundedChannel is extended with an optional struct RefundingScope, that holds data used during splicing (re)negotiation. It stores the same fields as PendingV2Channel, excet for the context. FundedChannel can act as a transaction constructor (much like PendingV2Channel), when the refunding context is present.
Extend begin_interactive_funding_tx_construction() with splicing-specific parameter: extra funding input.
|
👋 Thanks for assigning @wpaulino as a reviewer! |
Handle the transaction negotiation messages during splice negotiation (tx_add_input, tx_add_output, tx_complete).
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
| /// Data needed during splicing -- | ||
| /// when the funding transaction is being renegotiated in a funded channel. | ||
| #[cfg(splicing)] | ||
| struct RefundingScope { |
There was a problem hiding this comment.
Why are we introducing yet another structure as opposed to tracking all the fields here in PendingSplice?
There was a problem hiding this comment.
RefundingScope does not live through the whole lifetime of splicing. Not before splice_ack received, and not after tx_complete. PendingSplice has a longer lifetime. Also, the fields are belonging to each other. I could 'flatten' the structure, and just move the fields to PendingSplice, but I think it's clearer if they are in a struct, and can be set to None at once.
There was a problem hiding this comment.
Also, I did remove the PendingSpliceInit sub-struct, and included the few fields in PendingSplice directly (See 0f8acd3)
There was a problem hiding this comment.
I'm still not convinced this is helpful, FundedChannel and RefundingScope are almost the same, why not just implement the trait directly on FundedChannel?
There was a problem hiding this comment.
We have clarified as follows:
RefundingScopedoes not implement the trait, but theFundedChannelRefundingWrapperdoes- The wrapper makes sense to be kept
RefundingScopecould be dropped, and its 4 fields included directly inPendingSpliceFundedChannelRefundingWrappercould be returned byPendingV2Channelas well, and then the trait can be dropped, as only one struct would need it.
There was a problem hiding this comment.
RefundingScope has been dropped, its 4 fields are included directly in PendingSplice.
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.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3736 +/- ##
==========================================
+ Coverage 89.10% 91.01% +1.90%
==========================================
Files 156 158 +2
Lines 123431 139605 +16174
Branches 123431 139605 +16174
==========================================
+ Hits 109985 127059 +17074
+ Misses 10760 9940 -820
+ Partials 2686 2606 -80 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Use and_then() instead of map().flatten()
optout21
force-pushed
the
splice-dual-tx4
branch
2 times, most recently
from
171a6ac to
88d2e83
Compare
Instead of implementing FundingTxConstructorV2, in FundedChannel return a wrapper that implements FundingTxConstructorV2 (FundedChannelRefundingWrapper).
|
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. |
| 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.
| self.internal_tx_msg(&counterparty_node_id, msg.channel_id, |channel: &mut Channel<SP>| { | ||
| match channel.as_unfunded_v2_mut() { | ||
| Some(unfunded_channel) => { | ||
| Ok(unfunded_channel.tx_add_input(msg).into_msg_send_event(counterparty_node_id)) | ||
| }, | ||
| None => Err("tx_add_input"), | ||
| } | ||
| Ok(channel.tx_add_input(msg)?.into_msg_send_event(counterparty_node_id)) |
There was a problem hiding this comment.
Both tx_add_input and internal_tx_msg have their own error strings that when combined don't make sense. We should probably drop the one from internal_tx_msg and have tx_add_input, etc. return a ChannelError.
| // TODO try_channel_entry() | ||
| let splice_ack_msg = chan_entry.get_mut().splice_init(msg, our_funding_contribution, &self.signer_provider, |
There was a problem hiding this comment.
Any reason this is a TODO?
| } else { | ||
| return Err(MsgHandleErrInternal::send_err_msg_no_close("Channel is not funded, cannot splice".to_owned(), msg.channel_id)); | ||
| // Handle inside channel | ||
| let tx_msg_opt = chan_entry.get_mut().splice_ack(msg, &self.signer_provider, &self.entropy_source, &self.get_our_node_id(), &self.logger) |
There was a problem hiding this comment.
Why are we not using try_channel_entry anymore?
| @@ -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.
| our_funding_inputs: Vec::new(), // inputs go directly to [`FundingNegotiationContext`] above | ||
| awaiting_splice_ack: false, // we don't need any additional message for the handshake | ||
| refunding_scope, | ||
| }); | ||
| // TODO(splicing): Store msg.funding_pubkey |
lightning/src/ln/channel.rs
Outdated
| /// Data needed during splicing -- | ||
| /// when the funding transaction is being renegotiated in a funded channel. | ||
| #[cfg(splicing)] | ||
| struct RefundingScope { |
There was a problem hiding this comment.
I'm still not convinced this is helpful, FundedChannel and RefundingScope are almost the same, why not just implement the trait directly on FundedChannel?
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)