[Splicing] Tx negotiation during splicing #3736
Open
+874
−143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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! |
This was referenced Apr 15, 2025
[Draft] RefundingChannel: combine FundedChannel and PendingV2Channel using a trait for Pending
#3720
Closed
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
wpaulino
reviewed
Apr 29, 2025
Comment on lines
+2757
to
+2758
| 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).
| )?; | ||
|
|
||
| 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
Comment on lines
+9124
to
+9125
| 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?
jkczyz
reviewed
Apr 29, 2025
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:
|
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).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)