Merge pull request #3397 from vincenzopalazzo/macros/amount-less-refactoring

[RFC] rename pay_parameters for no amount invoice

Merge pull request #3402 from tnull/2024-11-pin-indexmap

Pin `indexmap` back to account for `hashbrown` MSRV bump

Merge pull request #3399 from TheBlueMatt/2024-11-fuzz-assert

Drop broken debug assertion on peer buffer lengths

Merge pull request #3395 from mhrheaume/mhr/process_events_docs

Updated docs on `PeerManager::process_events`.

Pin `indexmap` back to account for `hashbrown` MSRV bump

`indexmap` 2.6.0 upgraded to `hashbrown` 0.15, which unfortunately
bumped their MSRV to rustc 1.65 with the 0.15.1 release. So we pin
`indexmap` to 2.5.0 to fix our MSRV CI.

Merge pull request #3388 from TheBlueMatt/2024-10-counter-test

Add additional test coverage of `NetworkGraph` counters

Merge pull request #3401 from tnull/2024-11-update-fuzz-readme

Update `fuzz` README to account for additional required `RUSTFLAGS`

Update `fuzz` README to account for additional required `RUSTFLAGS`

rename pay_parameters for no amount invoice

This commit renames the function `pay_parameters_for_zero_amount_invoice`
to `pay_parameters_for_variable_amount_invoice`.

The term "variable amount" is used to align with
the naming convention in the LDK node, helping to avoid
confusion between similar packages.

Fixes: https://github.com/lightningdevkit/rust-lightning/issues/2879
Replaces: https://github.com/lightningdevkit/rust-lightning/pull/2979
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Updated docs on `PeerManager::process_events`.

Try to make it a bit more clear that there are downsides to solely
relying on `lightning-net-tokio`, and it's still recommended to
occasionally call this function in a separate loop.

Merge pull request #3398 from vincenzopalazzo/macros/fixing-ci

ci: fixing the coverage report

Merge pull request #3394 from tnull/2024-11-pin-idna-adapter

Pin `idna_adapter` to fix MSRV

Merge pull request #3237 from jkczyz/2024-08-offers-experimental-tlvs

Experimental offer TLVs

Drop broken debug assertion on peer buffer lengths

1b711ed15f426ce40f1aa6be83d930a01ab530ba changed it so that we can
enqueue broadcast gossip messages to peers even though their buffer
is full as long as its our `ChannelMessageHandler` doing it. This
broke a debug assertion that the buffer isn't too large when
appending the broadcast message which is simply dropped here.

Found by the `full_stack_target` fuzzer.

ci: fixing the coverage report

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Refactor tuple serialization into a macro

Add parsing tests for experimental invoice TLVs

Parse experimental invoice TLV records

The BOLT12 spec defines an experimental TLV range that is allowed in
offer and invoice_request messages. The remaining TLV-space is for
experimental use in invoice messages. Allow this range when parsing an
invoice and include it when signing one.

Add parsing tests for experimental refund TLVs

Add parsing tests for experimental invreq TLVs

Test verification with experimental invreq TLVs

Payer metadata is generated from the invreq TLVs and should included
those in the experimental range. When verifying invoice messages, these
TLVs must be included. Modify the BOLT12 verification tests to cover
them.

Parse experimental invreq TLV records

The BOLT12 spec defines an experimental TLV range that are allowed in
invoice_request messages. Allow this range when parsing an invoice
request and include those bytes in any invoice. Also include those bytes
when verifying that a Bolt12Invoice is for a valid InvoiceRequest.

Add offer test vectors for experimental TLVs

Add parsing tests for experimental offer TLVs

Test verification with experimental offer TLVs

Offer metadata is generated from the offer TLVs and should included
those in the experimental range. When verifying invoice request and
invoice messages, these TLVs must be included. Similarly, OfferId
construction should included these TLVs as well. Modify the BOLT12
verification tests to cover these TLVs.

Parse experimental offer TLV records

The BOLT12 spec defines an experimental TLV range that are allowed in
offer messages. Allow this range when parsing an offer and include those
bytes in any invoice requests. Also include those bytes when computing
an OfferId and verifying that an InvoiceRequest is for a valid Offer.

