LDK v0.0.120: Important Bug Fixes, Full Blinded Paths Support & More

LDK/rust-lightning is a highly performant and flexible implementation of the Lightning Network protocol.

"LDK 0.0.120 is here," announced the Lightning Dev Kit team.
This release includes important bugfixes, full support for blinded paths, and better BOLT12 payment reliability and privacy, among other things.
v0.0.120 fixes a denial-of-service vulnerability which is reachable from untrusted input from peers if the UserConfig::manually_accept_inbound_channels option is enabled.
In total, this release features 67 files changed, 3016 insertions, 2473
deletions in 79 commits from 9 authors, in alphabetical order: Elias Rohrer, Jeffrey Czyz, José A.P, Matt Corallo, Tibo-lg, Valentine Wallace, benthecarman, optout, shuoer86.

Release notes

The PeerManager bound on UtxoLookup was removed entirely. This enables use of UtxoLookup in cases broken in 0.0.119 by #2773 (#2822).
LDK now exposes and fully implements the route blinding feature (#2812).
The lightning-transaction-sync crate no longer relies on system time
without the time feature (#2799, #2817).
lightning::onion_message's module layout has changed (#2821).
Event::ChannelClosed now includes the channel_funding_txo (#2800).
CandidateRouteHop variants were destructured into individual structs,
hiding some fields which were not generally consumable (#2802).

Fixed a rare issue where lightning-net-tokio may not fully flush its send buffer, leading to connection hangs (#2832).
Fixed a panic which may occur when connecting to a peer if we opened a second channel with that peer while they were disconnected (#2808).
Retries for a payment which previously failed in a blinded path will now always use an alternative blinded path (#2818).
Feature's Eq and Hash implementation now ignore dummy bytes (#2808).
Some missing DiscardFunding or ChannelClosed events are now generated in rare funding-related failures (#2809).
Fixed a privacy issue in blinded path generation where the real
cltv_expiry_delta would be exposed to senders (#2831).

A peer that sent an open_channel message with the channel_type field
unfilled would trigger a reachable unwrap since LDK 0.0.117 (#2808).
In protocols where a funding output is shared with our counterparty before it is given to LDK, a malicious peer could have caused a reachable panic by reusing the same funding info in (#2809).

Announcement / Archive
GitHub Repo