ビットコイン・インスティテュート

BIP 141 — Segregated Witness（コンセンサスレイヤー）

事象 · 更新 · 提案者 エリック・ロンブロゾ · BIP（ビットコイン改善提案） · GitHub
人物： エリック・ロンブロゾ ,  ジョンソン・ラウ ,  ピーター・ウィーユ
BIPSegWitスケーリングソフトフォークトランザクション展性ライトニングネットワークブロックサイズ 
BIP: 141
  Layer: Consensus (soft fork)
  Title: Segregated Witness (Consensus layer)
  Authors: Eric Lombrozo <elombrozo@gmail.com>
           Johnson Lau <jl2012@xbt.hk>
           Pieter Wuille <pieter.wuille@gmail.com>
  Status: Deployed
  Type: Specification
  Assigned: 2015-12-21
  License: PD

概要

本 BIP は「ウィットネス」と呼ばれる新しい構造を定義する。これはトランザクションマークルツリーとは別途、ブロックにコミットされる。本構造はトランザクションの正当性を検査するために必要だが、トランザクションの効果を決定するためには必要でないデータを保持する。具体的には、スクリプトと署名がこの新構造に移される。

ウィットネスは、本 BIP をソフトフォークとして互換に保つ目的で、コインベーストランザクションを介してブロック既存のマークルルートに入れ子化されたツリーにコミットされる。将来のハードフォークでは、このツリーを独自のブランチに配置できる。

動機

トランザクションの効果全体は、出力の消費 (使用) と新たな出力の生成によって決定される。それ以外のトランザクションデータ、特に署名は、ブロックチェーン状態を検証するために必要であって、状態を決定するためには必要ない。

これらのデータをトランザクションマークルツリーにコミットされるトランザクション構造から取り除くことで、いくつかの問題が解決される。

  1. 非意図的な展性が不可能になる。署名データがトランザクションハッシュの一部ではなくなるため、トランザクションへの署名方法の変更はトランザクション識別と無関係になる。トランザクション展性への解決策として、これは正規署名手法 (BIP62 (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki)) よりも優れている。
  • すべてのインプットが署名されている (CHECKSIG または CHECKMULTISIG 操作が最低 1 つある) 限り、あらゆるスクリプト型に対して非意図的なトランザクション展性を防止する。
  • m-of-n CHECKMULTISIG スクリプトの場合、トランザクションが展性を持つのは m 名の秘密鍵保持者の合意がある場合に限られる (BIP62 では秘密鍵保持者 1 名だけで展性が成立する)。
  • 未知の ECDSA 署名展性に起因する非意図的なトランザクション展性を防止する。
  • 相手方リスクなしに未確認トランザクション依存連鎖の構築を可能にする。これはライトニングネットワークのようなオフチェーンプロトコルにとって重要な機能である。
  1. 署名データの伝送が任意となる。署名データが必要なのは、ピアがトランザクションの存在を確認するだけでなく、その正当性を検証しようとする場合のみである。これにより SPV 証明のサイズが縮小し、SPV クライアントが同じ帯域でより多くのトランザクションをダウンロードできるため、その匿名性が向上する可能性もある。
  2. 一部の制約をソフトフォークで回避できる。トランザクションデータの一部を現行プロトコルに未知の構造に移すことで、たとえば以下が可能になる。
  • ブロックサイズ計算時にウィットネスのサイズを無視ないし割引することで、実効的にブロックサイズをある程度拡張できる。
  • 最大データプッシュサイズ (520 バイト) や sigops 制限などのハードコードされた定数を再評価ないし撤廃できる。
  • 既存スクリプトセマンティクスの制約を受けない新しいスクリプトシステムを導入できる。たとえばトランザクション署名検証のための新しいトランザクションダイジェストアルゴリズムが BIP143 (https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) で記述されている。

仕様

トランザクション ID

新たなデータ構造 witness が定義される。各トランザクションは 2 つの ID を持つ。

txid の定義は変更されない。すなわち、従来のシリアライゼーション形式の二重 SHA256 ハッシュである。

[nVersion][txins][txouts][nLockTime]

新たに wtxid が定義される。これはウィットネスデータを含む新シリアライゼーションの二重 SHA256 ハッシュである。

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

nVersion、txins、txouts、nLockTime の形式は従来のシリアライゼーションと同じである。

marker は 1 バイトのゼロ値 0x00 でなければならない (MUST)。

flag は 1 バイトの非ゼロ値でなければならない (MUST)。現状では 0x01 を用いなければならない (MUST)。

