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]