|
| 1 | +# 0.1.4 - May 23, 2025 - "Careful Validation of Bogus States" |
| 2 | + |
| 3 | +## Bug Fixes |
| 4 | + * In cases where using synchronous persistence with higher latency than the |
| 5 | + latency to communicate with peers caused issues fixed in 0.1.2, |
| 6 | + `ChannelManager`s may have been left in a state which LDK 0.1.2 and later |
| 7 | + would refuse to deserialize. This has been fixed and nodes which experienced |
| 8 | + this issue prior to 0.1.2 should now deserialize fine (#3790). |
| 9 | + * In some cases, when using synchronous persistence with higher latency than |
| 10 | + the latency to communicate with peers, when receiving an MPP payment with |
| 11 | + multiple parts received over the same channel, a channel could hang and not |
| 12 | + make progress, eventually leading to a force-closure due to timed-out HTLCs. |
| 13 | + This has now been fixed (#3680). |
| 14 | + |
| 15 | +## Security |
| 16 | +0.1.4 fixes a funds-theft vulnerability in exceedingly rare cases. |
| 17 | + * A malicious peer, if they allow a public channel with an LDK-based node to |
| 18 | + have no reserve on the LDK end, if the LDK-based node increases the channel |
| 19 | + feerate on an anchor-based channels somewhat while there are several |
| 20 | + HTLCs in the channel and the LDK-based node has nearly zero balance in the |
| 21 | + channel, may be able to cause the LDK-based node to create an invalid |
| 22 | + commitment transaction which it cannot use to claim its part of forwarded |
| 23 | + HTLC. The counterparty would have to forfeit their reserve value (#3796). |
| 24 | + |
| 25 | + |
1 | 26 | # 0.1.3 - Apr 30, 2025 - "Routing Unicode in 2025"
|
2 | 27 |
|
3 | 28 | ## Bug Fixes
|
|
0 commit comments