Merge pull request #1921 from arik-so/2022-12-prohibit-old-rgs-updates

Throw error for RGS data that's more than two weeks old

Throw error for RGS data that's more than two weeks old, fixing #1785

Merge pull request #2008 from valentinewallace/2023-02-remove-manual-retries

Abandon payments on behalf of the user and remove manual retries

Reword and fix grammar in PartialFailure docs

Remove retry_payments method

We're no longer supporting manual retries since
ChannelManager::send_payment_with_retry can be parameterized by a retry
strategy

This commit also updates all docs related to retry_payment and abandon_payment.
Since these docs frequently overlap with changes in preceding commits where we
start abandoning payments on behalf of the user, all the docs are updated in
one go.

When processing pending htlcs, abandon outbounds that are not retryable

Abandon payment on behalf of the user on payment path failure

Removed retry_single_path_payment, it's replaced by automatic_retries with
AutoRetry::Success

Abandon payment if retry fails in process_pending_htlcs

Merge pull request #1832 from jkczyz/2022-11-composite-handler

Macro for composing custom message handlers

Pass pending events to outbound_payments::abandon_payment

This makes it uniform with the outbound payment methods that generate events
and set us up for abandoning payments on behalf of the user.

Fix indentation in outbound payment mark_abandoned

Merge pull request #2020 from valentinewallace/2023-02-test-inflight-scoring

Fix and test in-flight HTLC scoring in between retries

Add CI testing for lightning-custom-message crate

Re-write CustomMessageHandler documentation

Documentation for CustomMessageHandler wasn't clear how it is related to
PeerManager and contained some grammatical and factual errors. Re-write
the docs and link to the lightning_custom_message crate.

Fix compilation errors in some doc tests

These are seen in newer versions of rustc.

Macro for composing custom message handlers

BOLT 1 specifies a custom message type range for use with experimental
or application-specific messages. While a `CustomMessageHandler` can be
defined to support more than one message type, defining such a handler
requires a significant amount of boilerplate and can be error prone.

Add a crate exporting a `composite_custom_message_handler` macro for
easily composing pre-defined custom message handlers. The resulting
handler can be further composed with other custom message handlers using
the same macro.

This requires a separate crate since the macro needs to support "or"
patterns in macro_rules, which is only available in edition 2021.

https://doc.rust-lang.org/edition-guide/rust-2021/or-patterns-macro-rules.html

Otherwise, a crate defining a handler for a set of custom messages could
not easily be reused with another custom message handler. Doing so would
require explicitly duplicating the reused handlers type ids, but those
may change when the crate is updated.

Merge pull request #2029 from wpaulino/update-pgp-key

Update Wilmer Paulino's PGP key

Remove unnecessary scoring methods from Router trait

Fix computing in-flight HTLCs in between retries + test

test_utils: parameterize TestRouter by TestScorer

This allows us set scoring expectations and ensure in-flight htlcs are factored
into scoring

Merge pull request #1966 from ViktorTigerstrom/2023-01-store-channels-per-peer-followups

1507 followups

Don't serialize nodes which we have no channels to

Initialize `list_channels_with_filter` result vec with capacity

Update unknown peer passed to msg and api functions handling

Always remove disconnected peers with no channels

When a peer disconnects but still has channels, the peer's `peer_state`
entry in the `per_peer_state` is not removed by the `peer_disconnected`
function. If the channels with that peer is later closed while still
being disconnected (i.e. force closed), we therefore need to remove the
peer from `peer_state` separately.

To remove the peers separately, we push such peers to a separate HashSet
that holds peers awaiting removal, and remove the peers on a timer to
limit the negative effects on parallelism as much as possible.

Update `ChannelManager` docs

Updates multiple instances of the `ChannelManager` docs related to the
previous change that moved the storage of the channels to the
`per_peer_state`. This docs update corrects some grammar errors and
incorrect information, as well as clarifies documentation that was
confusing.

Check `peer_state` existence more idiomatically

Remove redundant Vec in `get_and_clear_pending_msg_events`

Don't clone the Vec in `remove_first_msg_event_to_node`

Remove redundant hashmap lookups

Avoid doing the same hashmap lookups twice in a row, when it's not
needed. Refactor `claim_funds_from_hop` in order to enable this change.

Update Wilmer Paulino's PGP key

The old key (729E9D9D92C75A5FBFEEE057B5DD717BEF7CA5B1) has been revoked
as of 2023-02-11.

All commits going forward will be signed with the new key.

Merge pull request #1980 from TheBlueMatt/2023-01-async-utxo-lookups

Merge pull request #2019 from tnull/2023-02-expose-peer-addrs

Expose peer addresses in `PeerManager`

Merge pull request #2027 from danielgranhao/fix-create-inbound-payment-docs

Fix out-of-date `create_inbound_payment()` docs

