Válka o OP_RETURN - zabijí libovolná data Bitcoin?

Válka o OP_RETURN - zabijí libovolná data Bitcoin? – OBSAH

1. Ukládání informací do Bitcoinu
2. Full nody, pruned nody a SPV
3. Forky
4. Veřejná síť
5. Konsenzus a standardnost
6. Jak obcházení pravidel standardnosti způsobuje centralizaci
7. OP_RETURN
8. Velikost bloku
9. Blokování extra dat
10. Současná diskuse
11. No dobře, ale je blokování opravdu horší?
12. Další argumenty pro a proti
13. Závěr

Ukládání informací do Bitcoinu

Jelikož má být Bitcoin vzácný (21M limit) a je zároveň elektronický, je nutné zajistit, aby stejné satoshi nebyly použity dvakrát (tím samým vlastníkem). V decentralizované síti je jedinou možností, jak toho dosáhnout, zveřejnění „účetní knihy“. Každý účastník musí vědět o každé transakci. Důsledkem je, že Bitcoin je jedna z nejvíce replikovaných databází, tzn. kopie dat Bitcoinu je na obrovském počtu počítačů po celém světě. Díky tomu je Bitcoin velmi odolný i vůči obrovským živelným katastrofám a nehodám.

Tato vlastnost je ale zajímavá i pro lidi mimo Bitcoin nebo pro bitcoinery na účely jiné než samotné transakce. Krátce po vzniku Bitcoinu do něj proto začali lidé ukládat informace navíc. (Zlé jazyky tvrdí, že Satoshiho zpráva v Genesis bloku byla jen politický komentář - nebyla, byl to i důkaz, že Satoshi nezačal těžit dříve.) Už tehdy se ohledně tématu vedly diskuse a sentiment byl nepoužívat Bitcoin na nefinanční účely. Tomu je však v decentralizovaném systému navrženém na obranu proti cenzuře náročné zabránit.

Další vlastností uložení informací do Bitcoin time chainu je schopnost dokázat, že informace byly známy v konkrétním časovém rozsahu. (Čas bloku není přesný, je třeba počítat s možnou odchylkou 2 hodiny a také s dobou potvrzení.) Někteří lidé si myslí, že přímo uložení informace je nutné, ale ve skutečnosti to tak není. Je možné vytvořit důkaz o znalosti informace a „přimíchat“ ho do veřejného klíče tak, že se nezmění jeho velikost a dokonce pro třetí stranu ani není možné určit, zda se v klíči takový důkaz nachází nebo ne. V angličtině se tomu říká „commitment“ a dalo by se to přeložit jako „kryptografický závazek“.

Funguje to podobně jako zapečetěná obálka. Obsah obálky zůstává skrytý a neměnný, dokud ji někdo neotevře. Stejně tak informace „zapečetěné“ v klíči jsou skryté a neměnné. Je ale třeba zdůraznit, že tam nejsou reálně uložené - dá se k nim dostat pouze tak, že je autor prozradí a poté se jen ověří, zda je autor nezměnil. Je to podobné jako když rozpustíme krystal soli ve vodě - dá se zjistit, že je slaná, ale původní krystal z ní nedostaneme.

Takový klíč smíchaný s důkazem funguje jako běžný veřejný klíč. Pro vložení do time chainu stačí vytvořit zcela obyčejnou transakci na adresu odpovídající tomuto klíči a důkaz je hotový. Je to velmi efektivní. Tuto techniku přímo využívá i bitcoinové vylepšení Taproot a pro nefinanční účely poskytuje služba Open Timestamps zdarma nástroje na vytváření takovýchto důkazů. A protože se přitom nemění velikost dat, nemusíme to v tomto tématu dále rozebírat.

Existuje však ještě jedno specifické využití ukládání informací. V některých kryptografických protokolech, jako např. Lightning Network, je nutné zajistit, aby byla za určitých (nouzových) okolností zveřejněna konkrétní informace. Nestačí jen důkaz, že v nějakém čase existovala; relevantní účastníci protokolu k ní musí mít přístup. Zároveň je potřeba i důkaz, že je informace skutečně dostupná – nestačí ji jen „uložit do cloudu“ nebo třeba zveřejnit v novinách. Bitcoin timechain zde nabízí přirozené řešení: každý uživatel Bitcoinu s full nodem má přístup ke všem datům v time chainu a zároveň, pokud by ke zveřejnění nedošlo, určitá transakce by nebyla považována za platnou. Tedy je možné zajistit, že buď všechno proběhne v pořádku, nebo se nic nestane (tj. nic se nepokazí).

Full nody, pruned nody a SPV

Pro úplnost si zopakujme typy nodů, protože lidé v nich mají někdy zmatek.

Pojem „full node“ označuje jakýkoli node, který provedl úplné ověření time chainu. To znamená, že pokud by obdržel blok, který by porušoval jakékoli pravidlo, odmítne ho. Stejně jako validátor bankovek odmítne falešnou bankovku. To je velmi důležité pro zabránění podvodům.

Někteří lidé si myslí, že pruned node není full node, ale není to pravda. Pruned node je jednoduše takový full node, který se zbaví starých a nepotřebných dat. To znamená starých bloků. Ověřovat může nadále v plné míře, protože má stále potřebná data a ta nezahodí, dokud je potřebuje. Pruned node tedy dokáže všechno to, co jiný full node (tzv. full archival node), avšak v případě získávání starých bloků se zvyšuje odezva a zatížení sítě uživatele.

