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

[Custom Transactions] Commitment Transaction & Channel Refactors #3606

Merged
merged 10 commits into from
Mar 25, 2025

Conversation

tankyleo
Copy link
Contributor

@tankyleo tankyleo commented Feb 18, 2025

Miscellaneous refactors of CommitmentTranscation and channel in preparation for the upcoming TxBuilder trait. See the commit messages.

@arik-so
Copy link
Contributor

arik-so commented Feb 19, 2025

Do you also wanna add the cfg-gate to the CI testing configs?

@tankyleo
Copy link
Contributor Author

Do you also wanna add the cfg-gate to the CI testing configs?

Thank you done

Copy link

codecov bot commented Feb 19, 2025

Codecov Report

Attention: Patch coverage is 97.97297% with 3 lines in your changes missing coverage. Please review.

Project coverage is 89.25%. Comparing base (4c43a5b) to head (1b5bcb0).

Files with missing lines Patch % Lines
lightning/src/ln/channel.rs 97.11% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3606      +/-   ##
==========================================
+ Coverage   89.18%   89.25%   +0.06%     
==========================================
  Files         155      155              
  Lines      119274   119206      -68     
  Branches   119274   119206      -68     
==========================================
+ Hits       106379   106393      +14     
+ Misses      10290    10223      -67     
+ Partials     2605     2590      -15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@tankyleo tankyleo changed the title [Custom Transactions] Define ChannelParameters, TxBuilder traits [Custom Transactions] Define the TxBuilder trait Feb 20, 2025
@tankyleo
Copy link
Contributor Author

tankyleo commented Feb 20, 2025

Rebase:

  • Remove the ChannelParameters trait - focus on the basics for now, we can add the bells and whistles later, as needed.
  • Add the trimmed_value_sat parameter to build_commitment_transaction to cover the case where the sum of the trimmed outputs gets added to an ephemeral anchor output.
  • Add ChannelSigner::derive_tx_builder method. For now we specify the exact type to return, can be made generic later.

@tankyleo
Copy link
Contributor Author

Notes:

  • First commit defines the API, then second commit demonstrates a full integration of this API into the codebase. This is so that we can have more context for the API discussion, happy to drop it. It does not change the public API, but does require changes to persistence.
  • ChannelContext::build_commitment_transaction sorts the htlcs based on their state,
  • then TxBuilder::build_commitment_transaction sorts the htlcs based on the dust limit.
  • Now we do not tell TxBuilder the trimmed value - TxBuilder decides this - but does it need to let us know the trimmed value? I don't see an immediate need.
  • We now return CommitmentStats, but without the preimages.

@tankyleo tankyleo requested a review from TheBlueMatt February 24, 2025 06:00
@jkczyz jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025
@tankyleo
Copy link
Contributor Author

Note that this PR now breaks the public API of CommitmentTransaction.

@tankyleo tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79 Compare February 27, 2025 21:26
@tankyleo tankyleo requested a review from wpaulino March 4, 2025 06:40
@tankyleo tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997a Compare March 6, 2025 21:02
@tankyleo
Copy link
Contributor Author

tankyleo commented Mar 6, 2025

@wpaulino just chatted with @TheBlueMatt offline some takeaways:

  • TxBuilder takes a Vec<HTLCOutputInCommitment>, then channel does a brute force search to populate the output indices. We are ok with the performance.
  • When / if we refactor ChannelTransactionParameters to get rid of all these unwraps, as you suggested, we can include the dust limits in the parameters too, and drop one more field. Does not have to happen before this PR.
  • I will immediately drop the channel_value_satoshis field, and take it from ChannelTransactionParameters.

@tankyleo
Copy link
Contributor Author

Rebase: switch from saturating subs to checked subs, update comments, delete broken test vector.

TheBlueMatt
TheBlueMatt previously approved these changes Mar 14, 2025
The `DirectedChannelTransactionParameters` argument of the
`CommitmentTransaction` constructor already contains the broadcaster,
and the countersignatory public keys, which include the respective
funding keys.

It is therefore not necessary to ask for these funding keys in
additional arguments.
Instead of asking callers to generate the `TxCreationKeys` on every new
commitment before constructing a `CommitmentTransaction`, this commit
lets `CommitmentTransaction` derive the `TxCreationKeys` it will use to
build the raw commitment transaction.

