Merge pull request #2221 from TheBlueMatt/2023-04-bp-exit-fast

Check for `background-processor` exit condition before+after sleep

Merge pull request #2146 from valentinewallace/2023-03-blinded-pathfinding-groundwork

Blinded pathfinding groundwork

Check for `background-processor` exit condition before+after sleep

In a synchronous `BackgroundProcessor`, the exit is done by setting
an atomic flag, which is most likely to happen while we're asleep.
Thus, we previously checked for the exit condition after the sleep
(and after we persisted the `ChannelManager`, if required, though
this is no longer required and dates back to when we didn't do a
re-persist after breaking out of the main loop).

For an async `background-processor`, this is also fine, however
because of the relatively longer sleep time, if the exit flag is
set via a sleep check returning true during event processing, we
may end up delaying exit rather substantially.

In order to avoid this, we simply check for the exit condition both
before and immediately after the sleep in `background-processor`.

Merge pull request #2212 from wpaulino/off-by-one-locktime

Fix off-by-one finalized transaction locktime

Fix off-by-one finalized transaction locktime

While these transactions were still valid, we incorrectly assumed that
they would propagate with a locktime of `current_height + 1`, when in
reality, only those with a locktime strictly lower than the next height
in the chain are allowed to enter the mempool.

Catch up test nodes to latest block height

In a future commit, we plan to correctly enforce that the spending
transaction has a valid locktime relative to the chain for the node
broascasting it in `TestBroadcaster::broadcast_transaction` to. We catch
up these test node instances to their expected height, such that we do
not fail said enforcement.

Use current height when generating claims on block_disconnected

The `height` argument passed to `OnchainTxHandler::block_disconnected`
represents the height being disconnected, and not the current height.
Due to the incorrect assumption, we'd generate a claim with a locktime
in the future.

Ultimately, we shouldn't be generating claims within
`block_disconnected`. Rather, we should retry the claim at a later block
height, since the bitcoin blockchain does not ever roll back without
connecting a new block. Addressing this is left for future work.

Merge pull request #2199 from tnull/2023-04-fix-async-event-processing

Allow async events processing without holding `total_consistency_lock`

Merge pull request #2208 from wpaulino/monitor-rebroadcast-pending-claims

Implement pending claim rebroadcast on force-closed channels

Call ChainMonitor::rebroadcast_pending_claims on REBROADCAST_TIMER tick

This will prompt monitors to rebroadcast/fee-bump their pending claims
on a force-closed channel once on startup and every 30 seconds after.

Implement pending claim rebroadcast on force-closed channels

This attempts to rebroadcast/fee-bump each pending claim a monitor is
tracking for a force-closed channel. This is crucial in preventing
certain classes of pinning attacks and ensures reliability if
broadcasting fails. For implementations of `FeeEstimator` that also
support mempool fee estimation, we may broadcast a fee-bumped claim
instead, ensuring we can also react to mempool fee spikes between
blocks.

Extend OnchainTxHandler::generate_claim to optionally force feerate bump

In the next commit, we plan to extend the `OnchainTxHandler` to retry
pending claims on a timer. This timer may fire with much more frequency
than incoming blocks, so we want to avoid manually bumping feerates
(currently by 25%) each time our fee estimator provides a lower feerate
than before.

Fix outbound_payment for new Path::blinded_tail

Update changelog for backwards compat

Account for Path::blinded_tail when adding a shadow cltv offset

Test scoring paths with blinded tails

Account for Path::blinded_tail in InflightHtlcs::process_path

Support (de)serializing Path::blinded_tails in HTLCSource

Support (de)serializing Path::blinded_tails in Routes

Support (de)ser for Path::blinded_tails in events

Add blinded path {metadata} fields to Path, but disallow paying blinded paths for now

Merge pull request #2210 from alandotcom/patch-1

Fix README typo

Fix README typo

Allow events processing without holding `total_consistency_lock`

Unfortunately, the RAII types used by `RwLock` are not `Send`, which is
why they can't be held over `await` boundaries. In order to allow
asynchronous events processing in multi-threaded environments, we here
allow to process events without holding the `total_consistency_lock`.

Replace Vec<RouteHop> with new Path struct

This lays groundwork for adding blinded path info to Path

Add utilities for getting a path's final value and cltv delta

Minor Route/RouteHop doc updates

Fix BP prune timer and don't panic on persistence notification failure

Merge pull request #2205 from wpaulino/sign-ecdsa-with-noncedata

Generate local signatures with additional randomness

Use new feature to gate test vectors behind

To match the local signatures found in test vectors, we must make sure
we don't use any additional randomess when generating signatures, as
we'll arrive at a different signature otherwise.

Sign gossip messages without grinding low R signatures

