rust-lightning

Apply MPP receive timeout to keysend payments

Incomplete keysend MPPs skipped the receive timeout path,
allowing partial payments to hold HTLC slots until CLTV
expiry instead of failing after `MPP_TIMEOUT_TICKS`.
Apply the existing `total_mpp_amount_msat` completeness
check to all MPP receives and add a regression test
covering the keysend case.

The timeout logic was originally added only for
invoice-backed MPPs in 2022, and that invoice-only
guard remained when receive-side MPP keysend support
landed in 2023, leaving this gap latent until now.

Co-Authored-By: HAL 9000

Remove ldk-node integration workflow

ci: pin hyper-rustls for Rust 1.75 sync builds

The build-sync job started resolving hyper-rustls v0.27.8 for the esplora-async-https configuration. That release requires rustc 1.85, but the sync CI job still runs on Rust 1.75.0.

Pin hyper-rustls to 0.27.7 when building with rustc older than 1.85, alongside the existing MSRV dependency pins in ci-tests-common.sh.

AI tools were used in preparing this commit.

Validate HTTPS scheme in LSPS5 URL Readable deserialization

The `Readable` implementations for `LSPSUrl` and `LSPS5WebhookUrl`
were bypassing URL validation, allowing non-HTTPS URLs (e.g., http://,
ftp://) to be deserialized from the wire protocol without rejection.
Only the serde `Deserialize` and `new()`/`parse()` paths were correctly
validating the HTTPS scheme.

Route `LSPSUrl::Readable` through `LSPSUrl::parse()` and add a length
check to `LSPS5WebhookUrl::Readable` so that wire-deserialized URLs
receive the same validation as JSON-deserialized ones.

Fixes #4559

Reported-by: Thomas Kilbride of Block Security
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Document that LSPS5 services should double-check the destination

It would be easy to implement an LSPS5 service and forget that the
webhook calls are going out based on a URI and headers provided by
an untrusted client, so such implementations need to make sure to
check if the destination is some internal resource before sending.

Reported by Jordan Mecom of Block's Security Team

Avoid `Vec::with_capacity(huge)` on empty `Route`s

In generally we consider empty `Route`s bogus garbage and don't
always handle them super carefully, but ideally we shouldn't
allocate a huge buffer just because someone passes a bogus `Route`
to an onion-building utility method.

Reported by Jordan Mecom of Block's Security Team

Test by Claude Opus 4.6

Use `saturating_mul` when multiplying feerates by the fee spike buf

In theory a channel's feerate could be set to some absurd value
(millions of satoshis per vB) and we'd overflow the fee spike
buffer, accepting the absurd fee and ignoring our fee spike buffer
check. This is harmless - the counterparty has much easier ways of
bricking the channel if they want, and paying several BTC in fees
is probably not the best way. Our commitment transaction and dust
fee exposure logic all correctly map the `u32` to a `u64` before
multiplying, making them overflow-safe.

Still, its good to fix overflows because it is a remotely-reachable
crash in debug builds.

Reported by Jordan Mecom of Block's Security Team

Correct blinded path forwarding CLTV expiry check

The `PaymentConstraints::max_cltv_expiry` field exists to ensure
a blinded path expires across the entire path at once - once the
path is expired it will be rejected by the introduction node rather
than traversing the entire path and failing at the destination.

This was broken by the fact that we were checking the outgoing CLTV
value rather than the incoming one, which admittedly isn't clear in
the spec but is somewhat implied. Here we fix this, updating a test
which was actually (kinda) exploiting this privacy loss rather than
allowing the HTLC to fail at the introduction node.

This, of course, does not risk funds loss as our own CLTV policy is
still enforced on top. The only impact it could have is a recipient
which was relying on blinded path expiry to avoid some cost (e.g.
LSPS5 node wakeup cost) involved in receiving an HTLC they
ultimately fail, though I'm not aware of any practical deployment
where that is a concern.

Reported by Jordan Mecom of Block's Security Team

Fix async release before HTLC decode

Handle `ReleaseHeldHtlc` messages that arrive before the sender-side LSP
has even queued the held HTLC for onion decoding. Unlike lightningdevkit#4106, which
covers releases arriving after the HTLC is in `decode_update_add_htlcs`
but before it reaches `pending_intercepted_htlcs`, this preserves
releases that arrive one step earlier and would otherwise be dropped as
HTLC not found.

Co-Authored-By: HAL 9000
Co-Authored-By: Elias Rohrer <dev@tnull.de>

Hold peer lock when pushing to decode_update_adds

This avoids race conditions where we're unable to properly update an HTLC's
state because we need to update its state in the ChannelManager, but the HTLC
is stuck in transit from the Channel to
ChannelManager::decode_update_add_htlcs. Now the HTLC will atomically go from
the Channel to the ChannelManager decode queue under the same lock.

Remove wallet argument from FundingTemplate::splice_out

It does not require coin selection, so the wallet argument is not
necessary.

util: add helper ChannelHandshakeConfig -> ChannelHandshakeConfigUpdate

Mirror the ChannelConfig -> ChannelConfigUpdate helper

fuzz: add fuzz target for P2PGossipSync gossip message handling

Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>

Note why we don't use `update_for_new_tip` in offers flow block upd

cargo fmt

Bypass channel monitor sync requests when no partition key given

Add missing `OffersMessageHandler::best_block` updating

It seems we forgot to ensure `OffersMessageHandler::best_block` is
consistently updated, leading to us building invalid blinded
payment paths for short-lived payment paths after two weeks without
restart.

Drop stale DNSSec resolution logic in `OffersMessageFlow`

In 884158d0914c64df4807c394e3155646dead478d we dropped built-in
BIP 353 resolution logic in favor of the
`bitcoin-payment-instructions` crate but forgot to do so in the
`OffersMessageFlow`. Here we do so.

Fix cltv_expiry_delta comment

Fix incorrect comment about cltv_expiry_delta.
The cltv_expiry on the outgoing HTLC must be less than the
one in the incoming HTLC.

Correctly refer to `pay_for_offer_from_hrn` in `pay_for_offer` docs

If a `pay_for_offer` call comes in that was for an HRN, downstream
code should instead call `pay_for_offer_from_hrn`, not
`pay_for_offer`.

Drop `ChannelManager`-built-in BIP 353 resolution logic

Since we shipped the `bitcoin-payment-instructions` crate we
generally expect downstream code to use that rather than doing
BIP 353 DNS resolutions over onion messages directly from the
`ChannelManager`. Thus, in 0.2 we marked
`pay_for_offer_from_human_readable_name` deprecated and here remove
it in favor of explicit references to the
`bitcoin-payment-instructions` crate in documentation.

chainmon: fixup stale docs mentioning removed funding_txo params

Add `unannounced_channel_max_inbound_htlc_value_in_flight_percentage`

Users can now configure two different max percentages for the channel
value that can be allocated to inbound HTLCs, one for announced
channels, and another for unannounced channels.

We also bump the default maximums to 25% for announced channels, and
100% for unannounced channels, to bring them closer to what people would
expect.

Wipe empty entries from `actions_blocking_raa_monitor_updates`

In a very specific case, forgetting to do so can lead to a debug
assertion failure when we see a double-claim of an HTLC (see the
included test).

Found by @joostjager's work on growing the chanmon_consistency
fuzzer.

Make fuzz targets deterministic

Gate all SystemTime::now() and Instant::now() calls in production code
with #[cfg(all(feature = "std", not(fuzzing)))] so that fuzz targets
produce consistent results regardless of wall-clock time. For each
location, the existing no-std fallback (highest_seen_timestamp, None,
or a constant) is reused under fuzzing.

Also force deterministic hashing when the fuzzing cfg is active,
rather than requiring the LDK_TEST_DETERMINISTIC_HASHES env var.

AI tools were used in preparing this commit.