BIP 110 се провали след два блока и не промени правилата на Биткойн

Опитът за активиране на BIP 110 приключи с отделяне на слабо поддържана верига, която произведе само два блока — 961 632 и 961 633 — и след това спря. Основният блокчейн на Биткойн продължи да натрупва значително повече изчислителна работа, без да прилага предложените ограничения върху трансакциите.

На 9 август 2026 г. официалният сайт на BIP 110 потвърди спирането и публикува инструкции към операторите на заседнали възли да се върнат към версия на Bitcoin Knots отпреди RDTS. Седемте нови правила не достигнаха състояние `ACTIVE` и не станаха част от консенсуса на Биткойн.

Затова най-точното определение е, че опитът за активация се провали на практика. Това не е протоколно състояние `FAILED`, защото схемата на BIP 110 изобщо не съдържа такова състояние.

BIP 110 предложи временен софтфорк за ограничаване на данните

BIP 110 е Bitcoin Improvement Proposal, озаглавен Reduced Data Temporary Softfork. На български най-разбираемият превод е „временен софтфорк за ограничаване на данните“, откъдето идва и съкращението RDTS.

Софтфоркът затяга действащите консенсусни правила: част от блоковете и трансакциите, които предишният софтуер приема за валидни, стават невалидни за обновените възли. За разлика от него, хардфоркът въвежда правила, които не са обратно съвместими със старите възли.

Предложението е публикувано под името на псевдонимния разработчик Dathon Ohm. В документа Luke Dashjr е посочен за автор на първоначалната чернова и съветник. В първото съобщение до Bitcoin Development Mailing List Dathon Ohm представя работата като продължение на по-ранно предложение на Luke Dashjr.

Целта беше за приблизително една година да бъдат наложени седем допълнителни консенсусни правила, ограничаващи определени технически способи за записване на произволни данни в трансакциите. След 52 416 активни блока ограниченията трябваше автоматично да отпаднат.

RDTS не можеше да разпознава дали дадени байтове представляват изображение, текст, криптографско доказателство или платежна информация. Правилата забраняваха конкретни структури и размери, а не съдържание според неговия смисъл.

Статусът Complete не означава, че предложението е прието

BIP 110 не е със статус `Deployed`. В официалния BIP документ продължава да е отбелязан като `Complete`.

Според правилата на BIP 3 статусът `Complete` означава, че авторът е приключил планираната работа, смята спецификацията за готова и я препоръчва за приемане. Това не показва, че мрежата я е одобрила или активирала.

`Deployed` се използва при убедителни доказателства, че предложението действително се прилага — например когато критериите за активация на софтфорк са изпълнени или има установена употреба в основната мрежа. BIP 110 не достигна този етап.

Пропускът е важен, защото публикуването на BIP не представлява гласуване. Регистърът съхранява технически предложения и не определя вместо потребителите, миньорите и икономическите участници кои правила са Биткойн.

Предложението премина през няколко съществени редакции

Ранната версия съдържаше механизъм, позволяващ реакция чрез реорганизация на блокчейна. След критики за риск от двойно харчене той беше премахнат. Добавена беше и защитата на вече съществуващите UTXO записи, за да не се блокират средства, заключени преди активацията.

Седемте RDTS правила променяха валидността на трансакциите

Консенсусните RDTS ограничения — седемте допълнителни правила във временния софтфорк за ограничаване на данните — трябваше да се прилагат само след достигане на състояние `ACTIVE`.

• Заключващите скриптове на новите изходи се ограничават до 34 байта.

Всеки Биткойн трансакционен изход съдържа `scriptPubKey`, който определя при какви условия средствата могат да бъдат похарчени. Изключение се допуска за `OP_RETURN`, където общият размер може да достигне 83 байта. Стандартните платежни формати обикновено се побират в тези граници.

• Отделните полета с данни се ограничават до 256 байта.

Ограничението обхваща данните, които скриптът поставя в стека чрез `OP_PUSHDATA`, както и определени елементи в witness секцията. Witness съдържа подписи, скриптове и други данни, с които се доказва правото за изразходване на даден изход. Предвидено е изключение за `redeemScript` при BIP 16.

• Не могат да се харчат изходи с още недефинирани witness или Tapleaf версии.**

Разрешени остават вече определените формати, сред които Witness v0, Taproot и P2A. Създаването на изход с бъдеща, все още неопределена версия остава валидно, но изразходването му би било забранено, докато RDTS е активен.

• Taproot annex става невалиден.

Annex е резервирано поле в Taproot witness структурата, оставено за бъдещи разширения. Понеже няма установена употреба и няма фиксиран размер, BIP 110 предлагаше временно да го забрани.

• Taproot control block се ограничава до 257 байта.

Control block е доказателството, че разкритият скрипт е част от Taproot структурата. Лимитът допуска път с най-много седем хеш нива, което при балансирана структура съответства на приблизително 128 Tapleaf скрипта.

• Tapscript с `OP_SUCCESS*` става невалиден, дори командата да е в неизпълнена част от скрипта.

Opcode е отделна операция в Bitcoin Script. `OP_SUCCESS*` е запазен набор от команди за бъдещи софтфоркове. BIP 110 щеше да забрани самото им присъствие, независимо дали изпълнението достига до тях.

• Изпълнението на `OP_IF` или `OP_NOTIF` в Tapscript става невалидно.**

Това са условни операции, чрез които скриптът избира различен път според подадена стойност. Ограничението се отнася до действително изпълнена команда, независимо дали условието връща истина или неистина.

Правила не премахват математически възможността за записване на данни. Информацията може да бъде разделена на по-малки части или представена чрез други разрешени структури. BIP 110 се опитваше да направи употребата по-скъпа и неудобна, без да твърди, че може да я премахне напълно.

Съществуващите UTXO записи трябваше да останат защитени

UTXO е неизразходван трансакционен изход — конкретно количество BTC, което все още може да бъде похарчено. BIP 110 включваше механизъм, известен като UTXO grandfathering, или запазване на старите правила за вече съществуващите изходи.

Всеки UTXO, създаден преди височината на активация, трябваше да остане освободен от новите ограничения. Височина на активация означава номера на блока, от който възлите започват да прилагат новите правила. Така съществуващите средства можеха да бъдат похарчени по същия начин, както преди софтфорка.

Ограниченията щяха да се прилагат само за UTXO записи, създадени след активацията. След изтичането на 52 416 активни блока всички изходи отново трябваше да бъдат проверявани по предишните правила.

Защитата намаляваше риска, но не покриваше всяка възможна предварително подписана поредица от трансакции. Ако стара договорна конструкция създава нов UTXO след активацията и разчита на забранен скрипт за бъдещото му изразходване, средствата можеха временно да станат недостъпни.

Някои сложни Taproot конструкции можеха да бъдат засегнати

Обикновените плащания не бяха основният технически риск. По-голяма несигурност имаше при редки и сложни Taproot конструкции.

Miniscript е структуриран начин за създаване и анализиране на Bitcoin Script условия. Някои портфейли могат чрез него да създадат Tapleaf — отделен скриптов път в Taproot дървото — който използва `OP_IF` или се намира на повече от седем нива дълбочина.

BitVM конструкциите разчитат на голям брой предварително подготвени скриптове, чрез които спорно изчисление може да бъде проверено в Биткойн. Лимитът върху control block би затруднил по-големи или небалансирани Taproot структури.

Рискът се отнасяше най-вече до нови UTXO записи, създадени след евентуалната активация. Тъй като BIP 110 не достигна `ACTIVE`, тези ограничения останаха само в спецификацията и не засегнаха реалните трансакции в Биткойн.

Конфликтът започна от inscriptions и Bitcoin Core 30

Вписванията, известни като inscriptions, се разпространиха след появата на Ordinals през 2022 г. Те могат да поставят изображения, текст или други данни в Taproot script-path witness.

При този начин на изразходване вместо обикновен подпис по ключовия път се разкрива конкретен скрипт от Taproot структурата и witness данните, необходими за неговото изпълнение. Witness отстъпката при изчисляването на теглото на трансакцията прави този подход по-евтин от поставянето на същия обем в други части на трансакцията.

Спорът се изостри след Bitcoin Core 30.0. Версията увеличи стойността по подразбиране на `-datacarriersize` до 100 000 и позволи повече от един `OP_RETURN` изход в една трансакция.

`OP_RETURN` създава доказуемо неизразходваем изход, предназначен да носи ограничено количество данни, без да остава в активния UTXO набор. Промяната в Core 30 не направи по-големите `OP_RETURN` трансакции консенсусно валидни — те вече бяха валидни. Тя промени кои от тях софтуерът по подразбиране препредава и предлага за включване в блок.

