ビットコインの​トランザクション設計 — UTXOモデル、​スクリプト、​署名方​式

はじめに

本ページは設計文書シリーズのL1 #2 — トランザクション設計である。トランザクション層を端から端まで解説する。価値がどのように表現され、転送され、ロックされ、アンロックされるかを扱う。マイニングのインセンティブ、ブロック重量、手数料市場、ウォレットの使い勝手など、ビットコインのあらゆる要素は、ここで解説する構造の上に成り立っている。

これらの概念がはじめての方は、ビットコインを持つとは、実際どういうことかがUTXO・鍵・トランザクションを事前知識ゼロで紹介している。本ページは同じトランザクション層を、そちらでは扱わないBitcoin Scriptの仕組みも含めて設計文書として扱う。このForthベースのScriptシステムが最初に実装されたv0.1ソースそのものは、Forensicxsによる2024年のコードウォークスルーがたどっている。

トランザクション層は3つの疑問に答える:

1. コインとは何か? 未使用トランザクション出力 (UTXO) であり、口座残高ではない。
2. 有効な支払いとはどのような形式か? 既存のUTXOを消費し、暗号署名で認可を証明し、新しいUTXOを作成するトランザクション。
3. 認可はどのように表現されるか? ロック条件とアンロック条件を評価するスタックベース言語、ビットコインスクリプトによって表現される。

サトシ時代の実装（v0.1、2009年1月）と現行のBitcoin Core（v27以降基準）で挙動が異なる場合は、両方を記す。

v0.1のトランザクション経路をソースでたどる

v0.1のソースコードを読むと、UTXOモデルが具体的な処理として見えてくる。固定コミット4184ab2のsrc/main.h 193–363行にあるCTransactionは入力、出力、ロックタイムを保持し、src/main.cpp 772–854行のConnectInputsは参照された各出力をたどり、未成熟のコインベースを拒否し、署名を検証し、出力が使用済みか確認し、使用済みとして記録し、入力額から出力額を引いて手数料を計算する。スクリプト側は別の経路だが、接続している。src/script.cpp 692–901行のOP_CHECKSIGは署名対象のスクリプトから署名自体を取り除き、レガシー署名ハッシュを構成し、そのダイジェストを公開鍵に対して検証する。

これらの参照箇所が記録するのは2009年1月の実装であり、現行Bitcoin Coreが同じ内部コード経路をたどるという主張ではない。そのため、後続の節ではv0.1と現行基準を分けて記載する。

別のv0.1直列化境界分析では、トランザクション・ブロック・署名ハッシュに入るバイトと、ネットワーク・ディスク経路でオブジェクトが再利用される仕組みを対応付けている。

1. UTXOモデル

ビットコインは残高を追跡しない。代わりに、すべてのトランザクションが1つ以上の離散的な出力を作成し、各出力は特定の金額とロック条件を持つ。後のトランザクションでまだ消費されていない出力が未使用トランザクション出力 (UTXO) である。ある時点でのすべてのUTXOの集合が、誰が何を支払えるかの完全な全体像となる。

UTXOライフサイクル

「コイン」とは単にUTXOセットの1エントリーであり、ウォレットの「残高」はアンロック可能な全UTXOの合計にすぎない。

UTXOモデルとアカウントモデルの比較

2. トランザクション構造

トランザクションは、1つ以上の既存UTXO（入力）を消費し、1つ以上の新しいUTXO（出力）を作成する署名済みメッセージである。入力値合計と出力値合計の差がトランザクション手数料となり、そのトランザクションをブロックに含めるマイナーが徴収する。

トランザクションの構造

フィールド別の詳細

サトシ時代とv27以降基準: トランザクション形式

3. ビットコインスクリプト

ビットコインのトランザクションは公開鍵に直接ロックされるのではない。代わりに、各出力はロックスクリプト（scriptPubKey）と呼ばれる小さなプログラムを持ち、各入力はロック条件を満たすアンロックスクリプト（scriptSigまたは証人データ）を提供する。ビットコインスクリプトはこれらのプログラムが書かれるスタックベース言語である。

スクリプト評価フロー

インタープリターはオペコードを順次処理する。データ項目をスタックにプッシュし、スタック要素を消費・生成する操作を実行する。すべてのオペコード処理後にスタック最上位の要素がゼロでない（真）であれば、支払いは有効である。

一般的なスクリプトパターン

スクリプトの進化: v0.1からv27以降へ

4. 署名方式

暗号署名は、支払者がUTXOのロック条件に対応する秘密鍵を管理していることを証明するメカニズムである。ビットコインはその歴史を通じて2つの署名方式を使用してきた。

ECDSAとシュノアの比較

署名と検証のフロー

支払者は署名する前にトランザクション(入力、出力、ロックタイム)を構築する。受信側では、検証ノードがダイジェストを再計算する前に、支払いが一致すべき公開鍵を特定する。Taprootの鍵パス支払いでは前の出力のロックスクリプトから、P2PKHやP2WPKHでは入力自身のアンロックデータから特定する。

5. SegWitとTaproot

SegWit（Segregated Witness、2017年）とTaproot（2021年）は、ビットコインのトランザクション形式に対する誕生以来最大の2つの構造的変更である。どちらも後方互換性のあるソフトフォークである。Mt. Goxは2014年2月に出金を止めたとき、以下で述べる修正が塞ぐトランザクション展性を理由に挙げた。しかし、その前の1年あまりのネットワークの調査では、閉鎖前に展性攻撃が広く使われた形跡はなかった。

構造比較

主要な革新

6. コイン選択

ウォレットがトランザクションを構築する際、入力としてどのUTXOを支払うかを選択する必要がある。これがコイン選択問題である。この選択はトランザクションサイズ（したがって手数料）、プライバシー（どのUTXOがチェーン上でリンクされるか）、ウォレットのUTXOプールの将来の形状に影響する。

現行のBitcoin Core（v27以降基準）は複数のアルゴリズム（BnB、ナップサック、単一無作為抽出、手数料率が高いときはCoinGrinder）を走らせ、無駄が最も少ない結果を採る。サトシのv0.1のSelectCoinsはナップサックの祖先である。ちょうどの額の硬貨があればそれを使い、なければ小さい硬貨の部分和を無作為に1,000回試した最良の組み合わせと、目標額を上回る最小の硬貨1枚とを比べた。

7. 二時代比較

8. 本ページの範囲

本ページはトランザクション層を独立して扱う。以下のトピックは本ページの範囲外であり、設計文書シリーズ内のそれぞれのドメインページで扱う:

• ブロック構造とマークルツリー: トランザクションがブロックにバッチされマークルルートでコミットされる仕組み。
• マイニングとプルーフ・オブ・ワーク: どのトランザクションがブロックチェーンに入るかを選択するインセンティブメカニズム。
• メモリープールポリシー: 中継規則、手数料率の下限、承認前のトランザクション伝播を制御するパッケージ中継。
• ネットワーク層のトランザクション中継: inv、getdata、txメッセージがP2Pネットワーク上でトランザクションを伝播させる仕組み。
• Lightning Networkとペイメントチャネル: ここで説明したトランザクション基本要素の上に構築されるレイヤー2構成。
• ウォレットの鍵導出: ロックスクリプトで使用されるアドレスを生成するBIP 32/44/84/86のHD鍵ツリーとディスクリプターウォレット。

トランザクションは、他のすべての設計ページが触れる対象である。ブロックチェーン設計ではブロックの中身、暗号設計では署名とハッシュの消費者、貨幣設計ではコインベースと手数料の仕組み、P2Pネットワーク設計では伝播される中身、ストレージ設計ではUTXO集合を更新する単位、ウォレット設計では組み立てて署名する対象、エコシステム設計では手数料市場とライトニングが扱う単位である。