Biuletyn Bitcoin Optech nr 430

W tym tygodniu w biuletynie podsumowano trwającą dyskusję na temat wykorzystania techniki „TCP hole punching” w celu zapewnienia dostępności węzłów znajdujących się za routerami domowymi oraz opisano projekt BIP dotyczący standaryzacji zasad wydatkowania, które współpodpisujący egzekwują podczas emulacji klauzul umownych. Znajdują się tu również nasze stałe rubryki podsumowujące propozycje i dyskusje dotyczące zmiany zasad konsensusu w sieci Bitcoin, ogłaszające nowe wersje i wersje kandydackie oraz opisujące istotne zmiany w popularnym oprogramowaniu infrastruktury Bitcoin.

Aktualności

● Kontynuacja dyskusji na temat TCP hole punching dla węzłów domowych: W nawiązaniu do

naszego majowego podsumowania wątku 0xB10C „Delving Bitcoin” dotyczącego wykorzystania „hole punching” w celu umożliwienia węzłom znajdującym się za routerami domowymi akceptowania połączeń między sobą, 0xB10C poinformował, że wznowiono prace nad specyfikacją oraz eksperymentalną implementacją w Bitcoin Core. Węzły domowe zazwyczaj mogą nawiązywać jedynie połączenia wychodzące, a domyślne włączenie mapowania portów NAT-PMP w Bitcoin Core 30.0 nie sprawiło, że znacznie więcej z nich stało się dostępnych, jak oczekiwano. Technika „hole punching”, w której dwa węzły domowe otwierają połączenia między sobą w tym samym momencie, tak aby każdy router przepuszczał ruch drugiego węzła, stanowiłaby uzupełnienie przekierowania portów z gwarancją najlepszego wysiłku. Większa liczba dostępnych uczciwych węzłów utrudniłaby atakującym, których węzły są łatwiej dostępne, zapełnianie slotów połączeń wychodzących danego węzła.

0xB10C podsumował cztery omówione dotychczas projekty i zaproponował nową opcję, która nie wymaga koordynatora: węzeł ogłasza swój adres umożliwiający „punch” oraz tymczasowy klucz publiczny w nowym typie addr v2, a każda para węzłów wyprowadza tę samą listę kandydatów i czas wykonania „punch” na podstawie wspólnego sekretu oraz każdego nowego bloku. W odpowiedzi na zastrzeżenie Anthony’ego Townsa, że osoba atakująca mogłaby zalewać system prawdziwymi adresami, a także po późniejszym stwierdzeniu, że węzły niedostępne odbierają takie ogłoszenia znacznie mniej niezawodnie niż węzły nasłuchujące, naszkicował alternatywę w postaci „tablicy ogłoszeń”, w której węzły nasłuchujące przechowują zweryfikowane adresy węzłów macierzystych poszukujących partnera.

Towns zakwestionował, czy losowe połączenia przychodzące w ogóle pomagają węzłom macierzystym, i argumentował, że „hole punching” ułatwia atakującemu bezpośredni dostęp do uczciwych węzłów, nie gwarantując przy tym połączenia z żadnym z nich. Oszacował, że atakujący ogłaszający około 10 000 adresów szybko zostałby wykryty przez większość uczciwych węzłów i zaproponował krótkotrwałe połączenia z losowymi partnerami jako alternatywę o mniejszym ryzyku . Jonathan Harvey-Buschel przytoczył dane wskazujące, że uczciwe węzły są trudniej dostępne niż te kontrolowane przez atakujących, i opowiedział się za koordynacją za pośrednictwem własnej usługi Tor danego węzła. Towns zapytał później, czy niedawne luki w zabezpieczeniach protokołu TCP i innych protokołów sprawiają, że nieakceptowanie połączeń przychodzących jest bezpieczniejszym ustawieniem domyślnym dla użytkowników domowych. Dyskusja trwa.

● Projekt BIP dotyczący ujednoliconych zasad wydatkowania przez współpodpisujących: Luke Carriere

