LND

lnwallet/test: fix flaky neutrino reorg sync timeout

waitForWalletSync used time.Tick inside the poll loop, leaking a new
goroutine on every iteration. Over 5 reorg cycles with ~300 polls each
this accumulated up to 1500 leaked goroutines, adding measurable system
load that made the 30s timeout too tight, especially when running against
a postgres backend where block-processing writes carry more overhead.

Fix the leak by using a single time.NewTicker (deferred Stop), and raise
the timeout to 2 minutes to give the neutrino P2P layer and the
address-manager transaction walk enough headroom under load.

Also improve the timeout error messages to identify which of the two
sync layers was stuck:
- Layer 1 (header/P2P): ChainIO.GetBestBlock height has not yet caught
up to the miner tip — neutrino is still fetching headers.
- Layer 2 (transaction walk): heights matched but IsSynced() never
returned true — the chain-sync notification or the address-manager
DB write (undo+redo on reorg) did not complete in time.

Add a detailed doc comment to waitForWalletSync explaining the three
pipeline stages (header sync, compact-filter/block fetch, transaction
walk) and why each stage is relevant, so a future timeout can be
diagnosed from the error message alone.

lnwallet/chancloser: create unique ServiceKey for the RBF chan closer

This can be used to allow any system to send a message to the RBF chan
closer if it knows the proper service key. In the future, we can use
this to redo the msgmux.Router in terms of the new actor abstractions.

lncfg+config: add tunable onion message rate limit options

In this commit we surface the onion message rate limiter thresholds as
ProtocolOptions so that operators can tune them from lnd.conf or the
command line. Four options are added — onion-msg-peer-rate,
onion-msg-peer-burst, onion-msg-global-rate, and onion-msg-global-burst —
and are documented such that a rate of zero disables the corresponding
limiter entirely. The default values are seeded from the constants added
in the previous commit via DefaultConfig, following the same pattern that
the Gossip sub-config already uses for its own rate limiter knobs.

The fields are duplicated into protocol_integration.go so that the
integration build tag sees the same surface; this mirrors how the
existing NoOnionMessagesOption and related fields are declared.

lncfg+peer+server: add protocol.onion-msg-relay-all to bypass channel gate

Add a new protocol option, protocol.onion-msg-relay-all, that controls
whether incoming onion messages are required to come from peers with a
fully open channel. The default is false, which preserves the existing
behavior: the channel-presence gate drops messages from peers with no
channel before the rate limiters are consulted, so a new no-cost
identity cannot burn any per-peer byte budget and saturate the global
bucket. Setting the flag to true skips the gate so that onion messages
from any peer are admitted into the per-peer + global IngressLimiter
pipeline.

The flag is plumbed through ProtocolOptions in both the default and
integration build variants of lncfg/protocol*.go, threaded into the
peer subsystem as peer.Config.OnionRelayAll, and wired by the server
from s.cfg.ProtocolOptions.OnionMsgRelayAll alongside the existing
OnionLimiter field. allowOnionMessage gains a relayAll bool parameter;
the gate check becomes "if \!relayAll && \!hasChannel { drop }" so the
semantics of hasChannel stay pure — it still means "this peer has a
channel" — and the policy toggle lives entirely in the caller's
configuration rather than being spread across gate-state and flag
state.

sample-lnd.conf gains a commented-out entry for the new option with
the default value and an operator-facing note that enabling it trades
the Sybil-resistance property of the gate for reachability to peers
with whom we have no channel.

A new TestAllowOnionMessageRelayAll unit test exercises the four
(hasChannel, relayAll) combinations at the helper level, including
the key new behavior — a peer with hasChannel=false being rejected
under relayAll=false and admitted into the limiter under
relayAll=true — and the nil-limiter path under relayAll=true, which
must still accept. The existing allowOnionMessage tests were
extended with the new parameter set to false so they continue to
assert the gate semantics unchanged.

multi: add SCB restore support for production taproot channels

Add the missing SimpleTaprootFinalVersion case to
chanrestore.openChannelShell() so that SCB backups created for
production taproot channels can be properly restored. Without this,
the channel type bits were not reconstructed during restore, causing
DLP to fail.

Also add integration tests for both confirmed and zero-conf variants
of production taproot channel backup restoration.

lnwallet: fix HTLC trimming test case to use dust_limit for zero-fee HTLCs

In this commit, we fix the "commitment tx with some HTLCs trimmed" test
case to actually exercise trimming for taproot's zero-fee HTLC
transactions.

With zero-fee second-level HTLCs, the HTLC output value on the
commitment transaction equals the HTLC amount directly (no fee is
deducted). This means trimming is determined solely by whether the HTLC
amount falls below the dust limit, not by the fee rate. The previous
parameters (fee_per_kw=100000, dust_limit=546) didn't actually trim any
of the test HTLCs because even the smallest test HTLC (1000 sats) was
above the 546 sat dust limit.

We now use fee_per_kw=644 (a reasonable rate) and dust_limit=2500 to
ensure that the three smallest test HTLCs (1000, 2000, 2000 sats) are
properly trimmed, leaving only the 3000 and 4000 sat HTLCs on the
commitment transaction.

