Počet potvrzení je odvozený stav, nikoli pole uložené v transakci. Leží-li transakce v bloku výšky h a tip aktivního řetězce je H, její hloubka je H − h + 1. Transakce v mempoolu má nula potvrzení; Bitcoin Core může u konfliktní wallet transakce zobrazit zápornou hodnotu vyjadřující hloubku konfliktu.
Rozeslání není potvrzení. Každý uzel samostatně uplatní policy pro přijetí do svého mempoolu a různé uzly mohou kvůli času, fee, konfliktům, package limitům či nastavení vidět jinou množinu. RBF může nepotvrzenou transakci nahradit a platba viděná obchodníkem může zmizet, aniž se dostane do bloku. Zero-conf tedy mění rychlost za riziko double-spendu a neúplného síťového pohledu; txid ani stránka exploreru nejsou vypořádání. [Bitcoin Developer Guide — Transactions] [Bitcoin Core — JSON-RPC consistency] [BIP 125 — Opt-in Full Replace-by-Fee]
Miner může transakci vybrat do kandidátního bloku, první potvrzení však vzniká až tehdy, když validující uzel blok přijme a blok leží v jeho aktivním řetězci s největší chainwork. Full node ověří proof of work, scripts, existenci a neutracení inputs, částky i ostatní konsenzuální pravidla; miner nedokáže pouhým zařazením zplatnit neplatnou útratu. Merkle root zaváže transakci do bloku a odkaz na předchozí blok ji umístí do historie proof of work. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp]
Je-li blok transakce ve výšce h a aktuální tip uzlu H, počet je H − h + 1: samotný blok se počítá jako první. Hodnota vzniká vůči nejlepšímu ověřenému bloku daného uzlu, takže se u tipu může mezi uzly krátce lišit. Není zapsaná v transakci, neroste plynutím času a nelze ji spolehlivě určit z timestampu. Bitcoin Core vrací blockhash, blockheight a confirmations jako stav wallet či UTXO pohledu. [Bitcoin Developer Guide — Block Chain] [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — getbestblockhash]
Získá-li konkurenční platná větev více chainwork, uzel odpojí bloky starého tipu a připojí vítěznou větev. Transakce z odpojeného bloku se může vrátit do mempoolu, pokud zůstává platná, potvrdit se v jiné výšce, nebo se stát konfliktní, protože nová větev utratila stejný input. Záporné confirmations v Bitcoin Core jsou konvence wallet pro hloubku konfliktu, nikoli záporné bloky v konsenzu. [Bitcoin Core RPC — gettransaction] [Bitcoin Core — validation.cpp]
Další potvrzení přidávají proof of work za transakci, a typicky tak zdražují a znepravděpodobňují přepsání historie. Nevytvářejí deterministickou finalitu. Výpočet dohnání z whitepaperu i pozdější modely závisejí na podílu útočníkova hashrate, chování poctivé sítě a pozorování příjemce. „Šest potvrzení“ je historická pomůcka, ne konstanta konsenzu ani univerzální bezpečná mez; hluboký reorg je v principu stále možný. [Bitcoin whitepaper — Proof-of-Work and Calculations] [Rosenfeld — Analysis of Hashrate-Based Double Spending]
Počet vyžaduje příjemce, burza nebo navazující protokol, nikoli transakce sama. Káva, nevratné vydání drahého zboží, burzovní deposit a otevření kanálu mají jiné poměry ztráty a čekání. Policy má zohlednit hodnotu, vratnost plnění, motivaci a hashrate útočníka, konflikty či RBF, custody a backend, eclipse risk i neobvyklý stav řetězce. Potvrzení tlumí riziko přepsání chainu; neopraví ukradený klíč, chybnou adresu ani podvod protistrany. [BIP 125 — Opt-in Full Replace-by-Fee] [Rosenfeld — Analysis of Hashrate-Based Double Spending]
Bitcoin cílí na průměr zhruba deset minut mezi bloky, jenže příchody proof-of-work jsou náhodné: další blok může přijít za sekundy i za hodiny. Vyšší feerate může zlepšit pořadí při výběru minerem a RBF či CPFP ekonomiku package, žádný fee však nekupuje pevný čas a nezrychlí tvorbu bloků. Levná transakce může čekat mnoho bloků nebo být z mempoolu odstraněna; odhad je pravděpodobnost, ne deadline. [Bitcoin Developer Guide — Block Chain] [Bitcoin Developer Guide — Transactions]
Full node ověřuje řetězec a odpovídá podle vlastního aktivního tipu. SPV klient kontroluje proof of work v headers a Merkle proof zařazení, ale sám nespouští všechna konsenzuální pravidla; custodial služba navíc přidává vlastní crediting a risk policy. I RPC výsledek full nodu je snapshot změnitelný reorgem. Otázka tedy nezní jen „kolik potvrzení“, ale také čí chain view, validaci a custody uživatel důvěřuje. [Bitcoin whitepaper — Proof-of-Work and Calculations] [Bitcoin Core — Validation] [Bitcoin Core — JSON-RPC consistency]
Potvrzením začínají i jiné hodiny. Coinbase output podléhá COINBASE_MATURITY = 100 a lze jej utratit až po 100 nových blocích; to je jiné pravidlo než policy běžné platby. Relativní timelocks BIP68, vynucené skriptem BIP112 CHECKSEQUENCEVERIFY (CSV), měří věk od bloku potvrzení outputu. Nepotvrzený parent drží descendants v závislosti; aby se child potvrdil, musí být jeho předci ve stejném nebo starším bloku. [Bitcoin Core — consensus.h] [BIP 112 — CHECKSEQUENCEVERIFY]
BOLT 2 dovoluje příjemci Lightning kanálu zvolit minimum_depth funding transakce před channel_ready; číslem oceňuje double-spend risk financování. Zero-conf channel nastaví minimum_depth na nulu a vědomě spoléhá na důvěru ve fundera a protokolová omezení, nikoli na okamžitou finalitu. Coinbase funding čeká na maturity. Operátor má sledovat funding outpoint, hloubku v aktivním chainu a reorgy, ne považovat rozeslaný txid za otevřený kanál. [BOLT 2 — Peer Protocol] [Bitcoin Optech — Zero-conf channels]
Pro nejúplnější obraz čtěte toto heslo společně s Blok, Transakce, Reorganizace řetězce, Dvojí útrata, Proof of Work, Bitcoin. Opačným směrem na něj odkazují také Dvojí útrata, Coinbase transakce, Reorganizace řetězce, Riziko vypořádání.