LND

multi: fix linter issues

lnwallet: regenerate test vectors with BIP-340 HTLC signatures

Regenerate the test vector JSON with HTLC second-level transaction
signatures that use BIP-340 standard nonce derivation (zero auxrand)
instead of RFC6979. This makes the HTLC signatures reproducible across
different Schnorr implementations. The commitment transaction MuSig2
signatures are unchanged.

multi: fix linter issues

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

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+input: add production taproot channel integration tests

This commit adds comprehensive integration test coverage for production
taproot channels to validate end-to-end functionality in realistic scenarios.
The tests verify that production taproot channels can be successfully opened,
operated, and closed using the finalized taproot specification with optimized
scripts and feature bits 80/81.

The integration tests cover channel opening with the SIMPLE_TAPROOT_FINAL
commitment type, ensuring that the complete channel lifecycle works correctly
with production taproot features. Test utilities have been enhanced to support
production taproot channel creation and validation, providing the necessary
infrastructure for comprehensive testing scenarios.

Additional unit tests have been added to the input package to validate size
calculations and witness generation for production taproot witness types.
These tests ensure that the new Final witness types produce correctly sized
witnesses and transactions, maintaining the expected efficiency benefits of
the optimized script structure.

The test coverage helps ensure that production taproot channels operate
correctly across all system components while maintaining compatibility with
existing channel types and providing confidence in the production readiness
of the implementation.

funding: add production taproot channel negotiation support

This commit extends the funding manager's commitment type negotiation logic
to handle production taproot channels. The negotiation system now recognizes
and properly processes requests for channels using the final taproot
specification with feature bits 80/81 and optimized script structures.

The commitment type negotiation has been enhanced to distinguish between
staging and production taproot variants during the channel opening process.
When a production taproot channel is requested, the negotiation logic ensures
that both parties support the necessary feature bits and applies the
appropriate channel type configuration including the TaprootFinalBit flag.

Comprehensive test coverage has been added to validate the negotiation
behavior for production taproot channels, ensuring that the funding process
correctly handles feature bit validation, commitment type mapping, and error
conditions. The tests verify that production taproot channels are only
established when both peers indicate support for the finalized taproot
features.

lnwire: add local_nonces field to revoke_and_ack

input: thread script options through taproot HTLC functions

This commit extends the taproot HTLC script generation functions to accept
TaprootScriptOpt parameters, enabling callers to specify whether production
or staging script variants should be generated. The SenderHTLCScriptTaproot
and ReceiverHTLCScriptTaproot functions now accept a variadic opts parameter
that is forwarded to the underlying script tree construction.

This change provides the necessary infrastructure for the wallet and contract
resolution systems to generate the appropriate script trees based on channel
type. Production taproot channels can now pass the WithProdScripts() option
to generate optimized scripts using OP_CHECKSIGVERIFY, while staging channels
continue to use the existing development script structure.

The modification maintains backward compatibility by making the opts parameter
variadic with sensible defaults. Existing callers that do not specify options
will continue to generate staging scripts as before, ensuring no disruption
to current functionality while enabling future production script support.

itest: extend relevant itests to cover taproot chans final

lnrpc/walletrpc: add witness types for taproot chans final

watchtower: prepare infrastructure for production taproot support

This commit adds preparatory infrastructure and TODO markers in the watchtower
justice kit generation for future production taproot channel support. The
changes establish placeholders for channel type detection and script option
selection that will be needed when watchtowers begin handling breach scenarios
for production taproot channels.

The current implementation includes commented code structures that demonstrate
the intended approach for integrating production script options into the
justice transaction generation process. When channel type information becomes
available in the BreachRetribution structure, these placeholders can be
activated to ensure that watchtowers generate justice transactions using the
appropriate script optimization level.

This preparatory work ensures that the watchtower system has a clear path
toward production taproot support while maintaining current functionality
for staging taproot and legacy channels. The TODO comments provide explicit
guidance for future development when watchtower breach handling for production
taproot channels is implemented.

lnrpc+rpcserver: add production taproot commitment type to RPC interface

This commit extends the Lightning RPC interface to support production taproot
channels by adding a new SIMPLE_TAPROOT_FINAL commitment type. This allows
external clients to explicitly request channels that use the finalized taproot
specification with optimized script structures and feature bits 80/81.