watchtower: add production taproot channel support to justice kit

Wire channel type through BreachRetribution and the watchtower blob
system to support production taproot channels with final scripts.

The key changes are:

1. Add ChanType field to BreachRetribution so downstream consumers
(including the watchtower) can determine the script variant.

2. Add FlagTaprootFinalChannel blob type flag and
TypeAltruistTaprootFinalCommit blob type to distinguish production
from staging taproot channels in watchtower backups.

3. Add TaprootFinalCommitment to the watchtower's CommitmentType enum
with appropriate witness type and size mappings.

4. Update taprootJusticeKit to use WithProdScripts() when constructing
script trees for production taproot channels. The isFinal flag is
set during construction from BreachRetribution.ChanType and during
deserialization from the blob's commitment type.

Without this change, the watchtower would construct justice transactions
using staging scripts for production taproot channels, resulting in
invalid witnesses that fail to sweep breached outputs.

multi: fix linter issues

Fix gci (extra blank lines) and ll (line length > 80 chars) issues
across contractcourt, input, and watchtower packages.

multi: use feature bits to pick which taproot nonce field to use

Before this commit, we'd _always_ set both nonces fields, for both the
staging and the final taproot channels type.

With this commit, we've switched to only setting the new nonce map field
for the final taproot feature bit type.

lnwallet: return error from AggregateNonces in MusigSession

Fix swallowed error in MusigSession.Refresh where AggregateNonces
failure returned nil instead of the actual error.

multi: fix linter issues

cmd/commands: add taproot-final to lncli open command

lnwallet: add support for local nonces map in revoke_and_ack

We only ever set a single nonce, but we'll check both fields to make
sure that at least one of them is set.

itest: extend relevant itests to cover taproot chans final

lnrpc/walletrpc: add witness types for taproot chans final

lnwallet: integrate production script options in commitment generation

This commit updates the wallet's commitment transaction generation logic to
use appropriate script options based on the channel type. The commitment
builder now determines whether a channel uses production taproot scripts
and passes the WithProdScripts() option accordingly to HTLC script generation
functions.

The changes affect three key areas of the wallet: channel state management,
commitment transaction construction, and funding reservation handling. Each
area now properly detects production taproot channels using the IsTaprootFinal()
method and applies the correct script generation options to ensure consistency
with the channel's script optimization level.

This integration ensures that production taproot channels generate commitment
transactions with optimized script trees using OP_CHECKSIGVERIFY, while
maintaining full compatibility with staging taproot and legacy channel types.
The script option selection is applied consistently across all commitment
transaction scenarios including local commits, remote commits, and HTLC
processing.

sqldb/v2: enforce require ssl mode

Apply the RequireSSL config knob when opening Postgres stores
so it cannot be silently ignored.

Before this change, sqldb/v2 exposed PostgresConfig.RequireSSL
but still opened cfg.Dsn verbatim, which meant RequireSSL=true
was a no-op. A caller could set RequireSSL=true together with a
DSN such as sslmode=disable and still establish a non-TLS
connection.

This is a v2-only API contract bug, not a v1 regression in DSN
handling: v1 never offered a separate RequireSSL flag and always
left TLS policy entirely up to the DSN. The fix rewrites the DSN
to use sslmode=require when needed, while preserving stricter
modes such as verify-ca and verify-full.

The bug was easy to miss because no test asserted that the boolean
flag changed the effective DSN or overrode an insecure sslmode.
Keep the focused DSN rewrite test because it proves the contract
without needing a live Postgres instance.

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.

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.

lnwallet/chancloser: fix flaky test assertions

Restore the defaultTimeout constant (500ms) that was lost during the
PR's commit squash, where the hardcoded 10ms replaced it. The 10ms
value was too tight and caused timeouts under -race -count=N.

Also fix assertSingleRemoteRbfIteration to consume both iteration
transitions in a single assertStateTransitions call. When
iteration=true, the state machine emits two ClosingNegotiation
transitions from a single event (via internal events). Making two
separate assertStateTransitions calls races with the "no more states"
check, which could drain the second transition before the second
assertion consumed it.

lnwallet/chancloser: use AND for IsTaproot check, use partialSigToWireSig

Change IsTaproot() from OR to AND: both LocalMusigSession and
RemoteMusigSession must be set to consider the channel taproot. This
prevents panics from nil session access when only one session is
initialized.

Also use partialSigToWireSig helper for consistency in
extractSigAndNonceFromComplete instead of inline conversion.

lnwallet/chancloser: address PR review comments

Fix several issues raised in PR review:
- Use safe type assertion in createClosingSigMessage to avoid panic if
localSig is not *MusigPartialSig.
- Fix typo "taprotot" -> "taproot" in comment.
- Remove unnecessary type argument in NewTaprootSigType.
- Simplify nested if to single condition for taproot nonce generation.
- Fix typo "once the no updates" -> "once there are no updates" in
test comments.
- Move misplaced TestRbfCloseClosingNegotiationLocal doc comment to
the correct function definition.

chancloser: update RBF close to match current flow

lnwallet/chancloser: fix rbf close docs