Sieć peer-to-peer: przekazywanie, propagacja, węzły i warstwa Lightning.
14 publikacji
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.
Bitcoin Core
Pozorując połączenia węzła z samym sobą, napastnik mógł rozdymać logi Bitcoin Core: wystarczyło użyć tego samego nonce z wiadomości version w wielu połączeniach. Pierwsze połączenie ofiary domyślnie wygasa po 60 sekundach, więc zapełnienie dysku trwałoby długo, stąd niski stopień zagrożenia CVE-2025-54604. Niklas Goegge zgłosił lukę w 2022 roku, a kończy ją ograniczenie tempa logowania w 29.1 i 30.0.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
Ł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.
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
Ź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.
Bitcoin Core
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.
Bitcoin Core
Użytkownicy Tora mogą już wejść na stronę Bitcoin Core przez adres onion, o co często proszono. Ukryta usługa to dodatkowa droga obejścia cenzury i ścieżka zaufania, która nie zależy ani od urzędów certyfikacji, ani od DNS.
Bitcoin Core
Peery korzystające z przekazywania bloków kompaktowych (BIP152) wymieniają szkic każdego nowego bloku, około 9 KB dla przeciętnego bloku 1 MB, plus narzut na transakcje, których odbiorca nie ma. W eksperymentach na żywo w trybie wysokiej przepustowości, z maksymalnie 6 wstępnie wypełnionymi transakcjami, znacznie ponad 90% bloków rozeszło się bez dodatkowego żądania.
Bitcoin Core
