rust-lightning

Add `counterparty_node_id` to `TransactionType` variants

This adds `counterparty_node_id` tracking to all `TransactionType`
variants, enabling downstream users to identify the channel counterparty
associated with each broadcast transaction.

For single-channel variants (`CooperativeClose`, `UnilateralClose`,
`AnchorBump`, `Claim`, `Splice`), the counterparty is stored directly.

For multi-channel variants (`Funding`, `Sweep`), the type now uses
`Vec<(PublicKey, ChannelId)>` to pair each channel with its counterparty.

The `OnchainTxHandler` now stores `counterparty_node_id` and provides a
`set_counterparty_node_id` method for initialization during
deserialization of older data.

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

Add `counterparty_node_id` to `Event::SpendableOutputs`

This adds an optional `counterparty_node_id` field to the
`SpendableOutputs` event, providing users with information about which
channel counterparty the spendable outputs belong to.

The field uses TLV type 3 (odd) for backwards compatibility, meaning
older versions will safely ignore it during deserialization. When
reading events serialized by older LDK versions, this field will be
`None`.

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

Rustfmt ChannelManager::process_background_events

Switch `SplicePrototype` feature flag to the prod feature bit

When we shipped 0.2 we used the feature bit 155 to signal splicing,
in line with what eclair was using. However, eclair was actually
using that bit to signal splicing on a previous design which is
incompatible with the current spec.

The result of this was that eclair nodes may attempt to splice
using their protocol and we'd fail to deserialize their splice
message (resulting in a reconnect, which luckily would clear their
splice attempt and return the connection to normal).

As we really need to get off of their feature bit and there's not
much reason to keep using a non-final-spec bit, we simply redefine
`SplicePrototype` to bit 63 here.

Correct crate version numbers that have broken semver

The semver CI check is great but only checks the immediate crate in
question. It doesn't catch that many of our crates depend on
`lightning` and thus have actually broken semver as the types they
use have changed to `lightning` 0.3.

Here we hump the version of crates that have actually changed
semver since 0.2.

In addition to those that depend on `lightning`,
`lightning-invoice`'s API has changed (but was not being checked by
the semver CI task).

Finally, `lightning-macros` was updated to 0.2.1, so the version is
changed to 0.2.2.

Add Utxo::new_v1_p2tr

Drop unused imports

Co-Authored-By: HAL 9000

Refactor `BroadcasterInterface` to include `TransactionType`

Add a `TransactionType` enum to provide context about the type of
transaction being broadcast. This information can be useful for
logging, filtering, or prioritization purposes.

The `TransactionType` variants are:
- `Funding`: A funding transaction establishing a new channel
- `CooperativeClose`: A cooperative close transaction
- `UnilateralClose`: A force-close transaction
- `AnchorBump`: An anchor transaction for CPFP fee-bumping
- `Claim`: A transaction claiming outputs from commitment tx
- `Sweep`: A transaction sweeping spendable outputs to wallet

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

Extract second stage of ChannelManager::read into from_channel_manager_data

Move the validation and reconstruction logic (stage 2) from the
ReadableArgs::read implementation into a new pub(super) constructor
`from_channel_manager_data`. This separates the pure deserialization
from the complex reconstruction logic, making the code more modular
and easier to test.

The read function now:
1. Deserializes into ChannelManagerData (stage 1)
2. Calls from_channel_manager_data for validation/reconstruction (stage 2)

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

Resolve optional hash map TLV fields during ChannelManagerData deserialization

Move the unwrap_or_else(new_hash_map) resolution for pending_intercepted_htlcs
and decode_update_add_htlcs from stage 2 (from_channel_manager_data) to stage 1
(ChannelManagerData::read). This changes the struct fields from Option<HashMap>
to HashMap, making it explicit that these are always present after deserialization.

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

Resolve legacy TLV fields during ChannelManagerData deserialization

Move the resolution of legacy/compatibility TLV fields from
from_channel_manager_data (stage 2) into ChannelManagerData::read
(stage 1). This keeps ChannelManagerData minimal by consolidating
mutually exclusive fields into their final form during deserialization:

- pending_outbound_payments: Merge TLV 3, TLV 1 (no_retry), and
non-TLV compat fields into a single HashMap
- in_flight_monitor_updates: Convert legacy TLV 10 (keyed by OutPoint)
to TLV 17 format (keyed by ChannelId)
- pending_events: Apply events_override (TLV 8) if present

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

Unwrap TLV fields with initialized defaults in ChannelManagerData

For TLV fields that are initialized with Some(...) before reading and
thus always have a value after deserialization, remove the Option
wrapper from ChannelManagerData and unwrap when constructing it.

This applies to pending_claiming_payments and
monitor_update_blocked_actions_per_peer.

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

Split ChannelManager::read into two stages

Introduce ChannelManagerData<SP> as an intermediate DTO that holds all
deserialized data from a ChannelManager before validation. This splits
the read implementation into:

1. Stage 1: Pure deserialization into ChannelManagerData
2. Stage 2: Validation and reconstruction using the DTO

The existing validation and reconstruction logic remains unchanged;
only the deserialization portion was extracted into the DTO's
ReadableArgs implementation.

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

Drop Deref indirection for OutputSpender

Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

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

Drop Deref indirection for SignerProvider

Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

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

Drop Deref indirection for Logger

Reduces generics and verbosity across the codebase, should provide equivalent
behavior.

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

Drop Deref indirection for BroadcasterInterface

Reduces generics and verbosity across the codebase, should
provide equivalent behavior.

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

Fix race condition in async `UtxoFuture` resolution

Previously, we refactored the `GossipVerifier` to not require holding a
circular reference. As part of this, we moved to a model where the
`UtxoFuture`s are now polled by the background processor which checks
for completion through `get_and_clear_pending_msg_events`.

However, as part of this refactor we introduced race-condition: as we
only held `Weak` references in `PendingChecksContext` and the
`UtxoFuture` was directly dropped by the `GossipVerifier` after calling
`resolve`, the actual data was dropped with the future and gone when the
background processor attempted to retrieve and apply it via
`check_resolved_futures`.

Here, we fix this issue by simply holding on to the `state` `Arc`s in a
separate `pending_states` `Vec` that is only pruned in
`check_resolved_futures`, ensuring any completed results are collected
first.

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

`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

Use Amount in calculate_change_output_value

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

Inline format args