diff --git a/CHANGELOG.md b/CHANGELOG.md index 6df2b2c2133..95a1ef79571 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,176 @@ +# 0.1 - Jan XXX, 2025 - XXX + +## 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). + * Various denial-of-service issues in the formerly-alpha `lightning-liquidity` + crate have been addressed (#3436, #3493). + + # 0.0.125 - Oct 14, 2024 - "Delayed Beta Testing" ## Bug Fixes diff --git a/pending_changelog/3137-channel-negotiation-type.txt b/pending_changelog/3137-channel-negotiation-type.txt deleted file mode 100644 index 8eafa4e072b..00000000000 --- a/pending_changelog/3137-channel-negotiation-type.txt +++ /dev/null @@ -1,7 +0,0 @@ -# API Updates - * `Event::OpenChannelRequest::push_msat` has been replaced by the field `channel_negotiation_type` to - differentiate between an inbound request for a dual-funded (V2) or non-dual-funded (V1) channel to be - opened, with value being either of the enum variants `InboundChannelFunds::DualFunded` and - `InboundChannelFunds::PushMsat(u64)` corresponding to V2 and V1 channel open requests respectively. - This is in preparation for supporting accepting dual-funded channels, which will be available in a later release. - diff --git a/pending_changelog/3243-remove-balance_msat.txt b/pending_changelog/3243-remove-balance_msat.txt deleted file mode 100644 index 6378bd79054..00000000000 --- a/pending_changelog/3243-remove-balance_msat.txt +++ /dev/null @@ -1 +0,0 @@ -* The `AvailableBalances::balance_msat` field has been removed in favor of `ChainMonitor::get_claimable_balances`. `ChannelDetails` serialized with versions of LDK >= 0.0.125 will have their `balance_msat` field set to `next_outbound_htlc_limit_msat` when read by versions of LDK prior to 0.0.125 (#3243). diff --git a/pending_changelog/3259-no-downgrade.txt b/pending_changelog/3259-no-downgrade.txt deleted file mode 100644 index ed4193da480..00000000000 --- a/pending_changelog/3259-no-downgrade.txt +++ /dev/null @@ -1,4 +0,0 @@ -# Backwards Compatibility - * Downgrading after using `ChannelManager`'s - `unsafe_manual_funding_transaction_generated` may cause deserialization of - `ChannelManager` to fail with an `Err` (#3259). diff --git a/pending_changelog/3322-a.txt b/pending_changelog/3322-a.txt deleted file mode 100644 index 83849926a4e..00000000000 --- a/pending_changelog/3322-a.txt +++ /dev/null @@ -1,6 +0,0 @@ -API Changes -=========== - -Additional information is now stored in `ChannelMonitorUpdate`s which may increase the size of -`ChannelMonitorUpdate`s claiming inbound payments substantially. The expected maximum size of -`ChannelMonitorUpdate`s shouldn't change materially. diff --git a/pending_changelog/3322-b.txt b/pending_changelog/3322-b.txt deleted file mode 100644 index c8bb0c64bd9..00000000000 --- a/pending_changelog/3322-b.txt +++ /dev/null @@ -1,7 +0,0 @@ -API Updates -=========== - -As a part of adding robustness against several unlikely scenarios, redundant `PaymentClaimed` -`Event`s will be generated more frequently on startup for payments received on LDK 0.1 and -newer. A new `Event::PaymentClaimed::payment_id` field may be used to better differentiate -between redundant payments. diff --git a/pending_changelog/3358-include-counterparty-id-in-payment-forwarded.txt b/pending_changelog/3358-include-counterparty-id-in-payment-forwarded.txt deleted file mode 100644 index 8c2b1e338a6..00000000000 --- a/pending_changelog/3358-include-counterparty-id-in-payment-forwarded.txt +++ /dev/null @@ -1,7 +0,0 @@ -API Updates -=========== - -To improve clarity and uniqueness in identifying forwarded payments, the `PaymentForwarded` -event now includes counterparty node IDs alongside `ChannelIds`. This change resolves -potential ambiguity in cases like v1 0conf channel opens, where `ChannelIds` alone may not -be unique. \ No newline at end of file diff --git a/pending_changelog/3383-deprecate-old-inbounds.txt b/pending_changelog/3383-deprecate-old-inbounds.txt deleted file mode 100644 index 654cbcb5078..00000000000 --- a/pending_changelog/3383-deprecate-old-inbounds.txt +++ /dev/null @@ -1,6 +0,0 @@ -# Backwards Compatibility -* Pending inbound payments added in versions 0.0.116 or earlier using the - `create_inbound_payment{,_for_hash}_legacy` API will be ignored on `ChannelManager` - deserialization and fail to be received - - diff --git a/pending_changelog/3435-authenticate-payment-receive-tlvs.txt b/pending_changelog/3435-authenticate-payment-receive-tlvs.txt deleted file mode 100644 index 714bd00d8ce..00000000000 --- a/pending_changelog/3435-authenticate-payment-receive-tlvs.txt +++ /dev/null @@ -1,9 +0,0 @@ -## API Updates - * Payment `ReceiveTlvs` now contains an `authentication` field. It should be - set to `None` and then filled in with a nonce and the HMAC produced by - `ReceiveTlvs::hmac_for_offer_payment` when passing in the nonce (#3435). - -## Backwards Compatibility - * `ReceiveTlvs` for payments over `BlindedPaymentPath`s are now authenticated. - Any inbound payments for a preexisting `Bolt12Invoice` will therefore fail - (#3435). diff --git a/pending_changelog/3439-remove-accept-mpp-keysend-cfg.txt b/pending_changelog/3439-remove-accept-mpp-keysend-cfg.txt deleted file mode 100644 index f52d123d2ac..00000000000 --- a/pending_changelog/3439-remove-accept-mpp-keysend-cfg.txt +++ /dev/null @@ -1,3 +0,0 @@ -# Backwards Compatibility -* The presence of pending inbound MPP keysend payments breaks downgrades to LDK versions 0.0.115 and - earlier. diff --git a/pending_changelog/matt-no-upgrade-skip.txt b/pending_changelog/matt-no-upgrade-skip.txt deleted file mode 100644 index f5fcb8c5f25..00000000000 --- a/pending_changelog/matt-no-upgrade-skip.txt +++ /dev/null @@ -1,6 +0,0 @@ -## 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 and resolve any HTLCs that were - originally forwarded or received running 0.0.123 or earlier. diff --git a/pending_changelog/matt-persist-preimage-on-upgrade.txt b/pending_changelog/matt-persist-preimage-on-upgrade.txt deleted file mode 100644 index fc53469c6f6..00000000000 --- a/pending_changelog/matt-persist-preimage-on-upgrade.txt +++ /dev/null @@ -1,8 +0,0 @@ -# Backwards Compatibility - * The `ChannelManager` deserialization semantics no longer require that - `ChannelMonitor`s be re-persisted after `(BlockHash, ChannelManager)::read` - is called prior to normal node operation. This applies to upgraded nodes - only *after* a startup with the old semantics completes at least once. IOW, - you must deserialize the `ChannelManager` with upgraded LDK, persist the - `ChannelMonitor`s then continue to normal startup once, and thereafter you - may skip the `ChannelMonitor` persistence step.