Update CHANGELOG for 0.0.100
authorMatt Corallo <git@bluematt.me>
Sat, 14 Aug 2021 03:42:51 +0000 (03:42 +0000)
committerMatt Corallo <git@bluematt.me>
Tue, 17 Aug 2021 18:55:07 +0000 (18:55 +0000)
CHANGELOG.md

index dc2ea744cf522aea5dc393843ceb0beef25ced4f..a23f9d76a957b61fe5be5cb28f23f542b317286e 100644 (file)
@@ -1,15 +1,94 @@
-# 0.0.100 - WIP
+# 0.0.100 - 2021-08-17
+
+## API Updates
+ * The `lightning` crate can now be built in no_std mode, making it easy to
+   target embedded hardware for rust users. Note that mutexes are replaced with
+   no-ops for such builds (#1008, #1028).
+ * LDK now supports sending and receiving "keysend" payments. This includes
+   modifications to `lightning::util::events::Event::PaymentReceived` to
+   indicate the type of payment (#967).
+ * A new variant, `lightning::util::events::Event::PaymentForwarded` has been
+   added which indicates a forwarded payment has been successfully claimed and
+   we've received a forwarding fee (#1004).
+ * `lightning::chain::keysinterface::KeysInterface::get_shutdown_pubkey` has
+   been renamed to `get_shutdown_scriptpubkey`, returns a script, and is now
+   called on channel open only if
+   `lightning::util::config::ChannelConfig::commit_upfront_shutdown_pubkey` is
+   set (#1019).
+ * Closing-signed negotiation is now more configurable, with an explicit
+   `lightning::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis`
+   field allowing you to select the maximum amount you are willing to pay to
+   avoid a force-closure. Further, we are now less restrictive on the fee
+   placed on the closing transaction when we are not the party paying it. To
+   control the feerate paid on a channel at close-time, use
+   `ChannelManager::close_channel_with_target_feerate` instead of
+   `close_channel` (#1011).
+ * `lightning_background_processor::BackgroundProcessor` now stops the
+   background thread when dropped (#1007). It is marked `#[must_use]` so that
+   Rust users will receive a compile-time warning when it is immediately
+   dropped after construction (#1029).
+ * Total potential funds burn on force-close due to dust outputs is now limited
+   to `lightning::util::config::ChannelConfig::max_dust_htlc_exposure_msat` per
+   channel (#1009).
+ * The interval on which
+   `lightning::ln::peer_handler::PeerManager::timer_tick_occurred` should be
+   called has been reduced to once every five seconds (#1035) and
+   `lightning::ln::channelmanager::ChannelManager::timer_tick_occurred` should
+   now be called on startup in addition to once per minute (#985).
+ * The rust-bitcoin and bech32 dependencies have been updated to their
+   respective latest versions (0.27 and 0.8, #1012).
+
+## Bug Fixes
+ * Fix panic when reading invoices generated by some versions of c-lightning
+   (#1002 and #1003).
+ * Fix panic when attempting to validate a signed message of incorrect length
+   (#1010).
+ * Do not ignore the route hints in invoices when the invoice is over 250k
+   sats (#986).
+ * Fees are automatically updated on outbound channels to ensure commitment
+   transactions are always broadcastable (#985).
+ * Fixes a rare case where a `lightning::util::events::Event::SpendableOutputs`
+   event is not generated after a counterparty commitment transaction is
+   confirmed in a reorg when a conflicting local commitment transaction is
+   removed in the same reorg (#1022).
+ * Fixes a remotely-triggerable force-closure of an origin channel after an
+   HTLC was forwarded over a next-hop channel and the next-hop channel was
+   force-closed by our counterparty (#1025).
+ * Fixes a rare force-closure case when sending a payment as a channel fundee
+   when overdrawing our remaining balance. Instead the send will fail (#998).
+ * Fixes a rare force-closure case when a payment was claimed prior to a
+   peer disconnection or restart, and later failed (#977).
 
 ## Serialization Compatibility
+ * Pending inbound keysend payments which have neither been failed nor claimed
+   when serialized will result in a `ChannelManager` which is not readable on
+   pre-0.0.100 clients (#967).
+ * Because
+   `lightning::chain::keysinterface::KeysInterface::get_shutdown_scriptpubkey`
+   has been updated to return a script instead of only a `PublicKey`,
+   `ChannelManager`s constructed with custom `KeysInterface` implementations on
+   0.0.100 and later versions will not be readable on previous versions.
+   `ChannelManager`s created with 0.0.99 and prior versions will remain readable
+   even after the a serialization roundtrip on 0.0.100, as long as no new
+   channels are opened. Further, users using a
+   `lightning::chain::keysinterface::KeysManager` as their `KeysInterface` will
+   have `ChannelManager`s which are readable on prior versions as well (#1019).
+ * `ChannelMonitorUpdate`s created by 0.0.100 and later for channels when
+   `lightning::util::config::ChannelConfig::commit_upfront_shutdown_pubkey` is
+   not set may not be readable by versions prior to 0.0.100 (#1019).
  * HTLCs which were in the process of being claimed on-chain when a pre-0.0.100
    `ChannelMonitor` was serialized may generate `PaymentForwarded` events with
    spurious `fee_earned_msat` values. This only applies to payments which were
-   unresolved at the time of the upgrade.
- * 0.0.100 clients with pending PaymentForwarded events at serialization-time
-   will generate serialized `ChannelManager` objects which 0.0.99 and earlier
-   clients cannot read. The likelihood of this can be reduced by ensuring you
-   process all pending events immediately before serialization (as is done by
-   the `lightning-background-processor` crate).
+   unresolved at the time of the upgrade (#1004).
+ * 0.0.100 clients with pending `Event::PaymentForwarded` events at
+   serialization-time will generate serialized `ChannelManager` objects which
+   0.0.99 and earlier clients cannot read. The likelihood of this can be reduced
+   by ensuring you process all pending events immediately before serialization
+   (as is done by the `lightning-background-processor` crate, #1004).
+
+
+In total, this release features 59 files changed, 5861 insertions, and 2082
+deletions in 95 commits from 6 authors.
 
 
 # 0.0.99 - 2021-07-09