Merge pull request #3156 from valentinewallace/2024-07-b12-max-path-len

Set max path length when paying BOLT 12 invoices.

Set max path length when paying BOLT 12 invoices.

Merge pull request #3158 from dunxen/2024-07-excludemergesfrommutants

Skip incremental-mutants job for main

Fix CI for unused `PendingOnionMessage`

Skip incremental-mutants job for main

There is no diff when running against main, so we skip incremental-mutants.
Before this commit, we'd get `Error: Failed to parse diff: Line 1: Error while parsing:`
as the diff file was empty.

Test router: support expecting blinded payment paths.

Remove spurious commented out code line.

Merge pull request #3154 from TheBlueMatt/2024-06-message-flags

Fix spelling in comment

Fix spelling in comment

From @valentinewallace at
https://github.com/lightningdevkit/rust-lightning/pull/3144#discussion_r1661404243

Merge pull request #3144 from TheBlueMatt/2024-06-message-flags

(Re-)add handling for `ChannelUpdate::message_flags`

Use `test_msg_exact` in `channl_update` fuzz testing

Gossip messages should always use `test_msg_exact` to ensure they
round-trip during signature validation.

(Re-)add handling for `ChannelUpdate::message_flags`

When the `htlc_maximum_msat` field was made mandatory in
`ChannelUpdate` (in b0e8b739b73cc25f3e1ab00695a14d972162a140) we
started ignoring the `message_flags` field entirely and always
writing `1`. The comment updates indicated that the `message_flags`
field was deprecated, but this is not true - only the
`htlc_maximum_msat` indicator bit was deprecated, requiring it to
be 1.

If a node creates a `channel_update` with `message_flags` bits set
other than the low bit, this will cause us to spuriously reject
the message with an invalid signature error as we will check the
message against the wrong hash.

With today's current spec this is totally fine - the only other bit
defined for `message_flags` is the `dont_forward` bit, which when
set indicates we shouldn't accept the message into our gossip store
anyway (though this may lead to spurious `warning` messages being
sent to peers). However, in the future this may mean we start
rejecting valid `channel_update`s if new bits are defiend.

Merge pull request #2763 from dunxen/2023-11-mutation-testing

Introduce mutation testing

Introduce basic incremental mutation testing

We introduce a CI job for mutation testing of PR diffs using cargo-mutants.
Missed cases do not trigger a fail of this job yet as we just introduce it
now for visibility. We may start enforcing stricter rules at a later stage.

Merge pull request #3129 from optout21/splicing-msgs-update

Update splice messages according to new spec draft

Merge pull request #3147 from TheBlueMatt/2024-06-feerate-overflow

Handle feerates of `u32::MAX` without overflowing

Merge pull request #2989 from optout21/iatx-shared-output

Interactive TX negotiation tracks shared outputs

Handle feerates of `u32::MAX` without overflowing

Though we generally shouldn't be seeing these, and the
`get_dust_buffer_feerate` implementation will still return
`u32::MAX` in spite of the overflow, we should handle the overflow
to avoid panic when `debug_assertions` are enabled.

Found by the `full_stack_target` fuzzer

Merge pull request #3145 from valentinewallace/2024-06-AP-prefactor-followup

Followups to #3125

Implement AsyncPaymentsMessageHandler for ChanMan and use everywhere

Dummy implementation for now. This avoids having to change a bunch of type
signatures in the future when we replace the dummy impl with a real one.

Onion message fuzzer: update held_htlc_available handling

Fuzzers should always do more, not less. Post-merge feedback on
e8f154dd3c299c7988762909df48b0c9d919d6f8.

Merge pull request #3125 from valentinewallace/2024-06-async-payments-prefactor

Async payments message encoding and prefactor

Update splice messages according to new spec draft

Cfg-gate async payments module and public enum variants.

Remove unused imports in static_invoice.rs

Add OffersMessage variant for static invoices.

DRY responder instantiation for onion messages.

AsyncPaymentsMessageHandler trait for OnionMessenger

