Skip to content

Commit 32b469f

Browse files
TheBlueMattTheBlueMatt
committed
Add CHANGELOG entries for 0.1 patch releases
1 parent 4ed4094 commit 32b469f

File tree

1 file changed

+202
-0
lines changed

1 file changed

+202
-0
lines changed

‎CHANGELOG.md‎

Lines changed: 202 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,205 @@
1+
# 0.1.7 - Oct 21, 2025 - "Unstable Release CI"
2+
3+
## Bug Fixes
4+
* Builds with the `docsrs` cfg flag (set automatically for builds on docs.rs
5+
but otherwise not used) were fixed.
6+
7+
8+
# 0.1.6 - Oct 10, 2025 - "Async Preimage Claims"
9+
10+
## Performance Improvements
11+
* `NetworkGraph::remove_stale_channels_and_tracking` has been sped up by more
12+
than 20x in cases where many entries need to be removed (such as after
13+
initial gossip sync, #4080).
14+
15+
## Bug Fixes
16+
* Delivery of on-chain resolutions of HTLCs to `ChannelManager` has been made
17+
more robust to prevent loss in some exceedingly rare crash cases. This may
18+
marginally increase payment resolution event replays on startup (#3984).
19+
* Corrected forwarding of new gossip to peers which we are sending an initial
20+
gossip sync to (#4107).
21+
* A rare race condition may have resulted in outbound BOLT12 payments
22+
spuriously failing while processing the `Bolt12Invoice` message (#4078).
23+
* If a channel is updated multiple times after a payment is claimed while using
24+
async persistence of the `ChannelMonitorUpdate`s, and the node then restarts
25+
with a stale copy of its `ChannelManager`, the `PaymentClaimed` may have been
26+
lost (#3988).
27+
* If an async-persisted `ChannelMonitorUpdate` for one part of an MPP claim
28+
does not complete before multiple `ChannelMonitorUpdate`s for another channel
29+
in the same MPP claim complete, and the node restarts twice, the preimage may
30+
be lost and the MPP payment part may not be claimed (#3928).
31+
32+
## Security
33+
0.1.6 fixes a denial of service vulnerability and a funds-theft vulnerability.
34+
* When a channel has been force-closed, we have already claimed some of its
35+
HTLCs on-chain, and we later learn a new preimage allowing us to claim
36+
further HTLCs on-chain, we could in some cases generate invalid claim
37+
transactions leading to loss of funds (#4154).
38+
* When a `ChannelMonitor` is created for a channel which is never funded with
39+
a real transaction, `ChannelMonitor::get_claimable_balances` would never be
40+
empty. As a result, `ChannelMonitor::check_and_update_full_resolution_status`
41+
would never indicate the monitor is prunable, and thus
42+
`ChainMonitor::archive_fully_resolved_channel_monitors` would never remove
43+
it. This allows a peer which opens channels without funding them to bloat our
44+
memory and disk space, eventually leading to denial-of-service (#4081).
45+
46+
47+
# 0.1.5 - Jul 16, 2025 - "Async Path Reduction"
48+
49+
## Performance Improvements
50+
* `NetworkGraph`'s expensive internal consistency checks have now been
51+
disabled in debug builds in addition to release builds (#3687).
52+
53+
## Bug Fixes
54+
* Pathfinding which results in a multi-path payment is now substantially
55+
smarter, using fewer paths and better optimizing fees and successes (#3890).
56+
* A counterparty delaying claiming multiple HTLCs with different expiries can
57+
no longer cause our `ChannelMonitor` to continuously rebroadcast invalid
58+
transactions or RBF bump attempts (#3923).
59+
* Reorgs can no longer cause us to fail to claim HTLCs after a counterparty
60+
delayed claiming multiple HTLCs with different expiries (#3923).
61+
* Force-closing a channel while it is blocked on another channel's async
62+
`ChannelMonitorUpdate` can no longer lead to a panic (#3858).
63+
* `ChannelMonitorUpdate`s can no longer be released to storage too early when
64+
doing async updates or on restart. This only impacts async
65+
`ChannelMonitorUpdate` persistence and can lead to loss of funds only in rare
66+
cases with `ChannelMonitorUpdate` persistence order inversions (#3907).
67+
68+
## Security
69+
0.1.5 fixes a vulnerability which could allow a peer to overdraw their reserve
70+
value, potentially cutting into commitment transaction fees on channels with a
71+
low reserve.
72+
* Due to a bug in checking whether an HTLC is dust during acceptance, near-dust
73+
HTLCs were not counted towards the commitment transaction fee, but did
74+
eventually contribute to it when we built a commitment transaction. This can
75+
be used by a counterparty to overdraw their reserve value, or, for channels
76+
with a low reserve value, cut into the commitment transaction fee (#3933).
77+
78+
79+
# 0.1.4 - May 23, 2025 - "Careful Validation of Bogus States"
80+
81+
## Bug Fixes
82+
* In cases where using synchronous persistence with higher latency than the
83+
latency to communicate with peers caused issues fixed in 0.1.2,
84+
`ChannelManager`s may have been left in a state which LDK 0.1.2 and later
85+
would refuse to deserialize. This has been fixed and nodes which experienced
86+
this issue prior to 0.1.2 should now deserialize fine (#3790).
87+
* In some cases, when using synchronous persistence with higher latency than
88+
the latency to communicate with peers, when receiving an MPP payment with
89+
multiple parts received over the same channel, a channel could hang and not
90+
make progress, eventually leading to a force-closure due to timed-out HTLCs.
91+
This has now been fixed (#3680).
92+
93+
## Security
94+
0.1.4 fixes a funds-theft vulnerability in exceedingly rare cases.
95+
* If an LDK-based node funds an anchor channel to a malicious peer, and that
96+
peer sets the channel reserve on the LDK-based node to zero, the LDK-node
97+
could overdraw its total balance upon increasing the feerate of the
98+
commitment transaction. If the malicious peer forwards HTLCs through the
99+
LDK-based node, this could leave the LDK-based node with no valid commitment
100+
transaction to broadcast to claim its part of the forwarded HTLC. The
101+
counterparty would have to forfeit their reserve value (#3796).
102+
103+
104+
# 0.1.3 - Apr 30, 2025 - "Routing Unicode in 2025"
105+
106+
## Bug Fixes
107+
* `Event::InvoiceReceived` is now only generated once for each `Bolt12Invoice`
108+
received matching a pending outbound payment. Previously it would be provided
109+
each time we received an invoice, which may happen many times if the sender
110+
sends redundant messages to improve success rates (#3658).
111+
* LDK's router now more fully saturates paths which are subject to HTLC
112+
maximum restrictions after the first hop. In some rare cases this can result
113+
in finding paths when it would previously spuriously decide it cannot find
114+
enough diverse paths (#3707, #3755).
115+
116+
## Security
117+
0.1.3 fixes a denial-of-service vulnerability which cause a crash of an
118+
LDK-based node if an attacker has access to a valid `Bolt12Offer` which the
119+
LDK-based node created.
120+
* A malicious payer which requests a BOLT 12 Invoice from an LDK-based node
121+
(via the `Bolt12InvoiceRequest` message) can cause the panic of the
122+
LDK-based node due to the way `String::truncate` handles UTF-8 codepoints.
123+
The codepath can only be reached once the received `Botlt12InvoiceRequest`
124+
has been authenticated to be based on a valid `Bolt12Offer` which the same
125+
LDK-based node issued (#3747, #3750).
126+
127+
128+
# 0.1.2 - Apr 02, 2025 - "Foolishly Edgy Cases"
129+
130+
## API Updates
131+
* `lightning-invoice` is now re-exported as `lightning::bolt11_invoice`
132+
(#3671).
133+
134+
## Performance Improvements
135+
* `rapid-gossip-sync` graph parsing is substantially faster, resolving a
136+
regression in 0.1 (#3581).
137+
* `NetworkGraph` loading is now substantially faster and does fewer
138+
allocations, resulting in a 20% further improvement in `rapid-gossip-sync`
139+
loading when initializing from scratch (#3581).
140+
* `ChannelMonitor`s for closed channels are no longer always re-persisted
141+
immediately after startup, reducing on-startup I/O burden (#3619).
142+
143+
## Bug Fixes
144+
* BOLT 11 invoices longer than 1023 bytes long (and up to 7089 bytes) now
145+
properly parse (#3665).
146+
* In some cases, when using synchronous persistence with higher latency than
147+
the latency to communicate with peers, when receiving an MPP payment with
148+
multiple parts received over the same channel, a channel could hang and not
149+
make progress, eventually leading to a force-closure due to timed-out HTLCs.
150+
This has now been fixed (#3680).
151+
* Some rare cases with multi-hop BOLT 11 route hints or multiple redundant
152+
blinded paths could have led to the router creating invalid `Route`s were
153+
fixed (#3586).
154+
* Corrected the decay logic in `ProbabilisticScorer`'s historical buckets
155+
model. Note that by default historical buckets are only decayed if no new
156+
datapoints have been added for a channel for two weeks (#3562).
157+
* `{Channel,Onion}MessageHandler::peer_disconnected` will now be called if a
158+
different message handler refused connection by returning an `Err` from its
159+
`peer_connected` method (#3580).
160+
* If the counterparty broadcasts a revoked state with pending HTLCs, those
161+
will now be claimed with other outputs which we consider to not be
162+
vulnerable to pinning attacks if they are not yet claimable by our
163+
counterparty, potentially reducing our exposure to pinning attacks (#3564).
164+
165+
166+
# 0.1.1 - Jan 28, 2025 - "Onchain Matters"
167+
168+
## API Updates
169+
* A `ChannelManager::send_payment_with_route` was (re-)added, with semantics
170+
similar to `ChannelManager::send_payment` (rather than like the pre-0.1
171+
`send_payent_with_route`, #3534).
172+
* `RawBolt11Invoice::{to,from}_raw` were added (#3549).
173+
174+
## Bug Fixes
175+
* HTLCs which were forwarded where the inbound edge times out within the next
176+
three blocks will have the inbound HTLC failed backwards irrespective of the
177+
status of the outbound HTLC. This avoids the peer force-closing the channel
178+
(and claiming the inbound edge HTLC on-chain) even if we have not yet managed
179+
to claim the outbound edge on chain (#3556).
180+
* On restart, replay of `Event::SpendableOutput`s could have caused
181+
`OutputSweeper` to generate double-spending transactions, making it unable to
182+
claim any delayed claims. This was resolved by retaining old claims for more
183+
than four weeks after they are claimed on-chain to detect replays (#3559).
184+
* Fixed the additional feerate we will pay each time we RBF on-chain claims to
185+
match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (#3457).
186+
* Fixed a cased where a custom `Router` which returns an invalid `Route`,
187+
provided to `ChannelManager`, can result in an outbound payment remaining
188+
pending forever despite no HTLCs being pending (#3531).
189+
190+
## Security
191+
0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
192+
cause force-closure of unrelated channels.
193+
* If a malicious channel counterparty force-closes a channel, broadcasting a
194+
revoked commitment transaction while the channel at closure time included
195+
multiple non-dust forwarded outbound HTLCs with identical payment hashes and
196+
amounts, failure to fail the HTLCs backwards could cause the channels on
197+
which we recieved the corresponding inbound HTLCs to be force-closed. Note
198+
that we'll receive, at a minimum, the malicious counterparty's reserve value
199+
when they broadcast the stale commitment (#3556). Thanks to Matt Morehouse for
200+
reporting this issue.
201+
202+
1203
# 0.1 - Jan 15, 2025 - "Human Readable Version Numbers"
2204

3205
The LDK 0.1 release represents an important milestone for the LDK project. While

0 commit comments

Comments
 (0)