Produce a single monitor update per commitment number by tankyleo · Pull Request #3738 · lightningdevkit/rust-lightning

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo · 2025-04-15T16:36:30Z

 Produce a single monitor update per commitment number
Such updates will contain a single HTLC-source table for that
commitment number, together with a vector of commitment transactions
created at that commitment number. This vector will grow with the number
of pending splices for a channel.
The HTLC-source table produced by channel will stop storing information
on which HTLCs were assigned which output index. Instead, this
information will be stored in each commitment transaction in the
monitor update.
This commit deduplicates the `HTLCSource` collection for each commitment
number, but `HTLCOutputData` would store information already stored in
each `CommitmentTransaction` in a monitor update.
This is a partial rework of b8a03cd. That commit has not been shipped in
a release yet.

ldk-reviews-bot · 2025-04-15T16:36:33Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tankyleo · 2025-04-15T17:13:57Z

@TheBlueMatt this is what we've been discussing with @wpaulino can we get your impression of this approach ? Thank you.

tankyleo · 2025-04-15T17:16:13Z

A high level overview of how I am thinking these new monitor updates will get produced on channel / tx-builder side:

Channel ───────────► HTLC Outputs─────────────────────► HTLC Outputs │ │ │ │ └►──────► TX Builder ─────────► Commitment Transcation

TheBlueMatt

Design makes sense to me.

wpaulino · 2025-04-15T19:18:52Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

wpaulino · 2025-04-15T19:30:43Z

+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),
+	},
+	(7, LatestCounterpartyCommitmentTXs) => {


Should be even, and the members below should be odd

wpaulino · 2025-04-15T19:30:54Z

+ (0, htlc_data, required_vec),
+ (2, commitment_txs, required_vec),
+ (4, claimed_htlcs, required_vec),


Should be odd

wpaulino · 2025-04-15T19:31:42Z

+	(0, offered, required),
+	(2, amount_msat, required),
+	(4, cltv_expiry, required),
+	(6, payment_hash, required),


Should be odd

codecov · 2025-04-16T02:58:14Z

Codecov Report

Attention: Patch coverage is 40.42553% with 28 lines in your changes missing coverage. Please review.

Project coverage is 89.19%. Comparing base (83e9e80) to head (0b93e43).
Report is 5 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	6.89%	27 Missing ⚠️
lightning/src/ln/channel.rs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #3738 +/- ##
==========================================
+ Coverage 89.12% 89.19% +0.06% 
==========================================
Files 156 156 Lines 123514 123984 +470 Branches 123514 123984 +470 ==========================================
+ Hits 110086 110582 +496 + Misses 10749 10734 -15 + Partials 2679 2668 -11

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

Such updates will contain a single HTLC-source table for that commitment number, together with a vector of commitment transactions created at that commitment number. This vector will grow with the number of pending splices for a channel. The HTLC-source table produced by channel will stop storing information on which HTLCs were assigned which output index. Instead, this information will be stored in each commitment transaction in the monitor update. This commit deduplicates the `HTLCSource` collection for each commitment number, but `HTLCOutputData` would store information already stored in each `CommitmentTransaction` in a monitor update. This is a partial rework of b8a03cd. That commit has not been shipped in a release yet.

TheBlueMatt · 2025-04-16T14:26:08Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.

Why do we not want to keep them separate now?

tankyleo · 2025-04-16T15:00:17Z

@TheBlueMatt note that going with this design will mean undoing a good chunk of the work in #3664 to no longer keep the non-dust sources separate. Should be fine as long as we get it shipped in the same release.
Why do we not want to keep them separate now?

The HTLC-source table now no longer holds "dust-vs-nondust" data; that information is now solely stored in each CommitmentTransaction.

So in the updates, we no longer have this concept of a "dust-vs-nondust source"; they are all part of a single vector that contains all the sources for this set of commitment transactions.

TheBlueMatt · 2025-04-16T19:41:37Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

tankyleo · 2025-04-16T19:51:15Z

Right, but why? I guess now because there's many commitment txn we will no longer rely on the HTLCs to be sorted in commitment-tx-order and so now it doesn't matter (and HTLCs could theoretically be dust in some commitments but not in others)?

The HTLCs could be sorted in the same commitment tx order across funding scopes, but the transaction output indices of the HTLCs might vary, as which index the non-HTLC outputs get assigned to might vary across funding scopes - because of the different channel_value_satoshis, to_remote and to_local will get different amounts.

Right now though I don't see a way for a HTLC to be dust in one scope, and non-dust in another scope... but looks like this will change with dynamic commitments if I recall.

Looking at BOLT PR 1117 yes - that is a proposal to vary the dust_limit_satoshis across funding scopes.

TheBlueMatt · 2025-04-16T20:37:20Z

Right, so basically there's no point in splitting by dust/non-dust because we're not longer going to be able to rely on the order of the HTLCSources in the update, and instead now have to scan them when we need them, so we just shove them all in the update in a big heap cause it doesn't matter. Makes sense to me.

wpaulino · 2025-07-08T19:46:29Z

Done in #3855

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

tankyleo force-pushed the one-update-per-commitment-number branch from 2adce74 to 829402cCompare April 15, 2025 17:11

TheBlueMatt reviewed Apr 15, 2025
View reviewed changes

Comment threadlightning/src/ln/chan_utils.rs Outdated
Comment threadlightning/src/chain/channelmonitor.rs

wpaulino reviewed Apr 15, 2025
View reviewed changes

tankyleo force-pushed the one-update-per-commitment-number branch 2 times, most recently from 8fd9765 to 0b93e43Compare April 16, 2025 02:49

tankyleo force-pushed the one-update-per-commitment-number branch from 0b93e43 to 8ac0358Compare April 16, 2025 03:06

TheBlueMatt mentioned this pull request Apr 21, 2025
Revert separate non-dust HTLC sources for holder commitments #3745
Closed

wpaulino closed this Jul 8, 2025

Uh oh!

Conversation

tankyleo commented Apr 15, 2025

Uh oh!

ldk-reviews-bot commented Apr 15, 2025

Uh oh!

tankyleo commented Apr 15, 2025

Uh oh!

tankyleo commented Apr 15, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

wpaulino commented Apr 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Apr 16, 2025

Uh oh!

tankyleo commented Apr 16, 2025

Uh oh!

TheBlueMatt commented Apr 16, 2025

Uh oh!

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

Uh oh!

Uh oh!

TheBlueMatt commented Apr 16, 2025

Uh oh!

wpaulino commented Jul 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

tankyleo commented Apr 15, 2025

Uh oh!

ldk-reviews-bot commented Apr 15, 2025

Uh oh!

tankyleo commented Apr 15, 2025

Uh oh!

tankyleo commented Apr 15, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

wpaulino commented Apr 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Apr 16, 2025

Uh oh!

tankyleo commented Apr 16, 2025

wpaulino commented Apr 15, 2025•
edited
Loading

codecovBot commented Apr 16, 2025•
edited
Loading

tankyleo commented Apr 16, 2025•
edited
Loading

wpaulino commented Apr 15, 2025•
edited
Loading

codecovBot commented Apr 16, 2025•
edited
Loading

tankyleo commented Apr 16, 2025•
edited
Loading

wpaulino commented Apr 15, 2025•
edited
Loading

codecovBot commented Apr 16, 2025•
edited
Loading