By EZ in Releases — Oct 24, 2023

LDK v0.0.118: BOLT12 Sending & Receiving

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

"BOLT12 sending and receiving is now supported as an alpha feature. We are seeking feedback from early testers."
ConfirmationTarget has been rewritten to allow LDK users to more
accurately target their feerate estimates.
"0.0.118 expands mitigations against transaction cycling attacks to non-anchor channels, though note that no mitigations which exist today are considered robust to prevent the class of attacks."
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors: Antonio Yang, Elias Rohrer, Evan Feenstra, Fedeparma74, Gursharan Singh, Jeffrey Czyz, Matt Corallo, Sergi Delgado Segura, Vladimir Fomene, Wilmer Paulino, benthecarman, slanesuke.

What's new

BOLT12 sending and receiving is now supported as an alpha feature. You may run into unexpected issues and will need to have a direct connection with the offer's blinded path introduction points as messages are not yet routed. We are seeking feedback from early testers (#2578, #2039).
ConfirmationTarget has been rewritten to provide information about the specific use LDK needs the feerate estimate for, rather than the generic low-, medium-, and high-priority estimates. This allows LDK users to more accurately target their feerate estimates (#2660). For those wishing to retain their existing behavior, see the table below for conversion.
ChainHash is now used in place of BlockHash where it represents the
genesis block (#2662).
lightning-invoice payment utilities now take a Deref to
AChannelManager (#2652).
peel_onion is provided to statelessly decode an OnionMessage (#2599).
ToSocketAddrs + Display are now impl'd for SocketAddress (#2636, #2670)
Display is now implemented for OutPoint (#2649).
Features::from_be_bytes is now provided (#2640).

Calling ChannelManager::close_channel[_with_feerate_and_script] on a
channel which did not exist would immediately hang holding several keyChannelManager-internal locks (#2657).
Channel information updates received from a failing HTLC are no longer applied to our NetworkGraph. This prevents a node which we attempted to route a payment through from being able to learn the sender of the payment. In some rare cases, this may result in marginally reduced payment success rates (#2666).
Anchor outputs are now properly considered when calculating the amount available to send in HTLCs. This can prevent force-closes in anchor channels when sending payments which overflow the available balance (#2674).
A peer that sends an update_fulfill_htlc message for a forwarded HTLC, then reconnects prior to sending a commitment_signed (thus retransmitting their update_fulfill_htlc) may result in the channel stalling and being unable to make progress (#2661).
In exceedingly rare circumstances, messages intended to be sent to a peer prior to reconnection can be sent after reconnection. This could result in undefined channel state and force-closes (#2663).

Creating a blinded path to receive a payment then downgrading to LDK prior to 0.0.117 may result in failure to receive the payment (#2413).
Calling ChannelManager::pay_for_offer or ChannelManager::create_refund_builder may prevent downgrading to LDK prior to 0.0.118 until the payment times out and has been removed (#2039).

LDK now sends a bogus channel_reestablish message to peers when they ask to resume an unknown channel. This should cause LND nodes to force-close and broadcast the latest channel state to the chain.
In order to trigger this when we wish to force-close a channel, LDK now disconnects immediately after sending a channel-closing error message.
This should result in cooperative peers also working to confirm the latest commitment transaction when we wish to force-close (#2658).