Move to a constant for "bucket one" in the scoring buckets

Scoring buckets are stored as fixed point ints, with a 5-bit
fractional part (i.e. a value of 1.0 is stored as "32"). Now that
we also have 32 buckets, this leads to the codebase having many
references to 32 which could reasonably be confused for each other.

Thus, we add a constant here for the value 1.0 in our fixed-point
scheme.

Decay `historical_estimated_channel_liquidity_*` result to `None`

`historical_estimated_channel_liquidity_probabilities` previously
decayed to `Some(([0; 8], [0; 8]))`. This was thought to be useful
in that it allowed identification of cases where data was previously
available but is now decayed away vs cases where data was never
available. However, with the introduction of
`historical_estimated_payment_success_probability` (which uses the
existing scoring routines so will decay to `None`) this is
unnecessarily confusing.

Given data which has decayed to zero will also not be used anyway,
there's little reason to keep the old behavior, and we now decay to
`None`.

We also take this opportunity to split the overloaded
`get_decayed_buckets`, removing uneccessary code during scoring.

Special-case the 0th minimum bucket in historical scoring

Points in the 0th minimum bucket either indicate we sent a payment
which is < 1/16,384th of the channel's capacity or, more likely,
we failed to send a payment. In either case, averaging the success
probability across the full range of upper-bounds doesn't make a
whole lot of sense - if we've never managed to send a "real"
payment over a channel, we should be considering it quite poor.

To address this, we special-case the 0th minimum bucket and only
look at the largest-offset max bucket when calculating the success
probability.

Track "steady-state" channel balances in history buckets not live

The lower-bound of the scoring history buckets generally never get
used - if we try to send a payment and it fails, we don't learn
a new lower-bound for the liquidity of a channel, and if we
successfully send a payment we only learn a lower-bound that
applied *before* we sent the payment, not after it completed.

If we assume channels have some "steady-state" liquidity, then
tracking our liquidity estimates *after* a payment doesn't really
make sense - we're not super likely to make a second payment across
the same channel immediately (or, if we are, we can use our
un-decayed liquidity estimates for that). By the time we do go to
use the same channel again, we'd assume that its back at its
"steady-state" and the impacts of our payment have been lost.

To combat both of these effects, here we "subtract" the impact of
any just-successful payments from our liquidity estimates prior to
updating the historical buckets.

Move the historical bucket tracker to 32 unequal sized buckets

Currently we store our historical estimates of channel liquidity in
eight evenly-sized buckets, each representing a full octile of the
channel's total capacity. This lacks precision, especially at the
edges of channels where liquidity is expected to lie.

To mitigate this, we'd originally checked if a payment lies within
a bucket by comparing it to a sliding scale of 64ths of the
channel's capacity. This allowed us to assign penalties to payments
that fall within any more than the bottom 64th or lower than the
top 64th of a channel.

However, this still lacks material precision - on a 1 BTC channel
we could only consider failures for HTLCs above 1.5 million sats.
With today's lightning usage often including 1-100 sat payments in
tips, this is a rather significant lack of precision.

Here we rip out the existing buckets and replace them with 32
*unequal* sized buckets. This allows us to focus our precision at
the edges of a channel (where the liquidity is likely to lie, and
where precision helps the most).

We set the size of the edge buckets to 1/16,384th of the channel,
with the size increasing exponentially until it approaches the
inner buckets. For backwards compatibility, the buckets divide
evenly into octets, allowing us to convert the existing buckets
into the new ones cleanly.

This allows us to consider HTLCs down to 6,000 sats for 1 BTC
channels. In order to avoid failing to penalize channels which have
always failed, we drop the sliding scale for comparisons and simply
check if the payment is above the minimum bucket we're analyzing and
below *or in* the maximum one. This generates somewhat more
pessimistic scores, but fixes the lower bound where we suddenly
assign a 0% failure probability.

While this does represent a regression in routing performance, in
some cases the impact of not having to examine as many nodes
dominates, leading to a performance increase.

On a Xeon E3-1220 v5, the `large_mpp_routes` benchmark shows a 15%
performance increase, while the more stable benchmarks show an 8%
and 15% performance regression.