witness はトランザクションのすべてのウィットネスフィールドのシリアライゼーションである。各 txin にはウィットネスフィールドが対応する。ウィットネスフィールドは、その txin に対するスタック項目数を示す var_int から始まる。続いてスタック項目が並び、各項目はその長さを示す var_int から始まる。ウィットネスデータはスクリプトではない。

非ウィットネスプログラム (以下で定義) の txin は、0x00 で表される空のウィットネスフィールドと対応していなければならない (MUST)。すべての txin がウィットネスプログラムでない場合、トランザクションの wtxid はその txid と等しい。

コミットメント構造

wtxid へのコミットメントを要求する新たなブロックルールが追加される。コインベーストランザクションの wtxid は 0x0000....0000 と仮定する。

witness root hash は、これらすべての wtxid を葉として、ブロックヘッダー内の hashMerkleRoot と同様の方法で計算される。

コミットメントはコインベーストランザクションの scriptPubKey に記録される。少なくとも 38 バイトであり、先頭 6 バイトは 0x6a24aa21a9ed でなければならない。すなわち、

1 バイト - OP_RETURN (0x6a) 1 バイト - 続く 36 バイトをプッシュ (0x24) 4 バイト - コミットメントヘッダー (0xaa21a9ed) 32 バイト - コミットメントハッシュ: Double-SHA256(witness root hash|witness reserved value)

39 バイト目以降: コンセンサス上の意味を持たない任意データ

であり、コインベースのインプットのウィットネスは witness reserved value のための単一の 32 バイト配列で構成されなければならない。

このパターンに合致する scriptPubKey が複数存在する場合、出力インデックスが最も大きいものをコミットメントと仮定する。

ブロック内のすべてのトランザクションがウィットネスデータを持たない場合、コミットメントは任意である。

ウィットネスプログラム

1 バイトのプッシュオペコード (OP_0,OP_1,OP_2,...,OP_16 のいずれか) に続いて 2 から 40 バイトの直接データプッシュからなる scriptPubKey (または BIP16/P2SH で定義される redeemScript) には、新たな特別な意味が与えられる。最初のプッシュの値は「バージョンバイト」と呼ばれる。続いてプッシュされるバイト列は「ウィットネスプログラム」と呼ばれる。 より詳しくは、これは (順に) 以下から構成される scriptPubKey または redeemScript を意味する。

  • まず、バイト 0x00 (OP_0) または 0x51 (OP_1) から 0x60 (OP_16) までのいずれかのバイト (バージョンバイト)。
  • 次に、0x02 (2 バイトのプッシュ) から 0x28 (40 バイトのプッシュ) までのいずれかのバイト L。
  • 最後に、L 個の任意のバイト (ウィットネスプログラム)。

ウィットネス検証ロジックが起動するケースは 2 つある。各ケースにおいて、ウィットネスバージョンバイトとプログラムの位置、および scriptSig の形式が決定される。

  1. ちょうどバージョンバイトのプッシュとウィットネスプログラムのプッシュからなる scriptPubKey によって起動される場合。scriptSig はちょうど空でなければならず、そうでなければ検証は失敗する (「ネイティブウィットネスプログラム」)。
  2. scriptPubKey が P2SH スクリプトであり、scriptSig にプッシュされた BIP16 redeemScript がちょうどバージョンバイトのプッシュとウィットネスプログラムのプッシュからなる場合に起動される。scriptSig はちょうど BIP16 redeemScript のプッシュでなければならず、そうでなければ検証は失敗する (「P2SH ウィットネスプログラム」)。

バージョンバイトが 0 でウィットネスプログラムが 20 バイトの場合 (L = 20):

  • pay-to-witness-public-key-hash (P2WPKH) プログラムとして解釈される。
  • ウィットネスはちょうど 2 個の項目 (各々 520 バイト以下) から構成されなければならない。1 つ目は署名、2 つ目は公開鍵である。
  • 公開鍵の HASH160 は 20 バイトのウィットネスプログラムと一致しなければならない。
  • 通常のスクリプト評価の後、署名は CHECKSIG 操作によって公開鍵に対して検証される。検証はスタック上にちょうど 1 つの TRUE を残さなければならない。

