BIP 110

Представьте двух операторов узлов, получивших один блок. Один принимает его по прежним правилам, другой отвергает из-за нового ограничения. Именно на таком уровне действовал BIP 110: он менял бы действительность блоков, а не только желание узла передать транзакцию или оставить её в mempool, местной очереди неподтверждённых платежей. При проверке 2026-10-23 спецификация версии 1.0.1 имела статус Closed, то есть закрыта. Номер BIP или опубликованная программа не подтверждают принятие сетью. Реестр хранит документ и его историю, но не переключает удалённо правила отдельных узлов. [1] [2]

У каждого нового выхода есть scriptPubKey — скрипт с условиями будущего расходования. Проект разрешал максимум 34 байта или 83 байта, если скрипт начинается с OP_RETURN, инструкции, делающей выход доказуемо нерасходуемым. Считается весь скрипт. Другой предел, 256 байт, относился к отдельным данным OP_PUSHDATA* и аргументам в witness, сопроводительных данных для проверки расходования. Исключение — помещение redeemScript, раскрытого скрипта условий, в scriptSig по BIP16. Сами witness scripts и Tapleaf scripts не являются такими аргументами, но их инструкции помещения данных остаются ограниченными. Это пределы отдельных частей, а не общей длины транзакции или всего witness. [1]

Ограничения затрагивали и Taproot, способ выражения условий расходования. Запрещалось расходовать неопределённые версии witness или Tapleaf, но не создавать такие выходы. Запрещались annex, дополнительное поле, и control block больше 257 байт — слишком длинное доказательство принадлежности скрипта к зафиксированной структуре. Tapscript не мог бы содержать OP_SUCCESS* даже в неисполняемом коде или выполнять OP_IF и OP_NOTIF независимо от результата условия. Для технического сравнения определены форматы P2WPKH, P2WSH, P2TR с версией Tapleaf 0xc0 и P2A с программой 0x4e73, последний только с пустым стеком witness. Это точные названия форматов, а не поля, которые обычный пользователь должен заполнять в кошельке. [1]

UTXO — ещё не потраченный выход: конкретная сумма с условиями использования. Проект освобождает от новых правил входы, расходующие UTXO, подтверждённые до активации. Но новые выходы той же транзакции не получают такой свободы. Заранее подготовленная подпись также не защищает выход, который создаётся только в активный период. Для некоторых предварительно подписанных конструкций Taproot спецификация допускает заморозку или потерю средств, если ограничения делают задуманные пути недействительными и доступной альтернативы нет. Это касается и возможных последствий для Miniscript, инструмента построения условий расходования, и BitVM, конструкций для проверки вычислений. Поэтому нельзя обещать, что затронуты будут только неденежные данные. [1] [3]

Майнер может отметить поддержку в блоке: здесь используется бит 4 и порог 1109 из 2016 блоков, примерно 55 процентов. Но предложение не ограничивалось добровольным сигналом. Если порог не достигнут раньше, сигнализация требовалась на высотах 961632–963647, затем LOCKED_IN с 963648 и ACTIVE с 965664, если соответствующая цепь дойдёт до этих высот. Высота — позиция блока в цепи. LOCKED_IN фиксирует переход, ACTIVE означает фактическое применение ограничений данных. Клиент отвергал бы блоки без сигнала уже в обязательный период, поэтому узлы могли разойтись до запуска самих лимитов. Они должны были действовать 52416 блоков после реальной активации, затем перейти в EXPIRED и прекратить действие; это не точно отмеренный календарный год. [1] [4]

Сторонники хотели снизить расходы на узлы, давление на набор UTXO и объём нежелательного содержимого, отдав приоритет платежам. Это объясняет намерение, но не доказывает результат. Критики указывали на последствия для полезных скриптов, будущих расширений и риск раскола сети. Данные также можно разделить на мелкие части: в начальном обсуждении Peter Todd показал транзакцию, содержащую таким способом весь тогдашний текст предложения. Даже спецификация не обещает полностью устранить стеганографию, то есть сокрытие информации внутри других данных. Удорожание хранения и полное предотвращение хранения — разные результаты. Аналогично опасение юридической ответственности за содержимое само по себе не устанавливает конкретной правовой обязанности. [1] [3]

Запись PR 2247 описывает разделение 2026-08-08 на высоте 961632. Основная цепь содержала блок без требуемого сигнала, а OCEAN добыл сигнализирующую альтернативу. В сообщении от 2026-08-09 Murch указал, что меньшая ветвь получила всего 2 блока и остановилась, пока основная продвинулась более чем на 100 блоков. Такой отчёт нужно читать вместе с датой и автором: это не независимое воспроизведение blockchain для данной статьи и не описание нынешнего состояния меньшей ветви. Он также показывает, почему разделение из-за сигнализации не равнозначно достижению ACTIVE и включению самих ограничений данных. [5] [6]

Документ прошёл через Complete, завершённую спецификацию, и в итоге получил Closed. PR 2245 о закрытии был принят 2026-08-10; журнал изменений спецификации указывает 2026-08-09. Даты относятся к разным записям, а не к ещё одной активации. Выпуск клиента v0.4.1 описывает EXPIRED и vbrequired, поле шаблона блока с обязательным сигнальным битом. Существование этого клиента не означает принятия в Bitcoin Core. Есть также test vectors, примеры транзакций с ожидаемыми результатами, и функциональные тесты. Статья их не запускает и не проверяет текущую меньшую цепь. Она объясняет предложение и его документированную историю, не выдавая исторический документ за нынешние общие правила сети. [7] [1] [4]