rust-lightning

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`

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

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: 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: 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: 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: 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>

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.

Free holding cells immediately rather than in message sending

I noted in review for an unrelated PR that adding more per-channel
logic in `ChannelManager::get_and_clear_pending_msg_events` really
sucks for our performance, especially if it ends up hitting a sync
monitor persistence. This made me wonder how far we actually are
from not needing the holding `check_free_holding_cells` call that's
currently there.

Turns out, at least according to our functional test coverage, the
answer is "not very far".

Thus, here we drop it in favor of consistently calling a new util
method on channels that might have the ability to release holding
cell updates in the same lock where they change state, rather than
waiting until `get_and_clear_pending_msg_events`.

We still process async monitor events in
`get_and_clear_pending_msg_events`, which can lead to channel (and
monitor) updates, but that should only be the case for async
persist applications, which then are likely to have fast
`ChannelMonitorUpdate` in-line handling logic (cause its async).

Introduce Dummy BlindedPaymentTlv

Dummy BlindedPaymentTlvs is an empty TLV inserted immediately before the
actual ReceiveTlvs in a blinded path. Receivers treat these dummy
hops as real hops, which prevents timing-based attacks.

Allowing arbitrary dummy hops before the final ReceiveTlvs obscures
the recipient's true position in the route and makes it harder for
an onlooker to infer the destination, strengthening recipient privacy.

Use Amount in calculate_change_output_value

fuzz: support initial async monitor persistence in chanmon_consistency

Read the first byte of fuzz input to determine initial monitor styles
for each node (bit 0 = node A, bit 1 = node B, bit 2 = node C). When
set, the node starts with InProgress persistence mode from the
beginning.

This allows fuzzing the async persistence path during initial channel
creation, not just after reload. The make_channel macro now completes
pending monitor updates after watch_channel calls to allow the channel
handshake to proceed.

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

Remove spurious debug assertion added in 0.2

In 20877b3e229ffedee9483e2b021fdcb98c7a378a we added a
`debug_assert`ion to validate that if we call
`maybe_free_holding_cell_htlcs` and it doesn't manage to generate
a new commitment (implying `!can_generate_new_commitment()`) that
we don't have any HTLCs to fail, but there was no reason for that,
and its reachable.

Here we simply remove the spurious debug assertion and add a test
that exercises it.

Add an option to deserialize monitors in parallel in async load

`MonitorUpdatingPersister::read_all_channel_monitors_with_updates`
was made to do the IO operations in parallel in a previous commit,
however in practice this doesn't provide material parallelism for
large routing nodes. Because deserializing `ChannelMonitor`s is the
bulk of the work (when IO operations are sufficiently fast), we end
up blocked in single-threaded work nearly the entire time.

Here, we add an alternative option - a new
`read_all_channel_monitors_with_updates_parallel` method which uses
the `FutureSpawner` to cause the deserialization operations to
proceed in parallel.

Rustfmt channel methods

Add logger to monitor_updating_paused

Split `OffersContext::OutboundPayment` into `InRefund`/`InInvReq`

Because they end up both being used to validate a `Bolt12Invoice`,
we ended up with a single `OffersContext` both for inclusion in a
`Refund` and an `InvoiceRequest`. However, this is ambiguous, and
while it doesn't seem like an issue, it also seems like a nice
property to only use a given `OffersContext` in one place.

Further, in the next commit, we use `OffersContext` to figure out
what we're building a blinded path for and changing behavior based
on it, so its nice to be unambiguous.

Thus, we split the single existing context into
`OutboundPaymentInRefund` and `OutboundPaymentInInvReq`.

Inline format args

Allow clippy's new assertions-on-constants lint

This is really dumb, `assert!(cfg!(fuzzing))` is a perfectly
reasonable thing to write!

Rustfmt touched methods

Remove `check_added_monitors` macro

Replace calls to `check_added_monitors` macro
to the identically-named function.

Add docs to `commitment_signed_dance_return_raa`