“In total, this release features 148 files changed, 13780 insertions, 6279 deletions in 280 commits from 22 authors, in alphabetical order: Arik Sosman, Chris Waterson, Elias Rohrer, Evan Feenstra, Gursharan Singh, Jeffrey Czyz, John Cantrell, Lalitmohansharma1, Matt Corallo, Matthew Rheaume, Orbital, Rachel Malonson, Valentine Wallace, Willem Van Lint, Wilmer Paulino, alexanderwiederin, benthecarman, henghonglee, jbesraa, olegkubrakov, optout and shaavan.”
What’s new
API Updates
The LDK crate ecosystem MSRV has been increased to 1.63 (#2681).The bitcoin dependency has been updated to version 0.30 (#2740).lightning-invoice::payment::* have been replaced with parameter generation via payment_parameters_from[_zero_amount]_invoice (#2727).{CoinSelection,Wallet}Source::sign_tx are now sign_psbt, providing more information, incl spent outputs, about the transaction being signed (#2775).Logger Records now include channel_id and peer_id fields. These are opportunistically filled in when a log record is specific to a given channel and/or peer, and may occasionally be spuriously empty (#2314).When handling send or reply onion messages (e.g. for BOLT12 payments), a new Event::ConnectionNeeded may be raised, indicating a direct connection should be made to a payee or an introduction point. This event is expected to be removed once onion message forwarding is widespread in the network (#2723)Scoring data decay now happens via ScoreUpDate::time_passed, called from lightning-background-processor. process_events_async now takes a new time-fetch function, and ScoreUpDate methods now take the current time as a Duration argument. This avoids fetching time during pathfinding (#2656).Receiving payments to multi-hop blinded paths is now supported (#2688).MessageRouter and Router now feature methods to generate blinded paths to the local node for incoming messages and payments. Router now extends MessageRouter, and both are used in ChannelManager when processing or creating BOLT12 structures to generate multi-hop blinded paths (#1781).lightning-transaction-sync now supports Electrum-based sync (#2685).Confirm::get_relevant_txids now returns the height at which a transaction was confirmed. This can be used to assist in reorg detection (#2685).ConfirmationTarget::MaxAllowedNonAnchorChannelRemoteFee has been removed. Non-anchor channel feerates are bounded indirectly through ChannelConfig::max_dust_htlc_exposure (#2696).lightning-invoice Descriptions now rely on UntrustedString for sanitization (#2730).ScoreLookUp::channel_penalty_msat now uses CandidateRouteHop (#2551).The EcdsaChannelSigner trait was moved to lightning::sign::ecdsa (#2512).SignerProvider::get_destination_script now takes channel_keys_id (#2744)SpendableOutputDescriptor::StaticOutput now has channel_keys_id (#2749).EcdsaChannelSigner::sign_counterparty_commitment now takes HTLC preimages for both inbound and outbound HTLCs (#2753).ClaimedHTLC now includes a counterparty_skimmed_fee_msat field (#2715).peel_payment_onion was added to decode an encrypted onion for a payment without receiving an HTLC. This allows for stateless verification of if a theoretical payment would be accepted prior to receipt (#2700).create_payment_onion was added to construct an encrypted onion for a payment path without sending an HTLC immediately (#2677).Various keys used in channels are now wrapped to provide type-safety for specific usages of the keys (#2675).TaggedHash now includes the raw tag and merkle_root (#2687).Offer::is_expired_no_std was added (#2689).PaymentPurpose::preimage() was added (#2768).temporary_channel_id can now be specified in create_channel (#2699).Wire definitions for splicing messages were added (#2544).Various lightning-invoice structs now impl Display, now have pub fields, or impl From (#2730).The Hash trait is now implemented for more structs, incl P2P msgs (#2716).
Performance Improvements
Memory allocations (though not memory usage) have been substantially reduced, meaning less overhead and hopefully less memory fragmentation (#2708, #2779).
Bug Fixes
Since 0.0.117, calling close_channel* on a channel which has not yet been funded would previously result in an infinite loop and hang (#2760).Since 0.0.116, sending payments requiring data in the onion for the recipient which was too large for the onion may have caused corruption which resulted in payment failure (#2752).Cooperative channel closure on channels with remaining output HTLCs may have spuriously force-closed (#2529).In LDK versions 0.0.116 through 0.0.118, in rare cases where skimmed fees are present on shutdown the ChannelManager may fail to deserialize (#2735).ChannelConfig::max_dust_exposure values which, converted to absolute fees, exceeded 2^63 – 1 would result in an overflow and could lead to spurious payment failures or channel closures (#2722).In cases where LDK is operating with provably-stale state, it panics to avoid funds loss. This may not have happened in cases where LDK was behind only exactly one state, leading instead to a revoked broadcast and funds loss (#2721).Fixed a bug where decoding Txids from Bitcoin Core JSON-RPC responses using lightning-block-sync would not properly byte-swap the hash. Note that LDK does not use this API internally (#2796).
Backwards Compatibility
ChannelManagers written with LDK 0.0.119 are no longer readable by versions of LDK prior to 0.0.113. Users wishing to downgrade to LDK 0.0.112 or before can read an 0.0.119-serialized ChannelManager with a version of LDK from 0.0.113 to 0.0.118, re-serialize it, and then downgrade (#2708).Nodes that upgrade to 0.0.119 and subsequently downgrade after receiving a payment to a blinded path may leak recipient information if one or more of those HTLCs later fails (#2688).Similarly, forwarding a blinded HTLC and subsequently downgrading to an LDK version prior to 0.0.119 may result in leaking the path information to the payment sender (#2540).