opublikował na stronie Delving Bitcoin swoją propozycję ujednolicenia zasad wydatkowania egzekwowanych przez współpodpisujących podczas emulacji umów. Kilka najnowszych projektów, w tym projekt Johana Halsetha dotyczące zasłoniętych współpodpisujących oraz delegowanie kodu łańcucha, definiują własne zasady, więc portfel stworzony dla jednego z nich nie może korzystać ze współpodpisującego lub wyroczni stworzonej dla innego. Carriere nie wnioskuje o nadanie numeru BIP dla tego projektu i zapytał, czy jest to właściwa warstwa do standaryzacji.

Projekt opiera się na kilku zasadach projektowych:

Wszystko, co może być egzekwowane przez skrypt Bitcoin, musi być egzekwowane właśnie tam, a zasady dotyczące współpodpisujących definiują jedynie to, czego skrypt nie jest w stanie zrobić.

Zawsze musi być dostępna co najmniej jedna ścieżka wydatkowania, która nie wymaga współpodpisującego.

Sposób, w jaki współpodpisujący weryfikuje wydatek, oraz to, co gwarantuje jego uczciwość, to

profile modułowe wybierane zgodnie z daną polityką.

Współpodpisujący muszą akceptować poświadczenia wyroczni w formacie

DLC, aby już dostępne wyrocznie mogły być ponownie wykorzystywane bez żadnych modyfikacji.

Polityka składa się z pięciu części. Wyjście definiuje deskryptor Taproot, w którym przechowywane są środki; grupa współpodpisujących grupa określa, którzy współpodpisujący biorą udział i ilu z nich musi podpisać, szablony wymieniają transakcje, które współpodpisujący mogą podpisać wraz z ich dokładnymi wynikami, warunki określają, co musi być spełnione, zanim każdy szablon będzie mógł zostać podpisany, a profile określają tryb weryfikacji, formaty dowodów oraz ewentualny system rozliczalności. Niektóre kwestie pozostają otwarte, na przykład to, czy do serializacji należy używać formatu JSON czy TLV, czy należy już teraz określić weryfikację ślepą, czy też poczekać na większe doświadczenie wdrożeniowe, czy format poświadczania oświadczeń należy określić w propozycji czy w specyfikacjach DLC oraz czy ścieżka awaryjna musi być zablokowana czasowo.

W trakcie późniejszej dyskusji organizacja PREDGE zwróciła uwagę, że jeden z profili dowodów, zwany `statement-v0`, nie posiada flagi ostateczności, co oznacza, że współpodpisujący mógłby podjąć działania na podstawie tymczasowego poświadczenia, które zostało później skorygowane. Ponadto tehiyadu stwierdził, że skrót polityki powinien być ściśle powiązany z dokładną semantyką weryfikatora, aby zapobiec sytuacji, w której różne implementacje akceptowałyby te same bajty, stosując jednocześnie różne warunki. Carriere zgodził się z obydwoma uwagami i oświadczył, że doda flagę ostateczności oraz precyzyjnie określi zasady działania weryfikatora.

Zmiana konsensusu

*Comiesięczna sekcja podsumowująca propozycje i dyskusje dotyczące zmiany zasad konsensusu Bitcoina.*

● Kontynuacja dyskusji na temat BIP54: Antoine Riard opublikował na

