Стандартность и политика

Любопытство

1. Почему иногда действительная транзакция отклоняется кошельком до того, как она вообще достигнет майнера?
2. Что произойдёт, если контрагент использует другое ПО, чем вы, но оба варианта «правильные»?
3. Как недопущение неиспользуемых опкодов к ретрансляции может защитить будущие обновления?

Исследование

1. Правила консенсуса определяют действительность: они задают, что может появиться в блоке и быть принято каждой нодой. Стандартность — это отдельная, локальная политика, определяющая, какие транзакции конкретная нода ретранслирует своим пирам и хранит в своём мемпуле. Транзакция может быть полностью действительной по консенсусу, но нестандартной согласно политике ретрансляции по умолчанию. Когда пользователь транслирует такую транзакцию, его собственная нода может сразу её отбросить, хотя майнеры технически могли бы включить её в блок.
2. Стандартные типы выходов строго ограничены, чтобы защитить ноды от атак типа «отказ в обслуживании» и исчерпания ресурсов. К ним относятся P2PKH, P2SH, P2WPKH, P2WSH, P2TR, небольшие «голые» мультиподписные скрипты (до трёх ключей) и выходы данных OP_RETURN определённого размера. Скрипты, использующие зарезервированные или неизвестные опкоды либо превышающие лимиты размера, по умолчанию не ретранслируются. Такая фильтрация сохраняет мемпул управляемым и не даёт злоумышленникам засорять сеть сложным, вычислительно затратным мусором.
3. Политика не статична: она меняется от реализации к реализации ноды. В 2025 году разработчики Bitcoin Core решили ослабить ограничение по умолчанию на размер выходов данных OP_RETURN. Это изменение вызвало споры среди операторов нод: некоторые выступили против расширения и перешли на альтернативное ПО, например Bitcoin Knots, чтобы сохранить прежние, более строгие лимиты. Это расхождение показывает, что стандартность — локальная настройка: две ноды с разными версиями или форками могут ретранслировать разные подмножества действительных транзакций, не нарушая консенсуса.
4. Нестандартная, но действительная транзакция всё равно может быть подтверждена, если полностью минует обычную сеть ретрансляции. Майнеры предлагали сервисы прямой отправки, позволяющие пользователям отправлять транзакции прямо в их блоки независимо от политики нод. Если кошелёк полагается на отклонение нестандартных транзакций ради безопасности — исходя из того, что подозрительный скрипт никогда не распространится, — он рискует: контрагент с прямым доступом к майнеру может добиться подтверждения такой транзакции. Это создаёт расхождение в поведении, а не в истине, и может привести к неожиданному движению средств или их потере.
5. Стандартность служит предохранительным клапаном для будущих обновлений через софт-форк. Применяя более строгие правила уже сейчас — например, считая зарезервированные для обновлений опкоды NOP нестандартными при ретрансляции, — протокол обеспечивает плавный переход, когда обновление ужесточает правила консенсуса. Поскольку транзакции с зарезервированными опкодами по умолчанию не ретранслируются и не включаются майнерами в блоки, к моменту, когда софт-форк придаёт этим опкодам значение, таких транзакций почти или совсем нет, поэтому новые правила не делают недействительным ничего, на что люди полагались, а не обновившиеся майнеры вряд ли добудут блок, который новые правила отклонят.
6. Прочитайте проверки политики сами: в исходном коде Bitcoin Core файл policy/policy.cpp содержит IsStandard и IsStandardTx, где перечислены допустимые типы выходов и лимиты размера; серия Bitcoin Optech «Waiting for confirmation» объясняет их логику. Сравните их с правилами консенсуса в коде валидации и обратите внимание, насколько у́же правила ретрансляции.

Ключевые факты

Упражнение девять, шесть, три, один

Проверка фактов

Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)