Wszystko, co zebrano z oficjalnych źródeł.
141 publikacji
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.
Bitcoin Optech
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.
Bitcoin Optech
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.
Bitcoin Optech
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.
Bitcoin Core
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
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.
Bitcoin Core
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.
Bitcoin Core
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).
Bitcoin Core
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.
Bitcoin Core
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.
Bitcoin Core
Adam Gibson opowiada o Lichen, swojej warstwie 2 z jednym emitentem i jednostronnymi wyjściami weryfikowanymi przez BitVM. Program #428 prowadzą Gustavo Flores Echaiz i Brandon Black, a pozostali goście to João Dias i Vincenzo Palazzo. W rozmowie pojawiają się też składnia deskryptorów dla preobrazów haszy, rbitcoin 0.8.0 i LND v0.21.5-beta.rc1.
Bitcoin Optech
Lichen, projekt Adama Gibsona, pozwala użytkownikom warstwy 2 z jednym emitentem odzyskać bitcoiny onchain, gdy hub odmawia współpracy albo znika z sieci. Spory rozstrzygają dowody Groth16 i wstępnie podpisane transakcje BitVMX. Drugi temat newslettera #428 to propozycja João Diasa dotycząca prywatnej formy preobrazu we fragmentach haszy w miniscripcie, a wśród aktualizacji oprogramowania są Ibis Wallet v5.0-beta i rbitcoin 0.8.0.
Bitcoin Optech
Dwa błędy pamięci w Eclair, ukryte w procedurze otwierania kanału, wyjaśnia w omówieniu #427 Erick Cestari: jeden wyłapał fuzzer Matta Morehouse'a, drugi znaleziono z pomocą modelu LLM. Adam Gibson przedstawia następnie LN-GAP, a jako przykład podaje partię szachów rozgrywaną wewnątrz kanału Lightning. W dalszej części audycji mowa o Bitcoin Core 32.0rc4 i serii poprawek do Eclair.
Bitcoin Optech
Eclair v0.14.0 i starsze można było pozbawić pamięci podczas otwierania kanału: jeden błąd powodował wyciek około 1 MB na sekundę, a drugi wyczerpywał 4 GB w około 48 minut przez jedno połączenie, bez kosztów onchain. Oba usunięto w v0.14.1. Newsletter #427 omawia je obok LN-GAP, schematu Adama Gibsona dla wielorundowych kontraktów w kanałach Lightning, który opiera się na komitecie z uczciwą większością.
Bitcoin Optech
Clara Shikhelman otwiera omówienie #426 tematem Shielded Bitcoin, współtworzonej przez siebie propozycji przesyłania bitcoinów bez ujawniania nadawcy, odbiorcy i kwot, bez zmian w konsensusie i bez operatorów. Elias Rohrer ze Spiral bierze potem na warsztat wydania LDK v0.3-rc3 i v0.2.7 oraz zmiany w kodzie LDK. Program prowadzi Gustavo Flores Echaiz.
Bitcoin Optech
Metaprotokół Shielded Bitcoin, zaproponowany przez Mishę Komarova wraz z Clarą Shikhelman i Aleksiejem Moskvinem, ma umożliwić prywatne przelewy onchain bez zmiany konsensusu. Wymaga jednak jednorazowej ceremonii konfiguracyjnej i zostawia ślad przy wejściu i wyjściu. Anthony Towns szkicuje BIP, dzięki któremu peery same wybiorą jednobajtowe identyfikatory wiadomości w transporcie BIP324, a Fabian Jahr pyta, czy tagi w tagowanych haszach powinny zawierać numery BIP.
Bitcoin Optech
Parser bitów funkcji w Eclair alokował ponad 300 MB przy obsłudze jednej wiadomości o maksymalnej długości, mówi w omówieniu #425 Matt Morehouse; po poprawce jest to około 200 KB. Gustavo Flores Echaiz i Brandon Black przechodzą dalej do synchronizacji etykiet portfeli, typów wyjść PQC, granic time warp w BIP54 i propozycji kowenantów dla skarbców.
Bitcoin Optech
Zapytanie gossip o wielkości 64 kB mogło w Eclair v0.13.1 i starszych urosnąć do 64 MB, a wiadomość init o maksymalnej długości przemielić około 300 MB. Oba błędy DoS ujawnił Matt Morehouse, a usunięto je w v0.14.0. Jakub sprawdza, czy ktoś chciałby synchronizować etykiety portfeli BIP329 przez niezaufany magazyn, a dział konsensusu w newsletterze #425 wraca do postkwantowych typów wyjść.
Bitcoin Optech
Ahmet Kurt objaśnia PQLN, czyli bezpieczeństwo postkwantowe powierzchni offchain w Lightning, w pierwszym nagranym wcześniej fragmencie programu Optech. Część na żywo prowadzą Gustavo Flores Echaiz i Mike Schmidt, a dołącza do nich Jan B, współtwórca Bitcoin Core, który recenzuje PR-y i pracuje nad kodem jądra. W planie są Bitcoin Core 32.0rc2 i przewodnik po jego testowaniu.
Bitcoin Optech
PQLN, dzieło Ahmeta Kurta i współpracowników, zabezpiecza przed komputerami kwantowymi gossip, transport, faktury, oferty i onion w Lightning. Operacji onchain nie rusza, bo te wymagałyby zmiany konsensusu. Ceną jest przepustowość: węzeł pobiera 10 razy i przechowuje 9 razy więcej danych, a podpis ML-DSA zajmuje zaledwie 0,33 ms. Działającą implementację w rust-lightning można testować już teraz.
Bitcoin Optech