Test `get_peer_nodeids` returns peer addresses

Expose peer addresses via `get_peer_node_ids`

Fix out-of-date `create_inbound_payment()` docs

Merge pull request #1870 from tnull/2022-11-add-transaction-sync-crate

Add transaction sync crate

Build and test transaction sync crate in CI

Test syncing against Esplora backend

Add transaction sync crate

This crate provides utilities for syncing LDK via the transaction-based
`Confirm` interface. The initial implementation facilitates
synchronization with an Esplora backend server.

Move the channel_announcement process log into `NetworkGraph`

This ensures its always written after we update the graph, no
matter how we updated the graph.

Add tests for the new async gossip checking internal APIs

Support async results in `TestChainSource`, count `get_utxo` calls

Suggest a socket read buffer of 4KiB to limit message count

...and switch the same in `lightning-net-tokio`

Don't apply gossip backpressure to non-channel-announcing peers

When we apply the new gossip-async-check backpressure on peer
connections, if a peer has never sent us a `channel_announcement`
at all, we really shouldn't delay reading their messages.

This does so by tracking, on a per-peer basis, whether they've sent
us a channel_announcement, and resetting that state whenever we're
not backlogged.

Apply backpressure when we have too many gossip checks in-flight

Now that the `RoutingMessageHandler` can signal that it needs to
apply message backpressure, we implement it here in the
`PeerManager`. There's not much complicated here, aside from noting
that we need to add the ability to call `send_data` with no data
to indicate that reading should resume (and track when we may need
to make such calls when updating the routing-backpressure state).

Allow `RoutingMessageHandler` to signal backpressure

Now that we allow `handle_channel_announcement` to (indirectly)
spawn async tasks which will complete later, we have to ensure it
can apply backpressure all the way up to the TCP socket to ensure
we don't end up with too many buffers allocated for UTXO
validation.

We do this by adding a new method to `RoutingMessageHandler` which
allows it to signal if there are "many" checks pending and
`channel_announcement` messages should be delayed. The actual
`PeerManager` implementation thereof is done in the next commit.

Forward gossip messages which were verified asynchronously

Gossip messages which were verified against the chain
asynchronously should still be forwarded to peers, but must now go
out via a new `P2PGossipSync` parameter in the
`AccessResolver::resolve` method, allowing us to wire them up to
the `P2PGossipSync`'s `MessageSendEventsProvider` implementation.

Add the ability to broadcast gossip msgs via the event pipeline

When we process gossip messages asynchronously we may find that we
want to forward a gossip message to a peer after we've returned
from the existing `handle_*` method. In order to do so, we need to
be able to send arbitrary loose gossip messages back to the
`PeerManager` via `MessageSendEvent`.

This commit modifies `MessageSendEvent` in order to support this.

Process `channel_update`/`node_announcement` async if needed

If we have a `channel_announcement` which is waiting on a UTXO
lookup before we can process it, and we receive a `channel_update`
or `node_announcement` for the same channel or a node which is a
part of the channel, we have to wait until the lookup completes
until we can decide if we want to accept the new message.

Here, we store the new message in the pending lookup state and
process it asynchronously like the original `channel_announcement`.

Track in-flight `channel_announcement` lookups and avoid duplicates

If we receive two `channel_announcement`s for the same channel at
the same time, we shouldn't spawn a second UTXO lookup for an
identical message. This likely isn't too rare - if we start syncing
the graph from two peers at the same time, it isn't unlikely that
we'll end up with the same messages around the same time.

In order to avoid this we keep a hash map of all the pending
`channel_announcement` messages by SCID and simply ignore duplicate
message lookups.

Add an async resolution option to `ChainAccess::get_utxo`

For those operating in an async environment, requiring
`ChainAccess::get_utxo` return information about the requested UTXO
synchronously is incredibly painful. Requesting information about a
random UTXO is likely to go over the network, and likely to be a
rather slow request.

Thus, here, we change the return type of `get_utxo` to have both a
synchronous and asynchronous form. The asynchronous form requires
the user construct a `AccessFuture` which they `clone` and pass
back to us. Internally, an `AccessFuture` has an `Arc` to the
`channel_announcement` message which we need to process. When the
user completes their lookup, they call `resolve` on their
`AccessFuture` which we pull the `channel_announcement` from and
then apply to the network graph.

Clean up `check_channel_announcement` style

`check_channel_announcement` had long lines, a (very-)stale TODO
and confusing variable assignment, which is all cleaned up here.

Move logic to check a `ChannelAnnouncement` to `gossip_checking`

This commit is deliberately move-only, though the code being moved
is somewhat crufty.

Update the `gossip` and `router` module docs which were out of date

Move `chain::Access` to `routing` and rename it `UtxoLookup`

