partial fix

fml

Merge pull request #2125 from benthecarman/invoice-expire-time

Add helper functions for invoice expiry

Add helper functions for invoice expiry

Merge pull request #2110 from munjesi/docs_fixes

Replacing (C-not exported) in the docs

Merge pull request #2123 from benthecarman/create-inv-desc

Add generic InvoiceDescription to invoice in InvoiceBuilder

Add generic InvoiceDescription to invoice in InvoiceBuilder

Merge pull request #2114 from Evanfeenstra/force_close_msg_display

use PrintableString to Display CounterpartyForceClosed peer_msg

Replacing (C-not exported) in the docs

SanitizedString struct to safely Display CounterpartyForceClosed peer_msg

Merge pull request #2102 from douglaz/node_info_addresses

Remove NodeAnnouncementInfo addresses

Merge pull request #2034 from wpaulino/anchor-revoked-aggregate-claim

Add test for aggregated revoked HTLC claim on anchors channel

Merge pull request #2100 from douglaz/docs_fixes

Docs improvements

Remove redundant `addresses` field from `NodeAnnouncementInfo`

...replacing it with an acessor `addresses()`.

Besides removing a redundant data structure already present on inner
`NodeAnnouncement`, this change makes it possible to discover new address types
upon deserialization thanks to `UnsignedNodeAnnouncement`'s implementation.

Docs improvements

Test anchors build in CI

Merge pull request #2118 from TheBlueMatt/2023-03-no-useless-strings

Remove unnecessary heap allocations in log-entry-matching tests

Remove unnecessary use in `channelmonitor` tests module

Remove unnecessary heap allocations in log-entry-matching tests

Add test for aggregated revoked HTLC claim on anchors channel

Maintain order of yielded claim events

Since the claim events are stored internally within a HashMap, they will
be yielded in a random order once dispatched. Claim events may be
invalidated if a conflicting claim has confirmed on-chain and we need to
generate a new claim event; the randomized order could result in the
new claim event being handled prior to the previous. To maintain the
order in which the claim events are generated, we track them in a Vec
instead and ensure only one instance of a PackageId only ever exists
within it.

This would have certain performance implications, but since we're
bounded by the total number of HTLCs in a commitment anyway, we're
comfortable with taking the cost.

Rename keys for OnchainTxHandler::claimable_outpoints map

Clarify OnchainEvent::Claim behavior

The previous documentation was slightly incorrect, a `Claim` can also be
from the counterparty if they happened to claim the same exact set of
outputs as a claiming transaction we generated.

Add missing docs for BumpHTLCResolution

Fix stale import behind anchors build tag

Derive Eq on structs behind anchors build flag

Implement PartialEq manually

Since we don't store `pending_claim_events` within `OnchainTxHandler` as
they'll be regenerated on restarts, we opt to implement `PartialEq`
manually such that the field is not longer considered.

Merge pull request #2116 from TheBlueMatt/2023-03-serde-sucks

Drop `serde` dependency from `lightning-block-sync`

Drop `serde` dependency from `lightning-block-sync`

`serde` doesn't bother with MSRVs, so its expected to break
frequently. Yesterday, the `derive` feature had its MSRV broken in
a patch version without care.

Luckily its trivial for us to remove the `serde` dependency in
`lightning-block-sync`, using only `serde_json` for the JSON
deserialization part. It even ends up net-negative on LoC.

Merge pull request #2024 from TheBlueMatt/2023-02-6conf-pub-hints

Include a route hint for public, not-yet-announced channels

Include a route hint for public, not-yet-announced channels

If we have a public channel which doesn't yet have six
confirmations the network can't possibly know about it as we cannot
have announced it yet. However, because we refuse to include
route-hints if we have any public channels, we will generate
invoices that no one can pay.

Thus, if we have any public, not-yet-announced channels, include
them as a route-hint.

Merge pull request #2107 from TheBlueMatt/2023-04-msrv-cleanup

Bump MSRV to 1.48 and replace most of CI with a bash script

Replace the bulk of CI with a (much simpler) bash script

Merge pull request #2094 from johncantrell97/expose-fee

expose `feerate_per_kw` in `ChannelDetails`

Fix onion_message functional_tests `no-std` build

Remove `build-features` CI flag now that its always true