Операторът на възел може да върне предишния общ лимит чрез `-datacarriersize=83`. Core 30 обаче продължава да допуска повече от един `OP_RETURN` изход, стига сборът на пренасяните данни да остане в зададената граница.

Самите inscriptions не зависят основно от `OP_RETURN`. Затова BIP 110 не се ограничаваше до отмяна на промяната в Core 30, а предлагаше правила за Taproot, witness елементи, размери на скриптове и други структури.

Локалната policy и мрежовият консенсус имат различна роля

Policy са местните правила, чрез които един възел решава кои непотвърдени трансакции да приема в mempool-а си, да препредава към други възли или да предлага в блоков шаблон. Те могат да бъдат променяни от оператора и не определят дали вече намерен блок е валиден.

Консенсусът определя валидността на блоковете и трансакциите. Ако блок нарушава консенсусно правило, пълният възел го отхвърля независимо от таксите, миньора или натрупаната работа върху него.

По-строгата политика за препредаване може да затрудни разпространението на inscriptions, но не може да попречи на потребител да изпрати трансакцията директно до миньор. Ако миньорът я включи в блок и тя спазва консенсусните правила, останалите възли трябва да приемат блока.

В позицията си за препредаването на трансакции разработчици на Bitcoin Core обясняват, че местната политика трябва да предвижда кои трансакции вероятно ще бъдат добити. Това подпомага изчисляването на такси, бързото разпространение на блокове и достъпа на по-малки миньори до плащащи такси трансакции.

Според поддръжниците на BIP 110 този подход прави строгите филтри безсилни срещу миньор, който съзнателно ги заобикаля. Затова предложението се опита да превърне конфигурируемата местна политика в общовалидни правила за целия протокол.

Поддръжниците поставиха разходите за възлите над свободата на блоковото пространство

Всеки пълен възел трябва да изтегли и провери данните в блоковете. Възел с включено „pruning“ може впоследствие да изтрие старите блокови файлове от локалния диск, след като ги е валидирал. Архивните възли ги съхраняват неограничено.

UTXO наборът е по-чувствителен. Неизразходваните изходи трябва да останат достъпни, докато не бъдат похарчени, защото възелът ги използва при проверката на нови трансакции. Ненужното му разрастване — UTXO bloat — увеличава изискванията към паметта и бързото дисково пространство и не може да бъде решено чрез обикновено изтриване на старите блокове.

Миньорът получава еднократна такса за включването на дадена трансакция. Разходът по изтеглянето, проверката и евентуалното дългосрочно съхранение се разпределя между всички възли. От тази гледна точка пазарът на такси не определя напълно цената на натоварването, което потребителят прехвърля върху останалата мрежа.

Поддръжниците на BIP 110 виждаха ограниченията като защита на достъпната самостоятелна валидация и на Биткойн като парична система, а не като общо хранилище за файлове.

Критиците отхвърлиха определянето на допустима употреба чрез консенсуса

Критиката срещу BIP 110 не изисква защита на Ordinals или твърдение, че всяко inscription има икономическа стойност. Основният аргумент е, че консенсусът не може да разпознава намерението зад еднакви байтове.

Една и съща техническа структура може да представлява изображение, криптографско доказателство, резервирана възможност за бъдещ софтфорк или част от платежен протокол. BIP 110 забраняваше структури и размери, а не само трансакции, които някой е определил като „спам“.

Майкъл Сейлър изложи подобна позиция в публичната критика на Strategy. Според нея спорната употреба на валидни, плащащи такси трансакции не оправдава рискована промяна на консенсуса.

Показателен е и експериментът на Peter Todd в Bitcoin Development Mailing List. Той публикува трансакция, която съдържа пълния тогавашен текст на предложението, но остава съвместима с ограниченията му. Данните са разделени на множество малки части вместо на едно голямо поле.

BIP 110 признава тази граница. Предложението не обещаваше да премахне всички произволни данни, а да ги направи по-фрагментирани, скъпи и неудобни за обработка.

Схемата за активация използваше пет последователни състояния

BIP 110 използваше променена версия на BIP 9 — механизъм, който следи сигнализирането на миньорите през периоди от по 2 016 блока.

Предвидените състояния бяха:

