BIP-110: Як обмеження неплатіжних даних у блокчейні Bitcoin змінює правила гри

У криптоспільноті набирає обертів дискусія навколо BIP-110 — пропозиції тимчасово, на рік, обмежити запис сторонніх даних у блокчейн Bitcoin. Йдеться про зображення, тексти та інший контент, що не стосується платіжних транзакцій.

Прихильники ініціативи представляють її як боротьбу зі спамом. Згідно з даними BIP-110 Monitor, за вісім місяців сигналізування підтримки не перевищило півтора відсотка нових блоків.

Здавалося б, питання вирішено. Однак автори прописали активацію так, що позиція майнерів на неї не впливає: на початку серпня обмеження все ж запрацюють, хоч і не в усій мережі.

Далі — цікавіше. Проти софтфорку виступили Майкл Сейлор, Адам Бек та глава JAN3 Самсон Моу — люди, яких важко запідозрити у симпатіях до спамерів.

Опоненти BIP-110 висувають одразу кілька аргументів. Деякі вказують на потенційну помилку в механізмі активації, яка може призвести до розбіжності ланцюгів. Інші демонструють, що запропоновані обмеження можна обійти: словацький розробник записав у блокчейн зображення, попри заборони, зафіксовані в документі.

Розбираємося, що насправді не влаштувало індустрію.

Пропозиції щодо покращення Bitcoin (Bitcoin Improvement Proposals, BIP) існують з 2011 року. Їхнє завдання — формалізувати процедуру внесення значних змін до коду першої криптовалюти.

Чернетку з офіційною назвою Reduced Data Temporary Softfork розробник під псевдонімом Dathon Ohm подав до репозиторію 24 жовтня 2025 року. Півтора місяця документ обговорювали під кодом BIP-444, а 3 грудня йому було присвоєно номер 110.

25 червня 2026 року версія 1.0.0 отримала статус “Complete”. Згідно з правилами BIP-3, це означає, що автори завершили роботу і рекомендують прийняття. Однак такий статус не передбачає згоди спільноти — про це репозиторій попереджає окремим рядком.

Софтфорк вводить сім обмежень терміном приблизно на один рік:

  • нові адреси-одержувачі (scriptPubKey) — не довше 34 байт, з винятком 83 байт для OP_RETURN;
  • окремі порції даних та елементи witness («свідка» — частини транзакції з підписами) — до 256 байт;
  • заборона антекс Taproot — службового поля необмеженого розміру, зарезервованого під майбутні розширення і жодного разу не задіяного;
  • відмова обробляти Tapscript з опкодами OP_SUCCESSx, залишеними як запас для наступних софтфорків;
  • заборона витрачати виходи з невизначеними версіями witness та Tapleaf — створювати такі виходи все ще дозволено;
  • control block — службова частина скрипта з доказом шляху — не більше 257 байт, що обмежує вкладеність сімома рівнями;
  • заборона виконуваних OP_IF та OP_NOTIF всередині Tapscript.

Сім обмежень. Джерело: специфікації BIP-110.

Монети на адресах, створених до введення нових норм, не підпадають під обмеження — витратити їх можна буде як раніше. У суперечках навколо BIP-110 цю примітку найчастіше оминають, хоча саме вона знімає головний страх: що документ конфіскує вже наявні кошти.

Не допомагає це правило лише в одному випадку. Деякі схеми влаштовані так, що транзакцію готують заздалегідь, а відправляють через місяці або роки — наприклад, мультисиг-конструкції з відкладеним терміном виконання. Якщо така підготовка зроблена за старими правилами, а момент відправки випадає на рік дії обмежень, кошти можуть стати недоступними. Власникам подібних схем рекомендують перевести монети завчасно.

Щоб зрозуміти природу конфлікту, достатньо розібратися з одним ключовим опкодом.

OP_RETURN з’явився в Bitcoin Core 0.9.0 у 2014 році як безпечніша альтернатива способу, яким спільнота вже записувала повідомлення в блокчейн.

До появи опкоду залишити повідомлення в ланцюзі можна було єдиним шляхом — відправити монети на адресу, від якої ні у кого немає ключа. Монети згорали, зате текст зберігався.

Проблема полягала не в втрачених біткоїнах. Кожна така операція залишала запис у наборі невитрачених виходів — тому самому, який зобов’язана тримати напоготові вся мережа. OP_RETURN дозволив позначати дані як свідомо непридатні для витрати: зберігати їх не потрібно.

Спочатку ліміт становив 40 байт, у 2015 році його підвищили до 80, у 2016 — до 83. Планку тримали низькою навмисно: цього вистачало на хеш, але не на сам документ.

