-
Notifications
You must be signed in to change notification settings - Fork 366
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
Interactive TX negotiation tracks shared outputs #2989
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2989 +/- ##
==========================================
+ Coverage 89.15% 91.11% +1.96%
==========================================
Files 118 118
Lines 97678 107009 +9331
Branches 97678 107009 +9331
==========================================
+ Hits 87080 97496 +10416
+ Misses 8357 7145 -1212
- Partials 2241 2368 +127 ☔ View full report in Codecov by Sentry. |
b20679f
to
50dce76
Compare
Changed |
ef18e92
to
ae57869
Compare
Sorry about this, but I've reverted this in #2981 as there just ended up being too much cloning going around. I believe we will still be fine with the splicing additions here to have single maps for inputs/outputs. Edit: I've also removed the minimal splicing specific stuff from #2981 so that all that can be done atomically in this PR. See: #2981 (comment). Basically just removed the So a PR title change might be appropriate here. Thanks! 🙏 |
ae57869
to
eaf76f6
Compare
Rebased after merge of #2981 . |
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.
Apologies for the delay. I've done some initial review and so far LGTM. Did you want to tackle splicing calculations in a separate PR? I was thinking it would be okay to do that here and track the shared inputs too. Or do imagine that to be quite involved and more than a few extra commits?
Either way this looks good to take out of draft if you're happy and I'll give it another round once you're happy 🙂
e43786c
to
0cf4681
Compare
With current state of splicing work, I still don't see exactly the way (and the need) to track the shared output, so I would defer that to the time splicing is added. |
Folded in proposed comment changes; marked ready for review. |
Thanks. I'll give this another look over today. |
0cf4681
to
83f7845
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.
LGTM. I'm currently writing some more tests at the channelmanager-level to cover some more interesting funding cases.
Looking forward to rebasing on this.
83f7845
to
9869e48
Compare
Made some smaller changes according to review comments. |
The last review questions made me thinking, if the API can be made more straightforward. The user of the Maybe it would be better to wrap the provided outputs in an enum, for different types:
Additionally, for the infrequent case when we don't specify any outputs, but expect a shared output and some balance belonging to us, an optional (pubkey+localvalue) should be provided. Maybe this way the API would be easier to understand. |
Rather than pushing type info upstream, maybe we should have simpler (public) constructors for the |
9869e48
to
02a8244
Compare
Reworked:
|
Good idea, though this version aims at dual funding only (only funding outputs), splicing is not considered in this PR |
I've been writing some new tests for #2302 and have encountered some issues due to not tracking the shared output within the constructor and when validating the constructed tx, so this PR is a little bit of a blocker for 2302. I'll integrate these changes for now though so I can carry on with the new tests. :) |
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.
Sorry for the delay here :(
02a8244
to
85350fe
Compare
Addressed review comments (sorry, they fall of my priority table...). Remaining outstanding:
|
3163ffc
to
6a2d787
Compare
Did remaining changes:
|
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.
Just some comment nits, but LGTM. I believe this needs to be formatted with rustfmt
as it's not excluded.
6a2d787
to
80eb5ce
Compare
Did formatting, plus 2 minor comment wording change (review). |
Since this only affects |
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.
Post-merge ACK, but a few nits.
}, | ||
OutputOwned::Shared(output) => { | ||
// Sanity check | ||
if output.local_owned > output.tx_out.value.to_sat() { |
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 should be >=
, right (as = should have gone through SharedControlFullyOwned
)?
/// its ownership -- value fully owned by the adder or jointly | ||
#[derive(Clone, Debug, Eq, PartialEq)] | ||
pub enum OutputOwned { | ||
/// Belongs to local node -- controlled exclusively and fully belonging to local node |
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 is wrong, right? Single
maybe be owned by the counterparty, depending on where its stored.
} | ||
|
||
#[derive(Clone, Debug, Eq, PartialEq)] | ||
pub struct InteractiveTxOutput { |
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.
There's no reason for this to be pub
, right? Its an internal abstraction.
} | ||
|
||
#[derive(Clone, Debug, Eq, PartialEq)] | ||
pub enum InteractiveTxInput { |
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.
There's no reason for this to be pub
, right? Its an internal abstraction.
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.
Looks like visibility could be reduced indeed. I will check in the wider scope where this class is actually used.
These are used in ConstructedTransaction
, which is pub(crate)
.
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.
Sounds good, thanks. A followup reducing visibility of the nits here would be much appreciated.
Interactive TX negotiation now tracks the shared funding output. This allows for better checks, better contribution verification.
Shared inputs are not included, those are splicing-specific, shall be done later.
Besed on 36e7452 by @dunxen .
One notable change is that local/remote contribution are not computed by filtering by serial_id and adding values, but summing local/remote values across all inputs/outputs (i.e. in
build_transaction()
https://github.com/lightningdevkit/rust-lightning/pull/2989/files#diff-c92e994fd9949ebcb6a8d9ec76553e8497ee223b707b51905e35017b80124c77R467).Housekeeping: this should come after #2981