LND

lnwire: validate MuSig2 nonces in LocalNoncesData decode

Validate each nonce in decodeLocalNoncesData with
ValidateMusig2Nonce to reject malformed entries.

lnwallet/chancloser: remove racy "no more states" check

The assertStateTransitions helper contained a non-blocking select
after consuming expected states to verify no additional transitions
occurred. This check is inherently racy: the state machine goroutine
can emit the next transition before the non-blocking select runs,
causing spurious "unexpected state transition" failures.

This was the primary cause of TestRbfCloseErr flakes (~29% failure
rate under coverage instrumentation).

To preserve strictness, add a post-Stop() quiet-period check in
stopAndAssert(). After the state machine is stopped, no further
transitions should be produced, so draining the subscriber channel
there is deterministic and catches any unexpected stragglers.

Also fix the CloseErr restart test paths (send_offer_restart,
recv_offer_restart) which were under-consuming transitions. Both
ClosePending and CloseErr produce an extra ClosingNegotiation
emission on restart via internal requeue, so the helpers now take
an explicit expectExtraTransition flag rather than the ambiguous
iteration bool.

Finally, register the state subscriber before Start() to avoid
racing with the initial state notification emitted by driveMachine.
The old ordering (Start then RegisterStateEvents) could miss the
first transition entirely on slow CI runners, causing a permanent
timeout in assertStartupAssertions.

lnwallet/chancloser: use wait.DefaultTimeout for state transitions

The hardcoded defaultTimeout (previously 500ms, then 5s) used in
assertStateTransitions was too tight for CI runners, especially
under coverage instrumentation or remote DB backends (postgres).

Use wait.DefaultTimeout which automatically adapts to the build
environment: 30s on standard platforms, 60s+ for remote DB builds,
and 60s on Windows.

docs: add release note for v1 node horizon query optimization

graph/db: add node horizon index benchmark

Add BenchmarkNodeHorizonIndex to compare query performance under old
vs new index configurations for NodeUpdatesInHorizon. Tests both
all-nodes and public-only variants against native SQLite and
optionally Postgres backends, swapping indexes via DDL between runs.

sqldb/sqlc: split public-only node horizon query and upgrade channel indexes

Split GetNodesByLastUpdateRange into two query variants: one for all
nodes and a new GetPublicNodesByLastUpdateRange for public-only nodes.
The public-only variant uses two separate EXISTS checks (one per
node_id column) instead of a single OR, allowing the planner to do
direct index probes on each channel node-id index.

Also upgrade the channel node-id indexes from single-column
(node_id_1) and (node_id_2) to composite (node_id_1, version) and
(node_id_2, version) to support version-aware public node checks
while preserving usefulness for node-centric lookups.

sqldb/sqlc: add version filter and composite index for v1 node horizon query

The v1 GetNodesByLastUpdateRange query was missing an explicit
`WHERE version = 1` filter and used a single-column index on
`graph_nodes(last_update)` which didn't match the full query ordering
shape `ORDER BY last_update, pub_key`, requiring an extra sort step.

Add `WHERE version = 1` to the query for correctness and replace the
index with a composite `(version, last_update, pub_key)` index that
covers the filter, range scan, and pagination ordering together.

Note: the migration 000009_graph_v2 file is edited directly (dropping
the old index and creating the new one) rather than adding a new
migration, since this migration has not been included in a release yet.

docs: add release note for versioned graph horizon queries

graph/db: remove ChannelGraph horizon wrappers, use VersionedGraph

The ChannelGraph.NodeUpdatesInHorizon and
ChannelGraph.ChanUpdatesInHorizon methods were only used in tests.
All production callers already use VersionedGraph (which supplies
the gossip version from its embedded field).

Remove the ChannelGraph wrappers and update tests to instantiate a
VersionedGraph via NewVersionedGraph(MakeTestGraph(t), v1) instead,
dropping the explicit version parameter from horizon calls.

discovery: replace chain param with ctx in UpdatesInHorizon

Replace the unused chainhash.Hash parameter in
ChannelGraphTimeSeries.UpdatesInHorizon with context.Context. The
chain parameter was never consulted by the implementation since the
graph is not chain-scoped. The context is threaded through to the
underlying graph DB queries that need it.

graph/db: add v2 block-height path for NodeUpdatesInHorizon