Implement serialization for `[u16; 32]`, DRYing it with `[u8; *]`

In the next commit we'll need serialization for `[u16; 32]`, which
we add here, unifying it with the `[u8; *]` serialization macro.

Clarify some scoring documentation by removing extraneous info

Merge pull request #2248 from TheBlueMatt/2023-04-gossip-check

Implement the UtxoSource interface for REST/RPC clients

Merge pull request #2503 from valentinewallace/2023-08-fix-router-debug-panic

Fix debug panic in the case where a first hop has a channel with an introduction node

Merge pull request #2466 from TheBlueMatt/2023-07-expose-success-prob

Expose the historical success probability calculation itself

Merge pull request #2519 from Sharmalm/main

Print contents of our own channel updates for broadcast in non-gossip logs

Router: account for blinded path fee, etc on first_hop<>intro hop add

This previously led to a debug panic in the router because we wouldn't account
for the blinded path fee when calculating first_hop<>intro_node hop's available
liquidity and construct an invalid path that forwarded more over said hop than
was actually available.

This also led to us hitting unreachable code, see direct_to_matching_intro_nodes
test description.

improving message in log

Fail UTXO lookups if the block doesn't have five confirmations

The BOLT spec mandates that channels not be announced until they
have at least six confirmations. This is important to enforce not
because we particularly care about any specific DoS concerns, but
because if we do not we may have to handle reorgs of channel
funding transactions which change their SCID or have conflicting
SCIDs.

Add a simple naive block cache in gossip sync lookups

Make the `P2PGossipSync` `UtxoLookup` exchangable without &mut self

Because a `UtxoLookup` implementation is likely to need a reference
to the `PeerManager` which contains a reference to the
`P2PGossipSync`, it is likely to be impossible to get a mutable
reference to the `P2PGossipSync` by the time we want to add a
`UtxoLookup` without a ton of boilerplate and trait wrapping.

Instead, we simply place the `UtxoLookup` in a `RwLock`, allowing
us to modify it without a mutable self reference.

The lifetime bounds updates in tests required in this commit are
entirely unclear to me, but do allow tests to continue building, so
somehow make rustc happier.

Implement the `UtxoSource` interface for REST/RPC clients

In LDK, we expect users operating nodes on the public network to
implement the `UtxoSource` interface in order to validate the
gossip they receive from the network.

Sadly, because the DoS attack of flooding a node's gossip store
isn't a common issue, and because we do not provide an
implementation off-the-shelf to make doing so easily, many of our
downstream users do not have a `UtxoSource` implementation.

In order to change that, here we implement an async `UtxoSource`
in the `lightning-block-sync` crate, providing one for users who
sync the chain from Bitcoin Core's RPC or REST interfaces.

Merge pull request #2515 from TheBlueMatt/2023-08-earlier-payment-hash-log

Include payment hash in more early payment logs

Store a `HistoricalMinMaxBuckets` in `DirectedChannelLiquidity`

This removes the need to reconstruct the struct in a number of
places by simply creating it up front.

Move the bucketed history tracking logic into a scoring submodule

Expose the historical success probability calculation itself

In 3f32f60ae7e75a4be96d3d5adc8d18b53445e5e5 we exposed the
historical success probability buckets directly, with a long method
doc explaining how to use it. While this is great for logging
exactly what the internal model thinks, its also helpful to let
users know what the internal model thinks the success probability
is directly, allowing them to compare route success probabilities.

Here we do so but only for the historical tracking buckets.

Find payment bucket in calculate_success_probability_times_billion

This simply moves code which will simplify the next commit
somewhat.

Correctly apply penalty bounds on the per-amount penalties

When we attempt to score a channel which has a success probability
very low, we may have a log well above our cut-off of two. For the
liquidity penalties this works great, we bound it by
`NEGATIVE_LOG10_UPPER_BOUND` and `min` the two scores. For the
amount liquidity penalty we didn't do any `min`ing at all.

This fix is to min the log itself first and then reuse the min'd
log in both calculations.

