Merge pull request #2362 from TheBlueMatt/2023-06-unblocked-mons-in-manager

Move in-flight ChannelMonitorUpdates to ChannelManager

Rename `Channel::pending_monitor_updates` to `blocked`

To differentiate between in-flight pending completion and blocked
updates.

Rename Channel's latest-monitor-update fetch method for clarity

`Channel::get_latest_complete_monitor_update_id` no longer refers
to complete updates, but rather ones which were passed to the
`ChannelManager` and which the `CHannel` no longer knows about.
Thus, we rename it `get_latest_unblocked_monitor_update_id`.

Remove the `blocked` param on `ChannelMonitorUpdates` in `Channel`

Now that all `ChannelMonitorUpdate`s stored in `Channel` are
blocked we don't need a bool to track it.

Drop the now-unused update_id param to monitor update macros

Move in-flight `ChannelMonitorUpdate`s to `ChannelManager`

Because `ChannelMonitorUpdate`s can be generated for a
channel which is already closed, and must still be tracked
through their completion, storing them in a `Channel`
doesn't make sense - we'd have to have a redundant place to
put them post-closure and handle both storage locations
equivalently.

Instead, here, we move to storing in-flight
`ChannelMonitorUpdate`s to the `ChannelManager`, leaving
blocked `ChannelMonitorUpdate`s in the `Channel` as they
were.

Merge pull request #2361 from arik-so/2023-06-anchor-channel-type-features

Replace `opt_anchors` with `ChannelTypeFeatures`

Sync `ChannelTransactionParameters` features to `ChannelContext`.

Verify channel type features for decoding.

Replace `opt_anchors` with `ChannelTypeFeatures`

This change modifies six structs that were keeping
track of anchors features with an `opt_anchors` field,
as well as another field keeping track of nonzero-fee-
anchor-support.

Merge pull request #2365 from TheBlueMatt/2023-06-fix-fuzz-dep

Ensure we build if a downstream crate sets `--cfg=fuzzing`

Method for `ChannelTypeFeatures` serialization compatibility.

Define `ChannelTypeFeatures` methods for anchors logic.

Specifically, introduce a new constructor for an anchors-
supporting feature set, as well as methods that will
maintain forwards-compatible deserialization in older
versions.

Reference-rhs bitwise operations for features.

Document nonzero anchors in features module.

Introduce nonzero fee anchors feature.

Simplify cases in `handle_new_monitor_update` macro

By giving up on a tiny bit of parallelism and tweaking the return
types, we can make the `handle_new_monitor_update` macro a bit
clearer - now the only cases where its called after a monitor was
updated was when the monitor was initially committed.

Drop the now-unused `push_blockable_mon_update`

Move most `handle_new_monitor_update` calls to pass the update

Most of the calls to the `handle_new_monitor_update` macro had the
exact same pattern - calling `update_monitor` followed by the
macro. Given that common pattern will grow to first pushing the
new monitor onto an in-flight set and then calling `update_monitor`
unifying the pattern into a single macro now avoids more code churn
in the coming commits.

Return owned `ChannelMonitorUpdate`s from `Channel`

In the coming commits we'll move to storing in-flight
`ChannelMonitorUpdate`s in the `ChannelManager` rather in the
`Channel` (which will then only retain `ChannelMonitorUpdate`s
which have not yet been released/are blocked.

This will simplify handling of pending `ChannelMonitorUpdate` after
a channel has closed by not having to move them into the
`ChannelManager`.

Merge pull request #2319 from valentinewallace/2023-05-forward-less-than-onion

Allow forwarding less than the amount in the onion

Ensure we build if a downstream crate sets `--cfg=fuzzing`

Downstream crates building fur fuzzing will usually set
`--cfg=fuzzing` as a side-effect of the Rust fuzzing tooling. Thus,
we should ensure we build without failure in such cases.

We do this here by simply relying on the `_test_utils` feature,
rather than conditionally-compiling in modules based on the
`fuzzing` flag.

Document on claim events that amount_msat may be > invoice amount

Check UpdateAddHTLC::skimmed_fee_msat on receive

Make sure the penultimate hop took the amount of fee that they claimed to take.
Without checking this TLV, we're heavily relying on the receiving wallet code
to correctly implement logic to calculate that that the fee is as expected.

Set UpdateAddHTLC::skimmed_fee_msat on forward

So the receiver can verify it and approve underpaying HTLCs (see
ChannelConfig::accept_underpaying_htlcs).

Persist update_add sender skimmed fee in Channel

Track the sender's skimmed fee in UpdateAddHTLC

Allow receiving less than the onion claims to pay

Useful for penultimate hops in routes to take an extra fee, if for example they
opened a JIT channel to the payee and want them to help bear the channel open
cost.

Add PaymentClaimable::counterparty_skimmed_fee_msat

See its docs

Persist counterparty skimmed fee in ClaimableHTLC

Used to get an accurate skimmed fee in the resulting PaymentClaimable event.

Set extra skimmed fee on intercepted forward

Receivers need to use this value to verify incoming payments if
ChannelConfig::accept_underpaying_htlcs is set.

Add config knob for accepting underpaying HTLCs

See ChannelConfig::accept_underpaying_htlcs

Move next hop packet pubkey calculation to outside channel lock

Move PendingHTLCStatus construction inside channel lock

We need the channel lock for constructing a pending HTLC's status because we
need to know if the channel accepts underpaying HTLCs in upcoming commits.

Merge pull request #2120 from valentinewallace/2023-03-blinded-pathfinding

Merge pull request #2089 from wpaulino/bump-transaction-event-handler

Add BumpTransaction event handler

Provide a default CoinSelectionSource implementation via a new trait

Certain users may not care how their UTXOs are selected, or their wallet
may not expose enough controls to fully implement the
`CoinSelectionSource` trait. As an alternative, we introduce another
trait `WalletSource` they could opt to implement instead, which is much
simpler as it just returns the set of confirmed UTXOs that may be used.
This trait implementation is then consumed into a wrapper `Wallet` which
implements the `CoinSelectionSource` trait using a "smallest
above-dust-after-spend first" coin selection algorithm.

Add BumpTransaction event handler

This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.

While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.

Expose ClaimId for each claim bump in BumpTransactionEvent

Expose existing PackageID to API and rename to ClaimId

In a future commit, we plan to expand `BumpTransactionEvent` variants to
include the unique identifier assigned to pending output claims by the
`OnchainTxHandler` when a commitment is broadcast/confirmed. This
requires making it public in our API. We also choose to rename it to
`ClaimId` for the benefit of users, as the previous `PackageID` term
could be interpreted to be the ID of a BIP-331 transaction package.

Change package ID computation for HTLC claims on anchor channels

While the previous way of computing the identifier was safe, it wouldn't
have been in certain scenarios if we considered splitting aggregated
packages. While this type of splitting has yet to be implemented, it may
come in the near future. To ensure we're prepared to handle such, we
opt to instead commit to all of the HTLCs to claim in the request.

Implement routing to blinded payment paths

Sending to them is still disallowed, for now.

Router: clean up Path construction

We don't need to collect a vec of Results anymore.

Add CandidateRouteHop::Blinded and ::OneHopBlinded variant

It's unclear what values 1-hop blinded paths should set their BlindedPayInfos
to, because those values are meant to refer to the fees/cltv delta on the path
*between* the intro node and the destination. We zero out these values in the
new variant's methods so they don't mess with path finding/construction.

Update CandidateRouteHop::short_channel_id to be optional

Merge pull request #2351 from TheBlueMatt/2023-04-remove-legacy-recv

Drop `create_inbound_payment*_legacy` breaking downgrade to 0.0.103

Routing: accommodate for blinded paths in used liquidity tracking

Replace max_channel_saturation_power_of_half hardcode with const

Add utils for creating blinded PaymentParameters

Reverse (BlindedPath, BlindedPayInfo) tuple order in offers invoice.

To make it uniform with PaymentParameters' Payee::Blinded::route_hints.

Merge pull request #2077 from dunxen/2023-02-splitchannelstate

Split prefunded `Channel` into `Inbound`/`Outbound` channels

Rename `inbound_is_awaiting_accept()` to `is_awaiting_accept()`

Rename `InboundV1Channel::new_from_req` to `InboundV1Channel::new`

Move inbound channel methods into `InboundV1Channel`'s impl

Move outbound channel methods into `OutboundV1Channel`'s impl

Create and use methods for counting channels

This commit also adds two new maps to `PeerState` for keeping track
of `OutboundV1Channel`s and `InboundV1Channel`s so that further
commits are a bit easier to review.

Refactor channel map update macros for use with `ChannelContext`

Move `Channel::force_shutdown` to `ChannelContext` impl

Move inbound channel constructor into `InboundV1Channel` impl

Move outbound channel constructor into `OutboundV1Channel` impl

Introduce `InboundV1Channel` & `OutboundV1Channel`

Move channel constants up

Make `ChannelManager::issue_channel_close_events` take a `ChannelContext`

Convert `ChannelDetails::from_channel` to `ChannelDetails::from_channel_context`

This rename and refactor is so that we can get channel details from a
`ChannelContext` which is a common object to all channels.

Move `Channel::get_available_balances` to `ChannelContext` impl

Move `Channel::next_*_commit_tx_fee_msat` methods to `ChannelContext` impl

Move `Channel::commit_tx_fee_msat` to file-level utilities

Move `Channel::get_*_pending_htlc_stats` to `ChannelContext` impl

Prepare some methods for upcoming moves to `ChannelContext`

To reduce interleaving in commits, we introduce a `context` variable
in methods to be moved in upcoming commits so there is minimal change
with the moves.

Move `Channel::get_feerate_sat_per_1000_weight` and other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

f s/tarcontext.get_/target_/

Move `Channel::build_holder_transaction_keys` and some other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::build_commitment_transaction` to `ChannelContext` impl

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::channel_id` and some other methods to `ChannelContext` impl

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.

Move `Channel::get_update_time_counter` and some other methods

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

This commit also uses these methods through the `context` field where
needed for compilation and tests to pass due to the above change.

Move `Channel::opt_anchors` to `ChannelContext` impl & move some util fns

This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.

Move `Channel` fields into `ChannelContext` struct

This is a first step for simplifying the channel state and introducing
new unfunded channel types that hold similar state before being promoted
to funded channels.

Essentially, we want the outer `Channel` type (and upcoming channel types)
to wrap the context so we can apply typestate patterns to the that wrapper
while also deduplicating code for common state and other internal fields.

Merge pull request #2294 from jkczyz/2023-05-onion-message-replies

BOLT 12 Offers message handling support

Reduce log level of potential noisy log statement

Fuzz test onion message replies

Use different node secrets in onion message fuzzer

When generating onion message fuzz data, the same public key was used
for each node. However, the code now advances the blinded path if the
sender is the introduction node. Use different node secrets for each
node to avoid this. Note that the exercised handling code is for the
sender's immediate peer.

Test onion message replies

Split TestCustomMessage into Request and Response

This will allow for testing onion message replies.

Remove unnecessary Sized bound

Support onion message replies in OnionMessenger

Modify onion message handlers to return an optional response message for
OnionMessenger to reply with.

MessageRouter trait for OnionMessenger

Add a trait for finding routes for onion messages and parameterize
OnionMessenger with it. This allows OnionMessenger to reply to messages
that it handles via one of its handlers (e.g., OffersMessageHandler).

Add OnionMessagePath wrapper struct

To avoid confusion in the upcoming MessageRouter trait, introduce an
OnionMessagePath struct that wraps the intermediate nodes and the
destination. Use this in OnionMessenger::send_onion_message.

OffersMessageHandler trait for OnionMessenger

Add a trait for handling BOLT 12 Offers messages to OnionMessenger and a
skeleton implementation of it for ChannelManager. This allows users to
either provide their own custom handling Offers messages or rely on a
version provided by LDK using stateless verification.

Avoid an unnecessary unwrap

Onion message payload for BOLT 12 Offers

BOLT 12 Offers makes use of onion messages to request and respond with
invoices. Add these types and an error type to OnionMessageContents
along with the necessary parsing and encoding.

Pass logger to onion payload decoder

In an upcoming commit, messages for BOLT 12 offers are read from the
onion payload. Passing a logger allows for logging semantic errors when
parsing the messages.

Add InvoiceError message

If an InvoiceRequest or an Invoice delivered via an onion message cannot
be handled, the recipient should reply with an InvoiceError if a reply
path was given. Define the message and conversion from SemanticError.

Support WithoutLength for UntrustedString

Fix oops'd docs on PaymentParameters::with_max_channel_saturation

Fix panic on pathfinding to blinded recipient

The previous dummy payee id was an invalid pubkey

Merge pull request #2353 from TheBlueMatt/2023-06-fix-msrv-build

Fix build on supported platforms due to `log` breakage

The `log` crate decided to break support for rustc 1.48 (Debian
bullseye) the day the next release of Debian comes out, obviously
before anyone has had a chance to upgrade to the new Debian
bookworm (at https://github.com/rust-lang/log/pull/543). Thus, we
have to manually pin it back to the previous release.

Sadly, the `log` crate is a transitive dependency of `tokio` until
0.20, which requires rustc 1.49. Luckily at least we won't have to
deal with this again, as `log` won't be a dependency of ours
anymore soon.

Stop writing old `user_payment_id` field not read since 0.0.103

Since we're breaking downgrade compatibility to LDK version 0.0.103
and before, we might as well go ahead and remove other code we have
for compatibility.

Drop `create_inbound_payment*_legacy` breaking downgrade to 0.0.103

0.0.103 is now downright ancient, and certainly shouldn't exist in
production anywhere today. Thus, it seems fine to remove the
ability to create legacy stateful inbound payment entries.

Users downgrading to 0.0.103 will thus not be able to claim any
payments created on modern LDK, though we still retain the ability
to claim such payments at least for one more release.

Merge pull request #2156 from alecchendev/2023-04-mpp-keysend

Support MPP Keysend

Add test for duplicate keysend payment

The logic has been changed around duplicate keysend payments such that
it's no longer explicitly clear that we reject duplicate keysend
payments now that we handle receiving multi-part keysends. This test
catches that. Note that this also tests that we reject MPP keysends when
our config states we should, and that we reject MPP keysends without
payemnt secrets when our config states we support MPP keysends.