The `chain::Access` trait (and the `chain::AccessError` enum) is a
bit strange - it only really makes sense if users import it via the
`chain` module, otherwise they're left with a trait just called
`Access`. Worse, for bindings users its always just called
`Access`, in part because many downstream languages don't have a
mechanism to import a module and then refer to it.

Further, its stuck dangling in the `chain` top-level mod.rs file,
sitting in a module that doesn't use it at all (it's only used in
`routing::gossip`).

Instead, we give it its full name - `UtxoLookup` (and rename the
error enum `UtxoLookupError`) and put it in the a new
`routing::utxo` module, next to `routing::gossip`.

Merge pull request #2022 from alecchendev/2023-02-cache-peer-nodeid

Store a cached `NodeId` for each `Peer`

Cache `NodeId` by converting `their_node_id` to tuple

This is done to avoid redundantly serializing peer node
ids when forwarding gossip messages in
`PeerManager::forward_broadcast_msg`.

Merge pull request #2016 from alecchendev/2023-02-gossip-msg-pubkey-to-nodeid

Swap gossip message `PublicKey` for `NodeId`

Merge pull request #2007 from valentinewallace/2023-02-remove-invpayer-add-utils

Swap `PublicKey` for `NodeId` in `UnsignedNodeAnnouncement`

Also swaps `PublicKey` for `NodeId` in `get_next_node_announcement`
and `InitSyncTracker` to avoid unnecessary deserialization that came
from changing `UnsignedNodeAnnouncement`.

Swap `PublicKey` for `NodeId` in `UnsignedChannelAnnouncement`

Adds the macro `get_pubkey_from_node_id`
to parse `PublicKey`s back from `NodeId`s for signature
verification, as well as `make_funding_redeemscript_from_slices`
to avoid parsing back and forth between types.

Expand ChannelManager::send_spontaneous_payment_with_retry docs

Remove InvoicePayer and replace with util methods

Don't pass `per_peer_state` to `claim_funds_from_hop`

Track if a peer is connected or not in `ChannelManager`

Merge pull request #1873 from jurvis/jurvis/2022-11-expose-pending-payments

Expose pending payments through `ChannelManager`

Merge pull request #2002 from valentinewallace/2023-01-keysend-retries

Support auto-retrying keysend payments in `ChannelManager`

Merge pull request #1996 from valentinewallace/2023-01-migrate-payment-scoring

Score payment paths from events in `BackgroundProcessor`

Expose pending payments through ChannelManager

Adds a new method, `list_recent_payments ` to `ChannelManager` that
returns an array of `RecentPaymentDetails` containing the payment
status (Fulfilled/Retryable/Abandoned) and its total amount across all
paths.

Score payment paths in BackgroundProcessor

Use TestScorer in BackgroundProcessor testing

Spontaneous payments: make preimage construction more concise

Support spontaneous payment retries in ChannelManager

Store keysend preimage in outbound payments

This sets us up for spontaneous payment retries in ChannelManager.

Currently, retrying spontaneous payments is broken in InvoicePayer because it
does not include the keysend preimage on retry.

Merge pull request #1994 from TheBlueMatt/2023-01-1916-followups

1916 Followups Part 1

Reduce the code in the commitment_signed_dance macro

This should marginally reduce compile times for the tests by
reducing the total volume of code across the tests in the lightning
crate.

Use only the failed amount when retrying payments, not the full amt

When we landed the initial in-`ChannelManager` payment retries, we
stored the `RouteParameters` in the payment info, and then re-use
it as-is for new payments. `RouteParameters` is intended to store
the information specific to the *route*, `PaymentParameters` exists
to store information specific to a payment.

Worse, because we don't recalculate the amount stored in the
`RouteParameters` before fetching a new route with it, we end up
attempting to retry the full payment amount, rather than only the
failed part.

This issue brought to you by having redundant data in
datastructures, part 5,001.

Move retry-limiting to `retry_payment_with_route`

The documentation for `Retry` is very clear that it counts the
number of failed paths, not discrete retries. When we added
retries internally in `ChannelManager`, we switched to counting
the number if discrete retries, even if multiple paths failed and
were replace with multiple MPP HTLCs.

Because we are now rewriting retries, we take this opportunity to
reduce the places where retries are analyzed, specifically a good
chunk of code is removed from `pay_internal`.

Because we now retry multiple failed paths with one single retry,
we keep the new behavior, updating the docs on `Retry` to describe
the new behavior.

Log more information when retrying a payment attempt fails

Test the `RouteParameters` passed to `TestRouter`

`TestRouter` allows us to simply select the `Route` that will be
returned in the next `find_route` call, but it does so without any
checking of what was *requested* for the call. This makes it a
somewhat dubious test utility as it very helpfully ensures we
ignore errors in the routes we're looking for.