Don't rely on `calculate_success_probability*` to handle amt > cap

Currently we let an `htlc_amount >= channel_capacity` pass through
from `penalty_msat` to
`calculate_success_probability_times_billion`, but only if its only
marginally bigger (less than 65/64ths). This is fine as
`calculate_success_probability_times_billion` handles bogus values
just fine (it will always return a zero probability in such cases).

However, this is risky, and in fact breaks in the coming commits,
so instead check it before ever calling through to the historical
bucket probability calculations.

Merge pull request #2337 from alecchendev/2023-06-watchtower-support

Support third-party watchtowers in persistence pipeline

Merge pull request #2412 from valentinewallace/2023-07-construct-blinded-paths

Add API for constructing blinded payment paths

Test justice tx formation from persistence

Here we implement `WatchtowerPersister`, which provides a test-only
sample implementation of `Persist` similar to how we might imagine a
user to build watchtower-like functionality in the persistence pipeline.

We test that the `WatchtowerPersister` is able to successfully build and
sign a valid justice transaction that sweeps a counterparty's funds if
they broadcast an old commitment.

Enable signing a justice tx using the channel monitor

Expose revokeable output index and building a justice tx from commitment

For watchtowers to be able to build justice transactions for our
counterparty's revoked commitments, they need to be able to find the
revokeable output for them to sweep. Here we cache `to_self_delay` in
`CommitmentTransaction` to allow for finding this output on the struct
directly. We also add a simple helper method to aid in building the
initial spending transaction.

This also adds a unit test for both of these helpers, and
refactors a bit of a previous `CommitmentTransaction` unit test to make
adding these easier.

Enable monitor to rebuild initial counterparty commitment tx

Upon creating a channel monitor, it is provided with the initial
counterparty commitment transaction info directly before the very first
time it is persisted. Because of this, the very first counterparty
commitment is not seen as an update in the persistence pipeline, and so
our previous changes to the monitor and updates cannot be used to
reconstruct this commitment.

To be able to expose the counterparty's transaction for the very first
commitment, we add a thin wrapper around
`provide_latest_counterparty_commitment_tx`, that stores the necessary
data needed to reconstruct the initial commitment transaction in the
monitor.

Build and expose counterparty commitments from monitor update

Remove redundant payment preimag hashing in HTLC claim pipeline

Currently, when we receive an HTLC claim from a peer, we first hash
the preimage they gave us before removing the HTLC, then
immediately pass the preimage to the inbound channel and hash the
preimage again before removing the HTLC and sending our peer an
`update_fulfill_htlc`. This second hash is actually only asserted
on, never used in any meaningful way as we have the htlc data
present in the same code.

Here we simply drop this second hash and move it into a
`debug_assert`.

Include payment hash in more early payment logs

If a user has issues with a payment, the most obvious thing they'll
do is check logs for the payment hash. Thus, we should ensure our
logs that show a payment's lifecycle include the payment hash and
are emitted (a) as soon as LDK learns of the payment, (b) once the
payment goes out to the peer (which is already reasonably covered
in the commitment transaction building logs) and (c) when the
payment ultimately is fulfilled or fails.

Here we improve our logs for both (a) and (c).

Add feerate and balances to `LatestCounterpartyCommitmentTXInfo`

This adds the feerate and local and remote output values to this channel
monitor update step so that a monitor can reconstruct the counterparty's
commitment transaction from an update. These commitment transactions
will be exposed to users in the following commits to support third-party
watchtowers in the persistence pipeline.

With only the HTLC outputs currently available in the monitor update, we
can tell how much of the channel balance is in-flight and towards which
side, however it doesn't tell us the amount that resides on either side.
Because of dust, we can't reliably derive the remote value from the
local value and visa versa. Thus, it seems these are the minimum fields
that need to be added.

Merge pull request #2492 from optout21/payment-hash-display

[minor] Add Display to Payment ID types

Document _init_and_read_* ser macro requirements

Fix documentation on onion message packet ControlTlvs

Blinded paths: rename encrypted_tlvs_ss to *_rho for precision

The previous name can be confused for the shared secret that the rho is derived
from.

