Błąd tkwił w implementacji reguły walidacji, nie w kryptografii ani harmonogramie emisji. Każde wyjście było dodatnie, ale ich suma wskutek przepełnienia stawała się ujemna. Różnica między wejściem a tym ujemnym wynikiem wyglądała następnie jak opłata. Wersja 0.3.10 dodała górne limity dla poszczególnych wyjść i sumy bieżącej; po reorganizacji na poprawioną gałąź wadliwy blok wypadł z aktywnej historii.
15 sierpnia 2010 roku deweloper Jeff Garzik zwrócił uwagę na dziwny blok 74 638. Transakcja 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 wydawała jedno wejście o wartości 0,50 BTC i tworzyła dwa ogromne wyjścia. Ówczesny wydruk printblock podaje dla każdego z nich 92 233 720 368,54275808 BTC. Nie ustalono wiarygodnie autora transakcji wykorzystującej błąd: publiczny zapis potwierdza jej dane, a nie tożsamość ani motyw twórcy. [1]
Bitcoin zapisywał wtedy kwoty jako 64-bitowe liczby całkowite ze znakiem w satoshi. Całkowita wartość każdego wyjścia, udokumentowana również szesnastkowo jako 0x7ffffffffff85ee0, była dodatnia i tuż poniżej maksimum int64. Ich suma 18 446 744 073 708 551 616 satoshi przekroczyła jednak zakres i zawinęła się do −1 000 000 satoshi. Stara walidacja akceptowała ten ujemny wynik przy porównaniu z wejściem. Był to błąd arytmetyczny, nie złamanie podpisów. Pierwszy zapis JSON w dyskusji ma inne końcowe cyfry po przecinku; do dokładnego obliczenia używamy tu wartości całkowitej potwierdzonej zarówno przez printblock, jak i zapis szesnastkowy. [1]
Ujemna suma wyjść −0,01 BTC przy wejściu 0,50 BTC dawała pozorną opłatę 0,51 BTC. Górnik pobrał więc w coinbase 50,51 BTC zamiast podstawowej nagrody 50 BTC. Po odjęciu wydanego wejścia i uwzględnieniu nadwyżki coinbase dwa ogromne wyjścia zwiększyły podaż wadliwej gałęzi dokładnie o 18 446 744 073 709 551 616 satoshi: 2^64 satoshi, czyli 184 467 440 737,09551616 BTC. Nie jest to zatem po prostu suma obu wyjść. [2]
Społeczność zareagowała publicznie pod presją czasu. Lfm nazwał błąd poważnym, Gavin Andresen zaproponował szybkie sprawdzanie każdego wyjścia względem 21 milionów BTC, a Satoshi Nakamoto opublikował szerszą poprawkę: odrzucać ujemne lub zbyt wysokie wyjście i po każdym dodaniu zbyt wysoką sumę bieżącą. Satoshi poprosił też górników o czasowe wstrzymanie, aby nowa prawidłowa gałąź mogła szybciej dogonić i zastąpić wadliwą. [2]
Satoshi ogłosił wersję 0.3.10 15 sierpnia 2010 roku o 23:48 czasu forum, około pięciu godzin i czterdziestu minut po zgłoszeniu Garzika. Zaktualizowane węzły uznały transakcję exploita i blok 74 638 za nieprawidłowe i budowały na ostatnim wspólnym poprawnym bloku. Ówczesne ogłoszenie podało później, że dobra gałąź wyprzedziła złą, więc klient mógł automatycznie się zreorganizować bez ręcznego usuwania plików blockchaina. [3]
Nie edytowano starego bloku w centralnej bazie danych. Istniały dwie konkurencyjne historie: stare węzły przyjmowały blok według pierwotnych reguł, a poprawione odrzucały go i uznawały wyłącznie pracę nad prawidłowym przodkiem. Gdy naprawiona gałąź zebrała więcej Proof of Work, sieć podążyła za nią, a blok inflacyjny opuścił aktywną historię; zdecydowały instalacja reguł przez użytkowników i górników oraz późniejsza praca, nie rozkaz administratora. [3]
Wprowadzona wtedy ochrona jest nadal widoczna w Bitcoin Core. CheckTransaction odrzuca ujemne wyjście, wyjście ponad MAX_MONEY i sumę bieżącą poza MoneyRange; kontrola po każdym dodaniu zapobiega przepełnieniu niebezpiecznej sumy przed porównaniem. Komentarz w kodzie wskazuje CVE-2010-5139, a osobna kontrola zduplikowanych wejść przypomina odmienny incydent CVE-2018-17144. [4]
Incydent pokazuje, że limit 21 milionów nie jest magiczną stałą chronioną samym hashowaniem: wymuszają go precyzyjne reguły walidacji i ich poprawna implementacja. Audyt powinien objąć zakresy wartości, bezpieczne dodawanie, coinbase i opłaty, kolejność kontroli, testy graniczne oraz zgodność niezależnych implementacji. Historia dowodzi zarazem zdolności wczesnej społeczności do szybkiej naprawy i jej ówczesnej zależności od niewielu deweloperów, górników i ręcznej koordynacji. [5]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Bitcoin Core, Reguły konsensusu, Transakcja, UTXO, Reorg, Soft Fork.
01Czy w prawidłowym Bitcoinie istniało kiedyś 184 miliardy BTC?+
Krótko istniały na wydobywanej wtedy wadliwej gałęzi jako skutek bloku exploita. Poprawione węzły odrzuciły tę gałąź, a prawidłowa ją zreorganizowała, dlatego ogromnych wyjść nie ma w dzisiejszym aktywnym blockchainie ani zbiorze UTXO. Historyczny incydent pozostaje udokumentowany przez blok i ówczesną reakcję.
02Czy incydent trwale złamał limit 21 milionów?+
Nie w historii uznawanej dzisiaj, bo poprawione reguły konsensusu odrzuciły wadliwy blok, a jego wyjścia zniknęły w reorganizacji. Zdarzenie pokazało jednak, że limit zależy od poprawnej walidacji i faktycznie uruchamianego oprogramowania; zapis w dokumentacji sam nie wymusza podaży.