Bitcoin Core opublikował oficjalne ujawnienie CVE-2025-62861 — luki o wysokim poziomie ryzyka w logice przekazywania transakcji oprogramowania węzła, która mogła sprawić, że operacje wydobywcze nadal liczyły na nieaktualnych szablonach bloków bez żadnego widocznego ostrzeżenia. Doradzenie uznaje badacza bezpieczeństwa Niklasa Goegge jako zgłaszającego problem i wywodzi go z reguły przekazywania, która zadziałała w złym momencie: podczas reorganizacji łańcucha, gdy powinna pozostać milcząca.

Dotknięte wersje obejmują Bitcoin Core od 28.0 do 28.2 oraz od 29.0 do 29.1. Poprawka trafiła do wydania w październiku 2025 roku, ale pełne szczegóły techniczne wstrzymano do listopada 2026 roku zgodnie z polityką skoordynowanego ujawniania projektu. Doradzenie nie wymienia żadnej awarii ani dotkniętego operatora; ekspozycja ma charakter historyczny. Sprzęt wydobywczy skierowany na węzeł w stanie uszkodzenia nadal by liczył, ale na ostatnim otrzymanym szablonie, więc nowe transakcje i ich opłaty pozostałyby niespłcone, dopóki ktoś by tego nie zauważył.

Jak reorganizacja może osierocić transakcję

Reorganizacja następuje, gdy węzeł porzuca swój aktualny czubek łańcucha na rzecz konkurującej, cięższej gałęzi. Transakcje w odłączonych blokach pozostają ważne, więc Bitcoin Core umieszcza je z powrotem w mempoolu — obszarze przechowywania niepotwierdzonych transakcji. Ponieważ te transakcje były już potwierdzone w ważnym bloku, węzeł dodaje je ponownie z flagą o nazwie bypass_limits, która wyłącza zwykłe kontrole antyspamowe i topologiczne. Celem jest wierne odtworzenie puli, a nie ponowna ocena transakcji, które przeszły już konsensus.

Jedną z kontroli, które powinny zostać wyłączone, dotyczy transakcji wersji trzeciej, czyli TRUC. Zgodnie z BIP 431 transakcja TRUC może mieć najwyżej jednego niepotwierdzonego rodzica i jedno niepotwierdzone dziecko. To polityka przekazywania, a nie reguła konsensusu: blok może legalnie zawierać rodzica TRUC z kilkoma dziećmi, mimo że żaden węzeł nie przyjąłby takiego kształtu do swojego mempoola z sieci. Ta sama granica między polityką a konsensem wyznaczyła granicę samego błędu: CVE-2025-62861 mógł zanieczyścić mempool węzła i zatrzymać jego produkcję szablonów, ale nie mógł stworzyć nieprawidłowego bloku ani zmienić reguł łańcucha.

Od wersji 28.0 Bitcoin Core egzekwuje limit jednego dziecka za pomocą mechanizmu zwanego sibling eviction. Gdy nowa transakcja dałaby rodzicowi TRUC drugie niepotwierdzone dziecko, węzeł traktuje istniejące dziecko jako kandydata do zastąpienia i, jeśli nowy uczestnik płaci wystarczająco dużo, usuwa je zgodnie z regułami replace-by-fee.

Błąd polegał na tym, że sibling eviction uruchamiał się nawet przy ustawionej fladze bypass_limits. Reorganizacja, która przywróciła rodzica TRUC z wieloma dziećmi — kształt całkowicie ważny wewnątrz odłączonego bloku — mogła wywołać usunięcie jednej przywróconej transakcji, pozostawiając w puli transakcje wydające jej wyjścia. Mempool zawierał wtedy dzieci, których rodzic już nigdzie nie istniał: ani w łańcuchu, ani w puli.

Poprawka Grega Sandersa uzależniła kontrole TRUC od flagi bypass_limits, więc eviction już nie uruchamia się podczas odtwarzania po reorganizacji. Powiązany pull request, PR #33504, dodał również scenariusz testowy, którego brakowało w pierwotnym kodzie: transakcje przychodzące z odłączonych bloków, a nie od peerów.

Jak wygląda zatrzymany szablon od strony wydobycia

Węzeł przekazuje pracę oprogramowaniu wydobywczemu przez getblocktemplate, które zestawia kandydata bloku, przepuszcza go przez własną kontrolę poprawności węzła i zwraca hash poprzedniego bloku, wybrane transakcje oraz następną wysokość. Przy transakcji bez rodzica w puli zestawiony kandydat nie przechodził tej kontroli, więc wywołanie nie mogło zwrócić świeżej pracy.

Z zewnątrz węzeł wyglądał na zdrowy:

• Proces działa
• Połączenia z peerami otwarte
• Czubek łańcucha się posuwa
• Mempool przyjmuje nowe transakcje