Support constructing BlindedPaths for payments.

Simplify onion message blinded hop construction

Also adds a util for general blinded hop creation to be reused for blinded
payment paths.

Add new _init_and_read_tlv_stream ser macro

Useful for when you want to use _init_and_read_len_prefixed_tlv_fields but there is no
length byte at the start of the TLV stream.

Use Display of PaymentId&PaymentPreimage; avoid log_bytes macro

Merge pull request #2441 from arik-so/2023-07-taproot-signer-wrapped

Wrapped Channel Signer Type

Remove unused imports.

Remove a bunch of unnecessary ChannelManager
imports.

Introduce ChannelSignerType.

Rather than using a holder_signer of a specific
signer type in Channel and ChannelContext, this
allows us to hold an enum such that depending on
the type of channel, the appropriate signer could
be held in its respective variant.

Doing so required the reparametrization of Channel
from using a Signer to using the SignerProvider
trait. This percolated down to the ChannelManager
and multiple tests.

Now, when accessign various signer methods, there
is a distinction between accessing methods defined
for all signers on ChannelSigner, and accessing
type-specific methods using accessors such as
`as_ecdsa`.

Fix bench lifetimes.

Benchmarks were failing because node config and
channel monitor configs were tied to the same
lifetime.

Introducing a separate lifetime allows to avoid
out-of-order deallocation errors.

Add Taproot feature support.

Introduce a Taproot feature on bits 30/31 for
initialization, node, and channel type contexts.

Fix persister/chain_monitor lifetimes.

The persister and chain_monitor variables must
be declared before the node channel manager is
initialized to avoid out of order deallocation.

Merge pull request #2511 from jbesraa/add-channel-id-to-spendableoutputs-event

Add channel_id to SpendableOutputs event

Merge pull request #2432 from jkczyz/2023-07-bolt12-node-signer

Support signing BOLT 12 messages in `NodeSigner`

Rename ser macro

We want a similar macro for reading TLV streams without a length prefix, so
rename this one to disambiguate.

Minor BlindedHop docs update

Update blinded path util to take iterator instead of slice

Useful for blinded payment path construction.

Move Padding into blinded_path module for use in blinded payments

Move blinded message path util into message submodule

Move some blinded path message code into message submodule.

We'll similarly separate blinded path payments code into its own module.

Move blinded path util into blinded_path::utils

This way it can be more easily reused for blinded payment paths.

Merge pull request #2411 from valentinewallace/2023-07-blinded-onion-keys

Support constructing blinded path onion keys

Add Display to PaymentId & PaymentPreimage

Use Display of PaymentHash; avoid log_bytes macro

Add Display to PaymentHash

Add channel_id to SpendableOutputs event
    This will make it possible to
    link between SpendableOuts and ChannelMonitor

    - change channel_id to option so we dont break upgrade
    - remove unused channel_id
    - document channel_id
    - extract channel id dynamically to pass test
    - use contains to check channel_id in test as the events are not ordered
    - update docs framing
    - specify ldk version channel_id will be introduced in

Co-authored-by: Elias Rohrer <dev@tnull.de>
Update lightning/src/events/mod.rs

Co-authored-by: Elias Rohrer <dev@tnull.de>

Merge pull request #2507 from TheBlueMatt/2023-08-lnd-6039

Work around LND bug 6039

Support signing BOLT 12 invoices in NodeSigner

BOLT 12 messages need to be signed in the following scenarios:
- constructing an InvoiceRequest after scanning an Offer,
- constructing an Invoice after scanning a Refund, and
- constructing an Invoice when handling an InvoiceRequest.

Extend the NodeSigner trait to support signing BOLT 12 invoices such
that it can be used in the latter contexts. The method could be used
in an OffersMessageHandler.

Use TaggedHash in merkle::verify_signature

An earlier commit introduced TaggedHash for use in sign_message. For
consistency, use it in verify_signature, too.

Expose Offer/InvoiceRequest methods in Invoice

Bolt12Invoice can either be for an Offer (via an InvoiceRequest) or a
Refund. It wraps those types, so expose their methods on both
Bolt12Invoice and UnsignedBolt12Invoice.

