Правила стандартизации, связанные с BIP 16 (P2SH)

Я могу прочитать в вики BIP0016 спецификацию P2SH.

Транзакции, которые компенсируют эти минусы pay-to-script, считаются стандартными только в том случае, если сериализованный скрипт, также называемый redeemScript, сам по себе является одним из других стандартных типов транзакций.

Правила проверки этих недостатков при ретрансляции транзакций или рассмотрении их для включения в новый блок следующие:

Проверка завершается ошибкой, если в scriptSig есть какие-либо операции, кроме операций "push data". Выполняется обычная проверка: создается начальный стек из подписей и {сериализованного сценария}, вычисляется хэш сценария, и проверка немедленно завершается неудачей, если он не совпадает с хэшем в точке выхода. {сериализованный скрипт} извлекается из исходного стека, и транзакция снова проверяется с использованием извлеченного стека и десериализованного скрипта в качестве scriptPubKey. Правила проверки этих недостатков при ретрансляции транзакций или рассмотрении их для включения в новый блок следующие:

Проверка завершается ошибкой, если в scriptSig есть какие-либо операции, кроме операций "push data". Выполняется обычная проверка: создается начальный стек из подписей и {сериализованного сценария}, вычисляется хэш сценария, и проверка немедленно завершается неудачей, если он не совпадает с хэшем в точке выхода. {сериализованный скрипт} извлекается из исходного стека, и транзакция снова проверяется с использованием извлеченного стека и десериализованного скрипта в качестве scriptPubKey. ...

  • OP_CHECKSIG и OP_CHECKSIGVERIFY считаются за 1 операцию подписи независимо от того, оцениваются они или нет.
  • OP_CHECKMULTISIG и OP_CHECKMULTISIGVERIFY, непосредственно предшествующие операциям с OP_1 по OP_16, считаются операцией подписи от 1 до 16, независимо от того, оцениваются они или нет.
  • Все остальные OP_CHECKMULTISIG и OP_CHECKMULTISIGVERIFY учитываются как 20 операций подписи.

Но в книге Антонопулоса я могу прочитать

До версии 0.9.2 клиента Bitcoin Core функция Pay-to-Script-Hash была ограничена стандартными типами сценариев транзакций биткойнов с помощью функции isStandard(). Это означает, что сценарий выкупа, представленный в транзакции расходов, может быть только одного из стандартных типов: P2PK, P2PKH или мультиподпись, за исключением RETURN и самого P2SH. Начиная с версии 0.9.2 клиента Bitcoin Core транзакции P2SH могут содержать любой допустимый сценарий, что делает стандарт P2SH более гибким и позволяет экспериментировать со многими новыми и сложными типами транзакций.

Теперь я использую 0.19.0, и я могу создать собственный скрипт и полагаться на него в своей среде regtest. вопрос такой: Может BIP0016 устарел? И если да, то где посмотреть, какой BIP устарел?

Ответы (1)

Как правило, изменения правил политики не указываются в BIP. В любом случае они зависят от индивидуальных клиентов.

BIP16 не устарел, хотя его описание правил стандартизации в Bitcoin Core уже устарело. Однако его правила консенсуса (то есть то, что действительно в блоке, а не то, что будет передано в виде отдельных транзакций) не изменились с момента его активации в 2012 году — все остальное было бы хардфорком.

Что касается политики в Bitcoin Core, то в версии 0.10.0 (2014 г.) смягчены стандарты для расходов P2SH, что позволяет любому сценарию использовать до 15 проверок подписи. Несколько позже были внесены изменения в стандартизацию (в том числе каждый софтфорк, затронутый скриптами (CLTV, CSV, Segwit), сопровождался созданием соответствующих стандартов расходов), но не столь фундаментальные.

Сегодня (Bitcoin Core v0.19.0) правила стандартизации расходов P2SH включают:

  • Максимальный размер scriptSig составляет 1650 байт, включая redeemScript (не применяется в тестовой сети)
  • Максимум 15 проверок подписи в скрипте (не применяется в тестовой сети)
  • Нет кодов операций, предназначенных для будущих обновлений (NOP3-NOP10) [препятствовать обновлению правила nops]
  • Никаких подписей, не закодированных с помощью DER, или гибридных открытых ключей [строгое правило]
  • Нет подписей со значениями s в верхней половине диапазона [правило низкого s]
  • Дополнительный аргумент, извлекаемый OP_CHECKMULTISIG(VERIFY), должен быть в точности пустым массивом байтов (как выдвигается OP_0) [нулевое фиктивное правило]
  • Все push-уведомления должны использовать кодировку минимального размера (OP_i вместо прямых push-уведомлений, где это возможно, без OP_PUSHDATAi, когда это не требуется), целые числа не могут иметь ненужное заполнение нулями [правило минимальных данных]
  • Выполнение должно заканчиваться ровно одним ненулевым элементом в стеке [правило cleanstack]
  • Неудачные операции Checksig должны быть переданы с пустой подписью [правило nullfail]
  • OP_CODESEPARATOR нельзя использовать (даже в невыполненной ветке).
  • Подписи, которые проверены, не могут появляться в scriptPubKey (они должны исходить из scriptSig) [правило const scriptcode]
  • На уровне транзакции: нет версии tx выше 2, и вся tx не может превышать 400 000 единиц веса (100 000 байт, если нет входных данных segwit).
Спасибо. Согласно ответу MCCCS, я не могу воспроизвести правила в regtest и testnet? Я не использую acceptnonstdtxnв своей конф.
Regtest идентичен основной сети для всего, что здесь перечислено. Testnet немного отличается (у него нет максимального размера scriptsig или правила проверки подписи max 15, но все остальные перечисленные правила по-прежнему применяются).
Еще раз спасибо за ваше время! В целом регтест близок к мейннету, тестнет немного отличается
Извините, я обновил свой комментарий, вы можете проверить, можете ли вы?
Да вроде правильно.
Правила стандартизации, связанные с BIP 16 (P2SH)
СпросиСетьПолитика конфиденциальности1y, 0v