[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
| pending_unfunded_context: UnfundedChannelContext, | ||
| pending_dual_funding_context: DualFundingChannelContext, |
There was a problem hiding this comment.
We shouldn't need these for splicing
There was a problem hiding this comment.
What do you mean?
During splicing we perform a full transaction negotiation, and these are used in the process. begin_interactive_funding_tx_construction() uses dual_funding_context, and funding_tx_constructed() uses unfunded_context.
There was a problem hiding this comment.
Let's rename DualFundingChannelContext something like FundingNegotiationContext as discussed offline.
There was a problem hiding this comment.
- Unfunded context was removed; the trait has instead a
transaction_number()function. DualFundingChannelContexthas been renamed
| /// 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)
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).
| )?; | ||
|
|
||
| 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(); |
lightning/src/ln/channel.rs
Outdated
| 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?
There was a problem hiding this comment.
Good point. Still leftover to-do.
There was a problem hiding this comment.
Complete (commit d2554a8)
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. |
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)