• `DEFINED` — начално състояние преди старта на сигнализирането;
  
  
• `STARTED` — миньорите могат доброволно да поставят bit 4 в блока;
  
  
• `LOCKED_IN` — активацията е заключена и не може да бъде отменена чрез последващо спадане на сигналите;
  
  
• `ACTIVE` — седемте ограничения вече определят валидността на трансакциите;
  
  
• `EXPIRED` — след 52 416 активни блока ограниченията отпадат.
  

Доброволно заключване изискваше поне 1 109 сигнализиращи блока от общо 2 016 — малко над 55%. Ако прагът бъде достигнат, предложението преминава в `LOCKED_IN`. След още един период от 2 016 блока правилата стават `ACTIVE`.

Стандартният BIP 9 използва времеви краен срок и състояние `FAILED`, ако подкрепата не бъде достигната. BIP 110 премахна крайния срок. Вместо него кодът съдържаше задължително сигнализиране между блокове 961 632 и 963 647.

Ако отделената верига преминеше през целия период, при блок 963 648 щеше да достигне `LOCKED_IN`. След още 2 016 блока — при височина 965 664 — седемте RDTS правила трябваше да станат `ACTIVE`.

Задължителното сигнализиране не беше ново гласуване

Периодът на задължително сигнализиране означаваше, че възлите с активиран BIP 110 приемат само блокове, в които миньорът е поставил bit 4. Всеки блок без този сигнал се смяташе за невалиден от тях.

Този период не измерваше нова подкрепа. Ако една верига допуска само сигнализиращи блокове, показателят ѝ естествено ще бъде 100%. Това е последица от филтъра в софтуера, а не доказателство, че всички миньори са променили позицията си.

В последния пълен период преди разделянето само 51 от 2 016 блока сигнализираха за BIP 110 — 2,53%. Това е наблюдаван дял от произведените блокове, а не пряко и напълно точно измерване на хешрейта. Сигнализиращ миньор също не е задължително да прилага седемте RDTS правила.

На 15 юли OCEAN включи bit 4 по подразбиране на съществуващия си endpoint. Миньорите, които не желаеха да сигнализират, трябваше да преминат към друг адрес. Промяната увеличи броя на сигнализиращите блокове, но не доказва, че всеки свързан миньор е взел самостоятелно решение в подкрепа на BIP 110.

Today, OCEAN is launching two additional Stratum endpoints.

We’ve heard from miners who want a simple way to express support/readiness for BIP110 in their blocks, and we’re making that available.

OCEAN has added two new Stratum endpoints:
• https://t.co/EvfOwnYuDF port 3110
•… pic.twitter.com/cfDU7QSsJS

— OCEAN (@ocean_mining) July 8, 2026

Броят на публично достъпните възли също не е надеждно гласуване. Един оператор може да стартира множество възли, а друг да управлява един възел, през който преминава значителна икономическа дейност. Такова измерване не е устойчиво срещу Sybil атака — създаване на много привидно независими участници от една страна.

Блок 961 632 отдели BIP 110 блокчейна от Биткойн

При блок номер 961 632 AntPool намери блок без bit 4. Обикновените Биткойн възли го приеха, защото той спазва действащите консенсусни правила.

Миньорът Roughnecks, използващ инфраструктурата на OCEAN, произведе алтернативен сигнализиращ блок на същата височина. Възлите с активиран BIP 110 отхвърлиха блока на AntPool и последваха сигнализиращата версия.

За възел без специалните правила на BIP 110 и двата блока поотделно са валидни. Той избира веригата с най-много натрупана изчислителна работа, известна като chainwork.

За възел, прилагащ BIP 110, блокът на AntPool е невалиден заради липсващия сигнал. Такъв възел не може автоматично да премине към основният блокчейн, независимо колко работа е натрупана върху нея, докато продължава да използва същите RDTS правила.

Полученият резултат е разделяне на веригата, въпреки че BIP 110 е проектиран като софтфорк. Софт  форка описва съвместимостта на правилата; разделянето описва фактическата поява на две несъвместими истории, следвани от различни възли.

Отделената верига произведе два блока и спря

След сигнализиращия блок 961 632 OCEAN произведе и блок 961 633. Следващ блок не се появи.

Около 06:00 ч. UTC на 9 август отделеният блокчейн оставаше при блок №961 633, докато основната верига на Биткойн вече беше достигнала 961 681. Разликата от 48 блока показваше, че почти цялото наблюдавано блоково производство продължава по основната верига. CoinDesk определи BIP 110 веригата като фактически спряла.

