Почему 20 максимальных открытых ключей в мультиподписной транзакции?

Число 20, по-видимому, происходит от этой фиксации : 8c9479c6bbbc38b897dc97de9d04e4d5a5a36730, также помеченной как v0.3.12, которая ввела термин «SigOps». К сожалению, я не вижу никаких упоминаний об этом изменении в самом сообщении фиксации или в примечании к выпуску этой версии, и там нет никакой документации.

Мы видим, что было установлено ограничение на максимальное количество сигопов в блоке:

static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

и способ их подсчета:

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;
}

И правила остаются теми же, особенно для голых скриптов с мультиподписью (тех, которые не вложены в p2shили p2wsh). Чистая CHECKMULTISIGоперация всегда считается как 20 сигоп (сегодня 80, с учетом масштабного коэффициента), поэтому допущение чего-либо, превышающего 20 контрольных сигналов CHECKMULTISIG, сделает это предположение недействительным и сделает возможным создание блоков с более чем максимально допустимым количеством сигоп.

Правила менее строгие для скриптов p2sh\p2wsh. Если код операции непосредственно перед CHECKMULTISIGэтим находится в диапазоне [OP_1, OP_16], то это число считается как sigops для проверки мультиподписи, а все остальное считается как 20. На практике 15 — это максимальное количество открытых ключей, которые вы можете отправить как p2sh-скрипт из-за 520 bytes push limit, но для p2wsh пример 17-of-20 будет выглядеть так:

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