Górnik mógł rozdmuchać plik undo Bitcoin Core ponad 4 GiB. Przekręcają się wtedy 32-bitowe pozycje, dane ulegają uszkodzeniu, a przy odpowiedniej reorganizacji łańcucha węzły się wyłączają; Windows i systemy 32-bitowe zawodzą już przy 2 GiB, bez żadnej reorganizacji. CVE-2026-117346 ma niski stopień zagrożenia i wymagałaby mniej więcej miesiąca wszystkich bloków w sieci. Wersje 32.1, 31.2, 30.4 i 29.5 naprawiają systemy 64-bitowe, ale węzły 32-bitowe i bloki trzymane na FAT32 pozostają podatne.
Monitorowanie wyjątków gniazd działa w Bitcoin Core 29.5 tak samo w poll() i select() (#36665), a peery ze wstrzymanym wysyłaniem podlegają egzekwowanemu limitowi czasu (#36667). Pozycje flatfile przechodzą na liczby 64-bitowe (#36669), węzły zakładają v2transport dla adresów z seedów, a jeden seed DNS znika z listy.
Złośliwy peer, który udawał brak obsługi pingów z BIP 31, unikał rozłączenia po 20 minutach i czytał powoli. Kolejka wysyłania rosła wtedy o maksymalnie 2 MB na godzinę dla każdego peera przychodzącego i 5 MB dla wychodzącego. CVE-2026-117349 o średnim stopniu zagrożenia usuwa #36667 w Bitcoin Core 32.1, 31.2, 30.4 i 29.5; węzły -blocksonly były znacznie mniej narażone.
Węzły na Windowsie, macOS i BSD mógł wywrócić połączony peer, wysyłając pilne dane TCP: omijały one wstrzymany odczyt w backendzie select() i bez końca zajmowały pamięć (CVE-2026-117350). Linuksa błąd nie dotyczy, bo węzły korzystają tam z poll(). Lukę o średnim stopniu zagrożenia, którą wykrył skan modelem LLM w ramach Project Loupe, usuwają Bitcoin Core 32.1, 31.2, 30.4 i 29.5.
Bity 5–28 z BIP 9 nie są już w Bitcoin Core 30.4 traktowane jako sygnały soft forków. Zgodnie z BIP 323 ustawiające je bloki przestają wywoływać ostrzeżenia o nieznanym wdrożeniu (#34779). W warstwie sieciowej doszedł egzekwowany limit czasu dla peerów ze wstrzymanym wysyłaniem (#36667), a pozycje flatfile zapisywane są teraz jako liczby 64-bitowe (#36669).
Prywatne rozgłaszanie dostaje w Bitcoin Core 31.2 górny limit. Kolejka transakcji, których sieć jeszcze nie odesłała, kończy się na 10 000 pozycji, a po zapełnieniu odrzuca nowe zgłoszenia i trzeba ją opróżnić poleceniem abortprivatebroadcast (#35406). Zgodnie z BIP 323 bity wersji 5–28 przestają się liczyć jako sygnały soft forków.
Prywatne rozgłaszanie w Bitcoin Core 32.1 nie grozi już ujawnieniem adresu IP nadawcy. Do wycieku mogło dojść, gdy po nieudanym połączeniu v2 ponowna próba przez v1 szła bezpośrednio, a nie przez Tor. Domyślne -maxconnections rośnie ze 125 do 200, a przekazywanie wychodzących transakcji ogranicza teraz globalna kolejka zamiast limitu na peera.
Duże obciążenie dysku odczytami i zapisami w normalnej pracy miało swoje źródło w błędzie usuniętym w Bitcoin Core 29.4: baza chainstate ciągle przepisywała spore swoje fragmenty. Poprawka wyłącza seek compaction w LevelDB i regularnie kompaktuje chainstate (#35465).
Koniec z mieleniem dysku przez chainstate. Bitcoin Core 30.3 usuwa też awarię feebumpera przy niedostępnej łącznej opłacie podbijającej (#34870) i błąd w wyborze monet, który liczył kwotę jako wartość logiczną (#34888). Po stronie PSBT klucze publiczne MuSig2 są teraz sprawdzane podczas deserializacji pubnonce i podpisów częściowych (#34219).
Wyciek adresu IP w -privatebroadcast został w Bitcoin Core 31.1 zamknięty: część połączeń szła przez clearnet zamiast przez włączoną sieć zapewniającą prywatność. Aktualizacja kończy też przepisywanie chainstate, które nadmiernie obciążało dysk, i odrzuca pustą listę kluczy publicznych przy agregacji kluczy MuSig2 (#35316).
Nieudany handshake v2 może w Bitcoin Core 31.0 zdradzić adres IP nadawcy: przy ustawionym -privatebroadcast ponowna próba przez v1 omija proxy Tor i łączy się z peerem bezpośrednio. Najbardziej prawdopodobny wyzwalacz to złośliwy peer, który celowo zamyka handshake. Do czasu wydania 31.1 można wyłączyć tę funkcję, ustawić -v2transport=0 albo kierować wychodzący ruch IPv4/IPv6 przez Tor.
Wydania Bitcoin Core po 0.14.0 i przed 29.0 mogły podczas walidacji spreparowanego, nieprawidłowego bloku odczytać zwolnioną pamięć i wywrócić węzeł. CVE-2024-52911 ma wysoki stopień zagrożenia, choć napastnik musi wydać prawidłowy proof-of-work na czubku łańcucha, a zdalne wykonanie kodu uznano za mało prawdopodobne. Błąd zgłosił Cory Fields, poprawkę zawiera 29.0.
Cluster mempool zastępuje w Bitcoin Core 31.0 dotychczasową konstrukcję: limity przodków i potomków ustępują klastrom o maksymalnie 64 transakcjach i 101 kB, a CPFP carveout znika. Domyślne -dbcache rośnie do 1024 MiB na maszynach z co najmniej 4096 MiB RAM, a nowa opcja -privatebroadcast wysyła transakcje z sendrawtransaction wyłącznie przez Tor lub I2P.
Dwie awarie związane z portfelami bez nazwy mają poprawki w Bitcoin Core 28.4: migracja starszych portfeli (#34156) oraz createfromdump, które przy niepowodzeniu kasowało katalog portfeli (#34215). Z chainparams usunięto też jeden seed DNS (#33723).
Peery przesyłające transakcje niezgodne z konsensusem nie są już w Bitcoin Core 29.3 karane (#33050). Walidacja zyskuje pamięć podręczną midstate sighash dla każdego wejścia w skryptach legacy, P2SH i segwit v0 (#32473) oraz wykrywa usuwanie witnessa bez ponownego uruchamiania sprawdzeń Script (#33105). Z addPackageTxs w kodzie górnika znika przepełnienie liczby bez znaku (#33475).
Bitcoin Core 30.2 usuwa błąd migracji starszych portfeli bez nazwy (#34156), a createfromdump nie kasuje już katalogu portfeli, gdy zawiedzie na takim portfelu (#34215). Naciśnięcie Ctrl-C przestaje też zawieszać program podczas oczekujących wywołań IPC (#33511).
W rzadkich okolicznościach nieudana migracja wallet.dat w Bitcoin Core 30.0 lub 30.1 może usunąć wszystkie pliki z katalogu portfeli, co naraża środki. Deweloperzy wycofali te binaria i proszą, by do czasu 30.2 nie migrować portfeli przez GUI ani RPC. Do wystąpienia błędu potrzebny jest domyślny, nienazwany wallet.dat, którego nie da się zmigrować lub wczytać; pozostałych użytkowników problem nie dotyczy.
Portfele w Bitcoin Core 30.1 przestają brać pod uwagę niepotwierdzone monety TRUC mające przodków (#33528). W IPC opcje nie wymagają już argumentu -m (#33229), rejestrowanie wiadomości kosztuje mniej (#33517), a trwające wywołania waitNext można anulować (#33676).
Spreparowane niestandardowe transakcje mogły zajmować węzeł Bitcoin Core na kilka sekund każda, a nadawca nie był rozłączany. Napastnik mógł w ten sposób opóźniać propagację bloków. CVE-2025-46598 o niskim stopniu zagrożenia zgłosił Antoine Poinsot, a v30.0 łagodzi problem, skracając czas walidacji w najgorszym przypadku.
Bloki powyżej 1 GB mogły przepełnić sprawdzenie rozmiaru w 32-bitowych węzłach Bitcoin Core i wywrócić je przy zapisie na dysk. Działało to jednak tylko dla bloku kompaktowego i tylko wobec ofiary z -maxmempool powyżej 3 GB i 1 GB transakcji w mempoolu. CVE-2025-46597 o niskim stopniu zagrożenia znalazł Pieter Wuille; zamknęło ją ograniczenie -maxmempool na systemach 32-bitowych w 29.1 i 30.0.