Remove unnecessary destructure

Include experimental TLV records when verifying

Upcoming commits will allow parsing BOLT12 messages that include TLV
records in the experimental range. Include these ranges when verifying
messages since they will be included in the message bytes.

Pass bytes instead of TlvStream to verify

Passing bytes directly to InvoiceContents::verify improves readability
as then a TlvStream for each TLV record range can be created from the
bytes instead of needing to clone the TlvStream upfront. In an upcoming
commit, the experimental TLV record range will utilize this.

Function for iterating over Offer TLV records

Add a utility function for iterating over Offer TLV records contained in
any valid TLV stream bytes. Using a common function ensures that
experimental TLV records are included once they are supported.

Separate bytes for experimental TLVs

When constructing UnsignedInvoiceRequest or UnsignedBolt12Invoice, use a
separate field for experimental TLV bytes. This allows for properly
inserting the signature TLVs before the experimental TLVs when signing.

f Move pin to right place

Merge pull request #3360 from TheBlueMatt/2024-10-rebroadcast-chan-announcements

Re-broadcast `channel_announcement`s every six blocks for a week

Pin `idna_adapter` to fix MSRV

Merge pull request #3207 from valentinewallace/2024-07-invreq-in-onion

Include invoice requests in async payment onions

Merge pull request #3393 from tnull/2024-11-drop-dead-code

Drop dead code from `provide_latest_counterparty_commitment_tx`

Drop dead code from `provide_latest_counterparty_commitment_tx`

We drop some dead code that unnecessarily allocates a `Vec` but does
nothing else.

Fix outdated comment on PendingOutboundPayment::StaticInvoiceReceived

Factor invoice requests into payment path length limiting

Async payments include the original invoice request in the payment onion.
Since invreqs may include blinded paths, it's important to factor them into our
max path length calculations since they may take up a significant portion of
the 1300-byte onion.

Include invreq in payment onion when retrying async payments

While in the last commit we began including invoice requests in async payment
onions on initial send, further work is needed to include them on retry. Here
we begin storing invreqs in our retry data, and pass them along for inclusion
in the onion on payment retry.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Include invreq in payment onion when sending async payments

Past commits have set us up to include invoice requests in outbound async
payment onions. Here we actually pull the invoice request from where it's
stored in outbound_payments and pass it into the correct utility for inclusion
in the onion on initial send.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Store invreqs in StaticInvoiceReceived outbound payments

When transitioning outbound payments from AwaitingInvoice to
StaticInvoiceReceived, include the invreq in the new state's outbound payment
storage for future inclusion in an async payment onion.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Support including invreqs when paying to a route

Add a new invoice request parameter to outbound_payments and channelmanager
send-to-route internal utils. As of this commit the invreq will always be
passed in as None, to be updated in future commits.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Support including invreqs when building payment onions

Add a new invoice request parameter to onion_utils::create_payment_onion. As of
this commit it will always be passed in as None, to be updated in future
commits.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Support including invreqs when building onion payloads

Add a new invoice request parameter to onion_utils::build_onion_payloads.
As of this commit it will always be passed in as None, to be updated in future
commits.

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

Support encoding invreqs in outbound onion payloads

Per BOLTs PR 1149, when paying a static invoice we need to include our original
invoice request in the HTLC onion since the recipient wouldn't have received it
previously.

We use an experimental TLV type for this new onion payload field, since the
spec is still not merged in the BOLTs.

Stop taking &self in outbound_payments' create_inbound_payment

The method doesn't actually use its &self parameter, and this makes it more
obvious that we aren't going to deadlock by calling the method if the
outbound_payments lock is already acquired.

Prefix AsyncPaymentsMessageHandler methods with handle_*

"Release" is overloaded in the trait's release_pending_messages method, since
the latter releases pending async payments onion messages to the peer manager,
vs the release_held_htlc method handles the release_held_htlc onion message by
attempting to send an HTLC to the recipient.

Update docs for PaymentFailureReason::RouteNotFound

