rust-lightning

Expose current dust exposure in ChannelDetails

Co-authored-by: Codex <codex@openai.com>

expose scorer

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>

cargo fmt

Fetch blocks from source in parallel during initial sync

In `init::synchronize_listeners` we may end up spending a decent
chunk of our time just fetching block data. Here we parallelize
that step across up to 36 blocks at a time.

On my node with bitcoind on localhost, the impact of this is
somewhat muted by block deserialization being the bulk of the work,
however a networked bitcoind would likely change that. Even still,
fetching a batch of 36 blocks in parallel happens on my node in
~615 ms vs ~815ms in serial.

Pass a `BestBlock` to `init::synchronize_listeners`

On restart, LDK expects the chain to be replayed starting from
where it was when objects were last serialized. This is fine in the
normal case, but if there was a reorg and the node which we were
syncing from either resynced or was changed, the last block that we
were synced as of might no longer be available. As a result, it
becomes impossible to figure out where the fork point is, and thus
to replay the chain.

Luckily, changing the block source during a reorg isn't exactly
common, but we shouldn't end up with a bricked node.

To address this, `lightning-block-sync` allows the user to pass in
`Cache` which can be used to cache recent blocks and thus allow for
reorg handling in this case. However, serialization for, and a
reasonable default implementation of a `Cache` was never built.

Instead, here, we start taking a different approach. To avoid
developers having to persist yet another object, we move
`BestBlock` to storing some number of recent block hashes. This
allows us to find the fork point with just the serialized state.

In a previous commit, we moved deserialization of various structs
to return the `BestBlock` rather than a `BlockHash`. Here we move
to actually using it, taking a `BestBlock` in place of `BlockHash`
to `init::synchronize_listeners` and walking the `previous_blocks`
list to find the fork point rather than relying on the `Cache`.

Consolidate all the pub aync utils to `native_async`

Create better helper functions in `tx_builder`

Reduce line count and indentation

Shakedown zero reserve channels

Merge rbf_channel into splice_channel and expose prior contribution

Users previously had to choose between splice_channel (fresh splice) and
rbf_channel (fee bump) upfront. Since splice_channel already detects
pending splices and computes the minimum RBF feerate, rbf_channel was
redundant. Merging into a single API lets the user call one method and
discover from the returned FundingTemplate whether an RBF is possible.

The FundingTemplate now carries the user's prior contribution from the
previous splice negotiation when one is available. This lets users reuse
their existing contribution for an RBF without performing new coin
selection. A PriorContribution enum distinguishes whether the
contribution has been adjusted to the minimum RBF feerate (Adjusted) or
could not be adjusted due to insufficient fee buffer or max_feerate
constraints (Unadjusted).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Skip mixed-mode assertion for replayed monitor updates

When a node restarts and switches from async to sync persistence, the
in-flight monitor updates from the previous session are replayed as
background events. These replayed updates are resubmitted to the Watch
which now returns Completed, while earlier in-flight updates are still
queued as background events. This triggered a false panic in the
assertion that guards against out-of-order monitor update completion.

Track whether an update is a replay (already present in
in_flight_monitor_updates) and skip the assertion for replays, since
the remaining in-flight updates will be submitted by subsequent
background events.

AI tools were used in preparing this commit.

Add .cargo/config.toml for fuzz cfg flags

Set fuzzing, secp256k1_fuzz, and hashes_fuzz cfg flags in
fuzz/.cargo/config.toml so they are automatically applied to plain
cargo commands (cargo test, cargo run) run from the fuzz directory.
Remove the now-redundant RUSTFLAGS from the README crash reproduction
examples, the CI cargo test step, and generate_fuzz_coverage.sh.

The honggfuzz and cargo-fuzz docs are unchanged because those tools
build their own RUSTFLAGS env var (which overrides config.toml) and
require the flags to be exported separately.

AI tools were used in preparing this commit.

Drop unused `LSPS1OnchainPayment` type

Fix clippy lints

Drop `OutboundCRChannel`

The `OutboundChannel` construct simply wrapped `ChannelOrder` which we
can now simply use directly.

Remove TaprootChannelSigner

We plan to have a single channel signer type going forward, so this is
unnecessary.

Rustfmt reorg_tests.rs

Tell claude to be DRY

Reject offer_amount of 0 as invalid per BOLT 12

Per the spec clarification in https://github.com/lightning/bolts/pull/1316:
- Writers MUST set offer_amount greater than zero when present
- Readers MUST NOT respond to offers where offer_amount is zero

Reject amount_msats(0) in the builder with InvalidAmount, and reject
parsed offers with amount=0 (with or without currency) during TLV
deserialization.

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

Check that funder covers the fee spike buffer multiple after a splice

We do this for HTLCs, so we should also do this for splices. This
only applies to channels with non-zero-fee HTLC transactions.

Cleanup unused code

.. for which we got warnings

Let callers handle errors on `get_available_balances_for_scope`

`get_available_balances_for_scope` only errors if some party in the
channel cannot afford the HTLCs outbound from said party, and the
anchors and transaction fee if they are the funder. We do not account
for the channel reserve here, so this error should be exceedingly rare,
but could nonetheless happen due to concurrent updates on the channel's
state. The upcoming zero-reserve channel type could also make this case
more reachable.

`send_htlc` maps such an error to its own error type since it proposes
an update to the channel's state. The other callers only read the
channel's state, so it would not be a good fit to have them return an
error too. Hence, we choose to let these callers panic in debug mode,
and return saturated values in release mode.

Note that we now handle the if-we-removed-it-already-but-haven't
-fully-resolved-they-can-still-send-an-inbound-HTLC case, as
`LocalRemoved` HTLCs are considered resolved when calculating
`AvailableBalances`. We update the documentation accordingly.

Return `AvailableBalances` in `get_channel_stats`

Note that `AvailableBalances` will always refer to the holder's
balances, even when `local` is set to `false`, when calling
`TxBuilder::get_channel_stats`.

Format `tx_builder::get_available_balances`

Move `ChannelContext::get_available_balances_for_scope` to `tx_builder`

This is a direct code move to `tx_builder::get_available_balances`.