Samozřejmě, pokud by celá síť používala pouze pruned nody, měli bychom problém, protože staré bloky by se ztratily, ale v praxi se nezdá, že by to hrozilo. Cena uložiště, které uchová tolik dat, je do 50 EUR, a to počítám s rychlým SSD, pomalé HDD (což může stačit) je ještě levnější.

Naproti tomu SPV node je takový, který se spoléhá pouze na částečné ověření. Neověřuje všechna pravidla, protože porušení některých z nich je pro těžaře extrémně drahé, pokud je v síti dost ekonomicky aktivních full nodů. To znamená full nodů, jejichž majitelé běžně přijímají bitcoiny (v dostatečně velkých částkách). Pokud by full nodů bylo málo, šance úspěchu útoku narůstá, a tím i riziko pro SPV nody. Výhodou SPV nodu je, že spotřebuje méně výpočetního výkonu, místa na disku a síťové kapacity. Proto je používají lidé, kteří si full node nemohou dovolit nebo v situacích, kdy je nepraktické ho použít (např. na telefonech).

Full nody jsou tedy klíčové pro fungování Bitcoinu a množství lidí je právem proti změnám, které by příliš zvyšovaly cenu jejich provozu.

Forky

Pro jistotu ještě zopakujme, co jsou to forky: jsou to jakékoli změny v pravidlech Bitcoinu. Umožňují Bitcoin vylepšit nebo opravit kritické chyby. Jejich realizace je však velmi náročná, protože vyžadují, aby obrovské množství lidí aktualizovalo svůj node. Rozlišujeme dva typy: soft forky a hard forky. Soft forky zpřísňují pravidla a jejich realizace je mnohem snazší než realizace hard forků, které pravidla uvolňují. Bitcoin měl historicky pouze jeden hard fork (někteří by argumentovali, že to ani hard fork nebyl) a několik soft forků.

Veřejná síť

Snad každý, kdo slyšel o Bitcoinu, ví, že používá „jakýsi blockchain“, ale už málokdo ví o veřejné (P2P - zkratka z „peer to peer“) síti, která je také velmi významná. Umožňuje spolehlivě šířit důležité informace mezi nody. A ne, není to „blockchain“ ani „timechain“. Touto sítí si nody posílají zejména transakce a bloky. Každý node je připojen k několika jiným nodům, kterým může informace posílat. Ty pak posílají dále a ty dále. Jako hra na telefon.

Takto se časem každá transakce a každý blok dostane ke každému, včetně těžařů. V principu tato síť není nezbytná pro některé základní operace. Je možné například spojit se s těžařem přímo a posílat mu transakce. Obcházení veřejné sítě ale není dobré pro odolnost Bitcoinu (na to se podíváme v pozdější části).

Konsenzus a standardnost

Bitcoin má dvě sady pravidel transakcí: konsenzuální pravidla a pravidla standardnosti. Konsenzuální pravidla jsou „tvrdá“ - určují, jaké bloky jsou akceptovatelné pro účastníky sítě. Těžař, který by je porušil, by nedostal zaplaceno za vytěžený blok. Pravidla standardnosti jsou „měkká“ - určují, jaké transakce jsou nody ochotné šířit dále veřejnou sítí, předpokládajíce, že časem dorazí k těžaři. Avšak je možné je porušit například tím, že někdo přímo kontaktuje těžaře a pošle mu transakci.

Změna konsenzuálních pravidel tedy nutně znamená fork. Změna pravidel standardnosti ovlivňuje pouze to, jaké transakce se budou šířit veřejnou Bitcoin sítí. Pokud by měly různé nody různá konsenzuální pravidla, síť by se mohla rozdělit na části, což je dost katastrofální událost. (Která se bohužel jednou stala a SlushPool - současný Braiins - tehdy přišel o dost peněz.) Pokud by měly různé nody různá pravidla standardnosti, katastrofa nenastane, Bitcoin funguje dál, jen některé nody a někteří těžaři mohou mít problémy.

A skutečně, v praxi se pravidla standardnosti různí. Vedle nejpopulárnější implementace full nodu, Bitcoin Core, existují další alternativy. Známé jsou například Bitcoin Knots a Libre Relay. Bitcoin Knots má striktnější pravidla standardnosti, Libre Relay naopak uvolněnější. Výsledek je, že ta striktnější nemají na bloky praktický efekt - pokud někdo chce zveřejnit transakci, která je porušuje, stačí si nainstalovat a použít Libre Relay. A dokonce je možné porušit úplně jakákoli pravidla standardnosti.

I když se dají pravidla standardnosti různými způsoby obejít a nebrání v samotném vytěžení transakce, neznamená to, že jsou zbytečná. Naopak, hrají důležitou roli. Pomáhají chránit síť před některými DoS útoky (snahy o přetížení nodu), usnadňují zavádění různých vylepšení Bitcoinu a snižují riziko, že uživatelé omylem vytvoří problematické nebo neobvyklé transakce. Díky nim mohou soft forky bezpečně omezit určité typy transakcí bez toho, aby ohrozily existující uživatele. Pravidla tak slouží jako filtr pro transakce, které by mohly být škodlivé, neefektivní nebo v praxi nemají legitimní využití – například takové, které by vedly ke ztrátě BTC nebo zbytečně zatížily uzly v síti. Pokud však někdo opravdu chce vytvořit transakci mimo tato pravidla, stále má tu možnost.

