Dvojí útrata

Představte si, že Tomáš má jeden dříve přijatý výstup v hodnotě 100 000 sat, nejmenších jednotek bitcoinu. Takovému dosud neutracenému výstupu se říká UTXO. Připraví platbu, která pošle Alici 99 000 sat a 1 000 sat nechá jako poplatek. Mohl by však podepsat i jinou transakci, která utrácí stejné UTXO a posílá částku někam jinam. Obě odkazují na stejný zdroj peněz, proto jsou v konfliktu. Není to jako zkopírovat soubor: bitcoinový uzel, počítač ověřující pravidla, nedovolí použít stejný výstup dvakrát v jednom platném řetězci. Podvod by uspěl, pokud Alice vydá zboží za první platbu, ale v přijaté historii nakonec zůstane ta druhá. Nevznikly nové mince; Alice se spolehla na prohranou variantu. Technicky každý vstup odkazuje na výstup pomocí identifikátoru předchozí transakce txid a čísla výstupu. Tato dvojice se nazývá outpoint. [1] [3] [7]

Alice může vidět příchozí platbu během několika sekund. To ale ještě neznamená, že ji síť zapsala do bloku. Mempool je místní zásobník nepotvrzených transakcí uzlu; neexistuje jeden globální Mempool ani společné pořadí doručení platné pro celý Bitcoin. Jiný uzel mohl nejdřív dostat konfliktní variantu, nebo tu Alicinu dosud vůbec neviděl. Zásada first-seen znamená upřednostnění první přijaté varianty při předávání transakcí. Není to slib, že ji těžař zařadí do bloku. Screenshot peněženky ani samotný txid tedy nejsou důkazem vypořádání. Důležitý je stav konkrétní platby ve spolehlivě ověřeném řetězci. [2] [5]

Alice může naopak posílat poctivou platbu, která dlouho čeká. Funkce Replace-by-Fee (RBF) umožňuje nahradit nepotvrzenou transakci jinou, obvykle s vyšším poplatkem. Příjemce může dostat stejnou částku, přestože se změní txid. Náhrada používá alespoň část stejných prostředků, a je tedy technicky konfliktní s původní transakcí, aniž by se někdo pokoušel příjemce okrást. Rozhoduje obsah nové platby a okolnosti, ne samotný nápis RBF. Stejný mechanismus ovšem může také přesměrovat peníze jinam. Pravidla Full-RBF, která nevyžadují signalizaci nahraditelnosti v původní transakci, jsou v Bitcoin Core výchozí od verze 28. Náhrada stále musí splnit pravidla uzlu pro poplatky a ochranu proti zahlcení. Ani chybějící signalizace RBF proto nedělá nepotvrzenou platbu nezvratnou. [5] [6] [15]

Potvrzení vzniká, když se platba dostane do platného bloku přijatého uzlem. Další navazující bloky obvykle ztěžují nahrazení této historie, a tím snižují riziko úspěšného podvodu. Neexistuje však jeden bezpečný počet pro každou situaci. U kávy je případná ztráta jiná než při předání auta nebo výběru velké částky z burzy. Často uváděných šest potvrzení je zvyklost, nikoli pravidlo Bitcoinu. Příjemce má zvažovat hodnotu, možnost nápravy, neobvyklé chování řetězce a kvalitu svého zdroje informací. Izolace uzlu, označovaná Eclipse Attack, může jeho pohled na síť zkreslit. Čekání proto patří dohromady s ověřováním, ne místo něj. [2] [10]

Přechod uzlu na jinou platnou větev řetězce se nazývá reorganizace. Proof of Work dokládá práci potřebnou k vytvoření bloků; souhrnná práce větve se označuje chainwork. Po potvrzení už konfliktní transakce nemůže platbu pouze vytlačit z Mempoolu. Alternativní platná větev musí původní platbu vynechat, zahrnout druhou útratu a nashromáždit více práce, tedy chainwork, než aktivní řetězec příjemce. Reorganizace řetězce může nastat i bez podvodu, například při téměř současně vytěžených blocích nebo při chybě softwaru či sítě. O úspěšnou dvojí útratu vůči oběti jde až tehdy, když útočník získá hodnotu díky vítězství konfliktní transakce. Bitcoin Core může u prohrané transakce peněženky zobrazit záporný počet potvrzení v poli confirmations a související konflikty v poli walletconflicts. [4] [7] [8]

Hashrate je rychlost výpočtů při těžbě. Větší podíl výkonu může pomoci při závodě o historii, nedává ale výjimku z ostatních pravidel. O šanci, že soukromě těžená větev dožene poctivý řetězec, rozhodují mimo jiné podíl útočníka na výkonu sítě a počet potvrzení. Hodnota, kterou by mohl získat, ovlivňuje hlavně to, zda se mu útok vyplatí. Podíl pod 50 % neznamená nulovou šanci; trvalá většina výrazně zvyšuje možnost dohnat druhou větev. Ani většina však těžařům nedovolí padělat podpisy, utrácet cizí UTXO, porušit pravidla emise nebo přinutit plné uzly přijmout neplatný blok. Při posuzování útoku je třeba započítat výpočetní výkon, energii a ušlé odměny z poctivé těžby. Záleží také na dostupném kapitálu, riziku neúspěchu a možnosti odhalení. Výnos může zahrnout i zisk z pozic na finančních trzích, takže samotná cena pronájmu těžebních strojů k odhadu nestačí. [1] [10] [12]

Race zde znamená závod v načasování: příjemce a těžaři mohou nejdříve spatřit různé transakce. Při útoku race attack pošle plátce jednu transakci obchodníkovi a konfliktní transakci těžařům nebo jiným uzlům. Snaží se, aby obchodník nevratně předal zboží dříve, než blok vybere jednu variantu. Výsledek závisí na šíření transakcí, síťovém pohledu obchodníka, výběru těžařů a okamžiku předání zboží. Více nezávislých uzlů sledujících síť zlepší odhalování konfliktů, nezaručí však nezvratné vypořádání. Názvy race, Finney a Vector76 popisují scénáře útoku, nikoli datová pole transakce nebo odlišná pravidla konsenzu. [2] [11]

Finney attack je pojmenovaný scénář, ve kterém útočník kromě plateb ovládá také těžbu. Nejde o běžné chování peněženky při zvýšení poplatku. Při útoku Finney attack útočník s možností těžit nejprve soukromě vytěží blok s konfliktní transakcí, která vrací hodnotu jemu. Poté stejným UTXO zaplatí obchodníkovi, který přijímá platby bez potvrzení, a po převzetí zboží skrytý blok zveřejní. Plán uspěje pouze tehdy, pokud blok zůstane použitelný a síť jej přijme dříve, než přípravu zmaří poctivý konkurenční blok. Útočník tak riskuje odměnu za blok i náklady na těžbu. Čekání na zařazení obchodníkovy transakce do ověřeného bloku tento klasický postup přeruší, ale neodstraní riziko pozdější reorganizace řetězce. [1] [11]

RPC je programové rozhraní uzlu. Následující názvy jsou konkrétní příkazy a pole pro vývojáře platebního systému, nikoli další druh potvrzení. Systém obchodníka může na vlastním plném uzlu sledovat konfliktní útraty v Mempoolu, volat gettxspendingprevout, číst pole walletconflicts, porovnávat poslední blok aktivního řetězce a upozorňovat na ztrátu potvrzení. Více připojených nebo nezávislých uzlů omezuje slepá místa, ale nepřítomnost zjištěného konfliktu je slabým důkazem bezpečnosti: útočník může konfliktní transakci zadržet nebo ji poslat jinudy. Průzkumník bloků ukazuje pohled vlastního uzlu a může mít zpoždění. Odhalení konfliktu umožňuje zastavit předání zboží. Nemůže však těžařům přikázat, kterou transakci vybrat, ani učinit platbu bez potvrzení rovnocennou potvrzené platbě. [8] [9] [11]

Jako příjemce kontrolujte svou skutečnou příchozí platbu, její adresu, částku a potvrzení. Doklad od odesílatele to nenahradí. Vlastní plný uzel umožňuje pravidla ověřovat přímo; pokud používáte cizí službu, rozumějte tomu, čí informace a úschovu využíváte. Obchodní systém má spojit objednávku s konkrétními výstupy a sledovat i náhrady transakce. Při konfliktu nebo ztrátě potvrzení má pozastavit nevratné předání. Další platba utrácející nepotvrzenou vratku je na původní transakci závislá, není to nezávislé potvrzení její bezpečnosti. Lightning Network umožňuje rychlé platby v kanálech, jejichž financování se opírá o bitcoinovou transakci. Účastníci kanálu si vyměňují podepsané commitment transakce, které zachycují rozdělení prostředků. Při aktualizaci předávají protistraně tajné údaje umožňující postih, pokud by později zveřejnili překonaný stav; tomuto zneplatnění starého stavu se říká revocation. Ochrana vyžaduje včasné odhalení takového pokusu a reakci. Jde tedy o jiný mechanismus než předat zboží za nepotvrzený převod v blockchainu. Kanál otevřený bez potvrzení, zero-conf channel, vědomě důvěřuje poskytovateli financování a neodstraňuje riziko jeho dvojí útraty. [13] [14]