Merge pull request #3313 from valentinewallace/2024-09-fix-offer-double-pay

Don't pay a duplicate BOLT 12 invoice if `ChannelManager` is stale

Merge pull request #3218 from jkczyz/2024-07-offers-spec-update

Rename `Offer::signing_pubkey` to `Offer::issuer_id`

Fix bug where we double-pay an offer due to stale manager

This fixes the following bug:
- An outbound payment is AwaitingInvoice
- We receive an invoice and lock the HTLCs into the relevant ChannelMonitors
- The monitors are successfully persisted, but the ChannelManager fails to
  persist, so the outbound payment remains AwaitingInvoice
- We restart, causing the channels to close due to a stale ChannelManager
- We receive a duplicate invoice, and attempt to pay it again due to the
  payment still being AwaitingInvoice in the stale ChannelManager

After the fix for this, we will notice that the payment is already locked into
the monitor on startup and transition the incorrectly-AwaitingInvoice payment
to Retryable, which prevents double-paying on duplicate invoice receipt.

Rename Refund::payer_id

For consistency with Offer::issuer_signing_pubkey, rename
Refund::payer_id to use "signing_pubkey" instead of "id".

Rename InvoiceRequest::payer_id

For consistency with Offer::issuer_signing_pubkey, rename
InvoiceRequest::payer_id to use "signing_pubkey" instead of "id".

Update offer test vectors from latest spec changes

Use unsigned invoice types in docs

Add issuer_signing_pubkey to Bolt12Invoice

Useful for determining if the signing_pubkey is the
issuer_signing_pubkey or is from a blinded path.

Re-write Offer::issuer_signing_pubkey documentation

Rename Offer::signing_pubkey to Offer::issuer_signing_pubkey

The spec was recently changed to use offer_issuer_id instead of
offer_node_id. LDK always used signing_pubkey to avoid confusion with a
node_id. Rename it to issuer_signing_pubkey now as InvoiceRequest and
Bolt12Invoice will have similarly named methods in upcoming commits.

Move monitor<>outbound_payments startup htlc syncing code.

Move the code that ensures that HTLCs locked into ChannelMonitors are
synchronized with the ChannelManager's OutboundPayments store to the
outbound_payments module.

This is useful both because ChannelManager::read is very long/confusing method,
so it's nice to encapsulate some of its functionality, and because we need to
fix an existing bug in this logic where we may risk double-paying an offer due
to outbound_payments being stale on startup. See the next commit for this
bugfix.

Test utils: use full import path in reload_node macro.

Merge pull request #3315 from tnull/2024-09-rustfmt-crypto

`rustfmt`: Run on `crypto` module

`rustfmt`: Drop `crypto/mod.rs` from exclusion list

`rustfmt`: Run on `crypto/mod.rs`

`rustfmt`: Drop `crypto/utils.rs` from exclusion list

`rustfmt`: Run on `crypto/utils.rs`

`rustfmt`: Drop `crypto/streams.rs` from exclusion list

`rustfmt`: Run on `crypto/streams.rs`

`rustfmt`: Drop `crypto/poly1305.rs` from exclusion list

`rustfmt`: Run on `crypto/poly1305.rs`

`rustfmt`: Drop `crypto/chacha20poly1305.rs` from exclusion list

`rustfmt`: Run on `crypto/chacha20poly1305rfc.rs`

`rustfmt`: Drop `crypto/chacha20.rs` from exclusion list

`rustfmt`: Run on `crypto/chacha20.rs`

Merge pull request #3314 from G8XSU/event-logging

Add logging around event processing.

Merge pull request #3140 from valentinewallace/2024-06-pay-static-invoice

Support paying static invoices

Add logging around event processing.

Currently we don't have any visibility if BackgroundProcessor
takes considerably more of time to process events, adding logs
to help debug such issues.

Remove payment_release_secret from async payments messages.

