BIP-110: Обмеження неплатіжних даних у блокчейні Bitcoin набирає чинності

“>

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

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

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

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

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

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

Сім обмежень на один рік

Пропозиції щодо покращення Bitcoin існують з 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.

23 блоки

Першим за ініціативу проголосував не пул, а одна людина. 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, готовий застосовувати нові правила.

Foundry ставить питання руба

Замість того, щоб одразу визначитися з позицією щодо 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 — що бездіяльність ризикованіша. Жоден великий пул, біржа чи інвестиційна компанія не підтримали ініціативу відкрито.

Дірку знайшов ChatGPT

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

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

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 — не єдиний, але найпомітніший приклад.

110 заперечень Сейлора

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 публікує патч разом з описом помилки.

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

No votes yet.
Please wait...

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

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