-
Notifications
You must be signed in to change notification settings - Fork 405
One final fix + cut 0.0.103 #1153
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,69 @@ | ||
# 0.0.103 - 2021-11-02 | ||
|
||
## 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` | ||
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` | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 | ||
`ChannelMonitorUpdate` as persistence events that result from chain data no | ||
longer have a corresponding update (#1108). | ||
* `routing::Score` now has a `payment_path_failed` method which it can use to | ||
learn which channels often fail payments. It is automatically called by | ||
`InvoicePayer` for failed payment paths (#1144). | ||
* The default `Scorer` implementation is now a type alias to a type generic | ||
across different clocks and supports serialization to persist scoring data | ||
across restarts (#1146). | ||
* `Event::PaymentSent` now includes the full fee which was spent across all | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
payment paths which were fulfilled or pending when the payment was fulfilled | ||
(#1142). | ||
* `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). | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## 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 | ||
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). | ||
Comment on lines
+44
to
+48
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems to be worded in terms of what the bug was whereas the previous bullet is worded in terms of how the bug was fixed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yea, we've generally worded in terms of the bug, but I wasn't really sure how to word the previous in terms of the bug and still have it be clear. I'll try, though. |
||
|
||
## Serialization Compatibility | ||
* All above new Events/fields are ignored by prior clients. All above new | ||
Events/fields are not present when reading objects serialized by prior | ||
versions of the library. | ||
* Payments for which a `Route` was generated using a previous version or for | ||
which the payment was originally sent by a previous version of the library | ||
will not be retried by an `InvoicePayer`. | ||
|
||
This release was singularly focused and some contributions by third parties | ||
were delayed. | ||
In total, this release features 38 files changed, 4414 insertions, and 969 | ||
deletions in 71 commits from 2 authors, in alphabetical order: | ||
|
||
* Jeffrey Czyz | ||
* Matt Corallo | ||
|
||
|
||
# 0.0.102 - 2021-10-18 | ||
|
||
## API Updates | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
[package] | ||
name = "lightning-background-processor" | ||
version = "0.0.102" | ||
version = "0.0.103" | ||
authors = ["Valentine Wallace <[email protected]>"] | ||
license = "MIT OR Apache-2.0" | ||
repository = "http://github.com/rust-bitcoin/rust-lightning" | ||
|
@@ -11,9 +11,9 @@ edition = "2018" | |
|
||
[dependencies] | ||
bitcoin = "0.27" | ||
lightning = { version = "0.0.102", path = "../lightning", features = ["allow_wallclock_use"] } | ||
lightning-persister = { version = "0.0.102", path = "../lightning-persister" } | ||
lightning = { version = "0.0.103", path = "../lightning", features = ["allow_wallclock_use"] } | ||
lightning-persister = { version = "0.0.103", path = "../lightning-persister" } | ||
|
||
[dev-dependencies] | ||
lightning = { version = "0.0.102", path = "../lightning", features = ["_test_utils"] } | ||
lightning-invoice = { version = "0.10.0", path = "../lightning-invoice" } | ||
lightning = { version = "0.0.103", path = "../lightning", features = ["_test_utils"] } | ||
lightning-invoice = { version = "0.11.0", path = "../lightning-invoice" } |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
[package] | ||
name = "lightning-invoice" | ||
description = "Data structures to parse and serialize BOLT11 lightning invoices" | ||
version = "0.10.0" | ||
version = "0.11.0" | ||
authors = ["Sebastian Geisler <[email protected]>"] | ||
documentation = "https://docs.rs/lightning-invoice/" | ||
license = "MIT OR Apache-2.0" | ||
|
@@ -10,11 +10,11 @@ readme = "README.md" | |
|
||
[dependencies] | ||
bech32 = "0.8" | ||
lightning = { version = "0.0.102", path = "../lightning" } | ||
lightning = { version = "0.0.103", path = "../lightning" } | ||
secp256k1 = { version = "0.20", features = ["recovery"] } | ||
num-traits = "0.2.8" | ||
bitcoin_hashes = "0.10" | ||
|
||
[dev-dependencies] | ||
hex = "0.3" | ||
lightning = { version = "0.0.102", path = "../lightning", features = ["_test_utils"] } | ||
lightning = { version = "0.0.103", path = "../lightning", features = ["_test_utils"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should replace
NetworkGraph
withRouter
. I almost wonder if we should move theRouter
trait to thelightning
crate.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, IMO.