LND

lnwallet/chancloser: move nonce rotation to LocalOfferSent

Move the RemoteCloseeNonce update from updateAndValidateCloseTerms to
LocalOfferSent.ProcessEvent. This keeps updateAndValidateCloseTerms
focused on close term validation, and makes the nonce rotation point
explicit in the state machine — it happens when processing the
LocalSigReceived event, alongside signature extraction.

Update TestNextCloseeNonceStorageFromClosingSig to verify that
updateAndValidateCloseTerms no longer modifies RemoteCloseeNonce.

lnwire: add LocalNonces TLV structure and tests

This commit introduces a new TLV structure LocalNoncesData that contains
a map of transaction IDs to MuSig2 nonces. This structure enables
coordinating multiple nonces for different purposes (e.g., channel
commits, splice operations) within a single wire message.

This is a prep for upcoming spec changes to allow a party that has
in-prorgess splices to tell the remote party which nonces to use for
which splice.

lncli: add `sign` subcommand to `lncli wallet psbt`

Adds a new sub command `lncli wallet psbt sign` to `lncli` that calls
the wallet RPC's `SignPsbt` method.

lnwire: validate MuSig2 nonce points on wire decode

Add point-on-curve validation for MuSig2 public nonces at the TLV
decode layer. A MuSig2 nonce is 66 bytes (two 33-byte compressed
secp256k1 public keys). Previously, nonce bytes were accepted without
validation, with invalid points only failing later during MuSig2
session creation deep in the signing flow. Now, malformed nonces from
a peer are rejected immediately at decode time with clear errors.

This hardens all nonce-carrying messages: ClosingComplete (JIT closer
nonces in PartialSigWithNonce), ClosingSig (NextCloseeNonce), Shutdown,
ChannelReestablish, CommitSig, and others.

channeldb: add V2 (taproot) waiting proof codec support

Introduce the WaitingProofInner interface and two concrete
implementations — V1WaitingProof (AnnounceSignatures1) and
V2WaitingProof (AnnounceSignatures2 + optional aggregate MuSig2 nonce).

WaitingProof.Encode/Decode now dispatch on the type prefix byte added
in the previous commit, so the store can transparently persist either
proof variant.

The gossiper is updated with a V1 type assertion to maintain existing
behaviour; full V2 gossiper integration will follow when taproot channel
announcements are wired up.

No live code path creates V2 waiting proofs yet — this commit only
lands the codec and storage readiness so the schema is in place before
new writers are introduced.

channeldb: add type-prefix to waiting proof store records

Existing waiting proof records encode a bare isRemote flag followed by a
raw AnnounceSignatures1 payload. A future gossip v2 implementation will
store AnnounceSignatures2 (taproot) proofs in the same bucket, so each
record needs a discriminator byte to select the correct decoder.

This commit:

1. Defines WaitingProofTypeV1 (= 0x00) for the current
AnnounceSignatures1-based proofs.
2. Updates WaitingProofKey to 10 bytes [proofType(1) || scid(8) ||
isRemote(1)] to avoid cross-version key collisions.
3. Adds migration 35, which rewrites every existing record to prepend
the type byte and rewrites keys to the new format.
4. Updates WaitingProof.Encode/Decode to always write/expect the prefix.

The migration, codec changes, and tests are kept in one atomic commit so
there is no intermediate revision where the new Decode can encounter
unmigrated records.

graph,discovery: version IsZombieChannel

Change the IsZombieChannel / isStillZombieChannel function signature
throughout the gossip and routing stacks from
func(time.Time, time.Time) bool to func(ChannelUpdateInfo) bool.

This allows zombie detection to inspect the full channel update info—
including version and freshness type—rather than receiving two raw unix
timestamps that carry no meaning for v2 channels.

Builder.IsZombieChannel is updated to extract version-appropriate
freshness from the ChannelUpdateInfo: unix-time expiry for v1, and a
block-count expiry (derived from ChannelPruneExpiry and
avgBitcoinBlockTime) for v2. The gossipSyncer, SyncManager, and gossiper
Config fields are updated to use the new signature.

