LND

multi: drop tor v2 onion production, keep wire codec faithful

Tor stopped serving v2 onion services in October 2021; lnd should not
produce v2 addresses anymore, but it must still verify signatures on
and re-broadcast peer NodeAnnouncement messages that carry v2 entries.

Stop accepting v2 as configuration input (lncfg), strip the legacy
`--tor.v2` flag from the sample config, and remove the
`tor.OnionHostToFakeIP` helper. Operator entry points (`--externalip`,
`--listen`, `lncli connect`, `lncli wtclient towers add`) fail fast on
a v2 `.onion` string, so upgrading nodes must remove any v2 entry from
`lnd.conf` before lnd will start.

Filter persisted v2 state before use without rewriting on-disk records:
the self-announcement builder strips any v2 entry inherited from the
stored self-node; the watchtower client drops v2 entries from each
persisted tower's address list (skipping the tower entirely if no
non-v2 address remains); the autopilot connector, graph bootstrapper,
and static-channel backup restore paths skip v2 entries before
attempting outbound dials. Restrict the Tor controller's ADD_ONION
path to v3 keys, including the encrypted on-disk legacy-key fallback.

For inbound announcements, keep the wire codec wire-faithful:
`lnwire.WriteOnionAddr`, `graph/db.encodeOnionAddr`, and the matching
decoders round-trip v2 bytes so `DataToSign` reproduces the bytes the
remote peer signed, signature validation succeeds, and the announcement
is persisted to the graph DB and re-broadcast across restarts byte-for-
byte. RPC surfaces continue to expose the full address set so external
tools can independently reproduce and verify the signed bytes.

Add a netann regression test that signs a [v3, v2, ipv4] announcement,
round-trips it through Encode/Decode, verifies the signature, and
confirms the resulting models.Node preserves the v2 entry. Add a
graph bootstrapper test asserting v2 entries are skipped while v3 and
plain TCP entries on the same node still surface as bootstrap
candidates.

itest: assert sweep outpoint mined after RBF

contractcourt+itest: tests for coop close insta-dispatch

In this commit, we add three focused unit tests in contractcourt
plus an itest that exercises the regression end-to-end.

The chain watcher harness gains an opt-in early-dispatch capture that
records every notifyEarlyCoopClose invocation so tests can assert how
many fired and what summaries they carried. On top of that:

TestEarlyDispatchCoopClose verifies the headline behavior. An
async-path coop close fires exactly one early dispatch with
IsPending=true and the post-N-conf flow still produces the regular
CooperativeCloseInfo downstream.

TestEarlyDispatchForceCloseNotInvoked guards the carve-out: force
closes never fire the early dispatch since their CLOSED_CHANNEL
event timing is intentionally unchanged.

TestEarlyDispatchReorgRefiresOnReReplacement nails down the reorg
path. Once a deep reorg removes the close, the early-dispatch flag
is cleared and the next coop close re-fires the early event with its
own summary, so a subscriber observes each distinct close attempt.

testZeroConfCoopCloseSubscribeEvents brings up a zero-conf channel
between Alice and Bob with --dev.force-channel-close-confs=3 so the
chain watcher takes the async multi-confirmation path. Alice
subscribes to channel events, initiates a cooperative close, and the
test asserts that CLOSED_CHANNEL fires after only one confirmation
of the close tx (not after the full three) and that
FULLY_RESOLVED_CHANNEL arrives once the close has reached three
confirmations. A quiet-window assertion at the end verifies that
exactly one CLOSED_CHANNEL event is delivered. If the suppression in
MarkChannelClosed broke and let it re-fire NotifyClosedChannel at N
confs, this assertion would catch the duplicate.

contractcourt+server: insta-dispatch CLOSED_CHANNEL on first conf

PR #10331 introduced a multi-confirmation reorg-aware dispatch in the
chain watcher. In production builds CloseConfsForCapacity is at least
3, so the chain watcher waits for three confirmations of a close tx
before running dispatchCooperativeClose, MarkChannelClosed, and
NotifyClosedChannel. Subscribers of the SubscribeChannelEvents stream
that used to receive a CLOSED_CHANNEL event after a single
confirmation in v0.20.1 stopped seeing the event entirely on shorter
test cycles and were delayed by two extra blocks on longer ones. This
is the regression alexbosworth reported on zero-conf channels.

