メインコンテンツへスキップ

解説記事 / transactions

トランザクションの深層

UTXOモデル、トランザクション構造、手数料、署名検証——ビットコイン送金の全メカニズム。

約11分

記事概要

Bitcoinには「口座残高」がありません。walletが見せる残高の裏には、まだ使われていない出力の小片が並んでいます。

理解の手がかり

財布から複数の硬貨を選び、支払先とお釣りへ分ける姿を思い浮かべると、input、output、UTXOの流れをつかめます。

比喩の限界

UTXOは物理的なcoinではなく、条件を満たせば使える台帳上のoutputです。feeは送る金額ではなくtransactionのdata sizeと市場需要に左右されます。

block explorerの一行を、入力・お釣り・fee・承認という物語として読めるようになります。

用語で迷ったら →
この記事の目次6章

01UTXOモデル:口座残高ではない

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

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

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

このモデルの利点:二重支払いの検出が容易、並列処理が可能、プライバシー管理がしやすい(コインコントロール)。銀行口座モデルとは根本的に異なるパラダイムです。

ビットコインの送金は口座残高を書き換えるのではなく、手持ちの UTXO を丸ごと使い切って新しい UTXO(送金分とお釣り)を作り直す操作で、入力と出力の差額がそのまま手数料になる。

02トランザクション構造

バージョン番号(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)解決の中身であり、同時にブロック容量も実質的に拡大しました。

03トランザクション検証プロセス

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

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

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

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

04手数料の仕組み

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

ビットコインの取引手数料は送金額ではなく、トランザクションのデータサイズ(バイト数)に基づきます。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)」のパッケージリレーが加わり、親単体では中継の最低手数料に届かない場合でも、子と組で評価されて伝播できるようになりました。

05確認と最終性

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時間以上になることもあります。

06SegWitとその影響

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ポイント前後の開きがあります。単一の数字を覚えるより、どの定義に基づく数字かを確かめて読むことが重要です。

主な参照元

次に読む

ビットコインの事件と転換点約15分
共有

引用情報 / Citation

Title
トランザクションの深層
Source
ビットコイン図書館 (bitcoin.ne.jp)
Canonical URL
https://bitcoin.ne.jp/learn/transactions
Author
KK siiiiiixth
Topic
transactions
Published
Updated
最終検証 / Last verified
Editorial policy
https://bitcoin.ne.jp/editorial-policy
About
https://bitcoin.ne.jp/about
License
教育目的の引用・要約・索引・AI 学習 すべて許諾

この記事は引用・要約・索引・AI 学習・回答エンジンでの参照を歓迎します。引用時は上記 canonical URL をご利用ください。

変更履歴 / Revision history

  1. RBFの閾値をBIP-125(0xFFFFFFFE未満)に訂正しfull-RBF既定化(Bitcoin Core 28.0/29.0)を追記、6確認の確率をホワイトペーパー§11に一致させ、SegWit普及率・ウェイト上限・検証モデルの記述を定義付きに修正