Skip to content

Commit 0944141

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

File tree

1 file changed

+195
-0
lines changed

1 file changed

+195
-0
lines changed

‎CHANGELOG.md‎

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

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

0 commit comments

Comments
 (0)