LND

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

multi: fix linter issues

lnwallet: add taproot channel test vector generator

In this commit, we add a test vector generator and verifier for
taproot channel constructions. All vectors are derived
deterministically from a single 32-byte seed using SHA256(seed ||
label) for key derivation, ensuring any implementation can reproduce
them independently.

The generator covers two areas:

Script vectors decompose the full tapscript trees for every output
type: funding (MuSig2 aggregated key), to_local (delay + revocation
leaves), to_remote (1-block CSV leaf), anchors (OP_16 OP_CSV),
offered/accepted HTLCs on both local and remote commits, and
second-level HTLC transactions. Each entry captures the raw leaf
scripts, leaf hashes, tapscript root, internal key, output key, and
pkScript.

Transaction vectors produce full serialized commitment transactions
and HTLC resolution transactions for three scenarios: a simple
commitment with no HTLCs, a commitment with five untrimmed HTLCs,
and the same HTLCs at a higher fee rate causing some to be trimmed.

To generate: go test -run TestTaprootVectors ./lnwallet/ -args -generate-taproot-vectors
To verify: go test -run TestTaprootVectors ./lnwallet/

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.

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.

lnrpc/walletrpc: add witness types for taproot chans final

itest: extend relevant itests to cover taproot chans final

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.

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.

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.

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.

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.

lnwire: add local_nonces field to revoke_and_ack

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.

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.

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: 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 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.

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.

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+funding+peer+server: migrate gossip result to actor.Future[error]

In this commit, we eliminate the three buffered chan error patterns in
the discovery package and replace them with actor.Promise[error]/
actor.Future[error]. The old pattern is error-prone: if a channel is
completed more than once (e.g. when a deferred message copy is
re-enqueued and processed again), the second write to a capacity-1
channel blocks forever. actor.Promise.Complete() is idempotent via
sync.Once, so the second call is always a safe no-op regardless of
whether anyone holds a reference to the Future.

Additionally, PropagateChanPolicyUpdate previously blocked on <-errChan
after enqueuing a policy update with no quit-channel check, creating a
latent deadlock if the gossiper shut down between enqueue and send. It
now uses AwaitGossipResult with a ContextFromQuit-derived context, so
shutdown is always respected.

This is an atomic migration that updates all callers in the same
commit so each commit builds standalone. The three main pieces are:

discovery

networkMsg.err chan error becomes errPromise actor.Promise[error].
chanPolicyUpdateRequest.errChan chan error becomes errPromise.
syncTransitionReq.errChan chan error becomes errPromise. All ~65 sites
that previously wrote to the error channel now call
completeGossipResult(nMsg.errPromise, err) instead.

ProcessRemoteAnnouncement and ProcessLocalAnnouncement now return
actor.Future[error] instead of chan error. The capacity-2 buffer
comment on ProcessRemoteAnnouncement, which was itself a workaround
for the old pattern, is removed along with the TODO referencing the
actor model redesign. ProcessSyncTransition in syncer.go follows the
same pattern: the errChan select is replaced with AwaitGossipResult
using a ContextFromQuit-derived context.

funding

The SendAnnouncement function type in funding.Config changes from
returning chan error to returning actor.Future[error]. The call sites
in addToGraph and announceChannel are updated to await the future with
AwaitGossipResult, passing a context derived from f.quit via
ContextFromQuit. Shutdown signals (context.Canceled and
discovery.ErrGossiperShuttingDown) are both mapped to
ErrFundingManagerShuttingDown via the new mapGossipError helper, which
also factors out the duplicated graph-rejected / unknown-error
handling. The three mock SendAnnouncement implementations in
manager_test.go are updated accordingly.

peer+server

In peer/brontide.go, the ProcessRemoteAnnouncement call in the gossip
stream handler intentionally discards the result since remote gossip
messages are fire-and-forget from the peer's perspective. The old
comment explaining why the chan error was unsafe to use is replaced
with a note that an unawaited Future[error] carries no overhead.

In server.go (applyChannelUpdate), the previous select on errChan and
the quit channel is replaced with ContextFromQuit + AwaitGossipResult.

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.