Add GetNodesByBlockHeightRange SQL query and wire it into
SQLStore.nodeUpdatesInHorizonV2. This mirrors the existing v1
time-based query but filters on (version, block_height) instead of
last_update, using the same [start, end) exclusive-end semantics
and (block_height, pub_key) compound cursor pagination.

The public-node filter for v2 checks for channels with a non-empty
channel announcement signature (c.signature), matching the v2
protocol's public channel indicator.

graph/db: version NodeUpdatesInHorizon and ChanUpdatesInHorizon

Replace the (startTime, endTime time.Time) parameters on
NodeUpdatesInHorizon and ChanUpdatesInHorizon with
(v GossipVersion, r NodeUpdateRange/ChanUpdateRange). The range
types enforce version-correct bounds at the type level: v1 uses unix
timestamps, v2 will use block heights.

The KV store rejects non-v1 versions since it only stores v1 data.
The SQL store dispatches to version-specific helpers
(nodeUpdatesInHorizonV1, chanUpdatesInHorizonV1); the v2
block-height paths return an error for now and will be wired up in
follow-up commits.

VersionedGraph wrappers supply the version from the embedded field,
so callers only pass the range.

graph/db: add v2 block-height path for ChanUpdatesInHorizon

Add GetChannelsByPolicyBlockRange SQL query and wire it into
SQLStore.chanUpdatesInHorizonV2. This mirrors the existing v1
time-based query but filters on policy block_height instead of
last_update, using the same [start, end) exclusive-end semantics
and (max_block_height, channel_id) compound cursor pagination.

