[翻訳]BIP 146署名符号化の拡張性の解決

4074 ワード

総括する


本提案では,ECDSA署名符号化に関連する取引の拡張性を修正するためにビットコイン取引の検証ルールを変更することについて述べる.

動機


署名拡張性とは、ネットワーク内の任意の中継ノードが、対応する取引の秘密鍵を取得する必要がなく、その取引署名を変更する能力を指す.SW以外の取引の場合、署名の拡張性はtxidを変更し、確認されていないすべてのサブ取引を失効させる.SW取引(BIP 141)のtxidがサードパーティ製でない場合でも、このような拡張性のvectorはwtxidを変化させ、コンパクトブロックの中継効率を低下させる可能性がある(BIP 152).
厳格なDER署名が実装されてから、ECDSA署名には2つの既知の拡張性ソースがあります.
  • ECDSA自身の署名拡張性:ECDSA署名は、内部Sの負の値(モード曲線順序)が署名を無効にしないため、自身が拡張性を持っている.
  • 無効な署名の拡張性:OP_を使用する場合CHECKSIGまたはOP_CHECKMULTISIGの署名検証に失敗し、falseがスタックに戻され、スクリプト検証が続行されます.無効な署名は、BIP 66に記載されているすべての規則に従う限り、任意の値を使用することができる.

    • 本提案では,上述した拡張性を修正するための新しいルールを定義した.

    ルール＃ルール＃


    署名符号化の拡張性を修正するために,次の新しい規則を現在の分離検証スクリプトと分離検証スクリプトに適用した.

    LOW_S


    新しい規則では、ECDSA署名内のSの値は、曲線半径を2で割った値(実際にはその下半分の範囲に制限されている)が最大であることが要求されています.それぞれOP_を使用していますCHECKSIG1,OP_CHECKSIGVERIFY,OP_CHECKMULTISIG,OP_CHECKMULTISIGVERIFYオペレーティングコードの署名であり、ECDSA検証を採用している場合、0 x 1および0 x 7のFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 5 D 576 E 7357 A 4501 DDFE 92 F 46681 B 20 A 0を使用し、厳格なDER符号化のS値を採用しなければならない.
    ECDSA認証に渡された署名がLOW_を通過しなかった場合Sがチェックされ、空でないバイト配列である場合、スクリプト全体の評価はすぐに失敗します.
    署名において、S'=0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE BAAEDCE 6 AF 48 A 03 B BFD 25 E 8 C D 0364141−Sにより、S値を平滑に置き換えることができる.

    NULLFAIL


    OP 1つならCHECKSIGはスタックにfalse値を返そうとしたが,対応する署名は空のバイト配列でなければならない.
    OP 1つならCHECKMULTISIGはスタックにfalseを返そうとし、OP_への転送を要求した.CHECKMULTISIGのすべての署名は、早期の署名検証の中断によっていくつかの署名処理がスキップされる可能性がある場合でも、空のバイト配列でなければならない.
    それ以外の場合、スクリプト全体の評価はすぐに失敗します.

    例


    次の例はLOW_SとNULLFAIL 2ルールで構成されています.
    記号:
    CO       : curve order = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
HCO      : half curve order = CO / 2 = 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0
P1, P2   : valid, serialized, public keys
S1L, S2L : valid low S value signatures using respective keys P1 and P2 (1 ≤ S ≤ HCO)
S1H, S2H : signatures with high S value (otherwise valid) using respective keys P1 and P2 (HCO < S < CO)
F        : any BIP66-compliant non-empty byte array but not a valid signature

    これらのスクリプトは、以前のようにTRUEをスタックに返します.
    S1L P1 CHECKSIG
0 S1L S2L 2 P1 P2 2 CHECKMULTISIG

    これらのスクリプトは、以前のようにFALSEをスタックに返します.
    0 P1 CHECKSIG
0 0 0 2 P1 P2 2 CHECKMULTISIG

    新しいルールが実行されると、前のTRUEスクリプトはすぐに失敗します.
    S1H P1 CHECKSIG
0 S1H S2L 2 P1 P2 2 CHECKMULTISIG
0 S1L S2H 2 P1 P2 2 CHECKMULTISIG
0 S1H S2H 2 P1 P2 2 CHECKMULTISIG

    新しいルールが実行されると、前のTRUEスクリプトはすぐに失敗します.
      F P1 CHECKSIG
  0 S2L S1L 2 P1 P2 2 CHECKMULTISIG
  0 S1L F   2 P1 P2 2 CHECKMULTISIG
  0 F   S2L 2 P1 P2 2 CHECKMULTISIG
  0 S1L 0   2 P1 P2 2 CHECKMULTISIG
  0 0   S2L 2 P1 P2 2 CHECKMULTISIG
  0 F   0   2 P1 P2 2 CHECKMULTISIG
  0 0   F   2 P1 P2 2 CHECKMULTISIG

    配置:


    このBIPはBIP 9(版本位)で配備される.
    ビットコインマスターネットワークでは、BIP 9の開始時間は、midnight TBD UTC(紀元タイムスタンプTBD)、BIPの終了時間は、midnight TBD UTC(紀元タイムスタンプTBD)である.
    ビットコインテストネットワークでは、BIP 9の開始時間は、midnight TBD UTC(紀元タイムスタンプTBD)、BIPの終了時間は、midnight TBD UTC(紀元タイムスタンプTBD)である.

    互換性


    v 0から9.0クライアントがLOW_を生成しましたS互換性スクリプト、v 0から.11.1クライアント開始、LOW_Sルールはすでに中継ポリシーとして強制的に実行されている.2016年8月現在、上記のルールに違反した取引がメインチェーンに追加されることは少ない.実際に使用されているすべてのscriptPubKeyタイプでは、互換性のない署名をスムーズに互換性に変換できるため、これらの新しいルールは機能の損失を招くことはありません.
    OP_の使用CHECKSIG or OP_CHECKMULTISIGで失敗したスクリプトは、プライマリ・チェーンにはあまり表示されません.v 0から13.1クライアントが開始し、NULLFAILルールは中継ポリシーとして強制的に実行された.
    新しいスクリプトを設計する場合、ユーザーはこれらの新しいルールに注意する必要があります.

    インプリメンテーション


    参照クライアントの実装は、github/interpreter.cppとgithub/pull

    脚注

  • P 2 WPKHの取引はBIP 141において
    • と記載する.
  • v 0のために注意してください.13.1クライアントにおける具体的な実装の詳細は、S値の高い署名を使用してLOW_を通過したものもある.S検出.しかし、これらの署名は無効であり、その後のNULLFAIL検出に失敗したに違いない.

    • 参照


    BIP 146原文:https://github.com/bitcoin/bips/blob/master/bip-0146.mediawikiECDSAブログ:http://www.instructables.com/id/Understanding-how-ECDSA-protects-your-data/
    本文はCopernicus によって翻訳され、転載は許可を必要としない.
    Spring BootとJPAを使用した2-TIL(1)
    [Programmers][MySQL]牛乳とヨーグルトがいっぱい入ったショッピングバスケット