Новый флаг SIGHASH_ANYPREVOUT: как биткоин-сообщество готовится к революции в транзакциях

Это третья часть серии технических статей Cointelegraph Research о биткоин-ковенантах. Предыдущую статью можно прочитать здесь.

Предложенный в BIP 118 флаг SIGHASH_ANYPREVOUT стал логическим развитием концепции SIGHASH_NOINPUT, впервые упомянутой в статье Джозефа Пуна и Таддеуса Драйя о Lightning Network 2015 года, а затем формально представленной Пуном на рассылке bitcoin-dev в феврале 2016-го.

SIGHASH_ANYPREVOUT — это не новый оператор, а обновлённое значение флага SIGHASH, которое предполагается внедрить через софт-форк. Флаг SIGHASH добавляется к подписи и определяет, какие части транзакции подлежат подписанию и проверке в CHECKSIG. Выбор флага осуществляется подписывающим, а не задаётся скриптом PubKey. Из-за технических ограничений софт-форка новая версия флага будет работать только с адресами Taproot.

В биткоине уже существуют стандартные режимы SIGHASH, как показано на Рисунке 1. При SIGHASH_ALL подпись охватывает все входы, выходы и конкретный аутпут, тем самым привязывая авторизацию к конкретному UTXO. Аутпут — это комбинация идентификатора транзакции и индекса выхода, однозначно определяющая потребляемый UTXO. В режиме SIGHASH_NONE подписываются только входы, а выходы остаются свободными. Вариант SIGHASH_SINGLE подписывает все входы, но только тот выход, индекс которого совпадает с индексом входа. Модификатор ANYONECANPAY добавляет гибкости, позволяя подписывать один вход независимо от остальных. Однако ни один из этих режимов не позволяет исключить привязку к аутпуту — именно эту проблему решает SIGHASH_ANYPREVOUT.

BIP-118 описывает два варианта ANYPREVOUT, различающихся по степени исключения данных из подписи, что отражено на Рисунке 2. В режиме SIGHASH_ANYPREVOUT из подписи исключается аутпут, но сохраняется привязка к сумме и скрипту PubKey предыдущего выхода, а также к полю nSequence входа. В режиме SIGHASH_ANYPREVOUTANYSCRIPT исключаются также сумма и скрипт, что полностью снимает привязку к блокирующему скрипту потраченного выхода. Все остальные параметры подписи следуют стандартной конструкции сообщения для Taproot и зависят от базового флага, например SIGHASH_ALL или SIGHASH_SINGLE.

Исключение аутпута из подписи позволяет одной и той же подписи авторизовать трату разных, но совместимых UTXO. Например, заранее подписанная транзакция с флагом ANYPREVOUT | ALL на вывод 0,5 BTC может быть использована повторно, если тот же адрес получит новый UTXO с такой же суммой — даже если закрытый ключ, которым была создана подпись, больше недоступен. Если новый UTXO содержит больше 0,5 BTC, излишек достанется майнерам, если в оригинальной транзакции не был предусмотрен выход для сдачи. Это свойство «перепривязки» делает ANYPREVOUT особенно ценным для протоколов второго уровня, где одна и та же заранее подписанная транзакция должна работать с несколькими возможными UTXO на цепочке без необходимости в новых подписях.

Для приложений, напоминающих ковенанты, наиболее востребованы варианты ANYPREVOUT с сохранением привязки к скрипту PubKey, так как они позволяют переиспользовать подписи для совместимых UTXO, сохраняя контроль над блокирующим скриптом. Режим ANYPREVOUTANYSCRIPT полностью снимает эту привязку и менее подходит для ковенант-подобных сценариев.

Как и OP_CTV, SIGHASH_ANYPREVOUT расширяет возможности предварительно подписанных транзакций, но сам по себе не обеспечивает рекурсивных ковенантов или интроспекции транзакций. Вместо этого он ослабляет жёсткую связку между подписью и конкретным UTXO, позволяя использовать одну подпись для разных совместимых выходов.

Исследователи также отмечают, что исключение привязки к аутпуту открывает возможности для «восстановления ключей»: из фиксированной подписи и сообщения можно вывести публичный ключ таким образом, что соответствующий приватный ключ окажется недоступным, делая UTXO недоступным для траты через ключевой путь и заставляя использовать скриптовый путь. Это избавляет от необходимости в временных ключах, которые обычно требуются для блокировки ключевого пути в конструкциях, где расход возможен только через скрипт. Это наблюдение приводится в работе «Bitcoin Covenants: Three Ways to Control the Future» (Якоб Свамбо и др., 2020), хотя пока остаётся теоретической конструкцией и не включено в BIP-118.

Основной риск SIGHASH_ANYPREVOUT — возможность повторного использования подписи. Поскольку подпись не привязана к конкретному аутпуту, она может быть использована для траты другого UTXO, если он соответствует оставшимся обязательным параметрам. Риск усиливается в определённых конфигурациях: при использовании ANYPREVOUT | SINGLE с возможностью перераспределения сумм выходов; если существует другой UTXO с тем же скриптом PubKey и суммой (для ANYPREVOUT); если тот же публичный ключ используется в совместимом скрипте (для ANYPREVOUTANYSCRIPT); или если майнер может влиять на порядок транзакций для эксплуатации уязвимости. Однако все эти сценарии требуют либо злонамеренного использования, либо ошибок в проектировании протокола со стороны пользователя или разработчика.

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