> they already provide meaningful privacy and efficiency improvements

Don't count on it, that's only for the happy path. Force closes reveal Lightning specifics on-chain and are more expensive than anchors.

There's also much higher complexity in backups/watchtowers/state management = more bug surface. If you've ever had difficulty recovering funds from a dead Lightning node know that Taproot can only make that experience worse. 

Be weary of privacy virtue signals when justifying new script. Lightning effectively being a giant decentralized coinjoin, when used correctly, doesn't benefit from added crypto-theater that shifts the emphasis away from good practices.

justin_shocknet

Zapped, commenting to bookmark this for later.

Kruw

, nodes can open production Simple Taproot channels. These are still 

HTLC-based channels, there are no PTLCs yet, but they already provide meaningful privacy and efficiency improvements.

A Taproot channel funding output looks like an ordinary P2TR output on-chain. When the channel is closed cooperatively, it can be spent through the Taproot key path without revealing the Lightning channel script, making it much harder to distinguish from an ordinary Taproot payment.

Cooperative closes are also more block-space efficient. A force close can still reveal the channel structure, so Taproot does not make every possible channel lifecycle invisible.

. Instead of using the real short channel ID. Which directly identifies the funding transaction and output. Instead, the peers use an unrelated alias for routing.

This is particularly useful for private channels:

Together, this makes private channels substantially harder to associate with an on-chain UTXO.

protocol.simple-taproot-chans=true
protocol.option-scid-alias=true


Restart LND, connect to a compatible peer, and open the channel explicitly:

lncli openchannel \
  --node_key=<PUBKEY> \
  --local_amt=2000000 \
  --private \
  --channel_type=taproot \
  --scid_alias


Taproot channels must currently be private in LND. Both sides must advertise support, and the remote node can still reject the channel through its own acceptance policy.

To find candidates in your local graph, look for:

After connecting, verify the peer again with 

. The public graph can contain stale feature information, while 

 shows the features advertised during the current connection.

Taproot channels are not the final form of Lightning privacy, but they are an important step toward making Lightning activity look more like ordinary Bitcoin activity.

lightning

Starting with **LND 0.21.0**, nodes can open production Simple Taproot channels. These are still **HTLC-based channels, there are no PTLCs yet, but they already provide meaningful privacy and efficiency improvements.**

A Taproot channel funding output looks like an ordinary P2TR output on-chain. When the channel is closed cooperatively, it can be spent through the Taproot key path without revealing the Lightning channel script, making it much harder to distinguish from an ordinary Taproot payment.

Cooperative closes are also more block-space efficient. A force close can still reveal the channel structure, so Taproot does not make every possible channel lifecycle invisible.

You can combine Taproot channels with **SCID aliases**. Instead of using the real short channel ID. Which directly identifies the funding transaction and output. Instead, the peers use an unrelated alias for routing.

This is particularly useful for private channels:

* The channel is not announced in the public gossip graph.
* Invoice routing hints can use the SCID alias rather than exposing the funding outpoint.
* A cooperative close does not reveal the channel script.

Together, this makes private channels substantially harder to associate with an on-chain UTXO.

Enable support in `lnd.conf`:

```
protocol.simple-taproot-chans=true
protocol.option-scid-alias=true

```

Restart LND, connect to a compatible peer, and open the channel explicitly:

```
lncli openchannel \
  --node_key=<PUBKEY> \
  --local_amt=2000000 \
  --private \
  --channel_type=taproot \
  --scid_alias

```

Taproot channels must currently be private in LND. Both sides must advertise support, and the remote node can still reject the channel through its own acceptance policy.

To find candidates in your local graph, look for:

* `44/45`: explicit channel types
* `46/47`: SCID aliases
* `80/81`: production Taproot channels

```
lncli describegraph | jq -r '
.nodes[]
| select(
    (.features["44"]? or .features["45"]?) and
    (.features["46"]? or .features["47"]?) and
    (.features["80"]? or .features["81"]?)
  )
| [.alias, .pub_key, ([.addresses[]?.addr] | join(","))]
| @tsv
'

```

After connecting, verify the peer again with `lncli listpeers`. The public graph can contain stale feature information, while `listpeers` shows the features advertised during the current connection.

Taproot channels are not the final form of Lightning privacy, but they are an important step toward making Lightning activity look more like ordinary Bitcoin activity.