rust-lightning

Check semver of all workspace crates rather than an explicit list

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

ln: use correct blinding point for trampoline payload decodes

The blinding point that we pass in is supposed to be the "update add"
blinding point equivalent, which in blinded trampoline relay is the
one that we get in the outer onion.

Use `--quiet` not `--verbose` on `cargo` calls in `ci-tests.sh`

I'm pretty confident I've never needed the full command strings
printed by the `--verbose` argument to `cargo` in `ci-tests.sh` and
it makes the output nontrivially larger. Further, I'm not sure
there's really much reason at all to output which thing is built
built - we only care about failures, thus we switch to `--quiet`.

This should make CI output comparatively easy to parse as scrolling
up to see which command failed requires a lot less scrolling.

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>

invoice: Use PaymentHash in raw invoice types

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.

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>

Simplify legacy TLV resolution in ChannelManagerData::read

The previous commit intentionally kept the code as close to a move as
possible to ease review. This follow-up applies idiomatic simplifications:

- Use unwrap_or for events_override resolution
- Use unwrap_or_else with iterator chains for pending_outbound_payments
- Use match with into_iter().collect() for in_flight_monitor_updates

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>

Remove spurious universality comment on `KVStore`

There would be nothing wrong with passing a different `KVStore` to
`OutputSweeper` from `MonitorUpdatingPersister` (though I'm not
really sure why someone would), and in fact I'm not aware of any
cases where passing a different `KVStore` to different structs
would be problematic. Thus, the sentence in docs is simply removed.

Ignore channel_update with dont_forward bit set in P2PGossipSync

Add CHANGELOG entries for 0.1.9 and 0.2.1

Expand test to cover Bolt11 custom TLVs

Extends the payment flow test to assert that custom TLVs passed to
`pay_for_bolt11_invoice` are preserved and delivered correctly.

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.

Centralize custom TLV validation behind `CustomTlvs`

Introduce a `CustomTlvs` wrapper to move sorting and validation of custom
TLVs out of `RecipientOnionFields` and into a dedicated type.

This makes TLV validity an explicit construction-time concern, allowing
`RecipientOnionFields` to assume correctness and remain a simple data
carrier. In turn, custom TLV usage becomes easier to extend without
duplicating protocol checks.

Drop Deref indirection for UtxoLookup

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

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