Finality

Pavel nejprve vidí, že se o transakci dozvěděla jeho peněženka. To není totéž jako její zařazení do bloku. Jakmile blok vznikne a navazují na něj další, přibývá práce, kterou by bylo nutné překonat při nahrazení dané historie. Právě tak roste praktická Finality. Záleží ale i na prostředcích případného útočníka a na stavu sítě. Protokol nevydá matematický certifikát nevratnosti; příjemce posuzuje, jak silné podklady má pro přijetí konkrétní platby. [1] [2]

Full Node, tedy uzel samostatně ověřující pravidla Bitcoinu, nepřijme historii jen proto, že je dlouhá. Nejprve kontroluje její platnost a mezi platnými větvemi vybírá tu s největší kumulovanou prací. Jde o práci doloženou bloky, ne o počet lidí, kteří pro větev hlasují, ani o množství jejich mincí. Více práce nedělá neplatnou transakci platnou. Pro Pavla je podstatné obojí: ověřit, že platba odpovídá pravidlům, a zjistit, jak hluboko leží v právě používané platné historii. [1]

V našem příkladu je Pavlova transakce v bloku s výškou 800000 a aktuální konec stejné větve má výšku 800005. Výška je pořadové číslo bloku, nikoli čas. Počítáme 800005 − 800000 + 1 = 6 potvrzení; započítává se i blok obsahující samotnou transakci. Nejde tedy jen o bloky, které přišly po něm. Pokud je platba pouze v mempoolu, seznamu dosud nepotvrzených transakcí daného uzlu, má 0 potvrzení. Samotné čekání tento počet nezvýší. [2] [3]

Síť může krátce znát soupeřící bloky a později pokračovat jinou platnou větví s větší prací. Takové změně aktivní historie se říká reorganizace. V dokumentaci Bitcoin Core 28.0 vrací dotaz na hlavičku bloku, getblockheader, hodnotu confirmations = -1, pokud tento blok není v aktivním řetězci. To popisuje blok, nikoli automatickou ztrátu všech jeho plateb. Pavlova transakce může být i v nové větvi, čekat bez potvrzení nebo být v konfliktu s jinou transakcí. Její konkrétní stav je proto nutné znovu ověřit. [1] [3]

Vývojářská příručka zmiňuje 6 potvrzení jako běžně používaný práh u hodnotných plateb, ale zároveň vysvětluje potřebu posuzovat riziko. Je to pravidlo příjemce, nikoli okamžik změny bitcoinového konsensu. Pavel má zvažovat hodnotu kola, případnou ztrátu a důvěryhodnost svého ověření; samotné číslo nerozhodne za něj. Ani přibližně hodinový průměr neznamená, že šest bloků vždy vznikne za hodinu. Těžba nemá pevný jízdní řád a starší obecné doporučení není zárukou pro každou situaci. [2]

Pavel může mít BTC potvrzené a přesto řešit spor o předání nebo stav kola. PFMI, mezinárodní principy pro finanční infrastruktury, požadují jasně určený okamžik konečného vypořádání a mez, po níž účastník nemůže odvolat pokyn. To je jiný rámec než počet bloků v Bitcoinu. Potvrzení samo neurčuje právní účinek smlouvy, konečnost bankovní platby ani převod vlastnictví prodávané věci. Technická kontrola platby je důležitá, ale nenahrazuje ostatní podmínky obchodu. [4]

Pokud se Pavel s kupujícím dohodnou na vrácení peněz, běžná refundace proběhne novou transakcí, kterou odešle příjemce původní platby. Původní převod tím z historie nezmizí. Bitcoin nemá centrální podporu s tlačítkem, kterým by na požádání zrušila potvrzenou platbu. Reorganizace je změna aktivní historie sítě, nikoli zákaznická služba pro opravu omylu. Proto je třeba kontrolovat příjemce a částku už před odesláním; čekání na další potvrzení špatně zadanou platbu neopraví. [5]

Pro provozovatele platební aplikace přijetím platby práce nekončí. Má evidovat transakci, její blok a zdroj ověření a rozpoznat, zda uzel nezůstal pozadu za sítí. Hodnota confirmations je stav při dotazu, ne trvalý certifikát. Když počet klesne nebo se objeví konflikt, aplikace musí postupovat podle předem stanovených pravidel a znovu ověřit aktuální větev. Starý snímek obrazovky proto není novým důkazem. Pro Pavla z toho plyne jednoduchá zásada: rozhodovat podle současného stavu své platby, ne pouze podle toho, co jednou ukázala peněženka. [2] [3]