OP_CHECKMULTISIG

Байт 0xae сделал возможным совместное хранение: опкод снимает со стека количество ключей, столько публичных ключей, количество требуемых подписей, столько подписей и затем еще один лишний элемент. Консенсус допускает до 20 ключей в одном вызове. Именно поэтому компания может требовать, чтобы вывод средств одобрили трое из пяти ответственных лиц, и никто из них не мог действовать в одиночку.

Как это работает

Проверка представляет собой один проход по двум спискам, а не поиск. Опкод перебирает подписи по порядку и пробует каждую с последовательными публичными ключами, поэтому подписи должны идти в том же относительном порядке, что и ключи, которым они принадлежат. Если предъявить действительную схему 2-из-3 с двумя переставленными подписями, скрипт завершится ошибкой, и это обычная причина путаницы, когда люди вручную собирают расходы с мультиподписью.

В стеке всегда остается на один элемент меньше, и так было с самого начала. В исходной реализации снимался лишний элемент, который никогда не использовался, и это ошибка, которую нельзя было убрать, не сломав все существующие монеты. Подписанты научились сначала помещать в стек одноразовый элемент, а BIP-147 устранил возникшую из-за этого изменяемость, потребовав, чтобы этот элемент был пустым, начиная с блока 481 824.

Именно в учете затрат это и проявляется. Простой вызов тарифицируется как 20 операций с подписью независимо от того, сколько ключей в нем на самом деле, если только непосредственно перед ним не стоит опкод малого числа, и в этом случае тарифицируется это число. Блок ограничен 80 000 единицами стоимости операций с подписью, а политика ретрансляции допускает не более 15 из них в одном входе pay-to-script-hash. Именно это число из политики, а не собственный лимит опкода в 20, является причиной того, что адреса скриптов ограничены пятнадцатью соподписантами.

Tapscript полностью его упразднил. BIP-342 сделал так, что опкод и его вариант проверки сразу завершаются ошибкой внутри листа Taproot, потому что проверка пакета подписей Schnorr по списку за одну операцию сводит на нет пакетную проверку, ради которой Schnorr и нужен.

Где это встречается

Выход 2-из-2, который финансирует каждый канал Lightning, использует OP_CHECKMULTISIG, и уже одно это ставит опкод в значительную долю скриптовых расходов сети. Корпоративные казначейства, схемы эскроу на старых одноранговых площадках и холодное хранение на биржах, построенное до Taproot, тоже его используют, обычно как 2-из-3 внутри хеша скрипта.

Простые вызовы, где ключи находятся прямо в выходе без хеша перед ними, являются стандартными для ретрансляции при числе ключей до трех и почти никогда не применяются, потому что отправитель платит за каждый ключ, а вся схема публична еще до того, как сдвинется хоть одна монета. В 2014 году этот формат ненадолго стал способом хранить файлы в блокчейне, и отчасти поэтому споры о хранении данных снова возникают всякий раз, когда кто-либо трогает политику ретрансляции.

Если вы настраиваете совместное хранение сейчас, ваш кошелек, скорее всего, создаст схему Taproot со счетной альтернативой или скрипт P2WSH, если совместимость важнее комиссий.

OP_CHECKMULTISIG vs мультиподпись P2SH

OP_CHECKMULTISIG является инструкцией, а мультиподпись P2SH представляет собой способ ее упаковки. Опкод определяет, как проверяется кворум; упаковка определяет, что кворум скрыт за хешем и раскрывается в момент расхода. Одна и та же инструкция может находиться в простом выходе с открытыми ключами, в скрипте погашения за адресом, начинающимся с 3, или в скрипте свидетеля за адресом bc1q, и эти три случая сильно различаются по стоимости и приватности, хотя выполняют одинаковую логику проверки. Чего сделать нельзя, так это использовать инструкцию в листе Taproot, и поэтому современные кворумы строятся на совершенно другом опкоде.