Gossip messages always use signatures in their compact form, so grinding
for low R signatures is unnecessary.

Generate local signatures with additional randomness

Previously, our local signatures would always be deterministic, whether
we'd grind for low R value signatures or not. For peers supporting
SegWit, Bitcoin Core will generally use a transaction's witness-txid, as
opposed to its txid, to advertise transactions. Therefore, to ensure a
transaction has the best chance to propagate across node mempools in the
network, each of its broadcast attempts should have a unique/distinct
witness-txid, which we can achieve by introducing random nonce data when
generating local signatures, such that they are no longer deterministic.

Implement EntropySource for InMemorySigner

This allows the `InMemorySigner` to produce its own randomness, which we
plan to use when generating signatures in future work.

We can no longer derive `Clone` due to the `AtomicCounter`, so we opt to
implement it manually.

Merge pull request #2206 from jkczyz/2023-04-invoice-description

Expose description from Invoice's offer/refund

outbound_payment: remove unused cltv delta var

Extract read/write variants from impl_for_vec

We'll need to (de)serialize vecs of BlindedPaths differently based on whether
we're writing or reading

Update PaymentParameters::route_hints for blinded paths

Update docs and method names for blinded payment paths

Move blinded_path and its utils into a new module

Expose description from Invoice's offer/refund

This will allow clients like VLS to check the description for an invoice
as part of verification.

Merge pull request #1989 from jkczyz/2023-01-stateless-offers

Stateless BOLT 12 message verification

DRY up InvoiceFields construction

Support responding to refunds with transient keys

Extract keys from Offer::metadata to sign Invoice

For offers where the signing pubkey is derived, the keys need to be
extracted from the Offer::metadata in order to sign an invoice.
Parameterize InvoiceBuilder such that a build_and_sign method is
available for this situation.

DRY up verification of invreq TLV records

Stateless verification of Invoice for Refund

Stateless verification of Invoice for Offer

Verify that an Invoice was produced from a Refund constructed by the
payer using the payer metadata reflected in the Invoice. The payer
metadata consists of a 128-bit encrypted nonce and possibly a 256-bit
HMAC over the nonce and Refund TLV records (excluding the payer id)
using an ExpandedKey.

Thus, the HMAC can be reproduced from the refund bytes using the nonce
and the original ExpandedKey, and then checked against the metadata. If
metadata does not contain an HMAC, then the reproduced HMAC was used to
form the signing keys, and thus can be checked against the payer id.

Refund metadata and payer id derivation

Add support for deriving a transient payer id for each Refund from an
ExpandedKey and a nonce. This facilitates payer privacy by not tying any
Refund to any other nor to the payer's node id.

Additionally, support stateless Invoice verification by setting payer
metadata using an HMAC over the nonce and the remaining TLV records,
which will be later verified when receiving an Invoice response.

Stateless verification of Invoice for Offer

Verify that an Invoice was produced from an InvoiceRequest constructed
by the payer using the payer metadata reflected in the Invoice. The
payer metadata consists of a 128-bit encrypted nonce and possibly a
256-bit HMAC over the nonce and InvoiceRequest TLV records (excluding
the payer id) using an ExpandedKey.

Thus, the HMAC can be reproduced from the invoice request bytes using
the nonce and the original ExpandedKey, and then checked against the
metadata. If metadata does not contain an HMAC, then the reproduced HMAC
was used to form the signing keys, and thus can be checked against the
payer id.

Fix builder docs in offers module

InvoiceRequest metadata and payer id derivation

Add support for deriving a transient payer id for each InvoiceRequest
from an ExpandedKey and a nonce. This facilitates payer privacy by not
tying any InvoiceRequest to any other nor to the payer's node id.

Additionally, support stateless Invoice verification by setting payer
metadata using an HMAC over the nonce and the remaining TLV records,
which will be later verified when receiving an Invoice response.

Refactor InvoiceRequestContents fields into a sub-struct

InvoiceRequestBuilder has a field containing InvoiceRequestContents.
When deriving the payer_id from the remaining fields, a struct is needed
without payer_id as it not optional. Refactor InvoiceRequestContents to
have an inner struct without the payer_id such that
InvoiceRequestBuilder can use it instead.

Stateless verification of InvoiceRequest

Verify that an InvoiceRequest was produced from an Offer constructed by
the recipient using the Offer metadata reflected in the InvoiceRequest.
The Offer metadata consists of a 128-bit encrypted nonce and possibly a
256-bit HMAC over the nonce and Offer TLV records (excluding the signing
pubkey) using an ExpandedKey.