Jak obcházení pravidel standardnosti způsobuje centralizaci

Pravidla standardnosti však mají i své temné stránky. Jednou z nich je to, že kvůli různým pravidlům jsou mempooly různé, takže se hůře zjišťuje, jaké jsou skutečné poplatky v síti. To může mít za následek i nespolehlivost uzavírání LN kanálů a v extrémním, velmi hypotetickém případě, ztrátu satoshi kvůli podvádění. Dalším problémem je, že pokud existuje touha některá pravidla obejít a nedá se najít alternativa pomocí veřejné sítě, je nutné kontaktovat přímo těžaře. Jenže nikdo se nebude obtěžovat kontaktovat nějakého sólo těžaře, který má 0,01 % výkonu sítě, aby mu zaplatil za to, že s pravděpodobností 0,01 % vytěží jeho speciální transakci. Ten, kdo chce těžit speciální transakce, jednoduše kontaktuje několik velkých poolů, zaplatí jim, možná i mimo time chain, a transakce se vytěží.

To ale dává konkurenční výhodu velkým těžařům, protože mají extra příjem, který malí nemají - přímo v protikladu s myšlenkou decentralizace. Zároveň bloky, které mají speciální transakce, se šíří sítí pomaleji, protože nemohou tak dobře využít optimalizaci popsanou výše. Za normálních okolností se pro šíření bloků používá optimalizace, která využívá přítomnost transakce v mempoolu nodu, aby ji nebylo třeba posílat znovu. Jenže speciální transakce v mempoolu nejsou a musí se tedy poslat.

Naneštěstí, pomalé šíření bloku dává další konkurenční výhodu velkým těžařům. Jakmile je vytěžen nový blok, těžaři, kteří o něm ještě nevědí, stále těží na starém. A s pravděpodobností, která je proporcionální jejich výkonu, se stane, že najdou alternativní blok, který bude soupeřit s tím, který našel jiný těžař. Pokud však blok nenajdou, jsou to pouze spálené peníze a těžení nemělo smysl. V případě malých těžařů se statisticky častěji stane, že alternativní blok nenajdou a budou mít vyšší ztráty. Velcí těžaři naopak získávají tím, že se zbavují konkurence.

Výsledek je, že malí těžaři spíše zbankrotují a síť zůstane pouze větším těžařům, či poolům, podkopávajíc decentralizaci.

Aby toho nebylo málo, různost pravidel zároveň může způsobit větší zátěž nodů. Vždy, když node šíří transakci veřejnou sítí, musí spotřebovat nějaké zdroje, aby ji zpracoval. Aby nebylo možné node jednoduše zaspamovat, vyžaduje, aby transakce byla platná a platila dostatečně vysoký poplatek. Pokud jsou pravidla různá, je tak možné poslat různé transakce různým nodům, ale po vytěžení bude platná jen jedna z nich. To za určitých okolností může vést k tomu, že nody zbytečně spotřebují zdroje na zpracování transakce, což má za následek, že provoz takových nodů je náročnější a bude jich méně.

Popravdě řečeno, trochu vyšší zátěž nodů v praxi není příliš velký problém a útok je drahý. I kdyby pár nodů vypnulo službu přeposílání transakcí, stále se najde dost těch, které to budou dělat, a zatím jich není potřeba mnoho. Je to však celkem zajímavý detail a kdo ví, jak se potřeba těchto nodů vyvine v budoucnosti.

OP_RETURN

Na rozdíl od příznivců Etherea, Bitcoin podporuje chytré kontrakty a podporoval je od samého začátku, už když ho vydal Satoshi. Aby to bylo možné, nerozhoduje o umožnění transferu Bitcoinu přímo podpis, ale krátký program (nazvaný Bitcoin Script), který může obsahovat verifikaci podpisů. Tento program se skládá z instrukcí a jedna z nich se nazývá OP_RETURN. Tato instrukce říká, že převod je neplatný a hned transakci odmítne bez dalšího pokračování ve skriptu. A právě tato instrukce se stala základním kamenem pro vyřešení vážného problému s ukládáním dat.

Pokud nemáte mnoho místa na disku, ale chcete provozovat full node, v současnosti to není problém. Prostě zapnete „pruning“ - průběžné mazání starých a nepotřebných údajů. Avšak některé údaje jsou potřebné, a to zejména UTXO set - množina všech neutracených „mincí“ - výstupů. Ta narůstá s každým výstupem transakce. No ale právě do těch výstupů lidé v minulosti ukládali data, maskující se jako veřejné klíče, protože jiné alternativy nebyly praktické. Tím nemyslím „commitment“, jako byl popsán výše, ale fiktivní veřejný klíč, ke kterému nikdo (ani sám autor) nezná soukromý.