The intent behind the original change was to wait three confirmations
under the hood for reorg safety while still dispatching a
CLOSED_CHANNEL event to RPC subscribers immediately, matching the
v0.20.1 surface. That insta-dispatch was wired into
peer.WaitForChanToClose for the local CloseChannel response stream
but was never extended to the channel-notifier path that drives
SubscribeChannelEvents.

In this commit, we wire a new optional notifyEarlyCoopClose callback
into the chain watcher's processDetectedSpend. The first time a coop
close spend is detected on chain, the chain watcher synthesizes a
ChannelCloseSummary with IsPending=true and dispatches a
CLOSED_CHANNEL event over the channel notifier, no DB round-trip
required. The callback is plumbed through ChainArbitratorConfig
.NotifyEarlyClosedChannel to the new
ChannelNotifier.NotifyEarlyClosedChannelEvent. The summary builder
shared with dispatchCooperativeClose is extracted into
buildCoopCloseSummary so the early and post-N-conf paths produce
equivalent payloads.

A coopCloseEarlyDispatched flag on the chain watcher keeps the
dispatch idempotent across blockbeat replays of the same spend, and
the closeObserver clears it on negativeConfChan so a re-mined or
replacement close after a deep reorg re-fires the preliminary event
with its own summary. The early-dispatch call sits before the
fast-path check so numConfs==1 also fires the early event through the
same code path.

Suppressing the duplicate notify at MarkChannelClosed time happens
inline in the chain_arbitrator MarkChannelClosed callback: after
CloseChannel succeeds, NotifyClosedChannel is fired only when the
close type is not CooperativeClose. Force, breach, and abandon paths
intentionally remain on the existing N-confirmation dispatch contract.

channelnotifier: add NotifyEarlyClosedChannelEvent

Today NotifyClosedChannelEvent rebuilds its event by round-tripping
through FetchClosedChannel, which forces the caller to have already
persisted the close summary to the closed-channel bucket. The chain
watcher needs to surface a CLOSED_CHANNEL event to RPC subscribers as
soon as a coop close spend is first detected on chain, well before
the close has reached the required confirmation depth at which the
state machine would normally call MarkChannelClosed.

In this commit, we add NotifyEarlyClosedChannelEvent, which dispatches
a ClosedChannelEvent built from a caller-supplied summary directly
through the subscribe server. The summary is expected to carry
IsPending=true so subscribers can recognize that the close has not
yet been finalized in the database.

Two unit tests assert that the new path delivers the supplied summary
verbatim and produces exactly one event per call.

docs: clarify taproot channel open defaults

funding: reject public taproot opens before sending

funding: require explicit taproot channel negotiation

multi: rename "taproot" channel type to mean production variant

In this commit, we shuffle the CLI and RPC names so the bare "taproot"
identifier refers to the production taproot channel type (final
scripts, feature bits 80/81), i.e. the variant new integrations should
actually be using. Before this commit, "taproot" on the CLI mapped to
the staging bits, and anyone who wanted a real production taproot
channel had to spell out "taproot-final" on `lncli openchannel` or
`SIMPLE_TAPROOT_FINAL` over RPC. The recommended choice was hidden
behind the longer name.

On the CLI (`lncli openchannel --channel_type=...`):

- "taproot" now selects the production variant (it used to mean
staging).
- "taproot-staging" is added for the legacy development bits, for
peers that haven't moved over yet.
- "taproot-final" stays as a deprecated alias for "taproot" so
existing scripts don't break.

On the RPC (`CommitmentType`):

- `TAPROOT = 7` is added as the canonical name for the production
type. `SIMPLE_TAPROOT_FINAL = 7` is kept as a deprecated alias via
`option allow_alias = true`, so existing clients keep compiling
against the same Go constant and the wire value doesn't change.
- `SIMPLE_TAPROOT = 5` (staging) is unchanged.
- `SIMPLE_TAPROOT_OVERLAY = 6` is unchanged. The taproot-assets
daemon hard-codes this distinct enum value, so it's unaffected.

