[0.1] Further backports and draft release notes#4710
Conversation
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
|
I've assigned @wpaulino as a reviewer! |
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
5ed4dcc to
167d648
Compare
|
I've already reviewed this PR in a prior pass and verified all the core fixes. The diff is unchanged — the production code changes ( No issues found. |
tnull
left a comment
There was a problem hiding this comment.
Reviewed release notes, LGTM
167d648 to
e2c8d21
Compare
|
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 |
e2c8d21 to
5cac547
Compare
|
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). |
5cac547 to
8caaa3e
Compare
|
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). |
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.