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

Merged
merged 1 commit into from
Jun 27, 2024

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

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.

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
dunxen
dunxen previously approved these changes May 20, 2024
lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
@dunxen
Copy link
Contributor

dunxen commented May 21, 2024

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

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a 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 :(

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved
lightning/src/ln/interactivetxs.rs 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 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

optout21 commented Jun 18, 2024

Addressed review comments (sorry, they fall of my priority table...).

Remaining outstanding:

  • rebase
  • whether there should be a check in validate_tx for the existence of a shared output

@optout21 optout21 marked this pull request as draft June 18, 2024 15:38
@optout21 optout21 force-pushed the iatx-shared-output branch 3 times, most recently from 3163ffc to 6a2d787 Compare June 20, 2024 10:57
@optout21
Copy link
Contributor Author

Did remaining changes:

  • Add check for missing funding output in validate_tx()
  • Make expected_shared_funding_output mandatory in NegotiationContext, as suggested by @TheBlueMatt . In InteractiveTxConstructor either a shared output has to be provided, or a pubkey for the shared output to be added by the remote.

@optout21 optout21 marked this pull request as ready for review June 20, 2024 10:59
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.

Just some comment nits, but LGTM. I believe this needs to be formatted with rustfmt as it's not excluded.

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

Did formatting, plus 2 minor comment wording change (review).

@optout21
Copy link
Contributor Author

If this is merged before #3137, these interactivetx.rs changes will disappear from #3137 diff. That would make sense, as this PR has been mostly reviewed already.

@dunxen
Copy link
Contributor

dunxen commented Jun 27, 2024

If this is merged before #3137, these interactivetx.rs changes will disappear from #3137 diff. That would make sense, as this PR has been mostly reviewed already.

Yip, that's the plan. I just cherry-picked this.

@dunxen
Copy link
Contributor

dunxen commented Jun 27, 2024

Since this only affects interactivetxs.rs, I'm going to go ahead and merge this and any other nits/issues can be addressed in a follow-up. Then that should unblock 3137.

@dunxen dunxen merged commit cb08498 into lightningdevkit:main Jun 27, 2024
16 checks passed
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a 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() {
Copy link
Collaborator

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

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

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

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.

Copy link
Contributor Author

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

Copy link
Collaborator

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.

@TheBlueMatt TheBlueMatt mentioned this pull request Jul 11, 2024
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.

4 participants