Potvrzení

Alice pošle kamarádovi 20 000 sat, tedy nejmenších jednotek bitcoinu. Její peněženka ukazuje Odesláno a kamarád už vidí příchozí platbu, ale zatím s nulou potvrzení. To si neodporuje: informace o platbě se rozšířila mezi uzly, tedy počítači ověřujícími Bitcoin, ale dosud není v bloku. Mempool je místní zásobník nepotvrzených transakcí takového uzlu; nejde o jednu společnou frontu celé sítě. Jakmile platba vstoupí do přijatého bloku, získá první potvrzení. Další navazující blok znamená druhé a další třetí. Alice nemusí nic odesílat znovu. Samotné rozeslání transakce není potvrzení a ani její identifikátor txid to nezaručuje. Nepotvrzenou transakci může nahradit jiná, například pomocí Replace-by-Fee (RBF) při zvýšení poplatku. Přijmout platbu bez potvrzení se označuje jako zero-conf a znamená nést riziko, že se nakonec potvrdí jiná útrata stejných prostředků. [4] [8] [11]

Těžař vybírá transakce do nového bloku a hledá platný Proof of Work, výsledek nákladných výpočtů požadovaný pravidly Bitcoinu. Ostatní plné uzly potom blok samy prověří: sedí podpisy, částky a podmínky utracení a nejsou použité prostředky už utracené? Nejde o hlasování těžařů ani o razítko jedné firmy. Těžař nemůže neplatnou platbu udělat platnou tím, že ji vloží do bloku. Uzel ji započítá jako potvrzenou teprve v přijaté větvi řetězce. Mezi platnými větvemi vybírá podle největší nahromaděné práce, označované chainwork. Každý blok odkazuje na předchozí, takže dodatečná změna starší historie vyžaduje přepracovat i její pokračování. [2] [7]

Bitcoin míří na průměrně deset minut mezi bloky, nikoli na jízdní řád. Nový blok může přijít za několik sekund, ale také mnohem později. Ani hodina čekání sama o sobě neznamená šest potvrzení. Vyšší sazba poplatku může zvýšit šanci, že těžař vybere právě vaši transakci, ale nezrychlí vznik bloků. Peněženka někdy umí použít RBF, tedy náhradu nepotvrzené transakce s vyšším poplatkem, nebo CPFP (Child Pays for Parent): navazující transakce přidá dostatečný poplatek, aby se těžaři vyplatilo zahrnout ji společně s předchozí. Možnost závisí na konkrétní peněžence a transakci. Nízký poplatek může znamenat dlouhé čekání nebo odstranění z místního Mempoolu. Odhad peněženky proto berte jako odhad, ne jako slíbený termín. [3] [4]

Příjemce nebo služba si určuje, po kolika potvrzeních platbu uzná. U malé částky může přijmout jiné riziko než u nevratného předání drahého zboží. Pokud burza čeká na několik potvrzení, může být transakce už v blockchainu, zatímco zůstatek na burzovním účtu ještě není připsaný. Neznamená to automaticky chybu platby. Ověřte částku, cílovou adresu a stav ve vlastní peněžence; u služby také její podmínky připsání. Důležitý je i zdroj informací. Útočník může izolovat uzel a podsouvat mu omezený pohled na síť; tomu se říká Eclipse Attack. Přiměřené čekání proto závisí na hodnotě platby, možnosti nápravy, důvěře v protistranu i způsobu ověřování. Samotný počet potvrzení nechrání před ukradeným klíčem. [11] [13]

Představte si platbu jako zápis, nad kterým přibývají další stránky historie. Změnit ji nestačí jen v jedné staré stránce: útočník by musel vytvořit konkurenční platné pokračování s dostatečnou nahromaděnou prací. S dalšími potvrzeními je to za běžných předpokladů obtížnější. Výsledek ale závisí i na výpočetním výkonu útočníka a stavu sítě. Často uváděných šest potvrzení je historické vodítko, nikoli pravidlo konsenzu ani kouzelná hranice úplné bezpečnosti. Pravděpodobnost přepsání historie nelze poctivě vyjádřit jedním pevným číslem pro všechny situace. Ani více potvrzení neopraví chybnou adresu nebo platbu podvodníkovi. [1] [13]

