Skip to content

[0.1] Further backports and draft release notes#4710

Open
TheBlueMatt wants to merge 6 commits into
lightningdevkit:0.1from
TheBlueMatt:2026-06-0.1-backports-2
Open

[0.1] Further backports and draft release notes#4710
TheBlueMatt wants to merge 6 commits into
lightningdevkit:0.1from
TheBlueMatt:2026-06-0.1-backports-2

Conversation

@TheBlueMatt

@TheBlueMatt TheBlueMatt commented Jun 17, 2026

Copy link
Copy Markdown
Collaborator

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.

jkczyz and others added 4 commits June 17, 2026 20:07
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

ldk-reviews-bot commented Jun 17, 2026

Copy link
Copy Markdown

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.

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
@ldk-claude-review-bot

ldk-claude-review-bot commented Jun 17, 2026

Copy link
Copy Markdown
Collaborator

I've already reviewed this PR in a prior pass and verified all the core fixes. The diff is unchanged — the production code changes (payment.rs:525 checked_sub, channelmanager.rs [2; 33] pubkey, lib.rs Ok(None), offer.rs quantity check, channel.rs monitor_pending_revoke_and_ack clearing) are all correct, and the remaining additions are tests and CHANGELOG notes.

No issues found.

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

@tnull tnull left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Reviewed release notes, LGTM

Comment thread CHANGELOG.md Outdated
@TheBlueMatt TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 167d648 to e2c8d21 Compare June 18, 2026 13:53
@TheBlueMatt

Copy link
Copy Markdown
Collaborator Author

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

Comment thread CHANGELOG.md Outdated
Comment thread CHANGELOG.md Outdated
@TheBlueMatt TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from e2c8d21 to 5cac547 Compare June 18, 2026 16:01
@TheBlueMatt

Copy link
Copy Markdown
Collaborator Author

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 TheBlueMatt force-pushed the 2026-06-0.1-backports-2 branch from 5cac547 to 8caaa3e Compare June 18, 2026 16:12
@TheBlueMatt

Copy link
Copy Markdown
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants