Mixed mode splicing #4261
Mixed mode splicing #4261
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
jkczyz
force-pushed
the
2025-12-splice-in-and-out
branch
2 times, most recently
from
fc608ab to
a89b894
Compare
jkczyz
force-pushed
the
2025-12-splice-in-and-out
branch
2 times, most recently
from
d9f02da to
c9cade5
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4261 +/- ##
========================================
Coverage 89.33% 89.34%
========================================
Files 180 180
Lines 139042 139228 +186
Branches 139042 139228 +186
========================================
+ Hits 124219 124393 +174
- Misses 12196 12207 +11
- Partials 2627 2628 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
When adding support for mixed splice-in and splice-out, the contribution amount will need to be computed based on the splice-in and splice-out values. Rather than add a third variant to SpliceContribution, which could have an invalid contribution amount, use a more general struct that can represent splice-in, splice-out, and mixed. Constructors are provided for the typical splice-in and splice-out case whereas support for the mixed case will be added in an independent change.
Some splicing use cases require to simultaneously splice in and out in the same splice transaction. Add support for such splices using the funding inputs to pay the appropriate fees just like the splice-in case, opposed to using the channel value like the splice-out case. This requires using the contributed input value when checking if the inputs are sufficient to cover fees, not the net contributed value. The latter may be negative in the net splice-out case.
|
🔔 1st Reminder Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review. |
1 similar comment
|
🔔 1st Reminder Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review. |
jkczyz
force-pushed
the
2025-12-splice-in-and-out
branch
from
c9cade5 to
175bf79
Compare
| }, | ||
| pub struct SpliceContribution { | ||
| /// The amount to contribute to the splice. | ||
| value: SignedAmount, |
There was a problem hiding this comment.
Can you remind me why we need this? Can we not just have a constructor that calculates the change output and adds it to outputs if needed?
There was a problem hiding this comment.
There's a bunch of others things need to calculate change (e.g., signer provider, channel keys id, fee rate, holder dust limit, shared input/output). See:
rust-lightning/lightning/src/ln/channel.rs
Lines 6678 to 6717 in e663517
It also checks if we have enough input to pay for change, so the constructor would be be fallible.
Maybe some of that code can be moved here using some fake values for the shared output, for instance. It's currently used for dual funding, too, though. The user would need to obtain and pass the shared input unless a fake is also fine. Not sure if this would be worth it, though.
|
|
||
| /// The inputs included in the splice's funding transaction to meet the contributed amount | ||
| /// plus fees. Any excess amount will be sent to a change output. | ||
| inputs: Vec<FundingTxInput>, |
There was a problem hiding this comment.
Should we just leave these fields public as they were (implicitly cause it was an enum)? Could then presumably drop the splice_in_and_out constructor?
There was a problem hiding this comment.
Hmm... not sure if we want the user to calculate the net contribution value given it is partly derived from the supplied outputs.
Maybe we could actually keep it as an enum (adding an extra variant) and have a method to derive the net contribution? I'm not 100% certain we need to use a struct, and the enum approach is nice because the fields are named when initializing a SpliceContribution variant.
3 participants
Some splicing use cases require to simultaneously splice in and out in the same splice transaction. Add support for such splices using the funding inputs to pay the appropriate fees just like the splice-in case, opposed to using the channel value like the splice-out case. This requires using the contributed input value when checking if the inputs are sufficient to cover fees, not the net contributed value. The latter may be negative in the net splice-out case.