V té době byly standardní pouze transakce obsahující výstupy typů P2PK, P2PKH, P2SH. Kdo chtěl ukládat data, poslal prostě pár satoshi „na adresu“, ve skutečnosti však tato „adresa“ byly zakódované údaje. A protože soukromý klíč není znám, nikdy nebude možné výstup utratit. Následek je, že žádný majitel full nodu už nebude nikdy moci tyto údaje smazat, protože neví, že se utratit nedají. Ani kdyby s tím souhlasil ten, kdo tam ty údaje přidal, protože se nedá dokázat, že to tak udělal a že je vůbec právoplatným majitelem, protože nemá privátní klíč.

Další problém takového ukládání dat je, že spotřebovává i data navíc. Každý výstup potřebuje minimálně 9 B v transakci navíc. No, standardní výstupy potřebují alespoň 11 B. Pokud je výstupů mnoho, velikost se navýší ještě o kousek, ale pro jednoduchost to nyní ignorujme (pointa platí i bez toho). Pokud by tedy někdo chtěl uložit například 320 B dat, musel by je rozdělit na 10 částí. To by ve výsledku znamenalo zabrání 430 B dat. No a pro každý takový výstup v UTXO setu je třeba 92 B dat, což znamená, že pro takovou transakci se ukládá 920 B dat v UTXO setu. Transakce tedy na full archival node zabírá dohromady 1240 B dat - skoro čtyřnásobek toho, co chtěl někdo uložit.

Nejenže tato data zabírají místo, ale zpomalují i verifikaci time chainu. Tento fenomén je výborně popsán v technických článcích The Myth of RAM. Nebudu to zde rozebírat, protože je to náročné, faktem ale je, že čím větší úložiště, tím déle trvá z něj vytahovat data v náhodném pořadí (případ Bitcoinu).

Když se takové ukládání stalo populárním, představovalo to pro Bitcoin problém. Jako řešení vývojáři Bitcoin Core změnili standardnost tak, že umožnili, aby skripty ve výstupech začínaly instrukcí OP_RETURN a výstup, který takový skript obsahuje, může mít nulovou sumu. (Ta byla také nestandardní.) Takový skript tedy vždy zakáže utratit dotyčné bitcoiny (předchozí výstup). Tato vlastnost je, na rozdíl od veřejných klíčů, přímo viditelná ve skriptu pro každý node. No a protože výstup se prokazatelně nedá utratit, netřeba ho ukládat do UTXO setu, protože ho určitě nebude nikdo potřebovat. Teoreticky se tedy ušetří zhruba 75 % dat pro full archival node a 100 % pro pruned node. Navíc nulový limit na sumu představuje drobnou slevu za to, že se používá efektivnější metoda ukládání a motivuje lidi tuto šetrnější metodu preferovat.

I takový výstup se skriptem začínajícím s OP_RETURN byl se standardním limitem 80 B (původně 40 B, v průběhu historie se měnil). To donedávna stačilo na většinu použití, protože se převážně používal na ukládání hashů méně efektivních timestamp služeb nebo veřejných částí stealth address protokolu. Vyskytl se ale nový protokol, který potřebuje 144 B. Ten opět zbývající data ukládá do dalších výstupů, nafukujíc UTXO set. Bylo by možné prostě limit zvýšit, pokud by se však později něco podobného opět vyskytlo, diskuse by se opakovala a stále by platilo, že pokud se limit nezvýší, bude někdo ukládat do UTXO setu. Takže je jednodušší prostě limit odstranit. (Limit bloku 4 MB zůstává, dá se tedy říct, že limit 80 B se zvýšil na necelých 4 MB) A právě o tom je aktuální diskuse.

Velikost bloku

Zpracování a ukládání dat o transakcích všech lidí je přirozeně náročné na procesorový výkon a jiné zdroje. Když k tomu přidáme nefinanční data, je to ještě náročnější. To na jedné straně omezuje, kolik transakcí může síť zpracovat a na druhé straně udává minimální hardwarové požadavky pro full node. Riziko zahlcení sítě vedlo k jednomu z nejznámějších parametrů Bitcoinu - 4MB limit velikosti bloku.

Detaily jsme podrobně rozebírali v podcastu s Duškym. Zkrácená verze je, že velké bloky vytvářejí tlak proti decentralizaci. Pokud je cena ověření time chainu kvůli množství dat příliš vysoká, málo lidí bude ověřovat všechna data v síti a hrozí riziko, že dojde k porušení pravidel, například i inflací. Pokud je velikost bloku příliš nízká, poplatky za použití time chainu stoupají a tlačí lidi používat custodial služby, které by je mohly okrást nebo špehovat. Kvůli tomu v roce 2017 Bitcoineři vedli virtuální válku, protože bylo náročné dohodnout se, jak tyto výzvy vyřešit. Nakonec vyhrálo zvýšení limitu z 1 MB na 4 MB a podpora technologií, jako je Lightning Network. (Někteří zmatení lidé i nyní, téměř 8 let od konce „války“, tvrdí, že velikost je 1 MB)

Samozřejmě, i když máme limit na velikost bloku, stále je lepší, aby byly bloky menší, pokud je to možné. Extra data stále velikost bloku zvyšují. Snad žádný vývojář netouží po tom, aby byly bloky větší. V ideálním světě by měly nekonečnou zápornou velikost! To se samozřejmě nedá, takže se musíme spokojit s nějakou kladnou velikostí. Logicky by dávalo smysl extra data blokovat, to ale není možné – a alternativy jsou horší.

