第4回UTXO勉強会
1~3回振り返り
第1回 UTXO勉強会：「UTXOとは何か？」
UTXO（Unspent Transaction Output）モデルの基本
BitcoinなどのUTXOベースのブロックチェーンでは、取引（トランザクション）は過去のUTXOを消費（インプット）し、新たなUTXOを生成（アウトプット）します。未使用の出力がUTXOとしてウォレットに残り、次に使える資金となります。
アカウントモデルとの比較（Ethereumなど）
UTXOモデルは「現金」に近いイメージで、状態遷移がシンプルかつ並列性・プライバシーに優れる。一方、アカウントモデルは「電子マネー」のようにアカウント残高を直接減増させ、スマートコントラクトとの親和性が高いが、並列処理には不向きです。
第2回 UTXO勉強会
1. ビットコインアドレスとは
何のために使うか：ビットコインネットワーク上で送金先を特定する識別子です。UTXO（未使用トランザクションの出力）を管理するため、ウォレットはこのアドレスを使ってどこに資金を送るのかを識別します。
公開鍵からアドレスへの変換：公開鍵をSHA‑256でハッシュ化し、その結果をRIPEMD‑160でさらにハッシュ化（HASH160）。そこにバージョン情報やチェックサムを追加し、Base58CheckまたはBech32でエンコードしてアドレスが完成します。
table:_
アドレス形式 エンコーディング プレフィックス 特長
P2PKH（レガシー） Base58Check 「1」で始まる 古くからある形式。互換性が高いが、手数料やサイズが大きめ。 (note（ノート）) 第3回 UTXO勉強会：「Bitcoinの手数料」
手数料の仕組み
Bitcoinのトランザクション手数料は、トランザクションの仮想バイトサイズ（vB、virtual byte）と手数料率（sats/vB）の積として計算されます。たとえば、200 vB × 50 sats/vB = 10,000 sats（0.0001 BTC）
SegWitのメリット
SegWit（セグウィット）形式のアドレス（P2WPKH、P2WSH、P2TR）を使うと、署名データ部分の計算上の重みが軽く評価されるため、手数料が安くなります。
混雑時の優先度
ネットワークが混雑すると、mempool（未承認トランザクション集積領域）に滞留する間にマイナーは手数料率が高いトランザクションを優先的に処理します。そのため、混雑時は高めの手数料設定が必要です。
-------------------------------------------------------------------------------------------------------------------
決定性ウォレット（Deterministic Wallet）
■ 従来のウォレット（ランダムウォレット）
以前はアドレスごとにランダムな秘密鍵を生成して管理していました。
各秘密鍵は独立しており、バックアップが煩雑。
例：100個のアドレスを生成して送金に使ったら、その100個の秘密鍵すべてをバックアップしないと資金が失われるリスクがある。
■ 決定性ウォレットの基本原理
1つのシード値（seed）から秘密鍵を決定的に生成する方式。
シードはランダムに生成された128〜256ビットのエントロピー値。
例：seed = 256bit → KDF(Key Derivation Function)を通じて秘密鍵を導出。
同じシード値からは必ず同じ鍵ペア系列が生成されるため、シードだけをバックアップすればすべての鍵を復元可能。
HDウォレット（階層的決定性ウォレット）
決定性ウォレットの改良版として BIP32 で規格化されたのが HDウォレット。
■ 特徴
秘密鍵/公開鍵を ツリー構造（階層的） に生成できる。
1つのマスターシードから「マスター秘密鍵 + チェーンコード」を生成。
その後、子鍵導出関数（Child Key Derivation Function: CKD） を用いて、無数の子鍵を階層的に生成できる。
-------------------------------------------------------------------------------------------------------------------
絶対ロック＝CLTV、相対ロック＝CSV を言語化して説明できる
nLockTime / nSequence / MTP（Median Time Past）の役割を区別できる
Lightning Networkでの値の意味（HTLC=CLTV、to_self_delay=CSV）を理解する
1. 全体像（4つのピース）
nLockTime：トランザクション全体の「最短採掘時刻/高さ」
< 500,000,000 なら ブロック高、>= 500,000,000 なら UNIX時刻
有効化条件：少なくとも1入力の nSequence が 0xffffffff 以外（= non-final）
CLTV（OP_CHECKLOCKTIMEVERIFY）：絶対タイムロックを出力スクリプトに課す
比較対象は Tx側の nLockTime（単位の整合が必要）
nSequence：各入力の番号。BIP68で相対ロックの意味を持つように解釈される
CSV（OP_CHECKSEQUENCEVERIFY）：相対タイムロック（出力スクリプト）
比較対象は 入力の nSequence（BIP68解釈に従う）
MTP（BIP113）：時刻型 locktime の比較は 直近11ブロックのtimestamp中央値で行う
単調増加のため「時計いじり」への耐性が高い
2. nLockTime（基礎）
閾値：<500,000,000 → 高さ、>=500,000,000 → 時刻（ただし比較はMTP）
有効化：1つ以上の入力で nSequence != 0xffffffff（final解除）
用途：Tx全体の採掘可能時刻を制御（スクリプト不要）
3. CLTV（絶対ロック）
典型スクリプト（P2WSHのredeem scriptイメージ）
<lock> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkey> OP_CHECKSIG
Tx条件：nLockTime = <lock> を設定し、少なくとも1入力の nSequence を non-final に
単位注意：<lock> と nLockTime の型（高さ/時刻）一致が必要
OP_DROP：CLTVは値をスタックに残すので、後続の署名検証へ進むために落とす
4. BIP68 / CSV（相対ロック）
BIP68の解釈（nSequence）
値：下位16bit（0x0000ffff）＝相対ロック量
Typeフラグ：1<<22（0=高さ、1=時間512秒単位）
Disableフラグ：1<<31（1で相対ロック無効）
有効化：Tx version >= 2、かつ Disable=0
CSVスクリプト
<delay> OP_CHECKSEQUENCEVERIFY OP_DROP <pubkey> OP_CHECKSIG
Tx側：該当入力の nSequence に delay を設定（Type/Disable 正しく）
上限の目安：
高さ型：最大 65,535 ブロック（≒ 455日）
時間型：512秒 × 65,535 ≒ 388日
5. どちらを使う？（CLTV vs CSV）
CLTV（絶対）：期限を一意に決めたい（例：HTLCのタイムアウト高）
CSV（相対）：ブロードキャスト後にカウント開始（例：to_self_delay の待機）
覚え方：CLTV＝期限、CSV＝待機（状態遷移後のセーフガード）
6. MTP（時刻ロックの落とし穴）
MTP比較：時刻型の nLockTime / CLTV は MTP で評価（ローカル時計は無関係）
デモで詰まりやすい：PCの時計を変えても通らない→ブロックの中央値を見るため
7. コード断片（実用最小セット）
7.1 CLTV（高さでロック）
code:code
# Redeem script（P2WSH想定）
<600000> OP_CHECKLOCKTIMEVERIFY OP_DROP <pub> OP_CHECKSIG
# Tx側：nLockTime=600000、かつ少なくとも1入力の nSequence != 0xffffffff
7.2 CSV（ブロック高で相対遅延）
code:code
# 約1日待ち（144ブロック）
<144> OP_CHECKSEQUENCEVERIFY OP_DROP <pub> OP_CHECKSIG
# Tx側：version=2、該当入力の nSequence=144（Disable=0, Type=高さ）
7.3 CSV（時間で相対遅延）
code:code
# 約2時間待ち（14 * 512秒）
<14> OP_CHECKSEQUENCEVERIFY OP_DROP <pub> OP_CHECKSIG
# Tx側：version=2、nSequence=(1<<22) | 14（Disable=0, Type=時間）
7.4 Miniscript / Descriptor ヒント
CLTV：wsh(and_v(v:after(600000),pk(key)))
CSV：wsh(and_v(v:older(144), pk(key)))
8. Lightning Network との関係
to_local 出力：CSV(to_self_delay) により違反放流への待機を強制
HTLC：CLTV で期限管理（HTLC-timeout / HTLC-success 派生Tx）
直感：支払いは「期限（CLTV）で切る」、違反対策は「待機（CSV）で守る」