У жовтні 2025 року розробники Bitcoin Core випустили реліз v30, де «стеля» зросла з 80 байт до 100 000. Саме тоді частина спільноти пішла на альтернативний клієнт Bitcoin Knots — цей розкол і породив нинішні розбіжності.

Більшість суперечок пов’язана не з самими обмеженнями, а зі способом їх активації.

BIP-110 використовує перероблений BIP 9 — стандартну процедуру, за якою майнери повідомляють про готовність до оновлення, виставляючи певний біт у заголовку видобутого блоку. Змін три, і всі вони знижують залежність активації від згоди майнерів.

Поріг активації. У BIP 9 софтфорк вважається схваленим, якщо за один період перерахунку складності підтримку сигналізують 95% блоків. У BIP-110 поріг знижено до 55% — 1109 з 2016 блоків.

Механізм активації. На першому етапі майнери можуть сигналізувати підтримку добровільно. Потім починається примусова фаза: вузли, що оновилися до BIP-110, перестають приймати блоки без встановленого біта 4.

Якщо вузли перейдуть на новий ланцюг, остаточна активація BIP-110 очікується не пізніше блоку #963 648, а самі обмеження набудуть чинності приблизно до блоку #965 664.

Сценарій невдалої активації. Зараз, якщо пропозиція не набирає необхідної підтримки за відведений термін, вона отримує статус FAILED і вважається відхиленою.

У BIP-110 такого сценарію немає: навіть після закінчення добровільної фази оновлення може перейти до примусової активації, якщо його підтримають оператори вузлів.

Сейлор у пункті 86 свого есе пише, що автори BIP-110 скасували «аварійний вихід»: пропозиція, що не зібрала підтримки, повинна припиняти дію сама, без примусової координації.

Цю логіку автори BIP-110 запозичили у UASF — софтфорку, що активується користувачами. У 2017 році невелика частина операторів вузлів оголосила, що відхилятиме блоки без сигналу підтримки SegWit. Зрештою майнери почали масово сигналізувати оновлення, і софтфорк був активований.

Той епізод і сьогодні слугує головним доводом обох сторін у суперечці про BIP-110. Одні бачать у ньому доказ того, що економічна більшість здатна нав’язати майнерам свою волю. Інші — попередження: якщо інструмент спрацював один раз, ним може скористатися і меншість — заради значно більш спірної мети.

Точні дати цього розкладу назвати не можна: майнери добувають блоки в середньому раз на десять хвилин, але інтервал плаває, тому будь-яке число тут — розрахункове. Одні джерела відносять початок примусової фази до 9 серпня, інші — до середини місяця. Розбіжність на тиждень тут — звичайна справа.

Таймер до початку примусової фази. Джерело: BIP-110 Monitor.

Першим за ініціативу проголосував не пул, а одна людина. 1 березня 2026 року соло-майнер під ніком Barefoot Mining видобув блок із сигналом підтримки BIP-110 через інфраструктуру пулу Ocean.

Технічно це стало можливим завдяки протоколу DATUM: він дозволяє клієнтам Ocean збирати власний шаблон блоку без узгодження з оператором. Сам Ocean правила BIP-110 не застосовує. Сигнал Barefoot Mining — особиста позиція учасника мережі, а не рішення керівництва пулу.

До середини квітня ситуація майже не змінилася. За період перерахунку складності №467 підтримку BIP-110 сигналізували лише три з 1840 видобутих блоків — усі через Ocean. Foundry, AntPool, F2Pool, ViaBTC, Marathon та Luxor не подали жодного сигналу.

Публічно висловився лише один з великих гравців — співзасновник F2Pool Ван Чунь виступив категорично проти ініціативи.

Максимальна підтримка припала на період №475, що завершився: 23 блоки, або 1,2% від загальної кількості. Однак навіть цей рекорд виявився вкрай далеким від необхідних 1109 блоків (55%). Новий період перерахунку складності, що стартував 27 липня, поки не приніс жодного сигналу підтримки.

Графік з динамікою підтримки нових правил майнерами. Джерело: BIP-110 Monitor.

Якщо дивитися не на кількість блоків, а на розподіл хешрейту, підтримка BIP-110 виявляється ще скромнішою. До кінця червня ініціативу поділяли близько 5 EH/s із загальної потужності мережі в 940 EH/s. Найбільший пул, AntPool, з часткою близько 14%, сигнал так і не подав.

