Podpisywanie w Bitcoin Core 26.2 nie zakłada już, że TapMiniscript jest poprawny (#29853), getnetworkhashps zgłasza błąd przy nieprawidłowych parametrach (#28554), a setmocktime ma egzekwowaną wartość maksymalną (#29869). Kompilacja działa też z miniupnpc 2.2.8.
Przed Bitcoin Core 0.10.1 odbierane wiadomości mogły mieć 32 MiB, więc napastnik mógł wymusić alokację takiej ilości RAM na każde połączenie i ewentualnie wywrócić węzeł. Zgłosił to użytkownik Bitcointalk o nicku Evil-Knievel; #5843 obniżył limit do 2 MiB, później podniesiony do 4 MB ze względu na Segwit. Ujawnienie zapowiedziane na 2015 rok przełożono, a szczegóły wyszły na światło dzienne w 2024 roku.
Dzięki IPv6 niewielkim kosztem dało się rozdąć nieograniczoną listę banów w Bitcoin Core, a każda wiadomość GETADDR wymuszała potem jej przeszukanie dla każdego zwracanego adresu, a tych mogło być do 2500. Awarię pamięci i drenaż procesora, ocenione na wysoki stopień zagrożenia, usunął #19219, wydany w 0.20.1 i 0.21.0.
Dwa błędy w obsłudze wiadomości version, przepełnienie liczby ze znakiem i błąd logiczny w abs64, pozwalały napastnikowi przesunąć skorygowany czas ofiary tak, że odrzucała nowe bloki jako datowane zbyt daleko w przyszłość. Napastnik musiał znaleźć się wśród pierwszych 200 peerów, które się połączyły. Lukę o średnim stopniu zagrożenia usunięto w Bitcoin Core 0.21.0.
Fałszywy link płatności BIP72 mógł wywrócić Bitcoin-Qt: jego parametr r wskazywał ogromny plik, a program próbował zaalokować na niego pamięć, podczas gdy pobieranie po cichu trwało w tle. Błąd o średnim stopniu zagrożenia zniknął, gdy #17165 usunął obsługę BIP70, co trafiło do 0.20.0.
Spreparowane transakcje osierocone, nieprawidłowe, ale kosztowne w walidacji, mogły zatrzymać węzeł na wiele godzin, bo każda nowo przyjęta transakcja uruchamiała kwadratowe przeszukiwanie pamięci podręcznej sierot. #15644 Pietera Wuille'a przerywa tę pracę, gdy tylko znajdzie się dopasowanie, i przechodzi do nowych wiadomości. Poprawka błędu o wysokim stopniu zagrożenia dotarła do użytkowników w Bitcoin Core 0.18.0.
Źle sformowana wiadomość GETDATA mogła w Bitcoin Core przed 0.20.0 zostawić wątek net_processing kręcący się na 100% CPU i dokładać 1,5 MB pamięci na każdego atakującego peera. Inne peery nadal były obsługiwane, stąd niski stopień zagrożenia. John Newbery znalazł błąd i naprawił go w #18808.
Nagłówki zbudowane bezpośrednio na bloku genesis, wymagające tylko trudności 1, od Bitcoin Core 0.12.0 aż do 0.15.0 prześlizgiwały się przez logikę punktów kontrolnych. Spamer mógł więc bez ograniczeń powiększać mapBlockIndex i ewentualnie wywrócić węzeł z braku pamięci. Błąd o średnim stopniu zagrożenia zgłosił w 2017 roku Cory Fields, a zamknął go #11028.
Jedna wiadomość INV z 50 000 pozycji bloków mogła zmusić węzeł do ustawienia w kolejce 50 000 odpowiedzi getheaders po około 1 kB każda, a peer, który ich nie odczytywał, utrzymywał ten bufor wysyłania o wielkości 50 MB pełny. #18962 Johna Newbery'ego, przedstawiony jako oszczędność pasma, wysyłał jedno GETHEADERS na INV i trafił do 0.20.0.
Napastnik wstrzymywał odpowiedzi GETDATA, a potem spamował fałszywymi ogłoszeniami, aby usunąć transakcję z 50-tysięcznej mapy g_already_asked_for. Mógł ją wtedy ogłaszać raz za razem, a ofiara nie prosiła o nią nikogo innego. Błąd o średnim stopniu zagrożenia ujawnił John Newbery, a naprawił Pieter Wuille w #19988, wydanym w Bitcoin Core 0.21.0.
Drugie przepełnienie bufora w miniupnpc, które znalazł Wladimir J. Van Der Laan, ujawniało dane i dało się połączyć z CVE-2015-6031 w zdalne wykonanie kodu, co zademonstrował na miniupnpc 1.6-precise z Ubuntu. Jego exploita nie dało się bezpośrednio przenieść na Bitcoin Core, a poprawka trafiła do wersji 0.12 w lutym 2016 roku.
Bitcoin Core 27.1 to same poprawki błędów: działa już podbijanie opłaty w GUI dla niepodpisanych transakcji, pole adresu IP proxy nie przyjmuje portu, a GetAddedNodeInfo() wykrywa peery CJDNS z addnode (#30085). Zmienia się też obsługa TapMiniscript przy podpisywaniu (#29853).
Transport BIP324 v2 jest w Bitcoin Core 27.0 domyślnie włączony, a nowy algorytm CoinGrinder szuka najlżejszego zestawu wejść przy stawkach od 30 sat/vB. Czas skorygowany przez sieć ustępuje w kodzie konsensusu czasowi systemowemu, więc dokładny zegar ma dla operatorów większe znaczenie. libbitcoinconsensus zostaje wycofywany, a jego usunięcie zaplanowano na v28.
Węzły z Bitcoin Core 25.2 przestają przetwarzać zmutowane bloki (#29412). Aktualizacja usuwa też segfault w getrawtransaction (#29003), use-after-free w WalletBatch::EraseRecords (#29176) oraz awarię GUI po wybraniu opcji „Mask values”.
Sesje I2P w Bitcoin Core 26.1 korzystają zarówno z szyfrowania ECIES-X25519, jak i ElGamal (#29200), a węzeł loguje postęp podczas wczytywania mempoolu. Wśród poprawek są odmowa przetwarzania zmutowanych bloków (#29412) oraz portfel, który pomija wybór monet BnB przy włączonym SFFO (#28994).
Eksperymentalny transport BIP324 v2 debiutuje w Bitcoin Core 26.0: domyślnie wyłączony, włącza się go opcją -v2transport. Nowe RPC loadtxoutset wczytuje migawki assumeutxo i daje działający węzeł w kilka minut, podczas gdy oryginalny chainstate kończy walidację w tle. Z kolei submitpackage wysyła surowe transakcje do mempoolu jako pakiet.
Nieaktualne szacunki opłat nie są już serwowane przez Bitcoin Core 24.2 (#27622), a RPC poprawnie obsługuje nieprawidłowe adresy bech32 (#27727). Większość pozostałych zmian dotyczy systemu kompilacji i CI, w tym poprawka budowania pakietu Qt na macOS z linkerem Xcode 15 (#28543).
Równoległe pobieranie bloków kompaktowych trafia do Bitcoin Core 25.1 (#27626). Pozostałe poprawki obejmują awarię REST na /deploymentinfo (#27853), wyłączanie serwera po rozłączeniu zdalnego klienta (#28551) i migrację portfeli, która odrzuca teraz nieprawidłowe skrypty (#28125).
Ponowne skanowanie portfeli deskryptorowych przyspiesza w Bitcoin Core 25.0, gdy kompaktowe filtry bloków BIP158 są dostępne przez -blockfilterindex=1, a nowe RPC scanblocks przeszukuje te filtry. Polityka przekazywania akceptuje teraz transakcje od 65 bajtów bez witnessa. W trybie -blocksonly maksymalna pamięć mempoolu spada z 300 MB do 5 MB.
Trzon Bitcoin Core 23.2 stanowią trzy zmiany w P2P: koniec z uszkadzaniem peers.dat (#26909), koniec z przedwczesnym czyszczeniem stanu pobierania innych peerów (#27608) i szybsze kolejki inv-to-send (#27610). Reszta to prace nad kompilacją i CI, na przykład budowanie bdb przez clang-16 na aarch64.