По-късно официалният сайт на предложението потвърди спирането и инструктира операторите да:

• прекратят временно услугите, свързани със заседналия възел;
  
  
• преминат към Bitcoin Knots версия без RDTS;
  
  
• отхвърлят локално първия BIP 110 блок, ако възелът не смени веригата автоматично;
  
  
• изчакат пълна синхронизация с основната верига на Биткойн.
  

Публикуването на процедура за връщане, вместо план за продължаване на добива, показва практическия край на опита за активация.

Наследената трудност направи продължаването нереалистично

Блок 961 632 постави началото на нов период от 2 016 блока между две преизчислявания на трудността. Биткойн настройва трудността приблизително на всеки две седмици, така че при наличния хешрейт средното време между блоковете да остане около десет минути.

Proof of Work не измерва броя на миньорите, а реално вложената изчислителна работа. И двете вериги наследиха една и съща трудност при разделянето, но отделената BIP 110 верига разполагаше само с малка част от наблюдаваното блоково производство.

Затова нейните блокове идваха през часове, а не през приблизително десет минути. За да получи първа корекция на трудността, тя трябваше самостоятелно да произведе още 2 014 блока след 961 633.

При първоначално наблюдаваното темпо мониторът оценяваше достигането на следващата корекция след около 350 дни, вместо обичайните 14. Биткойн допълнително ограничава промяната при едно преизчисляване до фактор четири. Дори достигането на първата корекция нямаше веднага да пригоди трудността към хешрейт от няколко процента.

Тук се вижда разликата между номер на блок и календарно време. Кодът можеше да постави `LOCKED_IN` на височина 963 648, но не можеше да гарантира кога отделеният блокчейн ще произведе необходимите блокове. След като тя спря при 961 633, максималната активационна височина 965 664 изгуби практическо значение.

Повече за връзката между миньорите, блоковете и трудността може да прочетете в материалите за Биткойн майнинга и структурата на блокчейн блока.

Replay рискът възникна от общата история на двата блокчейна

Двата блокчейна споделят еднаква история до блок 961 631. Един и същ стар UTXO следователно съществува и в двете версии на регистъра.

BIP 110 не включва автоматична защита срещу повторно излъчване на трансакции, известна като replay protection. Преди активацията на седемте RDTS правила и двете вериги приемаха еднакво подписани трансакции.

Ако притежател подпише трансакция с частния си ключ, за да продаде монетите от BIP 110 веригата, купувачът може да копира същата трансакция и да я излъчи в основната мрежа. Така продавачът може неволно да изпрати и реалните си BTC до същия получател.

Предупреждението за replay риска не означава, че портфейлът може да бъде източен без подпис. Могат да бъдат повторени само вече подписани трансакции.

Безопасното разделяне на монети изисква UTXO, който вече съществува само в едната история, както и внимателен coin control — ръчен избор на точно определени неизразходвани изходи. Това е специализирана операция и не трябва да се приема, че всеки Биткойн портфейл я поддържа правилно.

След спирането на BIP 110 блокчейнът обикновените притежатели нямат причина да взаимодействат с нея. Операторите на заседнали възли трябва да изпълнят официалната процедура за възстановяване, преди да изпращат или приемат плащания.

Съществуването на втори регистър с два блока не удвоява икономическото количество BTC. За да се появи отделен актив, са нужни работещ блокчейн, миньори, портфейли, борси, ликвидност и участници, които му приписват стойност. BIP 110 не изгради такава инфраструктура.

Сравнението с BIP 148 пропуска ролята на BIP 91

BIP 110 често беше сравняван с BIP 148 — потребителски активирания софтфорк от 2017 г., свързан с активирането на SegWit.

И при двете предложения определени възли трябваше да отхвърлят блокове без изисквания сигнал. Разликата е в предварителната координация.

Преди флаговата дата на BIP 148, BIP 91 получи достатъчна миньорска подкрепа и започна да изисква сигнализиране за SegWit. Това позволи на BIP 141 да достигне заключване на активацията, без да се развие продължително разделяне около BIP 148.

Доколко заплахата от потребителски активиран софт форк е ускорила тази координация остава исторически спор. Проверимият факт е, че преди решаващия момент вече съществуваше работещ механизъм с широка миньорска подкрепа.

BIP 110 започна задължителното сигнализиране с 51 от 2 016 блока, или 2,53%, и без подобен координационен мост. Резултатът не повтори 2017 г. — появи се отделен блокчейн, който спря след два блока.