Kupodivu se extra data zpracovávají dokonce mnohem snadněji než obyčejné transakce. Je to tím, že Bitcoin Core obsah těchto dat nepotřebuje ověřovat - stačí je zahashovat, aby se ujistil, že se nezměnila. Transakční data naproti tomu obsahují podpisy a jejich ověření je velmi výpočetně náročné v porovnání s hashováním (ono i to hashování v rámci nich probíhá). To vede k paradoxu: sice pokud blok není plný, tak přidávání extra dat snižuje rychlost ověřování, ale pokud je blok plný, tak extra data vytlačují klíče, podpisy a podobně, jejichž zpracování by trvalo déle, čili rychlost zpracování se zvýší! Pro rychlost validace je lepší mít 1MB blok pouze s finančními daty než mít 3MB blok s finančními daty a s extra nefinančními daty navíc, ale je také lepší mít 4MB blok s nefinančními daty než mít 4MB blok s finančními daty.

Blokování extra dat

Jelikož je příliš velké množství dat v time chainu problém, někteří lidé by rádi extra data zablokovali. Podívejme se, jak by to vypadalo.

V současnosti se používají tři hlavní způsoby ukládání dat:

• Výstup, jehož skript začíná OP_RETURN
• Veřejné klíče bez známého soukromého klíče
• Witness data

První dva jsem už vysvětlil, ten poslední ukládá data do podpisu transakcí a používají ho inscriptions. Jelikož se dá lehce vymazat, má také slevu 75 %. (Jak jsem ukázal výše, zhruba tolik se ušetří, dá se ale argumentovat, že kvůli pruningu by ta sleva měla být vyšší.) Představme si, že bychom chtěli všechny způsoby zablokovat. Nejprve pouze standardností: Zablokovat výstup, jehož skript začíná OP_RETURN, je lehké, prostě bychom odstranili výjimku z kódu, která tam byla před lety přidána, a máme hotovo.

Witness data jsou podstatně těžší - abychom neohrozili legitimní položky ve Witness, museli bychom nějak sledovat, které instrukce nespotřebovávají data. Například by mohlo být nutné zakázat instrukci OP_DROP, pokud prvek, který odstraňuje, nebyl předtím použit v některé z legitimních instrukcí. Ale museli bychom se zbavit i různých triků, kde se instrukce kombinují, aby to obešly. (Např. OP_DUP OP_EQUALVERIFY) Pokud tomu nerozumíte, je to v podstatě pointa: je to těžké. :) Myslím si ale, že by to šlo. (Pro ITčkaře: Skript není Turing-kompletní.) Bylo by to samozřejmě extra zpracování dat navíc.

Neutratitelné klíče mají jednoduché řešení: mohli bychom požadovat, aby ti, kdo se snaží transakci odeslat prokázali, že jsou klíče funkční. To je vlastně celkem lehké - stačí, aby podepsali nějakou konkrétní zprávu (ne transakci). První problém je, že verifikace podpisů je dost náročná operace a vedla by k zátěži nodů. Druhý je, že bychom to museli udělat i pro Taproot - vylepšení, které se aktivovalo před pár lety a přináší významné optimalizace v time chainu a dokonce zlepšení soukromí. Vyžadováním podpisů by se však pokazily některé možnosti použití. (Například současná implementace Firefish by přestala fungovat.) A výrazně by to podkopalo výhody soukromí, které Taproot přinesl.

Tohle všechno by však stále nezabránilo lidem v kontaktování těžařů, a jak jsem psal výše, vedlo by to k centralizaci. Pokud bychom to navíc chtěli zavést jako soft fork, bylo by to ještě horší. V první řadě by bylo náročné ověřovat dodatečná data o důkazech v rámci konsenzu, takže by to muselo probíhat „mimo“, podobně jako vylepšení SegWit přenáší podpisy „mimo“. Ten kód je dost komplikovaný a bylo by náročné ho napsat a dlouhodobě udržovat. Další data by přinesla i extra náklady na ověřování, které by však nyní už byly povinné a pro všechny transakce od určitého bloku. Čili ironicky by se zátěž nodů a cena synchronizace ještě více zvýšila. A ne triviálně - můj dávný experiment ukázal, že ověřování a neověřování podpisů všech transakcí udělá rozdíl v synchronizaci řádově ve dnech! Spolu s nutností odhalit data z Taprootu bychom navíc ztratili úplně všechny jeho výhody - optimalizaci velikosti, soukromí i výkonu.

A to není všechno! I kdybychom zablokovali všechny tyto způsoby ukládání dat, což není vůbec lehké, zůstal by jeden, který nikdy nebude možné blokovat: steganografie - skrývání toho, že se něco skrývá. Už velmi dávno jsem napsal program, který demonstroval, že je možné vygenerovat posloupnost Bitcoin adres, do kterých je ukrytá tajná informace. Jsou to plnohodnotné adresy - normálně se na ně dá přijmout i odeslat z nich. Každá má svůj privátní klíč a je možné to dokázat jiným nodům - čili prošly by kontrolou popsanou výše. A protože data jsou zašifrovaná, není možné odlišit je od legitimní posloupnosti adres. Jinými slovy, nikdy nebude možné vytvořit na ně filtr. Nevýhoda tohoto řešení je, že zabírá násobně více dat a vytváří násobně více výstupů. Navíc, pokud se adresy skutečně použijí na útratu, je třeba ještě více času na ověření kvůli podpisům, jak jsem psal výše. (Ale aspoň nezpůsobí dlouhodobý problém zvětšování UTXO setu.)

Výsledkem je, že time chain by se zvětšil už sám o sobě a dostatečně motivovaní „ukladači dat“ by navíc byli donuceni zvětšit ho ještě víc. Samozřejmě, zaplatili by za to víc satoshi než dnes, ale určitě by je to odradilo? Pokud dnes lidé platí miliony za obrázek opice nebo banánu nalepeného na stěně, pochybuji, že pár desítek nebo stovek eur navíc by je odradilo.

Celá věc je dvojnásobně ironická: nastalo by přesně to, čemu se blokování snažilo zabránit, a k tomu by šlo v podstatě o snahu cenzurovat - přitom Bitcoin byl výslovně navržen tak, aby byla cenzura prakticky nemožná. No, ono ta nemožnost blokovat „nefinanční transakce“ bude asi důsledkem obrany před cenzurováním.

Čili, jak říkají naši čeští bratři, „tudy cesta nevede“.

Současná diskuze

Nedávno na základě těchto argumentů (v kratší formě) vývojáři Bitcoinu navrhli odstranění 80B limitu standardnosti pro výstupy, jejichž skript začíná OP_RETURN. Toto téma bylo diskutováno ve veřejném mailing listu. Kdokoliv si mohl argumenty přečíst a reagovat. Jelikož však vývojáři rozuměli, že je limit spíše škodlivý, v diskusi souhlasili a jeden z nich připravil změnu kódu, kterou odeslal jako pull request. (Pull request slouží na technické připomínkování, zda kód funguje správně.)

Po „válce o Bitcoin“ zůstali mnozí bitcoineři obezřetní, možná až ustrašení ohledně změn Bitcoinu. V jistém smyslu je velmi dobré, že jsou lidé skeptičtí vůči změnám a pustí se do boje. Kéž by to tak zůstalo. V tomto případě bohužel mnozí vůbec nečetli argumenty na mailing listu a hned zbrkle reagovali na GitHub pull requestu. GitHub pull request však není pro takovou diskusi vhodné místo.

Proto moderátor, technicky správně, skryl irelevantní příspěvky, tím ale asi dotyčné ještě více naštval. Samozřejmě, vypadá to jako cenzura. V kombinaci s podozřele vypadající změnou a dokonce údajným konfliktem zájmů to může vypadat jako kompromitace Core vývojářů. No není tomu tak.

Abych to přiblížil, představte si, že pracujete ve slušné firmě, kde management, zváživ pro a proti na svých poradách, rozhodne o určitém postupu práce. Celý závěr vám vysvětlí a vy souhlasíte, že to má logiku a pustíte se do toho. Dokonce to všechno zveřejní pro kohokoli, kdo má zájem se o tom dozvědět, i s vhodným kontaktem na možné připomínky. Uprostřed práce vám na pracoviště vtrhne zástup neznámých lidí, kteří začnou tvrdit, že to tak dělat nemáte, a argumentují věcmi, které úplně ignorují realitu. Z vyjádření je jasné, že téma vůbec nemají nastudované. Přišlo by vám to v pohodě? Nebylo by snad vhodnější, aby si dotyční nastudovali argumenty a logicky je vyvrátili na určeném místě skrz zveřejněné kontaktní údaje? (Jasné, analogie má nepřesnost v tom, že Bitcoin nemá management, ale pointa je, že odpor byl projeven na nevhodném místě nevhodným způsobem.)

Čili není to cenzura, je to normální moderování lidí, kteří se nechovají slušně. Co je navíc velmi smutné, ani po upozornění, že se to probíralo a že jsou zveřejněné argumenty pro, jsem neviděl nikoho z odpůrců zrušení limitu se ani jen pokusit argumenty vyvrátit. Ani jeden necitoval některý z argumentů a neukázal, proč je chybný, byť i chybně. Dokázal bych pochopit, že si někdo té diskuse nevšiml, ale psát stylem „jeden o voze, druhý o koze“ i po upozornění je velmi zvláštní.

No dobře, ale je blokování opravdu horší?

Samozřejmě, je pravda, že blokování alespoň trochu zvyšuje náklady na přidávání dat. Je tedy teoreticky možné, že blokování je stále menší zlo než neblokování.

Podívejme se nejprve na blokování pomocí soft forku: Pro zabránění ukládání libovolných dat bychom museli vyžadovat dvakrát tolik podpisů než dnes. Za každý výstup ne-taproot transakce (běžná má dva) bychom navýšili velikost alespoň o 97 bytů (33 pro klíč, 64 pro podpis), čili typicky 192 bytů na transakci. To je více než dvojnásobek dnešního limitu pro výstup začínající OP_RETURN. Pro Taproot je to složitější - museli bychom uložit celý strom - všechny skripty, jejich verze a pro každý klíč v nich zase podpis. No i kdybychom vzali optimistický případ, že žádné skripty nejsou, museli bychom to dokázat, což také zabírá 33 B a spolu s podpisem by to opět bylo 97.