З вузлами ситуація зворотна: тут підтримка куди помітніша. Частка Bitcoin Knots за перші місяці року помітно зросла. Залежно від методики підрахунку, вона оцінюється в діапазоні від 8% до понад 20% усіх публічно доступних вузлів мережі. Ймовірну причину називає розробник Джеймсон Лопп: багато нод піднімають через Tor, майже безкоштовно і в будь-якій кількості, тому сирі цифри легко накрутити.

Голоси хешрейту та голоси вузлів розходяться. Великі пули біт 4 не виставляють — і для них це позиція, а не бездіяльність. Деякі оператори нод тим часом переходять на Bitcoin Knots, готовий застосовувати нові правила.

Замість того, щоб одразу визначитися з позицією щодо BIP-110, Foundry USA вирішив спочатку запитати своїх клієнтів. 21 липня найбільший пул опублікував на сайті розбір аргументів прихильників та противників BIP-110. Наступного дня там же відкрили голосування через email-форму.

Схема майже зумовлює результат. Вага голосу кожного клієнта рахується за середнім хешрейтом за десять днів — з 6 по 15 липня. Мовчання зараховується як «ні». Пул обіцяє змінити сигнал на «так», тільки якщо прихильники наберуть 51% від загальної суми голосів.

Вікно закривається на блоці #961 632 — тій самій висоті, де за розкладом BIP-110 має стартувати примусова сигналізація. Збіг не випадковий: саме до цього моменту пулу потрібно визначитися.

Частка Foundry у хешрейті мережі перевищує 22%. Це найвагоміший публічний жест за вісім місяців спостережень: великий гравець вперше формально запитав клієнтів, а не просто промовчав.

При типовій для таких опитувань явці набрати 51% хешрейту непросто суто арифметично — річ не в ідеології. Мовчазна більшість автоматично посилює табір «проти».

Підсумків Foundry публічно не розкриває — ані явки, ані проміжного рахунку. Дізнатися, до чого схиляються клієнти, вийде тільки за фактом: якщо пул змінить сигнал, це буде помітно в таблиці моніторингу ще до офіційного оголошення.

27 лютого 2026 року словацький програміст Мартін Хабовштяк написав у X: мережа Bitcoin помилково прийняла його «цілісний файл зображення» за транзакцію без OP_RETURN — і тепер файл назавжди залишиться в блокчейні.

Шістнадцятковий код транзакції при розшифруванні перетворюється на файл формату TIFF вагою 66 КБ. На картинці — Люк Деш-молодший, один із головних прихильників BIP-110, що плаче.

Технічно вона обходить усі три вектори, які автори софтфорку називають ключовими: OP_RETURN відсутній, замість Taproot використано SegWit v0, опкод OP_IF не задіяно.

Пізніше Хабовштяк пояснив, що хотів перевірити один з ключових аргументів прихильників BIP-110. На їхню думку, оператор повного вузла може зіткнутися з юридичними ризиками, якщо на його комп’ютері зберігається незаконний контент, записаний у блокчейн. Звідси робиться висновок, що розмір окремих елементів даних слід обмежити настільки, щоб у них не можна було розмістити повноцінний фрагмент незаконного контенту. Цей ланцюжок міркувань програміст назвав абсурдним.

Є деталь, яку легко пропустити. BIP-110 просувають не тільки як боротьбу зі спамом, а й як юридичне прикриття для операторів вузлів. У суперечках про софтфорк цей довід звучить рідше, ніж «спам», — і саме його спростовував експеримент розробника.

Акцію Хабовштяк назвав разовою і код публікувати відмовився — за його словами, щоб не спровокувати «нову хвилю NFT-шіткоїнів» у Bitcoin. Розробник підкреслив, що спам він не любить, але брехню зневажає ще сильніше. Однак ті, хто бажає засмітити мережу, обхідний шлях знайдуть завжди: на його думку, більшість захисних заходів лише породжують нові проблеми.

Згідно з даними TheBitcoinPortal, до початку березня підтримку BIP-110 сигналізували близько 8,8% вузлів.

Жоден із критиків BIP-110 не захищає написи в блокчейні. Претензії до методу, а не до змісту.

Адам Бек висловився першим, ще 15 лютого. За його словами, ініціатива б’є по репутації Bitcoin як засобу заощадження і нагадує «суд Лінча» — спробу проштовхнути зміни без загальної згоди. Спам він назвав подразнюючим фактором, який сам по собі вписується в ліміт розміру блоку і тому мережі не загрожує. На той момент сигнал підтримки подавали близько 7,5% вузлів — майже виключно на Bitcoin Knots.

22 липня спір отримав продовження. Інфраструктурна компанія Start9 запропонувала майнерам «просто перемкнути біт»: за її розрахунками, це обійшлося б приблизно в 0,1% річного виторгу, а відмова загрожувала б розколом ланцюга та втратою платних користувачів.

