[翻訳]BIP 66厳格なDER署名(Strict DER signatures)

概要:

この提案は,署名フィールドが厳格なDER符号化でなければならないことを制限するためにビットコイン取引の正当性規則の変化を定義した.

動機:

現在のビットコインの署名検証実装はOpenSSLに依存しており、これはOpenSSLがビットコインのブロック検証ルールを暗黙的に定義していることを意味する.残念なことに、opensslは厳格な共通認識行為を定義していません(異なるバージョン間のbug互換性を保証しません).Opensslライブラリの変更はビットコインソフトウェアの安定化に影響します.特に重要な点は、署名コードです.最近までopensslライブラリのリリース版は、異なるDER標準符号化を受信することができ、署名時に有効であると考えられていました.Opensslが1.0.0 pおよび1.0.1 kからアップグレードされると、一部のノードはプライマリチェーンの承認を拒否する動作を生じさせる.本提案の目的は,有効署名をDERで規定された範囲内に制限し,opensslの署名解析に共通認識規則を依存させないことである.共通認識コードからすべてのopensslを除去するには、このような修正が必要です.

きかく

各転送先はOP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFYオペレーティングコードの署名は、ECDSAの検証を採用するとともに、この署名は厳格なDER符号化を採用しなければならない.公開/秘密鍵ペアグループでは、ECDSA検証を実行するすべての操作がスタックの上部から後方に反復されます.各署名について、次のIsValidSignatureEncoding()メソッドのチェックに失敗した場合、スクリプト全体の実行はすぐに失敗します.署名時に有効なDER符号化が、ECDSAによって検証されていない場合、操作は以前のように実行され続け、操作コードの実行は停止してスタックトップpush false(ただし、すぐにスクリプトを失敗させることはない)に向かい、いくつかのケースでは、いくつかの署名(これらの署名呼び出しIsValidSignatureEncodingを使用しない)をスキップすることがある.

DERコードリファレンス

次のコードは、厳格なDERチェック動作を指定します.注:この関数は、追加バイトのビットコイン署名ハッシュタイプの識別を含む署名バイトベクトルをテストします.この関数は、0の長さの署名で呼び出されず、意図的に埋め込まれた無効な署名に簡単で、短く、効率的な署名検証を提供します.DER定義はhttps://www.itu.int/rec/T-REC-X.690/en .

bool static IsValidSignatureEncoding(const std::vector &sig) {
    // Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]
    // * total-length: 1-byte length descriptor of everything that follows,
    //   excluding the sighash byte.
    // * R-length: 1-byte length descriptor of the R value that follows.
    // * R: arbitrary-length big-endian encoded R value. It must use the shortest
    //   possible encoding for a positive integers (which means no null bytes at
    //   the start, except a single one when the next byte has its highest bit set).
    // * S-length: 1-byte length descriptor of the S value that follows.
    // * S: arbitrary-length big-endian encoded S value. The same rules apply.
    // * sighash: 1-byte value indicating what data is hashed (not part of the DER
    //   signature)

    // Minimum and maximum size constraints.
    if (sig.size() < 9) return false;
    if (sig.size() > 73) return false;

    // A signature is of type 0x30 (compound).
    if (sig[0] != 0x30) return false;

    // Make sure the length covers the entire signature.
    if (sig[1] != sig.size() - 3) return false;

    // Extract the length of the R element.
    unsigned int lenR = sig[3];

    // Make sure the length of the S element is still inside the signature.
    if (5 + lenR >= sig.size()) return false;

    // Extract the length of the S element.
    unsigned int lenS = sig[5 + lenR];

    // Verify that the length of the signature matches the sum of the length
    // of the elements.
    if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
 
    // Check whether the R element is an integer.
    if (sig[2] != 0x02) return false;

    // Zero-length integers are not allowed for R.
    if (lenR == 0) return false;

    // Negative numbers are not allowed for R.
    if (sig[4] & 0x80) return false;

    // Null bytes at the start of R are not allowed, unless R would
    // otherwise be interpreted as a negative number.
    if (lenR > 1 && (sig[4] == 0x00) && !(sig[5] & 0x80)) return false;

    // Check whether the S element is an integer.
    if (sig[lenR + 4] != 0x02) return false;

    // Zero-length integers are not allowed for S.
    if (lenS == 0) return false;

    // Negative numbers are not allowed for S.
    if (sig[lenR + 6] & 0x80) return false;

    // Null bytes at the start of S are not allowed, unless S would otherwise be
    // interpreted as a negative number.
    if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80)) return false;

    return true;
}

例

シンボル:p 1およびp 2は有効であり、シーケンス化された公開鍵である.s 1およびs 2は、p 1およびp 2に対応する有効な署名である.s 1′とs 2′は非DERの符号化であるが,同じ公開鍵の有効署名を用いる.Fはすべての無効なDER互換署名(0、この空の文字列を含む)です.F'は無効であり、DER互換性のない署名です.

S1' P1 CHECKSIG fails (changed)

S1' P1 CHECKSIG NOT fails (unchanged)

F P1 CHECKSIG fails (unchanged)

F P1 CHECKSIG NOT can succeed (unchanged)

F' P1 CHECKSIG fails (unchanged)

F' P1 CHECKSIG NOT fails (changed)

0 S1' S2 2 P1 P2 2 CHECKMULTISIG fails (changed)

0 S1' S2 2 P1 P2 2 CHECKMULTISIG NOT fails (unchanged)

0 F S2' 2 P1 P2 2 CHECKMULTISIG fails (unchanged)

0 F S2' 2 P1 P2 2 CHECKMULTISIG NOT fails (changed)

0 S1' F 2 P1 P2 2 CHECKMULTISIG fails (unchanged)

0 S1' F 2 P1 P2 2 CHECKMULTISIG NOT can succeed (unchanged)

注:上記の例では、この変化は、ソフトフォークが要求するように、追加の検証失敗例を追加しただけであることを示しています.

配置

BIP 34の二重しきい値切替機構を繰り返し使用し、同じしきい値を使用するが、バージョン番号は3.この新しい規則は、バージョン番号3のすべてのブロックに影響し、1000個のブロックごとに少なくとも750個のバージョン番号3のブロックが含まれている.さらに、1000個のブロックごとに950個以上のバージョン番号3のブロックが含まれている場合、バージョン番号2のブロックは無効となり、以降のすべての新しいブロックが新しいルールを強制的に採用する.

互換性

0.8.0以降、署名要件はDER符号化を厳格に強制し、中継ポリシーとして使用されており、2015年1月以降、このルールに違反した取引はほとんどプライマリチェーンに追加されていない.それ以外に、各非互換署名は互換署名にスムーズに変換できるので、機能の損失はありません.本提案は,取引の延性を低下させる利点もある.

参照

テキストリンク:https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
本文はCopernicusチームの姚永芯が翻訳し、転載は許可を必要としない.