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

• "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, José A.P, Matt Corallo, Tibo-lg, Valentine Wallace, benthecarman, optout, shuoer86.

Release notes

API Updates

• 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).

Bug Fixes

• 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).

Security

• 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