Trwa dyskusja o TCP hole punchingu, który ma umożliwić osiągalność domowych węzłów za routerami. Wydanie omawia też projekt BIP standaryzujący zasady wydawania środków egzekwowane przez współsygnatariuszy przy emulacji covenantów.
Do gospodarzy Optech dołączają Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov i Nishant Bansal. Omówienie #429 zaczyna się od Bitcoin Core #36665, #36667 i #36669, po czym przechodzi do zaktualizowanej polityki bezpieczeństwa. Później mowa o wielostronnych silent payments, ujawnionej luce DoS w Core Lightning i Eclair 0.14.6; transkrypcja jeszcze się nie ukazała.
Ogłoszenie kanału z tym samym węzłem na obu końcach mogło wywracać Core Lightning w wersjach od 25.02 do 26.04 przy każdym restarcie, a napastnika kosztowało tylko opłaty onchain; poprawka trafiła do 26.04.1. Oprócz tej luki newsletter #429 opisuje protokół Oleksandra Kurbatova dla wielostronnych wejść silent payments i szybsze wydania poprawkowe Bitcoin Core przy łatwych do wykrycia błędach.
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.
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.
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.
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.