liście mailingowej Bitcoin-Dev swój punkt widzenia na temat stanu soft forka porządkującego konsensus (BIP54). Zakaz transakcji, których rozmiar po usunięciu świadectwa wynosi dokładnie 64 bajty, jest nadal najbardziej kontrowersyjną zasadą. Implementacja w Bitcoin Core jest obecnie poddawana przeglądowi i testom i stanowi implementację referencyjną, do której odwołuje się BIP (Bitcoin Core #35793). PR umożliwia włączenie nowych zasad w regtest bez aktywacji w sieci głównej. Zwrócił również uwagę na prace nad interoperacyjnością w btcd (btcd #2537) i stwierdził, że nie zna żadnej implementacji libbitcoin. Jego zdaniem pozostaje jeszcze więcej przeglądów i testów, a także dokumentacja, aby portfele miały świadomość proponowanego limitu 2 500 operacji podpisywania w skrypcie pre-segwit oraz zasady 64 bajtów, a dopiero później – logika aktywacji. Mówiąc wyłącznie w swoim imieniu, uznał, że realistyczne byłoby rozpoczęcie rozważań nad aktywacją w drugiej połowie 2027 r., o ile społeczność do tego czasu wyrazi na to zgodę.

Pieter Wuille zaktualizował swój wątek „Delving Bitcoin” dotyczący tego, w jaki sposób dwie reguły znaczników czasu z BIP54 ograniczają długość łańcucha (zobacz biuletyn nr 425). Najnowszy post zawiera teraz dokładny wzór na dolną granicę pracy, a zarówno ten wzór, jak i przybliżenie dziesiętne zostały potwierdzone w kodzie Lean, do którego znajduje się link.

Riard odniósł się do zastrzeżenia zgłoszonego podczas projektowania BIP54: że naprawienie błędu time warp uniemożliwiłoby zmianę konsensusu w stylu proponowanego przez Marka Friedenbacha forward blocks w całej przyszłej historii Bitcoina. Ponieważ poprawka ogranicza manipulację znacznikami czasu, a nie eliminuje ją całkowicie, nadal można by wdrożyć znacznie bardziej ograniczoną propozycję dotyczącą bloków przyszłych. Oszacował on, że okno 7 200 sekund, nadal dozwolone przez tę poprawkę, mogłoby obniżyć trudność o około 0,60% na okres ponownego ustalania celu oraz podnieść częstotliwość tworzenia bloków o mniej więcej tyle samo, co jest wartością znacznie niższą od wzrostu przepustowości przewidzianego w pierwotnej propozycji. Riard argumentował również, że pomysł ten jest nieuzasadniony nawet przy starych zasadach: walidatorzy przetwarzaliby transakcje raz w łańcuchu przyszłym i ponownie po zsynchronizowaniu ich z łańcuchem kompatybilności, za te same opłaty, chyba że użytkownicy zapłaciliby dwukrotnie, a węzły, które nie zostały zaktualizowane, nadal musiałyby pobierać dodatkowe dane. Riard zaproponuje krótki przypis do BIP54, w którym przedstawi te argumenty, i poprosi Friedenbacha o kontrargumenty.

Prototyp opcjonalnej ochrony przed powtórzeniem : Sjors Provoost nawiązał do wątku na Delving Bitcoin dotyczącego opcjonalnej ochrony przed powtórzeniem w przypadku rozgałęzienia łańcucha (zob. biuletyn nr 420 ) , przedstawiając prototyp wykorzystujący nową wersję świadka. Załącznik , którego ładunek zaczyna się od bajtu 0x01, identyfikuje blok za pomocą 4-bajtowej wysokości, a każdy podpis na tym wejściu potwierdza hash bloku w wybranym łańcuchu. Sam hash nie występuje w transakcji. Oszacował dodatkowy koszt na 1,75 vbyte'a. Wymieniony blok musi mieć co najmniej 100 bloków, co odpowiada horyzontowi zapadalności coinbase. Stwierdził, że gdyby hashrate został podzielony równomiernie, czas oczekiwania przed podziałem monet wyniósłby w najgorszym przypadku dwa dni, ponieważ zasada ta musi obowiązywać tylko po jednej stronie. Zasugerował wydanie wersji świadka wraz z inną propozycją, która jej wymaga, taką jak CISA (BIP460), BIP360 lub wyjście w stylu P2TRv2

z ścieżką klucza, którą można później wyłączyć.

Anthony Towns odpowiedział, że nowa wersja „witness” jest niepotrzebna, a wystarczyłoby nowe kodowanie klucza publicznego do sprawdzania podpisu taproot , w stylu BIP118. Provoost odpowiedział, że rozważał to kodowanie i uznał je za prowizoryczne rozwiązanie, a także że, zgodnie z jego rozumieniem, nie zadziałałoby ono w przypadku wydatkowania ścieżki klucza.

Moonsettler zapytał, czy wymaganie 100 bloków jest pożądane w przypadku podziału, w którym ta funkcja miałaby największe znaczenie, i zasugerował, aby utrzymać to opóźnienie jako zasadę, którą można by złagodzić. Provoost odpowiedział, że po tym, jak monety przejdą na szybszą stronę i zgromadzą potwierdzenia, wolniejsza strona nie będzie już potrzebowała tej ochrony. Provoost napisał również, że spodziewa się, iż zasada ta zostanie wdrożona przed kontrowersyjnym hard forkiem, tak aby obie strony ją odziedziczyły i żadna z nich nie mogła jej łatwo zrezygnować: hash bloku znajduje się wyłącznie w komunikacie podpisu, więc usunięcie tej zasady oznacza zmianę serializacji transakcji w celu przeniesienia hasha.

● QSAVE dla monet, które nie przeszły migracji: James Tagg opublikował na

liście mailingowej Bitcoin-Dev pięć projektów BIP dotyczących QSAVE (Quantum Secure Asset Verification and Escrow), czyli przejścia na system postkwantowy, które nie wiąże się ze spalaniem monet. Opisał je jako alternatywę dla BIP361 oraz dla Hourglass. Z punktu widzenia egzekwowania, które mogłoby zostać uruchomione jako soft fork w dowolnym momencie, każde wejście, które nie znajduje się w rejestrze znanych typów postkwantowych, byłoby traktowane jako niemigrowane, w tym nieznane i przyszłe typy skryptów. Niemigrowane dane wejściowe nadal musiałyby spełniać wymagania skryptu blokującego, a także drugi warunek: albo dowód zerowej wiedzy, że jedno ziarno generuje zarówno skrypt wydatkowania, jak i klucz postkwantowy, albo powiązanie postkwantowe ustanowione przed terminem granicznym. Jeśli jakikolwiek nieprzeniesiony wkład w transakcji nie posiada tego drugiego czynnika, każde wydatkowalne wyjście musi być wyjściem odzyskiwania. W QSAVE nie ma terminu wygaśnięcia, więc brak drugiego czynnika nie niszczy monety. Dowód w łańcuchu bloków może zawsze wydatkować ją bezpośrednio, bez udziału strony trzeciej. W przeciwnym razie opisał proces odzyskiwania utraconych środków poza łańcuchem bloków, którego prawne i ekonomiczne uregulowanie umieścił poza konsensusem, w ramach którego grupa zdecentralizowanych powierników przechowywałaby wyjścia odzyskiwania, wraz z powiernikiem rezerwowym i kontrolerem z prawem weta, a środki mogłyby przynosić konserwatywny zwrot w wysokości 0,5%, przeznaczony na cele charytatywne. W projektach określono również znaki wodne przed odcięciem, opcjonalny klucz ML-DSA-87, który nazwał QD5, oraz liść wydatkowania zk-STARK dla wyjść BIP360 (P2MR) .

● Proof-of-decay dla wyjść, których nie przeniesiono: bitKingAE

opublikował na stronie Delving Bitcoin szkic rozwiązania dotyczącego zmniejszania wartości wyjść narażonych na ataki postkwantowe, takich jak wczesne monety P2PK, które nie zostały przeniesione w okresie karencji. Po upływie okresu karencji wartość wyjścia spadałaby zgodnie z harmonogramem uzależnionym od wysokości bloku. Utracone satoshi zostałyby spalone lub wypłacone jako nagrody za wydobycie, zamiast zamrażania monet lub pozostawiania ich temu, kto zdoła wygenerować podpis. W przykładzie podanym w poście było to niewielki procent salda co 50 000 bloków. Vinicius Cestari odpowiedział, zgłaszając trzy zastrzeżenia: atakujący kwantowy może poczekać do końca okresu karencji i zebrać narażone wyjścia, zanim spadek wartości będzie znaczący; nagły postęp w zakresie ataków kwantowych może doprowadzić do ich wyczerpania jeszcze wcześniej; a harmonogram zmniejsza saldo pasywnego właściciela, w tym takiego, którego klucze zostały już skradzione.

● Cenzura pakietów BIP300: Ori Newman argumentował na

liście mailingowej Bitcoin-Dev, że górnik posiadający 26% mocy obliczeniowej może cenzurować prawidłowy pakiet wypłat w ramach propozycji dotyczącej łańcuchów napędowych (BIP300) na czas nieokreślony. Napisał, że jeśli górnik dysponujący 26% mocy obliczeniowej wysyła sygnał ALARM w każdym wydobywanym przez siebie bloku, każdy z tych bloków obniża wynik każdego oczekującego pakietu o 1. Jeśli pozostałe 74% mocy obliczeniowej zagłosuje za pakietem w każdym bloku, jego oczekiwana ocena wyniesie 12 624 na końcu okna obejmującego 26 300 bloków, co jest wynikiem niższym od wymaganego poziomu 13 150. Zasugerował zakazanie sygnału ALARM oraz wszelkich innych głosów przeciwnych, co przywróciłoby założenie uczciwej większości: pakiet popierany przez 51% mocy obliczeniowej prawie na pewno zostałby przyjęty, a ten popierany przez 49% prawie na pewno odrzucony. Jeśli obecna zasada jest zamierzona, poprosił, aby w BIP-ie zamiast tego określono założenie uczciwej większości na poziomie 75%. Nazwał to znacznym odejściem od modelu bezpieczeństwa Bitcoina i stwierdził, że jednym z argumentów przemawiających za tym jest to, że kradzież środków byłaby trudniejsza dla atakującego dysponującego mniej niż 75% mocy obliczeniowej.

Wersje i wersje kandydackie

*Nowe wersje i wersje kandydackie popularnych projektów infrastruktury Bitcoin. Prosimy o rozważenie aktualizacji do nowych wersji lub pomoc w testowaniu wersji kandydackich.*

● LND v0.21.6-beta i v0.20.7-beta to wydania poprawiające bezpieczeństwo

dla gałęzi 0.21 i 0.20 tej popularnej implementacji węzła LN. Oba Oba zawierają środki zaradcze dotyczące luki w zabezpieczeniach jądra systemu Linux CVE-2026-98432 opisanej poniżej w zgłoszeniu LND #11456. Operatorzy systemów Linux powinni przeprowadzić aktualizację, wyłączyć MPTCP na hoście w celu ochrony innych usług oraz zainstalować załatane jądro, ponieważ rozwiązanie wprowadzone w LND nie usuwa podstawowej luki.

● Core Lightning 26.06.10 to wydanie zabezpieczające tej popularnej implementacji węzła LN.

Naprawia ono luki w zabezpieczeniach związanych z podwójnym finansowaniem, łączeniem transakcji, rozliczaniem HTLC w łańcuchu bloków, kontrolą dostępu oraz innymi komponentami. Kod źródłowy poprawek bezpieczeństwa jest dostępny, natomiast powiązane testy zostały tymczasowo wstrzymane, aby dać użytkownikom więcej czasu na aktualizację. Projekt zdecydowanie zaleca aktualizację.

● BTCPay Server 2.4.7 to wydanie poprawiające bezpieczeństwo tego samodzielnie hostowanego systemu przetwarzania płatności. Naprawia ono 85 luk w zabezpieczeniach zgłoszonych przez program OSS Scanner firmy Anthropic, w tym problemy dotyczące limitów wypłat, dostępu do danych innych sklepów, uwierzytelniania oraz wyczerpania zasobów. Naprawia również problemy związane z rozliczaniem płatności i niezawodnością. Zdecydowanie zaleca się aktualizację, szczególnie w przypadku serwerów współużytkowanych przez wielu sprzedawców.

Istotne zmiany w kodzie i dokumentacji

*Istotne ostatnie zmiany w Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIP), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition oraz BINANAs.*

