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
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
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).
42 * Fix panic when reading invoices generated by some versions of c-lightning
44 * Fix panic when attempting to validate a signed message of incorrect length
46 * Do not ignore the route hints in invoices when the invoice is over 250k
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).
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).
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).
90 In total, this release features 59 files changed, 5861 insertions, and 2082
91 deletions in 95 commits from 6 authors.
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).
126 * We now forward gossip messages to peers instead of only relaying
127 locally-generated gossip or sending gossip messages during initial sync
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
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).
147 ## Node Compatibility
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)
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).
157 ## Serialization Compatibility
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).
165 # 0.0.98 - 2021-06-11
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.
projects / rust-lightning / blob