Jinými slovy, pokud by dnes každá jedna transakce přidala výstup začínající OP_RETURN maximální standardní délky, velikost bloků by se zmenšila méně než kdyby bylo implementováno blokování, a navíc by s sebou nesla extra cenu verifikace či ztráty soukromí Taprootu. Dnes nemá každá transakce výstup začínající OP_RETURN, takže tato změna je úplně jasně horší.

Aby bylo jasno, netvrdím, že někdo toto navrhl a nechci tu strawmanovat. Pokud vím, nikdo to seriózně neřeší a není to reálný argument. Chci jen ukázat, že se touto možností nemá smysl dále zabývat.

Tak to zjednodušme na pravidla standardnosti a skutečný argument: „alespoň je to těžší“. Problém je, že jde o software - jakmile jednou existuje naprogramovaný nástroj, který něco ulehčí, od toho momentu to bude lehké. No a zde je možnost pro mining pooly či velké solo těžaře získat výhodu: Naprogramují webovou stránku, kde uživatel zadá svá data, pošle BTC ať už na adresu nebo pomocí LN a těžař to vytěží. Udělat něco takového je poměrně jednoduché, troufám si říct, že funkční základ bych dokázal udělat nejpozději za pár dní.

V momentu, kdy existuje taková stránka, se výhoda blokování trvale ztratila a zůstala pouze nevýhoda. A co čert nechtěl, i kdyby se potom limit zrušil, stále existuje funkční nástroj, který zvýhodňuje některé těžaře, a jediný způsob, jak ho porazit, je udělat konkurenční, lepší nástroj, který poskytuje tutéž službu za lepších podmínek. Tento nástroj by samozřejmě mohl vytvořit konkurenční těžař, ale malý na to nebude mít peníze. Bitcoinerská komunita by takovou věc musela dobrovolně zafinancovat a spravovat. Blokování by tak maximálně pozastavilo ukládání dat na možná pár týdnů.

Jsem přesvědčen, že to za to nestojí.

Další argumenty pro a proti

Výše jsem uvedl podrobnou analýzu hlavní linie sporu a argumentů, ale mezi argumenty proti se objevily i jiné, které do ní nezapadají.

„Ty chceš, aby lidé spamovali Bitcoin!“

Nechci. Mě vážně nezajímá, že na opačné straně planety Jožo poslal Ferovi opici, ba nezajímá mě ani, že poslal BTC. Nechci platit za dražší HW jen proto, abych tyto nesmysly zpracoval. A to platí snad pro každého vývojáře Bitcoinu. Ale jiná možnost prostě není. Tak, jako bych chtěl vzlétnout jen zamáváním rukou, ale nedá se to.

„Proti špatné věci se vyplatí bojovat i tak, například jako bojujeme proti zločinům, i když nedokonale.“

Tento argument je chybný, protože zločinci čelí vážným následkům, pokud spáchají zločin a jsou chyceni. Páchat zločiny je tedy rizikové (dražší) a to je reálně drží na uzdě. Pokud však někdo jen vytvoří transakci, která je zablokovaná jako spam, nic se mu nestane. Ztratí maximálně tak čas, který strávil její tvorbou, a dokonce může zkusit najít jinou metodu, která zabere. A když už je jednou metoda známá, může se rozšířit a může ji používat více lidí.

Ale argument je chybný i proto, že, jak jsem popsal výše, důsledky boje proti nefinančním datům jsou horší.

„Co když někdo do transakce vloží nepřerušenou sekvenci ilegálních bytů?“

Přesněji, argument je, že některé soubory jsou dnes ilegální a uživatelé mohou mít kvůli nim problémy a, ačkoli je možné ilegální soubor uložit do time chainu, v současnosti musí být rozkouskovaný.

V první řadě, právník Radim Kozub, kterého asi někteří znáte z jeho aktivit v Paralelní Polis, mi potvrdil, že jen mít data na disku jako součást jiné aplikace (ne přímo dostupná) není ilegální (Pozor, toto není právní rada!) Ale i kdyby bylo, argument má další problémy.

Pokud by to byla pravda, existoval by způsob, jak mohou zločinci ukládat a šířit nelegální obsah: stačí ho rozdělit na části. Myslíte, že by u soudu nějaký šiřitel ilegálních souborů uspěl s argumentem „ten soubor nebyl ilegální, protože byl rozdělen na části“? Já osobně tomu nevěřím. Ale i kdyby ano, typický příklad takového obsahu jsou obrázky. Pokud by někdo v takovém ilegálním obrázku změnil každý 173. pixel na červený, stal by se legálním? Tady je příklad, jak takový obrázek vypadá.

Radim potvrdil, že obrázek, který vypadá prakticky stejně, je stále ilegální - pár bodů to nezmění. Tento obrázek je ale možné už dnes vložit do time chainu tak, že bude mít údaje následující po sobě. Tento problém už tedy v Bitcoinu je a odstraněním (zvětšením) limitu se nic nezmění.

Protiargument k tomuto byl, že je to náročné. Ale opět, stačí, aby to udělal jediný člověk, a celý Bitcoin je „infikovaný“. A náročné to není, při tvorbě mého příkladu napsal kód ChatGPT a fungoval bezchybně na první pokus.