Бек відповів коротко: «не перемикайте біт, і нічого не станеться», назвавши саму кампанію проявом ідіократії. На звинувачення в «циклічності» міркувань він послався на практику IETF — міжнародної організації, що розробляє стандарти інтернету, — де враховуються лише обґрунтовані технічні заперечення. За його словами, спроб саботажу не може враховувати жоден процес: інакше його розхитає будь-яка скоординована група.

Глава JAN3 Самсон Моу 25 липня описав сценарій «атаки 1%»: орендувати 1% хешрейту мережі та підняти 3000 вузлів. До форку це нічого не коштує — обладнання продовжує майнити Bitcoin як зазвичай. А після оренда обійдеться приблизно в 4,5 BTC на добу, а підтримка вузлів — у $15 000 на місяць. За підрахунками Моу, ціна входу настільки мала, що реагувати на такі сценарії — створювати прецедент для наступних.

Найлаконічніша формула належить аналітику Акселю Адлеру — молодшому. Змінювати консенсус, написав він, варто лише за об’єктивної технічної необхідності — критичної вразливості, ризику інфляції, реальної загрози безпеці. BIP-110 у нинішньому вигляді «зачіпає нейтральність мережі сильніше, ніж того вимагає сама проблема».

Голосів «за» майже не чутно. Єдиний публічний аргумент прозвучав від самої Start9 — що бездіяльність є ризикованішою. Жоден великий пул, біржа чи інвестиційна компанія не підтримали ініціативу відкрито.

Уявіть, що в клубі змінили правила на вході. Охоронець тепер прискіпливо звіряє кожного прибулого за оновленим списком. Тих, хто зайшов десять хвилин тому, за ним ніхто не перевіряв.

Придратися ні до чого: охоронець діє суворо за інструкцією. Але фактично всередині вже сидять люди, яких за нею б не пустили.

18 липня дослідник під ніком Dathon Pwn опублікував розбір саме такої вразливості — тільки не в клубі, а в клієнті активації BIP-110.

Кожен вузол зберігає список блоків, які він уже прийняв, і при перезапуску довіряє цій базі.

BIP-110 додає нові умови перевірки. Правила ці вмикаються лише в момент, коли вузол бачить блок вперше. Уявімо: оператор працював на звичайному клієнті та прийняв його як один із чергових. Потім оновився і включив BIP-110 поверх тієї ж бази. Запис нікуди не подівся: він так і залишився позначеним як легітимний, хоча перевірявся ще за старими правилами.

Автор пояснює це на прикладі. Вузол Аліси працює без BIP-110 і приймає блок B — за старими правилами той абсолютно легітимний. Пізніше Аліса оновлює клієнт, і нові обмеження набувають чинності. Вузол Боба, навпаки, застосовує їх з самого початку. Отримавши той самий блок B, він його відхиляє.

Взаємодія Аліси та Боба з неодномчасно оновленим ПЗ. Джерело: розбір Dathon Pwn.

Обидві ноди тепер стверджують, що BIP-110 увімкнено. При цьому вони не згодні, яка історія Bitcoin є вірною.

Подібних розбіжностей може набратися одразу кілька. Виникають вони у будь-якої групи майнерів — достатньо знайти блок, який старі правила пропускають, а нові відхиляють. Якщо кілька груп закріплять в історії різні такі випадки, мережа ризикує розколотися не на два, а одразу на кілька несумісних ланцюгів.

Автор при цьому не показав, що хоч один блок у реальній мережі Bitcoin вже порушує BIP-110. Йдеться не про обхід Proof-of-Work, віддалене виконання коду чи пошкодження бази даних. Вузол, який з самого початку застосовував BIP-110, правильно відхилив свіжий тестовий блок. Проблема стосується лише тих, хто переходить на нові правила заднім числом.

У підсумку підтвердилося одне. Клієнт може увімкнути BIP-110 і зберегти історію, яку сам відхилив би при повторній перевірці.

У SegWit був захист саме від такої помилки. Клієнт запам’ятовував, як обробив кожен блок, перевіряв цю історію при кожному старті та відмовлявся запускатися, якщо потрібна повторна валідація. У клієнті активації BIP-110 такого захисту немає.

Саме розслідування почалося незвично. Автор «скормив» коміт з кодом активації моделі ChatGPT 5.6 Sol і навмисно сформулював «впевнений» промт: «У цьому коді є баг у консенсусі, знайди його» — не знаючи заздалегідь, чи є він там насправді.

