Simple Taproot Channels

What Are Simple Taproot Channels?

Simple Taproot Channels are an upgrade to Lightning Network channels that replaces the on-chain funding output format. Traditional Lightning channels use a P2WSH output encoding a 2-of-2 multisig script. When this output is spent, the multisig structure is revealed in the witness data, making it straightforward for chain analysis to identify the transaction as a Lightning channel operation.

Simple Taproot Channels instead use a P2TR (Pay-to-Taproot) output where both channel parties' public keys are aggregated into a single key using the MuSig2 protocol. When the channel closes cooperatively, the spend appears as a standard single-signature Taproot key-path spend: no multisig script is ever revealed on-chain.

The "simple" designation indicates this is the minimum viable upgrade. These channels still use HTLCs for payment routing rather than the more private PTLCs that Taproot enables. This design choice ensures backward compatibility: payments routed through Taproot channels can still traverse nodes that only support legacy channels.

How It Works

To understand the improvement, it helps to compare the legacy and Taproot channel formats side by side.

Legacy Channel Funding

In a traditional Lightning channel, the funding transaction creates a P2WSH output that locks funds behind a 2-of-2 multisig script:

# Legacy funding output (P2WSH 2-of-2 multisig)
OP_2 <pubkey_A> <pubkey_B> OP_2 OP_CHECKMULTISIG

# Spending reveals the full script in witness data
witness: <sig_A> <sig_B> <redeem_script>

When this output is spent (whether by cooperative or force close), the witness data exposes the 2-of-2 multisig structure. Chain observers can identify it as a Lightning channel with high confidence because ordinary wallets rarely create bare 2-of-2 multisig outputs.

Taproot Channel Funding

Simple Taproot Channels replace this with a P2TR output. Both parties' funding keys are aggregated via BIP 327 (MuSig2) into a single aggregate public key:

# Taproot funding output (P2TR with MuSig2 internal key)
internal_key = MuSig2_KeyAgg(pubkey_A, pubkey_B)
funding_output = P2TR(internal_key, tapscript_tree)

# Cooperative spend: key-path spend with single signature
witness: <musig2_aggregate_signature>

The cooperative close produces a single 64-byte Schnorr signature in the witness, identical to what any single-key Taproot wallet would produce. There is no way for an observer to determine whether one person or two (or more) signed the transaction.

The MuSig2 Signing Process

MuSig2 is a two-round multi-signature scheme. Within the Lightning protocol, the rounds map onto existing channel messages:

1. Nonce exchange: each party generates ephemeral nonces and shares them with the counterparty. In Simple Taproot Channels, nonces are piggybacked onto existing protocol messages like revoke_and_ack and commit_sig via TLV extensions.
2. Partial signature exchange: each party computes a partial signature using their private key, the aggregate nonce, and the transaction to be signed. The partial signatures are combined via PartialSigAgg into a single valid Schnorr signature.

Nonces are treated as ephemeral and discarded after a connection drop. This conservative approach prevents nonce reuse, which would be catastrophic for security: reusing a nonce in Schnorr signing allows an attacker to extract the private key.

On-Chain Footprint Savings

The efficiency gains are significant. A Taproot key-path spend input requires approximately 57.5 vbytes, compared to roughly 96 vbytes for a legacy P2WSH 2-of-2 multisig input: a reduction of about 40%. This translates directly to lower transaction fees for cooperative closes.

Privacy Benefits

The primary motivation for Simple Taproot Channels is privacy. Chain analysis firms have long been able to identify Lightning channel opens and closes by looking for the distinctive P2WSH 2-of-2 multisig pattern.

Cooperative Closes

When both parties agree to close a Taproot channel, the on-chain transaction is indistinguishable from any other single-signature Taproot spend. An observer sees a P2TR input with one signature: it could be a Lightning channel close, a wallet transfer, an exchange withdrawal, or any other Taproot transaction. This is a fundamental improvement over legacy channels, where the multisig pattern is a clear fingerprint.

Unannounced Channels

Private (unannounced) channels benefit the most. Because there is no gossip data linking the on-chain output to the Lightning Network, and the output itself has no distinguishing features, these channels are effectively invisible on-chain during their entire lifecycle (assuming cooperative open and close).

Force Close Limitations

Privacy improvements apply primarily to the cooperative path. When a channel is force-closed, the Tapscript tree is revealed through a script-path spend. This exposes the commitment transaction structure, which can still be identified as a Lightning channel by sophisticated chain analysis. The force-close path uses pre-signed commitment transactions with timelocked outputs that remain recognizable.