Since Refund does not have all the Offer/InvoiceRequest methods, use an
Option return type such that None can returned for refund-based
invoices.

For methods that are duplicated between Offer/InvoiceRequest and
Bolt12Invoice, prefer the (non-Option, if applicable) method from
Bolt12Invoice (e.g., amount_msats, signing_pubkey).

Expose invoice accessors in UnsignedBolt12Invoice

Expose Offer accessor functions in InvoiceRequest

Also, expose both Offer and InvoiceRequest functions in
UnsignedInvoiceRequest.

Macro-ize InvoiceRequest accessors for reuse

Various messages wrap InvoiceRequestContents, which shouldn't be exposed
as it is an implementation detail. Define a macro for InvoiceRequest
accessor methods so that these messages can also define them.

Macro-ize Offer accessors for reuse

InvoiceRequest wraps OfferContents, which shouldn't be exposed as it is
an implementation detail. Define a macro for Offer accessor methods so
that InvoiceRequest and UnsignedInvoiceRequest can also define them.

Move BOLT 12 invoice method implementations

Move BOLT 12 InvoiceRequest method implementations

Move BOLT 12 offer method implementations

Unsigned BOLT 12 message parsing and serialization

Rename field of unsigned BOLT message contents

Using `contents` for the field name is more consistent with the signed
messages.

Wrap KeyPair by DerivedSigningPubkey

InvoiceBuilder is parameterized by a SigningPubkeyStrategy, either
ExplicitSigningPubkey and DerivedSigningPubkey. It also holds an
Option<KeyPair>, which may be None and Some for those strategies,
respectively. This leads to methods for InvoiceBuilder parameterized by
DerivedSigningPubkey needing to blindly unwrap the Option<KeyPair>.
Instead, have DerivedSigningPubkey wrap KeyPair.

TaggedHash for BOLT 12 signing function

The function used to sign BOLT 12 messages only takes a message digest.
This doesn't allow signers to independently verify the message before
signing nor does it allow them to derive the necessary signing keys, if
needed.

Introduce a TaggedHash wrapper for a message digest, which each unsigned
BOLT 12 message type constructs upon initialization. Change the signing
function to take AsRef<TaggedHash>, which each unsigned type implements.
This allows the signing function to take any unsigned message and obtain
its tagged hash.

Send warning messages when repeating shutdown messages at volume

Merge pull request #2498 from arik-so/arik/2023-08-gossip-logging

Improve network graph update logging

Merge pull request #2478 from waterson/settle-htlcs

Provide the HTLCs that settled a payment.

Merge pull request #2112 from TheBlueMatt/2023-02-sent-persist-order

Delay RAA-after-next processing until PaymentSent is are handled

Provide the HTLCs that settled a payment.

Creates a new `events::ClaimedHTLC` struct that contains the relevant
information about a claimed HTLC; e.g., the channel it arrived on, its ID, the
amount of the HTLC, the overall amount of the payment, etc. Adds appropriate
serialization support.

Adds a `Vec<events::ClaimedHTLC>` to the `ClaimingPayment`
structure. Populates this when creating the struct by converting the
`payment.htlcs` (which are `ClaimingHTLC` structs) into `event::ClaimedHTLC`
structs. This is a straightforward transformation.

Adds a `Vec<events::ClaimedHTLC>` to the `events::Event::PaymentClaimed`
enum. This is populated directly from the `ClaimingPayment`'s `htlcs` vec.

Fixes #2477.

Struct-ify decoded onion failures

To avoid several long hard-to-read tuple return values.

Document and test 0-len channel update onion error case

Add missing test coverage for bogus err packet with valid hmac

Generalize next_hop_packet_pubkey onion util

Useful for generating a next hop blinding point when forwarding a blinded
payment.

Blinded paths: support constructing onion keys + handling onion errors

We don't bother actually parsing errors from within a blinded path, since all
errors should be wiped by the introduction node by the time it gets back to us
(the sender).

Work around LND bug 6039

LND hasn't properly handled shutdown messages ever, and
force-closes any time we send one while HTLCs are still present.
The issue is tracked at
https://github.com/lightningnetwork/lnd/issues/6039 and has had
multiple patches to fix it but none so far have managed to land
upstream. The issue appears to be very low priority for the LND
team despite being marked "P1".

We're not going to bother handling this in a sensible way, instead
simply repeated the Shutdown message on repeat until morale
improves.

Delay RAA-after-next processing until PaymentSent is are handled

In 0ad1f4c943bdc9037d0c43d1b74c745befa065f0 we fixed a nasty bug
where a failure to persist a `ChannelManager` faster than a
`ChannelMonitor` could result in the loss of a `PaymentSent` event,
eventually resulting in a `PaymentFailed` instead!

As noted in that commit, there's still some risk, though its been
substantially reduced - if we receive an `update_fulfill_htlc`
message for an outbound payment, and persist the initial removal
`ChannelMonitorUpdate`, then respond with our own
`commitment_signed` + `revoke_and_ack`, followed by receiving our
peer's final `revoke_and_ack`, and then persist the
`ChannelMonitorUpdate` generated from that, all prior to completing
a `ChannelManager` persistence, we'll still forget the HTLC and
eventually trigger a `PaymentFailed` rather than the correct
`PaymentSent`.

Here we fully fix the issue by delaying the final
`ChannelMonitorUpdate` persistence until the `PaymentSent` event
has been processed and document the fact that a spurious
`PaymentFailed` event can still be generated for a sent payment.

The original fix in 0ad1f4c943bdc9037d0c43d1b74c745befa065f0 is
still incredibly useful here, allowing us to avoid blocking the
first `ChannelMonitorUpdate` until the event processing completes,
as this would cause us to add event-processing delay in our general
commitment update latency. Instead, we ultimately race the user
handling the `PaymentSent` event with how long it takes our
`revoke_and_ack` + `commitment_signed` to make it to our
counterparty and receive the response `revoke_and_ack`. This should
give the user plenty of time to handle the event before we need to
make progress.

Sadly, because we change our `ChannelMonitorUpdate` semantics, this
change requires a number of test changes, avoiding checking for a
post-RAA `ChannelMonitorUpdate` until after we process a
`PaymentSent` event. Note that this does not apply to payments we
learned the preimage for on-chain - ensuring `PaymentSent` events
from such resolutions will be addressed in a future PR. Thus, tests
which resolve payments on-chain switch to a direct call to the
`expect_payment_sent` function with the claim-expected flag unset.

Pass `OutPoint`, rather than channel id to `claim_funds_internal`

This is a trivial refactor which will be used in the next commit.

Merge pull request #2506 from tnull/2023-08-dont-leak-internal-macros

Don't require import of internal macro for `impl_writeable_tlv_based`

Improve network graph update logging.

Don't require import of internal macros

Commit f560320b introduced changes that require users of
`impl_writeable_tlv_based`/`impl_writeable_tlv_based_enum` to import
`_encode_varint_length_prefixed_tlv` and `alloc` separately.

Here, we take care of the necessary imports in
`_encode_varint_length_prefixed_tlv` itself, allowing users to just
import the `impl_writeable_tlv_based` variant they need.

Merge pull request #2501 from TheBlueMatt/2023-08-err-pre-accept

Ensure we wipe pending un-accepted channel requests on err/discon.

Update documentation on `Channel::set_outbound_scid_alias`

...and replace an assertion with a debug_assertion

Merge pull request #2504 from alecchendev/2023-08-custom-tlvs-followup

Followup: custom HTLC TLVs

Address custom HTLC TLV fixups

Don't collect iterators to compare, minorly simplify encoding the
keysend TLV, combine the _encode_tlv_stream variants to check that the
ordering of TLVs is correct including custom TLVs.

Simplify custom HTLC TLV tests

Remove print statement, remove some unnecessary checks copied over from
test utils, make minor simplifications, wrap especially long lines.

Merge pull request #2500 from TheBlueMatt/2023-08-fix-test-lifetimes

Use more human-readable lifetime names in test structs