Bitcoinのスケーラビリティの問題への対応の１つとして、トランザクションの情報から署名（Witness）を分離（Segregate）する”Segregated Witness”という提案がされており、この導入によりトランザクション容量の削減が期待されている。

実際に”Segregated Witness”が有効になったテスト環境「SegNet」も2015年12月にデプロイされている。

BIPの中でSegregated Witness関連のBIPが以下の５つ。



Segregated Witnessの仕様がどのようなものか、BIP-141を見てみる。

トランザクション のマークルツリーにコミットされた トランザクション の構造からこのデータを除去することにより、↓のような問題が解決される。

Total transaction size は、witnessデータを含むBIP-144で定義されたフォーマットで トランザクション を シリアライズ したデータのバイト数。

Base transaction size はwitness関連のデータを除いて トランザクション を シリアライズ したデータのバイト数。

Transaction weight / 4 した値を Virtual transaction size として定義。（小数点以下は四捨五入）

以下の定義はコンセンサスの限界値には関係ないが、↑のコンセンサスの説明に出てくる内容を言語として定義したもの。

さらに、witness program内のopcodeは以前と同様にカウントされる。witness programではCHECKSIGは1 sigopとしてカウントされ、CHECKMULTISIGは引数に応じて1 〜 20 sigopsとしてカウントされる。このルールはネイティブ witness programとP2SH witness programの両方に適用される。

現在のpubkey script, signature script, P2SH check script内のSigopsは前の値の４倍でカウントされる。Sigops制限も同様に４倍の80,000以下となる。

ブロックあたりのSigopsは現在20,000までに制限されているが、この制限を以下のように変更する。

新しいルールでは、 block weight の合計が 4,000,000以下とされる。

トータルサイズはBIP-144 *4 に定義されている シリアライズ フォーマットで トランザクション を シリアライズ したバイト単位のブロックサイズで、ベースデータとwitnessデータを含む。

ベースサイズはwitness関連のデータを除外したオリジナルの トランザクション を シリアライズ したバイト単位のブロックサイズ。

ブロックは現在、最大サイズが１MBに制限されているが、この制限を以下のように変更する。

version byteが1〜16の場合、witness programやwitnessのさらなる解釈は発生せず、witnessに関するサイズ制限も無い。この1〜16は将来の拡張のために予約されている。

version byteが0でwitness programが20バイトでも32バイトでも無い場合、その スクリプト はfailになる必要がある。

witnessの検証ロジックが起動されるのは２つのケースがある。各ケースはscriptSigの形態と同様にwitnessのversion byteとprogramの位置を決める。

パターンにマッチするscriptPubKeyが複数ある場合は、一番高い出力インデックスを持つものがコミットメントであると想定される。

そしてコインベースの入力のwitnessは、`witness reserved value `である単一の32バイト配列で構成する必要がある。

コミットメントはコインベース トランザクション のscriptPubKeyに記録される。 0x6a24aa21a9ed の最初の6バイトを持つ少なくとも３８バイトのデータになる。

witnessのルートハッシュは、ブロックヘッダのhashMerkleRootと似ていて、マークルツリーのリーフのようにwtxidを全て使って計算される。

後述するnon-witness programでは、txinは 0x00 で表される空のwitnessフィールドに関連付けられる必要がある。全てのtxinがnon-witness programの場合、 トランザクション のwtxidはtxidと同じ値になる。

witness は トランザクション 内の全witnessデータを シリアライズ したもの。各txinはwitnessフィールドと関連付けられる。witnessフィールドはtxinのスタックアイテムの数を示すためvar_intから始まる。各アイテムはその長さを示すためvar_intで始まりスタックアイテムが続く。witnessデータは スクリプト ではない。

flag は必ず0以外の１バイトで、現在は 0x01 を使わないといけない。

新たに wtxid が定義され、witnessデータを持つ新しい シリアライズ 形式のダブルSHA-256ハッシュ。

既存の txid の定義は変更されず、従来の シリアライズ 形式のダブルSHA-256ハッシュのまま。

新しいデータ構造 witness が定義され、各 トランザクション は２つのIDも持つ。

例

P2WPKH 次の例は、バージョン0のpay-to-witness-public-key-hash (P2WPKH) witness: <signature> <pubkey> scriptSig: (empty) scriptPubKey: 0 <20-byte-hash> (0x0014{20-byte-hash}) scriptPubKeyの先頭の’0’は続くプッシュデータがバージョン０のwitness programであることを示す。witness programの長さから（20バイトのハッシュなので）P2WPKHタイプであることが分かる。