Промяна на Proof of Work остана неизползван резервен вариант

Част от поддръжниците обсъждаха промяна на алгоритъма за Proof of Work, която да отдели BIP 110 от съществуващите SHA-256 ASIC миньори. Chris Guida съобщи, че е обновил по-стар код на Luke Dashjr за по-нова версия на Bitcoin Knots.

Seems like many miners still aren't getting the message that we need them to signal readiness for BIP-110 now to prevent forcing everyone to distribute CSAM

So I've rebased @LukeDashjr's 2017 PoW-change hardfork code onto a recent version of Knots: https://t.co/j4oT14EJZI

I…

— Chris Guida | ⚡🪢 BIP110 (@cguida6) August 4, 2026

Кодът не се превърна в мрежова промяна. Нямаше:

• приет BIP с окончателен алгоритъм;
  
  
• договорена височина за активиране;
  
  
• стабилна версия за реална употреба в основната мрежа;
  
  
• доказана подкрепа от миньори и икономически участници;
  
  
• инфраструктура за портфейли и борси.
  

Смяната на Proof of Work би представлявала хардфорк, отделен от BIP 110. Старите възли не могат да валидират блокове, добити чрез нов и непознат алгоритъм.

Официалният проект вече препоръчва връщане към веригата на Биткойн, а не активиране на резервния код. Това премахва PoW промяната като актуален сценарий за настоящия опит.

BIP 110 не промени консенсуса на Биткойн

Към 9 август 2026 г. резултатът може да бъде описан без предположения:

• седемте RDTS ограничения не са активирани;
  
  
• BIP 110 остава със статус `Complete`, а не `Deployed`;
  
  
• отделената верига спря при блок 961 633;
  
  
• основната верига на Биткойн продължава с най-много натрупана Proof of Work;
  
  
• официалният проект препоръчва на засегнатите възли да се върнат към софтуер без RDTS;
  
  
• правилата и лимитът от 21 милиона BTC не са променени;
  
  
• Bitcoin Core 30 продължава да прилага собствената си конфигурируема политика за препредаване.
  

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

Спорът за произволните данни не е решен. Остават основателни опасения за разходите на възлите, UTXO набъбването и превръщането на блоковото пространство в постоянно хранилище. Същевременно BIP 110 показа риска от промяна на консенсуса без достатъчно широка и проверима координация.

Биткойн продължи да работи по досегашните правила. Ако в бъдеще бъде предложено друго ограничение върху данните, то ще трябва да спечели подкрепа чрез нов процес, нова реализация и значително по-широко съгласие. Проваленият опит на BIP 110 не може сам да се превърне в активна промяна.

Източници:

1. Bitcoin BIPs — BIP 110: Reduced Data Temporary Softfork
2. BIP 3 — статути Complete, Deployed и Closed
3.Официална процедура за възстановяване след BIP 110](https://bip110.org/recovery/)
4. Bitcoin Development Mailing List — дискусията за BIP 110
5. Bitcoin Core 30.0 Release Notes
6. Bitcoin Core development and transaction relay policy
7. Strategy — 110 Reasons BIP 110 Is a Bad Idea
8. OCEAN — Публикация в Х: промяна на настройката за BIP 110 сигнализиране
9. CoinDesk — BIP 110 веригата спира след два блока
10. CoinDesk — рискът от replay на трансакции
11. BIP 148 — Mandatory activation of SegWit deployment
12. BIP 91 — Reduced threshold SegWit MASF
13. SimpleMining — хронология и сигнализиране за BIP 110
14. Chris Guida — Публикация в Х: резервен код за PoW промяна

Забележка: Информацията, публикувана в Cryptoria.bg, има изцяло образователен и информационен характер и не представлява финансова, правна или инвестиционна консултация. Нито една статия, анализ или новина на този уебсайт не следва да се тълкува като препоръка, оферта или покана за покупка, продажба или участие в каквито и да е криптовалути, дигитални активи или финансови инструменти.

Отказ от отговорност: Криптовалутите и свързаните с тях технологии са обект на висока волатилност и повишен риск. Препоръчваме ви винаги да провеждате собствено проучване (DYOR) и да се консултирате с лицензиран финансов или правен експерт, преди да вземате инвестиционни решения. Cryptoria.bg не носи отговорност за загуби или щети, произтичащи от използването на информацията, публикувана на този уебсайт.