Merge pull request #3283 from TheBlueMatt/2024-07-human-readable-names-resolution

Support paying directly to Human Readable Names using bLIP 32

Set the `dns_resolution` feature in `OMDomainResolver`

`OMDomainResolver` actually does support building DNSSECProofs, so
should be setting the `dns_resolution` `NodeFeature` flag.

Add a `lightning-dns-resolver` crate which answers bLIP 32 queries

When a lightning node wishes to send payments to a BIP 353 human
readable name (using BOLT 12), it first has to resolve that name to
a DNS TXT record. bLIP 32 defines a way to do so over onion
messages, and this completes our implementation thereof by adding
the server side.

It operates by simply accepting new messages and spawning tokio
tasks to do DNS lookups using the `dnsse_prover` crate. It also
contains full end-to-end tests of the BIP 353 -> BOLT 12 -> payment
logic using the new server code to do the resolution.

Note that because we now have a workspace crate which sets the
"lightning/dnssec" feature in its `dev-dependencies`, a naive
`cargo test` will test the "dnssec" feature.

Use `ChannelManager` as `DNSResolverMessageHandler` by default

Now that `ChannelManager` supports using bLIP 32 to resolve BIP 353
Human Readable Names we should encourage users to use that feature
by making the "default" (in various type aliases) to use
`ChannelManager` as the `DNSResolverMessageHandler`.

Support paying Human Readable Names directly from `ChannelManager`

Now that we have the ability to resolve BIP 353 Human Readable
Names directly and have tracking for outbound payments waiting on
an offer resolution, we can implement full BIP 353 support in
`ChannelManager`.

Users will need one or more known nodes which offer DNS resolution
service over onion messages using bLIP 32, which they pass to
`ChannelManager::pay_for_offer_from_human_readable_name`, as well
as the `HumanReadableName` itself.

From there, `ChannelManager` asks the DNS resolver to provide a
DNSSEC proof, which it verifies, parses into an `Offer`, and then
pays.

For those who wish to support on-chain fallbacks, sadly, this will
not work, and they'll still have to use `OMNameResolver` directly
in order to use their existing `bitcoin:` URI parsing.

Store the source `HumanReadableName` in `InvoiceRequestFields`

When we receive a payment to an offer we issued resolved with a
human readable name, it may have been resolved using a wildcard
DNS entry which we want to map to a specific recipient account
locally. To do this, we need the human readable name from the
`InvoiceRequest` in the `PaymentClaim{able,ed}`, which we pipe
through here using `InvoiceRequestFields`.

Add support for storing a source HRN in BOLT 12 `invoice_request`s

When we resolve a Human Readable Name to a BOLT 12 `offer`, we may
end up resolving to a wildcard DNS name covering all possible
`user` parts. In that case, if we just blindly pay the `offer`, the
recipient would have no way to tell which `user` we paid.

Instead, BOLT 12 defines a field to include the HRN resolved in the
`invoice_request`, which we implement here.

We also take this opportunity to remove constant parameters from
the `outbound_payment.rs` interface to `channelmanager.rs`

Add a new `AwaitingOffer` outbound payment state for BIP 353

Skip the implicit trailing `.` in `HumanReadableName`'s domain

Domain names implicitly have a trailing `.`, which we require in
bLIP 32 but generally shouldn't be exposing to the user in
`HumanReadableName`s (after all, they're human-readable). Here we
make sure the trailing `.` is dropped in `HumanReadableName`s
before we re-add them when building the bLIP 32 messages.

Merge pull request #3383 from valentinewallace/2024-09-blinded-keysend-verify

Verify blinded keysend payments

Merge pull request #3389 from jkczyz/2024-10-bolt11-invoice-utils

Add `ChannelManager::create_bolt11_invoice`

Verify blinded keysend payment secrets

If we're receiving a keysend to a blinded path, then we created the payment
secret within. Using our inbound_payment_key, we can decrypt the payment secret
bytes to get the payment's min_cltv_expiry_delta and min amount, to verify the
payment is valid. However, if we're receiving an MPP keysend *not* to a blinded
path, then we did not create the payment secret and shouldn't verify it since
it's only used to correlate MPP parts.

Therefore, store whether the payment secret is recipient-generated in our pending
inbound payment data so we know whether to verify it or not.

Update BOLT11 docs in ChannelManager

Update ChannelManager docs to use create_bolt11_invoice and correct
references to modules in the lightning-invoice crate that no longer
exist.

Test new behavior in create_bolt11_invoice

Bolt11InvoiceParameters allows for setting currency and
duration_since_epoch. If currency is not set, test that the one
corresponding to ChannelManager's chain hash is usd. If
duration_since_epoch, is not set then highest seen timestamp is used in
non-std compilations.

Deprecate functions in invoice_utils module

ChannelManager::create_bolt11_invoice is a simpler and more flexible way
of creating a BOLT11 invoice, so deprecate the corresponding functions
in the invoice_utils module.

Use ChannelManager::create_bolt11_invoice in tests

The utility methods in in invoice_utils will be removed or deprecated in
an upcoming commit.

Add a BOLT11 invoice utility to ChannelManager

Now that the lightning crate depends on the lightning_invoice crate, the
utility functions previously living in the latter can be implemented on
ChannelManager. Additionally, the parameters are now moved to a struct
in order to remove the increasingly combinatorial blow-up of methods.

The new Bolt11InvoiceParameters is used to determine what values to set
in the invoice. Using None for any given parameter results in a
reasonable the default or a behavior determined by the ChannelManager as
detailed in the documentation.

Remove currency support from invoice_utils

When creating an invoice using a ChannelManager, payments for a specific
ChainHash / Network are only valid. Use the one from the ChannelManager
instead of allowing arbitrary ones in the form of a Currency.

Support verifying payment_secrets for inbound static invoice payments

Add a new payment type for this, because normally the payment hash is factored
into the payment secrets we create for invoices, but static invoices don't have
a payment hash since they are paid via keysend.

Add new inbound payment key for spontaneous payments

This key will be used in upcoming commits for encrypting metadata bytes for
spontaneous payments' payment secrets, to be included in the blinded paths of
static invoices for async payments. We need a new type of payment secret for
these payments because they don't have an a prior known payment hash, see the
next commit.

Remove pending_inbound_payments map from ChannelManager

LDK versions prior to 0.0.104 had stateful inbound payments written in this
map. In 0.0.104, we added support for stateless inbound payments with
deterministically generated payment secrets, and maintained deprecated support
for stateful inbound payments until 0.0.116. After 0.0.116, no further inbound
payments could have been written into this map.

Remove no-std support from invoice_utils functions

The upcoming ChannelManager::create_bolt11_invoice will not support
setting a specific creation time, so remove that functionality from the
invoice_utils functions. This will avoid duplicate code when
deprecating.

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

Combine import statements

Add Description::empty constructor

When creating a default Bolt11InvoiceParameters, having an infallible
constructor avoids an unwrap.

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

Owned and ref versions of Bolt11InvoiceDescription

Split Bolt11InvoiceDescription into a version used with references to
the description or description hash in the invoice and an owned version
of these for when constructing an invoice. The latter is useful as it
removes an unnecessary clone and can be used in a future change
specifying either a description or description hash in larger set of
invoice parameters. Since it doesn't use a reference, it can be exposed
in bindings as well.

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.