[Custom Transactions] Commitment Transaction & Channel Refactors by tankyleo · Pull Request #3606 · lightningdevkit/rust-lightning

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo · 2025-02-18T05:39:57Z

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

arik-so · 2025-02-19T00:34:46Z

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

tankyleo · 2025-02-19T02:14:34Z

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

Thank you done

codecov · 2025-02-19T02:22:21Z

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 · 2025-02-20T05:04:56Z

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 · 2025-02-24T05:48:46Z

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 · 2025-02-27T19:29:28Z

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

tankyleo · 2025-03-06T22:11:27Z

@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 · 2025-03-13T23:18:41Z

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

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 · 2025-03-18T01:04:10Z

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 · 2025-03-18T06:00:28Z

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

TheBlueMatt · 2025-03-24T20:30:26Z

- value_to_self_msat_offset -= htlc.amount_msat as i64;
- },
+ OutboundHTLCState::AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome::Success(_)) |
+ OutboundHTLCState::AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome::Success(_)) |


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

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

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

Sheesh I was more tired than I thought :(

TheBlueMatt

Otherwise lgtm

TheBlueMatt · 2025-03-24T20:32:11Z

- 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())));


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

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

tankyleo mentioned this pull request Feb 18, 2025
Custom Transactions Tracking Issue #3603
Open
24 tasks

tankyleo force-pushed the 25-02-tx-builder branch from 81b0ecb to 647d42eCompare February 19, 2025 02:13

tankyleo commented Feb 19, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 647d42e to beec57fCompare February 20, 2025 04:59

tankyleo changed the title ~~[Custom Transactions] Define ChannelParameters, TxBuilder traits~~[Custom Transactions] Define the TxBuilder traitFeb 20, 2025

TheBlueMatt reviewed Feb 20, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from beec57f to 0c96878Compare February 24, 2025 05:36

tankyleo requested a review from TheBlueMatt February 24, 2025 06:00

TheBlueMatt reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs Outdated

wpaulino reviewed Feb 24, 2025
View reviewed changes

Comment threadlightning/src/sign/tx_builder.rs Outdated

tankyleo force-pushed the 25-02-tx-builder branch from 0c96878 to 11f6b5fCompare February 27, 2025 17:58

jkczyz added the weekly goal Someone wants to land this this week label Feb 27, 2025

tankyleo force-pushed the 25-02-tx-builder branch from 11f6b5f to 2f705d1Compare February 27, 2025 19:09

tankyleo requested review from TheBlueMatt and wpaulino February 27, 2025 19:19

tankyleo force-pushed the 25-02-tx-builder branch 2 times, most recently from 035e35f to 42d5a79Compare February 27, 2025 21:26

wpaulino reviewed Feb 28, 2025
View reviewed changes

TheBlueMatt reviewed Mar 1, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/chan_utils.rs Outdated

tankyleo requested a review from wpaulino March 4, 2025 06:40

tankyleo force-pushed the 25-02-tx-builder branch 3 times, most recently from d9c7ba9 to 9a1997aCompare March 6, 2025 21:02

tankyleo requested review from TheBlueMatt and wpaulino March 13, 2025 23:18

TheBlueMatt previously approved these changes Mar 14, 2025
View reviewed changes

tankyleo dismissed TheBlueMatt’s stale review via fe0f94cMarch 17, 2025 23:14

tankyleo force-pushed the 25-02-tx-builder branch from b27b9ee to fe0f94cCompare March 17, 2025 23:14

tankyleo added 5 commits March 17, 2025 23:20

Remove some unneeded Result's in CommitmentTransaction
9b71c64

tankyleo force-pushed the 25-02-tx-builder branch from fe0f94c to ee8b846Compare March 17, 2025 23:25

tankyleo requested a review from TheBlueMatt March 18, 2025 00:57

tankyleo added 5 commits March 18, 2025 05:43

Clean up tautologies in ChannelContext::build_commitment_transaction
22be385
There is no need for an if statement if it will always be true.

Reorg return values of ChannelContext::build_commitment_transaction
935a8fd
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`.

tankyleo force-pushed the 25-02-tx-builder branch from ee8b846 to ff259baCompare March 18, 2025 05:58

wpaulino approved these changes Mar 18, 2025
View reviewed changes

TheBlueMatt removed their request for review March 18, 2025 19:13

tankyleo requested a review from TheBlueMatt March 24, 2025 17:30

TheBlueMatt reviewed Mar 24, 2025
View reviewed changes

tankyleo mentioned this pull request Mar 24, 2025
Add ChannelContext::get_commitment_stats#3682
Merged

TheBlueMatt approved these changes Mar 25, 2025
View reviewed changes

TheBlueMatt merged commit 5fe72b5 into lightningdevkit:mainMar 25, 2025

wpaulino mentioned this pull request Mar 25, 2025
Replace use of HolderSignedTx with HolderCommitment #3664
Merged

Uh oh!

Conversation

tankyleo commented Feb 18, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arik-so commented Feb 19, 2025

Uh oh!

tankyleo commented Feb 19, 2025

Uh oh!

codecovBot commented Feb 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

tankyleo commented Feb 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tankyleo commented Feb 24, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tankyleo commented Feb 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tankyleo commented Mar 6, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tankyleo commented Mar 13, 2025

Uh oh!

tankyleo commented Mar 18, 2025

Uh oh!

tankyleo commented Mar 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tankyleoMar 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

tankyleo commented Feb 18, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tankyleo commented Feb 18, 2025•
edited
Loading

codecovBot commented Feb 19, 2025•
edited
Loading

tankyleo commented Feb 20, 2025•
edited
Loading

tankyleo commented Mar 6, 2025•
edited
Loading

tankyleoMar 24, 2025•
edited
Loading

tankyleo commented Feb 18, 2025•
edited
Loading

codecovBot commented Feb 19, 2025•
edited
Loading

tankyleo commented Feb 20, 2025•
edited
Loading

tankyleo commented Mar 6, 2025•
edited
Loading

tankyleoMar 24, 2025•
edited
Loading