Co faktycznie było zepsute:

• Żądanie szablonu zwraca błąd
• Hashery nadal liczą na nieaktualnej pracy
• Na aktualnym czubku nie można znaleźć bloku
• Stan utrzymuje się do restartu węzła

Wszystko, co obserwuje ogólny panel monitoringu, pozostałoby zielone. Sieć również nie dawała sygnału: czubek łańcucha dalej się posuwał — bloki nadal były znajdowane, tylko nie przez tę operację — więc koszt spadał wyłącznie na zatrzymanego kopacza, w postaci liczenia, które nie mogło wytworzyć bloku na aktualnym czubku, oraz opłat, które w innym wypadku zebrałby. Jedyne, czego kopacz potrzebuje od węzła — aktualny szablon — było tym jednym, czego przestał dostarczać.

Restart, poprawka i koniec wsparcia

Restart węzła przeładowuje mempool z dysku w spójnym stanie, co usuwa objaw. Nic nie robi z przyczyną: następna reorganizacja z tym samym kształtem transakcji mogłaby ponownie zatrzymać węzeł.

Przyczyna została usunięta w trzech wydaniach. Wersja 30.0 trafiła na rynek z poprawką 10 października 2025 roku, a backporty pojawiły się w 29.2 i 28.3. Od prywatnego zgłoszenia do ostatniego z tych wydań minęły trzy tygodnie:

Obie gałęzie backportów opuściły od tego czasu wsparcie. Polityka utrzymania Bitcoin Core obejmuje trzy najnowsze wersje główne — obecnie 30.x, 31.x i 32.x — a gałąź 29.x osiągnęła koniec życia 27 października 2026 roku. Operator, który odpowiedział na pierwotną awarię wyłącznie restartem, uruchamia teraz nieobsługiwan kod, przy publicznym opisie dokładnie tego, jaki kształt transakcji go wywołuje.

Dlaczego doradzenie czekało 396 dni

Od pierwszego poprawionego wydania do szczegółowego doradzenia minęło 396 dni, a ujawnienie wylądowało dokładnie dwa tygodnie po zakończeniu życia gałęzi 29.x. Żadna z tych liczb nie jest przypadkowa. Polityka ujawniania Bitcoin Core wstrzymuje szczegóły o średnim i wysokim poziomie ryzyka do dwóch tygodni po tym, jak ostatnie dotknięte wydanie przestanie być wspierane, z wstępnym ogłoszeniem dwa tygodnie wcześniej, zsynchronizowanym z nową wersją główną.

Embargo obejmowało wyjaśnienie, nie kod. Pull request jest publiczny od 29 września 2025 roku, a noty wydania 28.3 i 29.2 wymieniały wówczas poprawkę mempoola. Prywatne przez rok pozostawało opracowanie łączące łatkę z odtwarzalnym zatrzymaniem wydobycia.

Polityka przewiduje szybszą ścieżkę. Błędy zaklasyfikowane jako łatwe do odkrycia — projekt definiuje je jako findalne przy minimalnym wysiłku — otrzymują natychmiastowe wydanie punktowe i doradzenie bez embarga. Ten przeszedł standardowy harmonogram, więc opiekunowie nie uznali go za trywialny do znalezienia. Został opublikowany tego samego dnia wraz z dwoma innymi doradzeniami o średnim i wysokim poziomie ryzyka, dotyczącymi zatrzymania przetwarzania bloków oraz błędu uprawnień Tor; wszystkie trzy zostały naprawione w tym samym cyklu wydawniczym z października 2025 roku. Każda kompilacja nowa enough, by zawierać łatkę mempoola, zawiera więc również dwie pozostałe poprawki.

Wolniejsza ścieżka ucieleśnia własne założenie: że operatorzy aktualizują się w rocznym oknie, tak że gdy wyzwalacz zostanie opisany publicznie, nikt podatny już nie słucha.

Co monitorować zamiast czasu pracy

Dla operacji wydobywczej użyteczną kontrolą nie jest to, czy węzeł żyje, ale jak stary jest jego ostatni udany szablon. Proces działający, połączony i zsynchronizowany może nadal przestać dostarczać pracę, i ten błąd był jednym z cichych sposobów, by to się stało. Wersja kompilacji należy do tej samej kontroli, ponieważ węzeł aktualny w szablonach dziś może być jutro poza wsparciem.

Źródła zapasowe szablonów wymagają tego samego pytania. Węzeł failover na tym samym wydaniu i z tą samą polityką mempoola trafiłby na tę samą reorganizację i to samo zatrzymanie; dwa działające procesy to nie dwa niezależne źródła pracy. Tylko węzeł na innej, poprawionej kompilacji utrzymałby operację w wydobyciu, i tylko operator, który przetestował to pod symulowaną reorganizacją, wiedziałby o tym z wyprzedzeniem.