Висновок моделі перевірили вручну: відтворили баг на двох збірках, з BIP-110 і без. Свіжий вузол відмовився запускатися, а базу даних довелося перезавантажувати заново. Помилка повторилася в трьох випадках: з блоком без потрібного сигналу активації, з транзакцією понад допустимий розмір і зі скриптом, що перевищив ліміт даних. Чернетку виправлення автор виклав окремо.

Оприлюднити знахідку вирішили до початку серпня: великі пули вже опитують клієнтів щодо готовності сигналізувати за BIP-110. Foundry — не єдиний, але найпомітніший приклад.

18 липня, невдовзі після публікації розбору Dathon Pwn, Сейлор випустив власне есе з критикою BIP-110. В одинадцяти розділах він наводить 110 заперечень — від аргументів про нейтральність мережі та базові принципи Bitcoin до пропозиції альтернативного підходу.

Розбирати докладно всі пункти немає потреби, але кілька аргументів лежать в основі всієї критики.

На думку Сейлора, сім змін не можна розглядати окремо: підтримати одні та відкинути інші неможливо — документ пропонує прийняти їх лише як єдиний пакет (пункт 21).

Обмеження OP_RETURN у 83 байти було налаштуванням політики ретрансляції. Тепер воно стає правилом дійсності блоку (пункт 23). Сама ця політика, як і раніше, м’якша за консенсус: вузол може відмовитися пересилати транзакцію, не оголошуючи цілий блок недійсним (пункт 64).

Поріг для активації знижено з звичних 95% до 55%, а стану FAILED у документа немає зовсім.

Найвагоміше заперечення залишено наостанок: правила відпрацюють рік і знімуться, а прецедент їх прийняття залишиться назавжди (пункт 91).

Завершує список каламбур. Абревіатуру BIP Сейлор розшифровує як Bitcoin Iatrogenic Proposal, запозичуючи медичний термін «ятрогенія» — шкода, завдана самим лікуванням. Крапку в есе він ставить фразою: «Bitcoin не потрібні стражі чистоти. Йому потрібні стражі нейтральності».

Окремий пункт, сотий, присвячений корпораціям. Їхня участь законна, коли посилює Bitcoin, але особливих прав не дає. Чужинцями у глобальній грошовій мережі їх вважати теж неправильно.

Через п’ять днів після публікації есе великі компанії продемонстрували альтернативну модель участі в екосистемі: фінансувати розвиток Bitcoin, не втручаючись у правила протоколу.

Strategy Сейлора увійшла до числа дев’яти засновників Bitcoin Security Consortium разом з Blockstream, BlackRock, Coinbase, Fidelity Digital Assets, Galaxy, Block, Anchorage Digital та ARK Invest.

Учасники незалежно один від одного пообіцяли виділити 15 мільйонів доларів за три роки — але не в загальний фонд: кожен розпоряджається грошима самостійно. Координує роботу Майк Шмідт з некомерційної Brink, на волонтерських засадах. Перший напрямок — підготовка до можливої епохи квантових обчислень.

Статут консорціуму проводить рівно ту ж межу, про яку писав Сейлор. Організація фінансує розробників, але в сам протокол не втручається і позиції щодо конкретних змін не займає.

Внесок кожного з дев’яти учасників у ці 15 мільйонів доларів не розкривається. Чи входять туди окремо оголошені 5 мільйонів доларів Galaxy на захист від квантових загроз — теж неясно.

На початку серпня вузли з новими правилами почнуть відхиляти блоки без біта 4. Для решти мережі нічого не зміниться — вона продовжить приймати їх як зазвичай. Вийде не розкол, а паралельний ланцюг: менший і за хешрейтом, і за кількістю учасників.

Вісім місяців суперечок не зрушили сигнал підтримки BIP-110 навіть до двох відсотків. Для пересічного власника монет за цей час не змінилося абсолютно нічого: комісії, перекази та баланси живуть своїм життям, поки в соцмережах триває війна за майбутнє Bitcoin.

Так влаштована управління в цій мережі. Рішення не приймають голосуванням — ані майнери, ані розробники, ані компанії з мільярдами на балансі. Кожен учасник обирає, яку версію програми запустити, — це єдиний важіль впливу, який він має.

Foundry запитує клієнтів, бо вирішувати за них не може. Хабовштяк доводить правоту транзакцією, а не постом. Дослідник під ніком Dathon Pwn публікує патч разом з описом помилки.

Серпнева розвилка покаже, скільки учасників мережі готові застосовувати нові правила. Не більше і не менше.

Джерело новини: cryptocurrency.tech

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *