rust-lightning

Support generic HTLC interception

At various points we've had requests to support more generic HTLC
interception in LDK. In most cases, full HTLC interception was not,
in fact, the right way to accomplish what the developer wanted, but
there have been various times when it might have been.

Here, we finally add full HTLC interception support, doing so with
a configurable bitfield to allow developers to intercept only
certain classes of HTLCs.

Specifically, we currently support intercepting HTLCs:
* which were to be forwarded to intercept SCIDs (as was already
supported),
* which were to be forwarded to offline private channels (for LSPs
to accept HTLCs for offline clients so that they can attempt to
wake them before failing the HTLC),
* which were to be forwarded to online private channels (for LSPs
to take additional fees or enforce certain policies),
* which were to be forwarded over public channels (for general
forwarding policy enforcement),
* which were to be forwarded to unknown SCIDs (for everything
else).

Expose the outgoing HTLC's CLTV expiry in `Event::HTLCIntercepted`

In the previous commit our interception documentation noted that in
some cases devs may wish to validate the CLTV expiry of HTLCs
before forwarding. Here we enable that by exposing the next-hop's
CLTV value in `Event::HTLCIntercepted`

DRY HTLC failure paths in `process_pending_update_add_htlcs`

Drop lockorder comments on `ChannelManager`

While its nice to document things, the lockorder comment at the top
of `ChannelManager` is just annoying to always update and doesn't
add all that much value. Developers likely shouldn't be checking it
while writing code, our automated lockorder issue detection
framework more than suffices to catch any bugs in test-reachable
code. That makes it basically write-only which isn't exactly a
useful comment.

Move HTLC holding into HTLC decode from `forward_htlcs`

When we added support for async payments (which requires holding
HTLCs until we receive an onion message), we added the hold logic
to `ChannelManager::forward_htlcs`. This made sense as we reused
the forwarding datastructure in the holding logic so already had
the right types in place, but it turns out only a single call of
`forward_htlcs` should ever result in an HTLC being held.

All of the other calls (un-holding an HTLC, forwarding an
intercepted HTLC, forwarding an HTLC decoded by LDK prior to 0.2,
or processing a phantom receive) should never result in an HTLC
being held. Instead, HTLCs should actually only ever be held when
the HTLC is decoded in `process_pending_update_add_htlcs` before
forwarding.

Because of this, and because we want to move the interception (and
thus also the holding logic) out of `forward_htlcs`, here we move
the holding logic into `process_pending_update_add_htlcs`.

Fix the HTLC failure reason reported when a peer is offline

If a peer is offline, but only recently went offline and thus the
channel has not yet been marked disabled in our gossip, we should
be returning `LocalHTLCFailureReason::PeerOffline` rather than
`LocalHTLCFailureReason::ChannelNotReady`. Here we fix the error
returned and tweak documentation to make the cases clearer.

BOLT 12: Validate bech32 padding per BIP-173

Add validation for bech32 padding in BOLT 12 offer parsing per BIP-173
which states: "Any incomplete group at the end MUST be 4 bits or less,
MUST be all zeroes, and is discarded."

This adds a test vector from the BOLT specification that ensures offers
with invalid padding (exceeding the 4-bit limit) are properly rejected.

Previously, LDK would accept offers with invalid bech32 padding. This
was identified through differential fuzzing across Lightning
implementations (see lightning/bolts#1312).

The fix calls `validate_segwit_padding()` from the bech32 crate during
offer parsing, and introduces a new `InvalidPadding` variant to
`Bolt12ParseError` to surface these errors.

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

`ElectrumSyncClient`: Skip unconfirmed `get_history` entries

Electrum's `blockchain.scripthash.get_history` will return the
*confirmed* history for any scripthash, but will then also append any
matching entries from the mempool, with respective `height` fields set
to 0 or -1 (depending on whether all inputs are confirmed or not).

Unfortunately we previously only included a filter for confirmed
`get_history` entries in the watched output case, and forgot to add such
a check also when checking for watched transactions. This would have us
treat the entry as confirmed, then failing on the `get_merkle` step
which of course couldn't prove block inclusion. Here we simply fix this
omission and skip entries that are still unconfirmed (e.g., unconfirmed
funding transactions from 0conf channels).

Signed-off-by: Elias Rohrer <dev@tnull.de>

rustfmt: format priv_short_conf_tests

Set dont_forward on private channel updates and add tests

Drop unnecessary Rust install in SemVer CI

In the last few days there was incompatibility of `cargo-semver-checks`
with the new stable Rust 1.93.0. While this should fixed by today's
release of `cargo-semver-checks`, we take the opportunity to drop an
unnecessary install step from the CI workflow, as the action will bring
their own Rust version if not configured otherwise.

fuzz: simplify get_payment_secret_hash return type

Change `get_payment_secret_hash` to return `(PaymentSecret, PaymentHash)`
directly instead of `Option<...>`.

The function calls `create_inbound_payment_for_hash` with `min_value_msat=None`
and `min_final_cltv_expiry=None`, which cannot fail. Remove the retry loop
and use `.expect()` since the call will always succeed with these parameters.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

fuzz: track pending and resolved payments

Track payment lifecycle by maintaining pending_payments and
resolved_payments arrays per node:

- When sending a payment, add its PaymentId to pending_payments
- On PaymentSent/PaymentFailed events, move the PaymentId from
pending to resolved (or assert it was already resolved for
duplicate events)

This tracking enables verifying payment state consistency after
node restarts.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

fuzz: rename chan_id to scid in hop payment functions

Rename `middle_chan_id` to `middle_scid` and `dest_chan_id` to `dest_scid`
in `send_hop_noret` and `send_hop_payment`. These parameters are short
channel IDs (SCIDs), not channel IDs, so the rename improves clarity.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

fuzz: add transaction broadcast assertions

Add transaction tracking to TestBroadcaster and verify no unexpected
broadcasts occur during normal fuzzing operation:

- Store all broadcast transactions in TestBroadcaster
- Clear the broadcast set after initial channel opens
- Assert in test_return! that no transactions were broadcast

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

fuzz: convert send helpers to closures with node indices

Replace the standalone `send_noret` and `send_hop_noret` functions with
closures defined inside the main loop. This allows them to capture the
`nodes` array and use simple node indices (0, 1, 2) instead of passing
`&nodes[x]` references at each call site.

The `send_payment` and `send_hop_payment` functions are modified to take
pre-computed `PaymentSecret`, `PaymentHash`, and `PaymentId` parameters,
with the closures handling the credential generation. This centralizes
where `PaymentId` is constructed, which will make it easier to add
payment tracking in a future change.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

fuzz: consolidate payment counters into single counter

Replace the separate `p_id: u8` (for payment hash generation) and
`p_idx: u64` (for payment IDs) with a single `p_ctr: u64` counter.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Matt Corallo <git@bluematt.me>

Add `total_consistency_lock` check in `handle_post_event_actions`

We expect callers of `handle_post_event_actions` to hold a read
lock on `total_consistency_lock`, and found that we forgot it in
`process_pending_events` until recently. Here we add a relevant
assertion to avoid such issues in the future.

Mixed mode splicing

Some splicing use cases require to simultaneously splice in and out in
the same splice transaction. Add support for such splices using the
funding inputs to pay the appropriate fees just like the splice-in case,
opposed to using the channel value like the splice-out case. This
requires using the contributed input value when checking if the inputs
are sufficient to cover fees, not the net contributed value. The latter
may be negative in the net splice-out case.

net-tokio: add `fn tor_connect_outbound`

Routes `fn connect_outbound` through Tor.

This uses a unique stream isolation parameter for each connection: the
hex-encoding of 32 random bytes sourced from the `entropy_source`
parameter.

Introduce Blinded Payment Dummy Path test

Introduce payment dummy hops in DefaultRouter

Update PaymentPath, and ClaimAlongRoute arguments

Upcoming commits will need the ability to specify whether a blinded path
contains dummy hops. This change adds that support to the testing
framework ahead of time, so later tests can express dummy-hop scenarios
explicitly.

Introduce Payment Dummy Hop parsing mechanism

Introduce Dummy Hop support in Blinded Path Constructor

Adds a new constructor for blinded paths that allows specifying
the number of dummy hops.
This enables users to insert arbitrary hops before the real destination,
enhancing privacy by making it harder to infer the sender–receiver
distance or identify the final destination.

Lays the groundwork for future use of dummy hops in blinded path construction.