Обмеження OP_Return у Bitcoin: Розробники прагнуть змінити статус-кво зберігання даних

Розробники Bitcoin продовжують боротьбу з «довільним» зберіганням даних. Виснажені після років неефективних спроб запобігти не фінансовому («довільному») зберіганню на блокчейні Bitcoin, розробники просять підтримуючих Bitcoin Core затягнути зміну коду в продукцію, яка видалить обмеження на розмір даних.

Визнаючи двохрічні невдалі спроби обмежити довільне зберігання даних, яке деякі вважають спамом,Пітер Тодд створив запит на витягування (PR) номер 32359, що знімає довільні обмеження на виходи datacarrier через операційний код Bitcoin «OP_Return».

Якщо підтримуючі Core затягнуть зміну в продукцію через основний репозиторій, оператори вузлів Bitcoin, такі як майнери, зможуть публікувати більше байтів даних через виходи OP_Return.

Згідно з формалізацією пропозиціїАнтуана Пуансо з Chaincode Labs, для будь-яких розробників, які вважають 83-байтне обмеження на scriptPubKey OP_Return безглуздим, слід протестувати зміни коду і розглянути, чи погоджуються вони з його зняттям.

Спам обхідні рішення протягом багатьох років

Хоча спроба зменшити використання даних datacarrier була помірно ефективною, багато розробників зазначають, що люди все ще можуть зберігати медіа, спам і інші довільні дані через не OP_Return місця, такі як scriptsigs і незатрачені виходи.

Більше того, деякі користувачі просто обходили 83-байтне обмеження scriptPubKey, приватно транслюючи транзакції в мемпули майнерів, такі якMARA Slipstream, або неосновні вузли, такі якLibre Relay, оператори яких навіть не турбувалися про дотримання цього обмеження.

Пуансо навів як приклад зберігання даних на незатрачених виходах Taproot інше з багатьох обхідних шляхів для зберігання довільних даних на блокчейні Bitcoin.

Читати далі:

• Bitcoin ordinals pump and dump using stolen images and copyright

Реакції

В цілому, розробники опублікували змішані реакції на поштовому списку Bitcoin Core. Деякі розробники співчували неефективності обмеження OP_Return, коли альтернативні варіанти зберігання даних були у великій кількості.

З іншого боку,Люк Дашджер, рішучий критик довільного зберігання даних OP_Return та його використання — такі як Inscriptions і Ordinals — розкритикував ідею як «повну божевільність». Інші підтримали його, проголосувавши за це та написавши схвальні коментарі.

«Помилки мають бути виправлені, а не порушення обійняті», — вигукнув він у своєму типовому стилі. Являючись запеклим захисником обмеженого блочного простору Bitcoin для фінансових цілей, він відзначив більше двох років «атак» від довільних даних «спамерів», стверджуючи, що «шкода, яку вони вже завдали, має бути більш ніж достатньою для доведення, що невтручання не є життєздатним варіантом. Чи є я єдиним, хто залишився в цьому списку, хто насправді піклується про виживання Bitcoin?»

Багато людей погодилися з ним. Інші вважали обмеження безглуздим.

Нові огляди від розробників надходили щогодини через нитку поштового списку та GitHub.

Деякі проголосували за це простим «концепція ACK», підтримуючи термін для «концепція визнана», в той час як не дійшли до повного технічного тесту. Інші залишили «концепція NACK» в знак несприйняття її концептуальних переваг.