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.
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.
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.
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.
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.
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.
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.
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.
`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.
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.
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.
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`.
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).
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.
In cc78b77c71 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.
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.
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.
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.
