[0.1] Further backports and draft release notes by TheBlueMatt · Pull Request #4710 · lightningdevkit/rust-lightning

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

TheBlueMatt · 2026-06-17T21:18:26Z

Backports #4667, #4684, #4697, #4707, and #4709. Did not include #4673 as its not as trivial and I'm not really sure UTXO lokup implementors should ever return a dup result.

An offer advertising Quantity::Bounded expects at least one item, but is_valid_quantity accepted a quantity of 0 since it only checked the upper bound. Require the quantity to be greater than 0 so that an invoice request for 0 items is rejected as an InvalidQuantity. Co-Authored-By: Claude <noreply@anthropic.com> Backport of 7620124

The `chanmon_consistency` fuzz target found a reconnect ordering where `signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack` could both describe the same owed `revoke_and_ack`. The channel first received a `commitment_signed` whose monitor update completed, but the signer could not provide the next point or secret, leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer `revoke_and_ack` freed holding-cell HTLCs and produced a held monitor update. While that monitor update was still blocked, `channel_reestablish` saw the peer one state behind and recorded `monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending `commitment_signed`, so the messages could be replayed once monitor updating was restored. If the signer unblocked before the held monitor update was released, `signer_maybe_unblocked` generated and sent the already monitor-safe RAA using `signer_pending_revoke_and_ack`. The monitor-pending flag was not cleared at that point, so `monitor_updating_restored` later generated the same RAA again when the held update completed. The peer had already advanced after accepting the signer-unblocked RAA, so it rejected the duplicate secret as not corresponding to its current pubkey and force-closed. Fix this by clearing `monitor_pending_revoke_and_ack` in the signer-resume path only once a signer-pending RAA is actually being returned. Backport of 27223fd Conflicts resolved in: * lightning/src/ln/async_signer_tests.rs

If we have a high (200%+) proportional fee as an intermediate blinded node combined with a low inbound amount, we previously had some code that calculated the outbound amount of the forward that would've underflowed. This would've caused a panic in debug builds and caused us to relay a payment that should've been rejected (due to being unable to cover our high fee) in release builds. Reported by Project Loupe. Backport of e560ec1

If a caller of send_payment_with_route provided a route with either no paths, or where the first path had 0 hops, the method would panic due to attempting to unwrap a dummy pubkey that was initialized with 32 bytes instead of the required 33. Reported by Project Loupe. Backport of 54cdd85

ldk-reviews-bot · 2026-06-17T21:18:31Z

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

ldk-claude-review-bot · 2026-06-17T21:20:38Z

The diff is unchanged from my prior two review passes, as confirmed by my memory notes. All production code changes remain correct.

No issues found.

The diff is unchanged from prior review passes. All production code changes remain correct:

lightning/src/blinded_path/payment.rs:525 — inbound_amt.checked_sub(fee)? properly guards the underflow and returns None as documented.
lightning/src/ln/channelmanager.rs:4728 — dummy pubkey corrected to [2; 33] (valid 33-byte compressed key length).
lightning-custom-message/src/lib.rs:366 — Ok(None) instead of unreachable!() correctly handles peer-provided unknown message types within a sub-handler's range.
lightning/src/offers/offer.rs:908 — quantity > 0 && quantity <= n.get() correctly rejects 0 for bounded quantities.
lightning/src/ln/channel.rs:6122 — clearing monitor_pending_revoke_and_ack when an RAA is regenerated via the signer-pending path prevents duplicate RAA generation.

The remaining additions are tests and CHANGELOG release notes, consistent with the fixes.

tnull

Reviewed release notes, LGTM

TheBlueMatt · 2026-06-18T13:53:51Z

Updated release notes with feedback incl from #4706:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4d259c7a23..5fb5c9b157 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -9,3 +9,4 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in BOLT 12 `OfferBuilder` (#4324).+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ now maps 0-amounts to an amount of `None` (#4324).@@ -20,3 +21,4 @@
could have become stuck (#4520).
- * The electrum sync client now properly skips unconfirmed transactions (#4590).+ * The presence of unconfirmed transactions actually no longer causes+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
* `FilesystemStore::list_all_keys` will no longer fail if there are stale

TheBlueMatt · 2026-06-18T16:03:48Z

Fixed a typo and named the release:

$ git diff-tree -U1 e2c8d21de 5cac547d1
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5fb5c9b157..a6fd5bfb18 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - XXX - "XXX"+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"@@ -9,3 +9,3 @@
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuidler`+ * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).

TheBlueMatt · 2026-06-18T16:13:26Z

Fixed further typos from #4706

diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6fd5bfb18..67e929a5fc 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -3,9 +3,9 @@
## API Updates
- * `DefaultMessageRouter` will now always generate blinded message paths which+ * `DefaultMessageRouter` will now always generate blinded message paths that
provide no privacy (where our node is the introduction node) for nodes with
public channels. This works around an issue which will appear for any nodes
- with LND peers which enable onion messaging - such peers will refuse to+ with LND peers that enable onion messaging - such peers will refuse to
forward BOLT 12 messages from unknown third parties, which most BOLT 12
payers rely on today (#4647).
- * Explicit `amount_msats` of 0 is rejected in `Bolt12Offer`s, `OfferBuilder`+ * Explicit `amount_msats` of 0 is rejected in BOLT 12 `Offer`s; `OfferBuilder`
now maps 0-amounts to an amount of `None` (#4324).
@@ -31,3 +31,3 @@
`ChannelManager::abandon_payment` was called before the payment ultimately
- completing anyway (#4651).+ completes anyway (#4651).
* Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
@@ -44,4 +44,4 @@
* `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
- `Bolt12Offer` allowing any quantity up to a bound (#4667).- * `lightning-custom-message` handlers which return `Ok(None)` when asked to+ BOLT 12 `Offer`, allowing any quantity up to a bound (#4667).+ * `lightning-custom-message` handlers that return `Ok(None)` when asked to
deserialize a message in their defined range no longer cause panics (#4709).

valentinewallace · 2026-06-18T16:20:57Z

@@ -1,9 +1,67 @@
+# 0.1.10 - Jun 18, 2026 - "An Older Loupe"


A Strange Loupe
Loupe de Loupe

I was thinking in reference to the Through the Loupe for 0.2.3. What is strange in reference to?

Ahh. It's a famous book (I haven't read it) https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop

Took Loupe de Loupe.

TheBlueMatt · 2026-06-18T17:01:41Z

Corrected the text for 4697:

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 67e929a5fc..09dfe4e55e 100644
--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -1,2 +1,2 @@-# 0.1.10 - Jun 18, 2026 - "An Older Loupe"+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"@@ -26,3 +26,4 @@
* When forwarding an HTLC while in a blinded path with proportional fees over
- 100%, LDK will no longer spuriously charge 1 msat too little (#4697).+ 200%, LDK will no longer spuriously allow a forward that pays us 1 msat too+ little in fees (#4697).
* Fixed a rare case where a channel could get stuck on reconnect when using

A handler built with `composite_custom_message_handler!` routes an incoming message type to the sub-handler whose pattern matches it and assumed the sub-handler would always decode it. But per the `CustomMessageReader` contract a sub-handler returns `Ok(None)` for a type it doesn't recognize, and a sub-handler's pattern -- a range in particular -- can be broader than the types it actually decodes. Since the message type comes from peer input, this let a remote peer panic the message-processing thread with a single custom message whose type falls in a sub-handler's pattern but isn't decoded by it. Report such a message as unknown instead, matching how `wire::do_read` handles an undecoded custom message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Backport of 77ac339 Silent conflicts resolved in: * lightning-custom-message/src/lib.rs

TheBlueMatt · 2026-06-18T17:20:20Z

Fixed a backport missed conflict:

diff --git a/lightning-custom-message/src/lib.rs b/lightning-custom-message/src/lib.rs
index 0f55dcb842..5a9fa691dc 100644
--- a/lightning-custom-message/src/lib.rs+++ b/lightning-custom-message/src/lib.rs@@ -512,3 +512,3 @@ mod tests {
type CustomMessage = Foo;
- fn read<R: LengthLimitedRead>(+ fn read<R: Read>(
&self, message_type: u16, _b: &mut R,

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

jkczyzand others added 4 commits June 17, 2026 20:07

This was referenced Jun 17, 2026
Reject quantity of 0 for offers with bounded quantity #4667
Merged
Clear monitor-pending RAA once regenerated #4684
Merged
Fix underflow in blinded path amt_to_forward #4697
Merged
Fix invalid dummy pubkey in send_to_route #4707
Merged

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5ed4dcc to 167d648Compare June 17, 2026 21:20

TheBlueMatt mentioned this pull request Jun 17, 2026
Don't panic when a composite sub-handler returns Ok(None)#4709
Merged

ldk-reviews-bot requested a review from wpaulino June 17, 2026 21:28

tnull approved these changes Jun 18, 2026
View reviewed changes

tnull reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21Compare June 18, 2026 13:53

valentinewallace reviewed Jun 18, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated
Comment threadCHANGELOG.md Outdated

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547Compare June 18, 2026 16:01

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3eCompare June 18, 2026 16:12

valentinewallace approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch 2 times, most recently from d35fa91 to 43efc52Compare June 18, 2026 17:01

jkczyzand others added 2 commits June 18, 2026 17:19

Draft 0.1.10 release notes
e225350

TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 43efc52 to e225350Compare June 18, 2026 17:19

TheBlueMatt mentioned this pull request Jun 18, 2026
0.1.3 final backports #4720
Merged

jkczyz approved these changes Jun 18, 2026
View reviewed changes

TheBlueMatt merged commit 0cf27ff into lightningdevkit:0.1Jun 18, 2026
3 checks passed

Uh oh!

Conversation

TheBlueMatt commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-claude-review-bot commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

valentinewallaceJun 18, 2026• 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 commented Jun 18, 2026

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

TheBlueMatt commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-claude-review-bot commented Jun 17, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

TheBlueMatt commented Jun 18, 2026

Uh oh!

valentinewallaceJun 18, 2026• 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 commented Jun 18, 2026

TheBlueMatt commented Jun 17, 2026•
edited
Loading

ldk-reviews-bot commented Jun 17, 2026•
edited
Loading

ldk-claude-review-bot commented Jun 17, 2026•
edited
Loading

valentinewallaceJun 18, 2026•
edited
Loading

TheBlueMatt commented Jun 17, 2026•
edited
Loading

ldk-reviews-bot commented Jun 17, 2026•
edited
Loading

ldk-claude-review-bot commented Jun 17, 2026•
edited
Loading

valentinewallaceJun 18, 2026•
edited
Loading

TheBlueMatt commented Jun 17, 2026•
edited
Loading

ldk-reviews-bot commented Jun 17, 2026•
edited
Loading

ldk-claude-review-bot commented Jun 17, 2026•
edited
Loading

valentinewallaceJun 18, 2026•
edited
Loading