Also adds extractMaxBlockHeight helper (returns the max of both
policies' block heights for cursor tracking) and
buildChannelFromBlockRangeRow (structurally identical to the v1
variant but accepts the distinct sqlc-generated row type). The
extractChannelPolicies type-switch is extended with a case for the
new GetChannelsByPolicyBlockRangeRow type.

graph/db: add ChanUpdateRange and NodeUpdateRange types

Add version-aware range types for channel and node update horizon
queries. V1 gossip uses unix timestamps for ordering while v2 uses
block heights, so each range type validates that the correct bound
type is provided for the requested gossip version.

These types will be used in follow-up commits to version the
NodeUpdatesInHorizon and ChanUpdatesInHorizon Store methods.

sqldb: add composite indexes for v2 block-height horizon queries

Add composite indexes on graph_nodes and graph_channel_policies for
the upcoming v2 block-height-based horizon queries.

The v2 gossip protocol uses block heights instead of unix timestamps
for ordering node announcements and channel updates. The v2
NodeUpdatesInHorizon and ChanUpdatesInHorizon query paths will
filter on WHERE version = @v AND block_height >= start AND
block_height < end. Without these indexes, those queries would
require full table scans.

For nodes, the index is (version, block_height, pub_key). Including
pub_key covers the ORDER BY (block_height, pub_key) clause and
allows direct cursor seeks for pagination, avoiding an extra sort.

For channel policies, the index is (version, block_height). The
pagination cursor uses a CASE expression across two joined policy
rows so the index cannot cover the ORDER BY — the two leading
columns are sufficient for the range scan.

graph/db: use exclusive end time for horizon queries per BOLT 07

BOLT 07 specifies that gossip_timestamp_filter range semantics are
"greater or equal to first_timestamp, and less than first_timestamp
plus timestamp_range", i.e. [start, end). Three of the four
implementations (KV ChanUpdatesInHorizon, KV NodeUpdatesInHorizon,
SQL NodeUpdatesInHorizon) were incorrectly using an inclusive end
time (<= instead of <). Only SQL ChanUpdatesInHorizon was correct.

This commit fixes the KV store's fetchNextChanUpdateBatch and
fetchNextNodeBatch to use >= (instead of >) for the end time break
condition, and < (instead of <=) for the hasMore check. It also
fixes the SQL GetNodesByLastUpdateRange query to use < instead of <=
on the end_time bound.

All godocs are updated to reference the BOLT 07 spec language and
explicitly document the [start, end) range semantics. New dedicated
tests (TestNodeUpdatesInHorizonExclusiveEnd and
TestChanUpdatesInHorizonExclusiveEnd) verify that items at exactly
the end time are excluded while items at the start time are included.

rpcserver: wire ForwardingLog into router backend

In this commit, we pass the node's ForwardingLog into the RouterBackend
alongside the MinFwdHistoryAge configuration value, completing the
dependency injection chain from the RPC handler down to the database
layer.

docs: add forwarding history privacy guide

In this commit, we add a guide explaining the privacy implications of
retaining forwarding history and how to use DeleteForwardingHistory to
implement a data retention policy. The guide covers the CLI interface,
batch size tuning, cron-based automation, database compaction, fee
accounting considerations, and privacy best practices.

cmd: add deletefwdhistory CLI command

In this commit, we add the lncli deletefwdhistory command that wraps
the DeleteForwardingHistory RPC. The command accepts a time
specification in one of two forms:

--age=<duration> relative duration, e.g. "-90d", "-1M", "-720h"
--before=<unix> absolute Unix timestamp in seconds

An interactive confirmation prompt is shown before deletion proceeds,
which can be suppressed with --force/-f for unattended automation.
The --batch_size flag controls events deleted per database transaction
(default 10000, max 50000).

The response is printed as JSON, consistent with other lncli commands.

itest: add integration tests for DeleteForwardingHistory

In this commit, we add integration tests for the DeleteForwardingHistory
RPC covering four scenarios: basic deletion of all events, partial
deletion by time range, empty database handling, and idempotency.
A time format test validates both the relative duration and absolute
timestamp code paths end-to-end.

Bob's node is started with --routerrpc.min-fwd-history-age=2s so the
tests can exercise the minimum age guard without waiting an hour.

docs: add release-notes for LND 21

lntest: add DeleteForwardingHistory to RPC harness

In this commit, we extend the test harness RPC wrapper to expose the
new DeleteForwardingHistory method, following the established pattern
for router RPC calls with automatic error handling and logging.

onionmessage: use BackpressureMailbox for onion peer actors

This commit adds per-peer backpressure control to the onion message
actor system by introducing a BackpressureMailbox that uses Random
Early Detection (RED) to probabilistically drop messages when the
per-peer queue depth exceeds a configurable threshold.

The OnionActorFactory type now accepts variadic ActorOptions, allowing
the spawn call site (brontide) to provide per-peer mailbox configuration.
A DefaultOnionActorOpts helper provides the standard RED thresholds so
callers don't need to wire up the BackpressureMailbox manually.

Key changes:
- OnionActorFactory signature extended with ...ActorOption[*Request,
*Response] so backpressure policy is no longer baked into the factory.
- NewOnionActorFactory drops its shouldDrop parameter; it forwards opts
through to serviceKey.Spawn.
- DefaultOnionActorOpts(shouldDrop) returns the default backpressure
options (BackpressureMailbox + DefaultOnionMailboxSize).
- peer.Config gains OnionActorOpts callback for per-peer customization.
- server.go creates default opts once and returns them for every peer.

queue: add BackpressureQueue[T] with Random Early Drop

Add a generic BackpressureQueue that uses a DropPredicate to proactively
shed load before the queue is completely full.

Two predicate types are provided:
- DropCheckFunc: length-only drop decision (func(queueLen int) bool)
- DropPredicate[T]: item-aware drop decision

RandomEarlyDrop returns a DropCheckFunc since RED only considers queue
depth. The AsDropPredicate helper adapts it to DropPredicate[T] for use
with BackpressureQueue.

In addition to the blocking Enqueue/Dequeue methods, the queue exposes
TryEnqueue (non-blocking send with drop check), Len, ReceiveChan, and
Close. These are needed by the actor package's BackpressureMailbox which
uses BackpressureQueue as its core buffer while implementing the Mailbox
interface's select-based iteration and lifecycle methods.

Property-based tests using pgregory.net/rapid verify queue invariants
(capacity bounds, FIFO ordering, model consistency) across randomized
enqueue/dequeue sequences with RED enabled.

actor: add BackpressureMailbox and custom mailbox support

Add BackpressureMailbox, a Mailbox implementation backed by
queue.BackpressureQueue that consults a queue.DropCheckFunc on every
Send/TrySend to enable RED-style load shedding before the mailbox is
full.

Add MailboxFactory type and ActorOption functional options
(WithMailboxFactory, WithMailboxSize) so callers can inject custom
mailbox implementations when spawning actors via RegisterWithSystem
or ServiceKey.Spawn.