v0.1.1 - Jan 28, 2025 - "Onchain Matters"

API Updates
===========

 * A `ChannelManager::send_payment_with_route` was (re-)added, with semantics
   similar to `ChannelManager::send_payment` (rather than like the pre-0.1
   `send_payent_with_route`, #3534).
 * `RawBolt11Invoice::{to,from}_raw` were added (#3549).

Bug Fixes
=========

 * HTLCs which were forwarded where the inbound edge times out within the next
   three blocks will have the inbound HTLC failed backwards irrespective of the
   status of the outbound HTLC. This avoids the peer force-closing the channel
   (and claiming the inbound edge HTLC on-chain) even if we have not yet managed
   to claim the outbound edge on chain (#3556).
 * On restart, replay of `Event::SpendableOutput`s could have caused
   `OutputSweeper` to generate double-spending transactions, making it unable to
   claim any delayed claims. This was resolved by retaining old claims for more
   than four weeks after they are claimed on-chain to detect replays (#3559).
 * Fixed the additional feerate we will pay each time we RBF on-chain claims to
   match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (#3457).
 * Fixed a cased where a custom `Router` which returns an invalid `Route`,
   provided to `ChannelManager`, can result in an outbound payment remaining
   pending forever despite no HTLCs being pending (#3531).

Security
========

0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
cause force-closure of unrelated channels.
 * If a malicious channel counterparty force-closes a channel, broadcasting a
   revoked commitment transaction while the channel at closure time included
   multiple non-dust forwarded outbound HTLCs with identical payment hashes and
   amounts, failure to fail the HTLCs backwards could cause the channels on
   which we recieved the corresponding inbound HTLCs to be force-closed. Note
   that we'll receive, at a minimum, the malicious counterparty's reserve value
   when they broadcast the stale commitment (#3556). Thanks to Matt Morehouse for
   reporting this issue.

v0.1 - Jan 15, 2025 - "Human Readable Version Numbers"

The LDK 0.1 release represents an important milestone for the LDK project. While
there are certainly many important features which are still being built, the LDK
project has come a long way, and the LDK project is happy with the quality of
the features included in this release. Thus, the project will begin doing patch
releases to fix bugs in prior versions as new features continue to ship in new
minor versions.

API Updates
===========

 * The `lightning-liquidity` crate has been moved into the `rust-lightning`
   git tree, enabling support for both sides of the LSPS channel open
   negotiation protocols (#3436).
 * Since its last alpha release, `lightning-liquidity` has also gained support
   for acting as an LSPS1 client (#3436).
 * This release includes support for BIP 353 Human Readable Names resolution.
   With the `dnssec` feature enabled, simply call `ChannelManager`'s
   `pay_for_offer_from_human_readable_name` with a list of lightning nodes that
   have the `dns_resolver` feature flag set (e.g. those running LDK with the
   new `lightning_dns_resolver::OMDomainResolver` set up to resolve DNS queries
   for others) and a Human Readable Name (#3346, #3179, #3283).
 * Asynchronous `ChannelMonitorUpdate` persistence (i.e. the use of
   `ChannelMonitorUpdateStatus::InProgress`) is now considered beta-quality.
   There are no known issues with it, though the likelihood of unknown issues
   is high (#3414).
 * `ChannelManager`'s `send_payment_with_route` and `send_spontaneous_payment`
   were removed. Use `send_payment` and `send_spontaneous_payment_with_retry`
   (now renamed `send_spontaneous_payment`) instead (#3430).
 * `ChannelMonitor`s no longer need to be re-persisted after deserializing the
   `ChannelManager` before beginning normal operation. As such,
   `ChannelManagerReadArgs::channel_monitors` no longer requires mutable
   references (#3322). See the Backwards Compatibility section for more info.
 * Additional information is now stored in `ChannelMonitorUpdate`s which may
   increase the average size of `ChannelMonitorUpdate`s when claiming inbound
   payments substantially. The expected maximum size of `ChannelMonitorUpdate`s
   shouldn't change materially (#3322).
 * Redundant `Event::PaymentClaimed`s will be generated more frequently on
   startup compared to previous versions.
   `Event::PaymentClaim{able,ed}::payment_id` has been added to allow for more
   robust handling of redundant events on payments with duplicate
   `PaymentHash`es (#3303, #3322).
 * `ChannelMonitorUpdate::update_id`s no longer have a magic value (of
   `u64::MAX`) for updates after a channel has been closed. They are now
   always monotonically increasing (#3355).
 * The MSRV of `lightning-transaction-sync` has been increased to rustc 1.75 due
   to its HTTP client dependencies (#3528).
 * The default `ProbabilisticScoringFeeParameters` values now recommend specific
   ratios between different penalties, and default penalties now allow for
   higher fees in order to reduce payment latency (#3495).
 * On-chain state resolution now more aggressively batches claims into single
   transactions, reducing on-chain fee costs when resolving multiple HTLCs for a
   single channel force-closure. This also reduces the on-chain reserve
   requirements for nodes using anchor channels (#3340).
 * A `MigratableKVStore` trait was added (and implemented for
   `FilesystemStore`), enabling easy migration between `KVStore`s (#3481).
 * `InvoiceRequest::amount_msats` now returns the `offer`-implied amount if a
   Bitcoin-denominated amount was set in the `offer` and no amount was set
   directly in the `invoice_request` (#3535).
 * `Event::OpenChannelRequest::push_msat` has been replaced with an enum in
   preparation for the dual-funding protocol coming in a future release (#3137).
 * `GossipVerifier` now requires a `P2PGossipSync` which holds a reference to
   the `GossipVerifier` via an `Arc` (#3432).
 * The `max_level_*` features were removed as the performance gain compared to
   doing the limiting at runtime was negligible (#3431).
 * `ChannelManager::create_bolt11_invoice` was added, deprecating the
   `lightning::ln::invoice_utils` module (#3389).
 * The `bech32` dependency has been upgraded to 0.11 across crates (#3270).
 * Support for creating BOLT 12 `invoice_request`s with a static signing key
   rather than an ephemeral one has been removed (#3264).
 * The `Router` trait no longer extends the `MessageRouter` trait, creating an
   extra argument to `ChannelManager` construction (#3326).
 * The deprecated `AvailableBalances::balance_msat` has been removed in favor of
   `ChannelMonitor::get_claimable_balances` (#3243).
 * Deprecated re-exports of `Payment{Hash,Preimage,Secret}` and `features` were
   removed (#3359).
 * `bolt11_payment::*_from_zero_amount_invoice` methods were renamed
   `*_from_variable_amount_invoice` (#3397)
 * Offer `signing_pubkey` (and related struct names) have been renamed
   `issuer_signing_pubkey` (#3218).
 * `Event::PaymentForwarded::{prev,next}_node_id` were added (#3458).
 * `Event::ChannelClosed::last_local_balance_msat` was added (#3235).
 * `RoutingMessageHandler::handle_*` now all have a `node_id` argument (#3291).
 * `lightning::util::persist::MonitorName` has been exposed (#3376).
 * `ProbabilisticScorer::live_estimated_payment_success_probability` was added
   (#3420)
 * `EcdsaChannelSigner::sign_splicing_funding_input` was added to support an
   eventual splicing feature (#3316).
 * `{Payment,Offer}Id` now support lowercase-hex formatting (#3377).

Bug Fixes
=========

 * Fixed a rare case where a BOLT 12 payment may be made duplicatively if the
   node crashes while processing a BOLT 12 `invoice` message (#3313).
 * Fixed a bug where a malicious sender could cause a payment `Event` to be
   generated with an `OfferId` using a payment with a lower amount than the
   corresponding BOLT 12 offer would have required. The amount in the
   `Event::Payment{Claimable,Claimed}` were still correct (#3435).
 * The `ProbabilisticScorer` model and associated default scoring parameters
   were tweaked to be more predictive of real-world results (#3368, #3495).
 * `ProbabilisticScoringFeeParameters::base_penalty_amount_multiplier_msat` no
   longer includes any pending HTLCs we already have through channels in the
   graph, avoiding over-penalizing them in comparison to other channels (#3356).
 * A `ChannelMonitor` will no longer be archived if a `MonitorEvent` containing
   a preimage for another channel is pending. This fixes an issue where a
   payment preimage needed for another channel claim is lost if events go
   un-processed for 4038 blocks (#3450).
 * `std` builds no longer send the full gossip state to peers that do not
   request it (#3390).
 * `lightning-block-sync` listeners now receive `block_connected` calls, rather
   than always receiving `filtered_block_connected` calls (#3354).
 * Fixed a bug where some transactions were broadcasted one block before their
   locktime made them candidates for inclusion in the mempool (though they would
   be automatically re-broadcasted later, #3453).
 * `ChainMonitor` now persists `ChannelMonitor`s when their `Balance` set first
   goes empty, making `ChannelMonitor` pruning more reliable on nodes that are
   only online briefly (e.g. mobile nodes, #3442).
 * BOLT 12 invoice requests now better handle intermittent internet connectivity
   (e.g. on mobile devices with app interruptions, #3010).
 * Broadcast-gossip `MessageSendEvent`s from the `ChannelMessageHandler` are now
   delivered to peers even if the peer is behind in processing relayed gossip.
   This ensures our own gossip propagates well even if we have very limited
   upload bandwidth (#3142).
 * Fixed a bug where calling `OutputSweeper::transactions_confirmed` with
   transactions from anything but the latest block may have triggered a spurious
   assertion in debug mode (#3524).

Performance Improvements
========================

 * LDK now verifies `channel_update` gossip messages without holding a lock,
   allowing additional parallelism during gossip sync (#3310).
 * LDK now checks if it already has certain gossip messages before verifying the
   message signatures, reducing CPU usage during gossip sync after the first
   startup (#3305).

Node Compatibility
==================

 * LDK now handles fields in the experimental range of BOLT 12 messages (#3237).

Backwards Compatibility
=======================

 * Nodes with pending forwarded HTLCs or unclaimed payments cannot be
   upgraded directly from 0.0.123 or earlier to 0.1. Instead, they must
   first either resolve all pending HTLCs (including those pending
   resolution on-chain), or run 0.0.124 or 0.0.125 and resolve any HTLCs that
   were originally forwarded or received running 0.0.123 or earlier (#3355).
 * `ChannelMonitor`s not being re-persisted after deserializing the
   `ChannelManager` only applies to upgraded nodes *after* a startup with the
   old semantics completes at least once. In other words, you must deserialize
   the `ChannelManager` with an upgraded LDK, persist the `ChannelMonitor`s as
   you would on pre-0.1 versions of LDK, then continue to normal startup once,
   and for startups thereafter you can take advantage of the new semantics
   avoiding redundant persistence on startup (#3322).
 * Pending inbound payments paying a BOLT 12 `invoice` issued prior to upgrade
   to LDK 0.1 will fail. Issued BOLT 12 `offer`s remain payable (#3435).
 * `UserConfig::accept_mpp_keysend` was removed, thus the presence of pending
   inbound MPP keysend payments will prevent downgrade to LDK 0.0.115 and
   earlier (#3439).
 * Inbound payments initialized using the removed
   `ChannelManager::create_inbound_payment{,_for_hash}_legacy` API will no
   longer be accepted by LDK 0.1 (#3383).
 * Downgrading to prior versions of LDK after using `ChannelManager`'s
   `unsafe_manual_funding_transaction_generated` may cause `ChannelManager`
   deserialization to fail (#3259).
 * `ChannelDetails` serialized with LDK 0.1+ read with versions prior to 0.1
   will have `balance_msat` equal to `next_outbound_htlc_limit_msat` (#3243).

Security
========

0.1 fixes a funds-theft vulnerability when paying BOLT 12 offers as well as a
funds-lockup denial-of-service issue for anchor channels.
 * When paying a BOLT 12 offer, if the recipient responds to our
   `invoice_request` with an `invoice` which had an amount different from the
   amount we intended to pay (either from the `offer` or the `amount_msats`
   passed to `ChannelManager::pay_for_offer`), LDK would pay the amount from the
   `invoice`. As a result, a malicious recipient could cause us to overpay the
   amount we intended to pay (#3535).
 * Fixed a bug where a counterparty can cause funds of ours to be locked up
   by broadcasting a revoked commitment transaction and following HTLC
   transactions in specific formats when using an anchor channel. The funds can
   be recovered by upgrading to 0.1 and replaying the counterparty's broadcasted
   transactions (using `Confirm::transactions_confirmed`) (#3537). Thanks to
   Matt Morehouse for reporting and fixing this issue.
 * Various denial-of-service issues in the formerly-alpha `lightning-liquidity`
   crate have been addressed (#3436, #3493).

v0.1.0-beta1

Release notes forthcoming.

v0.0.125 - Oct 14, 2024 - "Delayed Beta Testing"

Bug Fixes
=========

 * On upgrade to 0.0.124, channels which were at a steady-state (i.e. for which
   the counterparty has received our latest `revoke_and_ack` message) will
   force-close upon receiving the next channel state update from our
   counterparty. When built with debug assertions a debug assertion failure will
   occur instead (#3362).
 * Listeners in a `ChainListenerSet` will now have their `block_connected`
   method called, when appropriate, rather than always having their
   `filtered_block_connected` method called with full block data (#3354).
 * Routefinding historical liquidity channel scores were made more consistent
   for channels which have very little data which has been decayed (#3362).
 * A debug assertion failure when adding nodes to the network graph after
   removal of nodes from the network graph was fixed (#3362).

In total, this release features 6 files changed, 32 insertions, 7
deletions in 5 commits since 0.0.124 from 2 authors, in alphabetical order:

 * Elias Rohrer
 * Matt Corallo

v0.0.124 - Sep 3, 2024 - "Papercutting Feature Requests"

API Updates
===========

 * `rust-bitcoin` has been updated to 0.32. The new `bitcoin-io` crate is now
   used for all IO traits, irrespective of the features set on LDK crates.
   LDK crates no longer automatically force features on dependent crates where
   possible, allowing different `std`/`no-std` settings between LDK and
   rust-bitcoin crates (e.g. to disable `std` on LDK to ensure system time is
   not accessed while using `bitcoin-io`'s `std` feature). (#3063, #3239, #3249).
 * A new `lightning_types` crate was added which contains various top-level
   types. Using types from `lightning::ln::features` or
   `Payment{Hash,Preimage,Secret}` from `lightning::ln` or
   `lightning::ln::types` is now deprecated. The new crate is re-exported as
   `lightning::types` (#3234, #3253).
 * `lightning` now depends on `lightning-invoice`, rather than the other way
   around. The `lightning_invoice::payment` module has moved to
   `lightning::ln::bolt11_payment` and `lightning_invoice::utils` to
   `lightning::ln::invoice_utils` (#3234).
 * Event handlers may now return errors, causing most events to be replayed
   immediately without blocking the background processor. See documentation on
   individual `Event`s for more information on replay (#2995).
 * `ChannelDetails::balance_msat` is deprecated in favor of
   `ChainMonitor::get_claimable_balances` and the `Balance`, which now contains
   substantially more details and more accurately calculates a node-wide
   balance when `Balance::claimable_amount_satoshis` are summed (#3212, #3247).
 * `ConfirmationTarget` has two new variants - a `MaximumFeeEstimate` which can
   help to avoid spurious force-closes by ensuring we always accept feerates up
   to this value from peers as sane and a `UrgentOnChainSweep`, replacing
   `OnChainSweep` and only being used when the on-chain sweep is urgent (#3268).
 * All `ChannelMonitor`s are no longer persisted after each block connection,
   instead spreading them out over a handful of blocks to reduce load spikes.
   Note that this will increase the incidence of `ChannelMonitor`s that have
   different best blocks on startup, requiring some additional chain replay
   (but only on some `ChannelMonitor`s) on startup for `Listen` users (#2966).
 * A new format for Rapid Gossip Sync data is now supported which contains
   additional node metadata and is more extensible (#3098).
 * `ChannelManager::send_payment_with_route` is now deprecated in favor of the
   much easier to use `Channelmanager::send_payment`. Those who wish to manually
   select the route such payments go over should do so by matching the
   `payment_id` passed to `send_payment` in `Router::find_route_with_id` (#3224)
 * `lightning-transaction-sync` now takes most `Confirm`s as a generic `Deref`.
   You may need an explicit `as &(dyn Confirm)` to update existing code (#3101).
 * HTLCs will now be forwarded over any channel with a peer, rather than only
   the specific channel requested by the payment sender (#3127).
 * `Event::PaymentFailed` is now used in place of `Event::InvoiceRequestFailed`,
   holding an `Option` for the payment hash, which will be `None` when no
   invoice has been received (#3192).
 * `ChannelManager` now supports intercepting and manually paying
   `Bolt12Invoice`s, see `UserConfig::manually_handle_bolt12_invoices` (#3078).
 * `logger::Record`s now contain a `PaymentHash` (#2930).
 * `ChainMonitor` no longer uses an opaque `MonitorUpdateId`, opting to reuse
   the `ChannelMonitorUpdate::update_id` instead. Note that you no longer have
   to call `ChainMonitor::channel_monitor_updated` for
   `ChannelMonitorUpdateStatus::InProgress` updates to a monitor that were
   started without a `ChannelMonitorUpdate` (#2957).
 * `NodeAnnouncementInfo` is now an enum holding either a gossip message or
   the important fields, reducing the memory usage of `NetworkGraph` (#3072).
 * Onion message handlers now include a message context, which allows for
   blinded path authentication (#3085, #3202).
 * `ChannelManager` now supports funding with only a txid and output index, see
   `ChannelManager::unsafe_manual_funding_transaction_generated` (#3024).
 * BOLT 12 invoice requests now go out over, and accept responses over, multiple
   paths (#3087).
 * `OnionMessenger` now supports intercepting and re-forwarding onion messages
   for peers that are offline at the time of receipt when constructed with
   `new_with_offline_peer_interception` (#2973).
 * Onion message handling trait methods now generally take a `Responder` which
   can be used to create a `ResponseInstruction` to better control how responses
   are sent. The `ResponseInstruction` can also be converted to
   `MessageSendInstructions` which can be passed to `OnionMessenger`'s
   `send_onion_message` to respond asynchronously (#2907, #2996, #3263).
 * `OnionMessenger::process_pending_events_async` was added (#3060).
 * Blinded paths used for BOLT 12 `Offer`/`Refund`s are now compact when they
   expire relatively soon, making them somewhat smaller (#3011, #3080).
 * `ChannelManager::force_close_*` now take a err msg to send to peers (#2889).
 * `ChannelDetails::is_public` has been renamed to `is_announced` and
   `ChannelHandshakeConfig::announced_channel` to `announce_for_forwarding` to
   address various misconceptions about the purpose of announcement (#3257).
 * `BlindedPath`s are now split into `BlindedMessagePath`s and
   `BlindedPaymentPath`s and `advance_path_by_one` added to each (#3182).
 * `BlindedPaymentPath` now includes the `BlindedPayInfo` (#3245).
 * BOLT 12 `Offer`/`Refund` builders no longer require a description, instead
   allowing it to be set on the builder itself (#3018).
 * The `{Inbound,Outbound}HTLCState{,Details}` and `ChannelDetails` structs have
   moved to the `ln::channel_state` module (#3089).
 * `Event::OpenChannelRequest` now contains `params` and `is_announced` (#3019).
 * Peers are no longer disconnected when we force-close a channel (#3088).
 * BOLT12 `Offer` and `Refund` now implement `Readable` (#2965).
 * `RecipientOnionFields` is now included in `Event::PaymentClaimed` (#3084).
 * `ClosureReason::HolderForceClosed::broadcasted_latest_txn` was added (#3107).
 * `EcdsaChannelSigner` no longer needs to be `Writeable` and the supertrait
   `WriteableEcdsaChannelSigner` has been removed (#3059).
 * `CustomMessageHandler::peer_{,dis}connected` were added (#3105).
 * `lightning_invoice::Description::as_inner()` was added (#3203).
 * Splice-related wire messages have been updated to the latest spec (#3129).

Bug Fixes
=========

 * `channel_update` messages are no longer extracted from failed payments and
   applied to the network graph via `Event::PaymentPathFailed`, preventing a
   node along the path from identifying the sender of a payment (#3083).
 * In order to prevent senders from identifying the recipient of a BOLT 12 offer
   that included a blinded path, cryptographic information from blinded paths
   are now included in the invoice request verification (#3085, #3139, #3242).
 * Routes are now length-limited based on the actual onion contents rather than
   a fixed value. This ensures no routes are generated that are unpayable when
   sending HTLCs with custom TLVs, blinded paths, or metadata (#3026, #3156).
 * Unannounced LDK nodes (or ones without a network graph) will now include
   unannounced peers as introduction points in blinded paths. This addresses
   issues where test networks were not usable for BOLT 12 due to failures to
   find paths over private channels to LDK nodes. It will also enable creating
   BOLT 12 offers for nodes with no local network graph (#3132).
 * If a channel partner fails to update the feerate on a channel for some time
   and prevailing network feerates increase, LDK will now force-close
   automatically to avoid being unable to claim our funds on-chain. In order to
   reduce false-positives, it does so by comparing the channel's fee against the
   minimum `ConfirmationTarget::MinAllowed{,Non}AnchorChannelRemoteFee` we've
   seen over the past day (and do not force-close if we haven't been running for
   a full day, #3037).
 * `MonitorUpdatingPersister` did not read `ChannelMonitorUpdate`s when
   archiving a `ChannelMonitor`, causing the archived `ChannelMonitor` to be
   missing some updates. Those updates were not removed from the `KVStore` and
   monitors being archived should have no pending updates as they were persisted
   on each new block for some time before archiving (#3276).
 * `CoinSelection`s selected for commitment transactions which did not contain a
   change output no longer result in broadcasting a non-standard transaction nor
   in under-paying the target feerate (#3285). Note that such a transaction
   would fail to propagate and LDK would have continued to bump the fee until a
   different `CoinSelection` is used which did contain a change output.
 * `invoice_error`s from BOLT 12 recipients now fail payments (#3085, #3192).
 * Fixed a bug which may lead to a missing `Event::ChannelClosed` and missing
   `Error` messages for peers when a bogus funding transaction is provided for a
   batch channel open (#3029).
 * Fixed an overflow in `RawBolt11Invoice::amount_pico_btc()` reachable via
   `Bolt11Invoice::amount_milli_satoshis()`, resulting in a debug panic or bogus
   value for invoices with invalid values (#3032).
 * In incredibly rare circumstances, when using the beta asynchronous
   persistence, it is possible that the preimage for an MPP claim could fail to
   be persisted in the `ChannelMonitor` for one or more MPP parts, resulting in
   only some of the payment's value being claimed (#3120).
 * A rare race was fixed which could lead to `ChannelMonitorUpdate`s appearing
   after a full `ChannelMonitor` persistence that already contained the same
   update. This could have caused a panic on startup for users of the
   `MonitorUpdatingPersister` in rare cases after a crash (#3196).
 * Background Processor is now woken from `ChainMonitor` when new blocks appear,
   reducing the worst-case latency to see an `Event::SpendableOutputs` (#3033).
 * `OnionMessenger::get_update_future` was added, allowing it to wake the
   background processor to ensure `Event`s are processed quickly (#3194).
 * `CoinSelection`s overpaying the target feerate by more than 1% no longer
   leads to a debug assertion (#3285).

Backwards Compatibility
=======================

 * BOLT 12 `Offer`s created in prior versions are still valid but are at risk of
   deanonymization attacks allowing identification of the recipient node (#3139)
 * BOLT 12 outbound payments in state `RecentPaymentDetails::AwaitingInvoice`
   will eventually time out after upgrade to 0.0.124 as any received invoice
   will be considered invalid (#3139).
 * BOLT 12 `Refund`s created in prior version with non-empty `Refund::paths` are
   considered invalid by `ChannelManager`. Any attempts to claim them will be
   ignored. `Refund`s without blinded paths are unaffected (#3139).
 * The format written by `impl_writeable_tlv_based_enum[_upgradable]` for tuple
   variants has changed, only impacting LDK-external use of the macros (#3160).
 * An `Event::PaymentFailed` without a payment hash will deserialize to a
   payment hash of all-0s when downgrading (#3192).
 * `Event::PaymentFailed` reasons may be mapped to similar reasons that were
   available in previous versions on downgrade (#3192).

Performance Improvements
========================

 * Route-finding is 11-23% faster (#3103, #3104, #2803, #3188, on an Intel Xeon
   Silver 4116 (Skylake)).
 * `lightning-block-sync` now much better avoids lock contention during parallel
   requests for block data, speeding up gossip sync from multiple peers (#3197).

Node Compatibility
==================

 * 0.0.123 contained a workaround for CLN v24.02 requiring the `gossip_queries`
   feature for all peers. Since an updated CLN has now shipped which does not
   require this, the workaround has been reverted (#3172).
 * LDK now supports BOLT 12 Offers without an explicit signing public key,
   allowing it to pay more compact offers generated by other nodes (#3017).
 * LDK now supports BOLT 12 Offers without descriptions when no amount is
   present (#3018).
 * A bug was fixed which might have led to LDK spuriously rejecting
   `channel_update`s that use as-yet-undefined flag bits (#3144).

In total, this release features 312 files changed, 29853 insertions, 15480
deletions in 549 commits since 0.0.123 from 26 authors, in alphabetical order:

 * Alec Chen
 * Arik Sosman
 * Duncan Dean
 * Elias Rohrer
 * Filip Gospodinov
 * G8XSU
 * Gursharan Singh
 * Harshit Verma
 * Jeffrey Czyz
 * Jiri Jakes
 * John Cantrell
 * Lalitmohansharma1
 * Matt Corallo
 * Matthew Rheaume
 * Max Fang
 * Mirebella
 * Tobin C. Harding
 * Valentine Wallace
 * Vincenzo Palazzo
 * Willem Van Lint
 * benthecarman
 * cooltexture
 * esraa
 * jbesraa
 * optout
 * shaavan

v0.0.123 - May 08, 2024 - "BOLT12 Dust Sweeping"

API Updates
===========

 * To reduce risk of force-closures and improve HTLC reliability the default
   dust exposure limit has been increased to
   `MaxDustHTLCExposure::FeeRateMultiplier(10_000)`. Users with existing
   channels might want to consider using
   `ChannelManager::update_channel_config` to apply the new default (#3045).
 * `ChainMonitor::archive_fully_resolved_channel_monitors` is now provided to
   remove from memory `ChannelMonitor`s that have been fully resolved on-chain
   and are now not needed. It uses the new `Persist::archive_persisted_channel`
   to inform the storage layer that such a monitor should be archived (#2964).
 * An `OutputSweeper` is now provided which will automatically sweep
   `SpendableOutputDescriptor`s, retrying until the sweep confirms (#2825).
 * After initiating an outbound channel, a peer disconnection no longer results
   in immediate channel closure. Rather, if the peer is reconnected before the
   channel times out LDK will automatically retry opening it (#2725).
 * `PaymentPurpose` now has separate variants for BOLT12 payments, which
   include fields from the `invoice_request` as well as the `OfferId` (#2970).
 * `ChannelDetails` now includes a list of in-flight HTLCs (#2442).
 * `Event::PaymentForwarded` now includes `skimmed_fee_msat` (#2858).
 * The `hashbrown` dependency has been upgraded and the use of `ahash` as the
   no-std hash table hash function has been removed. As a consequence, LDK's
   `Hash{Map,Set}`s no longer feature several constructors when LDK is built
   with no-std; see the `util::hash_tables` module instead. On platforms that
   `getrandom` supports, setting the `possiblyrandom/getrandom` feature flag
   will ensure hash tables are resistant to HashDoS attacks, though the
   `possiblyrandom` crate should detect most common platforms (#2810, #2891).
 * `ChannelMonitor`-originated requests to the `ChannelSigner` can now fail and
   be retried using `ChannelMonitor::signer_unblocked` (#2816).
 * `SpendableOutputDescriptor::to_psbt_input` now includes the `witness_script`
   where available as well as new proprietary data which can be used to
   re-derive some spending keys from the base key (#2761, #3004).
 * `OutPoint::to_channel_id` has been removed in favor of
   `ChannelId::v1_from_funding_outpoint` in preparation for v2 channels with a
   different `ChannelId` derivation scheme (#2797).
 * `PeerManager::get_peer_node_ids` has been replaced with `list_peers` and
   `peer_by_node_id`, which provide more details (#2905).
 * `Bolt11Invoice::get_payee_pub_key` is now provided (#2909).
 * `Default[Message]Router` now take an `entropy_source` argument (#2847).
 * `ClosureReason::HTLCsTimedOut` has been separated out from
   `ClosureReason::HolderForceClosed` as it is the most common case (#2887).
 * `ClosureReason::CooperativeClosure` is now split into
   `{Counterparty,Locally}Initiated` variants (#2863).
 * `Event::ChannelPending::channel_type` is now provided (#2872).
 * `PaymentForwarded::{prev,next}_user_channel_id` are now provided (#2924).
 * Channel init messages have been refactored towards V2 channels (#2871).
 * `BumpTransactionEvent` now contains the channel and counterparty (#2873).
 * `util::scid_utils` is now public, with some trivial utilities to examine
   short channel ids (#2694).
 * `DirectedChannelInfo::{source,target}` are now public (#2870).
 * Bounds in `lightning-background-processor` were simplified by using
   `AChannelManager` (#2963).
 * The `Persist` impl for `KVStore` no longer requires `Sized`, allowing for
   the use of `dyn KVStore` as `Persist` (#2883, #2976).
 * `From<PaymentPreimage>` is now implemented for `PaymentHash` (#2918).
 * `NodeId::from_slice` is now provided (#2942).
 * `ChannelManager` deserialization may now fail with `DangerousValue` when
    LDK's persistence API was violated (#2974).

Bug Fixes
=========

 * Excess fees on counterparty commitment transactions are now included in the
   dust exposure calculation. This lines behavior up with some cases where
   transaction fees can be burnt, making them effectively dust exposure (#3045).
 * `Future`s used as an `std::...::Future` could grow in size unbounded if it
   was never woken. For those not using async persistence and using the async
   `lightning-background-processor`, this could cause a memory leak in the
   `ChainMonitor` (#2894).
 * Inbound channel requests that fail in
   `ChannelManager::accept_inbound_channel` would previously have stalled from
   the peer's perspective as no `error` message was sent (#2953).
 * Blinded path construction has been tuned to select paths more likely to
   succeed, improving BOLT12 payment reliability (#2911, #2912).
 * After a reorg, `lightning-transaction-sync` could have failed to follow a
   transaction that LDK needed information about (#2946).
 * `RecipientOnionFields`' `custom_tlvs` are now propagated to recipients when
   paying with blinded paths (#2975).
 * `Event::ChannelClosed` is now properly generated and peers are properly
   notified for all channels that as a part of a batch channel open fail to be
   funded (#3029).
 * In cases where user event processing is substantially delayed such that we
   complete multiple round-trips with our peers before a `PaymentSent` event is
   handled and then restart without persisting the `ChannelManager` after having
   persisted a `ChannelMonitor[Update]`, on startup we may have `Err`d trying to
   deserialize the `ChannelManager` (#3021).
 * If a peer has relatively high latency, `PeerManager` may have failed to
   establish a connection (#2993).
 * `ChannelUpdate` messages broadcasted for our own channel closures are now
   slightly more robust (#2731).
 * Deserializing malformed BOLT11 invoices may have resulted in an integer
   overflow panic in debug builds (#3032).
 * In exceedingly rare cases (no cases of this are known), LDK may have created
   an invalid serialization for a `ChannelManager` (#2998).
 * Message processing latency handling BOLT12 payments has been reduced (#2881).
 * Latency in processing `Event::SpendableOutputs` may be reduced (#3033).

Node Compatibility
==================

 * LDK's blinded paths were inconsistent with other implementations in several
   ways, which have been addressed (#2856, #2936, #2945).
 * LDK's messaging blinded paths now support the latest features which some
   nodes may begin relying on soon (#2961).
 * LDK's BOLT12 structs have been updated to support some last-minute changes to
   the spec (#3017, #3018).
 * CLN v24.02 requires the `gossip_queries` feature for all peers, however LDK
   by default does not set it for those not using a `P2PGossipSync` (e.g. those
   using RGS). This change was reverted in CLN v24.02.2 however for now LDK
   always sets the `gossip_queries` feature. This change is expected to be
   reverted in a future LDK release (#2959).

Security
========
0.0.123 fixes a denial-of-service vulnerability which we believe to be reachable
from untrusted input when parsing invalid BOLT11 invoices containing non-ASCII
characters.
 * BOLT11 invoices with non-ASCII characters in the human-readable-part may
   cause an out-of-bounds read attempt leading to a panic (#3054). Note that all
   BOLT11 invoices containing non-ASCII characters are invalid.

In total, this release features 150 files changed, 19307 insertions, 6306
deletions in 360 commits since 0.0.121 from 17 authors, in alphabetical order:

 * Arik Sosman
 * Duncan Dean
 * Elias Rohrer
 * Evan Feenstra
 * Jeffrey Czyz
 * Keyue Bao
 * Matt Corallo
 * Orbital
 * Sergi Delgado Segura
 * Valentine Wallace
 * Willem Van Lint
 * Wilmer Paulino
 * benthecarman
 * jbesraa
 * olegkubrakov
 * optout
 * shaavan

v0.0.123-rc1 - May 7, 2024 - "Faster Async BOLT12 Retries"

Release notes forthcoming for the full release.

0.0.114-beta - Feb 28, 2023 - "Faster Async BOLT12 Retries"

Release notes forthcoming for the full release.