git.bitcoin.ninja Git - rust-lightning/blob - CHANGELOG.md

   1 # 0.0.100 - 2021-08-17
   2
   3 ## API Updates
   4  * The `lightning` crate can now be built in no_std mode, making it easy to
   5    target embedded hardware for rust users. Note that mutexes are replaced with
   6    no-ops for such builds (#1008, #1028).
   7  * LDK now supports sending and receiving "keysend" payments. This includes
   8    modifications to `lightning::util::events::Event::PaymentReceived` to
   9    indicate the type of payment (#967).
  10  * A new variant, `lightning::util::events::Event::PaymentForwarded` has been
  11    added which indicates a forwarded payment has been successfully claimed and
  12    we've received a forwarding fee (#1004).
  13  * `lightning::chain::keysinterface::KeysInterface::get_shutdown_pubkey` has
  14    been renamed to `get_shutdown_scriptpubkey`, returns a script, and is now
  15    called on channel open only if
  16    `lightning::util::config::ChannelConfig::commit_upfront_shutdown_pubkey` is
  17    set (#1019).
  18  * Closing-signed negotiation is now more configurable, with an explicit
  19    `lightning::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis`
  20    field allowing you to select the maximum amount you are willing to pay to
  21    avoid a force-closure. Further, we are now less restrictive on the fee
  22    placed on the closing transaction when we are not the party paying it. To
  23    control the feerate paid on a channel at close-time, use
  24    `ChannelManager::close_channel_with_target_feerate` instead of
  25    `close_channel` (#1011).
  26  * `lightning_background_processor::BackgroundProcessor` now stops the
  27    background thread when dropped (#1007). It is marked `#[must_use]` so that
  28    Rust users will receive a compile-time warning when it is immediately
  29    dropped after construction (#1029).
  30  * Total potential funds burn on force-close due to dust outputs is now limited
  31    to `lightning::util::config::ChannelConfig::max_dust_htlc_exposure_msat` per
  32    channel (#1009).
  33  * The interval on which
  34    `lightning::ln::peer_handler::PeerManager::timer_tick_occurred` should be
  35    called has been reduced to once every five seconds (#1035) and
  36    `lightning::ln::channelmanager::ChannelManager::timer_tick_occurred` should
  37    now be called on startup in addition to once per minute (#985).
  38  * The rust-bitcoin and bech32 dependencies have been updated to their
  39    respective latest versions (0.27 and 0.8, #1012).
  40
  41 ## Bug Fixes
  42  * Fix panic when reading invoices generated by some versions of c-lightning
  43    (#1002 and #1003).
  44  * Fix panic when attempting to validate a signed message of incorrect length
  45    (#1010).
  46  * Do not ignore the route hints in invoices when the invoice is over 250k
  47    sats (#986).
  48  * Fees are automatically updated on outbound channels to ensure commitment
  49    transactions are always broadcastable (#985).
  50  * Fixes a rare case where a `lightning::util::events::Event::SpendableOutputs`
  51    event is not generated after a counterparty commitment transaction is
  52    confirmed in a reorg when a conflicting local commitment transaction is
  53    removed in the same reorg (#1022).
  54  * Fixes a remotely-triggerable force-closure of an origin channel after an
  55    HTLC was forwarded over a next-hop channel and the next-hop channel was
  56    force-closed by our counterparty (#1025).
  57  * Fixes a rare force-closure case when sending a payment as a channel fundee
  58    when overdrawing our remaining balance. Instead the send will fail (#998).
  59  * Fixes a rare force-closure case when a payment was claimed prior to a
  60    peer disconnection or restart, and later failed (#977).
  61
  62 ## Serialization Compatibility
  63  * Pending inbound keysend payments which have neither been failed nor claimed
  64    when serialized will result in a `ChannelManager` which is not readable on
  65    pre-0.0.100 clients (#967).
  66  * Because
  67    `lightning::chain::keysinterface::KeysInterface::get_shutdown_scriptpubkey`
  68    has been updated to return a script instead of only a `PublicKey`,
  69    `ChannelManager`s constructed with custom `KeysInterface` implementations on
  70    0.0.100 and later versions will not be readable on previous versions.
  71    `ChannelManager`s created with 0.0.99 and prior versions will remain readable
  72    even after the a serialization roundtrip on 0.0.100, as long as no new
  73    channels are opened. Further, users using a
  74    `lightning::chain::keysinterface::KeysManager` as their `KeysInterface` will
  75    have `ChannelManager`s which are readable on prior versions as well (#1019).
  76  * `ChannelMonitorUpdate`s created by 0.0.100 and later for channels when
  77    `lightning::util::config::ChannelConfig::commit_upfront_shutdown_pubkey` is
  78    not set may not be readable by versions prior to 0.0.100 (#1019).
  79  * HTLCs which were in the process of being claimed on-chain when a pre-0.0.100
  80    `ChannelMonitor` was serialized may generate `PaymentForwarded` events with
  81    spurious `fee_earned_msat` values. This only applies to payments which were
  82    unresolved at the time of the upgrade (#1004).
  83  * 0.0.100 clients with pending `Event::PaymentForwarded` events at
  84    serialization-time will generate serialized `ChannelManager` objects which
  85    0.0.99 and earlier clients cannot read. The likelihood of this can be reduced
  86    by ensuring you process all pending events immediately before serialization
  87    (as is done by the `lightning-background-processor` crate, #1004).
  88
  89
  90 In total, this release features 59 files changed, 5861 insertions, and 2082
  91 deletions in 95 commits from 6 authors.
  92
  93
  94 # 0.0.99 - 2021-07-09
  95
  96 ## API Updates
  97
  98  * `lightning_block_sync::poll::Validate` is now public, allowing you to
  99    implement the `lightning_block_sync::poll::Poll` trait without
 100    `lightning_block_sync::poll::ChainPoller` (#956).
 101  * `lightning::ln::peer_handler::PeerManager` no longer requires that no calls
 102    are made to referencing the same `SocketDescriptor` after
 103    `disconnect_socket` returns. This makes the API significantly less
 104    deadlock-prone and simplifies `SocketDescriptor` implementations
 105    significantly. The relevant changes have been made to `lightning_net_tokio`
 106    and `PeerManager` documentation has been substantially rewritten (#957).
 107  * `lightning::util::message_signing`'s `sign` and `verify` methods now take
 108    secret and public keys by reference instead of value (#974).
 109  * Substantially more information is now exposed about channels in
 110    `ChannelDetails`. See documentation for more info (#984 and #988).
 111  * The latest best block seen is now exposed in
 112    `ChannelManager::current_best_block` and
 113    `ChannelMonitor::current_best_block` (#984).
 114  * Feerates charged when forwarding payments over channels is now set in
 115    `ChannelConfig::fee_base_msat` when the channel is opened. For existing
 116    channels, the value is set to the value provided in
 117    `ChannelManagerReadArgs::default_config::channel_options` the first time the
 118    `ChannelManager` is loaded in 0.0.99 (#975).
 119  * We now reject HTLCs which are received to be forwarded over private channels
 120    unless `UserConfig::accept_forwards_to_priv_channels` is set. Note that
 121    `UserConfig` is never serialized and must be provided via
 122    `ChannelManagerReadArgs::default_config` at each start (#975).
 123
 124 ## Bug Fixes
 125
 126  * We now forward gossip messages to peers instead of only relaying
 127    locally-generated gossip or sending gossip messages during initial sync
 128    (#948).
 129  * Correctly send `channel_update` messages to direct peers on private channels
 130    (#949). Without this, a private node connected to an LDK node over a private
 131    channel cannot receive funds as it does not know which fees the LDK node
 132    will charge.
 133  * `lightning::ln::channelmanager::ChannelManager` no longer expects to be
 134    persisted spuriously after we receive a `channel_update` message about any
 135    channel in the routing gossip (#972).
 136  * Asynchronous `ChannelMonitor` updates (using the
 137    `ChannelMonitorUpdateErr::TemporaryFailure` return variant) no longer cause
 138    spurious HTLC forwarding failures (#954).
 139  * Transaction provided via `ChannelMonitor::transactions_confirmed`
 140    after `ChannelMonitor::best_block_updated` was called for a much later
 141    block now trigger all relevant actions as of the later block. Previously
 142    some transaction broadcasts or other responses required an additional
 143    block be provided via `ChannelMonitor::best_block_updated` (#970).
 144  * We no longer panic in rare cases when an invoice contained last-hop route
 145    hints which were unusable (#958).
 146
 147 ## Node Compatibility
 148
 149  * We now accept spurious `funding_locked` messages sent prior to
 150    `channel_reestablish` messages after reconnect. This is a
 151    [known, long-standing bug in lnd](https://github.com/lightningnetwork/lnd/issues/4006)
 152    (#966).
 153  * We now set the `first_blocknum` and `number_of_blocks` fields in
 154    `reply_channel_range` messages to values which c-lightning versions prior to
 155    0.10 accepted. This avoids spurious force-closes from such nodes (#961).
 156
 157 ## Serialization Compatibility
 158
 159  * Due to a bug discovered in 0.0.98, if a `ChannelManager` is serialized on
 160    version 0.0.98 while an `Event::PaymentSent` is pending processing, the
 161    `ChannelManager` will fail to deserialize both on version 0.0.98 and later
 162    versions. If you have such a `ChannelManager` available, a simple patch will
 163    allow it to deserialize. Please file an issue if you need assistance (#973).
 164
 165 # 0.0.98 - 2021-06-11
 166
 167 0.0.98 should be considered a release candidate to the first alpha release of
 168 Rust-Lightning and the broader LDK. It represents several years of work
 169 designing and fine-tuning a flexible API for integrating lightning into any
 170 application. LDK should make it easy to build a lightning node or client which
 171 meets specific requirements that other lightning node software cannot. As
 172 lightning continues to evolve, and new use-cases for lightning develop, the API
 173 of LDK will continue to change and expand. However, starting with version 0.1,
 174 objects serialized with prior versions will be readable with the latest LDK.
 175 While Rust-Lightning is approaching the 0.1 milestone, language bindings
 176 components of LDK available at https://github.com/lightningdevkit are still of
 177 varying quality. Some are also approaching an 0.1 release, while others are
 178 still much more experimental. Please note that, at 0.0.98, using Rust-Lightning
 179 on mainnet is *strongly* discouraged.