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
base: main
Are you sure you want to change the base?
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. |
lightning/src/ln/interactivetxs.rs
Outdated
@@ -430,6 +463,14 @@ impl NegotiationContext { | |||
return Err(AbortReason::InvalidOutputScript); | |||
} | |||
|
|||
let txout = TxOut { value: msg.sats, script_pubkey: msg.script.clone() }; | |||
let output = if msg.script == self.intended_new_funding_output.script_pubkey { |
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.
Is this actually explicit in the splicing protocol (like our counterparty or we send an add_output
message, and who decides when and who to send it)?
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.
Initiator always sends the shared output (and input in the case of splicing, the shared input) but there is no restriction on when it is sent.
In the case of splicing, there is an explicit tlv for the funding txid which identifies it as the shared input. A funding output just looks like a regular tx_add_output so needs to be identified.
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.
What an awkward protocol...
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.
Yeah it's still strange...
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 |
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