Lightning Network
仕様書完全解説

主な定義

feature bit の規則

メッセージフォーマット

+--------+----------+
| type   | 2 bytes  |
| length | 2 bytes  |
| data   | length B |
+--------+----------+

TLV (Type-Length-Value) 拡張:
+------+--------+---------+
| type | length | value   |
+------+--------+---------+
type: varint（奇数=unknown OK）

主要メッセージ

init メッセージ

type:     16
fields:
  globalfeatures (legacy)
  localfeatures  (legacy)
  tlvs:
    networks  ← genesis block hash リスト
    (feature bits は BOLT 9)

接続時に双方が init を交換して feature bit を合意する。知らない required feature があれば切断。

Commitment TX 構造

txin[0]:  funding output (2-of-2 sig)
txout[0]: to_local (delayed P2WSH)
txout[1]: to_remote (P2WPKH or anchor)
txout[2]: anchor_local (330 sat, optional)
txout[3]: anchor_remote (330 sat, optional)
txout[4+]: HTLC outputs (P2WSH each)

Anchor Outputs (BOLT 3 改訂)

option_anchors 有効時:
- HTLC TX: SIGHASH_SINGLE|ANYONECANPAY
- 両者に 330 sat の anchor output
- force close 時に CPFP で手数料追加可

Sphinx Packet 構造

onion_packet:
  version:    1 byte   (=0)
  public_key: 33 bytes (Diffie-Hellman)
  hops_data:  1300 bytes (暗号化された hop 情報)
  hmac:       32 bytes (認証)

各 hop は自分の鍵でのみ復号できる層を剥がし、残りを次の hop へ転送。1300 bytes で最大 20 hop 程度を収容。

Hop Payload (TLV 形式)

amt_to_forward:       転送金額
outgoing_cltv_value:  次の HTLC の timeout
short_channel_id:     次の hop のチャネル ID
payment_data:         (最終 hop) payment_secret + total_msat

Route Blinding（BOLT 4 統合）

受信者が経路の後半部分を暗号化して invoice に含める。送信者は受信者の実 node ID を知らずに送信できる。

実装状況

Force Close の処理フロー

1. 最新の commitment TX をブロードキャスト
2. to_remote: 即時使用可能
3. to_local: to_self_delay ブロック後
4. HTLC-Timeout TX: cltv_expiry 後にブロードキャスト
5. HTLC-Success TX: preimage が判明次第

※相手が古い commitment TX をブロードキャストしたら:
→ Penalty TX（breach remedy）で全額没収

Watchtower との連携

ノードがオフラインの間も breach（古い commitment TX の使用）を検出・応答するために Watchtower を使用。

Gossip メッセージ

channel_announcement

short_channel_id: ブロック高+tx位置+out番号
node_id_1, node_id_2: チャネルの両端ノード
bitcoin_key_1, bitcoin_key_2: on-chain 鍵
signatures: 4 個（双方の node/bitcoin 鍵）

チャネル存在の証明として、on-chain funding TX の署名を含む。

channel_update（ルーティングポリシー）

short_channel_id: チャネル識別子
timestamp: 更新タイムスタンプ
cltv_expiry_delta: 中継 HTLC の timeout δ
htlc_minimum_msat: 最小転送額
fee_base_msat: 固定手数料
fee_proportional_millionths: 比例手数料 (ppm)
htlc_maximum_msat: 最大転送額

Noise XK ハンドシェイク

Act 1 (Initiator → Responder):
  initiator が ephemeral key を生成
  ECDH(ephemeral, responder_static) → shared secret
  → encrypt empty payload

Act 2 (Responder → Initiator):
  responder が ephemeral key を生成
  ECDH(ephemeral_r, ephemeral_i) → shared secret
  → encrypt empty payload

Act 3 (Initiator → Responder):
  initiator が自分の static key を送信
  → 以降 ChaCha20-Poly1305 で暗号化

特徴

• 相互認証: 双方が相手の node ID を確認
• Forward Secrecy: セッション鍵は session ごと
• メッセージ認証: AEAD (Poly1305)
• Tor 上でも動作（TCP 接続のみ要求）

暗号アルゴリズム

bech32 Invoice 形式

lnbc10m1p0rsn9qpp5...
│   │  │
│   │  └ データ部 (bech32 エンコード)
│   └─── 金額 (10m = 10 millibitcoin)
└─────── ln + bc (mainnet)
         ln + tb (testnet)
         ln + bcrt (regtest)

主要フィールド（タグ付きデータ）

BOLT 11 の限界

• 1 回限り: 各 invoice は payment_hash を 1 回のみ使用可
• 静的な QR コードが再利用できない
• 受信者が事前に作成・配布する必要がある
• 受信者 node ID が invoice に含まれてしまう（プライバシー問題）

署名

signature: secp256k1 ECDSA
           (payee node の秘密鍵で)
recovery_flag: (0-3)
→ 公開鍵を復元して検証

フロー

Offer フィールド例

offer_id:        SHA256 of offer TLV
chains:          Bitcoin mainnet
amount:          固定額 or 任意額
currency:        BTC (or fiat)
description:     "Monthly subscription"
issuer:          "Example Co."
quantity_max:    複数個注文可
recurrence:      定期支払い設定

BOLT 11 vs BOLT 12

実装状況

現在（P2WSH）との比較

現在 (P2WSH):
  funding output → 2-of-2 OP_CHECKMULTISIG
  on-chain に "これは LN チャネル" と見える

Taproot チャネル:
  funding output → P2TR (MuSig2 keypath)
  cooperative close → 通常の keypath spend
  → on-chain では普通の single-sig TX に見える

技術的詳細

Funding output:
  P2TR with keypath = MuSig2(Alice, Bob)
  tapscript = penalty script (force close 用)

HTLC output:
  P2TR with keypath = MuSig2 adaptor sig
  (PTLC 化の前段階として)

Commitment TX 署名:
  MuSig2 の 2-round 署名プロセスを
  BOLT 2 のメッセージシーケンスに統合

実装状況