バージョンバイトが 0 でウィットネスプログラムが 32 バイトの場合 (L = 32):

  • pay-to-witness-script-hash (P2WSH) プログラムとして解釈される。
  • ウィットネスはスクリプトに渡される入力スタックと、それに続くシリアライズ済みスクリプト (witnessScript) から構成されなければならない。
  • witnessScript (10,000 バイト以下) は初期ウィットネススタックからポップされる。witnessScript の SHA256 は 32 バイトのウィットネスプログラムと一致しなければならない。
  • witnessScript はデシリアライズされ、通常のスクリプト評価の後、残りのウィットネススタック (各スタック項目 520 バイト以下) を用いて実行される。
  • スクリプトは失敗してはならず、スタック上にちょうど 1 つの TRUE を残さなければならない。

バージョンバイトが 0 で、ウィットネスプログラムが 20 バイトでも 32 バイトでもない場合、スクリプトは失敗しなければならない。たとえば、OP_0 に続いて 40 バイトの非ゼロデータプッシュを持つ scriptPubKey は、プログラムサイズが不正であるため失敗する。一方、OP_0 に続いて 41 バイトの非ゼロデータプッシュを持つ scriptPubKey は通過する。これはウィットネスプログラムと見なされないためである。

バージョンバイトが 1 から 16 の場合、ウィットネスプログラムやウィットネススタックのそれ以上の解釈は行われず、ウィットネススタックにサイズ制限はない。これらのバージョンは将来の拡張のために予約されている。後方互換性のため、0 から 16 のいずれのバージョンバイトについても、ウィットネスプログラムの CastToBool 値がゼロの場合、スクリプトは失敗しなければならない。ただし、このようなハッシュを持つことはハッシュ関数に対するプリイメージ攻撃の成功を意味し、そのリスクは無視できる。

その他のコンセンサス上重要な制限

ブロックサイズ

ブロックは現在、合計サイズが 1,000,000 バイト (1MB) に制限されている。この制限を以下のように変更する。

ブロックウェイト (Block weight) は ベースサイズ (Base size) × 3 + 合計サイズ (Total size) と定義される。(根拠1MB のベースデータと 3MB のウィットネスデータといった 2 つの別個の制限ではなく単一の合成制約を用いる根拠: 別個の 2 つの制限を用いるとマイニングと手数料推定がほぼ不可能になる。マイナーは両制約のもとで手数料を最大化するトランザクション集合を見つけるために複雑な非線形最適化問題を解く必要があり、ウォレットはマイナーがブロックを生成しようとする時点でどちらの条件がより制約的かに依存するため、何を支払うべきかを知ることができなくなる。この手法のもう 1 つの問題はフリーローディングである。トランザクション集合がベースデータ 1MB の制約に達した時点で、ごく僅かに手数料を増やすだけで最大 3MB の追加データをウィットネスに加えられてしまう。この場合、追加のウィットネス領域に対する限界費用は実質的にゼロになる。)

ベースサイズ (Base size) は、未アップグレードのノードから見た、ウィットネス関連データを含まない元のトランザクションシリアライゼーションによるブロックサイズ (バイト) である。

合計サイズ (Total size) は、ベースデータとウィットネスデータを含めて BIP144 (https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) に記述される方法でシリアライズされたトランザクションを含むブロックサイズ (バイト) である。

新たなルールは ブロックウェイト (block weight) ≤ 4,000,000 である。

Sigops

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

現行の pubkey スクリプト、署名スクリプト、P2SH チェックスクリプト内の sigops は、従来の値の 4 倍として数える。 sigop の制限値も同様に 4 倍され ≤ 80,000 となる。

各 P2WPKH インプットは 1 sigop として数える。加えて、P2WSH witnessScript 内のオペコードは、従来の P2SH redeemScript 内と同じ規則で数える。すなわち、CHECKSIG は 1 sigop としてのみ数える。OP_1 から OP_16 が直前にある CHECKMULTISIG はそれぞれ 1 から 16 sigops として数え、それ以外の場合は 20 sigops として数える。本ルールはネイティブウィットネスプログラムと P2SH ウィットネスプログラムの双方に適用される。

追加定義

以下の定義はコンセンサス制限には用いられないが、上述の用語と整合する語彙を提供するために示す。

トランザクションサイズの計算

トランザクションウェイト (Transaction weight) は ベーストランザクションサイズ (Base transaction size) × 3 + 合計トランザクションサイズ (Total transaction size) と定義される (すなわち ブロックウェイト (Block weight) を ベースサイズ (Base size) と 合計サイズ (Total size) から計算するのと同じ方式)。

仮想トランザクションサイズ (Virtual transaction size) は トランザクションウェイト (Transaction weight) / 4 (次の整数へ切り上げ) と定義される。

