BOLT proposal · Schnorr · MuSig2 · BIP-340/341

Simple Taproot Channels
Schnorr × MuSig2 で再設計される Lightning Channel

従来の Lightning channel は P2WSH 2-of-2 multisig を使い、ECDSA 署名で構築されていた。 Simple Taproot Channels（BOLT proposal）は Bitcoin の Taproot upgrade（BIP-340/341/342, 2021 deploy）を活用し、Schnorr 署名 + MuSig2 鍵集約で channel をひとつの key-spend として構成する。これにより witness サイズ削減・on-chain プライバシー向上・PTLC への自然な移行パスを実現する。Eclair・LDK・Phoenix が先行実装。

基盤 BIPBIP-340 (Schnorr) · 341 (Taproot) · 342 (Tapscript)

鍵集約MuSig2 (BIP-327)

先行実装Eclair / LDK / Phoenix (2024–25)

P2WSH 2-of-2 multisig の限界

従来の Lightning channel は P2WSH (Pay-to-Witness-Script-Hash) ベースの 2-of-2 multisig を funding output に使う。これは:

Script reveal: close 時に script (2 公開鍵 + OP_CHECKMULTISIG) が on-chain に露出 → "これは Lightning channel" と即座に識別可能
witness サイズ大: 2 つの ECDSA 署名（合計 ~144 bytes）+ script (71 bytes) = 重い
HTLC が hash-based: payment 相関が 1 経路全体で成立 → wormhole / privacy 攻撃の根源
upgrade ゴテゴテ: anchor outputs / option_static_remotekey 等の追加 spec が積み重なって複雑化

Taproot で何が変わるか

⛔ P2WSH 2-of-2 (legacy)

# Funding output script
2 <Alice_pubkey> <Bob_pubkey> 2 OP_CHECKMULTISIG

# Cooperative close witness
<Alice_sig> <Bob_sig> [script reveal]
# ~144 bytes witness
# on-chain identifiable as Lightning

✅ P2TR + MuSig2 (Taproot)

# Funding output script
<musig2_aggregate(Alice, Bob)> # 1 key

# Cooperative close witness
<single_schnorr_sig> # key-path spend
# 64 bytes only
# indistinguishable from single-sig

§ 2 · Schnorr Signatures (BIP-340)

ECDSA から Schnorr への移行で何が嬉しいか

2021-11 の Taproot soft fork で Bitcoin に Schnorr signatures が追加された（BIP-340）。Lightning にとっての利点は線形性。

① 鍵の線形性

Schnorr は group operation の線形性を保つ。sig(k1) + sig(k2) = sig(k1+k2)。これが MuSig2 鍵集約の基盤。

② バッチ検証

複数の Schnorr 署名を 1 度の演算で同時検証可能。ノード負荷削減。

③ 64 bytes 固定

ECDSA は DER encoding で 71-72 bytes。Schnorr は 常に 64 bytes 固定で予測可能。

④ Adaptor signature 自然

Schnorr は adaptor signature が自然に構成可能。これが PTLC の基盤となる。

署名サイズ比較

同等のセキュリティでの witness サイズ

ECDSA P2WSH 2-of-2: ~144 bytes (sig×2 + script)

Schnorr P2TR 2-of-2 script-path: ~108 bytes

Schnorr P2TR + MuSig2 key-path: 64 bytes ✨

§ 3 · MuSig2 — 2 鍵を 1 鍵に集約

BIP-327 による 2-round multi-signature scheme

MuSig2 は 2-of-2（または n-of-n）の Schnorr 署名を 1 つの集約鍵 + 1 つの集約署名 に圧縮する。観察者から見ると 単一署名と区別不能。 Lightning では Alice / Bob の 2 鍵を 1 鍵に集約する場面で使われる。

A_pub

B_pub

→

P_agg

P_agg = a₁·A_pub + a₂·B_pub (a_i は鍵ごとの coefficient)

2-round signing protocol

# Round 1: nonce exchange
Alice: generate r1_a, r2_a (2 nonces) → R1_a = r1_a·G, R2_a = r2_a·G
Bob:   generate r1_b, r2_b → R1_b, R2_b
Exchange: (R1_a, R2_a) ↔ (R1_b, R2_b)

# Round 2: partial signature
nonce_aggregation: R = R1_agg + b·R2_agg     # b = derived from public inputs
challenge:         e = H(R || P_agg || msg)
Alice partial:     s_a = (r1_a + b·r2_a) + e·a1·priv_a
Bob   partial:     s_b = (r1_b + b·r2_b) + e·a2·priv_b

# Aggregate
s_total = s_a + s_b
final_signature = (R, s_total)
# Verify: s_total·G == R + e·P_agg  ✓ exactly like a single Schnorr sig

なぜ 2-round が重要か

MuSig (initial version) は 3 ラウンド要求した。MuSig2 は 2 ラウンドに圧縮し、しかも初期 round は 事前計算可能（Alice/Bob は協力前に nonce を準備できる）。これにより Lightning の commitment update は signing latency 1 ラウンドで済む。

セキュリティ前提

nonce 再利用厳禁: 同じ nonce で異なる message に署名すると秘密鍵が漏洩
nonce stateful: 各 signer は使用済み nonce を記録する必要
Wagner attack 耐性: MuSig1 の 3 round 設計は攻撃可能だった。MuSig2 は対策済
BIP-327 標準化: 2024 標準化完了。実装互換性確立

§ 4 · Commitment Transaction Redesign

P2WSH → P2TR への構造変化

Funding output の変化

Legacy (P2WSH)

scriptPubKey:
  OP_0 <sha256(redeem_script)>

redeem_script:
  2 <A> <B> 2 OP_CHECKMULTISIG

Taproot (P2TR)

scriptPubKey:
  OP_1 <musig2_aggregate(A, B)>

# Spend = single Schnorr signature
# No script reveal needed

Commitment TX の構造

HTLC output の Tapscript 化

HTLC は 2 つの spend path を持つ: success path（preimage 開示）と timeout path（CLTV expire 後の refund）。これらは Taproot の script-path spendとして構成される。

# HTLC Taproot tree
internal_key = unspendable_NUMS_point

tap_tree = {
  success_leaf: {
    OP_SHA256 <H> OP_EQUALVERIFY
    <remote_pubkey> OP_CHECKSIG
  },
  timeout_leaf: {
    <cltv> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <local_pubkey> OP_CHECKSIG
  }
}

# Spend = reveal one leaf via script-path
# Other leaf stays hidden in the merkle tree

Anchor output の変化

Anchor outputs（CPFP fee bumping 用）も Taproot 化される。dust 抑制と CPFP-carve-out exception を引き継ぐ。

Each party の anchor も P2TR (musig2 不要、シンプル single key)
16-block CSV による sweep 機能は維持
Anchor key の生成方式が更新（per-commitment derivation）

§ 5 · Spend Paths

Key-path / Script-path の使い分け

Taproot の本質は 1 つの output に 2 種類の spend 経路を内包すること。協調ケースは key-path（最小 cost、prviate）、紛争ケースは script-path（penalty / timeout）に fallback する。

用途別 spend path

シナリオ	spend path	witness size	備考
Cooperative close	Key-path (musig2)	64 bytes	外部から identical to single-sig
Mutual splice	Key-path	64 bytes	同上
Force-close (commitment broadcast)	N/A (only commit TX is broadcast)	—	commit TX 自体は funding を key-path で spend
HTLC success sweep	Script-path (success leaf)	~120 bytes	preimage reveal
HTLC timeout refund	Script-path (timeout leaf)	~110 bytes	CLTV after expiry
Penalty (revoked commitment)	Script-path (penalty leaf)	~120 bytes	justice TX

§ 6 · PTLC への自然な移行

HTLC → PTLC が Taproot Channels で可能になる

PTLC (Point-Time-Locked Contracts) は HTLC を Schnorr adaptor signature ベースに置き換える設計。 Taproot Channels が deploy されれば、各ホップの "lock" が 異なる point になり、wormhole / payment correlation 攻撃が原理的に消える。

HTLC (legacy)

各ホップが 同じ payment_hash H を共有
preimage R 開示で全ホップ unlock
Wormhole 攻撃: 共謀ホップが honest 中間者を skip 可能
Payment correlation: 経路観察者が同一支払いを追跡

PTLC (Taproot/Schnorr ready)

各ホップが 異なる point P_i を持つ
Adaptor sig による段階的解錠
Wormhole 攻撃成立しない（lock が hop ごとに変わる）
Payment correlation 困難

移行の段階

Phase 1 (current): Simple Taproot Channels deploy
  - Funding/commitment が P2TR + MuSig2
  - HTLC は依然 hash-based (script-path leaf)

Phase 2 (next): PTLC の中継対応
  - Taproot Channel 同士の連結で PTLC routing 可能
  - 混在 (HTLC ↔ PTLC) のホップ変換ロジック必要

Phase 3 (final): PTLC native
  - HTLC が deprecated
  - Wormhole/correlation 攻撃面が原理的に消失
  - Privacy 性質が抜本的改善

→ HTLC ↔ PTLC の暗号詳細は crypto_primitives.html

§ 7 · Adoption Status (2021 → 2026)

各実装の Simple Taproot Channels サポート

採用タイムライン

2021-11 Bitcoin Taproot soft fork activation (BIP-340/341/342)
2022    BOLT proposal "simple-taproot-channels" 起草
2023    BIP-327 (MuSig2) 標準化議論
2024-Q1 Eclair が initial taproot channels 実装
2024-Q2 LDK が taproot channel 設計議論
2024    BIP-327 (MuSig2) 標準化完了
2025-08 Eclair #3103 dual funding + splicing in simple taproot channels
2025    Phoenix が production で taproot channel
2026-Q1 LDK ≒ feature parity
2026    LND の taproot channel support 議論進行中

実装サポート比較

実装	Simple Taproot Channels	Splicing対応	BOLT 12 連携	Mainnet
Eclair	✓	✓ (#3103)	✓	2025
Phoenix	✓	✓	✓	2025
LDK	✓ (2026)	✓	✓	2026
Core Lightning	部分	✓	✓	2026
LND	議論中	議論中	部分	未投入

未解決課題

★★★

LND の遅延

最大シェアの LND が依然議論段階。ecosystem 全体での taproot channels 採用が遅れる主因。

★★

HTLC ↔ PTLC 混在期

Phase 2 移行期の attack surface 分析が未充分。jamming 研究と接続する。

★★

nonce stateful 問題

MuSig2 の nonce 再利用厳禁性が disaster recovery 設計を複雑化。stateless 派生 (MuSig-DN) も研究中。

§ 8 · Resources & Related Pages

Simple Taproot Channels
Schnorr × MuSig2 で再設計される Lightning Channel

P2WSH 2-of-2 multisig の限界

Taproot で何が変わるか

⛔ P2WSH 2-of-2 (legacy)

✅ P2TR + MuSig2 (Taproot)

ECDSA から Schnorr への移行で何が嬉しいか

① 鍵の線形性

② バッチ検証

③ 64 bytes 固定

④ Adaptor signature 自然

署名サイズ比較

同等のセキュリティでの witness サイズ

BIP-327 による 2-round multi-signature scheme

2-round signing protocol

なぜ 2-round が重要か

セキュリティ前提

P2WSH → P2TR への構造変化

Funding output の変化

Legacy (P2WSH)

Taproot (P2TR)

Commitment TX の構造

HTLC output の Tapscript 化

Anchor output の変化

Key-path / Script-path の使い分け

用途別 spend path

HTLC → PTLC が Taproot Channels で可能になる

HTLC (legacy)

PTLC (Taproot/Schnorr ready)

移行の段階

各実装の Simple Taproot Channels サポート

採用タイムライン

実装サポート比較

未解決課題

LND の遅延

HTLC ↔ PTLC 混在期

nonce stateful 問題

関連する HTML / wiki / spec

主要リファレンス

Simple Taproot ChannelsSchnorr × MuSig2 で再設計される Lightning Channel

P2WSH 2-of-2 multisig の限界

Taproot で何が変わるか

⛔ P2WSH 2-of-2 (legacy)

✅ P2TR + MuSig2 (Taproot)

ECDSA から Schnorr への移行で何が嬉しいか

① 鍵の線形性

② バッチ検証

③ 64 bytes 固定

④ Adaptor signature 自然

署名サイズ比較

同等のセキュリティでの witness サイズ

BIP-327 による 2-round multi-signature scheme

2-round signing protocol

なぜ 2-round が重要か

セキュリティ前提

P2WSH → P2TR への構造変化

Funding output の変化

Legacy (P2WSH)

Taproot (P2TR)

Commitment TX の構造

HTLC output の Tapscript 化

Anchor output の変化

Key-path / Script-path の使い分け

用途別 spend path

HTLC → PTLC が Taproot Channels で可能になる

HTLC (legacy)

PTLC (Taproot/Schnorr ready)

移行の段階

各実装の Simple Taproot Channels サポート

採用タイムライン

実装サポート比較

未解決課題

LND の遅延

HTLC ↔ PTLC 混在期

nonce stateful 問題

関連する HTML / wiki / spec

主要リファレンス

Simple Taproot Channels
Schnorr × MuSig2 で再設計される Lightning Channel