● Bitcoin Core #36539 przywraca format PSBTv0 dla transakcji niepodpisanych

i podwyżek opłat eksportowanych z interfejsu graficznego. Bitcoin Core 32.1 eksportował te pliki PSBT przy użyciu wersji 2, uniemożliwiając użytkownikom podpisywanie ich za pomocą narzędzi obsługujących wyłącznie wersję 0. Oddzielny proces pracy z zewnętrznym podpisującym, skonfigurowany za pomocą `-signer` (patrz biuletyn nr 138) nadal korzysta z PSBTv2, więc użytkownicy ci potrzebują zewnętrznego modułu podpisującego, który go obsługuje, takiego jak HWI 2.1.0 lub nowszego.

● Bitcoin Core #35714 naprawia błąd, w wyniku którego węzeł mógł aktualizować swój indeks bloków

i bazę danych UTXO po nieudanym zapisaniu danych bloków lub operacji cofania na dysk. Chociaż niepowodzenie to powodowało sygnalizację konieczności wyłączenia węzła, kod obsługujący te operacje zapisu mógł nadal aktualizować bazy danych przed zatrzymaniem węzła. Jeśli te aktualizacje zakończyły się powodzeniem, bazy danych mogły zapisać stan, dla którego odpowiadające dane blokowe lub dane cofania nie zostały jeszcze bezpiecznie zapisane. Mogło to spowodować niespójność lokalnego stanu węzła i skomplikować proces odzyskiwania. Obecnie kod pomija te operacje zapisu do baz danych podczas nieudanej próby zapisania. Stanowi to uzupełnienie wcześniejszych zabezpieczeń dotyczących kolejności zapisywania opcjonalnych indeksów, omówionych w biuletynie nr 414.

