BIP 110, nazvaný Reduced Data Temporary Softfork, je uzavřený návrh na dočasné zpřísnění pravidel, podle kterých uzly přijímají bloky. Uzel je počítač, který si sám ověřuje historii a platby. Návrh měl ztížit ukládání některých dat a podle zastánců posílit peněžní využití sítě. Nestal se tím automaticky pravidlem celého Bitcoinu.
Představte si, že dva provozovatelé uzlů přijmou stejný blok. První ho podle dosavadních pravidel uzná, druhý s novým omezením odmítne. Právě tak hluboko mířil BIP 110: měnil by platnost bloků, nejen ochotu uzlu přeposlat transakci nebo ji ponechat v mempoolu, místní čekárně nepotvrzených plateb. Kontrola 2026-10-23 našla ve specifikaci verze 1.0.1 stav Closed, tedy uzavřeno. Číslo BIP ani zveřejněný program nejsou razítkem, že změnu přijala síť. Registr návrhů uchovává dokument a jeho historii; pravidla jednotlivých uzlů na dálku nepřepíná. [1] [2]
Každý nový výstup transakce má scriptPubKey, skript určující podmínky budoucího utracení. Návrh mu dával nejvýše 34 bajtů. Pokud začíná OP_RETURN, instrukcí vytvářející prokazatelně neutratitelný výstup, povoloval 83 bajtů; do délky se počítá celý skript. Jiný limit, 256 bajtů, platil pro jednotlivá data vložená instrukcemi OP_PUSHDATA* a pro argumenty ve witnessu, doprovodných údajích k ověření utracení. Výjimkou je vložení redeemScript, odhaleného skriptu podmínek, do scriptSig podle BIP16. Samotné witness scripts a Tapleaf scripts nejsou takovými argumenty, jejich datové vkládací instrukce však limitu podléhají. Měřené jsou konkrétní části, nikoli celková délka transakce nebo celého witnessu. [1]
Zásah sahal také do Taproot, způsobu zápisu podmínek pro utracení. Zakazoval utrácet nedefinované verze witnessu nebo Tapleaf, ale nikoli takové výstupy vytvářet. Zakázán by byl annex, doplňkové pole, i control block nad 257 bajtů, tedy příliš dlouhý důkaz příslušnosti skriptu. V Tapscript by nesměl být OP_SUCCESS* ani v neprovedené části a nesmělo by dojít k vykonání podmíněných instrukcí OP_IF či OP_NOTIF bez ohledu na výsledek podmínky. Pro technické srovnání specifikace počítá s formáty P2WPKH, P2WSH, P2TR s verzí Tapleaf 0xc0 a P2A s programem 0x4e73, u něj pouze s prázdným witness stackem. To jsou přesná označení formátů, ne seznam údajů, které musí běžný uživatel zadávat do peněženky. [1]
UTXO je dosud neutracený výstup: konkrétní částka s podmínkami, za kterých ji lze použít. Pro vstupy utrácející UTXO potvrzená před aktivací návrh obsahuje výjimku. Neznamená to ale volnou ruku pro nové výstupy stejné transakce. Ani podpis připravený dopředu nezaručí ochranu, pokud se příslušné UTXO vytvoří až během aktivního období. U některých předem podepsaných Taproot konstrukcí specifikace připouští zmrazení nebo ztrátu prostředků, pokud omezení zneplatní zamýšlené cesty a nezbude použitelná alternativa. Týká se to i otázky dopadů na Miniscript, nástroj pro sestavování podmínek, a BitVM, konstrukce pro ověřování výpočtů. Nelze proto slíbit, že změna zasáhne pouze nepeněžní obsah. [1] [3]
Těžař může do bloku vložit signál podpory; zde šlo o bit 4 a práh 1109 z 2016 bloků, přibližně 55 procent. Návrh však nezůstával u dobrovolného signálu. Bez dřívějšího dosažení prahu požadoval signalizaci ve výškách 961632–963647, následně stav LOCKED_IN od 963648 a ACTIVE od 965664, pokud daný řetězec tak daleko dojde. Výška je pořadí bloku v řetězci. LOCKED_IN znamená připravený přechod, ACTIVE skutečné vynucování datových omezení. Už během povinné signalizace by klient odmítal nesignalizující bloky. Rozchod mezi uzly tedy mohl nastat ještě před novými datovými limity. Ty měly platit 52416 bloků od skutečné aktivace a pak přejít do EXPIRED, kdy se přestanou vynucovat; nejde o přesně odměřený kalendářní rok. [1] [4]
Zastánci chtěli snížit náklady provozu uzlu, tlak na soubor UTXO i množství nežádoucího obsahu a dát přednost peněžním platbám. To vysvětluje motivaci, samo to však neprokazuje účinek. Kritici upozorňovali na zásahy do užitečných skriptů, budoucích rozšíření a na riziko rozdělení sítě. Data navíc lze rozdělit do menších kusů: Peter Todd v počáteční diskusi předvedl transakci obsahující celý tehdejší návrh tímto způsobem. Ani specifikace neslibuje úplné odstranění steganografie, tedy ukrývání informace v jiných datech. Změna nákladů na ukládání dat a úplný zákaz jejich ukládání jsou odlišné výsledky. Stejně tak obava z právní odpovědnosti za obsah sama nedokládá konkrétní právní povinnost. [1] [3]
Záznam PR 2247 popisuje rozdělení dne 2026-08-08 na výšce 961632. Hlavní řetězec obsahoval blok bez požadovaného signálu, zatímco OCEAN vytěžil signalizující alternativu. Murch dne 2026-08-09 v diskusi uvedl, že menšinová větev získala jen 2 bloky a zastavila se, zatímco hlavní postoupila o více než 100 bloků. Takové hlášení je důležité číst s datem a jménem autora: nejde o zde provedené nezávislé přehrání blockchainu ani o dnešní stav menšinové větve. Ukazuje také, proč nelze zaměnit rozdělení kvůli signalizaci za dosažení ACTIVE a spuštění samotných datových omezení. [5] [6]
Dokument prošel stavem Complete, tedy dokončenou specifikací, a skončil jako Closed. PR 2245 k jeho uzavření byl sloučen 2026-08-10; záznam změn specifikace uvádí datum 2026-08-09. Rozdílná data popisují různé záznamy, nikoli další aktivaci. Vydání klienta v0.4.1 dokumentuje stav EXPIRED a údaj vbrequired, kterým šablona bloku označuje povinný signalizační bit. Existence tohoto klienta není přijetím návrhu v Bitcoin Core. K dispozici jsou i test vectors, vzorové transakce s očekávaným výsledkem, a funkční testy. Toto heslo je nespouští ani neověřuje současný menšinový řetězec. Smyslem je porozumět návrhu a jeho doloženému průběhu, nikoli vydávat historický dokument za dnešní společná pravidla sítě. [7] [1] [4]
O jediný bajt více může změnit výsledek
Představte si kontrolu nového výstupu v hypotetickém aktivním režimu. Běžný scriptPubKey o 34 bajtech projde tímto délkovým testem, při 35 bajtech už ne. Skript začínající OP_RETURN může mít 83 bajtů, při 84 bajtech limit překročí. Vždy měříme celý výstupní skript, ne pouze vložený text. Ani úspěch v tomto testu ještě neprokazuje platnost celé transakce a utrácení starého UTXO neuděluje výjimku novému výstupu.
Pro nejúplnější obraz čtěte toto heslo společně s Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. Opačným směrem na něj odkazují také OP_RETURN.
01Když je návrh Closed, nesmí už nikdo spouštět jeho klienta?+
Closed je stav dokumentu, nikoli zákaz používání programu. Uzly se řídí svým softwarem. Kdo ale zvolí odlišná pravidla, může skončit na jiné větvi řetězce; uzavření položky v registru tento rozdíl samo nesmaže.
02Platila datová omezení už v období povinné signalizace?+
Ne. Povinná signalizace předchází LOCKED_IN a ACTIVE. Klient může odmítnout blok bez požadovaného signálu ještě před spuštěním datových pravidel. Pro posouzení platnosti proto nestačí datum v kalendáři: záleží na stavu a výšce konkrétního řetězce.