Remove `build-no-std` CI flag now that its always true

Remove `build-net-tokio` flag in CI since its now always true

Bump MSRV to 1.48

1.48.0 was released at the end of 2020, nearly 2.5 years ago. It
has been the rustc available on Debian stable since bullseye,
released in 2021. supporting Debian oldstable for more than a year
seems more than sufficient time to give Debian folks to upgrade,
and bullseye is set to become `oldstable` later this year with the
release of `bookworm`, likely this summer.

This also allows us to clean up our MSRV substantially, having a
single MSRV across our crates rather than a number of separate
ones. Sadly, windows already requires 1.49.

expose `feerate_sat_per_1000_weight` in `ChannelDetails`

renames Channel::get_feerate to get_feerate_sat_per_1000_weight

Merge pull request #2045 from wpaulino/fix-broken-commitment-test-vectors

Update commitment test vectors

Merge pull request #2063 from valentinewallace/2023-03-remove-paymentpathfailed-retry

Remove `PaymentPathFailed::retry`

Merge pull request #2099 from tnull/2023-03-pin-ntapi-on-windows

Pin tokio to 1.26 on windows to fix CI

Merge pull request #2091 from tnull/2023-03-expose-impl-writeable-tlv-based-enum-common

Ensure payment_params present when checking is_retryable_now

Remove payment_params from send_payent_along_path

It's unused since it no longer inserts it into HTLCSource

Remove HTLCSource::OutboundRoute::payment_params

No longer used since it is no longer used to construct PaymentPathFailed events

Remove PaymentPathFailed::retry

We now support automatic retries in ChannelManager and no longer support manual
retries, so the field is useless.

Pin tokio to 1.26 on windows to fix CI

Merge pull request #2092 from TheBlueMatt/2023-03-find-route-id

Correct `outbound_payment` route-fetch calls to pass the hash + ID

Further simplify the `outbound_payments` failure macro

Correct `outbound_payment` route-fetch calls to pass the hash + ID

`Route::get_route_with_id` exists to provide users payment-specific
data when fetching a route, however we were failing to call it when
we have such info, opting for the simple `get_route` instead. This
defeats the purpose of the additional-metadata method, which we
swap to using here.

Expose `_impl_writeable_tlv_based_enum_common` macro

As it isn't currently, and it's used by the exposed
`impl_writeable_tlv_based_enum`.

Merge pull request #2079 from tnull/2023-03-add-list-channel-by-counterparty

Merge pull request #2078 from AdvaitPote/bigsize_tests

Added encoding and decoding tests for BigSize

Merge pull request #2085 from tnull/2023-03-introduce-async-https-feature

Support HTTPS Esplora endpoints in `lightning-transaction-sync` via new feature

encoding/decoding tests added for BigSize

removed unnecessary debugging line

using io::Cursor in place of the std one

encoding/decoding tests added for BigSize

made the code concise

encoding/decoding tests added for BigSize

Remove unnecessary logging imports

Support HTTPS Esplora endpoints via new feature

To support HTTPS endpoints, the async HTTP library `reqwest` needs one of
the `-tls` features enabled. While the users could specify this in their
own cargo dependencies, we here provide a new `esplora-async-https`
feature for conveinience.

Merge pull request #2084 from zpv/fix-changelog-all-paths-failed-typo

Fix `all_paths_failed` typo in changelog

Merge pull request #2081 from TheBlueMatt/2023-03-future-poll-panic

Fix `Event::PaymentPathFailed` typo in changelog

Fix `all_paths_failed` typo in changelog

Add `list_channels_by_counterparty` method

While we already provide a `list_channels` method, it could result in
quite a large `Vec<ChannelDetails>`. Here, we provide the means to query
our channels by `counterparty_node_id` and DRY up the code.

Avoid `poll`ing completed futures in the `background-processor`

`poll`ing completed futures invokes undefined behavior in Rust
(panics, etc, obviously not memory corruption as its not unsafe).
Sadly, in our futures-based version of
`lightning-background-processor` we have one case where we can
`poll` a completed future - if the timer for the network graph
prune + persist completes without a network graph to prune +
persist we'll happily poll the same future over and over again,
likely panicing in user code.

Merge pull request #2049 from douglaz/run-clippy-fix

Run clippy fix

Run clippy --fix and cleanup code