Thus, the HMAC can be reproduced from the offer bytes using the nonce
and the original ExpandedKey, and then checked against the metadata. If
metadata does not contain an HMAC, then the reproduced HMAC was used to
form the signing keys, and thus can be checked against the signing
pubkey.

Merge pull request #2203 from wpaulino/retry-untractable-packages

Retry untractable packages

TlvStream range iterator

Add an iterator that yields TlvRecords over a range of a TlvStream.
Useful for verifying that, e.g., an InvoiceRequest was sent in response
to an Offer constructed by the intended recipient.

Offer metadata and signing pubkey derivation

Add support for deriving a transient signing pubkey for each Offer from
an ExpandedKey and a nonce. This facilitates recipient privacy by not
tying any Offer to any other nor to the recipient's node id.

Additionally, support stateless Offer verification by setting its
metadata using an HMAC over the nonce and the remaining TLV records,
which will be later verified when receiving an InvoiceRequest.

Make PackageTemplate::height_timer non-optional

Now that we leverage a package's `height_timer` even for untractable
packages, there's no need to have it be an `Option` anymore. We aim to
not break compatibility by keeping the deserialization of such as an
`option`, and use the package's `height_original` when not present. This
allows us to retry packages from older `ChannelMonitor` versions that
have had a failed initial package broadcast.

Use existing height timer to retry untractable packages

Untractable packages are those which cannot have their fees updated once
signed, hence why they weren't retried. There's no harm in retrying
these packages by simply re-broadcasting them though, as the fee market
could have spontaneously spiked when we first broadcast it, leading to
our transaction not propagating throughout node mempools unless
broadcast manually.

Merge pull request #2127 from TheBlueMatt/2023-03-payment-metadata

Support sending `PaymentMetadata` in HTLCs

Fix variable name typo

Update and clarify the reasons for HTLCDestination::FailedPayment

Add some tests of payment metadata being sent and received

Expose the `RecipientOnionFields` in `Event::PaymentClaimable`

This finally completes the piping of the `payment_metadata` from
from the BOLT11 invoice on the sending side all the way through the
onion sending + receiving ends to the user on the receive events.

Pipe received `payment_metadata` through the HTLC receipt pipeline

When we receive an HTLC, we want to pass the `payment_metadata`
through to the `PaymentClaimable` event. This does most of the
internal refactoring required to do so - storing a
`RecipientOnionFields` in the inbound HTLC tracking structs,
including the `payment_metadata`.

In the future this struct will allow us to do MPP keysend receipts
(as it now stores an Optional `payment_secret` for all inbound
payments) as well as custom TLV receipts (as the struct is
extensible to store additional fields and the internal API supports
filtering for fields which are consistent across HTLCs).

`continue` automatically after `fail_htlc` in receiving an HTLC

If we receive an HTLC and are processing it a potential MPP part,
we always continue in the per-HTLC loop if we call the `fail_htlc`
macro, thus its nice to actually do the `continue` therein rather
than at the callsites.

Add a debug_assert the newly-documented (but existing) requirement

If we add an entry to `claimable_payments` we have to ensure we
actually accept the HTLC we're considering, otherwise we'll end up
with an empty `claimable_payments` entry.

Actually test `futures` builds

Currently the BP `futures` tests rely on `std`. In order to actually
have them run, we should enable `std`, i.e., remove
`--no-default-features`.

Fix unrelated warnings

Just two trivial compiler warnings that are unrelated to the changes
made here.

Make `claimable_payments` map value a struct, rather than a tuple

This makes the `claimable_payments` code more upgradable allowing
us to add new fields in the coming commit(s).

Add a `payment_metadata` field to `RecipientOnionFields`

This adds the new `payment_metadata` to `RecipientOnionFields`,
passing the metadata from BOLT11 invoices through the send pipeline
and finally copying them info the onion when sending HTLCs.

This completes send-side support for the new payment metadata
feature.

Deserialize payment metadata fields in the onion final hop data

Support setting the new payment metadata field in invoices

This adds support for setting the new payment metadata field in
BOLT11 invoices, using a new type flag on the builder to enforce
transition correctness.

We allow users to set the payment metadata as either optional or
required, defaulting to optional so that invoice parsing does not
fail if the sender does not support payment metadata fields.

Support reading the new `payment_metadata` field in invoices

This adds support for reading the new `PaymentMetadata` BOLT11
invoice field, giving us access to the `Vec<u8>` storing arbitrary
bytes we have to send to the recipient.

Unset the optional bit for a feature when setting the required bit

There is no reason to set both, and this currently makes testing
the new BOLT invoice tests slightly harder, so we just unset it.

Add features module-level documentation for missing features

Add another ExpandedKey derivation for Offers

To support transient signing pubkeys and payer ids for Offers, add
another key derivation to ExpandedKey. Also useful for constructing
metadata for stateless message authentication.