Add a trait for handling async payments messages to OnionMessenger. This allows
users to either provide their own custom handling for async payments messages
or rely on a version provided by LDK.

Merge pull request #2966 from G8XSU/2647-distribute

Optimize ChannelMonitor persistence on block connections.

Interactive TX negotiation tracks shared outputs

Merge pull request #3127 from wvanlint/non_strict_forwarding

Implement non-strict forwarding

Onion message payload for async payments

Async payments uses onion messages to indicate when HTLCs are held and
released. Add these types along with the necessary parsing and encoding.

Merge pull request #3135 from tnull/2024-06-rustfmt-rgs

Run `rustfmt` on `lightning-rapid-gossip-sync`

`rustfmt`: Drop `benches/src/bench.rs` from excluded files

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

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

`rustfmt`: Prepare `lightning-rapid-gossip-sync/src/processing.rs`

Implement non-strict forwarding

This change implements non-strict forwarding, allowing the node to
forward an HTLC along a channel other than the one specified
by short_channel_id in the onion message, so long as the receiver has
the same node public key intended by short_channel_id
([BOLT](https://github.com/lightning/bolts/blob/57ce4b1e05c996fa649f00dc13521f6d496a288f/04-onion-routing.md#non-strict-forwarding)).
This can improve payment reliability when there are multiple channels
with the same peer e.g. when outbound liquidity is replenished by
opening a new channel.

The implemented forwarding strategy now chooses the channel with the
lowest outbound liquidity that can forward an HTLC to maximize the
probability of being able to successfully forward a subsequent HTLC.

Fixes #1278.

Merge pull request #3132 from jkczyz/2024-06-bolt12-unannounced

Blinded paths with unannounced introduction nodes

Optimize ChannelMonitor persistence on block connections.

Currently, every block connection triggers the persistence of all
ChannelMonitors with an updated best_block. This approach poses
challenges for large node operators managing thousands of channels.
Furthermore, it leads to a thundering herd problem
(https://en.wikipedia.org/wiki/Thundering_herd_problem), overwhelming
the storage with simultaneous requests.

To address this issue, we now persist ChannelMonitors at a
regular cadence, spreading their persistence across blocks to
mitigate spikes in write operations.

Outcome: After doing this, Ldk's IO footprint should be reduced
by ~50 times. The processing time required to sync each block
will be significantly reduced, particularly for nodes with 1000s
of channels, as write latency plays a significant role in this process.
As a result, the Node/ChainMonitor will be blocked for a shorter
duration, leading to further efficiency gains.

Merge pull request #3126 from TheBlueMatt/2024-06-preimage-removal-blocked-by-claim-event

(Very) marginally expand `test_monitor_update_fail_claim`

(Very) marginally expand `test_monitor_update_fail_claim`

For some reason I wasn't sure this happened yet, so making the
test for no-`PaymentClaimed`-event-before-preimage-on-disk explicit
is nice.

Merge pull request #3115 from alecchendev/2024-06-specific-async-sign

Refactor async signing test utils to toggle specific method availability

Relax channel count check for unannounced nodes

When creating blinded paths, introduction nodes are limited to peers
with at least three channels to prevent easily guessing the recipient.
Relax this check when the recipient is unannounced since they won't be
in the NetworkGraph.

Advance self blinded payment paths

DefaultRouter will ignore blinded paths where the sender is the
introduction node. Similar to message paths, advance such paths by one
so that payments may be sent to them.

Re-order imports

Rename variable

Add advance_path_by_one for blinded payment paths

Similar to blinded paths for onion messages, if given a blinded payment
path where we are the introduction node, the path must be advanced by
one in order to use it.

Don't modify path when advance_path_by_one errors

When using advance_path_by_one when we are the introduction node, any
error will result having the first hop of the input blinded path
removed. Instead, only remove the first hop on success. Otherwise, the
path will be invalid.

Blinded payments to unannounced introduction node

When creating blinded paths for receiving onion payments, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending payments without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.

BlindedPath with unannounced introduction node

When creating blinded paths for receiving onion messages, allow using
the recipient's only peer as the introduction node when the recipient is
unannounced. This allows for sending messages without going through an
intermediary, which is useful for testing or when only connected to an
LSP with an empty NetworkGraph.

Merge pull request #3130 from TheBlueMatt/2024-06-doc-fee-present

Document when `Events::PaymentSent::pending_fee_msat` is `Some`

Remove global availability logic for testing async signing

Refactor tests to use specific async signing ops

Allow toggling specific signing methods in test channel signer

Start tracking chain_sync_monitor_persistences in TestPersister

It is helpful to assert that chain-sync did trigger a monitor
persist.

Merge pull request #3128 from TheBlueMatt/2024-06-no-claim-ret

Drop unused return value from `claim_funds_from_hop`

Document when `Events::PaymentSent::pending_fee_msat` is `Some`

Merge pull request #3123 from dunxen/2024-06-channelrefactor

Move accept_channel checks into `ChannelContext::do_accept_channel_checks`

Drop unused return value from `claim_funds_from_hop`

Move accept_channel checks into `ChannelContext::do_accept_channel_checks`

This is done ahead of getting the dual-funding implementation to reduce
refactoring noise there.

ser_macros: support messages with no fields

Merge pull request #3102 from tnull/2024-06-rustfmt-fuzz

`rustfmt`: Reformat the `fuzz` dir

Merge pull request #3098 from arik-so/arik/gossip-v2-parsing

Parse v2 gossip

Merge pull request #3078 from jkczyz/2024-05-invoice-event

Asynchronous `Bolt12Invoice` payment

Update documentation.

Parse v2 gossip.

Add pays_bolt12_invoice_asynchronously test

Expose send_payment_for_bolt12_invoice

UserConfig::manually_handle_bolt12_invoices allows deferring payment of
BOLT12 invoices by generating Event::InvoiceReceived. Expose
ChannelManager::send_payment_for_bolt12_invoice to allow users to pay
the Bolt12Invoice included in the event. While the event contains the
PaymentId for reference, that parameter is now removed from the method
in favor of extracting the PaymentId from the invoice's payer_metadata.

Reformat and tick config docs

Add UserConfig::manually_handle_bolt12_invoices

BOLT12 invoices are automatically paid once they have been verified.
Users may want to manually pay them by first performing additional
checks. Add a manually_handle_bolt12_invoices configuration option that
when set generates an Event::InvoiceReceived instead of paying the
invoice.

Merge pull request #3082 from valentinewallace/2024-04-bolt12-keysend-invoice

BOLT 12 static invoice encoding and building

Merge pull request #3103 from TheBlueMatt/2024-06-real-bench

Use a real (probing-generated) scorer in benchmarks

Static invoice parsing tests

Static invoice building tests

Builder for creating static invoices from offers

Add a builder for creating static invoices for an offer. Building produces a
semantically valid static invoice for the offer, which can then be signed with
the key associated with the offer's signing pubkey.

Add an InvoiceReceived event

Some users may want to handle a Bolt12Invoice asynchronously, either in
a different process or by first performing additional verification
before paying the invoice. Add an InvoiceReceived event to facilitate
this.

`rustfmt`: `fuzz/src/full_stack.rs`

Prepare `fuzz/src/full_stack.rs` for `rustfmt`

`rustfmt`: `fuzz/src/chanmon_consistency.rs`

Introduce `noret` wrappers

Drop unnecessary key derivation in route tests

In our route tests we need some "random" bytes for the router to
randomize amounts using. We generate this by building an actual
`KeysManager` and then deriving some random bytes using the
`EntropySource` trait. However, `get_route` (what we're normally
testing) doesn't actually use the random bytes, and even if it did,
using a `KeysManager` is just a fancy way of creating a constant,
so there's really no reason to do all the fancy crypto.

Instead, here, we change our routing tests and benchmarks to simply
use `[42; 32]` as the "random" bytes.

Push the route benchmark results into a separate uninlined function

This ensures the route benchmarks themselves will appear with a
distinct callgraph, making router profiling somewhat easier.

Use a real (probing-generated) scorer in benchmarks

Until now, our routing benchmarks used a synthetic scorer,
generated by scoring random paths to build up some history. This is
pretty far removed from real-world routing conditions, as
alternative paths generally have no scoring information and even
the paths we do take have only one or two past scoring results.

Instead, we fetch a static serialized scorer, generated using
minutely probes. This means future changes to the scorer's data may
be harder to benchmark, but makes for substantially more realistic
benchmarks for changes which don't impact the serialized state.

Static invoice encoding and parsing

Define an interface for BOLT 12 static invoice messages. The underlying
format consists of the original bytes and the parsed contents.

The bytes are later needed for serialization. This is because it must
mirror all the offer TLV records, including unknown ones, which aren't
represented in the contents.

Invoices may be created from an offer.

Merge pull request #3116 from TheBlueMatt/2024-06-3107-nit

Clarify `Display` text for `ClosureReason::HolderForceClosed` some

Prepare `chanmon_consistency.rs` for `rustfmt`

Merge pull request #3113 from TheBlueMatt/2024-04-async-monitor-fuzz

Fuzz reloading with a stale monitor in chanmon_consistency

Unblock channels awaiting monitor update based on `ChanMan` queue

When we have `ChannelMonitorUpdate`s which are completing both
synchronously and asynchronously, we need to consider a channel as
unblocked based on the `ChannelManager` monitor update queue,
rather than by checking the `update_id`s.

Consider the case where a channel is updated, leading to a
`ChannelMonitorUpdate` which completes asynchronously. The update
completes, but prior to the `ChannelManager` receiving the
`MonitorEvent::Completed` it generates a further
`ChannelMonitorUpdate`. This second update completes synchronously.
As a result, when the `MonitorEvent` is processed, the event's
`monitor_update_id` is the first update, but there are no updates
queued and the channel should be free to return to be unblocked.

Here we fix this by looking only at the `ChannelManager` update
queue, rather than the update_id of the `MonitorEvent`.

While we don't anticipate many users having both synchronous and
asynchronous persists in the same application, there isn't much
cost to supporting it, which we do here.

Found by the chanmon_consistency target.

Fuzz reloading with a stale monitor in chanmon_consistency

Now that we are gearing up to support fully async monitor storage,
we really need to fuzz monitor updates not completing before a
reload, which we do here in the `chanmon_consistency` fuzzer.

While there are more parts to async monitor updating that we need
to fuzz, this at least gets us started by having basic async
restart cases handled. In the future, we should extend this to make
sure some basic properties (eg claim/balance consistency) remain
true through `chanmon_consistency` runs.

InvoiceTlvStream{Ref}: add message_paths field

Will be used in static invoices. Also test that we'll fail to decode if these
paths are included in single-use BOLT 12 invoices.

Clarify `Display` text for `ClosureReason::HolderForceClosed` some

... to make it clear that we elected not to broadcast, rather than
failed to broadcast.

Merge pull request #3107 from mhrheaume/mhr/closure_reason_abandoned

Updated `ClosureReason::HolderForceClosed` with whether txn was broadcasted.

Use ? instead of matching in BOLT 12 invoice parsing.

Minor cleanup to be more concise.

BOLT 12 invoice: extract helper for invoice signing pubkey checks

Will be useful for static invoices.

BOLT 12 invoice: expose common helper methods and fields

Useful for static invoice support.

Genericize BOLT 12 invoice{_builder} common macro docs over invoice type

Will be useful so the docs generated work for static invoices.

Implement Readable for Responder

A future InvoiceReceived event will include a Responder. Since Event
implements Readable, so must Responder.

Implement Readable for Bolt12Invoice

A future InvoiceReceived event will include a Bolt12Invoice. Since Event
implements Readable, so must Bolt12Invoice.

Re-order imports in events module