Simple Taproot Channels 簡單 Taproot 通道

Traditional Channels vs Simple Taproot Channels:

Traditional P2WSH Channel:

Funding Output:
  OP_2 <pubkeyA> <pubkeyB> OP_2 OP_CHECKMULTISIG

Characteristics:
  • 2-of-2 multisig clearly visible
  • Script exposed on-chain
  • Obviously a Lightning channel

Simple Taproot Channel:

Funding Output:
  OP_1 <aggregated_pubkey>

Internal Structure:
  • Internal Key: MuSig2(pubkeyA, pubkeyB)
  • Taproot Tree: (empty for keypath spend)

Characteristics:
  • Looks like ordinary single-sig output
  • No script exposure on cooperative close
  • Significantly improved on-chain privacy

Simple Taproot Funding Output:

Key Aggregation:

1. Both parties exchange public keys
   Alice: pubkey_a
   Bob: pubkey_b

2. MuSig2 key aggregation
   aggregate_key = MuSig2_KeyAgg(pubkey_a, pubkey_b)

3. Build Taproot output
   internal_key = aggregate_key
   merkle_root = (empty)
   output_key = internal_key + H(internal_key || merkle_root)*G

4. Funding output
   scriptPubKey: OP_1 <output_key>
   This is a standard P2TR output

Why Use Empty Taproot Tree?

Simple Taproot = keypath spend only

Advantages:
  • Cooperative close looks completely ordinary
  • No script exposure
  • Minimal on-chain footprint

Disadvantages:
  • Non-cooperative case still reveals commitment tx structure
  • Less flexible than full Taproot channels

Simple Taproot Commitment Transaction:

Input Signing Method:

Traditional: Two separate ECDSA signatures

Simple Taproot:
  • MuSig2 aggregated signature
  • Single Schnorr signature
  • 64 bytes (vs traditional ~144 bytes)

Commitment Transaction Outputs (similar structure):

to_local Output (using P2TR):
  Internal Key: revocation_pubkey

  Script Path (leaf):
    <local_delayedpubkey>
    OP_CHECKSIG
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP

to_remote Output (using P2TR):
  Simple P2TR output
  Counterparty can spend directly via keypath

HTLC Output (using P2TR):

Offered HTLC:
  Internal Key: revocation_pubkey

  Script Leaves:
  [0] Success path: <remote_htlcpubkey> CHECKSIG
      (with preimage in annex)

  [1] Timeout path: <local_htlcpubkey> CHECKSIG
      <cltv_expiry> CHECKLOCKTIMEVERIFY

Received HTLC: Similar but paths reversed

Commitment Transaction MuSig2 Signing:

Two-Round Protocol:

  Alice                                    Bob
    |                                        |
    |  [Round 1: Nonce Exchange]             |
    |                                        |
    |---- nonce_a -------------------------->|
    |<--- nonce_b ---------------------------|
    |                                        |
    |  [Compute aggregate nonce]             |
    |  R = R_a + R_b                         |
    |                                        |
    |  [Round 2: Partial Signature]          |
    |                                        |
    |---- partial_sig_a -------------------->|
    |<--- partial_sig_b ---------------------|
    |                                        |
    |  [Combine signatures]                  |
    |  sig = partial_sig_a + partial_sig_b   |

Difference from Traditional Signing:

Traditional 2-of-2:
  • Alice signs -> sig_a
  • Bob signs -> sig_b
  • Witness: <sig_a> <sig_b> <script>

MuSig2:
  • Alice partial_sig -> s_a
  • Bob partial_sig -> s_b
  • Aggregate -> sig = (R, s_a + s_b)
  • Witness: <sig> (single signature)

Savings: ~80 bytes per commitment tx

Simple Taproot Channel Lifecycle:

Opening:

1. open_channel2 message
   • channel_type = option_taproot
   • funding_pubkey (for MuSig2)

2. accept_channel2 message
   • funding_pubkey

3. MuSig2 key aggregation
   • Compute aggregate public key

4. tx_add_input / tx_add_output
   • Dual-funded (if used)

5. commitment_signed (using MuSig2 nonces)
   • Exchange nonces
   • Exchange partial signatures

6. tx_signatures
   • Funding transaction signatures

Operation:

Updating commitment transaction:

1. update_add_htlc / update_fulfill_htlc / ...

2. commitment_signed
   • Contains MuSig2 nonce
   • Contains partial signature

3. revoke_and_ack
   • Reveal previous state's revocation key
   • Send new nonce (for next round)

Note: Requires additional nonce state management

Closing:

Cooperative close (ideal case):
  • shutdown message
  • closing_signed (using MuSig2)
  • On-chain shows only P2TR -> P2TR/P2WPKH
    Looks like ordinary single-sig transaction!

Non-cooperative close:
  • Broadcast commitment transaction
  • Reveals Taproot script path
  • Still smaller than traditional channels

Taproot Channel Gossip:

channel_announcement Changes:

Traditional:
  • bitcoin_key_1, bitcoin_key_2
  • Signature proves ownership of funding output

Taproot:
  • Need to prove ownership of aggregate key
  • Uses MuSig2 signature
  • New message format (pending standardization)

Chain Analysis Resistance:

On cooperative close:
  • Input: P2TR (looks like single-sig)
  • Output: P2TR/P2WPKH
  • Cannot determine from chain that it's a Lightning channel

Even for public channels:
  • Gossip participation is optional
  • Private channels completely hidden
  • Channel capacity no longer easily trackable