The RPC server has been updated to properly handle the new commitment type
during channel opening operations, mapping the SIMPLE_TAPROOT_FINAL type to
the appropriate internal channel type flags including both SimpleTaprootFeatureBit
and TaprootFinalBit. This ensures that channels opened through the RPC interface
are properly configured with production taproot capabilities.

The existing SIMPLE_TAPROOT commitment type has been clarified in its
documentation to indicate that it represents the staging version using
development scripts, providing clear distinction between the two taproot
variants available to RPC clients. The protobuf definitions and generated
code have been updated accordingly to support this new functionality.

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.

contractcourt: implement production taproot witness selection

This commit implements the core logic for selecting appropriate witness types
based on channel type in the contract resolution system. The commit sweep
resolver, HTLC timeout resolver, and HTLC success resolver have been updated
to use production taproot witness types when handling final taproot channels.

For each resolver, the witness type selection follows a consistent three-way
pattern: production taproot channels use Final witness types, staging taproot
channels use the existing taproot witness types, and legacy channels continue
to use their established witness types. This ensures that each channel type
uses the appropriate script structure and witness generation logic.

The HTLC success resolver required the addition of a new production input
constructor to properly handle direct HTLC sweeps on remote commitments with
production taproot channels. The HTLC timeout resolver was updated to handle
both second-level timeout transactions and direct timeout sweeps with the
correct production witness types.

These changes ensure that production taproot channels benefit from the
optimized script structure using OP_CHECKSIGVERIFY while maintaining full
backward compatibility with staging taproot and legacy channel types.

input: add production taproot witness types for final channels

This commit introduces seven new witness types specifically designed for
production taproot channels that use the final optimized script structure.
These witness types correspond to the existing staging taproot witness types
but are intended for channels using the finalized taproot specification with
optimized scripts that employ OP_CHECKSIGVERIFY instead of OP_CHECKSIG + OP_DROP.

The new witness types cover all taproot channel operations including local and
remote commitment spends, second-level HTLC transactions, direct HTLC sweeps,
and revocation scenarios. Each production witness type follows the established
naming convention by appending "Final" to distinguish them from their staging
counterparts.

The witness generation logic for these new types mirrors the existing taproot
implementation but will be used when the channel type indicates a production
taproot channel rather than a staging one. This ensures that the correct
script tree structure and witness format is used for each channel type.

contractcourt: integrate production taproot support in nursery

This commit completes the production taproot integration by updating the
UTXO nursery to properly handle production taproot channels. The nursery
is responsible for incubating time-locked outputs from commitment transactions
and must use the correct witness types for successful sweeping operations.

The witness type selection logic has been updated in three key areas within
the IncubateOutputs function: incoming HTLC resolution handling, outgoing
HTLC resolution handling, and baby output creation through makeBabyOutput.
Each location now uses a consistent three-way selection pattern that chooses
production taproot witness types for final channels, staging types for
development channels, and legacy types for traditional channels.

A new helper method isProdTaprootResolution has been added to determine
production taproot channels by examining the presence of a ResolutionBlob,
which indicates auxiliary channel information used by production taproot
implementations. The makeBabyOutput function has been converted to a method
to access this helper function.

The NurseryReport function has been updated to include all new Final witness
types in its switch statements, ensuring that production taproot outputs are
properly categorized and reported. This maintains consistency in the nursery's
reporting system while supporting the new witness types.

contractcourt: add channel type support to HTLC resolvers

This commit extends all HTLC contract resolvers to accept and store channel
type information, which is essential for determining whether to use staging
or production taproot witness types during contract resolution. Each resolver
constructor now accepts a channeldb.ChannelType parameter and stores it as
a field within the resolver struct.

The channel arbitrator has been updated to extract channel type information
from the channel state and pass it to all resolver constructors. This ensures
that each resolver has the necessary context to make appropriate decisions
about script generation and witness type selection based on the specific
channel type being resolved.

Helper methods isTaprootFinal() have been added to each resolver to provide
a clean interface for determining when production taproot witness types
should be used. This lays the groundwork for the resolvers to properly
handle both staging and production taproot channels with the correct
script optimizations.

The changes maintain backward compatibility with existing channel types
while providing the infrastructure needed for production taproot channel
support throughout the contract resolution system.

