Timewarp Attack to skoordynowana manipulacja znacznikami czasu w nagłówkach bloków, która zniekształca następne obliczenie trudności. Może ją obniżyć bez odpowiedniego spadku hashrate i przyspieszyć powstawanie bloków.
Bitcoin przelicza trudność co 2016 bloków, dążąc do średniej 10 minut między blokami. Odejmowany jest czas pierwszego bloku okresu od czasu ostatniego: obejmuje to tylko 2015 odstępów. Odstęp między ostatnim blokiem jednego okresu a pierwszym następnego nie mieści się w tych różnicach. Na tej granicy czas może się cofnąć, bez ciągłego połączenia obu okresów w obliczeniach. [4] [3]
Czas nowego bloku musi być większy niż Median Time Past (MTP), mediana czasów poprzednich 11 bloków. Nie musi jednak być późniejszy niż czas bezpośrednio poprzedzającego bloku. Atakujący mogą ustawiać większość czasów tylko 1 sekundę ponad MTP, ostatni blok okresu oznaczyć przybliżonym czasem rzeczywistym, a kolejny znów starszym. Manipulują nowymi blokami, zamiast przepisywać już potwierdzone nagłówki. [1]
Klasyczny scenariusz zakłada większość hashrate lub mniejszość z dodatkowym wpływem na kolejność bloków, na przykład przez Selfish Mining. Potrzebna jest długotrwała kontrola szeregu czasowego, a nie pojedynczy blok z nietypową datą. Przygotowanie klasycznego ataku trwa około miesiąca i pozostawia publicznie widoczne ślady w łańcuchu. [1]
W drugim atakowanym okresie czas może sugerować średnio 20 minut na blok, obniżając trudność mniej więcej o połowę. Kolejny okres jest wydobywany szybciej, lecz zmanipulowany czas znów wskazuje na potrzebę obniżki. Limit czterokrotnej zmiany w jednym przeliczeniu nie zatrzymuje powtórzeń. Teoretyczna długoterminowa granica wynikająca z MTP odpowiada około 6 blokom na sekundę; nie jest to obietnica praktycznej przepustowości sieci. [1] [3]
Szybsze bloki przesunęłyby pobieranie przyszłej subwencji blokowej do krótszego okresu; same nie zwiększają limitu 21 milionów BTC. Węzły musiałyby szybciej sprawdzać i przesyłać dane. Przeciążone procesory, niewystarczające łącza, konkurencyjne gałęzie i częste reorganizacje pogorszyłyby wiarygodność potwierdzeń. [1]
BIP 113 używa MTP poprzedniego bloku do oceny bezwzględnej blokady nLockTime określonej czasem. Blokady podane jako wysokość bloku nadal zależą od wysokości. Podczas ataku MTP może rosnąć znacznie wolniej niż czas rzeczywisty. Środki objęte warunkiem czasowym mogą pozostać niedostępne dłużej niż oczekiwano, a złożone protokoły utracić synchronizację etapów. [5] [1]
Propozycja ogranicza czas pierwszego bloku okresu: nie może być wcześniejszy od poprzedniego bloku o więcej niż 7200 sekund, czyli dwie godziny. Czas ostatniego bloku nie może też być mniejszy niż pierwszego. Specyfikacja ma status Complete. Oznacza to ukończenie propozycji, a nie jej aktywację: egzekwowanie nowych reguł konsensusu w mainnet wymaga osobnej aktywacji. [2]
Porównuj czas nagłówków, MTP, granice co 2016 bloków, rzeczywiste tempo wydobycia, trudność i hashrate. Rozróżniaj klasyczny atak i wariant Murch–Zawy oraz reguły testnetu i mainnetu. Program może zapobiegawczo tworzyć bezpieczniejsze szablony bloków; nie oznacza to, że cała sieć odrzuca każdy blok naruszający proponowaną ochronę. [3] [2]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Difficulty Adjustment, Wydobywanie, Proof of Work, Consensus Cleanup, Timelock, Reorg. Do tego hasła prowadzą również odsyłacze z Consensus Cleanup.
01Czy atak wymaga większości hashrate?+
Klasyczny scenariusz zakłada większość lub inną przewagę dającą potrzebny wpływ na kolejność bloków. Mniejszy górnik bez tej przewagi nie kontroluje dostatecznie ich czasów.
02Czy Median Time Past wystarczy do ochrony?+
Nie. MTP ogranicza poszczególne znaczniki czasu, lecz nie zamyka luki na granicy okresów. BIP 54 proponuje dodatkowe ograniczenia relacji między czasem pierwszego i ostatniego bloku.