← Watch feed
Update upstream CHANGELOG with latest 0.1/0.2 releases
Public commit record
50/100 · Thin
What the developer wrote
Authored by Matt Corallo
Update upstream CHANGELOG with latest 0.1/0.2 releases
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
What changed, and why it matters
This commit only updates the CHANGELOG.md file to add release notes for versions 0.2.4, 0.1.11, 0.2.3, and 0.1.10. It does not change any source code, build scripts, tests, or configuration. The changelog text describes security fixes that were already made in earlier commits, but this documentation-only commit itself does not introduce or fix any vulnerability.
Recommended action
No security action is required for this commit. Treat it as routine documentation maintenance. Review the referenced prior commits (e.g., #4719, #4592, #4670, #4593, #4605, #4713, #4712) if you need to verify that the described security fixes were actually applied in code.
Security signals we found
01
CHANGELOG-only commit with no source code changes
02
Release notes describe prior security fixes: anchor channel reserve underestimates, DoS vulnerabilities, unicode format-character sanitization, weak default randomness in possiblyrandom, panics from malicious invoices/LSPSDateTime/OMNameResolver, RGS memory limits, log spam mitigation, corrupted ChannelManager/ProbabilisticScorer memory allocation
03
Security issues attributed to Project Loupe in release notes
Evidence from the diff
The diff is a pure documentation change to CHANGELOG.md (+214 lines). It records previously-merged release notes for rust-lightning 0.2.4, 0.1.11, 0.2.3, and 0.1.10, including bug fixes and security-relevant items such as anchor reserve underestimates, DoS vectors, sanitization issues, and a weak randomness default in possiblyrandom. Because no code is modified, this commit has no direct security effect. The security signals are historical descriptions of prior patches, not new changes introduced here.
Changed components
CHANGELOG.mdInspect captured patch +214 / −0
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 12f926c..b49b0d1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,217 @@
+# 0.2.4 - Jun 25, 2026 - "Release the CI"
+
+## Bug Fixes
+ * 0.2.3 broke the MSRV of the `lightning` crate, which now again compiles on
+ `rustc` 1.63 (#4737).
+
+
+# 0.1.11 - Jun 24, 2026 - "CI Matters"
+
+## Bug Fixes
+ * 0.1.10 broke the MSRV of the `lightning` crate, which now again compiles on
+ `rustc` 1.63 (#4737).
+
+
+# 0.2.3 - Jun 18, 2026 - "Through the Loupe"
+
+## API Updates
+ * `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 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 BOLT 12 `Offer`s; `OfferBuilder`
+ now maps 0-amounts to an amount of `None` (#4324).
+
+## Bug Fixes
+ * `Features::supports_zero_conf` no longer clears the `ZeroConf` features and
+ `Features::requires_zero_conf` now correctly reports required, rather than
+ supported, status (#4517).
+ * If an MPP payment is claimed but `ChannelMonitorUpdate`s for some parts are
+ still being completed asynchronously, further channel updates (e.g.
+ forwarding another payment) are pending and the node restarts, the channel
+ could have become stuck (#4520).
+ * The presence of unconfirmed transactions actually no longer causes
+ `ElectrumSyncClient` to spuriously fail to sync (#4590).
+ * LSPS1, LSPS2, and LSPS5 persistence will no longer get stuck and refuse to
+ persist again after a single failure from the KVStore (#4597, #4282).
+ * Dropping the future returned by
+ `OutputSweeper::regenerate_and_broadcast_spend_if_necessary` no longer
+ results in future calls to the same method being spuriously ignored (#4598).
+ * Used async-receive offers are no longer refreshed on every timer tick once
+ their refresh time is reached (#4672).
+ * `FilesystemStore::list_all_keys` will no longer fail if there are stale
+ intermediate files lying around from a previous unclean shutdown (#4618).
+ * When forwarding an HTLC while in a blinded path with proportional fees over
+ 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
+ both async `ChannelMonitorUpdate` persistence and async signing (#4684).
+ * If we had exactly zero balance in a zero-fee-commitment channel, the
+ counterparty was able to splice all of their balance out, violating the
+ reserve requirements they'd otherwise be forced to keep (#4580).
+ * Providing an `Event::HTLCIntercepted` to the `LSPS2ServiceHandler` twice no
+ longer results in spuriously opening a channel early (#4656).
+ * `Event::PaymentSent::fee_paid_msat` is no longer `None` in cases where
+ `ChannelManager::abandon_payment` was called before the payment ultimately
+ completes anyway (#4651).
+ * `AnchorDescriptor::previous_utxo` now provides the correct `script_pubkey`
+ for non-zero-commitment-fee anchor channels (#4669).
+ * Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
+ full `ChannelMonitor`s to disk several times per block (#4544).
+ * `OMDomainResolver` now correctly accounts for failed queries when rate
+ limiting, ensuring we continue to respond to queries after failures (#4591).
+ * Calling `ChannelManager::send_payment_with_route` without a `route_params`
+ and with an invalid `Route` will no longer panic (#4707).
+ * `LSPS2ServiceHandler::channel_open_failed` now correctly fails intercepted
+ HTLCs rather than allowing them to fail just before expiry (#4677).
+ * `StaticInvoice::is_offer_expired` was corrected to check offer, rather than
+ static invoice, expiry (#4594).
+ * `lightning-custom-message`'s handling of `peer_connected` events now ensures
+ that sub-handlers will see a `peer_disconnected` event if a different
+ sub-handler refused the connection by `Err`ing `peer_connected` (#4595).
+ * Replay protection for LSPS5 signatures now detects replays which are only
+ different in the encoded signature's case (#4701).
+ * When `lightning-liquidity` is configured in the background processor, there
+ is no longer a stream of `Persisting LiquidityManager...` log spam (#4246).
+ * Incomplete MPP keysend payments will no longer see their HTLCs held until
+ expiry (#4558).
+ * `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
+ 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).
+ * Several spurious debug assertions were fixed (#4537, #4618, #4026)
+
+## Security
+0.2.3 fixes several underestimates of the anchor reserves required to ensure we
+can reliably close channels, several denial-of-service vulnerabilities and a
+sanitization issue.
+ * `Bolt11Invoice::recover_payee_pub_key` no longer panics if called on an
+ invoice which set an explicit public key, rather than relying on public key
+ recovery. Note that this method is called from
+ `PaymentParameters::from_bolt11_invoice` (#4717).
+ * Maliciously-crafted unpayable invoices which have overflowing feerates will
+ no longer cause an `unwrap` failure panic (#4716).
+ * Parsing an `LSPSDateTime` which is before 1970 no longer panics. This is
+ reachable when parsing messages from counterparties (#4715).
+ * `possiblyrandom` did not properly generate random data except when it was
+ explicitly configured to. By default this means LDK is vulnerable to various
+ HashDoS attacks (#4719).
+ * `OMNameResolver` will no longer panic when looking up payment instructions
+ which include unicode characters at the start of a TXT record (#4718).
+ * When using the `anchor_channel_reserves` module to calculate reserves
+ required to pay for fees when closing anchor channels, zero-fee-commitment
+ channels were not considered. This could allow a counterparty to open many
+ channels, leaving us unable to properly force-close (#4592).
+ * The `anchor_channel_reserves` module overestimated the value of `Utxo`s in
+ the wallet by ignoring the `TxIn` cost to spend them (#4670).
+ * `PrintableString` did not properly sanitize unicode format characters,
+ allowing an attacker to corrupt the rendering of logs or UI (#4593, #4605).
+ * RGS data is now limited in how large of a graph it is able to cause a client
+ to store in memory. Note that RGS data is still considered a DoS vector in
+ general and you should only use semi-trusted RGS data (#4713).
+ * Counterparty-provided strings in failure messages are no longer logged in
+ full, reducing the ability of such a counterparty to spam our logs (#4714).
+ * Reading a corrupted `ChannelManager` or `ProbabilisticScorer` can no longer
+ cause us to allocate large amounts of memory (#4712).
+
+Thanks to Project Loupe for reporting most of the issues fixed in this release.
+
+
+# 0.1.10 - Jun 18, 2026 - "Loupe de Loupe"
+
+## API Updates
+ * `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 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 BOLT 12 `Offer`s; `OfferBuilder`
+ now maps 0-amounts to an amount of `None` (#4324).
+
+## Bug Fixes
+ * Async `ChannelMonitorUpdate` persistence operations which complete, but are
+ not marked as complete in a persisted `ChannelManager` prior to restart,
+ followed immediately by a block connection and then another restart could
+ result in some channel operations hanging leading for force-closures (#4377).
+ * If an MPP payment is claimed but `ChannelMonitorUpdate`s for some parts are
+ still being completed asynchronously, further channel updates (e.g.
+ forwarding another payment) are pending and the node restarts, the channel
+ could have become stuck (#4520).
+ * 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
+ intermediate files lying around from a previous unclean shutdown (#4618).
+ * When forwarding an HTLC while in a blinded path with proportional fees over
+ 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
+ both async `ChannelMonitorUpdate` persistence and async signing (#4684).
+ * `Event::PaymentSent::fee_paid_msat` is no longer `None` in cases where
+ `ChannelManager::abandon_payment` was called before the payment ultimately
+ completes anyway (#4651).
+ * Syncing a `ChainMonitor` using the `Confirm` trait will no longer write some
+ full `ChannelMonitor`s to disk several times per block (#4544).
+ * `OMDomainResolver` now correctly accounts for failed queries when rate
+ limiting, ensuring we continue to respond to queries after failures (#4591).
+ * Calling `ChannelManager::send_payment_with_route` without a `route_params`
+ and with an invalid `Route` will no longer panic (#4707).
+ * `lightning-custom-message`'s handling of `peer_connected` events now ensures
+ that sub-handlers will see a `peer_disconnected` event if a different
+ sub-handler refused the connection by `Err`ing `peer_connected` (#4595).
+ * Incomplete MPP keysend payments will no longer see their HTLCs held until
+ expiry (#4558).
+ * `InvoiceRequestBuilder` will no longer accept a `quantity` of `0` for a
+ 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).
+ * Several spurious debug assertions were fixed (#4537, #4618).
+
+## Security
+0.1.10 fixes a sanitization issue and several denial-of-service vulnerabilities.
+ * `Bolt11Invoice::recover_payee_pub_key` no longer panics if called on an
+ invoice which set an explicit public key, rather than relying on public key
+ recovery. This method is called from `payment_parameters_from_invoice` and
+ `payment_parameters_from_variable_amount_invoice` (#4717).
+ * Maliciously-crafted unpayable invoices which have overflowing feerates will
+ no longer cause an `unwrap` failure panic (#4716).
+ * `possiblyrandom` did not properly generate random data except when it was
+ explicitly configured to. By default this means LDK is vulnerable to various
+ HashDoS attacks (#4719).
+ * `OMNameResolver` will no longer panic when looking up payment instructions
+ which include unicode characters at the start of a TXT record (#4718).
+ * `PrintableString` did not properly sanitize unicode format characters,
+ allowing an attacker to corrupt the rendering of logs or UI (#4593, #4605).
+ * RGS data is now limited in how large of a graph it is able to cause a client
+ to store in memory. Note that RGS data is still considered a DoS vector in
+ general and you should only use semi-trusted RGS data (#4713).
+ * Counterparty-provided strings in failure messages are no longer logged in
+ full, reducing the ability of such a counterparty to spam our logs (#4714).
+ * Reading a corrupted `ChannelManager` or `ProbabilisticScorer` can no longer
+ cause us to allocate large amounts of memory (#4712).
+
+Thanks to Project Loupe for reporting most of the issues fixed in this release.
+
+
+# 0.2.2 - Feb 6, 2025 - "An Async Splicing Production"
+
+## API Updates
+ * The `SplicePrototype` feature flag has been updated to refer to feature bit
+ 63 - the same as `SpliceProduction`. This resolves a compatibility issue with
+ eclair nodes due to the use of the same splicing feature flag (155) they were
+ using for a pre-standardization version of splicing (#4387).
+
+## Bug Fixes
+ * Async `ChannelMonitorUpdate` persistence operations which complete, but are
+ not marked as complete in a persisted `ChannelManager` prior to restart,
+ followed immediately by a block connection and then another restart could
+ result in some channel operations hanging leading for force-closures (#4377).
+ * A debug assertion failure reachable when receiving an invalid splicing
+ message from a peer was fixed (#4383).
+
+
# 0.2.1 - Jan 29, 2025 - "Electrum Confirmations Logged"
## API Updates
Risk score
Our methodology →Why this scored 15/100
Human-validated context
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
No validated notes yet.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.