LDK v0.0.119: API Updates, Performance Improvements, & Fixes
LDK/rust-lightning is a highly performant and flexible implementation of the Lightning Network protocol.
- "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
bitcoindependency has been updated to version 0.30 (#2740). lightning-invoice::payment::*have been replaced with parameter generation viapayment_parameters_from[_zero_amount]_invoice(#2727).{CoinSelection,Wallet}Source::sign_txare nowsign_psbt, providing more information, incl spent outputs, about the transaction being signed (#2775).- Logger
Records now includechannel_idandpeer_idfields. 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::ConnectionNeededmay 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 fromlightning-background-processor.process_events_asyncnow takes a new time-fetch function, andScoreUpDatemethods now take the current time as aDurationargument. This avoids fetching time during pathfinding (#2656). - Receiving payments to multi-hop blinded paths is now supported (#2688).
MessageRouterandRouternow feature methods to generate blinded paths to the local node for incoming messages and payments.Routernow extendsMessageRouter, and both are used inChannelManagerwhen processing or creating BOLT12 structures to generate multi-hop blinded paths (#1781).lightning-transaction-syncnow supports Electrum-based sync (#2685).Confirm::get_relevant_txidsnow returns the height at which a transaction was confirmed. This can be used to assist in reorg detection (#2685).ConfirmationTarget::MaxAllowedNonAnchorChannelRemoteFeehas been removed. Non-anchor channel feerates are bounded indirectly throughChannelConfig::max_dust_htlc_exposure(#2696).lightning-invoiceDescriptions now rely onUntrustedStringfor sanitization (#2730).ScoreLookUp::channel_penalty_msatnow usesCandidateRouteHop(#2551).- The
EcdsaChannelSignertrait was moved tolightning::sign::ecdsa(#2512). SignerProvider::get_destination_scriptnow takeschannel_keys_id(#2744)SpendableOutputDescriptor::StaticOutputnow haschannel_keys_id(#2749).EcdsaChannelSigner::sign_counterparty_commitmentnow takes HTLC preimages for both inbound and outbound HTLCs (#2753).ClaimedHTLCnow includes acounterparty_skimmed_fee_msatfield (#2715).peel_payment_onionwas 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_onionwas 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).
TaggedHashnow includes the rawtagandmerkle_root(#2687).Offer::is_expired_no_stdwas added (#2689).PaymentPurpose::preimage()was added (#2768).temporary_channel_idcan now be specified increate_channel(#2699).- Wire definitions for splicing messages were added (#2544).
- Various
lightning-invoicestructs now implDisplay, now have pub fields, or implFrom(#2730). - The
Hashtrait 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
ChannelManagermay fail to deserialize (#2735). ChannelConfig::max_dust_exposurevalues 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 usinglightning-block-syncwould 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-serializedChannelManagerwith 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).