This field isn't necessary because we already authenticate the messages via the
blinded reply paths payment_id, nonce and HMAC.

Document PendingOutboundPayment::{Static}InvoiceReceived semantics.

While these variants may sound similar, they are very different. One is so
temporary it's never even persisted to disk, the other is a state we will stay
in for hours or days. See added docs for more info.

Add new Bolt12PaymentError for failed blinded path creation.

Currently used when initiating an async payment via held_htlc_available OM. This
OM needs a reply path back to us, so use this error for our invoice_error OM if
we fail to create said reply path.

Verify inbound ReleaseHeldHtlc messages via hmac.

See AsyncPaymentsContext::hmac, but this prevents the recipient from
deanonymizing us. Without this, if they are able to guess the correct payment
id, then they could create a blinded path to us and confirm our identity.

We also move the PAYMENT_HASH_HMAC_INPUT const to use &[7; 16], which is safe
because this const was added since the last release. This ordering reads more
smoothly.

Rename Payment{Hash,Id} hmac creation/verification methods for offers.

We want to specify that these methods are only to be used in an outbound offers
payment context, because we'll be adding similar methods for the outbound async
payments context in upcoming commits.

Don't trigger manager persistence on unexpected release_htlc message.

If someone sends us an unexpected or duplicate release_held_htlc onion message,
we should simply ignore it and not persist the entire ChannelManager in
response.

Correct docs on payment id in RecentPaymentDetails.

Support abandoning pending outbound async payments.

Async payments may have very high expires because we may be waiting for days
for the recipient to come online, so it's important that users be able to
abandon these payments early if needed.

Timeout expired outbound async payments.

Support sending async payments as an always-online sender.

Async receive is not yet supported.

Here we process inbound release_htlc onion messages, check that they actually
correspond to one of our outbound payments, and actually forward the HTLCs.
Valid release_htlc receipt indicates that the recipient has now come online to
receive.

Split off send_payment_for_bolt12_invoice_internal util.

This new util will be able to send to both static and non-static BOLT 12
invoices.

Set max path len on receipt of static invoice.

Because we may receive a static invoice to pay days before the recipient
actually comes back online to receive the payment, it's good to do as many
checks as we can up-front. Here we ensure that the blinded paths provided
in the invoice won't cause us to exceed the maximum onion packet size.

Error on static invoice with unknown required features.

DRY handling when initiating payment to BOLT 12 invoice.

Support initiating an async payment to a static invoice.

Supported when the sender is an always-online node. Here we send the initial
held_htlc_available onion message upon receipt of a static invoice, next we'll
need to actually send HTLCs upon getting a response to said OM.

Release pending async payments to PeerManager.

Pass full message context into ChanMan blinded path util.

Allows us to repurpose this util to create blinded paths in an async payments
message context while maintaining support for the offers context.

Store async payment data in PendingOutboundPayment.

Adds a pending outbound payment variant for async payments, which indicates
that we have received a static invoice to pay and have generated a keysend preimage
for the eventual payment. When the recipient comes back online, we'll
transition from this new state to Retryable and actually forward the HTLCs.

Support creating PaymentParameters from static invoices.

Support checking that a static invoice matches an outbound invreq.

Useful for ensuring that an inbound static invoice matches one of our outbound
invreqs, otherwise it is an unexpected invoice and should be ignored and not
paid.

Merge pull request #3243 from dunxen/2024-08-reremove-balancemsat

Remove AvailableBalances::balance_msat

Merge pull request #3302 from TheBlueMatt/2024-09-atomic-cleanups

Simplify and fix AtomicCounter

Store AsyncPaymentsMessages for later sending

Upcoming commits will support sending and receiving held_htlc_available and
release_held_htlc messages. These messages need to be enqueued so that they can
be released in ChannelManager's implementation of AsyncPaymentsMessageHandler
to OnionMessenger for sending.

Pass context into held_htlc_available message handling.