Wire compat is preserved end-to-end: only the comments, enum entry
order, and the CLI string-to-enum mapping change. The numeric values
and the existing generated Go identifiers stay stable.

multi: update neutrino dep to include chainimport and header state fix

Update the neutrino dependency to a version that includes the
chainimport package for fast initial header sync, and the
ResetHeaderState fix that allows P2P sync to continue after import.

The updated neutrino dependency changes the ChainService.Start method
signature to accept a context.Context parameter. Update all call sites
to pass context.TODO() to maintain existing behavior.

config_builder: wire neutrino header import config

Pass the configured BlockHeadersSource and FilterHeadersSource into
neutrino's HeadersImportConfig when initializing the neutrino backend.
Set blockchain.BFFastAdd validation flags for regtest and simnet to
skip contextual timestamp checks on rapidly-mined blocks.

Call Validate on the neutrino config before proceeding to catch
misconfiguration early.

itest: add neutrino headers import integration test

Add an integration test that verifies neutrino header import from local
files. The test mines blocks, starts a reference node to generate header
files via normal P2P sync, copies those files with import metadata, then
starts a new node configured to import headers from the prepared files.

The test verifies the import node syncs to the chain tip and can
continue syncing additional blocks mined after import via P2P, exercising
the hybrid import-then-P2P sync path.

docs: add neutrino headers import documentation

Document the neutrino fast sync feature that allows importing block and
filter headers from local files or HTTP URLs on startup. Cover
configuration for mainnet (block-dn.org), testnet3, testnet4, signet,
file format details, security considerations, and troubleshooting.

lncfg: add neutrino header import source config fields

Add BlockHeadersSource and FilterHeadersSource fields to the Neutrino
config struct. These accept either local file paths or HTTP(S) URLs
pointing to pre-built header files for fast initial sync.

Add a Validate method that ensures both sources are specified together
or both are empty.

sample-lnd.conf: document neutrino header import options

Add commented examples for the new neutrino.blockheaderssource and
neutrino.filterheaderssource options, showing both URL-based import
from block-dn.org and local file path usage.

routerrpc: pass outgoing channels to probe requests

rpcserver: filter backup subscription events

Channel update notifications now flow through ChannelNotifier, so the
existing backup subscription deny-list started treating commitment
updates as backup-relevant events. This makes SubscribeChannelBackups
emit on every channel update, even though those updates can happen much
more frequently than lifecycle changes.

Switch the backup subscription to an allow-list of lifecycle events that
should trigger the stream. Also document that ChannelNotifier includes
high-frequency state updates, so lifecycle-only consumers should filter
explicitly.

lnwallet/rpcwallet: accept zero-value WitnessUtxo entries in remote-sign prep

Before forwarding a SignOutputRaw request to the remote signer instance,
remoteSign rebuilds a PSBT from the unsigned transaction and annotates
every input with a WitnessUtxo (so the downstream walletkit.SignPsbt
call accepts it — taproot sighash computation requires the prev output
of every input, not just the one being signed).

For non-signed inputs the prep stage first asks the watch-only wallet
about the outpoint via FetchOutpointInfo, then — when the wallet does
not own or track the outpoint — falls back to the sign descriptor's
PrevOutputFetcher. The fallback previously required `utxo.Value != 0`,
which silently dropped legitimate zero-value entries on the floor and
left the corresponding PSBT input bare.

The walletkit.SignPsbt entry point on the remote signer then rejected
the PSBT with "input (index=N) doesn't specify any UTXO info" because
input N had neither a WitnessUtxo nor a NonWitnessUtxo annotation.

BIP-322 (signing virtual transactions for message attestation) is the
canonical hitter: its to_spend output is mandated by the BIP to be
exactly value=0 with the message commitment as pk_script, and that
output is referenced as input 0 of every BIP-322 to_sign transaction.
Any caller that drives a BIP-322 sign through a remote-signer LND
deployment was failing for this reason.

