draft release notes

Author: TheBlueMatt

CHANGELOG.md

@@ -1,3 +1,41 @@
+# 0.1.6 - Oct XXX, 2025 - "Async Preimage Claims"
+
+## Performance Improvements
+ * `NetworkGraph::remove_stale_channels_and_tracking` has been sped up by more
+   than 20x in cases where many entries need to be removed (such as after
+   initial gossip sync, #4080).
+
+## Bug Fixes
+ * Delivery of on-chain resolutions of HTLCs to `ChannelManager` has been made
+   more robust to prevent loss in some exceedingly rare crash cases. This may
+   marginally increase payment resolution event replays on startup (#3984).
+ * Corrected forwarding of new gossip to peers which we are sending an initial
+   gossip sync to (#4107).
+ * A rare race condition may have resulted in outbound BOLT12 payments
+   spuriously failing while processing the `Bolt12Invoice` message (#4078).
+ * If a channel is updated multiple times after a payment is claimed while using
+   async persistence of the `ChannelMonitorUpdate`s, and the node then restarts
+   with a stale copy of its `ChannelManager`, the `PaymentClaimed` may have been
+   lost (#3988).
+ * If an async-persisted `ChannelMonitorUpdate` for one part of an MPP claim
+   does not complete before multiple `ChannelMonitorUpdate`s for another channel
+   in the same MPP claim complete, and the node restarts twice, the preimage may
+   be lost and the part of the MPP payment not claimed (#3928).
+
+## Security
+0.1.6 fixes a denial of service vulnerability and a funds-theft vulnerability.
+ * When a channel has been force-closed, we have already claimed some of its
+   HTLCs on-chain, and we later learn a new preimage allowing us to claim
+   further HTLCs on-chain, we could in some cases generate invalid claim
+   transactions leading to loss of funds (#XXX).
+ * When a `ChannelMonitor` is created for a channel which is never funded with
+   a real transaction, `ChannelMonitor::get_claimable_balances` would never be
+   empty. As a result, `ChannelMonitor::check_and_update_full_resolution_status`
+   would never indicate the monitor is prunable, and thus
+   `ChainMonitor::archive_fully_resolved_channel_monitors` would never remove
+   it. This allows a peer which opens channels without funding them to bloat our
+   memory and disk space, eventually leading to denial-of-service (#4081).
+
 # 0.1.5 - Jul 16, 2025 - "Async Path Reduction"
 
 ## Performance Improvements