● Bitcoin Core #35492 naprawia błąd, w wyniku którego `bitcoin-wallet dump` (patrz

biuletyn nr 130) mógł zgłaszać powodzenie po zapisaniu niekompletnego eksportu portfela. Wcześniej polecenie sprawdzało, czy może otworzyć plik docelowy, ale nie wykrywało późniejszych błędów zapisu, takich jak brak miejsca na dysku. W rezultacie użytkownicy mogli błędnie sądzić, że eksport został zakończony, by dopiero podczas próby przywrócenia portfela odkryć brakujące dane. Obecnie polecenie weryfikuje zapis, opróżnianie i zamykanie pliku. Zgłasza niepowodzenia i usuwa niekompletne pliki zrzutu.

● BIP-y nr 2205, 2210 i 2212 dodają trzy projekty

specyfikacji dotyczące agregacji podpisów z wielu wejść. BIP 458 określa nieinteraktywną agregację połowiczną, łączącą `n` istniejące podpisy BIP340 w `32 × (n + 1)` bajtów zamiast `64 × n` bajtów. BIP459 określa DahLIAS, interaktywny protokół, który generuje pojedynczy 64-bajtowy podpis agregowany dla wielu kluczy i komunikatów. BIP460 proponuje wykorzystanie tych schematów do wydatkowań typu keypath dla nowych wyjść w wersji świadka 2 , przy jednoczesnym zachowaniu indywidualnych podpisów dla wydatkowań typu „scriptpath” oraz umożliwieniu rezygnacji z udziału wejść typu „keypath”. Od czasu omówienia tej propozycji w biuletynie nr 417 wejścia, które zrezygnowały z udziału, zostały zmodyfikowane tak, aby korzystały z zwykłych podpisów zgodnych z BIP341 bez specjalnego znacznika, co pozwala portfelom na przyjęcie nowego typu wyjścia przy jednoczesnym ponownym wykorzystaniu istniejącej logiki podpisywania. Pozwoliłoby to zmniejszyć wagę transakcji i opłaty za transakcje z wieloma uczestniczącymi wejściami, w tym coinjoinami i payjoinami . Wdrożenie proponowanej agregacji transakcji wymagałoby soft forka. BIP460 nie określa mechanizmu aktywacji ani parametrów.

