[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
| impl<SP: Deref> PendingV2Channel<SP> where SP::Target: SignerProvider { | ||
| /// A channel struct implementing this trait can perform V2 transaction negotiation, | ||
| /// either at channel open or during splicing. | ||
| /// Accessors return a Result, because [`FundedChannel`] can act like a TX constructor, |
There was a problem hiding this comment.
Let's just make them all return an option? I don't see the error case being useful here
| fn pending_funding_mut(&mut self) -> Result<&mut FundingScope, &'static str>; | ||
| fn pending_funding_and_context_mut(&mut self) -> Result<(&FundingScope, &mut ChannelContext<SP>), &'static str>; | ||
| fn dual_funding_context(&self) -> Result<&DualFundingChannelContext, &'static str>; | ||
| fn swap_out_dual_funding_context_inputs(&mut self, funding_inputs: &mut Vec<(TxIn, TransactionU16LenLimited)>) -> Result<(), &'static str>; |
There was a problem hiding this comment.
Can we just get a mutable reference to the context to avoid this? This, along with the UnfundedContext, doesn't seem to apply for a splice anyway.
| pending_unfunded_context: UnfundedChannelContext, | ||
| pending_dual_funding_context: DualFundingChannelContext, |
There was a problem hiding this comment.
We shouldn't need these for splicing
| /// 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?
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).
| ChannelPhase::UnfundedV2(chan) => chan.tx_add_input(msg), | ||
| #[cfg(splicing)] | ||
| ChannelPhase::Funded(chan) => chan.tx_add_input(msg), | ||
| _ => panic!("Got tx_add_input in an invalid phase"), |
There was a problem hiding this comment.
We definitely don't want to panic. Peers can send any message at any point, and we shouldn't crash because of it.
| #[cfg(splicing)] | ||
| impl RefundingScope { | ||
| /// Get a transaction input that is the previous funding transaction | ||
| fn get_input_of_previous_funding(pre_funding_transaction: &Option<Transaction>, pre_funding_txo: &Option<OutPoint>) |
There was a problem hiding this comment.
This seems better suited as a method on FundedChannel
| )?; | ||
|
|
||
| let post_value_to_self_msat = self.funding().value_to_self_msat.saturating_add(our_funding_satoshis); | ||
| let mut post_channel_transaction_parameters = self.funding().channel_transaction_parameters.clone(); |
There was a problem hiding this comment.
This needs to have the funding key rotated
| counterparty_selected_channel_reserve_satoshis: self.funding.counterparty_selected_channel_reserve_satoshis, // TODO check | ||
| holder_selected_channel_reserve_satoshis: self.funding.holder_selected_channel_reserve_satoshis, // TODO check |
There was a problem hiding this comment.
These should be based on the new channel value, right?
| /// Accessors return a Result, because [`FundedChannel`] can act like a TX constructor, | ||
| /// but not always (only during splicing). |
There was a problem hiding this comment.
Hmm.... we could avoid needing Result by creating a temporary RenegotiatingFunding wrapper around &FundedChannel that implements FundingTxConstructorV2. It could be obtained using a as_renegotiating_funding method on FundedChannel. Basically, push the Result / Option check to when calling as_renegotiating_funding instead of all the other methods.
| fn pending_funding_mut(&mut self) -> Result<&mut FundingScope, &'static str>; | ||
| fn pending_funding_and_context_mut(&mut self) -> Result<(&FundingScope, &mut ChannelContext<SP>), &'static str>; | ||
| fn dual_funding_context(&self) -> Result<&DualFundingChannelContext, &'static str>; | ||
| fn swap_out_dual_funding_context_inputs(&mut self, funding_inputs: &mut Vec<(TxIn, TransactionU16LenLimited)>) -> Result<(), &'static str>; |
There was a problem hiding this comment.
Maybe just make a dual_funding_context_mut method and do the swap at the call site.
| chan.pending_splice.as_mut().map(|splice| | ||
| splice.refunding_scope.as_mut().map(|refunding_scope| &mut refunding_scope.pending_unfunded_context) | ||
| ).flatten() |
There was a problem hiding this comment.
Use and_then instead of map to avoid needing to call flatten. Likewise throughout this commit.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3736 +/- ##
==========================================
+ Coverage 89.10% 90.26% +1.16%
==========================================
Files 156 158 +2
Lines 123431 135623 +12192
Branches 123431 135623 +12192
==========================================
+ Hits 109985 122425 +12440
+ Misses 10760 10672 -88
+ Partials 2686 2526 -160 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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)