mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-01-18 13:24:36 +01:00
Code Issues Packages Projects Releases Wiki Activity

0.0.103 CHANGELOG tweaks from Jeff

Browse Source
This commit is contained in:
Matt Corallo 2021-11-03 16:05:02 +00:00
parent e3bdfa0585
commit 31cd00ebf5
1 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
CHANGELOG.md
View File

@ -3,18 +3,19 @@
## API Updates
* This release is almost entirely focused on a new API in the
`lightning-invoice` crate - the `InvoicePayer`. `InvoicePayer` is a
struct which takes a reference to a `ChannelManager` and a `NetworkGraph`
struct which takes a reference to a `ChannelManager` and a `Router`
and retries payments as paths fail. It limits retries to a configurable
number, but is not serialized to disk and may retry additional times across
a serialization/load. In order to learn about failed payments, it must
receive `Event`s directly from the `ChannelManager`, wrapping a
user-provided `EventHandler` which it provides all unhandled events to
(#1059).
* `get_route` has been renamed `find_route` (#1059) and now takes a `Payee`
struct in replacement of a number of its long list of arguments (#1134).
`Payee` is further stored in the `Route` object returned and provided in the
`RouteParameters` contained in `Event::PaymentPathFailed` (#1059).
* `ChannelMonitor`s must now be persisted after calls which provide new block
* `get_route` has been renamed `find_route` (#1059) and now takes a
`RouteParameters` struct in replacement of a number of its long list of
arguments (#1134). The `Payee` in the `RouteParameters` is stored in the
`Route` object returned and provided in the `RouteParameters` contained in
`Event::PaymentPathFailed` (#1059).
* `ChannelMonitor`s must now be persisted after calls that provide new block
data, prior to `MonitorEvent`s being passed back to `ChannelManager` for
processing. If you are using a `ChainMonitor` this is handled for you.
The `Persist` API has been updated to `Option`ally take the
@ -36,16 +37,18 @@
`NodeId` of both the source and destination nodes of a channel (#1133).
## Bug Fixes
* Delay disconnecting peers if we receive messages from them even if it takes
a while to receive a pong from them. Further, avoid sending too many gossip
messages between pings to ensure we should always receive pongs in a timely
manner. Together, these should significantly reduce instances of us failing
to remain connected to a peer during initial gossip sync (#1137).
* If a payment is sent, creating an outbound HTLC and sending it to our
* Previous versions would often disconnect peers during initial graph sync due
to ping timeouts while processing large numbers of gossip messages. We now
delay disconnecting peers if we receive messages from them even if it takes
a while to receive a pong from them. Further, we avoid sending too many
gossip messages between pings to ensure we should always receive pongs in a
timely manner (#1137).
* If a payment was sent, creating an outbound HTLC and sending it to our
counterparty (implying the `ChannelMonitor` was persisted on disk), but the
`ChannelManager` was not persisted prior to shutdown/crash, no
`Event::PaymentPathFailed` event will be generated if the HTLC is eventually
failed on chain (#1104).
`Event::PaymentPathFailed` event was generated if the HTLC was eventually
failed on chain. Events are now consistent irrespective of `ChannelManager`
persistence or non-persistence (#1104).
## Serialization Compatibility
* All above new Events/fields are ignored by prior clients. All above new