● Core Lightning #9419 dodaje opcjonalne `failure_reason` pole do

`listforwards` RPC oraz `forward_event` powiadomienia w przypadku lokalnych niepowodzeń prób przekazywania. Wcześniej kilka różnych problemów miało ten sam kod błędu protokołu, co utrudniało operatorom ustalenie przyczyny niepowodzenia przekazywania. Nowe pole rozróżnia przyczyny, takie jak niewystarczająca płynność wychodząca, węzeł wychodzący w trybie offline oraz limity dotyczące liczby lub łącznej wartości oczekujących HTLC.

● Core Lightning #9592 aktualizuje `xpay` (patrz Biuletyn nr 330)

w celu uniknięcia korzystania z węzła przekazującego dla pozostałej części płatności po tym, jak dwukrotnie zwrócił `unknown_next_peer`. Wcześniej każda awaria wykluczała jedynie zgłoszony kanał, więc kolejne próby mogły nadal wybierać inne kanały przez ten sam węzeł, aż do wygaśnięcia czasu ponownej próby płatności. Teraz, po drugiej awarii z tego samego węzła, `xpay` wyklucza go na poziomie prywatnej `askrene` warstwy routingu. Ta heurystyka może wykluczyć kanały nadające się do użytku, ale ogranicza powtarzające się próby przez ten sam węzeł.

