|
| 1 | +# 0.0.117 - XXX - "Everything but the Twelve Sinks" |
| 2 | + |
| 3 | +## API Updates |
| 4 | + * `ProbabilisticScorer`'s internal models have been substantially improved, |
| 5 | + including better decaying (#1789), a more granular historical channel |
| 6 | + liquidity tracker (#2176) and a now-default option to make our estimate for a |
| 7 | + channel's current liquidity nonlinear in the channel's capacity (#2547). In |
| 8 | + total, these changes should result in improved payment success rates at the |
| 9 | + cost of slightly worse routefinding performance. |
| 10 | + * Support for custom TLVs for recipients of HTLCs has been added (#2308). |
| 11 | + * Support for generating transactions for third-party watchtowers has been |
| 12 | + added to `ChannelMonitor/Update`s (#2337). |
| 13 | + * `KVStorePersister` has been replaced with a more generic and featureful |
| 14 | + `KVStore` interface (#2472). |
| 15 | + * A new `MonitorUpdatingPersister` is provided which wraps a `KVStore` and |
| 16 | + implements `Persist` by writing differential updates rather than full |
| 17 | + `ChannelMonitor`s (#2359). |
| 18 | + * Batch funding of outbound channels is now supported using the new |
| 19 | + `ChannelManager::batch_funding_transaction_generated` method (#2486). |
| 20 | + * `ChannelManager::send_preflight_probes` has been added to probe a payment's |
| 21 | + potential paths while a user is providing approval for a payment (#2534). |
| 22 | + * Fully asynchronous `ChannelMonitor` updating is available as an alpha |
| 23 | + preview. There remain a few known but incredibly rare race conditions which |
| 24 | + may lead to loss of funds (#2112, #2169, #2562). |
| 25 | + * `ChannelMonitorUpdateStatus::PermanentFailure` has been removed in favor of a |
| 26 | + new `ChannelMonitorUpdateStatus::UnrecoverableError`. The new variant panics |
| 27 | + on use, rather than force-closing a channel in an unsafe manner, which the |
| 28 | + previous variant did (#2562). Rather than panicking with the new variant, |
| 29 | + users may wish to use the new asynchronous `ChannelMonitor` updating using |
| 30 | + `ChannelMonitorUpdateStatus::InProgress`. |
| 31 | + * `RouteParameters::max_total_routing_fee_msat` was added to limit the fees |
| 32 | + paid when routing, defaulting to 1% + 50sats when using the new |
| 33 | + `from_payment_params_and_value` constructor (#2417, #2603, #2604). |
| 34 | + * Implementations of `UtxoSource` are now provided in `lightning-block-sync`. |
| 35 | + Those running with a full node should use this to validate gossip (#2248). |
| 36 | + * `LockableScore` now supports read locking for parallel routefinding (#2197). |
| 37 | + * `ChannelMonitor::get_spendable_outputs` was added to allow for re-generation |
| 38 | + of `SpendableOutputDescriptor`s for a channel after they were provided via |
| 39 | + `Event::SpendableOutputs` (#2609, #2624). |
| 40 | + * `[u8; 32]` has been replaced with a `ChannelId` newtype for chan ids (#2485). |
| 41 | + * `NetAddress` was renamed `SocketAddress` (#2549) and `FromStr` impl'd (#2134) |
| 42 | + * For `no-std` users, `parse_onion_address` was added which creates a |
| 43 | + `NetAddress` from a "...onion" string and port (#2134, #2633). |
| 44 | + * HTLC information is now provided in `Event::PaymentClaimed::htlcs` (#2478). |
| 45 | + * The success probability used in historical penalties when scoring is now |
| 46 | + available via `historical_estimated_payment_success_probability` (#2466). |
| 47 | + * `RecentPaymentDetails::*::payment_id` has been added (#2567). |
| 48 | + * `Route` now contains a `RouteParameters` rather than a `PaymentParameters`, |
| 49 | + tracking the original arguments passed to routefinding (#2555). |
| 50 | + * `Balance::*::claimable_amount_satoshis` was renamed `amount_satoshis` (#2460) |
| 51 | + * `*Features::set_*_feature_bit` have been added for non-custom flags (#2522). |
| 52 | + * `channel_id` was added to `SpendableOutputs` events (#2511). |
| 53 | + * `counterparty_node_id` and `channel_capacity_sats` were added to |
| 54 | + `ChannelClosed` events (#2387). |
| 55 | + * `ChannelMonitor` now implements `Clone` for `Clone`able signers (#2448). |
| 56 | + * `create_onion_message` was added to build an onion message (#2583, #2595). |
| 57 | + * `HTLCDescriptor` now implements `Writeable`/`Readable` (#2571). |
| 58 | + * `SpendableOutputDescriptor` now implements `Hash` (#2602). |
| 59 | + * `MonitorUpdateId` now implements `Debug` (#2594). |
| 60 | + * `Payment{Hash,Id,Preimage}` now implement `Display` (#2492). |
| 61 | + * `NodeSigner::sign_bolt12_invoice{,request}` were added for future use (#2432) |
| 62 | + |
| 63 | +## Backwards Compatibility |
| 64 | + * Users migrating to the new `KVStore` can use a concatentation of |
| 65 | + `[{primary_namespace}/[{secondary_namespace}/]]{key}` to build a key |
| 66 | + compatible with the previous `KVStorePersister` interface (#2472). |
| 67 | + * Downgrading after receipt of a payment with custom HTLC TLVs may result in |
| 68 | + unintentionally accepting payments with TLVs you do not understand (#2308). |
| 69 | + * `Route` objects (including pending payments) written by LDK versions prior |
| 70 | + to 0.0.117 won't be retryable after being deserialized by LDK 0.0.117 or |
| 71 | + above (#2555). |
| 72 | + * Users of the `MonitorUpdatingPersister` can upgrade seamlessly from the |
| 73 | + default `KVStore` `Persist` implementation, however the stored |
| 74 | + `ChannelMonitor`s are deliberately unreadable by the default `Persist`. This |
| 75 | + ensures the correct downgrade procedure is followed, which is: (#2359) |
| 76 | + * First, make a backup copy of all channel state, |
| 77 | + * then ensure all `ChannelMonitorUpdate`s stored are fully applied to the |
| 78 | + relevant `ChannelMonitor`, |
| 79 | + * finally, write each full `ChannelMonitor` using your new `Persist` impl. |
| 80 | + |
| 81 | +## Bug Fixes |
| 82 | + * Anchor channels which were closed by a counterparty broadcasting its |
| 83 | + commitment transaction (i.e. force-closing) would previously not generate a |
| 84 | + `SpendableOutputs` event for our `to_remote` (i.e. non-HTLC-encumbered) |
| 85 | + balance. Those with such balances available should fetch the missing |
| 86 | + `SpendableOutputDescriptor`s using the new |
| 87 | + `ChannelMonitor::get_spendable_outputs` method (#2605). |
| 88 | + * Anchor channels may result in spurious or missing `Balance` entries for HTLC |
| 89 | + balances (#2610). |
| 90 | + * `ChannelManager::send_spontaneous_payment_with_retry` spuriously did not |
| 91 | + provide the recipient with enough information to claim the payment, leading |
| 92 | + to all spontaneous payments failing (#2475). |
| 93 | + `send_spontaneous_payment_with_route` was unaffected. |
| 94 | + * The `keysend` feature on node announcements was spuriously un-set in 0.0.112 |
| 95 | + and has been re-enabled (#2465). |
| 96 | + * Fixed several races which could lead to deadlock when force-closing a channel |
| 97 | + (#2597). These races have not been seen in production. |
| 98 | + * The `ChannelManager` is persisted substantially less when it has not changed, |
| 99 | + leading to substantially less I/O traffic for it (#2521, #2617). |
| 100 | + * Passing new block data to `ChainMonitor` no longer results in all other |
| 101 | + monitor operations being blocked until it completes (#2528). |
| 102 | + * When retrying payments, any excess amount sent to the recipient in order to |
| 103 | + meet an `htlc_minimum` constraint on the path is now no longer included in |
| 104 | + the amount we send in the retry (#2575). |
| 105 | + * Several edge cases in route-finding around HTLC minimums were fixed which |
| 106 | + could have caused invalid routes or panics when built with debug assertions |
| 107 | + (#2570, #2575). |
| 108 | + * Several edge cases in route-finding around HTLC minimums and route hints |
| 109 | + were fixed which would spuriously result in no route found (#2575, #2604). |
| 110 | + * The `user_channel_id` passed to `SignerProvider::generate_channel_keys_id` |
| 111 | + for inbound channels is now correctly using the one passed to |
| 112 | + `ChannelManager::accept_inbound_channel` rather than a default value (#2428). |
| 113 | + * Users of `impl_writeable_tlv_based!` no longer have use requirements (#2506). |
| 114 | + * No longer force-close channels when counterparties send a `channel_update` |
| 115 | + with a bogus `htlc_minimum_msat`, which LND users can manually build (#2611). |
| 116 | + |
| 117 | +## Node Compatibility |
| 118 | + * LDK now ignores `error` messages generated by LND in response to a |
| 119 | + `shutdown` message, avoiding force-closes due to LND bug 6039. This may |
| 120 | + lead to non-trivial bandwidth usage with LND peers exhibiting this bug |
| 121 | + during the cooperative shutdown process (#2507). |
| 122 | + |
| 123 | +## Security |
| 124 | +0.0.117 fixes several loss-of-funds vulnerabilities in anchor output channels, |
| 125 | +support for which was added in 0.0.116, in reorg handling, and when accepting |
| 126 | +channel(s) from counterparties which are miners. |
| 127 | + * When a counterparty broadcasts their latest commitment transaction for a |
| 128 | + channel with anchor outputs, we'd previously fail to build claiming |
| 129 | + transactions against any HTLC outputs in that transaction. This could lead |
| 130 | + to loss of funds if the counterparty is able to eventually claim the HTLC |
| 131 | + after a timeout (#2606). |
| 132 | + * Anchor channels HTLC claims on-chain previously spent the entire value of any |
| 133 | + HTLCs as fee, which has now been fixed (#2587). |
| 134 | + * If a channel is closed via an on-chain commitment transaction confirmation |
| 135 | + with a pending outbound HTLC in the commitment transaction, followed by a |
| 136 | + reorg which replaces the confirmed commitment transaction with a different |
| 137 | + (but non-revoked) commitment transaction, all before we learn the payment |
| 138 | + preimage for this HTLC, we may previously have not generated a proper |
| 139 | + claiming transaction for the HTLC's value (#2623). |
| 140 | + * 0.0.117 now correctly handles channels for which our counterparty funded the |
| 141 | + channel with a coinbase transaction. As such transactions are not spendable |
| 142 | + until they've reached 100 confirmations, this could have resulted in |
| 143 | + accepting HTLC(s) which are not enforcible on-chain (#1924). |
| 144 | + |
| 145 | +up to date as of 620244dc2ec3153a61e009b80a8c59cf41514482 |
| 146 | +XXX: add diff statas |
| 147 | + |
1 | 148 | # 0.0.116 - Jul 21, 2023 - "Anchoring the Roadmap" |
2 | 149 |
|
3 | 150 | ## API Updates |
|
0 commit comments