Update same amount and preimage test vector

The amount for HTLC #6 was updated in the spec's test vectors, but the
"same amount and preimage" test vector itself was not updated, even
though the new HTLC amount resulted in a different commitment
transaction, and thus, different signatures.

Add missing test vector for anchors_zero_fee_htlc_tx

Tests the case where only one anchor output exists for the funder in the
commitment transaction due to the remote having a dust balance (in this
case, 0).

Merge pull request #2074 from TheBlueMatt/2023-03-fix-threaded-test

Make `fuzz_threaded_connections` more robust

Merge pull request #2028 from TheBlueMatt/2023-02-macros-for-wilmer

Reduce macro usage in tests

Merge pull request #1497 from TheBlueMatt/2022-05-no-default-opt

Disable LTO builds in tests (and bump deps to -O2)

Make `fuzz_threaded_connections` more robust

In `fuzz_threaded_connections`, if one thread is being run while
another is starved, and the running thread manages to call
`timer_tick_ocurred` twice after the starved thread constructs the
inbound connection but before it delivers the first bytes, we'll
receive an immediate error and `unwrap` it, causing failure.

The fix is trivial, simply remove the unwrap and return if we're
already disconnected when we do the initial read.

While we're here, we also reduce the frequency of the
`timer_tick_ocurred` calls to give us a chance to occasionally
deliver some additional messages.

Fixes #2073

Merge pull request #2065 from TheBlueMatt/2023-02-0.0.114

Cut 0.0.114

Update crate versions to 0.0.114/invoice 0.22

Add release notes for 0.0.114

Merge pull request #2072 from jkczyz/2023-01-fix-scoring-div-by-zero

Fix division by zero in `ProbabilisticScorer`

Merge pull request #2071 from TheBlueMatt/2023-01-fix-fast-extra-ready-panic

Fix panic on receiving `channel_ready` after 1st commitment update

Use ProbabilisticScorer in router fuzzing, to cover overflows there

Guard against division by zero in scorer

Since a node may announce that the htlc_maximum_msat of a channel is
zero, adding one to the denominator in the bucket formulas will prevent
the panic from ever happening. While the routing algorithm may never
select such a channel to score, this precaution may still be useful in
case the algorithm changes or if the scorer is used with a different
routing algorithm.

Update scoring history buckets when no change

Even when there is no change in min/max liquidity knowledge, tracking
should still be updated to include the additional data point.

Merge pull request #2068 from jkczyz/2023-03-doc-fixes

Doc and build warning fixes

Merge pull request #2069 from TheBlueMatt/2023-03-no-tx-sync-auto-std

Do not auto-select the lightning `std` feature from tx-sync crate

Merge pull request #2070 from TheBlueMatt/2023-03-get-key

Expose the node secret key in `{Phantom,}KeysManager`

Fix build warnings

Add more documentation about BlockSourceError

Some BlockSource implementations provide more error details. Document
this in case users want to examine it further.

Expose the node secret key in `{Phantom,}KeysManager`

When we removed the private keys from the signing interface we
forgot to re-add them in the public interface of our own
implementations, which users may need.

Merge pull request #2067 from benthecarman/fix-typos

Fix typos in lightning-transaction-sync

Merge pull request #2066 from TheBlueMatt/2023-02-no-enum-refs

Pass `FailureCode` to `fail_htlc_backwards` by ownership

Merge pull request #2048 from TheBlueMatt/2023-02-send-persist-order-a

Track claimed outbound HTLCs in ChannelMonitors

Do not auto-select the lightning `std` feature from tx-sync crate

We have some downstream folks who are using LDK in wasm compiled
via the normal rust wasm path. To ensure nothing breaks they want
to use `no-std` on the lightning crate, disabling time calls as
those panic. However, the HTTP logic in
`lightning-transaction-sync` gets automatically stubbed out by the
HTTP client crates when targeting wasm via `wasm_bindgen`, so it
works fine despite the std restrictions.

In order to make both work, `lightning-transaction-sync` can remain
`std`, but needs to not automatically enable the `std` flag on the
`lightning` crate, ie by setting `default-features = false`. We do
so here.

Pass `FailureCode` to `fail_htlc_backwards` by ownership

