rust-lightning

Use SignedAmount::unsigned_abs to avoid overflow

In debug mode, using SignedAmount::abs can lead to an integer overflow
when used with SignedAmount::MIN. Use SignedAmount::unsigned_abs to
avoid this.

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.

Fix 0.2 CHANGELOG to note that offers will break on downgrade

It turns out we also switched the key we use to authenticate offers
*created* in the 0.2 upgrade and as a result downgrading to 0.2
will break any offers created on 0.2. This wasn't intentional but
it doesn't really seem worth fixing at this point, so just document
it.

Add AChainMonitor trait and use it in background processor

Add a new `AChainMonitor` trait following the same pattern as
`AChannelManager`. This trait provides associated types for all
generic parameters of `ChainMonitor` and a `get_cm()` method to
access the underlying `ChainMonitor`.

Update the background processor to use `AChainMonitor` trait bounds
instead of spelling out the full `ChainMonitor` generic parameters.
This simplifies the function signatures by removing 5-6 explicit
generic parameters (CF, T, F, P, ES) per function.

This is preparation for adding a flush method to the AChainMonitor
trait.

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

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>

Add test coverage for `TransactionType::Splice`

Add parallel `txn_types` vector to `TestBroadcaster` to track
`TransactionType` alongside broadcast transactions. Existing
`txn_broadcast()` API remains unchanged for backward compatibility.
New `txn_broadcast_with_types()` API allows tests to verify transaction
types.

Also add a `clear()` helper method and update test files to use it
instead of directly manipulating `txn_broadcasted`, ensuring the two
vectors stay in sync.

Update splice tests to use the new API and verify that splice
transactions are broadcast with the correct `TransactionType`.

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

Export `outbound_payments` directly rather than via re-exports

Every time we use re-exports to hide a module in the public API we
end up accidentally breaking the public API due to accidental
seals. We did this yet again in
e9c6bbccc3ccd4cb121a092229f50e29b3345552 where we moved to using a
`CustomTlvs` field in the public API for `RecipientOnionFields` but
forgot to re-export it, making it impossible to use downstream.

Instead, here, we just actually export `outbound_payments`.

Compilation fixes by Claude.

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>

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>

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>

Introduce custom TLVs in `pay_for_bolt11_invoice`

Custom TLVs let the payer attach arbitrary data to the onion packet,
enabling everything from richer metadata to custom authentication on
the payee's side.

Until now, this flexibility existed only through `send_payment`. The
simpler `pay_for_bolt11_invoice` API offered no way to pass custom
TLVs, limiting its usefulness in flows that rely on additional context.

This commit adds custom TLV support to `pay_for_bolt11_invoice`,
bringing it to feature parity.

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

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 NodeSigner

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>

Extend full_stack fuzz test to cover splicing

This includes a new seed that covers the splice flow to completion
(exchanging `splice_locked` and promoting the `FundingScope`).

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

Support funding_transaction_signed for unfunded dual-funded channels

Now that we require users to first call
`ChannelManager::funding_transaction_signed` before releasing any
signatures, it's possible that it is called before we receive the
initial commitment signed from our counterparty, which would transition
the channel to funded. Because of this, we need to support the API call
while the channel is still in the unfunded phase.

Note that this commit is mostly a code move of
`FundedChannel::funding_transaction_signed` to
`Channel::funding_transaction_signed` that doesn't alter the signing
logic.

Rework ChannelManager::funding_transaction_signed

Previously, we'd emit a FundingTransactionReadyForSigning event once the
initial commitment_signed is exchanged for a splicing/dual-funding
attempt and require users to call back with their signed inputs using
ChannelManager::funding_transaction_signed. While this approach worked
in practice, it prevents us from abandoning a splice if we cannot or no
longer wish to sign as the splice has already been committed to by this
point.

This commit reworks the API such that this is now possible. After
exchanging tx_complete, we will no longer immediately send our initial
commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call
back before releasing both our initial commitment_signed and our
tx_signatures. As a result, the event is now persisted, as there is only
one possible path in which it is generated. Note that we continue to
only emit the event if a local contribution to negotiated transaction
was made.

Future work will expose a cancellation API such that we can abandon
splice attempts safely (we can just force close the channel with
dual-funding).

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>