ベーストランザクションサイズ (Base transaction size) は、ウィットネスデータを取り除いてシリアライズされたトランザクションのサイズである。

合計トランザクションサイズ (Total transaction size) は、ベースデータとウィットネスデータを含めて BIP144 (https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) に記述される方法でシリアライズされたトランザクションサイズ (バイト) である。

新しいスクリプトセマンティクス

P2WPKH および P2WSH のスクリプト言語は分離ウィットネス導入前のスクリプトに非常によく似て見えるが、いくつかの注目すべき差異がある。利用者は、分離ウィットネス導入前のシステムで使用可能なスクリプトが P2WPKH または P2WSH スクリプトとしても使用可能であると仮定してはならない (MUST NOT)。本番ネットワークでの大規模展開の前に、開発者はデフォルトリレーポリシーを有効にしたテストネットで、また BIP141 がメインネットで有効化された後に少額でスクリプトを試験するべきである。

コンセンサスレベルでの主要な差異は BIP143 (https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) で記述されている。これはバージョン 0 ウィットネスプログラムにおける署名検証のための新しいトランザクションダイジェストアルゴリズムである。

参照実装バージョン 0.13.1 における分離ウィットネスの初回リリースには、リレーおよびマイニングの 3 つのポリシーも含まれる。これらのポリシーに基づくソフトフォークは近い将来に提案される見込みである。トランザクション確認の無期限な遅延、また将来のソフトフォークでの恒久的な資金喪失を避けるため、利用者は新しいセマンティクスを慎重に遵守しなければならない (MUST)。

  1. P2WPKH および P2WSH では圧縮公開鍵のみが受け入れられる (BIP143 (https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type) 参照)。
  2. P2WSH における OP_IF/NOTIF の引数はミニマルでなければならない。https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html
  3. OP_CHECKSIG または OP_CHECKMULTISIG が失敗した場合、署名はヌルベクトルでなければならない (分離ウィットネス導入前のスクリプトと P2WSH の双方に適用、BIP146 (https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki) 参照)。

例

P2WPKH

以下の例はバージョン 0 の pay-to-witness-public-key-hash (P2WPKH) である。

witness:      <signature> <pubkey>
scriptSig:    (empty)
scriptPubKey: 0 <20-byte-key-hash>
              (0x0014{20-byte-key-hash})

scriptPubKey の 0 は、続くプッシュがバージョン 0 ウィットネスプログラムであることを示す。ウィットネスプログラムの長さは、それが P2WPKH 型であることを示す。ウィットネスはちょうど 2 個の項目から構成されなければならない。ウィットネス内の pubkey の HASH160 はウィットネスプログラムと一致しなければならない。

署名は以下のように検証される。

<signature> <pubkey> CHECKSIG

従来の P2PKH 出力と比較すると、P2WPKH の同等出力は scriptPubKey で 3 バイト少なく、署名と公開鍵を scriptSig からウィットネスに移している。

BIP16 P2SH に入れ子化された P2WPKH

以下の例は上と同じ P2WPKH を BIP16 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>

その後、公開鍵と署名は前の例で記述したように検証される。

前の例と比較すると、scriptPubKey は 1 バイト大きく、scriptSig は 23 バイト大きい。入れ子化したウィットネスプログラムは効率が劣るが、その支払いアドレスは完全に透過的であり、バージョン 0.6.0 以降のすべての Bitcoin 参照クライアントと後方互換である。

P2WSH

以下の例は 1-of-2 マルチシグのバージョン 0 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 は、続くプッシュがバージョン 0 ウィットネスプログラムであることを示す。ウィットネスプログラムの長さは、それが P2WSH 型であることを示す。ウィットネスの最後の項目 (witnessScript) がポップされ、SHA256 でハッシュされ、scriptPubKey 内の 32-byte-hash と比較された後、デシリアライズされる。

1 <pubkey1> <pubkey2> 2 CHECKMULTISIG

スクリプトはウィットネスの残りのデータを用いて実行される。

0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG

P2WSH では 520 バイトのプッシュ制限が回避されるため、最大スクリプトサイズが 10,000 バイトまで許容される。

scriptPubKey は 34 バイトを占め、BIP16 P2SH の 23 バイトに対して大きい。このサイズ増加は、起こりうる衝突攻撃に対する安全性を向上させる。280 の作業量はもはや実行不能とは言えないためである (2015 年末時点で、ビットコイン創設以来のマイニングにおいて 284 回のハッシュが計算されている)。使用スクリプトは同等の BIP16 P2SH 出力のものと同じだが、ウィットネスに移されている。