graph/db: version FilterChannelRange

Add a gossip version parameter to FilterChannelRange in the Store interface,
both KV and SQL implementations, and the ChannelGraph wrapper.

KVStore guards against non-v1 versions with ErrVersionNotSupportedForKVDB.
SQLStore accepts any known gossip version, filtering the channel results by
version and using it in policy lookups. The SQL query still uses
GetPublicV1ChannelsBySCID for now (a TODO marks where a version-aware query
will be substituted in a follow-up).

VersionedGraph.FilterChannelRange shadows the ChannelGraph method with a
version-free signature, passing its baked-in version to the store. This keeps
the ChannelGraphTimeSeries interface and ChanSeries implementation unchanged.

Add TestFilterChannelRangeVersionGuard to verify that the KV store returns
ErrVersionNotSupportedForKVDB for v2 requests while the SQL store handles
them gracefully.

mod+multi: bump neutrino to v0.16.2, btcwallet to 70a94ea39e9c

In this commit, we update our two core chain backend dependencies:
neutrino is bumped from v0.16.1 to v0.16.2, and btcwallet is updated
to commit 70a94ea39e9c (a pre-release past v0.16.17).

The updated btcwallet changes the `chain.Interface` `Start` method
signature from `Start() error` to `Start(context.Context) error`. The
same change was made to neutrino's `ChainService.Start`. We update all
call sites and interface implementations across the codebase to pass a
`context.Background()` at non-test call sites, and `t.Context()` in
tests.

The affected packages are: chainntnfs/bitcoindnotify, chainreg,
config_builder, lnmock, lntest/unittest, lnwallet/btcwallet,
lnwallet/test, and routing/chainview.

Merge pull request #9637 from Roasbeef/chan-type-required

feature: start to set the require bit for channel_type

payments/migration1: freeze lnwire and record dependency

Also freeze the lnwire and record packages used by the migration.

Copy the minimal subset of lnwire files (16) into
payments/db/migration1/lnwire/ and all record files (6) into
payments/db/migration1/record/. Three lnwire files are trimmed to avoid
pulling in the full message-type dispatch tree — all changes are purely
subtractive and can be verified with:

diff lnwire/message.go payments/db/migration1/lnwire/message.go
diff lnwire/writer.go payments/db/migration1/lnwire/writer.go
diff lnwire/lnwire.go payments/db/migration1/lnwire/lnwire.go

All migration1 files now import only the frozen packages, removing the
live dependency on lnwire and record so future changes to those packages
cannot affect migration correctness.

graph/db/migration1: fix defer commit/rollback in test tx executor

The defer closure checked a local err variable for commit/rollback
decisions, but err remained nil after a successful BeginTx. When
txBody failed, the error was returned directly without assigning to
err, so the defer always committed instead of rolling back.

Additionally, since err was not a named return value, the defer's
Commit error assignment was silently swallowed.

Replace the error-prone defer pattern with explicit rollback on
txBody failure and a direct Commit return.

scripts: switch verify-install.sh from curl to wget

Replace curl with wget for downloading release manifests and
signatures in verify-install.sh. wget handles redirects, retries, and
error reporting more robustly by default, which avoids silent download
failures that caused misleading "Invalid signature!" errors.

Also add error checking to all download calls so failures are reported
immediately with the URL that failed, and log which signature file and
user failed gpg verification.

scripts: log failing signature details in verify-install

When gpg --verify fails, include the signature filename, username,
and full GPG output in the error message. Previously only a generic
"Invalid signature!" was printed, making it hard to identify which
signer's signature was invalid.

graph/db: treat empty channel signatures as missing

This commit improves handling of missing channel signatures in the
database:

- Return nil from auth proof accessors instead of empty slices so that
missing signatures are stored as NULL in SQL.
- Update public channel checks to require signature length > 0, which
properly handles existing empty bytea values in the database.
- Add regression test covering empty v1 and v2 channel signatures to
prevent future issues.

