-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dual funding extension, needed also for splicing: begin_interactive_funding_tx_construction #3443
base: main
Are you sure you want to change the base?
Conversation
|
4f7e41b
to
0448cf9
Compare
Did the following:
|
0448cf9
to
0e47819
Compare
48e0518
to
9e44d2b
Compare
9e44d2b
to
b7e7a34
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you update the commit message with the rationale for the change? (i.e., specifically how it will be used in splicing)
70fde13
to
b1ae668
Compare
Review comments addressed, all resolved from my side (left a few open for visibility) |
b1ae668
to
86f9680
Compare
86f9680
to
a379f1d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3443 +/- ##
==========================================
- Coverage 88.35% 88.28% -0.07%
==========================================
Files 149 149
Lines 112876 113074 +198
Branches 112876 113074 +198
==========================================
+ Hits 99727 99829 +102
- Misses 10669 10760 +91
- Partials 2480 2485 +5 ☔ View full report in Codecov by Sentry. |
a379f1d
to
9256a47
Compare
9256a47
to
5194458
Compare
Rebased. |
lightning/src/ln/channel.rs
Outdated
} | ||
|
||
let mut funding_inputs_prev_outputs: Vec<&TxOut> = Vec::with_capacity(funding_inputs.len()); | ||
// Check that vouts exist for each TxIn in provided transactions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems better suited as a validation check when we construct the DualFundingChannelContext
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this also check the txid of the txin matches the transaction's?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I will check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check makes sense when we obtain the prev TxOut's from the full prev transactions.
I considered the case when in DualFundingChannelContext
we would store only the TxOut
's, and check and obtain at creation, but the full txs are needed later.
As a middle ground I extracted the logic of checking and extracting into a helper method in DualFundingChannelContext
, that can be called when the TxOut's are needed.
Also CC @dunxen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to do the same validation for the counterparty's provided inputs, I wonder if we already have code for that, or if we can use this new one there now?
} | ||
|
||
// Add output for funding tx | ||
let mut funding_outputs = Vec::new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the spec allows you to specify additional outputs here as part of the interactive negotiation, which would be included here. I noticed we don't seem to track/request these from the user though, is this something we're not planning to support? cc @dunxen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's planned, but not in this PR.
}; | ||
let change_output_weight = get_output_weight(&change_output.script_pubkey).to_wu(); | ||
let change_output_fee = fee_for_weight(self.dual_funding_context().funding_feerate_sat_per_1000_weight, change_output_weight); | ||
change_output.value = Amount::from_sat(change_value.saturating_sub(change_output_fee)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the resulting value is below dust then we shouldn't include the output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! Turns out this is checked, in holder_dust_limit_satoshis()
, invoked a few lines above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to check again after we subtract the fee of the change output because it may not be enough anymore.
27868f8
to
fce05cb
Compare
fce05cb
to
fbde31f
Compare
Rebased (post Inbound/OutboundV2Channel merge #3498 ) |
Add these two methods to the current dual funding implementation:
begin_interactive_funding_tx_construction()
calculate_change_output_value()
These changes are in the pipeline for dual funding implementation, and needed for dual funding negotiation during splicing, in #3444 .