Since we started using this error in send_payment_for_bolt12_invoice, this
error type is no longer only used on retry but also on initial send.

Add new PaymentFailureReason::BlindedPathCreationFailed

RouteNotFound did not fit here because that error is reserved for failing to
find a route for a payment, whereas here we are failing to create a blinded
path back to ourselves..

Remove unneeded Eq and PartialEq derives

TlvRecord has a few fields, but comparing only the record_bytes is
sufficient for equality since the other fields are initialized from it.
Remove the Eq and PartialEq derives as they compare these other fields.

Add optional lifetime to tlv_stream macro

Using the tlv_stream macro without a type needing a reference results in
a compilation error because of an unused lifetime parameter. To avoid
this, add an optional lifetime parameter to the macro. This allows for
experimental TLVs, which will be empty initially, and TLVs of entirely
primitive types.

Add parsing tests for unknown BOLT12 TLVs

Add additional test coverage of `NetworkGraph` counters

This would have caught the bug fixed in 0c0cb6fccbb426924f21915053b
in our tests.

Suggested by @valentinewallace.

Re-broadcast `channel_announcement`s every six blocks for a week

When we first get a public channel confirmed at six blocks, we
broadcast a `channel_announcement` once and then move on. As long
as it makes it into our local network graph that should be okay, as
we should send peers our network graph contents as they seek to
sync, however its possible an ill-timed shutdown could cause this
to fail, and relying on peers to do a full historical sync from us
may delay `channel_announcement` propagation.

Instead, here, we re-broadcast our `channel_announcement`s every
six blocks for a week, which should be way more than robust enough
to get them properly across the P2P network.

Fixes #2418

Merge pull request #3367 from TheBlueMatt/2024-10-dense-counters

Don't bump the `next_node_counter` when using a removed counter

Merge pull request #3380 from optout21/channel-funding-tx-simple

[Splicing] Preserve funding_transaction for the later lifecycle of the channel, simple solution

Preserve funding_transaction for the later lifecycle of the channel, simple solution

Merge pull request #3385 from arik-so/gossip-filter-event-send-logging

Log enqueueing of gossip messages

Merge pull request #3322 from TheBlueMatt/2024-06-mpp-claim-without-man

Stop relying on ChannelMonitor persistence after manager read

Log enqueueing of gossip messages

Doc the on-upgrade `ChannelMonitor` startup persistence semantics

Because the new startup `ChannelMonitor` persistence semantics rely
on new information stored in `ChannelMonitor` only for claims made
in the upgraded code, users upgrading from previous version of LDK
must apply the old `ChannelMonitor` persistence semantics at least
once (as the old code will be used to handle partial claims).

Stop relying on `ChannelMonitor` persistence after manager read

When we discover we've only partially claimed an MPP HTLC during
`ChannelManager` reading, we need to add the payment preimage to
all other `ChannelMonitor`s that were a part of the payment.

We previously did this with a direct call on the `ChannelMonitor`,
requiring users write the full `ChannelMonitor` to disk to ensure
that updated information made it.

This adds quite a bit of delay during initial startup - fully
resilvering each `ChannelMonitor` just to handle this one case is
incredibly excessive.

Over the past few commits we dropped the need to pass HTLCs
directly to the `ChannelMonitor`s using the background events to
provide `ChannelMonitorUpdate`s insetad.

Thus, here we finally drop the requirement to resilver
`ChannelMonitor`s on startup.

Replay MPP claims via background events using new CM metadata

When we claim an MPP payment, then crash before persisting all the
relevant `ChannelMonitor`s, we rely on the payment data being
available in the `ChannelManager` on restart to re-claim any parts
that haven't yet been claimed. This is fine as long as the
`ChannelManager` was persisted before the `PaymentClaimable` event
was processed, which is generally the case in our
`lightning-background-processor`, but may not be in other cases or
in a somewhat rare race.

In order to fix this, we need to track where all the MPP parts of
a payment are in the `ChannelMonitor`, allowing us to re-claim any
missing pieces without reference to any `ChannelManager` data.

Further, in order to properly generate a `PaymentClaimed` event
against the re-started claim, we have to store various payment
metadata with the HTLC list as well.

Here we finally implement claiming using the new MPP part list and
metadata stored in `ChannelMonitor`s. In doing so, we use much more
of the existing HTLC-claiming pipeline in `ChannelManager`,
utilizing the on-startup background events flow as well as properly
re-applying the RAA-blockers to ensure preimages cannot be lost.

Handle duplicate payment claims during initialization

In the next commit we'll start using (much of) the normal HTLC
claim pipeline to replay payment claims on startup. In order to do
so, however, we have to properly handle cases where we get a
`DuplicateClaim` back from the channel for an inbound-payment HTLC.

Here we do so, handling the `MonitorUpdateCompletionAction` and
allowing an already-completed RAA blocker.

Move payment claim initialization to an fn on `ClaimablePayments`

Here we wrap the logic which moves claimable payments from
`claimable_payments` to `pending_claiming_payments` to a new
utility function on `ClaimablePayments`. This will allow us to call
this new logic during `ChannelManager` deserialization in a few
commits.

Move `ChannelManager`-read preimage relay to after struct build

In a coming commit we'll use the existing `ChannelManager` claim
flow to claim HTLCs which we found partially claimed on startup,
necessitating having a full `ChannelManager` when we go to do so.

Here we move the re-claim logic down in the `ChannelManager`-read
logic so that we have that.

Store info about claimed payments, incl HTLCs in `ChannelMonitor`s

When we claim an MPP payment, then crash before persisting all the
relevant `ChannelMonitor`s, we rely on the payment data being
available in the `ChannelManager` on restart to re-claim any parts
that haven't yet been claimed. This is fine as long as the
`ChannelManager` was persisted before the `PaymentClaimable` event
was processed, which is generally the case in our
`lightning-background-processor`, but may not be in other cases or
in a somewhat rare race.

In order to fix this, we need to track where all the MPP parts of
a payment are in the `ChannelMonitor`, allowing us to re-claim any
missing pieces without reference to any `ChannelManager` data.

Further, in order to properly generate a `PaymentClaimed` event
against the re-started claim, we have to store various payment
metadata with the HTLC list as well.

Here we store the required MPP parts and metadata in
`ChannelMonitor`s and make them available to `ChannelManager` on
load.

Pass info about claimed payments, incl HTLCs to `ChannelMonitor`s

When we claim an MPP payment, then crash before persisting all the
relevant `ChannelMonitor`s, we rely on the payment data being
available in the `ChannelManager` on restart to re-claim any parts
that haven't yet been claimed. This is fine as long as the
`ChannelManager` was persisted before the `PaymentClaimable` event
was processed, which is generally the case in our
`lightning-background-processor`, but may not be in other cases or
in a somewhat rare race.

In order to fix this, we need to track where all the MPP parts of
a payment are in the `ChannelMonitor`, allowing us to re-claim any
missing pieces without reference to any `ChannelManager` data.

Further, in order to properly generate a `PaymentClaimed` event
against the re-started claim, we have to store various payment
metadata with the HTLC list as well.

Here we take the first step, building a list of MPP parts and
metadata in `ChannelManager` and passing it through to
`ChannelMonitor` in the `ChannelMonitorUpdate`s.

Use a struct to track MPP parts pending claiming

When we started tracking which channels had MPP parts claimed
durably on-disk in their `ChannelMonitor`, we did so with a tuple.
This was fine in that it was only ever accessed in two places, but
as we will start tracking it through to the `ChannelMonitor`s
themselves in the coming commit(s), it is useful to have it in a
struct instead.

Fix unused warning in fuzz.

Merge pull request #3007 from arik-so/arik/trampoline/2024-04-trampoline-blinded-hop-serialization

Serialize blinded Trampoline hops

Test non-legacy blinded Trampoline payloads.

Add non-legacy blinded Trampoline payloads.

Test blinded Trampoline payload serialization.

Serialize blinded path forwards in Trampoline onions.

Add missing `inbound_payment_id_secret` write in `ChannelManager`