BIP16 P2SH に入れ子化された P2WSH

以下の例は上と同じ 1-of-2 マルチシグ P2WSH スクリプトを BIP16 P2SH 出力に入れ子化したものである。

witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

scriptSig の唯一の項目は HASH160 でハッシュされ、scriptPubKey 内の 20-byte-hash と比較され、以下のように解釈される。

0 <32-byte-hash>

その後、P2WSH の witnessScript は前の例で記述したように実行される。

前の例と比較すると、scriptPubKey は 11 バイト小さい (安全性は低下する) が、ウィットネスは同じである。ただし、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 reserved value は将来のソフトフォークが指定する別の場所に記録される。この方式で任意の数の新コミットメントを追加できる。

ビットコインにとってコンセンサス上重要でないコミットメント (マージマイニング等) は、ビットコインコンセンサスプロトコルのアップグレード余地を保つため、witness reserved value を用いてはならない (MUST NOT)。

コミットメントに続く任意データ領域もまた将来のソフトフォークのメタデータのために残されており、他の目的に用いてはならない (MUST NOT)。

信頼不要な未確認トランザクション依存連鎖

分離ウィットネスはトランザクション展性の問題を根本から解決し、未確認トランザクション依存連鎖を信頼不要な形で構築可能にする。

アリスとボブの 2 者は、一定量のビットコインを 2-of-2 マルチシグ出力 (「ファンディングトランザクション」) に送ることに合意できる。ファンディングトランザクションに署名する前に、両者は別のトランザクションを作成し、将来時点へのタイムロックを掛けて、その 2-of-2 マルチシグ出力を第三のアカウントに使用する (「使用トランザクション」)。アリスとボブは使用トランザクションに署名し、署名を交換する。署名を確認した後、両者はファンディングトランザクションに署名し、ブロックチェーンへコミットする。それ以上の動作がなければ、使用トランザクションはロックタイム経過後に承認され、当初の契約に従って資金が解放される。さらに、より短いロックタイムを持つ別の使用トランザクションによってロックタイム前に当初契約を取り消す柔軟性も保たれる。ただし双方の合意が必要である。

このような設定は、展性修正としての BIP62 では実現できない。両者がまずファンディングトランザクションに署名しなければ使用トランザクションを作成できないためである。アリスがボブより先にファンディングトランザクションの署名を開示してしまうと、ボブは使用トランザクションへ一切署名しないまま資金を無期限にロックし続けられる。

未確認トランザクション依存連鎖は、双方向マイクロペイメントチャネルやライトニングネットワークといった、より高度な支払いネットワークの基本的な構成要素であり、ビットコインシステムの拡張性と効率を大きく向上させる潜在性を持つ。

将来の拡張

SPV ノード向けのコンパクトな不正証明

ビットコインには現状、実用上 2 種類のセキュリティモデルしかない。ユーザーは、システムのすべてのルールで各ブロックを検証するフルノードを動かすか、あるいは特定のトランザクションの公開証明としてヘッダーのみを検証する SPV (Simple Payment Verification) クライアントを動かすかのいずれかである。ビットコイン白書は、SPV ノードがフルノードから不正ブロックの検出時に警報を受け取り、その問題のブロックとトランザクションをダウンロードして検証する方式を示唆していた。しかしこの手法は、虚偽警報の生成コストが実質ゼロであるため、DoS 攻撃の経路になりうる。警報にはコンパクトかつ決定的な不正証明が伴わなければならない。

現行のビットコインプロトコルでは、いくつかの例外を除くほぼすべてのルールについてコンパクトな不正証明を生成可能である。例外は以下である。

  1. マイナーがコインベーストランザクション出力で過剰なビットコインを発行したことを、ブロック全体と全インプットトランザクションを示さずに証明することは不可能である。
  2. ブロック固有の制約 (サイズや sigop 制限等) への違反を、ブロック全体 (sigop 制限の場合は全インプットトランザクションも) を示さずに証明することは不可能である。
  3. 存在しないインプットの使用を、ジェネシスブロックまで遡るブロックチェーン上の全トランザクション ID を示さずに証明することは不可能である。

