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

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

BIP（ビットコイン改善提案） GitHub · 対象日 · 登録日 · 更新日
人物： エリック・ロンブロゾ ,  ジョンソン・ラウ ,  ピーター・ウィーユ
SegWitスケーリングソフトフォークトランザクション展性ライトニングネットワークブロックサイズブロックサイズ戦争
エリック・ロンブロゾ（Eric Lombrozo） 2015年12月21日 
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

他の外部ソース