Useful for using the payment_id within to look up the corresponding outbound
async payment so we know we can safely release the HTLCs to the now-onlinen
recipient.

Add MessageContext for async payments.

This context will be used in reply paths for outbound held_htlc_available
messages, so we can authenticate the corresponding release_held_htlc messages.

Tweak debug_assert message for parsed onion messages.

More specific.

Merge pull request #3010 from shaavan/issue2836

Introduce Retry InvoiceRequest Flow

Rename `AtomicCounter::get_increment` to simply `next`

Its a counter, `next` is super clear, `get_increment` is a bit
less so.

Simplify and fix `AtomicCounter`

`AtomicCounter` was slightly race-y on 32-bit platforms because it
increments the high `AtomicUsize` independently from the low
`AtomicUsize`, leading to a potential race where another thread
could observe the low increment but not the high increment and see
a value of 0 twice.

This isn't a big deal because (a) most platforms are 64-bit these
days, (b) 32-bit platforms aren't super likely to have their
counter overflow 32 bits anyway, and (c) the two writes are
back-to-back so having another thread read during that window is
very unlikely.

However, we can also optimize the counter somewhat by using the
`target_has_atomic = "64"` cfg flag, which we do here, allowing us
to use `AtomicU64` even on 32-bit platforms where 64-bit atomics
are available.

This changes some test behavior slightly, which requires
adaptation.

Fixes #3000

Introduce handle_message_received test

- Add a test to verify the functionality of the handle_message_received
  function.
- Ensure the test covers scenarios where InvoiceRequest messages are retried
  for PendingOutboundPayments after a simulated connection loss.

Introduce message_received in ChannelMessageHandler

- Introduce the `message_received` function to manage the
  behavior when a message is received from any peer.
- This function is used within `ChannelManager` to retry `InvoiceRequest`
  messages if we haven't received the corresponding invoice yet.
- This change makes the offer communication robust against sudden
  connection drops where the initial attempt to send the message
  might have failed.

Introduce enqueue_invoice_request Function

1. Separate the logic of forming `invoice_request` messages from
   `invoice_request` and `reply_paths` and enqueueing them into a
   separate function.
2. This logic will be reused in the following commit when reforming
   `invoice_request` messages for retrying.

Introduce RetryableInvoiceRequest in AwaitingInvoice

1. To enable the retry of the Invoice Request message, it's necessary
   to store the essential data required to recreate the message.
2. A new struct is introduced to manage this data, ensuring the
   InvoiceRequest message can be reliably recreated for retries.
3. The addition of an `awaiting_invoice` flag allows tracking of
   retryable invoice requests, preventing the need to lock the
   `pending_outbound_payment` mutex.

Merge pull request #3291 from tnull/2024-09-add-their-node-id-routing-msg-handler

Add node id to remaining `RoutingMessageHandler::handle_` methods

Merge pull request #3163 from shaavan/invoice_reply_path

Introduce Reply Paths for BOLT12 Invoice in Offers Flow.

Don't rely on route-fetching rand in `blinded_path_with_custom_tlv`

`blinded_path_with_custom_tlv` indirectly relied on route CLTV
randomization when sending because nodes were at substantially
different block heights after setup. Instead we make sure all nodes
are at the same height which makes the test more robust.

Drop `Debug` on `InMemorySigner` (and `EntropySource`)

