|
| 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 | + * If an LDK-based node funds an anchor channel to a malicious peer, and that |
| 18 | + peer sets the channel reserve on the LDK-based node to zero, the LDK-node |
| 19 | + could overdraw its total balance upon increasing the feerate of the |
| 20 | + commitment transaction. If the malicious peer forwards HTLCs through the |
| 21 | + LDK-based node, this could leave the LDK-based node with no valid commitment |
| 22 | + transaction to broadcast to claim its part of the forwarded HTLC. The |
| 23 | + 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