● LDK #5089 aktualizuje mechanizm podwyższania opłat podczas wymuszonego zamykania kanałów z

wyjściami kotwiczącymi. Jeśli LDK nie może uzyskać niezbędnych środków na transakcję potomną CPFP, która wykorzystuje wyjście kotwiczące, teraz rozgłasza wyłącznie transakcję zobowiązania. Wcześniej ta awaria mogła spowodować, że obie transakcje nie zostałyby rozesłane, opóźniając odzyskanie środków z kanału. Transakcja zobowiązania zawiera już opłatę, która może nadal być wystarczająca do potwierdzenia, jeśli szacowana opłata była konserwatywna lub zapotrzebowanie w sieci spadnie. Jednak to rozwiązanie awaryjne wyklucza transakcje zobowiązania o zerowej opłacie, które wymagają transakcji potomnej z opłatą do przekazania. Problem został zgłoszony przez Project Loupe.

● LND #11456 domyślnie wyłącza odbiorniki Multipath TCP (MPTCP) w celu

złagodzenia skutków luki CVE-2026-98432, luki w zabezpieczeniach jądra systemu Linux, w przypadku której wykazano możliwość zdalnego wykonania kodu przy użyciu MPTCP. Wersja Go 1.24 i nowsze domyślnie włączają te nasłuchujące moduły w obsługiwanych systemach Linux, co mogłoby narazić operatorów LND na ryzyko, nawet jeśli nie skonfigurują oni wyraźnie MPTCP. Ta zmiana ustawia `multipathtcp=0` domyślnych ustawień LND w języku Go. Blokuje to wykazaną ścieżkę ataku poprzez słuchacze LND, ale nie naprawia leżącego u jej podstaw błędu jądra. Systemy, których to dotyczy, nadal wymagają załatane jądro. Operatorzy korzystający z istniejących plików binarnych mogą zastosować to samo zabezpieczenie, restartując LND z użyciem zmiennej środowiskowej `GODEBUG=multipathtcp=0`.

● LND #11357 zaostrza weryfikację faktur BOLT11 zgodnie z BOLT

