|
| 1 | +# 0.1 - Jan XXX, 2025 - XXX |
| 2 | + |
| 3 | +## API Updates |
| 4 | + * The `lightning-liquidity` crate has been moved into the `rust-lightning` |
| 5 | + git tree, enabling support for both sides of the LSPS channel open |
| 6 | + negotiation protocols (#3436). |
| 7 | + * Since its last alpha release, `lightning-liquidity` has also gained support |
| 8 | + for acting as an LSPS1 client (#3436). |
| 9 | + * This release includes support for BIP 353 Human Readable Names resolution. |
| 10 | + With the `dnssec` feature enabled, simply call `ChannelManager`'s |
| 11 | + `pay_for_offer_from_human_readable_name` with a list of lightning nodes that |
| 12 | + have the `dns_resolver` feature flag set (e.g. those running LDK with the |
| 13 | + new `lightning_dns_resolver::OMDomainResolver` set up to resolve DNS queries |
| 14 | + for others) and a Human Readable Name (#3346, #3179, #3283). |
| 15 | + * Asynchronous `ChannelMonitorUpdate` persistence (i.e. the use of |
| 16 | + `ChannelMonitorUpdateStatus::InProgress`) is now considered beta-quality. |
| 17 | + There are no known issues with it, though the likelihood of unknown issues |
| 18 | + is high (#3414). |
| 19 | + * `ChannelManager`'s `send_payment_with_route` and `send_spontaneous_payment` |
| 20 | + were removed. Use `send_payment` and `send_spontaneous_payment_with_retry` |
| 21 | + (now renamed `send_spontaneous_payment`) instead (#3430). |
| 22 | + * `ChannelMonitor`s no longer need to be re-persisted after deserializing the |
| 23 | + `ChannelManager` before beginning normal operation. As such, |
| 24 | + `ChannelManagerReadArgs::channel_monitors` no longer requires mutable |
| 25 | + references (#3322). See the Backwards Compatibility section for more info. |
| 26 | + * Additional information is now stored in `ChannelMonitorUpdate`s which may |
| 27 | + increase the average size of `ChannelMonitorUpdate`s when claiming inbound |
| 28 | + payments substantially. The expected maximum size of `ChannelMonitorUpdate`s |
| 29 | + shouldn't change materially (#3322). |
| 30 | + * Redundant `Event::PaymentClaimed`s will be generated more frequently on |
| 31 | + startup compared to previous versions. |
| 32 | + `Event::PaymentClaim{able,ed}::payment_id` has been added to allow for more |
| 33 | + robust handling of redundant events on payments with duplicate |
| 34 | + `PaymentHash`es (#3303, #3322). |
| 35 | + * `ChannelMonitorUpdate::update_id`s no longer have a magic value (of |
| 36 | + `u64::MAX`) for updates after a channel has been closed. They are now |
| 37 | + always monotonically increasing (#3355). |
| 38 | + * The MSRV of `lightning-transaction-sync` has been increased to rustc 1.75 due |
| 39 | + to its HTTP client dependencies (#3528). |
| 40 | + * The default `ProbabilisticScoringFeeParameters` values now recommend specific |
| 41 | + ratios between different penalties, and default penalties now allow for |
| 42 | + higher fees in order to reduce payment latency (#3495). |
| 43 | + * On-chain state resolution now more aggressively batches claims into single |
| 44 | + transactions, reducing on-chain fee costs when resolving multiple HTLCs for a |
| 45 | + single channel force-closure. This also reduces the on-chain reserve |
| 46 | + requirements for nodes using anchor channels (#3340). |
| 47 | + * A `MigratableKVStore` trait was added (and implemented for |
| 48 | + `FilesystemStore`), enabling easy migration between `KVStore`s (#3481). |
| 49 | + * `InvoiceRequest::amount_msats` now returns the `offer`-implied amount if a |
| 50 | + Bitcoin-denominated amount was set in the `offer` and no amount was set |
| 51 | + directly in the `invoice_request` (#3535). |
| 52 | + * `Event::OpenChannelRequest::push_msat` has been replaced with an enum in |
| 53 | + preparation for the dual-funding protocol coming in a future release (#3137). |
| 54 | + * `GossipVerifier` now requires a `P2PGossipSync` which holds a reference to |
| 55 | + the `GossipVerifier` via an `Arc` (#3432). |
| 56 | + * The `max_level_*` features were removed as the performance gain compared to |
| 57 | + doing the limiting at runtime was negligible (#3431). |
| 58 | + * `ChannelManager::create_bolt11_invoice` was added, deprecating the |
| 59 | + `lightning::ln::invoice_utils` module (#3389). |
| 60 | + * The `bech32` dependency has been upgraded to 0.11 across crates (#3270). |
| 61 | + * Support for creating BOLT 12 `invoice_request`s with a static signing key |
| 62 | + rather than an ephemeral one has been removed (#3264). |
| 63 | + * The `Router` trait no longer extends the `MessageRouter` trait, creating an |
| 64 | + extra argument to `ChannelManager` construction (#3326). |
| 65 | + * The deprecated `AvailableBalances::balance_msat` has been removed in favor of |
| 66 | + `ChannelMonitor::get_claimable_balances` (#3243). |
| 67 | + * Deprecated re-exports of `Payment{Hash,Preimage,Secret}` and `features` were |
| 68 | + removed (#3359). |
| 69 | + * `bolt11_payment::*_from_zero_amount_invoice` methods were renamed |
| 70 | + `*_from_variable_amount_invoice` (#3397) |
| 71 | + * Offer `signing_pubkey` (and related struct names) have been renamed |
| 72 | + `issuer_signing_pubkey` (#3218). |
| 73 | + * `Event::PaymentForwarded::{prev,next}_node_id` were added (#3458). |
| 74 | + * `Event::ChannelClosed::last_local_balance_msat` was added (#3235). |
| 75 | + * `RoutingMessageHandler::handle_*` now all have a `node_id` argument (#3291). |
| 76 | + * `lightning::util::persist::MonitorName` has been exposed (#3376). |
| 77 | + * `ProbabilisticScorer::live_estimated_payment_success_probability` was added |
| 78 | + (#3420) |
| 79 | + * `EcdsaChannelSigner::sign_splicing_funding_input` was added to support an |
| 80 | + eventual splicing feature (#3316). |
| 81 | + * `{Payment,Offer}Id` now support lowercase-hex formatting (#3377). |
| 82 | + |
| 83 | +## Bug Fixes |
| 84 | + * Fixed a rare case where a BOLT 12 payment may be made duplicatively if the |
| 85 | + node crashes while processing a BOLT 12 `invoice` message (#3313). |
| 86 | + * Fixed a bug where a malicious sender could cause a payment `Event` to be |
| 87 | + generated with an `OfferId` using a payment with a lower amount than the |
| 88 | + corresponding BOLT 12 offer would have required. The amount in the |
| 89 | + `Event::Payment{Claimable,Claimed}` were still correct (#3435). |
| 90 | + * The `ProbabilisticScorer` model and associated default scoring parameters |
| 91 | + were tweaked to be more predictive of real-world results (#3368, #3495). |
| 92 | + * `ProbabilisticScoringFeeParameters::base_penalty_amount_multiplier_msat` no |
| 93 | + longer includes any pending HTLCs we already have through channels in the |
| 94 | + graph, avoiding over-penalizing them in comparison to other channels (#3356). |
| 95 | + * A `ChannelMonitor` will no longer be archived if a `MonitorEvent` containing |
| 96 | + a preimage for another channel is pending. This fixes an issue where a |
| 97 | + payment preimage needed for another channel claim is lost if events go |
| 98 | + un-processed for 4038 blocks (#3450). |
| 99 | + * `std` builds no longer send the full gossip state to peers that do not |
| 100 | + request it (#3390). |
| 101 | + * `lightning-block-sync` listeners now receive `block_connected` calls, rather |
| 102 | + than always receiving `filtered_block_connected` calls (#3354). |
| 103 | + * Fixed a bug where some transactions were broadcasted one block before their |
| 104 | + locktime made them candidates for inclusion in the mempool (though they would |
| 105 | + be automatically re-broadcasted later, #3453). |
| 106 | + * `ChainMonitor` now persists `ChannelMonitor`s when their `Balance` set first |
| 107 | + goes empty, making `ChannelMonitor` pruning more reliable on nodes that are |
| 108 | + only online briefly (e.g. mobile nodes, #3442). |
| 109 | + * BOLT 12 invoice requests now better handle intermittent internet connectivity |
| 110 | + (e.g. on mobile devices with app interruptions, #3010). |
| 111 | + * Broadcast-gossip `MessageSendEvent`s from the `ChannelMessageHandler` are now |
| 112 | + delivered to peers even if the peer is behind in processing relayed gossip. |
| 113 | + This ensures our own gossip propagates well even if we have very limited |
| 114 | + upload bandwidth (#3142). |
| 115 | + * Fixed a bug where calling `OutputSweeper::transactions_confirmed` with |
| 116 | + transactions from anything but the latest block may have triggered a spurious |
| 117 | + assertion in debug mode (#3524). |
| 118 | + |
| 119 | +## Performance Improvements |
| 120 | + * LDK now verifies `channel_update` gossip messages without holding a lock, |
| 121 | + allowing additional parallelism during gossip sync (#3310). |
| 122 | + * LDK now checks if it already has certain gossip messages before verifying the |
| 123 | + message signatures, reducing CPU usage during gossip sync after the first |
| 124 | + startup (#3305). |
| 125 | + |
| 126 | +## Node Compatibility |
| 127 | + * LDK now handles fields in the experimental range of BOLT 12 messages (#3237). |
| 128 | + |
| 129 | +## Backwards Compatibility |
| 130 | + * Nodes with pending forwarded HTLCs or unclaimed payments cannot be |
| 131 | + upgraded directly from 0.0.123 or earlier to 0.1. Instead, they must |
| 132 | + first either resolve all pending HTLCs (including those pending |
| 133 | + resolution on-chain), or run 0.0.124 or 0.0.125 and resolve any HTLCs that |
| 134 | + were originally forwarded or received running 0.0.123 or earlier (#3355). |
| 135 | + * `ChannelMonitor`s not being re-persisted after deserializing the |
| 136 | + `ChannelManager` only applies to upgraded nodes *after* a startup with the |
| 137 | + old semantics completes at least once. In other words, you must deserialize |
| 138 | + the `ChannelManager` with an upgraded LDK, persist the `ChannelMonitor`s as |
| 139 | + you would on pre-0.1 versions of LDK, then continue to normal startup once, |
| 140 | + and for startups thereafter you can take advantage of the new semantics |
| 141 | + avoiding redundant persistence on startup (#3322). |
| 142 | + * Pending inbound payments paying a BOLT 12 `invoice` issued prior to upgrade |
| 143 | + to LDK 0.1 will fail. Issued BOLT 12 `offer`s remain payable (#3435). |
| 144 | + * `UserConfig::accept_mpp_keysend` was removed, thus the presence of pending |
| 145 | + inbound MPP keysend payments will prevent downgrade to LDK 0.0.115 and |
| 146 | + earlier (#3439). |
| 147 | + * Inbound payments initialized using the removed |
| 148 | + `ChannelManager::create_inbound_payment{,_for_hash}_legacy` API will no |
| 149 | + longer be accepted by LDK 0.1 (#3383). |
| 150 | + * Downgrading to prior versions of LDK after using `ChannelManager`'s |
| 151 | + `unsafe_manual_funding_transaction_generated` may cause `ChannelManager` |
| 152 | + deserialization to fail (#3259). |
| 153 | + * `ChannelDetails` serialized with LDK 0.1+ read with versions prior to 0.1 |
| 154 | + will have `balance_msat` equal to `next_outbound_htlc_limit_msat` (#3243). |
| 155 | + |
| 156 | +## Security |
| 157 | +0.1 fixes a funds-theft vulnerability when paying BOLT 12 offers as well as a |
| 158 | +funds-lockup denial-of-service issue for anchor channels. |
| 159 | + * When paying a BOLT 12 offer, if the recipient responds to our |
| 160 | + `invoice_request` with an `invoice` which had an amount different from the |
| 161 | + amount we intended to pay (either from the `offer` or the `amount_msats` |
| 162 | + passed to `ChannelManager::pay_for_offer`), LDK would pay the amount from the |
| 163 | + `invoice`. As a result, a malicious recipient could cause us to overpay the |
| 164 | + amount we intended to pay (#3535). |
| 165 | + * Fixed a bug where a counterparty can cause funds of ours to be locked up |
| 166 | + by broadcasting a revoked commitment transaction and following HTLC |
| 167 | + transactions in specific formats when using an anchor channel. The funds can |
| 168 | + be recovered by upgrading to 0.1 and replaying the counterparty's broadcasted |
| 169 | + transactions (using `Confirm::transactions_confirmed`) (#3537). Thanks to |
| 170 | + Matt Morehouse for reporting and fixing this issue. |
| 171 | + * Various denial-of-service issues in the formerly-alpha `lightning-liquidity` |
| 172 | + crate have been addressed (#3436, #3493). |
| 173 | + |
| 174 | + |
1 | 175 | # 0.0.125 - Oct 14, 2024 - "Delayed Beta Testing" |
2 | 176 |
|
3 | 177 | ## Bug Fixes |
|
0 commit comments