Konflikt lze pozorovat ještě před vypořádáním, úspěšný double-spend však nastane až tehdy, když oběť vydá hodnotu za jednu transakci a v přijatém chainu zvítězí druhá. Nahrazená wallet platba, neúmyslný fee bump ani neúspěšný konflikt proto nejsou automaticky podvod. Zero-conf race a přepsání potvrzených bloků mají zásadně jiné náklady i riziko.
Každý input odkazuje na předchozí output pomocí txid a indexu. Dvě transakce jsou konfliktní, když nejméně jedním inputem odkazují na stejný dosud neutracený outpoint, ale nemohou platit zároveň. Uzel při validaci bloku kontroluje, že input existuje a nebyl utracen dříve v dané historii ani jinde v témže bloku. V platném UTXO setu přežije jen jedna větev; útok nevyrábí kopii satoshi, snaží se přimět příjemce jednat podle větve, která prohraje. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Bitcoin Developer Guide — Transactions] [Bitcoin Core — validation.cpp]
Před vytěžením neexistuje globální mempool ani konsenzuální pořadí nepotvrzených transakcí. Peers mohou kvůli propagaci, topologii, fee policy, package stavu či eclipse izolaci nejdříve vidět různé konflikty. First-seen je relay policy, nikoli závazek minerů potvrdit první variantu. Txid na backendu obchodníka dokládá jen to, že k němu dorazil jeden podepsaný kandidát, ne že jej viděla celá síť nebo že vyhraje blok. [Bitcoin Developer Guide — Payment Processing] [Bitcoin Core — Mempool Replacements]
Replace-by-fee dovoluje uzlu nahradit mempool conflicts splňující fee a anti-DoS pravidla; full-RBF je v Bitcoin Core výchozí policy od verze 28. Odesílatel může legitimně zvýšit fee uvízlé platby a zachovat výstup příjemce, nebo hodnotu přesměrovat. Konsenzus v obou případech vidí běžné kandidáty a přijme variantu v platné vytěžené historii. RBF signal, replacement ani bump sám nedokazuje podvod; transakce bez signálu zase není bezpečná pro zero-conf. [Bitcoin Core — Mempool Replacements] [BIP 125 — Opt-in Full Replace-by-Fee]
Při race attack pošle plátce jednu transakci obchodníkovi a konflikt minerům či jiným peers, aby obchodník vydal nevratné zboží dřív, než blok jednu variantu vybere. Výsledek závisí na propagaci, síťovém pohledu obchodníka, výběru minerů a čase předání. Více nezávislých posluchačů zlepší detekci, nevytvoří však deterministickou finalitu. Názvy race, Finney a Vector76 jsou modely scénářů, ne pole transakce ani různá konsenzuální pravidla. [Bitcoin Developer Guide — Payment Processing] [Karame et al. — Misbehavior in Bitcoin]
Finney-style útočník s možností těžit nejprve soukromě najde blok obsahující konflikt vracející hodnotu jemu, potom stejným UTXO zaplatí obchodníkovi zero-conf a po převzetí zboží skrytý blok zveřejní. Plán uspěje jen pokud blok zůstane použitelný a síť jej přijme dřív, než poctivý konkurenční blok zmaří přípravu; útočník riskuje block reward i náklady těžby. Čekání na zařazení obchodníkovy transakce do ověřeného bloku klasickou sekvenci ukončí, neodstraní však pozdější reorg risk. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Karame et al. — Misbehavior in Bitcoin]
Po potvrzení už konflikt nemůže platbu pouze vytlačit z mempoolu: alternativní platná větev musí platbu vynechat, zahrnout druhou útratu a získat více chainwork než aktivní chain příjemce. Reorg může vzniknout i bez podvodu při téměř současných blocích nebo incidentu software či sítě; úspěšným double-spendem vůči oběti je až získání hodnoty díky vítězství konfliktu. Bitcoin Core může u prohrané wallet transakce ukázat záporné confirmations a walletconflicts. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp] [Bitcoin Core RPC — gettransaction]
Podíl útočníkova hashrate, hloubka potvrzení a získatelná hodnota určují stochastický závod soukromé a poctivé práce. Pod 50 % neznamená nulovou šanci; trvalá většina výrazně zvyšuje možnost dohnání, ale minerům nedovolí padělat signatures, utrácet cizí UTXO, překročit issuance ani přinutit full nodes přijmout neplatný blok. Náklady zahrnují hashpower, energii, ušlé poctivé rewards, riziko prohry, likviditu a odhalení; příjem může zahrnout i market positions, takže pouhá cena pronájmu strojů nestačí. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Rosenfeld — Analysis of Hashrate-Based Double Spending] [Garay, Kiayias and Leonardos — The Bitcoin Backbone Protocol]
Každé další potvrzení nutí alternativní větev zopakovat více nahromaděné práce a za daných předpokladů snižuje pravděpodobnost úspěchu. Univerzální bezpečný počet neexistuje: káva, auto, burzovní deposit a nevratný withdrawal vystavují jinou hodnotu, motivaci i možnost nápravy. Často uváděných šest potvrzení je konvence, ne konsenzus. Policy má sledovat i rozložení hashrate, neobvyklé reorgy, důvěru v backend, eclipse risk a vratnost předání. [Bitcoin Developer Guide — Payment Processing] [Rosenfeld — Analysis of Hashrate-Based Double Spending]
Backend může na vlastním full nodu sledovat konfliktní mempool spends, volat gettxspendingprevout, číst walletconflicts, porovnávat active tip a upozornit na ztrátu confirmation. Více peers či nezávislých nodů snižuje slepá místa, ale absence zjištěného konfliktu je slabý důkaz: útočník jej může zadržet nebo poslat jinudy. Explorer ukazuje pohled vlastního uzlu a může mít zpoždění. Detekce dovolí zastavit výdej; nemůže minerům přikázat vítěze ani proměnit zero-conf v potvrzení. [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — gettxspendingprevout] [Karame et al. — Misbehavior in Bitcoin]
Pro onchain vypořádání validujte vlastním full nodem, svažte objednávku s přesným txid, outputs a částkou, nastavte hloubku podle možné ztráty, při reorgu či konfliktu zastavte plnění a oddělte připsaný zůstatek od vybratelného. Nepovažujte nepotvrzený change descendant za nezávislý na parentu. Lightning řeší rychlé opakované platby jinak: potvrzený funding outpoint ukotvuje kanál a commitment/revocation pravidla řídí offchain stav; zero-conf channel vědomě důvěřuje funderovi a funding double-spend risk nemaže. [BOLT 2 — Peer Protocol] [Bitcoin Optech — Zero-conf channels]
Pro nejúplnější obraz čtěte toto heslo společně s Transakce, Potvrzení, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. Opačným směrem na něj odkazují také Potvrzení, Replace-by-Fee (RBF), Problém byzantských generálů, Eclipse útok.