graph/db: support v2 channel proofs in AddEdgeProof

Update AddEdgeProof to handle both v1 (four separate signatures) and
v2 (single aggregated signature) channel authentication proofs using
the appropriate SQL queries.

graph/db: add version parameter to IsPublicNode

Make IsPublicNode version-aware by routing to the appropriate SQL
query based on gossip version. V1 and v2 have different criteria for
determining node publicity (v1 requires four signatures, v2 requires
one). Convert TestNodeIsPublic to versioned test for both protocols.

sqldb/sqlc: add IsPublicV2Node query

Add SQL query to determine if a node has public v2 channels. Unlike
v1 which requires all four individual signatures, v2 channels are
considered public when the single aggregated signature is present.

sqldb/sqlc: add AddV2ChannelProof query

Add SQL query to update the signature column for v2 channel auth proofs.
Unlike v1 which requires four separate signatures, v2 channels use a
single aggregated signature.

graph/db: add version parameter to createEdge test helper

Extend the createEdge test helper to accept a gossip version, enabling
creation of both v1 and v2 test channels. V2 channels include the
appropriate auth proof (single signature), merkle root hash, and
funding script fields.

multi: update models.ChannelAuthProof with v2 field

Also update it to more closely match the persisted version which has the
v1 and v2 only fields as optional.

Refactor ChannelAuthProof to support both v1 and v2 channel
announcements:

- Add Version field to distinguish v1 from v2 proofs
- Wrap v1-specific fields (NodeSig1/2, BitcoinSig1/2) in fn.Option
since v2 doesn't use them
- Add optional Signature field for v2's single schnorr signature
- Add constructor functions NewV1ChannelAuthProof and
NewV2ChannelAuthProof to enforce correct initialization
- Add getter methods (NodeSig1(), BitcoinSig1(), etc.) that safely
unwrap options, returning empty slices when not present

The IsEmpty() check is updated to handle both versions correctly.
Both stores validate v1-only for now.

graph/db: update SQLStore to read and write v2 channels

Extends the SQL store to support v2 (taproot) channel announcements:
- Add version validation in AddChannelEdge
- Store v2-specific fields: FundingPkScript, MerkleRootHash, Signature
- Update buildEdgeInfoWithBatchData to reconstruct v2 channels from DB
with optional bitcoin keys and funding script handling
- Add WithMerkleRootHash edge modifier for ChannelV2Fields

sqldb/sqlc: update graph CreateChannel query for v2

Add three new optional fields to the CreateChannel SQL query to
support v2 channel announcements:
- signature: single schnorr signature (replaces four ECDSA sigs)
- funding_pk_script: the funding output script
- merkle_root_hash: for taproot channels

These fields are NULL for v1 channels and populated for v2 channels.

graph/db: remove unused sig field from ChannelEdgePolicy

Remove the cached parsed signature field and its lazy getter method
from ChannelEdgePolicy. This field was unused throughout the codebase
and the signature is already stored as raw bytes in SigBytes.

The SetSigBytes method is updated to remove the cache invalidation
logic.

actor: introduce generic Mailbox interface with iter.Seq support

This commit introduces a new Mailbox interface that abstracts the
message queue implementation for actors. Previously, actors used a
direct channel for their mailbox, which limited flexibility and made
it difficult to implement alternative mailbox strategies.

The new Mailbox interface provides methods for sending, receiving, and
draining messages, with full context support for cancellation. The
Receive method leverages Go 1.23's iter.Seq pattern, providing a clean
iterator-based API that allows natural for-range loops over messages.

The ChannelMailbox implementation maintains the existing channel-based
behavior while conforming to the new interface. It stores the actor's
context internally, ensuring both caller and actor contexts are
properly respected during send and receive operations. This simplifies
context handling compared to complex context merging approaches.

This abstraction enables future implementations such as priority
mailboxes, persistent mailboxes, or bounded mailboxes with overflow
strategies, without requiring changes to the actor implementation.