Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

optout21
Copy link
Contributor

@optout21 optout21 commented Apr 10, 2024

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

@codecov-commenter
Copy link

codecov-commenter commented Apr 10, 2024

Codecov Report

Attention: Patch coverage is 95.77465% with 24 lines in your changes are missing coverage. Please review.

Project coverage is 91.11%. Comparing base (0e22b12) to head (02a8244).
Report is 94 commits behind head on main.

Files Patch % Lines
lightning/src/ln/interactivetxs.rs 95.77% 18 Missing and 6 partials ⚠️

❗ 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.
📢 Have feedback on the report? Share it here.

@optout21
Copy link
Contributor Author

Changed NegotiationContext to store local and remote inputs/output in separate vectors (in separate commit for now)

@dunxen
Copy link
Contributor

dunxen commented Apr 23, 2024

Changed NegotiationContext to store local and remote inputs/output in separate vectors (in separate commit for now)

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 to_remote_value_satoshis and the check which wasn't necessarily complete for both splice in and out. So if you rebase and see that then just take note why it was removed.

So a PR title change might be appropriate here.

Thanks! 🙏

@optout21
Copy link
Contributor Author

Rebased after merge of #2981 .

@optout21 optout21 reopened this Apr 24, 2024
Copy link
Contributor

@dunxen dunxen left a 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 🙂

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
@optout21
Copy link
Contributor Author

optout21 commented May 2, 2024

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?

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.

@optout21 optout21 marked this pull request as ready for review May 2, 2024 06:12
@optout21
Copy link
Contributor Author

optout21 commented May 2, 2024

Folded in proposed comment changes; marked ready for review.

@dunxen
Copy link
Contributor

dunxen commented May 2, 2024

Folded in proposed comment changes; marked ready for review.

Thanks. I'll give this another look over today.

@@ -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 {
Copy link
Collaborator

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)?

Copy link
Contributor

@dunxen dunxen May 6, 2024

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What an awkward protocol...

Copy link
Contributor

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...

dunxen
dunxen previously approved these changes May 7, 2024
Copy link
Contributor

@dunxen dunxen left a 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.

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
@optout21
Copy link
Contributor Author

Made some smaller changes according to review comments.

@optout21 optout21 marked this pull request as draft May 10, 2024 09:40
@optout21
Copy link
Contributor Author

The last review questions made me thinking, if the API can be made more straightforward.

The user of the InteractiveTxConstructor has to supply the provided outputs (TxOut's), plus it has to provide the script pubkey of the expected shared output (one of the outputs), and its contribution from that. This setup has a few easy places for inconsistency.

Maybe it would be better to wrap the provided outputs in an enum, for different types:

  • shared output, but its value belonging entirely to initiator (typical funding output)
  • shared output, with partial value belonging initiator (this value has to be provided, this is a less typical case)
  • output belonging to initiator (e.g. change)

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.
I put the PR back to Draft, for a 2nd thought.

@TheBlueMatt
Copy link
Collaborator

Rather than pushing type info upstream, maybe we should have simpler (public) constructors for the InteractiveTxConstructor that are context-specific? ie InteractiveTxConstructor::for_splicing and InteractiveTxConstructor::for_dual_funding are kinda separate things, and could use separate constructors. That would simplify the public interface without adding more types for callers to keep track of.

@optout21
Copy link
Contributor Author

Reworked:

  • In the InteractiveTxConstructor::new(), the type of the contributed outputs has to be specified -- controlled by local node, shared output but all belongs to the local node, or shared output with joint ownership (split).
  • Additional expected shared output script has to be specified only in the rare case when the local node does not add a shared output, but expects the remote node to add a joint-owned shared output.

@optout21 optout21 marked this pull request as ready for review May 13, 2024 21:54
@optout21
Copy link
Contributor Author

Rather than pushing type info upstream, maybe we should have simpler (public) constructors for the InteractiveTxConstructor that are context-specific? ie InteractiveTxConstructor::for_splicing and InteractiveTxConstructor::for_dual_funding are kinda separate things, and could use separate constructors.

Good idea, though this version aims at dual funding only (only funding outputs), splicing is not considered in this PR

@optout21 optout21 requested a review from dunxen May 14, 2024 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants