トランザクションの深層

ビットコインには「口座残高」という概念がありません。代わりにUTXO（Unspent Transaction Output＝未使用トランザクション出力）モデルを使います。

「残高」とは、自分のアドレスに紐づくすべての未使用出力の合計です。100円玉3枚と500円玉1枚を持っているようなもので、「残高800円」という抽象的な数字ではなく、具体的な「コイン」の集まりです。

送金時は、一つ以上のUTXOを「入力」として消費し、新しい「出力」（受取人への送金 + お釣り）を生成します。消費されたUTXOは使用済みとなり、二度と使用できません。

このモデルには利点があります。二重支払いを検出しやすく、並列に処理でき、プライバシーも管理しやすい（コインコントロール）という点です。銀行口座モデルとは根本的に異なる考え方に立っています。

バージョン番号（4バイト）：現在は2が主流です。OP_CHECKSEQUENCEVERIFY（相対タイムロック）を使う場合はバージョン2以上が必要になります。2024年10月のBitcoin Core 28.0以降は、未確認トランザクションの連鎖の形を制限するバージョン3（TRUC、BIP-431）も標準的な中継対象に加わりました。

入力（TxIn）：前のトランザクションの出力への参照。「前のトランザクションハッシュ」（32バイト）、「出力インデックス」（4バイト）、「scriptSig」（署名と公開鍵を含む解錠スクリプト）、「シーケンス番号」（4バイト）で構成されます。

出力（TxOut）：送金先と金額の指定。「金額」（8バイト、satoshi単位）と「scriptPubKey」（施錠スクリプト）で構成されます。

ロックタイム（4バイト）：指定したブロック高またはタイムスタンプまで、トランザクションが有効にならないという条件を設定できます。

代表的な出力の型：P2PKH（1で始まるレガシー）、P2SH（3で始まる。マルチシグやネストSegWitを含む）、P2WPKH／P2WSH（bc1qで始まるネイティブSegWit）、P2TR（bc1pで始まるTaproot）。SegWit以降、署名が何を対象に計算されるかはBIP-143で再定義されています。

SegWitトランザクションの場合、署名データ（witness）がトランザクション本体から分離されます。トランザクションID（txid）の計算からwitnessが外れ、witnessを含む全体のハッシュはwtxidとして別に扱われるため、第三者が署名の書き方を変えてもtxidは変わりません。これがトランザクション展性（malleability）解決の中身であり、同時にブロック容量も実質的に拡大しました。

レガシー（P2PKHなど）の検証は2段階で行われます：①入力のscriptSigを実行 → ②参照される出力のscriptPubKeyをscriptSigの結果を使って実行。最終的にスタックの先頭がtrue（非ゼロ）であれば有効です。ネイティブSegWit（bc1q／bc1p）ではscriptSigは空で、署名の検証はwitness側に置かれたデータに対して行われます。

標準的なP2PKH検証の流れ：署名と公開鍵がscriptSigに含まれる → 公開鍵がハッシュ化され、scriptPubKey内のハッシュと一致するか確認 → 署名が有効か検証 → すべて満たされれば取引は有効です。

マイナーはメモリプール（mempool）内の未確認トランザクションから、手数料の高いものを優先してブロックに含めます。

重要：入力の合計値から出力の合計値を引いた差額は、すべて取引手数料としてマイナーに渡ります。消えてなくなるわけではありませんが、送信者が取り戻すことはできません。お釣り用の出力を作り忘れると、入力の残り全額をそのまま手数料として支払ってしまうことになります。

前提として、本節で扱うRBF・CPFP・手数料の優先順位は、いずれも各ノードが個別に選べる中継とメモリプールのポリシーであり、ブロックの有効性を決める合意ルール（コンセンサスルール）ではありません。ソフトフォークを経ずに既定の挙動が変わることがあるのは、このためです。

ビットコインの取引手数料は送金額ではなく、トランザクションのデータサイズ（バイト数）に基づきます。1 BTC の送金も0.001 BTCの送金も、同じサイズなら同じ手数料です。

手数料率は「sat/vB」（satoshi per virtual byte）で表されます。SegWitトランザクションはwitnessデータが割引されるため、同じ機能でも手数料が安くなります。

RBF（Replace-By-Fee）：手数料が低すぎて確認されないトランザクションを、同じ入力を使うより高い手数料の取引で置き換える仕組みです。歴史的にはBIP-125のオプトイン方式が使われ、入力のいずれかのシーケンス番号が0xFFFFFFFE未満のときだけ置き換えの対象になっていました（0xFFFFFFFEはロックタイムを有効にしつつ置き換えを拒む値として、多くのウォレットが標準的に使います）。

その後、2024年10月のBitcoin Core 28.0でfull-RBFが既定となり（-mempoolfullrbfの既定値が0から1へ変更）、2025年4月の29.0ではオプション自体が削除されました。2026年8月時点の既定構成のノードでは、シグナリングの有無にかかわらず未確認トランザクションは原則すべて置き換えの対象になります。「RBFをシグナリングしていないから0確認でも安全」とは言えません。

CPFP（Child-Pays-For-Parent）：低手数料の未確認トランザクションの出力を使って、高手数料の子トランザクションを作成。マイナーは親子セットを一緒にマイニングするインセンティブが生まれます。Bitcoin Core 28.0以降は「1親1子（1P1C）」のパッケージリレーが加わり、親単体では中継の最低手数料に届かない場合でも、子と組で評価されて伝播できるようになりました。

0確認：トランザクションは送信されたがまだブロックに含まれていない状態。二重支払いのリスクがあります（レース攻撃、フィニー攻撃）。前節のとおり2025年以降のBitcoin Coreではfull-RBFが無条件なので、未確認の取引はいつでも別の取引で置き換えられうる前提で扱うべきです。

1確認：最初のブロックに含まれた状態。少額取引にはほぼ十分ですが、ベクター76攻撃のリスクが残ります。

6確認：慣例的に「最終確定」とみなされる基準です。ホワイトペーパー§11の計算では、ネットワークハッシュレートの10%を持つ攻撃者が6確認を覆せる確率は約0.024%とされています（同じ表で0.1%を下回るのは5確認からです）。ただしこれは攻撃者のハッシュパワーが一定で外部から調達もできないというモデル上の前提での数値であり、ハッシュパワーを借りられる現実の攻撃者にそのまま当てはまるわけではありません。

高額取引でより多くの確認を待つ運用もありますが、「100確認」という統一規格があるわけではなく、各事業者の内規によります。合意ルールとして100ブロックの待機が定められているのは、マイニング報酬（coinbase出力）が使えるようになるまでの期間（coinbase maturity）であり、通常の送金の確認数とは別の話です。確認数の選択は、取引金額と相手の信頼度に応じたリスク管理です。

平均確認時間は約10分（1ブロック）ですが、実際にはブロック生成間隔にはばらつきがあり、数秒〜1時間以上になることもあります。

Segregated Witness（SegWit、BIP-141）は2017年8月24日（ブロック481,824）に有効化されたソフトフォークで、ビットコインの最も重要なプロトコルアップグレードの一つです。

署名データ（witness）をトランザクション本体から分離し、従来の「1MB」というサイズ上限に代えて「ブロックウェイト400万WU（ウェイトユニット）以下」という別軸の上限を導入しました。witness以外のデータは1バイト＝4WU、witnessデータは1バイト＝1WUと数えるため、witnessの多いブロックほど多くの取引が入ります。実際のブロックはおおむね1.5〜2.5MB程度で、4MBに達することはまれです。手数料計算に使うvsize（仮想サイズ）は、ウェイトを4で割った値です。

トランザクション展性（malleability）の問題も解決しました。その結果、Lightning Networkなどの支払いチャネル技術を安全に構築できるようになりました。

ネイティブSegWitのアドレスは「bc1q」で始まるBech32形式です。3で始まるP2SHの中にSegWitを埋め込む「ネストSegWit」も同じ手数料割引を受けられます。Taprootで導入された「bc1p」はwitness version 1のアドレスで、Bech32を改良したBech32m（BIP-350）が使われます。

普及率は集計の定義によって大きく変わります。「SegWitの入力を1つ以上使うトランザクションの割合」を基準とする公開集計（mainnet.observer など）では2026年前半時点で約85〜90%、Glassnodeの「SegWit Adoption」指標では2026年3月23日時点で96.1%と、10ポイント前後の開きがあります。単一の数字を覚えるより、どの定義に基づく数字かを確かめて読むことが重要です。