BIP UNOFFICIAL DRAFT 0

提供: tezos-wiki
移動先: 案内、 検索 
  BIP：17
  タイトル：OP_NO_SKIP
  著者：Ben Reeves <support@pi​​.uk.com>
  ステータス：拒否
  タイプ：標準トラック
  作成日：14-01-2012

要約[編集]

このBIPは、新しいオペコード（ "OP_NO_SKIP"）と新しいタイプの標準トランザクションを記述します。

モチベーション[編集]

この提案の目的は、標準のテンプレートをスクリプト言語の必須部分にすることなく、スクリプトの機能を有料にすることです。

BIP_0016：

pay-to-script-hashの目的は、資金を送金者から償還者に償還する条件を提供する責任を移転することです。

メリットは、送信者がQRコードからスキャンするのに十分短いか、または簡単にコピーして貼り付けるのに十分な長さの固定長の20バイトのハッシュを使用して、どんなに複雑であっても任意のトランザクションに資金を提供できることです。

仕様[編集]

OP_NOP1はOP_NO_SKIPとして再定義され、次のように動作します：

  • OP_NO_SKIPはそれ自身ではNULL演算子のままです。
  • OP_NO_SKIPの直後にある "プッシュデータ"操作は、通常どおりデータをスタックにプッシュしますが、命令ポインタを進めることはありません。つまり、データはスタックにプッシュされて実行されます。

さらに、新しい標準のscriptPubKeyが定義されます： 

  OP_CHECKMULTISIGVERIFY OP_HASH160 [20-byte-hash-value] OP_EQUAL

新しい標準スクリプトであるSig（M of N） 

  OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2} >

実行例[編集]

基本的な例：

Stack Code
OP_NO_SKIP OP_PUSHDATA1 1 OP_1NEGATE OP_ADD
OP_PUSHDATA1 1 OP_1NEGATE OP_ADD
79 OP_1NEGATE OP_ADD
79 -1 OP_ADD
78

スクリプトの支払い例：

Stack Code
32 <sig> OP_NO_SKIP 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> OP_NO_SKIP 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> 22 <OP_SWAP 1 [pubkey] 2> OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<sig> <OP_SWAP 1 [pubkey] 2> OP_SWAP 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<OP_SWAP 1 [pubkey] 2> <sig> 1 [pubkey] 2 OP_CHECKMULTISIGVERIFY OP_HASH160 20 <scriptHash> OP_EQUAL
<OP_SWAP 1 [pubkey] 2> OP_HASH160 20 <scriptHash> OP_EQUAL
<scriptHashA> 20 <scriptHash> OP_EQUAL
<scriptHashA> <scriptHash> OP_EQUAL
1

理論的根拠[編集]

このBIPはBIP 12（ "OP_EVAL"）とBIP 16（ "/ P2SH /"）に代わるものです。

スクリプト機能に対する支払いの理論的根拠は他の提案で議論されているが、一般的な合意はこの機能性が望まれており、できるだけ早く実施すべきであるということである。

これまでの提案では、多数の潜在的な問題が見つかりました。

  • CHVは、scriptPubKeyがスタックにプッシュされていないscriptSigからのデータと対話することを要求します
  • OP_EVALは本質的にスクリプト言語を完成させるもので、哲学の意図的な意図は避けています。
  • P2SHでは、標準テンプレートがスクリプト言語の必須部分になることが要求されています。つまり、将来的に完全に価値を下げることはできません。

OP_NO_SKIPは、言語に特別な表現力を与えたり、単純なスタックベースの言語の規則に違反することなく、有料スクリプト機能を可能にする単純な妥協案になるように設計されています。

下位互換性[編集]

これらのトランザクションは、（通常は）リレーしないか、またはブロックに含める古い実装には標準ではありません。

古い実装では、スクリプトをスタックにプッシュし、ハッシュ値の一致を検証しますが、他の検証は行いません。新しいクライアントは、スクリプトをスタックにプッシュして実行します。

悪質なpay-to-scriptトランザクションによるブロックチェーンの分割を避けるには、1つのケースを注意深く処理する必要があります。

  • 新しいクライアント/鉱夫は無効ですが、古いクライアント/鉱夫は有効です。

正常にアップグレードし、長時間にわたるブロックチェーン分割が発生しないようにするには、鉱夫の50％以上が新しいトランザクションタイプの完全な検証をサポートしなければならず、古い検証ルールから新しいルールに同時に切り替える必要があります。

ハッシュ・パワーの50％以上がこのBIPをサポートしているかどうかを判断するために、鉱夫はソフトウェアをアップグレードし、コインベース取引の入力に "/ OPNOSKIP /"という文字列を作成するよう求められます。

2012年2月1日、ブロックチェーンを調べて、過去7日間のpay-to-script-hashをサポートするブロックの数を決定します。コインベースに550個以上の "/ OPNOSKIP /"が含まれている場合、2012年2月15日00:00:00 GMT以降のタイムスタンプを持つすべてのブロックは、pay-to-script-hashトランザクションを完全に検証するものとする。 1週間におよそ1,000のブロックが作成されます。したがって、新しい機能をサポートするネットワークの約55％になるはずです。

大部分のハッシング・パワーが新しい検証ルールをサポートしていない場合、ロールアウトは延期される（または多数決が決して達成されないことが明らかになった場合には却下される）。

リファレンスの実装[編集]

https://github.com/zootreeves/bitcoin/commits/master

拒絶理由[編集]

任意の鉱夫は、正当な署名スクリプトを置き換えることによって、トランザクションを簡単に没収することができます： 

  OP_0  <sig> OP_NO_SKIP <OP_SWAP {1 [pubkey1] [pubkey2] 2} >

with 

  <OP_SWAP {1 [pubkey1] [pubkey2] 2} > OP_0 <miner's_sig> OP_1 <miner's_pubkey> OP_1

関連項目[編集]

「http://tezos-wiki.jp/wiki/index.php?title=BIP_UNOFFICIAL_DRAFT_0&oldid=23570」から取得