Navíc, celým smyslem Bitcoinu je vyhnout se vlivu státu na finance. Pokud někdo provozuje full node takovým způsobem, že ho stát může reálně skenovat, či dokonce ovlivňovat, tak nepochopil Bitcoin a potenciálně zvyšuje rizika pro ostatní bitcoinery. Možná je to hnusné, ale takový člověk si problémy snad i zaslouží.

Trochu jiná, asi rozumnější, verze argumentu je, že různé skenovací nástroje by zbytečně nahlašovaly takové soubory, i když jsou v pořádku. To je sice asi pravda, ale aplikuje se pouze na lidi, kteří takové nástroje spouští - to není typické použití, ale uznávám, že není ani vyloučené. Tito lidé však mají možnost soubory proti takovým nástrojům zamaskovat. Dokonce je to automatické pro ty, co nestáhli data velmi dávno. A i ti, co stáhli, mají hned dvě možnosti, jak to vyřešit (smazat a stáhnout nanovo, nebo použít nedávno vydaný nástroj). Nezapomínejme však, že tento problém má Bitcoin už nyní. Limit pro výstup, jehož script začíná OP_RETURN, to nezmění.

I tak, není to argument proti (velkým) scriptům začínajícím OP_RETURN, ale maximálně pro jeho oddálení, dokud nebude podpora maskování lepší. Tedy, i to stojí na vratkých nohách, ale budiž, oddálit kvůli tomu vydání bych si dovedl představit.

„A co tedy ten konflikt zájmů?“

V první řadě bych chtěl upozornit, že konflikt zájmů neznamená hned, že je něco špatně. Pokud výrobce trianglů (hudební nástroj) řekne, že Pythagorova věta platí, tak to přece neznamená, že by neplatila, nebo že „lobuje za Pythagorovu větu“. Každopádně, ano, návrh zrušit limit zahrnoval zmínku o protokolu a jeden z jeho vývojářů s návrhem souhlasí. Co ale tento protokol ve skutečnosti získá? Kdyby ho předělali tak, aby používal výstup, jehož skript začíná OP_RETURN, ušetřili by malé množství satoshi, ale stálo by je to přepracování – minimálně několik hodin práce včetně testování a možná dokonce i auditu.

Změna pro ně téměř nemá smysl. (A proto je třeba konat co nejdříve - pokud to změní ještě před vydáním, bude to pro ně levnější a přijatelnější.) Ale nyní po nich Core vývojáři vlastně chtějí, aby to předělali z dobré vůle, že to nebude zatěžovat síť. Na druhé straně je jiní lidé očerňují a až změnu provedou, možná budou za špatné. Smutný stav.

Ale i kdyby tam konflikt zájmů byl, je to jen jeden vývojář z mnoha.

„Co když zrušení limitu způsobí nějaké katastrofální důsledky?“

Protože limit je možné obejít už dnes a jeden ze způsobů obcházení je spustit fork Bitcoin Core, který ho nemá, jsou tyto katastrofální následky možné už dnes, beze změny. Pokud má někdo důvod věřit, že katastrofální následky jsou možné, doporučuji prodat (a zdanit!) všechen Bitcoin.

„OK, proč ale PR odstraňuje konfigurovatelnost nodů?“

Toto je celkem relevantní otázka. Pokud je limit špatný, za normálních okolností by se neměl vynucovat, ale měla by zůstat možnost pro lidi ho zapnout. Obyčejně jsem pro konfigurovatelnost, ale má to zde logiku? Kdo zapne limit:

• Dostane ty transakce stejně, ale později
• Nebude moct tak dobře odhadovat poplatky (pokud se nechce spoléhat na veřejné služby)
• Nijak nezmění obsah bloků (a pokud by mohl, bude to spíše špatně)
• Ušetří RAM pouze v okrajových případech - když je málo transakcí
• Dopomůže maličko velkým minerům

Skutečně se někdo takový najde? Z PR vidíme, že takoví lidé jsou, což zjevně nikdo nečekal. Udržovat nesmyslné konfigurační volby má svou cenu - vývojáři stráví více času jejich správou, namísto toho, aby dělali něco jiného. Je tedy přirozené, že Peter Todd navrhl rovnou odstranit i tyto konfigurační volby.

Každopádně, ačkoli si myslím, že by bylo lepší je odstranit, ponechat je by neměl být velký problém. Daný pull request se už zrušil a nový konfigurační volby ponechá, jen změní výchozí hodnotu.

Závěr

Doufám, že odteď patříte i vy mezi ty, kteří Bitcoinu rozumí natolik, že dokážou dojít k závěru: limit 80 B pro skripty začínající OP_RETURN je škodlivý a měl by být zrušen. Chápu, že takové jednoznačné odpovědi jsou nezvyklé a asi se najdou lidé, kteří si stále nebudou jisti. Ale faktem je, že logicky vyplývají z toho, jak funguje Bitcoin, sítě, fyzika a matematika. Podobně jako Pythagorova věta taktéž logicky vyplývá z matematických axiomů. V každém případě vám všem držím palce při studiu Bitcoinu a při činění správných rozhodnutí ohledně provozu full node. :)

Na závěr chci ještě poděkovat všem lidem, kteří jakoukoli formou přispěli ke vzniku tohoto článku.