input: add production taproot HTLC succeed input constructor

This commit adds MakeTaprootHtlcSucceedInputFinal, a new input constructor
specifically for creating HTLC success inputs that use production taproot
witness types. This function parallels the existing MakeTaprootHtlcSucceedInput
but creates inputs with the TaprootHtlcAcceptedRemoteSuccessFinal witness type
instead of the staging variant.

The new constructor follows the same pattern and signature as its staging
counterpart, ensuring consistency in the input creation API. This allows
contract resolvers to create the appropriate input type based on whether
they are handling a staging or production taproot channel, ensuring that
the correct witness generation logic is applied during transaction creation.

This addition provides the necessary infrastructure for production taproot
channels to properly construct inputs for sweeping HTLC outputs on remote
commitment transactions with the optimized script structure.

channeldb: add production taproot channel type support

This commit introduces the infrastructure necessary to distinguish between
staging and production taproot channels in the channel database. A new
TaprootFinalBit flag is added to the ChannelType enumeration to identify
channels that use the final taproot specification with optimized scripts.

The IsTaprootFinal() method provides a clean interface for determining when
a channel uses production taproot scripts versus the staging implementation.
Production taproot channels are characterized by their use of feature bits
80/81 and optimized script structures that employ OP_CHECKSIGVERIFY for
improved efficiency and reduced transaction sizes.

This channel type distinction is essential for the contract resolution system
to select appropriate witness types and script generation options. The bit
must be set alongside SimpleTaprootFeatureBit to ensure proper channel type
validation and backwards compatibility with existing taproot implementations.

feature: add taproot final to feature bit manager

build: update to actor v0.0.6

discovery/test: assert ProcessSyncTransition error in sync transition test

TestGossipSyncerSyncTransitions calls ProcessSyncTransition but
discards its return value. If the function ever regresses and returns
an error on the happy path, the test would silently pass. Assert
that the returned error is nil.

multi/test: add unit tests for gossip result helpers and context bridge

In this commit, we add test coverage for the new helper functions
introduced as part of the chan error -> Future[error] migration.

discovery/gossip_result_test.go covers AwaitGossipResult (success,
error propagation, and context cancellation) and the idempotency of
completeGossipResult (a second call must never block or overwrite the
first result).

lnutils/context_test.go covers ContextFromQuit, verifying that closing
the quit channel cancels the derived context and that calling cancel()
allows the internal goroutine to exit cleanly without leaking.

actor/future_test.go removes a stale doc comment that was left over
from a prior edit pass.

discovery: add gossip result helpers wrapping actor.Future[error]

In this commit, we add gossip_result.go with three thin wrappers that
form the internal vocabulary for the chan error -> Future[error]
migration.

completeGossipResult(p Promise[error], err error) resolves a gossip
processing promise. A nil error signals success; non-nil signals the
specific gossip failure. Calling it more than once is safe since the
underlying Promise.Complete uses sync.Once, making any repeat call a
no-op. This idempotency is the core property that makes the pattern
safe for deferred message re-processing.

AwaitGossipResult(ctx, f Future[error]) error is the public-facing
counterpart: it blocks until the future resolves or the context is
cancelled, returning whichever error applies. Callers outside the
discovery package (funding, server) use this.

awaitGossipResult is a package-internal alias for AwaitGossipResult,
avoiding the need to qualify the symbol inside the package.

actor: add CompleteWith and AwaitFuture generic package-level helpers

In this commit, we add two package-level generic helpers to the actor
module as part of the broader chan error -> Future[error] migration in
the discovery package.

CompleteWith[T](p Promise[T], val T) is a one-liner convenience wrapper
over p.Complete(fn.Ok(val)). It lets callers complete a promise with a
plain value without constructing an fn.Result inline, which cuts noise
at every completion site.

AwaitFuture[T](ctx, f Future[T]) (T, error) provides the symmetric
receive side: it blocks until the future resolves or the context is
cancelled and returns the value and any context error unpacked from
the fn.Result, matching the (val, err) convention callers expect.

Both functions are deliberately thin (no policy, no timeout, no new
state) so they compose freely with higher-level helpers built on top,
e.g. discovery.AwaitGossipResult.

go.mod is updated to pin the actor module via a local replace directive
so the rest of the lnd module picks up these additions without waiting
for a tagged release.