In aa09c33a1719944769ba98624bfe18ea33083f44 we added a new secret
in `ChannelManager` with which to derive inbound `PaymentId`s. We
added read support for the new field, but forgot to add writing
support for it. Here we fix this oversight.

Allow `clippy::unwrap-or-default` because its usually wrong

`or_default` is generally less readable than writing out the thing
we're writing, as `Default` is opaque but explicit constructors
generally are not. Thus, we ignore the clippy lint (ideally we
could invert it and ban the use of `Default` in the crate entirely
but alas).

Merge pull request #3379 from arik-so/exclude-windows-msrv

Skip MSRV on Windows in CI

Merge pull request #3142 from TheBlueMatt/2024-06-robust-updates

Reliably deliver gossip messages from our `ChannelMessageHandler`

Skip MSRV on Windows in CI

Merge pull request #3376 from yellowred/yellowred/monitor_update_name_pub

Make monitor update name public

Make monitor update name public

These structs are meant for MonitoringUpdatingPersister implementation, but some
external implementations may still reuse them, so going to make them public.

Merge pull request #3377 from G8XSU/hex-impls

Implement to_lower_hex() Display/Debug for PaymentId & OfferId

Merge pull request #3267 from arik-so/rgs_metrics_2024-08

Update RGS stats for August 2024.

Implement to_lower_hex() Display/Debug for OfferId.

Implement to_lower_hex() Display/Debug for PaymentId.

Update processing times for iPhone.

Update RGS stats for August 2024.

Merge pull request #3370 from dunxen/2024-10-dry-funding-created-signed

DRY `funding_created()` and `funding_signed()` for V1 channels

DRY `funding_created()` and `funding_signed()` for V1 channels

There is a decent amount of shared code in these two methods so we make
an attempt to share that code here by introducing the
`InitialRemoteCommitmentReceiver` trait. This trait will also come in
handy when we need similar commitment_signed handling behaviour for
dual-funded channels.

Merge pull request #3356 from jkczyz/2024-10-inflight-scoring

Don't over-penalize channels with inflight HTLCs

Use total_inflight_amount_msat for probability fns

Rename parameters used when calculating success probability to make it
clear that the total mount in-flight should be used rather than the
payment amount.

Correct comments in avoids_saturating_channels

Correct base_penalty_amount_multiplier_msat docs

Commit df52da7b31494c7ec77a705cca4c44bc840f8a95 modified
ProbabilisticScorer to apply some penalty amount multipliers to the
total amount flowing over the channel. However, the commit updated the
docs for base_penalty_amount_multiplier_msat even though that behavior
didn't change. This commit reverts those docs.

Don't over-penalize channels with inflight HTLCs

Commit df52da7b31494c7ec77a705cca4c44bc840f8a95 modified
ProbabilisticScorer to apply some penalty amount multipliers (e.g.,
liquidity_penalty_amount_multiplier_msat) to the total amount flowing
over the channel (i.e., including inflight HTLCs), not just the payment
in question. This led to over-penalizing in-use channels. Instead, only
apply the total amount when calculating success probability.

Merge pull request #3359 from TheBlueMatt/2024-10-less-types-re-export

Remove deprecated re-exports

Merge pull request #3297 from TheBlueMatt/2024-09-cleanup-package

Cleanup `PackageTemplate`a bit

Add a test for the fee-bump rate of timeout HTLC claims on cp txn

In a previous commit we updated the fee-bump-rate of claims against
HTLC timeouts on counterparty commitment transactions so that
instead of immediately attempting to bump every block we consider
the fact that we actually have at least `MIN_CLTV_EXPIRY_DELTA`
blocks to do so, and bumping at the appropriate rate given that.

Here we test that by adding an extra check to an existing test
that we do not bump in the very next block after the HTLC timeout
claim was initially broadcasted.

Set correct `counterparty_spendable_height` for outb local HTLCs

For outbound HTLCs, the counterparty can spend the output
immediately. This fixes the `counterparty_spendable_height` in the
`PackageTemplate` claiming outbound HTLCs on local commitment
transactions, which was previously spuriously set to the HTLC
timeout (at which point *we* can claim the HTLC).