This allows a tighter coupling between the per-commitment keys, and the
corresponding commitment transaction.

As new states are generated, callers now only have to derive new
commitment points; `CommitmentTransaction` takes care of deriving the
per-commitment keys.

This commit also serves to limit the objects in LDK that derive
per-commitment keys according to the LN Specification in preparation
for enabling custom derivations in the future.
Channel objects should not impose a particular per-commitment derivation
scheme on the builders of commitment transactions. This will make it
easier to enable custom derivations in the future.

Instead of building `TxCreationKeys` explicitly, the function
`TrustedCommitmentTransaction::keys` should be used when the keys of the
commitment transaction are needed. We do that in this commit.
The logging for loop in `send_commitment_no_state_update` only iterates
over the non-dust HTLCs. Thus we do not need to create a
`Vec<HTLCOutputInCommitment>` that includes both dust and non-dust
HTLCs, we can grab the `Vec<HTLCOutputInCommitment>` that holds only
non-dust HTLCs directly from `CommitmentTransaction`.
@tankyleo tankyleo requested a review from TheBlueMatt March 18, 2025 00:57
@tankyleo
Copy link
Contributor Author

In case it helps, git diff 4605318 fe0f94c contains the changes from Wilmer's last approval.

Then the fe0f94c to ee8b846 is a rebase on main where I fix some conflicts in channel monitor.

Instead of converting operands to `i64` and checking if the subtractions
overflowed by checking if the `i64` is smaller than zero, we instead
choose to do checked and saturating subtractions on the original
unsigned integers.
There is no need for an if statement if it will always be true.
The fields `feerate_per_kw` and `num_nondust_htlcs` of `CommitmentStats`
can both be accessed directly from the `tx: CommitmentTransaction`
field.

We also take this opportunity to rename the balance fields to make it
extra clear what they refer to.
We choose to include in `CommitmentStats` only fields that will be
calculated or constructed by transaction builders.

The other fields are created by channel, and placed in a new struct
we call `CommitmentData`.
The saturating subtractions used in
`ChannelContext::build_commitment_transaction` are there for a reason;
when the remote party updates the fees, we build the new commitment
transaction before checking whether the remote party has enough balance
to cover the new fee, so we cannot guarantee that the remote party's
balance will be greater than or equal to the sum of the fee and the
anchors.
@tankyleo
Copy link
Contributor Author

Rebase from ee8b846 to ff259ba: correct the i64 casts commit message.

@TheBlueMatt TheBlueMatt removed their request for review March 18, 2025 19:13
@tankyleo tankyleo requested a review from TheBlueMatt March 24, 2025 17:30
value_to_self_msat_offset -= htlc.amount_msat as i64;
},
OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |
Copy link
Collaborator

Choose a reason for hiding this comment

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

AwaitingRemovedRemoteRevoke isn't a tautology because it is always !include even if generated_by_local.

Copy link
Contributor Author

@tankyleo tankyleo Mar 24, 2025

Choose a reason for hiding this comment

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

I don't think I make any changes to that variant ? As before, always subtract from the offset.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm off on the vocabulary, the tautology to me is the !generated_by_local expression below.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sheesh I was more tired than I thought :(

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no problem

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.

Otherwise lgtm

if msg.htlc_signatures.len() != commitment_stats.num_nondust_htlcs {
return Err(ChannelError::close(format!("Got wrong number of HTLC signatures ({}) from remote. It must be {}", msg.htlc_signatures.len(), commitment_stats.num_nondust_htlcs)));
if msg.htlc_signatures.len() != commitment_data.stats.tx.htlcs().len() {
return Err(ChannelError::close(format!("Got wrong number of HTLC signatures ({}) from remote. It must be {}", msg.htlc_signatures.len(), commitment_data.stats.tx.htlcs().len())));
Copy link
Collaborator

Choose a reason for hiding this comment

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

In a followup can we rename htlcs to nondust_htlcs or so? Would add a lot of clarity in a few places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

100%

@TheBlueMatt TheBlueMatt merged commit 5fe72b5 into lightningdevkit:main Mar 25, 2025
25 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
weekly goal Someone wants to land this this week
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants