Include payment hash in Bolt12Invoice reply path

Instead of using OffersContext::Unknown for the Bolt12Invoice reply path
use OffersContext::InboundPayment to include the payment hash.
OffersContext::Unknown will be removed in another commit.

Include payment hash when logging invoice handling

Include payment hash when logging InvoiceError

By including the payment hash from the invoice in an onion message's
reply path, it can be used when logging errors as additional context.

Use BlindedPath::new_for_payment in fuzz tests

When creating a Bolt12Invoice in fuzz tests, use
BlindedPath::new_for_payment instead of BlindedPath::new_for_message.
This way PaymentContext is used instead of MessageContext, as is more
realistic though should not affect the test. This allows us to remove
OffersContext::Unknown.

Use different iv_bytes for blinded path metadata

Best practice is to use different IV bytes for different contexts.
Update Offer and Refund metadata computation to use different IV bytes
when the metadata is included in a blinded path. For invoice requests,
the metatdata will always be in the blinded path, so it remains the
same.

Delay adding iv_bytes to MetadataMaterial::hmac

In an upcoming commit, the iv_bytes used in MetadataMaterial will vary
depending on when whether a blinded path is included in the
corresponding message. Delay adding into MetadataMaterial::hmac as
otherwise the HmacEngine would need to be re-initialized using an
ExpandedKey, which won't be readily available.

Result from Bolt12Invoice::verify_using_payer_data

Use a Result return type instead of a bool when verifying a
Bolt12Invoice. This way ignoring the result will produce a compiler
warning.

Bolt12Invoice::is_for_refund_without_paths tests

Merge pull request #3189 from tnull/2024-07-rustfmt-lightning-net-tokio

 `rustfmt`: Run on `lightning-net-tokio`

Merge pull request #3171 from jkczyz/2024-07-propagate-error

Include routing failures in `Bolt12PaymentError`

Merge pull request #3203 from lexe-app/pr/description-as-inner

lightning-invoice: Add `Description::as_inner`

lightning-invoice: Add `Description::as_inner`

Merge pull request #3196 from TheBlueMatt/2024-07-monitor-ordering

Ensure `ChannelMonitorUpdate`s are ordered with full monitor writes

Merge pull request #3199 from TheBlueMatt/2024-07-funding-check

Enforce segwit inputs for all "safe" funding transactions

Merge pull request #3139 from jkczyz/2024-06-blinded-path-auth

Authenticate use of offer blinded paths

Merge pull request #3197 from TheBlueMatt/2024-07-stupid-locked-connect

[block-sync] Don't hold client-cache lock while connecting

Enforce segwit inputs for all "safe" funding transactions

8403755a2a524beb9f6c8951f51dd60f7c54c912 introduced a separate path
for funding a channel without a full funding transaction, relying
on users to manually broadcast the funding tx. One of the major
things that makes this path less safe is that for other paths we're
supposed to validate that all inputs have witnesses, making the
funding transaction (likely) txid-non-malleable.

However, in one of several rewrites of that commit the funding tx
tests ended up getting elided in some call paths, which is fixed
here.

Add pending changelog for BOLT12 authentication

Rename Bolt12Invoice::verify

Elide nonce from payer metadata

InvoiceRequest and Refund have payer_metadata which consists of an
encrypted payment id and a nonce used to derive its signing keys and
authenticate any corresponding invoices. Now that the blinded paths
include this data in their OffersContext, remove the nonce as it is now
redundant. Keep the encrypted payment id as some data is needed in the
payer metadata according to the spec. This saves space and prevents
de-anonymization attacks as along as the nonce isn't revealed.

Correct docs

Include OffersContext in Event::InvoiceReceived

When authenticating that an invoice is for a valid invoice request, the
payer metadata is needed. Some of this data will be removed in the next
commit and instead be included in the message context of the request's
reply path. Add this data to Event::InvoiceReceived so that asynchronous
invoice handling can verify properly.

Authenticate Bolt12Invoice using BlindedPath data

When a Bolt12Invoice is handled with an OfferContext, use both the
containing payment_id and nonce to verify that it is for a pending
outbound payment. Previously, the nonce the payment_id were taken from
the payer_metadata and the latter was compared against the payment_id
in the OfferContext. The payer_metadata thus no longer needs to include
either when a blinded path is used. However, some payer_metadata will
still be needed as per the spec.

Add nonce to OffersContext::OutboundPayment

To authenticate that a Bolt12Invoice is for a valid InvoiceRequest or
Refund, include the nonce from the payer_metadata in the InvoiceRequest
reply path or Refund::paths, respectively. This can be used to prevent
de-anonymization attacks where an attacker sends invoices using
self-constructed paths to nodes near the blinded paths' introduction
nodes.

Add Bolt12Invoice::verify_using_payer_data

Invoices are authenticated by checking the payer metadata in the
corresponding invoice request or refund. For all invoices requests and
for refunds using blinded paths, this will be the encrypted payment id
and a 128-bit nonce. Allows checking the unencrypted payment id and
nonce explicitly instead of the payer metadata. This will be used by an
upcoming change that includes the payment id and nonce in the invoice
request's reply path and the refund's blinded paths instead of
completely in the payer metadata, which mitigates de-anonymization
attacks.

Pass Nonce directly to RefundBuilder

When using RefundBuilder::deriving_payer_id, the nonce generated needs
to be the same one included in any RefundBuilder::paths. This is because
the nonce is used along with the refund TLVs to derive a payer id and
will soon be used to authenticate any invoices.

Pass Nonce directly to InvoiceRequestBuilder

When using InvoiceRequestBuilder::deriving_payer_id, the nonce generated
needs to be the same one included in any reply path. This is because the
nonce is used along with the invoice request TLVs to derive a payer id.
While this data is also included in the payer_metadata, including it in
the blinded path would allow reducing the amount of data needed there to
just enough to provide entropy (i.e., 16 bytes). This is more important
for Refund because it can be transmitted via a QR code. But using the
same payer_metadata structure for both InvoiceRequest and Refund would
be beneficial to avoid more code.

Add failure tests for offer message authentication

Don't send InvoiceError on failed authentication

When an invoice or invoice request cannot be authenticated from an
OffersContext, simply do not respond instead of sending an InvoiceError
message. According to BOLT4, messages sent over a blinded path not
intended for its use MUST be ignored.

Authenticate Bolt12Invoice using OfferContext

When a Bolt12Invoice is handled with an OfferContext, use the
containing payment_id to verify that it is for a pending outbound
payment. Only invoices for refunds without any blinded paths can be
verified without an OfferContext.

Add docs to Metadata::without_keys

Rename InvoiceRequest::verify

Elide metadata from Offer with derived keys

When an Offer uses blinded paths, its metadata consists of a nonce used
to derive its signing keys. Now that the blinded paths contain this
nonce, elide the metadata as it is now redundant. This saves space and
also makes it impossible to derive the signing keys if an invoice
request is received with the incorrect nonce. The nonce shouldn't be
revealed in this case either to prevent de-anonymization attacks.

Authenticate InvoiceRequest using OfferContext

When an InvoiceRequest is handled with an OfferContext, use the
containing nonce to verify that it is for a valid Offer. Otherwise, fall
back to using Offer::metadata, which also contains the nonce. The latter
is useful for supporting offers without blinded paths or those created
prior to including an OffersContext in their blinded paths.

Add OffersContext::InvoiceRequest

To authenticate that an InvoiceRequest is for a valid Offer, include the
nonce from the Offer::metadata in the Offer::paths. This can be used to
prevent de-anonymization attacks where an attacker sends requests using
self-constructed paths to nodes near the Offer::paths' introduction
nodes.

Fix OffersContext::Unknown docs

Fix grammar

Expand OffersContext::OutboundPayment docs

Wrap docs at 100 characters

Clean up MessageContext docs

Assert and document valid Metadata states

Metadata is an internal type used within Offer messages. For any
constructed message, Metadata::Bytes is always used. The other variants
are used during construction or verification time. Document this and
debug_assert!(false) accordingly.

Add InvoiceRequest::verify_using_recipient_data

Invoice requests are authenticated by checking the metadata in the
corresponding offer. For offers using blinded paths, this will simply be
a 128-bit nonce. Allows checking this nonce explicitly instead of the
metadata. This will be used by an upcoming change that includes the
nonce in the offer's blinded paths instead of the metadata, which
mitigate de-anonymization attacks.

Pass Nonce directly to OfferBuilder

When using OfferBuilder::deriving_signing_pubkey, the nonce generated
needs to be the same one included in any OfferBuilder::paths. This is
because the nonce is used along with the offer TLVs to derive a signing
pubkey and will soon be elided from the metadata entirely.

Move Nonce to a separate offers sub-module

Nonce is used when constructing Offer::metadata and will soon be need
when constructing BlindedPath for use in authentication. Move it to
separate module now that it is public and will be more widely used.

Reorder imports

Change Nonce visibility to pub

A nonce is generated in OfferBuilder::deriving_signing_pubkey from an
EntropySource for use in Offer::metadata. The same nonce will need to be
included as recipient data in any blinded paths in the Offer. Increase
the visibility to allow for this.

Merge pull request #3024 from jbesraa/funding-signed-event

Funding signed event

[block-sync] Don't hold client-cache lock while connecting

`lightning-block-sync`'s REST and RPC clients both hold a cache for
a connected client to avoid the extra connection round-trip on each
request. Because only one client can be using a connection at once,
the connection is `take()`n out of an `Option` behind a `Mutex` and
if there isn't one present, we call `HttpClient::connect` to build
a new one.

However, this full logic is completed in one statement, causing a
client-cache lock to be held during `HttpClient::connect`. This
can turn into quite a bit of contention when using these clients as
gossip verifiers as we can create many requests back-to-back during
startup.

I noticed this as my node during startup only seemed to be
saturating one core and managed to get a backtrace that showed
several threads being blocked on this mutex when hitting a Bitcoin
Core node over REST that is on the same LAN, but not the same
machine.

Ensure `ChannelMonitorUpdate`s are ordered with full monitor writes

When we update a channel, then while connecting a block persist a
full `ChannelMonitor` prior to persisting the
`ChannelMonitorUpdate`, users can end up seeing a full
`ChannelMonitor` with a given `latest_update_id` prior to seeing
the `ChannelMonitorUpdate` with the same `update_id`. This
could cause users to have a full `ChannelMonitor` on disk as well
as a `ChannelMonitorUpdate` which was already applied. While this
isn't an issue for the LDK-provided update-based `Persist`, its
somewhat surprising for users so we avoid it.

Add debug_assert!(false) for unreachable code

Refactor send_payment_for_bolt12_invoice

The BOLT11 and BOLT12 outbound payment initiation code differ in that
the latter re-uses the retry path (i.e., find_route_and_send_payment).
The drawback of this is that Ok is returned even if there is an error
finding a route. Refactor send_payment_for_bolt12_invoice such that it
re-uses find_initial_route instead so that errors can be returned.

Merge pull request #3152 from alecchendev/2024-06-async-commit-secret-raa

Handle fallible commitment secret

Merge pull request #2995 from tnull/2024-04-fallible-event-handler

Make event handling fallible

Document `Failure Behavior and Persistence` for every event type

Add simple test for event replaying

Handle fallible events in `OnionMessenger`

Previously, we would just fire-and-forget in `OnionMessenger`'s event
handling. Since we now introduced the possibility of event handling
failures, we here adapt the event handling logic to retain any
events which we failed to handle to have them replayed upon the next
invocation of `process_pending_events`/`process_pending_events_async`.

Make event handling fallible

Previously, we would require our users to handle all events
successfully inline or panic will trying to do so. If they would exit
the `EventHandler` any other way we'd forget about the event and
wouldn't replay them after restart.

Here, we implement fallible event handling, allowing the user to return
`Err(())` which signals to our event providers they should abort event
processing and replay any unhandled events later (i.e., in the next
invocation).

Remove `lightning-net-tokio` from exclusion list

`rustfmt`: Run on `lightning-net-tokio`

Prepare `lightning-net-tokio/src/lib.rs`

Hold sep. Mutexes for pending `intercepted_msgs`/`peer_connected` events

This is a minor refactor that will allow us to access the individual
event queue Mutexes separately, allowing us to drop the locks earlier
when processing them individually.

Merge pull request #3160 from TheBlueMatt/2024-07-better-enum-upgradable-ser

Make `impl_writeable_tlv_based_enum*` actually upgradable

Test fallible commitment secret

Merge pull request #3187 from TheBlueMatt/2024-07-routing-nits

#2803 nits

Merge pull request #3136 from tnull/2024-06-rustfmt-lightning-block-sync

Run `rustfmt` on `lightning-block-sync`

Add pending changelog entry for the previous commit

Make `impl_writeable_tlv_based_enum*` actually upgradable

In cc78b77c715d6ef62693d4c1bc7190da990ec0fa it was discovered that
`impl_writeable_tlv_based_enum_upgradable` wasn't actually
upgradable - tuple variants weren't written with length-prefixes,
causing downgrades with new tuple variants to be unreadable by
older clients as they wouldn't know where to stop reading.

This was fixed by simply assuming that any new variants will be
non-tuple variants with a length prefix, but no code write-side
changes were made, allowing new code to freely continue to use the
broken tuple-variant serialization.

Here we address this be defining yet more serialization macros
which aren't broken, and convert existing usage of the existing
macros using non-length-prefixed tuple variants to renamed
`*_legacy` macros.

Note that this changes the serialization format of
`impl_writeable_tlv_based_enum[_upgradable]` when tuple fields are
written, and as such deliberately changes the call semantics for
such tuples.

Only the serialization format of `MessageContext` is changed here
which is fine as it has not yet reached a release of LDK.

Drop excess `()`s in `router.rs`

Marginally improve comments around cache lines in `gossip.rs`

Merge pull request #2803 from TheBlueMatt/2023-12-routing-dist-vec

Misc routing optimization

Handle fallible `release_commitment_secret`

Merge pull request #3087 from shaavan/reply_path_diversity

Allow blinded path diversification by expanding `create_blinded_paths`

Merge pull request #3185 from tnull/2024-07-clarify-max-description-length

Clarify maximum length of an invoice description

Merge pull request #3183 from TheBlueMatt/2024-07-no-strict

Drop unnecessary `strict` feature from `lightning-invoice`

Merge pull request #3150 from alecchendev/2024-06-async-commit-point-raa

Handle fallible per commitment point for RAA

Clarify maximum length of an invoice description

We previously stated in the docs that the invoice description can be at most `1023`
bytes long, which is wrong. According to BOLT 11 it's at most 1023*5 bits (639 bytes) long.

Test async get per commitment point for revoke_and_ack

Note: this does not test the CS -> RAA resend ordering, because this
requires handling async get_per_commitment_point for channel
reestablishment, which will be addressed in a follow up PR.

Allow failing revoke_and_ack if commitment point is not available

Change get_per_commitment_point to return result type

Includes simple changes to test util signers and tests, as well as
handling the error case for get_per_commitment_point in
HolderCommitmentPoint. This leaves a couple `.expect`s in places
that will be addressed in a separate PR for handling funding.

Merge pull request #3165 from Harshit933/link-fix

Fixes `Sensei` broken link

Add logger as parameter in creating ChannelContext

Return an error if we fail to advance our commitment number

Drop unnecessary `strict` feature from `lightning-invoice`

99aa6e27f616c96dda2b49d09bafbc0b982251e0 detected that we had an
undefined feature in `lightning-invoice` called `strict`, which was
used to turn on `deny(warnings)`. It resolved that by adding the
feature to the `Cargo.toml`, but we actually don't need it - our CI
already builds with `-Dwarnings`, so any warnings should be
rejected during CI and there's not a lot of value in having a
(public) feature to do the same.

Merge pull request #3173 from dunxen/2024-07-cargocheckcfg

Use native check-cfg lint in cargo beta

Split HolderCommitmentPoint::advance off into separate function

Merge pull request #3180 from tnull/2024-07-use-upstreamed-merkle-validation

Electrum: Use upstreamed `validate_merkle_proof`

Merge pull request #3172 from tnull/2024-07-revert-gossip-query-patch

Revert "Signal `GossipQuery` support when using `IgnoringMessagHandler`"

Use upstreamed `validate_merkle_proof`

We previously upstreamed the `validate_merkle_proof` utility method,
which shipped with `electrum-client` 0.19.0.

Since we upgraded to that version recently, we can now drop our local
code and use the upstreamed version.

Drop `lightning-background-processor/src/lib.rs` from exclusion list

We previously forgot to drop it (or it snuck back in during rebasing),
so we drop `lightning-background-processor` from the rustfmt exclusion
list.

`rustfmt`: Drop `lightning-custom-message/src/lib.rs` from excluded

.. files

`rustfmt`: Run on `lightning-block-sync/src/lib.rs`

`rustfmt`: Run on `lightning-block-sync/src/utils.rs`

`rustfmt`: Run on `lightning-block-sync/src/test_utils.rs`

`rustfmt`: Run on `lightning-block-sync/src/rpc.rs`

`rustfmt`: Run on `lightning-block-sync/src/rest.rs`

`rustfmt`: Run on `lightning-block-sync/src/poll.rs`

`rustfmt`: Run on `lightning-block-sync/src/init.rs`

`rustfmt`: Run on `lightning-block-sync/src/http.rs`

`rustfmt`: Run on `lightning-block-sync/src/gossip.rs`

Prepare `lightning-block-sync/src/gossip.rs`