`FaliureCode` is a trivial enum with no body, so we shouldn't be
passing it by reference. Its sufficiently strange that the Java
bindings aren't happy with it, which is fine, we should just fix it
here.

Remove unused compat block in `provide_latest_holder_commitment_tx`

Track claimed outbound HTLCs in ChannelMonitors

When we receive an update_fulfill_htlc message, we immediately try
to "claim" the HTLC against the HTLCSource. If there is one, this
works great, we immediately generate a `ChannelMonitorUpdate` for
the corresponding inbound HTLC and persist that before we ever get
to processing our counterparty's `commitment_signed` and persisting
the corresponding `ChannelMonitorUpdate`.

However, if there isn't one (and this is the first successful HTLC
for a payment we sent), we immediately generate a `PaymentSent`
event and queue it up for the user. Then, a millisecond later, we
receive the `commitment_signed` from our peer, removing the HTLC
from the latest local commitment transaction as a side-effect of
the `ChannelMonitorUpdate` applied.

If the user has processed the `PaymentSent` event by that point,
great, we're done. However, if they have not, and we crash prior to
persisting the `ChannelManager`, on startup we get confused about
the state of the payment. We'll force-close the channel for being
stale, and see an HTLC which was removed and is no longer present
in the latest commitment transaction (which we're broadcasting).
Because we claim corresponding inbound HTLCs before updating a
`ChannelMonitor`, we assume such HTLCs have failed - attempting to
fail after having claimed should be a noop. However, in the
sent-payment case we now generate a `PaymentFailed` event for the
user, allowing an HTLC to complete without giving the user a
preimage.

Here we address this issue by storing the payment preimages for
claimed outbound HTLCs in the `ChannelMonitor`, in addition to the
existing inbound HTLC preimages already stored there. This allows
us to fix the specific issue described by checking for a preimage
and switching the type of event generated in response. In addition,
it reduces the risk of future confusion by ensuring we don't fail
HTLCs which were claimed but not fully committed to before a crash.

It does not, however, full fix the issue here - because the
preimages are removed after the HTLC has been fully removed from
available commitment transactions if we are substantially delayed
in persisting the `ChannelManager` from the time we receive the
`update_fulfill_htlc` until after a full commitment signed dance
completes we may still hit this issue. The full fix for this issue
is to delay the persistence of the `ChannelMonitorUpdate` until
after the `PaymentSent` event has been processed. This avoids the
issue entirely, ensuring we process the event before updating the
`ChannelMonitor`, the same as we ensure the upstream HTLC has been
claimed before updating the `ChannelMonitor` for forwarded
payments.

The full solution will be implemented in a later work, however this
change still makes sense at that point as well - if we were to
delay the initial `commitment_signed` `ChannelMonitorUpdate` util
after the `PaymentSent` event has been processed (which likely
requires a database update on the users' end), we'd hold our
`commitment_signed` + `revoke_and_ack` response for two DB writes
(i.e. `fsync()` calls), making our commitment transaction
processing a full `fsync` slower. By making this change first, we
can instead delay the `ChannelMonitorUpdate` from the
counterparty's final `revoke_and_ack` message until the event has
been processed, giving us a full network roundtrip to do so and
avoiding delaying our response as long as an `fsync` is faster than
a network roundtrip.

Reference `Router` in `ChannelManager` docs

DRY up historical bucket_idx calculation

Fix scorer panic when available capacity is zero

ProbabilisticScorer takes a ChannelUsage when computing a penalty for a
channel. The formula for calculating the liquidity penalty reduces the
maximum capacity by the amount of in-flight HTLCs (available capacity)
and adds one to prevent division by zero.

However, since the available capacity is passed to
DirectedChannelLiquidity as the capacity, other penalty formulas may use
the available (i.e., reduced) capacity inadvertently. In practice, this
has two ramifications for the historical liquidity penalty computation:

1. The bucket formula doesn't have a consistent denominator for a given
   channel.
2. The bucket formula may divide by zero when the in-flight HTLC amount
   equals or exceeds the effective capacity.

Fixing this involves only using the available capacity when appropriate.

Fix typos in lightning-transaction-sync

Merge pull request #2060 from TheBlueMatt/2023-02-peers-disconnect-consistency

Remove peers from the node_id_to_descriptor even without init

Avoid removing stale preimages when hashes collide in fuzzing