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.
Domyślne minimalne stawki opłat spadają w Bitcoin Core 28.3: -blockmintxfee do 1 satoshi za kvB, a -minrelaytxfee i -incrementalrelayfee do 100 satoshi za kvB. Stawki portfela się nie zmieniają, a tańsze transakcje mogą się nie rozchodzić, dopóki nowe wartości nie upowszechnią się w sieci. Uprawnienia whitelist przestają też obowiązywać dla przychodzących połączeń onion (#33395).
FillBlock dostaje w Bitcoin Core 29.2 dwie poprawki P2P: sprawdzanie mutacji witnessa (#32646) i kontrolę pustego nagłówka przed wywołaniem (#33296). Podczas reorganizacji łańcucha reguły TRUC nie są już egzekwowane (#33504), a getblock i getblockheader przestają zwracać target czubka łańcucha (#33446).
Limity OP_RETURN w Bitcoin Core 30.0 praktycznie znikają: -datacarriersize ma domyślnie wartość 100 000, a jedna transakcja może zawierać wiele wyjść z danymi, choć -datacarriersize=83 przywraca dawny pułap. Domyślne stawki przekazywania spadają do 0,1 satoshi za vB, operacje podpisów legacy mają limit 2500 na standardową transakcję, a nowe polecenie bitcoin obudowuje istniejące pliki wykonywalne.
Bezwarunkowe logowanie na dysk ma w Bitcoin Core 29.1 limit 1 MiB na godzinę dla każdego miejsca w kodzie (#32604), a standardowe transakcje mogą zawierać najwyżej 2500 potencjalnie wykonywanych operacji podpisów legacy. Domyślne stawki przekazywania spadają do 100 satoshi za kvB, natomiast kompilacje 32-bitowe ograniczają -maxmempool do 500 MB, a -dbcache do 1 GiB.
Nieco ponad połowa zmian w Bitcoin Core 28.2 dotyczy procesu kompilacji. Guix notaryzuje teraz pakiet aplikacji na macOS i opatruje podpisem kodu wszystkie binaria dla macOS i Windows (#31407), a depends zyskuje poprawki kompilacji libevent na NetBSD (#31500) i freetype pod cmake (#32693).
Trzydziestu jeden współtwórców Bitcoin Core podpisało list, w którym czytamy, że oprogramowanie węzła nie powinno odmawiać przekazywania transakcji z trwałym popytem ekonomicznym, regularnie trafiających do bloków, bo użytkownicy i górnicy potrafią takie filtry obejść. Autorzy podkreślają, że nie popierają w ten sposób niefinansowego wykorzystania danych, a o wyborze oprogramowania i reguł decydują wyłącznie użytkownicy.
Lata nieprzerwanego spamu addr mogły przepełnić 32-bitowy identyfikator w menedżerze adresów Bitcoin Core i wywrócić węzeł. To pozostałość po ataku, który osłabiło już ograniczenie tempa w v22.0. Wersja 29.0 przechodzi na identyfikator 64-bitowy i zamyka CVE-2024-52919 o niskim stopniu zagrożenia. Błąd znalazł Eugene Siegel, zmianę wprowadził Martin Zumsande.
Obsługa UPnP znika z Bitcoin Core 29.0, a -natpmp działa teraz na wbudowanej implementacji PCP i NAT-PMP zamiast libnatpmp. Dochodzi nowa polityka ephemeral dust, poprawka podwójnie rezerwowanej wagi bloku wprowadza -blockreservedweight, a węzły proszą o brakujących rodziców każdego peera, który ogłosił transakcję osieroconą. Wersje 26.x i starsze dochodzą do etapu Maintenance End.
Z ustawionym -port Bitcoin Core 28.1 wylicza domyślny port nasłuchu onion jako ten port plus jeden, zamiast sztywnego 8334 na mainnecie. Kilka lokalnych węzłów znów może więc działać obok siebie bez kolizji przy starcie. Ręczne wpisy HiddenServicePort w torrc mogą wymagać zmiany. DecodeExtKey czyści także tajne dane (#31166).
Peer, który ogłosił blok, a potem zwlekał z jego wysłaniem, mógł zmusić węzeł Bitcoin Core do czekania nawet 10 minut, zanim ten poszukał go gdzie indziej, a napastnicy mogli ten trik powtarzać. CVE-2024-52922 o średnim stopniu zagrożenia zgłosił i naprawił Greg Sanders. Problem łagodzą v25.1 i v26.0, które mogą od razu poprosić o blok maksymalnie 3 peery compact block o wysokiej przepustowości.
Wersja 27.2 Bitcoin Core zamyka sytuację wyścigu w wykrywaniu połączeń z samym sobą (#30394) i poprawia wywołania FillPSBT, które błędnie zwracały complete=true (#30357). Wątek ładowania bloków i planista wyłączają się teraz w innej kolejności (#30435), a kod kompiluje się z miniupnpc 2.2.8 i GCC 15.
Zmutowane bloki od jednego peera mogły w Bitcoin Core przed v25.0 skasować stan pobierania u innych peerów ogłaszających ten sam blok, przez co węzeł zapominał o wciąż rekonstruowanym bloku kompaktowym. Problem zauważył Suhas Daftuar, a #27608 ogranicza każdego peera do jego własnego stanu. CVE-2024-52921 ma średni stopień zagrożenia.
Węzły z Bitcoin Core przed v25.0 można było wywrócić zdalnie, wysyłając powtórną wiadomość blocktxn dla jednego bloku, co naruszało asercję, że FillBlock działa tylko raz. Kolizja krótkich identyfikatorów nie była potrzebna: ta sama ścieżka otwierała się po dodaniu transakcji nieobecnych w korzeniu Merkle bloku. Niklas Gögge znalazł i naprawił ten błąd o wysokim stopniu zagrożenia, CVE-2024-35202.
Skok aktywności w sieci na początku maja 2023 roku, spotęgowany przez węzły szpiegowskie, spowolnił propagację bloków i transakcji, bo sortowanie rozdętych zbiorów inv-to-send pochłaniało niemal cały czas wątku P2P. Problem o średnim stopniu zagrożenia usunął w Bitcoin Core v25.0 #27610, który szybciej odrzuca transakcje nieobecne już w mempoolu i sprawniej opróżnia rosnące zbiory.
Testnet4 (BIP94) trafia do Bitcoin Core 28.0, a razem z nim ograniczone przekazywanie pakietów dla par 1-parent-1-child, standardowe transakcje TRUC według BIP 431 i nowy typ wyjścia Pay To Anchor. -mempoolfullrbf ma teraz domyślnie wartość 1, a libbitcoinconsensus znika po wycofaniu w 27.0.
Łańcuchy nagłówków o niskiej trudności mogły zdalnie wywracać węzły Bitcoin Core przed v24.0.1, a jeden spreparowany łańcuch nadawał się do użycia przeciwko dowolnemu węzłowi w sieci. Poprawka w #25717 każe węzłowi sprawdzić, czy łańcuch ma dość pracy, zanim go zapisze, co zakończyło też poleganie na punktach kontrolnych przy znanych atakach. Stopień zagrożenia: wysoki.
Zalew wiadomości addr mógł wywrócić węzeł Bitcoin Core: 2^32 wstawień do addrman przepełniało 32-bitowy licznik identyfikatorów i naruszało asercję. Błąd o wysokim stopniu zagrożenia zgłosił w 2021 roku Eugene Siegel, a poprawka Pietera Wuille'a weszła do v22.0.
Podszywając się w sieci lokalnej pod urządzenie UPnP, napastnik mógł zalewać węzeł Bitcoin Core rozdętymi odpowiedziami M-SEARCH aż do wyczerpania pamięci. Narażone były tylko węzły uruchomione z -miniupnp, bo domyślnie biblioteka jest wyłączona. Błąd o niskim stopniu zagrożenia naprawiono w v22.0.