Witness Data

アンナは以前 Bitcoin を受け取り、今度はそれでピーターに支払いたいと考えています。以前の支払いは、金額と後で使う条件を記した出力を作りました。新しい取引は入力を通じてその出力を参照します。しかし、コインがアンナのものだと言うだけでは足りません。通常の支払いでは、ウォレットが秘密鍵を明かさずに検証できる署名を作ります。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。秘密鍵は、そのような署名を作るために使う秘密の数値です。SegWit では、その検証データを入力の witness として提出します。署名があるだけで正しいとは限りません。 [1] [4] [5]

「有効な証明書を示す」という条件と、実際に示した証明書の違いを考えてみましょう。Bitcoin には人間の審査員がおらず、ルールが対応関係を確かめます。Witness program は以前の出力に記された条件の一部で、そのバージョンが評価方法を決めます。Witness を提供するのは、後からその出力を使う新しい取引です。技術的には入力ごとの順序付きデータ一覧であり、それ自体が自動的に実行可能なプログラムや未使用コイン全体のコピーになるわけではありません。 [1] [7]

Witness には署名、公開鍵、または実際に使うスクリプトが現れます。スクリプトは支出条件を記したプログラムです。公開鍵は署名の検証に使うもので、秘密にしておく必要はありません。暗号化された保管箱ではありません。秘密鍵は手元に残し、署名に使います。署名の代わりに鍵そのものをネットワークへ送るのではありません。Witness も公開済みの署名も、ウォレット復元用の単語列である Seed Phrase の代わりにはなりません。鍵とバックアップを失った場合、公開された支払い履歴だけでは新しい送金に署名できるようにはなりません。 [1] [3] [4]

ブロックエクスプローラーは、特定のネットワークの取引やブロックを調べるためのアプリです。エクスプローラーには txid とともに wtxid が表示されることがあります。どちらも、正確なデータ表現に SHA-256 を二度適用して求める短い指紋、ハッシュです。txid は witness を除いた表現、wtxid は witness を含む完全な表現を使います。受取アドレスでも、別々の支払いでもありません。Witness がない取引は元の形式を使うため、両者は一致します。Bitcoin Core v29.0 の decoderawtransaction では完全な識別子が hash、入力の witness データが txinwitness に示されます。 [1] [7] [8]

ある取引が承認される前に、別の取引がそれを参照することがあります。署名データを変えるだけで先の識別子が変わるなら、参照先が一致しなくなります。Witness だけの変更では txid は変わらず、Lightning Network のような依存する取引を使うプロトコルに役立ちます。ただし、取引全体が変更不能になるわけではありません。ほかのフィールドや SegWit ではない古い入力は txid に影響し得ますし、変更した witness も適用される検証ルールを満たす必要があります。 [1] [6]

Witness は完全な取引表現とともに送られ、収録後はブロックデータの一部になります。無料のチェーン外保管庫ではありません。Witness のシリアライズで追加される一バイトは 1 WU、基本データの一バイトは 4 WU と数えます。WU は重みの単位です。Full Node はルールを独立して確認し、支出を検証するために該当データを必要とします。重みが小さくても必要な確認は省けず、保存容量が不要になるわけでもありません。 [1] [7]

古い形式では支出の証拠を scriptSig に記していました。ネイティブ SegWit バージョン 0 はこのフィールドが空であることを要求し、証拠は witness に入ります。スクリプトのハッシュで条件を指定する従来方式の P2SH に包む形式もあります。この場合、scriptSig は対応する witness program をそのままスタックに積む操作だけを含み、任意の命令を追加できません。証拠は引き続き witness にあります。同じ目的でも表現が違うため、フィールド名だけでは判断できません。 [1] [5]

P2WPKH は署名と公開鍵を提出します。ノードは鍵のハッシュが元の条件と一致すること、署名が正しいことを確かめます。P2WSH はスクリプト全体のハッシュで指定した条件に対応します。最後の witness 要素は witnessScript で、そのハッシュが出力のプログラムと一致する必要があります。前の要素は、署名など、スクリプト実行の初期データです。BIP 143 はこのバージョンの署名対象メッセージを定め、使う出力の金額も含めます。データを読み取れただけでは条件を満たした証明になりません。 [1] [2] [5]

Taproot はネイティブ witness バージョン 1 を使い、鍵の経路とスクリプトの経路を区別します。判定前に、特殊な追加フィールド annex があれば取り分けますが、そのデータは重みに数えられ、署名の対象でもあります。残りが一要素なら鍵の経路の署名として解釈します。スクリプトの経路は使用したスクリプトと control block を示します。後者は以前の出力との結び付きを示すデータで、新しいブロックではありません。それ以前の要素があればスクリプトに渡します。バージョン 0 のルールをそのまま当てはめることはできません。 [3] [5]

暗号学的コミットメントは、データをその具体的な内容に結び付ける指紋のような値です。Witness データへのこのコミットメントが必要な場合、BIP 141 はマイナー報酬に使う最初の取引、Coinbase Transaction を通じて残りのブロックに結び付けます。wtxid のハッシュ木から、データを要約する根が得られます。この木では報酬取引の wtxid をゼロとして扱います。根と予約された 32 バイトの値を結合して二度ハッシュ化し、得たコミットメントをその出力に記録します。どの取引にも witness がなければ、コミットメントは任意です。公開された証拠同士を結ぶ仕組みであり、鍵のバックアップや実際の検証の代わりではありません。 [1]