-
Notifications
You must be signed in to change notification settings - Fork 377
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.44% 88.36% -0.09%
==========================================
Files 149 149
Lines 113330 113532 +202
Branches 113330 113532 +202
==========================================
+ Hits 100238 100320 +82
- Misses 10621 10739 +118
- Partials 2471 2473 +2 ☔ 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.
fce05cb
to
fbde31f
Compare
Rebased (post Inbound/OutboundV2Channel merge #3498 ) |
665be4e
to
c9aa52f
Compare
c9aa52f
to
c186145
Compare
let remaining_value = | ||
total_input_satoshis.saturating_sub(our_contribution).saturating_sub(fees_sats); | ||
|
||
if remaining_value <= holder_dust_limit_satoshis { |
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.
Should we check remaining_value < 0
so that we can bail and return an insufficient funds error to the user?
self.dual_funding_context.funding_feerate_sat_per_1000_weight, | ||
self.context.holder_dust_limit_satoshis, | ||
) { | ||
let change_script = signer_provider.get_destination_script(self.context.channel_keys_id).map_err( |
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.
Ideally we allow the user to specify their own change address if they wish to
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 .