Skip to content

0.0.103 CHANGELOG tweaks from Jeff #1154

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 20 additions & 14 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -29,23 +30,28 @@
* `Event::PaymentSent` now includes the full fee which was spent across all
payment paths which were fulfilled or pending when the payment was fulfilled
(#1142).
* `Event::PaymentSent` and `Event::PaymentPathFailed` now include the
`PaymentId` which matches the `PaymentId` returned from
`ChannelManager::send_payment` or `InvoicePayer::pay_invoice` (#1059).
* `NetGraphMsgHandler` now takes a `Deref` to the `NetworkGraph`, allowing for
shared references to the graph data to make serialization and references to
the graph data in the `InvoicePayer`'s `Router` simpler (#1149).
* `routing::Score::channel_penalty_msat` has been updated to provide the
`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
Expand Down