Warum sind 20 die maximalen öffentlichen Schlüssel in einer Multisig-Transaktion?

Die Zahl 20 scheint von diesem Commit zu stammen: 8c9479c6bbbc38b897dc97de9d04e4d5a5a36730, auch getaggt als v0.3.12, was den Begriff „SigOps“ einführte. Leider sehe ich keine Erwähnung dieser Änderung in der Commit-Nachricht selbst oder in den Versionshinweisen dieser Version und dort ist keine Dokumentation.

Wir sehen, dass sowohl ein Limit für eine maximale Anzahl von Sigops in einem Block festgelegt wurde:

static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

und eine Möglichkeit, sie zu zählen:

int GetSigOpCount() const
{
    int n = 0;
    const_iterator pc = begin();
    while (pc < end())
    {
        opcodetype opcode;
        if (!GetOp(pc, opcode))
            break;
        if (opcode == OP_CHECKSIG || opcode == OP_CHECKSIGVERIFY)
            n++;
        else if (opcode == OP_CHECKMULTISIG || opcode == OP_CHECKMULTISIGVERIFY)
            n += 20;
    }
    return n;
}

Und die Regeln sind immer noch die gleichen, speziell für bloße Multisig-Skripte (die nicht in p2shoder verschachtelt sind p2wsh). Eine bloße CHECKMULTISIGOperation wird immer als 20 Sigops gezählt (heute 80, mit Witness-Skalierungsfaktor). Wenn Sie also mehr als 20 Checksigs zulassen, CHECKMULTISIGwird diese Annahme ungültig und es werden Blöcke mit mehr als den maximal zulässigen Sigops erstellt.

Für p2sh\p2wsh-Skripte sind die Regeln weniger streng. Wenn der Opcode direkt davor CHECKMULTISIGim Bereich liegt [OP_1, OP_16], wird diese Zahl als Sigops für die Multisig-Verifizierung gezählt, alles andere als 20. In der Praxis ist 15 das Maximum an Pubkeys, die Sie als p2sh-Skript wegen 520 pushen können Bytes Push-Limit, aber für p2wsh würde ein Beispiel von 17-of-20 so aussehen:

0x01 0x11 <pubkey1> <pubkey2> ... <pubkey 20> 0x01 0x14 CHECKMULTISIG