Add missing UnknownRequiredFeatures tests

Common offers test_utils module

Move utility functions used across all offers modules into a common
module. Avoids duplicating larger utilities such as payment_path across
more than one module.

Merge pull request #2198 from TheBlueMatt/2023-04-fewer-disables

Only disable channels ~10 min after disconnect, rather than one

Only disable channels ~10 min after disconnect, rather than one

We correctly send out a gossip channel disable update after one
full time tick being down (1-2 minutes). This is pretty nice in
that it avoids nodes trying to route through our nodes too often
if they're down. Other nodes have a much longer time window,
causing them to have much less aggressive channel disables. Sadly,
at one minute it's not super uncommon for tor nodes to get disabled
(once a day or so on two nodes I looked at), and this causes the
lightning terminal scorer to consider the LDK node unstable (even
though it's the one doing the disabling - so is online). This
causes user frustration and makes LDK look bad (even though it's
probably failing fewer payments).

Given this, and future switches to block-based `channel_update`
timestamp fields, it makes sense to go ahead and switch to delaying
channel disable announcements for 10 minutes. This puts us more in
line with other implementations and reduces gossip spam, at the
cost of less reliable payments.

Fixes #2175, at least the currently visible parts.

Set `channel_update` disable bit based on staged even for onions

When generating a `channel_update` either in response to a fee
configuration change or an HTLC failure, we currently poll the
channel to check if the peer's connected when setting the disabled
bit in the `channel_update`. This could cause cases where we set
the disable bit even though the peer *just* disconnected, and don't
generate a followup broadcast `channel_update` with the disabled
bit unset.

While a node generally shouldn't rebroadcast a `channel_update` it
received in an onion, there's nothing inherently stopping them from
doing so. Obviously in the fee-update case we expect the message to
propagate.

Luckily, since we already "stage" disable-changed updates, we can
check the staged state and use that to set the disabled bit in all
`channel_update` cases.

Merge pull request #2138 from swilliamson5/replace-our-max-htlcs-constant

Replace `OUR_MAX_HTLCS` with config knob

Merge pull request #2196 from wpaulino/ci-ignore-master-cancel-prev

Prevent unnecessary CI workflow runs

Merge pull request #2195 from TheBlueMatt/2023-04-115-bindings-upstream

Cancel in-progress jobs on updated push

At times, PRs can go through multiple pushes in a short amount of time,
spawning a workflow run for each. Most of the time, there's no need to
let the previous jobs running if the code itself has changed (e.g., via
a force push), and we'd benefit from having those slots be used by other
PRs/branches instead.

Ignore workflow runs on master branch

This master branch is just an alias to the main branch for legacy
reasons, so there's no need to run workflows on both branches.

Mark the invoice `Network` getter no-export

...as it is redundant with the `currency` getter if we're not using
the rust-bitcoin types natively.

Merge pull request #2177 from TheBlueMatt/2023-04-test-function-generics

Genericize Test Functions

Merge pull request #2191 from TheBlueMatt/2023-04-fix-bucket-deser

Fix deserialization of u16 arrays

Merge pull request #2187 from benthecarman/invoice-serde-no-std

Replace OUR_MAX_HTLCS constant with config knob
holder_max_accepted_htlcs. Set upper bound of 483

Writes an even TLV if the value isn't 50

Fix deserialization of u16 arrays

u16 arrays are used in the historical liquidity range tracker.
Previously, we read them without applying the stride multiple,
reading bytes repeatedly and at an offset, corrupting data as we
go.

This applies the correct stride multiplayer fixing the issue.

Add CI test for compile no-std serde lightning-invoice

Fix compiling lightning-invoice for no-std + serde

Merge pull request #2172 from TheBlueMatt/2023-04-fix-panicy-debug-assert

Remove a race-y debug assertion in new channel update handling

Merge pull request #2180 from benthecarman/impl-pk-to-node-id

Implement to and from for PublicKey and NodeId

Impl FromStr for NodeId

Merge pull request #2179 from benthecarman/use-node-alias-type

Use NodeAlias type in NodeAnnouncement

Move some additional test macros into functions

This marginally reduces the quantity of code compiled in tests
further.

Introduce traits to make test utils generic across the `CM` Holder

In our test utilities, we generally refer to a `Node` struct which
holds a `ChannelManager` and a number of other structs. However, we
use the same utilities in benchmarking, where we have a different
`Node`-like struct. This made moving from macros to functions
entirely impossible, as we end up needing multiple types in a given
context.

Thus, here, we take the pain and introduce some wrapper traits
which encapsulte what we need from `Node`, swapping some of our
macros to functions.

Use NodeAlias type in NodeAnnouncement