Timewarp Attack je koordinovaná manipulace časovými údaji v hlavičkách bloků, která zkreslí výpočet další obtížnosti. Útok může obtížnost snižovat bez odpovídajícího poklesu hashratu, a tím urychlovat vznik bloků.
Bitcoin přepočítává obtížnost po 2016 blocích a míří na průměr 10 minut mezi bloky. Výpočet odečte čas prvního bloku období od posledního: zahrne tedy jen 2015 intervalů. Interval mezi posledním blokem jednoho období a prvním blokem dalšího se do těchto rozdílů nevejde. Právě na této hranici lze čas vrátit zpět, aniž by jej výpočet obou období souvisle propojil. [4] [3]
Nový blok musí mít čas větší než Median Time Past (MTP), medián časů předchozích 11 bloků. Nemusí však být novější než bezprostředně předchozí blok. Útočníci mohou většinu časů posouvat jen o 1 sekundu nad MTP, poslední blok období označit přibližně skutečným časem a další opět starším. Nemění přitom již potvrzené hlavičky; manipulují časy nově těžených bloků. [1]
Klasický scénář počítá s většinou hashratu, případně s menšinou, která získá další vliv na pořadí bloků například pomocí Selfish Mining. Je potřeba dlouhodobě ovládat časovou řadu, nikoli vytěžit jediný blok s neobvyklým časem. Rozjezd klasického útoku zahrnuje přibližně měsíc přípravy, jejíž stopy jsou veřejně viditelné v řetězci. [1]
Ve druhém napadeném období mohou časy vyvolat dojem průměrných 20 minut na blok, a obtížnost tak přibližně klesne na polovinu. Další období se vytěží rychleji, ale zmanipulované časy opět požadují snížení. Limit čtyřnásobné změny při jednom přepočtu opakování nezastaví. Teoretický dlouhodobý limit z pravidla MTP odpovídá přibližně 6 blokům za sekundu; není to příslib praktické propustnosti sítě. [1] [3]
Rychlejší bloky by přesunuly čerpání budoucí blokové dotace do kratší doby; samy o sobě nezvyšují limit 21 milionů BTC. Uzly by musely rychleji ověřovat data a přenášet je po síti. Přetížené procesory, nedostatečné připojení, konkurenční větve a časté reorganizace by zhoršily spolehlivost potvrzení. [1]
BIP 113 používá MTP předchozího bloku při vyhodnocení absolutního časového zámku nLockTime zadaného časem. Zámek zadaný výškou bloku se nadále řídí výškou. Při útoku se MTP může posouvat mnohem pomaleji než skutečné hodiny. Peníze v časově vázané smlouvě tak mohou zůstat nedostupné déle, než účastníci čekali; u složitějších postupů může selhat návaznost jednotlivých kroků. [5] [1]
Návrh omezuje čas prvního bloku období: nesmí být o více než 7200 sekund, tedy dvě hodiny, starší než předchozí blok. Čas posledního bloku období zároveň nesmí být menší než čas prvního. Specifikace má stav Complete. To označuje dokončení návrhu, nikoli jeho aktivaci: k vynucování nových konsenzuálních pravidel na mainnetu je zapotřebí samostatná aktivace. [2]
Při kontrole porovnávejte časy hlaviček, MTP, hranice po 2016 blocích, skutečné tempo těžby, obtížnost a hashrate. Rozlišujte klasický útok a variantu Murch–Zawy, pravidla testnetu a mainnetu. Software může preventivně vytvářet bezpečnější šablony bloků; to ještě neznamená, že celá síť odmítne všechny bloky porušující navrženou ochranu. [3] [2]
Pro nejúplnější obraz čtěte toto heslo společně s Difficulty Adjustment, Těžba, Proof of Work, Consensus Cleanup, Timelock, Reorg. Opačným směrem na něj odkazují také Consensus Cleanup.
01Vyžaduje útok většinu hashratu?+
Klasický scénář předpokládá většinu, nebo jinou výhodu poskytující potřebný vliv na pořadí bloků. Menší těžař bez takové výhody nemá dostatečnou kontrolu nad jejich časy.
02Nestačí ochrana pomocí Median Time Past?+
Nestačí. MTP omezuje jednotlivé časy, ale neuzavírá mezeru na hranici období. BIP 54 navrhuje další omezení vztahu mezi časy prvního a posledního bloku.