`InMemorySigner` has various private keys in it which makes
`Debug` either useless or dangerous (because most keys won't log
anything, but if they did we'd risk logging private key material).

Refactor: Take `their_node_id` by value across all handler interfaces

In order to maintain interface consistency, we refactor all message
handler interfaces to take `PublicKey` rather than `&PublicKey`, as the
difference in efficiency should be negigible and the former is easier to
handle in binding languages.

Over time, we also want to move (no pun intended) towards all messaging
interfaces using move semantics, so dropping the reference for
`PublicKey` is the first step in this direction.

Add node id to remaining `RoutingMessageHandler::handle_` methods

Previously, some `RoutingMessageHandler::handle_` methods (in particular
the ones handling node and channel announcements, as well as channel
updates, omitted the `their_node_id` argument. This didn't allow
implementors to discern *who* sent a particular method.

Here, we add `their_node_id: Option<&PublicKey>` to have them learn who
sent a message, and set `None` if our own node it the originator of a
broadcast operation.

Update Offers Test to Verify BOLT12 Invoice Reply Paths

1. Updated the Offers Test to check the reply paths in BOLT12 Invoices.
2. Changed the `extract_invoice` return type from `Option<BlindedMessagePath>`
   to `BlindedMessagePath` since all BOLT12Invoices now have a corresponding
   reply path by default.

Add reply_path to BOLT12Invoices in Offers Flow

1. Introduced reply_path in BOLT12Invoices to address a gap in error handling.
   Previously, if a BOLT12Invoice sent in the offers flow generated an Invoice Error,
   the payer had no way to send this error back to the payee.
2. By adding a reply_path to the Invoice Message, the payer can now communicate
   any errors back to the payee, ensuring better error handling and communication
   within the offers flow.

Add HMAC, and nonce to OffersContext::InboundPayment

Introduce HMAC and nonce calculation when sending Invoice with
reply path, so that if we receive InvoiceError back for the
corresponding Invoice we can verify the payment hash before logging it.

Merge pull request #3309 from TheBlueMatt/2024-09-always-print-why

Always print why we disconnect explicitly

Merge pull request #3305 from TheBlueMatt/2024-09-no-redundant-gossip-validation

Avoid redundant `{channel,node}_announcement` signature checks

Always print why we disconnect explicitly

...and drop the old, confusing, "protocol error" message when we
get a duplicate connection from a peer.

This should slightly further disambiguate disconnection reasons,
which are a key debugging tool for assigning blame.

Merge pull request #3306 from TheBlueMatt/2024-09-chan-id-hex

Write ChannelIds out as hex in Debug output

Introduce Verification trait.

- The trait defines the public method one may define for creating and
  verifying the HMAC.
- Using a pub trait to define these method allows the flexibility for
  other `OffersMessageHandler` construct to construct the HMAC and
authenticate the message.

Merge pull request #3296 from alecchendev/2024-09-async-close-sign-followup

Finish closing channel after async closing signed

Avoid redundant `{channel,node}_announcement` signature checks

If we receive `{channel,node}_announcement` messages which we
already have, we first validate their signatures and then look in
our graph and discover that we should discard the messages. This
avoids a second lock in `node_announcement` handling but does not
impact our locking in `channel_announcement` handling. It also
avoids lock contention in cases where the signatures are invalid,
but that should be exceedingly rare.

For nodes with relatively few peers, this is a fine state to be in,
however for nodes with many peers, we may see the same messages
hundreds of times. This causes a rather substantial waste of CPU
resources validating gossip messages.

Instead, here, we change to checking our network graph first and
then validate the signatures only if we don't already have the
message.

Remove AvailableBalances::balance_msat

The ChannelMonitor::get_claimable_balances and ChainMonitor::get_claimable_balances
methods provide a more straightforward approach to the balance of a channel, which
satisfies most use cases. The computation of AvailableBalances::balance_msat is
complex and originally had a different purpose that is not applicable
anymore.

Co-authored-by: Willem Van Lint <noreply@wvanlint.dev>

Finish closing channel after async closing signed

In addressing a followup to test reconnection during closing negotation
with async signing, we change things to only return a `ShutdownResult`
when we actually finish shutting down the channel, i.e. we have the
signature ready to send the final closing signed. This slightly
simplifies the logic where we would shutdown our channel
prematurely before we got the final signature. This also means
that we don't push multiple `ChannelClosed` events if we receive closing
signed, reconnect, and receive closing signed again.

Clean up imports in `lightning-types`

To remove the now-redundant `hex_conservative` explicit dependency.

Write `ChannelId`s out as hex in `Debug` output

`ChannelId`s are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for `Display`.

This uses the `hex_conservative` `impl_fmt_macros` which does all
the work for us, like we use for `lightning_types`.

impl `Borrow<[u8]>` for `ChannelId`

We do this for `Payment*` in `lightning-types` and its needed for
the `hex_conservaitve` `impl_fmt_traits` macro which we'll use in
the next commit.

Merge pull request #3304 from TheBlueMatt/2024-09-tokio-util-msrv

Fix MSRV builds of `lightning-transaction-sync` in CI

Reduce features on `lightning-transaction-sync`'s `tokio` dev-dep

This should marginally reduce the chance of MSRV or other issues in
the future, and is just good practice.

Test `lightning-transaction-sync` in our no-dev-deps MSRV test

Now that `lightning-transaction-sync` is in the workspace and
covered by our MSRV we should be testing it in our
`msrv-no-dev-deps-check` test crate.

Fix MSRV test of `lightning-transaction-sync` with `esplora-async`

`lightning-transaction-sync`'s `esplora-async` dependency
indirectly depends on `tokio-util`, which, like tokio, recently
bumped its MSRV.

Here we update `ci/ci-tests.sh` to pin `tokio-util` to make MSRV
builds pass.

HMAC Construction and Verification for PaymentHash

When a InvoiceError is received for a sent BOLT12Invoice, the
corresponding PaymentHash is to be logged. Introduce hmac construction
and verification function for PaymentHash for this purpose.

Merge pull request #3290 from tnull/2024-09-add-tx-sync-copyright

Add copyright notices to `lightning-transaction-sync` modules

Add copyright notices to `lightning-transaction-sync` modules

Merge pull request #3278 from TheBlueMatt/2024-08-124-relnotes

Add an 0.0.124 CHANGELOG entry

Update versions to 0.0.124 and invoice 0.32 types 0.1 release

Add an 0.0.124 CHANGELOG entry

Merge pull request #3285 from TheBlueMatt/2024-08-tx-too-small

Correct handling of added `OP_RETURN` outputs

Merge pull request #3284 from TheBlueMatt/2024-08-bindings-imports-suck

Correct `ANCHOR_INPUT_WITNESS_WEIGHT` constant

`ANCHOR_INPUT_WITNESS_WEIGHT` is too high by two weight units,
likely it was calculated to include the SegWit marker bytes, but
it is used to describe an `Input::satisfaction_weight`, which does
not expect the marker bytes.

This corrects that oversight, reducing the constant by two and
adding the marker bytes back in our own internal weight
calculations. It also fixes a second issue where the constant was
too low by one when `grind_signatures` is not set, as that may
result in a signature being one byte longer than we expect.

Add a test for the past few commits

This adds a single test for coin selection which exercises the
issues fixed in the past three commits.

Drop bogus debug assertion that we don't overpay on fees

We should always select at least as many coins as is required to
meet the feerate target, but its perfectly fine if we overshoot.
Specifically, we may overshoot deliberately if we choose to burn
change to fee instead.

Handle under-coin-selecting due to an added OP_RETURN output

When we do coin selection for channel close anchor spends, we may
do coin selection targeting exactly the input values we need.
However, if coin selection does not include a change output, we may
add an OP_RETURN output, which may cause us to end up with less
fee than we wanted on the resulting package.

Here we address this issue by running coin selection twice - first
without seeking the extra weight of the OP_RETURN output, and again
if we find that we under-selected.

Ensure we never try to broadcast a transaction <= 64 bytes

While these are consensus-valid, they have been nonstandard for
quite some time and will not relay nor confirm.

Specify imports manually in `types::features::sealed`

There's not a lot of reason to do this, but sadly the bindings
don't currently resolve wildcard imports at all, and I don't want
to deal with implementing it right now.