#1357 (patrz Biuletyn nr 428). Zamiast wykorzystywać pierwsze i ignorować pozostałe, odrzuca teraz zduplikowane pola sekretu płatności, zapobiegając niejednoznaczności między parserami, które wybierają różne wystąpienia. Jest to kontynuacja wcześniejszego odrzucania zduplikowanych skrótów płatności (patrz biuletyn nr 425). Testy dodane w ramach aktualizacji specyfikacji ujawniły również, że dotychczasowe wymagania nie były egzekwowane. Dekoder odrzuca teraz nieprawidłowe długości podczas analizowania skrótu płatności, skrótu opisu, klucza tajnego płatności oraz klucza publicznego odbiorcy, zamiast traktować te pola jako nieobecne. Wcześniej pole klucza publicznego odbiorcy o nieprawidłowej długości mogło spowodować, że LND przechodziło na odzyskiwanie klucza z podpisu. W przypadku faktur zawierających jawny klucz publiczny odbiorcy wymagany jest również podpis ECDSA o niskim S. Jednak to ograniczenie nie ma zastosowania, gdy klucz publiczny jest odzyskiwany z podpisu (zobacz biuletyn nr 381).

● LND #11413 przyspiesza czyszczenie przy uruchomieniu zapisanych wyników płatności wychodzących

na węzłach korzystających z SQLite lub PostgreSQL. Podczas normalnej pracy węzeł gromadzi wynik dla każdej rozstrzygniętej, zainicjowanej lokalnie próby HTLC. Przy uruchomieniu usuwa wyniki, które nie są już potrzebne. Wcześniej odczytywanie i usuwanie poszczególnych wpisów wymagało wielokrotnych przesyłania danych do i z bazy danych, co mogło sprawiać, że czyszczenie trwało wiele godzin na obciążonym węźle korzystającym ze zdalnej bazy PostgreSQL. Teraz czyszczenie grupuje operacje na bazie danych, zachowując jednocześnie wyniki potrzebne do wznowienia oczekujących płatności.

● LND #11151 wprowadza sprawdzanie nadmiernych stawek opłat za zobowiązania oraz niewystarczających

salda początkowych podczas akceptowania kanałów przychodzących. LND odrzuca teraz proponowaną stawkę opłaty wyższą niż dziesięciokrotność szacowanej wartości trzech bloków lub 100 sat/vbyte, w zależności od tego, która z tych wartości jest większa. Egzekwuje również zasadę rezerwy początkowej BOLT2 i odrzuca osobno kanały, w których saldo początkowe żadnej ze stron nie przekracza rezerwy, którą strona ta musi utrzymywać. Chociaż inicjator uiszcza opłatę za zobowiązanie, nadmierna opłata może wyczerpać jego saldo użytkowe, marnując pojemność kanału oczekującego odbiorcy podczas otwierania i pozostawiając kanał bezużyteczny po potwierdzeniu transakcji finansującej. Stanowi to uzupełnienie kontroli minimalnej stawki opłat omówionych w biuletynie nr 429.

● Rust Bitcoin #7067 rozszerza funkcje pomocnicze skrótu podpisu taproot

(sighash) tak, aby akceptowały opcjonalny aneks oraz, w przypadku wydatkowań typu scriptpath, pozycję kodu operacyjnego ostatniego OP_CODESEPARATOR wykonanego przed sprawdzeniem podpisu. Oba elementy mają wpływ na komunikat, do którego odnosi się podpis. Wcześniej te funkcje pomocnicze zakładały brak załącznika i brak wykonanego `OP_CODESEPARATOR`, więc wywołujący obsługujący takie wydatki musieli używać bardziej ogólnej funkcji sighash, aby uniknąć wygenerowania nieprawidłowego skrótu. Funkcje pomocnicze akceptują teraz te wartości bezpośrednio, chociaż wywołujący nadal muszą określić pozycję separatora. Wywołujący obsługujący wydatki bez załącznika lub bez wykonanego `OP_CODESEPARATOR` , mogą przekazać `None` dla nowych argumentów, aby zachować poprzednie zachowanie. Zobacz biuletyn nr 427, aby zapoznać się z powiązanymi zmianami w interfejsie API funkcji `sighash` dla transakcji typu legacy i segwit v0 .