Fork w sieci Bitcoin. Co tak naprawdę się stało i dlaczego?

Informowaliśmy wczoraj o konieczności aktualizacji klienta Bitcoin. Dzisiaj podajemy więcej szczegółów o sytuacji która miała miejsce.

 

 

Informowaliśmy wczoraj o konieczności aktualizacji klienta Bitcoin. Dzisiaj podajemy więcej szczegółów o sytuacji która miała miejsce.

 

W dniu wczorajszym wszedł w życie BIP066 który wprowadza ścisłą kontrolę sposobu zapisywania podpisów transakcji. Zmiana w protokole miała na celu zastąpienie używanej dotąd biblioteki OpenSSL która z powodów częstych aktualizacji i usuwania błędów nie zapewniała krytycznej dla Bitcoina wstecznej kompatybilności.

 

Pozostanie przy OpenSSL mogło w przyszłości doprowadzić do sytuacji, w której zaktualizowana biblioteka uniemożliwiłaby weryfikacje wcześniejszych (poprawnych) transakcji a nowo podpisywane mogły być uznawane za nieprawidłowe dla starszej wersji oprogramowania. Specyfikacja Bitcoin wymusza taką zgodność, stąd wprowadzenie jednolitego zapisu podpisów.

 

Gotowość do wprowadzenia BIP066 była zgłaszana przez kopalnie poprzez podanie nowego numeru wersji bloku: „3”. Czyli, jeśli kopalnia uaktualniła swoje oprogramowanie, zapisywała do właśnie wydobytego przez siebie bloku informację o tym fakcie. Dzięki tej operacji sieć miała informację o tym, że może bezpiecznie dokonać zmian a protokole gdyż większość kopalń posiada już oprogramowanie które jest zgodne z tą zmianą.

 

W momencie, gdy 950 z ostatnich 1000 bloków miało nowy numer wersji zmiana weszła w życie. Od tego momentu, zgodne z BIP066, wersje Core (0.10 i wyższe) weryfikowały nie tylko nowy numer wersji (musi być co najmniej 3) ale również czy wszystkie zawarte w bloku transakcje są podpisane w wymagany sposób. Core od wersji 0.9.5 również już generowało wszystkie transakcje w odpowiedni sposób.

 

Jednak pewna (niewielka) część transakcji krążących w sieci jest wysyłana z przestarzałych klientów, które nie trzymają się nowego formatu zapisu. Pomimo tego, że są one poprawne pod względem logicznym (sam podpis transakcji jest prawidłowy etc.) o tyle sposób zapisu odbiega od przyjętego właśnie standardu. Takie transakcje są już więc odrzucane przez nowe demony Core, nie są rozgłaszane ani przyjmowane do bloków.

 

Wczoraj gdy 95% bloków zostało już oznaczonych jako wersja “3” okazało się jednak, że (co najmniej) dwie kopalnie pomimo znakowania bloków jako “3” nie weryfikowały transakcji w nich zawartych. Oznaczało to, że po wejściu w życie BIP066 bloki takie były odrzucane przez aktualne wersje Core.

 

Powstaje pytanie, jak to się stało, że kopalnia zgłaszała nowe bloki jako aktualne mając starą wersję demona ?

 

Odpowiedź jest zaskakująca. Kopalnie w tym głównie chińska kopalnia F2Pool, zmodyfikowała swojego starego demona tak aby oznaczał bloki jako wersja “3”. To jednak nie wszystkie modyfikacje, kolejna umożliwiała nieweryfikowaniu bloku który jest w obecnej chwili przez pool kopany. Pobranie i zweryfikowanie bloku z sieci trwa około kilku sekund, w tym czasie kopalnia nie pracuje przez co nie zarabia. Niektóre kopalnie wpadły na pomysł aby nie weryfikować bloków dzięki czemu ich zysk może zwiększyć się o 1%.

 

Powstaje kolejne pytanie dlaczego kopalnie nie dokonały aktualizacji oprogramowania a następnie ponownej jego “nieuczciwej” modyfikacji ? Tu można tylko zgadywać, prawdopodobnie… z lenistwa. Ciężko doszukiwać się innego powodu.

 

Nieuczciwe praktyki kopalń doprowadziły do powstania bardzo długiego łańcucha bocznego (forka) w którym kopalnie te budowały kolejne po sobie bloki. Starsze wersje Core i inne programy niezgodne z BIP066 uznawały ten łańcuch za prawidłowy ponieważ był on najdłuższy. W tym samym czasie „dobre” kopalnie kopały równolegle bloki o tej samej wysokości.

 

W takiej sytuacji mogło dość do próby oszustwa na zasadzie „double spend” gdy odbiorca transakcji miał oprogramowanie niezgodne z BIP066. Atakujący mógł wykorzystać swoje monety wysyłając je dwukrotnie na różne adresy – raz w forku niezgodnym z BIP066 do odbiorcy którego chce oszukać i jednocześnie na inny adres w forku zgodnym. W czasie, gdy niezgodny fork był dłuższy odbiorca pomimo odczekania kilku potwierdzeń mógł faktycznie nie otrzymać monet. W momencie przełączenia się „starej” sieci na „nowy” łańcuch część transakcji ze starego łańcucha mogła być odrzucona.

 

Oczywiście, aby taki atak mógł się udać, atakujący musiałby przewidzieć taką sytuację, oraz wiedzieć, że dany odbiorca używa starego klienta co generalnie jest mało prawdopodobne.

 

Fork skończył się po kilku godzinach gdy kopalnie faktycznie zaktualizowały swoje wersje Core. Ponieważ nadal pojawiają się „stare” bloki wykopane w niezgodnych kopalniach, ilość osieroconych bloków będzie w najbliższych dniach zdecydowanie większa niż zwykle. Mogą też pojawić się kilku blokowe forki, gdy „stare” kopalnie będą budowały kolejne bloki po sobie.

 

Jeżeli używasz więc starszego oprogramowania warto je jak najszybciej zaktualizować, a w najgorszym przypadku czekać nie kilka a kilkanaście potwierdzeń przy otrzymywaniu środków.

 

Cała sytuacja była więc niegroźnym dla całej sieci i przypadkowym incydentem spowodowanym niekompetencją administratorów części kopalni. Developerzy Bitcoina mają nowy problem do rozwiązania jak bronić się przed tego rodzaju nieuczciwymi praktykami. Sami górnicy którzy kopią w nieuczciwych kopalniach powinni jak najszybciej zmienić je na inne skazując te na zapomnienie.

 

 

Fotografia na licencji Creative Commons: Flickr.com