Implementation Status

Simple Taproot Channels were formally specified in BOLTs PR #995, authored by Roasbeef (Olaoluwa Osuntokun of Lightning Labs). The PR was created in May 2022 and merged in May 2026 after four years of review and iteration. It introduces the concept of an "extension BOLT": a single document that modifies base BOLTs 2, 3, and 5 with Taproot-specific functionality.

LND

LND was the first implementation to ship simple taproot channels. LND v0.17.0-beta (October 2023) introduced experimental support, gated behind the --protocol.simple-taproot-chans flag and limited to unadvertised channels. LND v0.21.0-beta (June 2026) promoted the feature to production-ready status, adding finalized tapscript structures, optimized signature verification, and an RBF cooperative close protocol with nonce-reuse prevention.

Eclair

Eclair v0.13.0 (September 2025) added initial simple taproot channel support. Subsequent releases extended the feature with dual funding and splicing for Taproot channels, and enabled commitment format upgrades during splice transactions. ACINQ reported approximately 15% reduction in overall transaction weight. Full interoperability testing between LND and Eclair passed by April 2026.

CLN and LDK

Core Lightning does not yet support simple taproot channels. An open tracking issue exists, but no implementation timeline has been announced. LDK has been refactoring its signer abstractions (splitting EcdsaChannelSigner in anticipation of Schnorr support), but production-ready Taproot channel support has not yet shipped.

Relationship to Future Upgrades

Simple Taproot Channels are explicitly designed as a stepping stone toward more advanced protocol features that depend on Taproot and Schnorr signatures.

PTLCs

Point Time-Locked Contracts (PTLCs) replace hash-based locks with point-based locks using adaptor signatures. Unlike HTLCs, where the same payment hash is used at every hop (enabling correlation attacks), PTLCs use a different secret at each hop. This provides significantly better payment privacy. Simple Taproot Channels lay the required foundation: the Tapscript tree structure and MuSig2 signing infrastructure are prerequisites for PTLC support.

Public Taproot Channels

As of mid-2026, simple taproot channels can only be unadvertised (private). Public announcement requires the Gossip 1.75 protocol upgrade, which defines how nodes advertise Taproot funding outputs in channel announcements. This upgrade is under active development. Once shipped, nodes will be able to route public traffic through Taproot channels.

Dynamic Commitments

The dynamic commitments proposal will allow existing channels to upgrade their commitment format without closing and reopening. This means legacy channels could migrate to the Taproot format (and later to PTLCs) through an in-place upgrade, avoiding the on-chain cost and liquidity disruption of closing a channel.

Use Cases

• Privacy-focused node operators: merchants and services that want to prevent chain analysis from identifying their Lightning activity benefit immediately from Taproot channels, especially for unannounced channels with trusted peers.
• Fee-sensitive applications: the 40% reduction in cooperative close input size directly lowers on-chain costs, which matters for Lightning Service Providers and JIT channel services that manage many channels.
• Mobile wallets: Phoenix wallet integrated Taproot channels through Eclair, reporting 15-27% savings on swap-in transactions depending on input count. Lower fees improve the economics of small-value channels used by mobile users.
• Future-proofing: adopting Taproot channels now positions nodes to support PTLCs and other Taproot-dependent features as they ship, without requiring channel reopens if dynamic commitments are available.

Risks and Considerations

Limited Implementation Support

Only LND and Eclair have shipped simple taproot channel support as of mid-2026. Opening a Taproot channel requires both peers to run a compatible implementation. This limits adoption until CLN and LDK add support. Feature bits 80/81 are used to signal Taproot channel capability during the connection handshake.

Unadvertised Only

Taproot channels cannot yet be announced publicly in the gossip network. This means they cannot be used for general routing: only direct peers or nodes using invoice route hints can send payments through them. Public channel support requires the Gossip 1.75 specification to be finalized and deployed.

Nonce Management Complexity

MuSig2 introduces nonce handling requirements that do not exist in legacy channels. Nonce reuse in Schnorr signing is catastrophic: it allows extraction of the private key. Implementations must carefully manage nonce lifecycle, especially during protocol edge cases like connection drops mid-signing or RBF fee bumps during cooperative closes. LND v0.21 specifically addressed nonce reuse prevention for its RBF close protocol.

Force Close Privacy Gap

The privacy benefit is strongest for cooperative closes. Force closes still reveal Lightning-identifiable scripts through Tapscript path spends. Nodes that frequently force-close will see limited privacy improvement. This makes reliable uptime and cooperative behavior more important for privacy-conscious operators.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.