|
14 | 14 | * `KVStore` has been made async. Note that `KVStore` methods are not |
15 | 15 | `async fn`, but rather write ordering is fixed when the methods return, |
16 | 16 | though write completion is async. |
17 | | - * `BumpTransactionEventHandler` is no backed by an async `WalletSource` (and |
| 17 | + * `BumpTransactionEventHandler` is now backed by an async `WalletSource` (and |
18 | 18 | `Wallet`) or an async `CoinSelectionSource` and is now async. Sync versions |
19 | | - are in the new `sync` submodule (#3752). |
| 19 | + are in the new `events::bump_transaction::sync` submodule (#3752). |
20 | 20 | * `OutputSweeper` is now backed by an async `KVStore` and |
21 | 21 | `ChangeDestinationSource` and is now async (#3819, #3734, #4131). |
22 | 22 | * `MonitorUpdatingPersisterAsync` and `ChainMonitor::new_async_beta` were |
|
33 | 33 | LDK-based LSPs wishing to support often-offline senders and recipients should |
34 | 34 | set `UserConfig::enable_htlc_hold`, support the existing "onion mesage |
35 | 35 | mailbox" feature (setting `intercept_messages_for_offline_peers` on |
36 | | - `OnionMessegner` and handling `Event::OnionMessageIntercepted`s), and handle |
| 36 | + `OnionMessenger` and handling `Event::OnionMessageIntercepted`s), and handle |
37 | 37 | `Event::PersistStaticInvoice`s and `Event::StaticInvoiceRequested`s. |
38 | 38 | * Zero-Fee-Commitment channels are now supported in LDK. These channels remove |
39 | 39 | force-closure risk for feerate disagreements by using a fixed, zero fee on |
|
42 | 42 | breaking compatibility. This is negotiated automatically for |
43 | 43 | manually-accepted inbound channels and negotiated for outbound channels based |
44 | 44 | on `ChannelHandshakeConfig::negotiate_anchors_zero_fee_htlc_tx`. |
45 | | - |
46 | 45 | * `Event::BumpTransaction` is now always generated even if the transaction has |
47 | 46 | sufficient fee. This allows you to manage transaction broadcasting more |
48 | 47 | granularly for anchor channels (#4001). |
|
54 | 53 | * `LSPS2ClientEvent` now has events for failure events (#3804). |
55 | 54 | * `LSPS2ServiceHandler::channel_open_abandoned` was added (#3712). |
56 | 55 | * `Event::PendingHTLCsForwardable` has been replaced with regular calls to |
57 | | - `process_pending_htlc_forwards` in the background processor when |
58 | | - `ChannelManager::needs_pending_htlc_processing` is true (#3891, #3955). |
| 56 | + `process_pending_htlc_forwards` in the background processor while |
| 57 | + `ChannelManager::needs_pending_htlc_processing` is true. The delay between |
| 58 | + calls (and, thus, HTLC forwarding delay) is random between zero and 200ms, |
| 59 | + averaging 50ms, faster than the previous recommendation (#3891, #3955). |
59 | 60 | * `Event::HTLCHandlingFailed`s now include a`LocalHTLCFailureReason`, providing |
60 | 61 | much more granular reasons for HTLCs having been failed (#3744, etc). |
61 | 62 | * `Event::HTLCHandlingFailed` is now generated any time forwarding an HTLC |
|
78 | 79 | * Repeated `Listen::block_disconnected` calls for each disconnected block in a |
79 | 80 | reorg have been replaced with a single `blocks_disconnected` call with the |
80 | 81 | fork point block (i.e. the highest block on both sides of the reorg, #3876). |
81 | | - * `lightning::routing::scoring::CombinedScorer` was added to better support |
82 | | - nodes using both remote scoring info and their own payment results (#3562). |
| 82 | + * `lightning::routing::scoring::CombinedScorer` was added to combine scoring |
| 83 | + data between remote scoring info and local payment results (#3562). |
83 | 84 | * LDK will now store up to 1KiB of "peer storage" data in `ChannelManager` per |
84 | 85 | peer with which we have a funded channel (#3575). |
85 | 86 | * `ProbabilisticScoringFeeParameters::probing_diversity_penalty` was added to |
|
138 | 139 | ## Backwards Compatibility |
139 | 140 | * `ChannelMonitor`s which were created prior to LDK 0.0.110 and which saw no |
140 | 141 | updates since LDK 0.0.116 may now fail to deserialize (#3638, #4146). |
| 142 | + * Setting `v2_remote_key_derivation` on `KeysManager` to true, or splicing a |
| 143 | + channel results in using keys which prior versions of LDK do not know how to |
| 144 | + derive. This may result in missing funds or panics trying to sweep closed |
| 145 | + channels after downgrading (#4117). |
141 | 146 | * After upgrading to 0.2, downgrading to versions of LDK prior to 0.0.123 is no |
142 | 147 | longer supported (#2933). |
143 | 148 | * Blinded paths generated by previous versions of LDK, except those generated |
|
0 commit comments