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
bitcoin
dependency 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_tx
are nowsign_psbt
, providing more information, incl spent outputs, about the transaction being signed (#2775).- Logger
Record
s now includechannel_id
andpeer_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 fromlightning-background-processor
.process_events_async
now takes a new time-fetch function, andScoreUpDate
methods now take the current time as aDuration
argument. This avoids fetching time during pathfinding (#2656). - Receiving payments to multi-hop blinded paths is now supported (#2688).
MessageRouter
andRouter
now feature methods to generate blinded paths to the local node for incoming messages and payments.Router
now extendsMessageRouter
, and both are used inChannelManager
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 throughChannelConfig::max_dust_htlc_exposure
(#2696).lightning-invoice
Description
s now rely onUntrustedString
for sanitization (#2730).ScoreLookUp::channel_penalty_msat
now usesCandidateRouteHop
(#2551).- The
EcdsaChannelSigner
trait was moved tolightning::sign::ecdsa
(#2512). SignerProvider::get_destination_script
now takeschannel_keys_id
(#2744)SpendableOutputDescriptor::StaticOutput
now haschannel_keys_id
(#2749).EcdsaChannelSigner::sign_counterparty_commitment
now takes HTLC preimages for both inbound and outbound HTLCs (#2753).ClaimedHTLC
now includes acounterparty_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 rawtag
andmerkle_root
(#2687).Offer::is_expired_no_std
was added (#2689).PaymentPurpose::preimage()
was added (#2768).temporary_channel_id
can now be specified increate_channel
(#2699).- Wire definitions for splicing messages were added (#2544).
- Various
lightning-invoice
structs now implDisplay
, now have pub fields, or implFrom
(#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
Txid
s from Bitcoin Core JSON-RPC responses usinglightning-block-sync
would not properly byte-swap the hash. Note that LDK does not use this API internally (#2796).
Backwards Compatibility
ChannelManager
s 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-serializedChannelManager
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).