Instead, we require users of `TestRouter` pass a `RouteParameters`
to `expect_find_route`, which we compare against the requested
parameters passed to `find_route`.

Use the `PaymentParameter` final CLTV delta over `RouteParameters`

`PaymentParams` is all about the parameters for a payment, i.e. the
parameters which are static across all the paths of a paymet.
`RouteParameters` is about the information specific to a given
`Route` (i.e. a set of paths, among multiple potential sets of
paths for a payment). The CLTV delta thus doesn't belong in
`RouterParameters` but instead in `PaymentParameters`.

Worse, because `RouteParameters` is built from the information in
the last hops of a `Route`, when we deliberately inflate the CLTV
delta in path-finding, retries of the payment will have the final
CLTV delta double-inflated as it inflates starting from the final
CLTV delta used in the last attempt.

When we calculate the `final_cltv_expiry_delta` to put in the
`RouteParameters` returned via events after a payment failure, we
should re-use the new one in the `PaymentParameters`, rather than
the one that was in the route itself.

Merge pull request #1976 from tnull/2023-01-expose-impl-writeable-msg

Expose `impl_writeable_msg`

Move the final CLTV delta to `PaymentParameters` from `RouteParams`

`PaymentParams` is all about the parameters for a payment, i.e. the
parameters which are static across all the paths of a paymet.
`RouteParameters` is about the information specific to a given
`Route` (i.e. a set of paths, among multiple potential sets of
paths for a payment). The CLTV delta thus doesn't belong in
`RouterParameters` but instead in `PaymentParameters`.

Worse, because `RouteParameters` is built from the information in
the last hops of a `Route`, when we deliberately inflate the CLTV
delta in path-finding, retries of the payment will have the final
CLTV delta double-inflated as it inflates starting from the final
CLTV delta used in the last attempt.

By moving the CLTV delta to `PaymentParameters` we avoid this
issue, leaving only the sought amount in the `RouteParameters`.

Merge pull request #1998 from tnull/2023-01-no-none-in-channel-relevant-txids

Only return previously confirmed Txids from CM's `get_relevant_txids()`

Add version note in `Confirm` docs

While now `ChannelManager` will only return previously confirmed
transactions, we can't ensure the same for `ChainMonitor`, as we need to
maintain backwards compatibility with version prior to 0.0.113, at which
we started tracking the block hash in `ChannelMonitor`s. We therefore
add a note to the docs stating that users need to track confirmations on
their own for channels created prior to 0.0.113.

Return only `Some(block_hash)` in CM rel. txids

As of now the `Confirm::get_relevant_txids()` docs state that it won't
return any transactions for which we hadn't previously seen a
confirmation. To align its functionality a bit more with the docs, at
least for `ChannelManager`, we only return values for which we had
registered a confirmation block hash before.

Expose Retry enum from channelmanager module

Merge pull request #1997 from Kurtsley/fix-clean-up-documentation

Clean up documentation in the create_phantom_invoice functions

Clean up documentation in the create_phantom_invoice functions

Merge pull request #1961 from TheBlueMatt/2023-01-expose-hist-buckets

Expose historical bucket data via new accessors

Merge pull request #1972 from jkczyz/2023-01-bolt12-spec-updates

BOLT 12 spec updates

Expose historical bucket data via new accessors

Users should be able to view the data we use to score channels, so
this exposes that data in new accessors.

Fixes #1854.

Calc decayed buckets to decide if we have valid historical points

When we're calculating if, once we apply the unupdated decays, the
historical data tracker has enough data to assign a score, we
previously calculated the decayed points while walking the buckets
as we don't use the decayed buckets anyway (to avoid losing
precision). That is fine, except that as written it decayed
individual buckets additional times.

Instead, here we actually calculate the full set of decayed buckets
and use those to decide if we have valid points. This adds some
additional stack space and may in fact be slower, but will be
useful in the next commit and shouldn't be a huge change.

Update docs regarding payment path privacy

Disallow offer_metadata in Refund

The offer_metadata was optional but is redundant with invreq_metadata
(i.e., payer_metadata) for refunds. It is now disallowed in the spec and
was already unsupported by RefundBuilder.

Allow quantity in Refund

The spec always allowed this but the reason was unclear. It's useful if
the refund is for an invoice paid for offer where a quantity was given
in the request. The description in the refund would be from the offer,
which may have given a unit for each item. So allowing a quantity makes
it clear how many items the refund is for.

Support explicit quantity_max = 1 in Offer

The spec was modified to allow setting offer_quantity_max explicitly to
one. This is to support a use case where more than one item is supported
but only one item is left in the inventory. Introduce a Quantity::One
variant to replace Quantity::Bounded(1) so the later can be used for the
explicit setting.

Merge pull request #1985 from Kurtsley/chore-no-std-phantom-invoice

Remove std::SystemTime from create_phantom_invoice, ref #1978