Krátké rozvětvení může vzniknout i bez útoku, když dva těžaři najdou blok téměř současně. Přechod uzlu na jinou vítěznou větev se nazývá reorganizace. Výstup transakce eviduje částku a podmínky jejího utracení; vstup další transakce na tento výstup odkazuje a utrácí jej. Neutracený výstup se označuje UTXO. Získá-li konkurenční platná větev více nahromaděné práce, tedy chainwork, uzel odpojí závěrečné bloky původního řetězce a připojí vítěznou větev. Transakce z odpojeného bloku se může vrátit do Mempoolu, pokud je stále platná, nebo se může potvrdit v jiné výšce. Může se také stát konfliktní, jestliže nová větev utratila stejný výstup, na který odkazuje její vstup. Záporná hodnota confirmations v Bitcoin Core je způsob, jak peněženka vyjadřuje hloubku konfliktu. Neznamená záporný počet bloků v pravidlech konsenzu. [5] [7]

Výška bloku je jeho pořadové číslo, počítané od počátečního bloku s číslem nula. Je-li blok transakce ve výšce h a poslední blok aktivního řetězce uzlu ve výšce H, počet potvrzení je H − h + 1. Samotný blok s transakcí se tedy počítá jako první. Výsledek závisí na nejlepším ověřeném bloku daného uzlu, a při příchodu nových bloků se proto může mezi uzly krátce lišit. Není součástí transakce, neroste pouhým plynutím času a nelze jej spolehlivě určit z časového razítka. Bitcoin Core vrací údaje jako blockhash, blockheight a confirmations podle stavu, který zná příslušná peněženka nebo pohled na UTXO. [3] [5] [6]

SPV označuje zjednodušené ověřování plateb, zatímco RPC je programové rozhraní pro dotazy uzlu. Rozdíl mezi způsoby ověřování je důležitý i tehdy, když obě aplikace ukazují stejné číslo. Plný uzel ověřuje řetězec a odpovídá podle aktuálního konce svého ověřeného řetězce. Klient SPV kontroluje Proof of Work v hlavičkách bloků a Merkleův důkaz zařazení transakce, ale sám neověřuje všechna pravidla konsenzu. Merkleův důkaz pomocí krátké sady kryptografických otisků doloží zařazení transakce do bloku, aniž by bylo nutné stáhnout všechny jeho transakce. Služba, která drží prostředky za uživatele, navíc uplatňuje vlastní pravidla připisování plateb a řízení rizika. I výsledek RPC z plného uzlu zachycuje stav v určitém okamžiku, který může změnit reorganizace. Vedle počtu potvrzení proto záleží i na tom, čímu pohledu na řetězec, ověřování a úschově prostředků uživatel důvěřuje. [1] [2] [8]

Coinbase Transaction je zvláštní první transakce bloku, která vyplácí odměnu těžaři; nesouvisí s burzou Coinbase. Časový zámek omezuje, kdy lze prostředky utratit. BIP označuje dokument technického návrhu nebo standardu. Potvrzení spouští také některé lhůty protokolu. Výstup coinbase transakce podléhá pravidlu COINBASE_MATURITY = 100: lze jej utratit nejdříve v bloku, jehož výška je o 100 vyšší než výška bloku s touto coinbase transakcí. Jde o povinnou čekací lhůtu před utracením odměny za blok, nikoli o volbu příjemce běžné platby. Relativní časové zámky BIP68 se odvozují od potvrzení utráceného výstupu a vyhodnocují jeho stáří podle pravidel pro bloky nebo čas. Skript je krátký program, který určuje podmínky utracení výstupu. Příkaz CHECKSEQUENCEVERIFY (CSV) z BIP112 umožňuje tuto relativní podmínku vynutit ve skriptu. Transakce utrácející nepotvrzený výstup stále závisí na transakci, která jej vytvořila. Aby se navazující transakce mohla potvrdit, musí být její předchůdci zahrnuti ve stejném nebo starším bloku. [9] [10]

Lightning Network umožňuje platby přes kanály, jejichž financování je zajištěno bitcoinovou transakcí. BOLT je označení její technické specifikace; zde jde o otevření kanálu, nikoli o čekání na blok u každé platby uvnitř něj. BOLT 2 umožňuje straně přijímající Lightning kanál stanovit v poli minimum_depth požadovaný počet potvrzení financující transakce před odesláním zprávy channel_ready. Tímto požadavkem zohledňuje riziko dvojí útraty financování. Kanál otevřený bez potvrzení, tedy zero-conf channel, nastaví minimum_depth na nulu a vědomě spoléhá na důvěru v poskytovatele financování i omezení protokolu. Nezískává tím okamžité nevratné vypořádání. Pokud je samotná financující transakce coinbase transakcí, BOLT 2 ukládá straně, která kanál neotevírá, počkat nejméně 100 bloků. Provozovatel má sledovat konkrétní financující výstup, tedy funding outpoint, jeho hloubku v aktivním řetězci a reorganizace. Samotný rozeslaný txid ještě neznamená otevřený kanál. [12] [14]