The validation we actually want is that the fetched prev output is
representable as a usable WitnessUtxo: non-nil and with a non-empty
pk_script. Drop the Value check; the zero-value case is well-formed
and the resulting PSBT input will serialize cleanly. The fetched-but-
empty-pk_script case continues to be rejected (a WitnessUtxo with
empty PkScript is malformed at PSBT serialization), and the warning
log when no fallback resolves the outpoint is preserved verbatim.

Lift the WitnessUtxo-population loop out of remoteSign into a
package-level helper so the resolution policy is unit-testable without
spinning up a real wallet + remote signer pair. The helper takes a
fetchOutpointInfoFn callback that mirrors
lnwallet.WalletController.FetchOutpointInfo. No behavior change for
the wallet-owns-it path or the no-fallback path.

lnwallet/rpcwallet: add unit tests for WitnessUtxo population helper

Cover the four resolution branches plus the BIP-322 regression case:

- wallet-owns-it: FetchOutpointInfo returns a Utxo, helper writes
the matching WitnessUtxo into the PSBT input.
- external-fallback: wallet returns ErrNotMine, helper writes the
WitnessUtxo from the sign descriptor's PrevOutputFetcher.
- zero-value-fallback: same as above with the fetched entry's Value
set to zero. This is the BIP-322 to_spend shape (input 0 of every
BIP-322 to_sign references a virtual prev whose Value is mandated
to be zero); the helper must populate the WitnessUtxo rather than
silently skip it.
- no-fallback: wallet returns ErrNotMine and no PrevOutputFetcher
is provided; the helper leaves the input bare and the warning log
fires (asserted only by absence of a populated WitnessUtxo).
- empty-pk_script-fallback: the fetcher returns a non-nil entry
with an empty PkScript; the helper rejects it as unusable (the
PSBT WitnessUtxo serializer requires a non-empty script) and
leaves the input bare.

The signed input (signDesc.InputIndex) is intentionally left untouched
by the helper — that input is the one the caller's main path will
populate later — and the tests cross-check that invariant on the
wallet-owns-it case.

docs: release-note zero-value WitnessUtxo remote-sign fix

Add the bug-fix entry under 0.21.0 with a link to the PR.

proto: remove deprecated SendPayment, SendToRoute, TrackPayment RPCs

Remove the following deprecated RPC definitions that were announced for
removal in 0.21 via the 0.20 release notes:

lnrpc:
- SendPayment (bidirectional streaming)
- SendPaymentSync
- SendToRoute (bidirectional streaming)
- SendToRouteSync

routerrpc:
- SendPayment (streaming)
- SendToRoute
- TrackPayment (streaming)

Also remove the now-unused PaymentState enum and PaymentStatus message
that were only used by the deprecated TrackPayment response stream, plus
the corresponding REST annotations from the yaml files.

Drop the now-orphan routerrpc.SendToRouteResponse message that was only
referenced by the deleted routerrpc.SendToRoute RPC.

Also remove the deprecated outgoing_chan_id field from
lnrpc.QueryRoutesRequest (tag 14) and routerrpc.SendPaymentRequest
(tag 8); their tag numbers are now reserved. Callers must use the
multi-channel outgoing_chan_ids field introduced in 0.20.

Drop the compat fallback in router_backend.go that previously consumed
the field, and regenerate all protobuf, gRPC, REST gateway, JSON, and
swagger files.

docs: document deprecated RPC and field removals in 0.21 release notes

Add entries to the Breaking Changes section covering the payment and
tracking RPCs and the `outgoing_chan_id` field removed in this branch,
all of which were announced for removal in 0.21 via the 0.20 release
notes.

lnwire_test: add createValidTLVExtraData

In this commit, we added createValidTLVExtraData which creates a
valid TLV data, and use it in place of createExtraData for messages
that their Encode or Decode requires validating the TLV data, which
were failing initially.

lnwire_test: add onion message to makeAllMessages

In this commit, we include onion message to the list of lnwire
messages for benchmark testing.

docs: add release note for EstimateRouteFee outgoing chans