追加のウィットネスデータをコミットすることで、SPV ノードが迅速に検証可能な、ブロック非妥当性のコンパクトな証明が可能になる。

  1. トランザクション手数料の合計ツリーをコミットすることで、マイナーがコインベーストランザクションに過剰な手数料を加えていないことのコンパクトな証明を構成可能になる。ブロックサイズや sigop 数の制限についても同様である。
  2. トランザクションのインプットが使用する出力への逆方向リンクを提供できる。これらの逆方向リンクはブロックハッシュとオフセットから構成され、シンクライアントは容易にクエリして出力の存在を検証できる。

これらのコミットメントは拡張可能なコミットメント構造を介してソフトフォークで含めることができ、新ルールを理解しないノードに対しては透過的になる。

新しいスクリプトシステム

ウィットネスプログラムの前にバージョンバイトがプッシュされ、未知のバージョンのプログラムは常に anyone-can-spend スクリプトと見なされるため、ソフトフォークによって任意の新しいスクリプトシステムを導入可能である。構造としてのウィットネスは既存のスクリプトセマンティクスや制約、特に 520 バイトプッシュ制限の影響を受けず、任意の大きさのスクリプトと署名を許容する。

新しいスクリプトシステムの例には、マルチシグトランザクションのサイズを大幅に削減するシュノア署名、量子計算機への耐性を持つラムポート署名、極端に複雑な条件付きスクリプトに対して非常にコンパクトなウィットネスを可能にするマークル化抽象構文木 (MAST) が含まれる。

インプットごとのロックタイムと相対ロックタイム

現在、トランザクション内には nLockTime フィールドが 1 つしかなく、すべてのインプットは同じ値を共有しなければならない。BIP68 (https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) は nSequence フィールドを用いてインプットごとの相対ロックタイムを可能にするが、ロックタイム期間と分解能に制限がある。

ソフトフォークにより、インプットごとのロックタイムと相対ロックタイムを許容する独立したウィットネス構造を導入し、新データへの署名と操作が可能な新しいスクリプトシステム (BIP65 (https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) や BIP112 (https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) のような) を導入することが可能である。

後方互換性

ソフトフォークであるため、旧ソフトウェアは変更なしで動作を継続する。ただし、未アップグレードのノードはウィットネスデータを見ることも検証することもなく、すべてのウィットネスプログラムを anyone-can-spend スクリプトと見なす (ウィットネスプログラムが 0 に等しい一部のエッジケースを除く。この場合スクリプトは失敗しなければならない)。ウォレットは常に anyone-can-spend スクリプトに注意し、疑いをもって扱うべきである。未アップグレードのノードは、新機能を活用するためにアップグレードすることが強く推奨される。

未アップグレードのウォレットができること

  • 未アップグレードおよびアップグレード済みウォレットからのビットコイン受領
  • 従来の P2PKH アドレスで未アップグレードおよびアップグレード済みウォレットへビットコインを送付 (分離ウィットネスの利点なし)
  • P2SH アドレスでアップグレード済みウォレットへビットコインを送付
  • BIP70 (https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) 支払いプロトコルを介してネイティブウィットネスプログラムでアップグレード済みウォレットへビットコインを送付

未アップグレードのウォレットができないこと

  • 分離ウィットネストランザクションの検証。そのようなトランザクションを常に有効と仮定する。

配備

本 BIP は「バージョンビット」 BIP9 を用い、名前を segwit、ビットを 1 として展開される。

ビットコインメインネットでは、BIP9 開始時刻は 2016 年 11 月 15 日 UTC の午前 0 時 (エポックタイムスタンプ 1479168000) であり、BIP9 タイムアウトは 2017 年 11 月 15 日 UTC の午前 0 時 (エポックタイムスタンプ 1510704000) である。

ビットコインテストネットでは、BIP9 開始時刻は 2016 年 5 月 1 日 UTC の午前 0 時 (エポックタイムスタンプ 1462060800) であり、BIP9 タイムアウトは 2017 年 5 月 1 日 UTC の午前 0 時 (エポックタイムスタンプ 1493596800) である。

クレジット

本 BIP のアイディアの多くを生み出したグレゴリー・マクスウェルと、これをソフトフォークとして展開する方法を見出した Luke-Jr に特別な感謝を表する。

脚注

参照実装

https://github.com/bitcoin/bitcoin/pull/8149

参考文献

  • BIP16 Pay to Script Hash (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki)
  • BIP143 Transaction Signature Verification for Version 0 Witness Program (https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)
  • BIP144 Segregated Witness (Peer Services) (https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki)
  • BIP173 Base32 address format for native v0-16 witness outputs (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)

著作権

本文書はパブリックドメインに置かれる。

関連エントリー

原典の外部ソース

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

他の外部ソース