witnessは２つのアイテムから構成される必要があり、witnessの公開鍵のHASH160はwitness programと一致する必要がある。 署名は次のように検証される。 <signature> <pubkey> CHECKSIG 従来のP2PKHの出力と比べると、P2WPKHはscriptPubKeyが３バイト少なく、署名と公開鍵をscriptSigからwitnessに移動する。

BIP-16のP2SHでネストされたP2WPKH 以下の例は同じP2WPKHだけど、BIP-16のP2SHでネストされている。 witness: <signature> <pubkey> scriptSig: <0 <20-byte-key-hash>> (0x160014{20-byte-key-hash}) scriptPubKey: HASH160 <20-byte-script-hash> EQUAL (0xA914{20-byte-script-hash}87) scriptSig内のアイテムはHASH160でハッシュ化され、scriptPubKey内の20-byte-script-hashと比較され、以下のように解釈される 0 <20-byte-key-hash> 続いて前のサンプルと同様に公開鍵と署名の検証が行われる。 前の（P2WPKHの）例と比べると、scriptPubKeyが１バイト大きくscriptSigは23バイト大きくなる。ネストされたwitness programはあまり効率的ではないが、そのアドレスはBitcoin Core 0.6.0以降のとの完全な下位互換がある。

P2WSH 次の例は、1-of-2のマルチシグのバージョン０のpay-to-witness-script-hash (P2WSH) witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> scriptSig: (empty) scriptPubKey: 0 <32-byte-hash> (0x0020{32-byte-hash}) scriptPubKeyの’0’は続くプッシュデータがバージョン０のwitness programであることを示す。witness programの長さから（32バイトのハッシュなので）P2WSHであることを示している。witnessの最後のアイテム（"witnessScript")がポップされ、SHA256でハッシュされ、scriptPubKey内の32バイトのハッシュと比較され、デシリアライズされる。 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG スクリプトがwitnessに続く残りのデータで実行される。 0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG P2WSHのスクリプトサイズは最大10,000バイトまで。 P2SHの２３バイトとは対照的に、このscriptPubKeyは34バイトを占有する。サイズの増加は衝突攻撃に対する安全性の向上になる。2^80のハッシュ計算はもはや実現不可能ではない。（２０１５年末には、Bitcoinが作られて以降、2^84のハッシュがマイニングで計算されている）使用（消費）するスクリプトは、P2SHの出力のものと同じだが、witnessに移動される。

BIP-16のP2SHでネストされたP2WSH 次の例は、上の例と同じ1-of-2のマルチシグのP2WSHだけど、P2SHの出力でネストされている。 witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG> scriptSig: <0 <32-byte-hash>> (0x0020{32-byte-hash}) scriptPubKey: HASH160 <20-byte-hash> EQUAL (0xA914{20-byte-hash}87) scriptSig内のアイテムはHASH160でハッシュ化され、scriptPubKey内の20バイトのハッシュと比較され以下のように解釈される。 0 <32-byte-hash> 前P2WSHの例と同様に、P2WSHのwitnessScriptが実行される。 前の例と比較すると、witnessは同じだが、scriptPubKeyは１１バイト小さくなっている（その分、衝突攻撃への耐性は減少するけど）。しかしscriptSigで35バイト必要になる。

拡張可能なコミットメント構造 コインベーストランザクションの新しいコミットメントは`witness root hash`と`witness reserved value`のハッシュである。`witness reserved value`には現在コンセンサスの意味は無いが、将来のソフトフォークのための新しいコミットメント値を許可する。例えば将来コンセンサスクリティカルなコミットメントが必要となった際にコインベースにおけるコミットメントは以下のようになる。 Double-SHA256(Witness root hash|Hash(new commitment|witness reserved value)) 後方互換姓のため、Hash(new commitment|witness reserved value) の部分はコインベースのwitnessに記録され、`witness reserved value`は将来のソフトフォークで指定された異なる場所に記録されるだろう。任意の数の新しいコミットメントが同様の方法で追加できる。 マージマイニングのようにBitcoinにコンセンサスクリティカルでない任意のコミットメントは、Bitcoinのコンセンサスプロトコルをアップグレードする能力を保持するために`witness reserved value`を使ってはいけない。 コミットメントに続くオプションのデータ空間は将来のソフトフォークのメタデータのための余地を残しており、他の目的のために使ってはいけない。