Bitcoin Optech – spravodaj č. 430

Tento týždenný spravodajský bulletin prináša súhrn pokračujúcej diskusie o využívaní techniky „TCP hole punching“ na zabezpečenie dostupnosti uzlov za domácimi smerovačmi a opisuje návrh BIP na štandardizáciu pravidiel výdavkov, ktoré spolupodpisovatelia uplatňujú pri emulácii dohôd. Súčasťou sú aj naše pravidelné rubriky, ktoré zhrňujú návrhy a diskusie o zmene konsenzuálnych pravidiel bitcoinu, oznamujú nové verzie a kandidátske verzie a opisujú významné zmeny v populárnom softvéri bitcoinovej infraštruktúry.

Novinky

● Pokračujúca diskusia o technike TCP hole punching pre domáce uzly: V nadväznosti na

naše májové zhrnutie vlákna „Delving Bitcoin“ od 0xB10C o využívaní „hole punching“ na umožnenie uzlom za domácimi smerovačmi prijímať spojenia medzi sebou, 0xB10C uviedol, že sa opäť začalo pracovať na špecifikácii a experimentálnej implementácii v Bitcoin Core. Domáce uzly zvyčajne dokážu nadväzovať len odchádzajúce pripojenia a zapnutie mapovania portov NAT-PMP ako predvoleného nastavenia v Bitcoin Core 30.0 nezabezpečilo, že by bolo oveľa viac z nich dostupných, ako sa očakávalo. Technika „hole punching“, pri ktorej dva domáce uzly otvoria pripojenia medzi sebou v rovnakom okamihu, aby každý router prepustil dátový tok toho druhého, by bola doplnkom k presmerovaniu portov s maximálnym úsilím. Väčší počet dostupných čestných uzlov by sťažil útočníkom, ktorých uzly sú ľahšie dostupné, zaplniť sloty pre odchádzajúce pripojenia uzla.

0xB10C zhrnul štyri doteraz diskutované návrhy a navrhol novú možnosť, ktorá nepotrebuje koordinátora: uzol oznámi svoju adresu, na ktorú je možné vytvoriť „punch“, a dočasný verejný kľúč v novom type addr v2, a každá dvojica uzlov odvodí ten istý zoznam kandidátov a načasovanie „punch“ zo svojho zdieľaného tajného kľúča a každého nového bloku. V reakcii na námietku Anthonyho Townsa, že útočník by mohol zaplaviť systém skutočnými adresami, a po tom, čo neskôr zistil, že nedostupné uzly prijímajú takéto oznámenia oveľa menej spoľahlivo ako počúvajúce uzly, načrtol alternatívu v podobe „nástenky“, v ktorej počúvajúce uzly uchovávajú overené adresy domovských uzlov hľadajúcich partnera.

Towns spochybnil, či náhodné prichádzajúce pripojenia vôbec pomáhajú domácim uzlom, a argumentoval, že „hole punching“ uľahčuje útočníkovi priamy prístup k čestným uzlom, pričom prispieva len málo k zaručeniu pripojenia k čestnému uzlu. Odhadol, že útočník, ktorý inzeruje približne 10 000 adries, by sa rýchlo zhodoval s väčšinou čestných uzlov, a navrhol krátkodobé pripojenia k náhodným partnerom ako alternatívu s nižším rizikom . Jonathan Harvey-Buschel citoval údaje, ktoré ukazujú, že čestné uzly sú menej dostupné ako tie kontrolované útočníkmi, a uprednostnil koordináciu prostredníctvom vlastnej služby Tor daného uzla. Towns neskôr sa opýtal, či nedávne zraniteľnosti protokolu TCP a ďalších protokolov nerobia neprijímanie prichádzajúcich pripojení bezpečnejším predvoleným nastavením pre domácich používateľov. Diskusia stále prebieha.

● Návrh BIP na štandardizáciu pravidiel výdavkov spolupodpisovateľov: Luke Carriere

zverejnil na stránke Delving Bitcoin svoj návrh na štandardizáciu pravidiel výdavkov, ktoré uplatňujú spolupodpisovatelia pri emulácii zmluvných podmienok. Niekoľko nedávnych návrhov, vrátane Halsetha o zaslepených spolupodpisovateľoch a delegovaní reťazového kódu, každý definuje svoje vlastné pravidlá, takže peňaženka vytvorená pre jeden návrh nemôže používať spolupodpisovateľa alebo orákulum vytvorené pre iný návrh. Carriere nežiada o pridelenie čísla BIP pre tento návrh a opýtal sa, či je toto správna vrstva na štandardizáciu.

Návrh sa riadi niekoľkými návrhárskymi princípmi:

Všetko, čo je možné vynútiť prostredníctvom skriptu Bitcoin, musí byť vynútené tam, pričom zásady spolupodpisovateľov definujú len to, čo skript nedokáže.

Vždy musí byť k dispozícii aspoň jedna cesta výdavku, ktorá nevyžaduje spolupodpisovateľa.

Spôsob, akým spolupodpisovateľ overuje výdavok, a to, čo zaručuje jeho čestnosť, sú

pripojiteľné profily zvolené podľa príslušnej politiky.

Spolupodpisovatelia musia akceptovať osvedčenia orákulov vo formáte

DLC, aby bolo možné už dostupné orákuly opätovne použiť bez akýchkoľvek úprav.

Zásada sa skladá z piatich častí. Výstup definuje deskriptor Taproot, ktorý obsahuje prostriedky, skupina spolupodpisovateľov určuje, ktorí spolupodpisovatelia sa zúčastňujú a koľko z nich musí podpísať, šablóny uvádzajú transakcie, ktoré môžu spolupodpisovatelia podpísať, spolu s ich presnými výstupmi, podmienky stanovujú, čo musí byť splnené, aby mohla byť každá šablóna podpísaná, a profily určujú režim overovania, formáty dôkazov a akýkoľvek systém zodpovednosti. Niektoré body zostávajú otvorené, napríklad či použiť na serializáciu JSON alebo TLV, či by sa malo špecifikovať slepé overovanie už teraz, alebo počkať na väčšie skúsenosti s implementáciou, či špecifikovať formát osvedčenia výpisu v návrhu alebo v špecifikáciách DLC a či musí byť záložná cesta časovo uzamknutá.

V nasledujúcej diskusii organizácia PREDGE poukázala na to, že jeden z profilov dôkazov s názvom `statement-v0`, nemá príznak konečnosti, čo znamená, že spolupodpisovateľ by mohol konať na základe predbežného osvedčenia, ktoré bolo neskôr opravené. Navyše tehiyadu uviedol, že hash politiky by sa mal viazať na presnú sémantiku overovateľa, aby sa zabránilo tomu, že rôzne implementácie budú akceptovať rovnaké bajty, pričom budú vynucovať odlišné podmienky. Carriere súhlasil s oboma bodmi a uviedol, že pridá príznak konečnosti a spresní pravidlá overovateľa.

Zmena konsenzu

*Mesačná rubrika sumarizujúca návrhy a diskusiu o zmene pravidiel konsenzu v Bitcoine.*

● Pokračujúca diskusia o BIP54: Antoine Riard zverejnil na

mailing liste Bitcoin-Dev svoj pohľad na stav soft forku na vyčistenie konsenzu (BIP54). Zákaz transakcií, ktorých veľkosť bez svedectva je presne 64 bajtov, je stále najkontroverznejším pravidlom. Implementácia v Bitcoin Core je v súčasnosti predmetom posudzovania a testovania a predstavuje referenčnú implementáciu, na ktorú odkazuje BIP (Bitcoin Core #35793). Tento PR aktivuje nové pravidlá v regtest bez aktivácie v mainnete. Poukázal tiež na prácu v oblasti interoperability v btcd (btcd #2537) a uviedol, že nevie o žiadnej implementácii v libbitcoin. Podľa jeho názoru zostáva ešte viac preskúmania a testovania, dokumentácia, aby peňaženky vedeli o navrhovanom limite 2 500 podpisových operácií v skripte pred segwit a o pravidle 64 bajtov, a až neskôr logika aktivácie. Hovoril len za seba, keď uviedol, že by bolo realistické začať uvažovať o aktivácii v druhej polovici roku 2027, ak sa na tom komunita do tej doby zhodne.

Pieter Wuille aktualizoval svoje vlákno na fóre Delving Bitcoin o tom, ako dve pravidlá časových pečiatok BIP54 ohraničujú dĺžku reťazca (pozri Newsletter č. 425). Prvý príspevok teraz obsahuje presný vzorec pre dolnú hranicu práce a tak tento vzorec, ako aj desatinná aproximácia sú teraz overené v prepojenom kóde Lean.

Riard nadviazal na námietku vznesenú počas návrhu BIP54: že oprava chyby časového posunu by znemožnila zmenu konsenzu v štýle Marka Friedenbacha forward blocks po zvyšok budúcej histórie Bitcoinu. Keďže táto oprava obmedzuje manipuláciu s časovými pečiatkami, namiesto toho, aby ju úplne odstránila, stále by bolo možné implementovať oveľa obmedzenejší návrh „forward blocks“. Odhadol, že 7 200-sekundové okno, ktoré oprava stále umožňuje, by mohlo znížiť obtiažnosť približne o 0,60 % za každé obdobie preorientovania a zvýšiť rýchlosť tvorby blokov približne o rovnakú hodnotu, čo je zďaleka menej ako zvýšenie kapacity v pôvodnom návrhu. Riard tiež argumentoval, že táto myšlienka je neopodstatnená aj pri starých pravidlách: validátori by spracovávali transakcie raz v predbežnom reťazci a znovu, keď by sa synchronizovali do kompatibilného reťazca, za rovnaké poplatky, pokiaľ by používatelia neplatili dvakrát, a uzly, ktoré neprešli na novú verziu, by stále museli stiahnuť dodatočné dáta. Riard navrhne krátku poznámku pod čiarou k BIP54, v ktorej tento argument vysvetlí, a požiada Friedenbacha o protiargumenty.

Prototyp ochrany proti opakovanému prehrávaniu s možnosťou zapojenia : Sjors Provoost nadviazal na vlákno na fóre Delving Bitcoin o ochrane proti opakovanému prehrávaniu s možnosťou zapojenia v prípade rozdelenia reťazca (pozri spravodaj č. 420 ) s prototypom, ktorý využíva novú verziu svedka. Príloha , ktorej užitočné dáta začínajú bajtom 0x01, identifikuje blok pomocou 4-bajtovej výšky, a každý podpis na tomto vstupe sa viaže na hash bloku v požadovanom reťazci. Samotný hash nie je prítomný v transakcii. Dodatočné náklady odhadol na 1,75 vbytes. Pomenovaný blok musí byť starý aspoň 100 blokov, čo je rovnaký horizont ako splatnosť coinbase. Uviedol, že ak by sa hashrate rozdelil rovnomerne, čakanie pred rozdelením mincí by v najhoršom prípade trvalo dva dni, pretože pravidlo musí platiť len na jednej strane. Navrhol vydanie verzie svedka spolu s iným návrhom, ktorý ju potrebuje, napríklad CISA (BIP460), BIP360 alebo výstup v štýle P2TRv2

s kľúčovou cestou, ktorú bude možné neskôr deaktivovať.

Anthony Towns odpovedal, že nová verzia s witnessom je nepotrebná a že by stačilo nové kódovanie verejného kľúča pre kontrolu podpisu taproot v štýle BIP118. Provoost odpovedal, že túto kódovaciu metódu zvažoval a považoval ju za provizórne riešenie, a že podľa jeho chápania by nefungovala pri výdaji prostredníctvom kľúčovej cesty.

Moonsettler spochybnil, či je požiadavka 100 blokov žiaduca v prípade rozdelenia, kde by táto funkcia mala najväčší význam, a navrhol, aby sa toto oneskorenie zachovalo ako pravidlo politiky, ktoré by sa mohlo uvoľniť. Provoost odpovedal, že po tom, čo sa mince presunú na rýchlejšiu stranu a nazbierajú potvrdenia, pomalšia strana už túto ochranu nepotrebuje. Provoost tiež napísal, že očakáva, že pravidlo bude nasadené pred sporným hard forkom, aby ho zdedili obe strany a aby ho žiadna strana nemohla ľahko zrušiť: hash bloku je iba v podpisovej správe, takže odstránenie pravidla znamená zmenu serializácie transakcie tak, aby obsahovala tento hash.

● QSAVE pre nemigrované mince: James Tagg zverejnil na

mailing liste Bitcoin-Dev päť návrhov BIP pre QSAVE (Quantum Secure Asset Verification and Escrow), čo je postkvantový prechod, pri ktorom nedochádza k spáleniu mincí. Opísal ich ako alternatívu k BIP361 a k Hourglass. Z hľadiska vynútiteľnosti, ktorú by bolo možné kedykoľvek aktivovať ako soft fork, by sa každý vstup, ktorý nie je v registri známych postkvantových typov, považoval za nemigrovaný, vrátane neznámych a budúcich typov skriptov. Nemigrovaný vstup by aj naďalej musel spĺňať požiadavky svojho uzamykacieho skriptu a zároveň druhý faktor: buď dôkaz s nulovou znalosťou, že jedno semeno odvádza ako skript výdavku, tak aj postkvantový kľúč, alebo postkvantovú väzbu potvrdenú pred termínom ukončenia. Ak akémukoľvek nemigrovanému vstupu v transakcii chýba tento druhý faktor, každý utratiteľný výstup musí byť výstupom na obnovenie. V QSAVE neexistuje žiadny termín ukončenia platnosti, takže chýbajúci druhý faktor nezničí mincu. Dôkaz v reťazci ju môže vždy utratiť priamo, bez tretej strany. Inak opísal mimoreťazcový proces pre stratené majetky, ktorého právne a ekonomické zaobchádzanie umiestnil mimo konsenzu, v ktorom by skupina decentralizovaných správcov držala výstupy na obnovenie, spolu so záložným správcom a kontrolórom s právom veta, a prostriedky by mohli prinášať konzervatívny výnos 0,5 % smerujúci na charitu. V návrhoch sú tiež špecifikované vodoznaky pred uzávierkou, voliteľný kľúč ML-DSA-87, ktorý nazval QD5, a zk-STARK výdavkový list pre výstupy BIP360 (P2MR) .

● Dôkaz úbytku (Proof-of-decay) pre nemigrované výstupy: bitKingAE

zverejnil na stránke Delving Bitcoin náčrt na zmenšovanie výstupov vystavených postkvantovým útokom, ako sú napríklad rané P2PK mince, ktoré neboli presunuté v rámci ochranného obdobia. Po uplynutí ochranného obdobia by hodnota výstupu klesala podľa harmonogramu v závislosti od výšky bloku. Stratené satoshi by boli spálené alebo vyplatené ako odmeny za ťažbu, namiesto toho, aby boli mince zmrazené alebo ponechané tomu, kto dokáže vytvoriť podpis. V príspevku bol uvedený príklad malého percenta zostatku každých 50 000 blokov. Vinicius Cestari odpovedal tromi námietkami: kvantový útočník môže počkať, kým uplynie ochranná lehota, a zmiesť vystavené výstupy skôr, než ich zníženie hodnoty výrazne postihne; náhle zlepšenie kvantových útokov ich môže vyčerpať ešte skôr; a tento harmonogram znižuje zostatok pasívneho vlastníka, vrátane toho, ktorému už boli ukradnuté kľúče.

● Cenzúra zväzkov podľa BIP300: Ori Newman argumentoval na

diskusnej skupine Bitcoin-Dev, že ťažiari s 26 % hashrate môžu cenzurovať platný zväzok výberov v návrhu drivechains (BIP300) na neurčito. Napísal, že ak ťažiari s 26 % hashrate pošle ALARM v každom bloku, ktorý vyťaží, každý z týchto blokov zníži skóre každého čakajúceho balíka o 1. Ak zvyšných 74 % hashrate v každom bloku balík podporí, jeho očakávané skóre by na konci 26 300-blokového okna bolo 12 624, čo je menej ako požadovaných 13 150. Navrhol zakázať ALARM a akékoľvek iné negatívne hlasovanie, čo by obnovilo predpoklad čestnej väčšiny: balík podporovaný 51 % hashrate by takmer určite prešiel a ten podporovaný 49 % by takmer určite neprešiel. Ak je súčasné pravidlo zámerné, požiadal, aby BIP namiesto toho stanovil predpoklad čestnej väčšiny na úrovni 75 %. Nazval to výrazným odklonom od bezpečnostného modelu bitcoinu a uviedol, že jedným z argumentov v jeho prospech je, že krádež prostriedkov by bola pre útočníka s menej ako 75 % hashrate ťažšia.

Vydania a kandidátske verzie

*Nové verzie a kandidátske verzie pre populárne projekty bitcoinovej infraštruktúry. Zvážte prosím aktualizáciu na nové verzie alebo pomoc pri testovaní kandidátskych verzií.*

● LND v0.21.6-beta a v0.20.7-beta sú bezpečnostné

verzie pre vetvy 0.21 a 0.20 tejto obľúbenej implementácie uzla LN . Obe verzie obsahujú nápravu zraniteľnosti jadra Linuxu CVE-2026-98432 opísanej nižšie v LND #11456. Prevádzkovatelia v systéme Linux by mali vykonať aktualizáciu, deaktivovať MPTCP na hostiteľskom počítači na ochranu ostatných služieb a nainštalovať opravené jadro, keďže nápravné opatrenie LND neodstraňuje základnú zraniteľnosť.

● Core Lightning 26.06.10 je bezpečnostná verzia tejto populárnej implementácie uzla LN

. Opravuje zraniteľnosti v oblasti duálneho financovania, spájania transakcií, riešenia HTLC v reťazci, kontroly prístupu a ďalších komponentov. Zdrojový kód bezpečnostných opráv je k dispozícii, zatiaľ čo súvisiace testy sú dočasne pozastavené, aby mali používatelia viac času na aktualizáciu. Projekt dôrazne odporúča aktualizáciu.

● BTCPay Server 2.4.7 je bezpečnostná verzia tohto platobného procesora na vlastnom serveri. Opravuje 85 bezpečnostných chýb, ktoré nahlásil program OSS Scanner, vrátane problémov týkajúcich sa limitov výplat, prístupu k údajom iných obchodov, autentifikácie a vyčerpania zdrojov. Opravuje tiež problémy s účtovaním platieb a spoľahlivosťou. Aktualizácia sa dôrazne odporúča, najmä v prípade serverov zdieľaných viacerými obchodníkmi.

Významné zmeny v kóde a dokumentácii

*Významné nedávne zmeny v 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 a BINANAs.*

● Bitcoin Core #36539 obnovuje formát PSBTv0 pre nepodpísané transakcie

a zvýšenia poplatkov exportované z grafického rozhrania. Bitcoin Core 32.1 exportoval tieto PSBT pomocou verzie 2, čím zabránil používateľom v ich podpisovaní pomocou nástrojov, ktoré podporujú iba verziu 0. Samostatný pracovný postup s externým podpisovateľom nakonfigurovaný s `-signer` (pozri Newsletter č. 138) naďalej používa PSBTv2, takže títo používatelia potrebujú externý podpisovací nástroj, ktorý ho podporuje, napríklad HWI 2.1.0 alebo novší.

● Bitcoin Core #35714 opravuje chybu, pri ktorej uzol mohol aktualizovať svoj index blokov

a databázu UTXO po tom, čo sa nepodarilo zapísať údaje o blokoch alebo vrátení zmien na disk. Hoci táto chyba signalizovala uzlu, aby sa vypol, kód spracúvajúci tieto zápisy mohol stále aktualizovať databázy predtým, ako sa uzol zastavil. Ak by tieto aktualizácie prebehli úspešne, databázy by mohli zaznamenať stav, pre ktorý podporné blokové alebo vrátené údaje ešte neboli bezpečne uložené. To by mohlo spôsobiť nekonzistentnosť lokálneho stavu uzla a skomplikovať obnovenie. Kód teraz tieto zápisy do databázy počas neúspešného pokusu o vyprázdnenie preskakuje. Toto dopĺňa skoršie ochrany poradia vyprázdňovania pre voliteľné indexy, o ktorých sme písali v spravodajstve č. 414.

● Bitcoin Core #35492 opravuje chybu, pri ktorej `bitcoin-wallet dump` (pozri

Newsletter č. 130) mohol hlásiť úspech po zapísaní neúplného exportu peňaženky. Predtým príkaz skontroloval, či dokáže otvoriť cieľový súbor, ale nezistil následné chyby zápisu, ako napríklad nedostatok miesta na disku. V dôsledku toho sa používatelia mohli mylne domnievať, že export bol dokončený, a až pri pokuse o obnovenie peňaženky zistili chýbajúce údaje. Teraz príkaz overuje zápis, vyprázdnenie a zatvorenie súboru. Nahlasuje zlyhania a odstraňuje neúplné súbory výpisu.

● BIP #2205, #2210 a #2212 pridávajú tri návrhy

špecifikácií pre agregáciu podpisov z viacerých vstupov. BIP458 špecifikuje neinteraktívnu polovičnú agregáciu, ktorá kombinuje `n` existujúcich podpisov BIP340 do `32 × (n + 1)` bajtov namiesto `64 × n` bajtov. BIP459 špecifikuje DahLIAS, interaktívny protokol, ktorý vytvára jediný 64-bajtový agregovaný podpis pre viaceré kľúče a správy. BIP460 navrhuje použitie týchto schém pre výdavky typu keypath s novou verziou svedka 2 výstupov, pričom zachováva individuálne podpisy pre výdavky typu „scriptpath“ a umožňuje vstupom typu „keypath“ odhlásiť sa. Odkedy bol tento návrh spomenutý v spravodajstve č. 417 , odhlásené vstupy boli upravené tak, aby používali bežné podpisy podľa BIP341 bez špeciálneho označenia, čo umožňuje peňaženkám prijať nový typ výstupu a zároveň opätovne využiť svoju existujúcu logiku podpisovania. Tým by sa znížila veľkosť transakcie a poplatky za transakcie s viacerými zúčastnenými vstupmi, vrátane coinjoinov a payjoinov . Zavedenie navrhovanej agregácie transakcií by si vyžadovalo soft fork. BIP460 nedefinuje mechanizmus aktivácie ani parametre.

● Core Lightning #9419 pridáva voliteľné `failure_reason` pole do

`listforwards` RPC a `forward_event` oznámenia v prípade lokálne zlyhaných pokusov o presmerovanie. Predtým sa na rovnaký kód zlyhania protokolu vzťahovalo niekoľko rôznych problémov, čo operátorom sťažovalo zistenie dôvodu, prečo presmerovanie zlyhalo. Nové pole rozlišuje medzi príčinami, ako sú nedostatočná odchádzajúca likvidita, offline odchádzajúci peer a obmedzenia týkajúce sa počtu alebo celkovej hodnoty čakajúcich HTLC.

● Core Lightning #9592 aktualizuje `xpay` (pozri Newsletter č. 330)

s cieľom vyhnúť sa použitiu uzla na odosielanie pre zvyšnú časť platby po tom, čo dvakrát vrátil `unknown_next_peer`. Predtým každé zlyhanie vylúčilo len hlásený kanál, takže následné pokusy mohli naďalej vyberať iné kanály cez ten istý uzol, kým nevypršal čas na opakovanie platby. Teraz, po druhom zlyhaní z toho istého uzla, `xpay` sa tento uzol vylúči na úrovni súkromnej `askrene` smerovacej vrstvy. Táto heuristika môže vylúčiť použiteľné kanály, ale obmedzuje opakované pokusy cez ten istý uzol.

● LDK #5089 aktualizuje zvyšovanie poplatkov pri nútenom uzatváraní kanálov s

kotvovými výstupmi. Ak LDK nedokáže získať potrebné prostriedky na podriadenú transakciu CPFP, ktorá čerpá z kotvového výstupu, teraz vysiela iba záväznú transakciu. Predtým táto chyba mohla spôsobiť, že obe transakcie zostali nevysielané, čo spomalilo obnovenie finančných prostriedkov kanála. Záväzok už obsahuje poplatok, ktorý môže byť stále dostatočný na potvrdenie, ak bol odhad poplatku konzervatívny alebo ak klesne dopyt v sieti. Toto náhradné riešenie však vylučuje záväzkové transakcie s nulovým poplatkom, ktoré na prenos vyžadujú podriadenú transakciu s poplatkom. Problém nahlásil Project Loupe.

● LND #11456 štandardne deaktivuje poslucháče Multipath TCP (MPTCP) s cieľom

zmierniť CVE-2026-98432, zraniteľnosť jadra Linuxu, pri ktorej bolo pomocou MPTCP demonštrované vzdialené spustenie kódu. Go 1.24 a novšie verzie tieto poslucháče štandardne aktivujú na podporovaných systémoch Linux, čo by mohlo ohroziť prevádzkovateľov LND, aj keby MPTCP výslovne nekonfigurovali. Táto zmena nastavuje `multipathtcp=0` predvolené nastavenia LND v jazyku Go. Tým sa blokuje preukázaná cesta zneužitia cez poslucháče LND, ale nerieši sa základná chyba jadra. Postihnuté systémy stále vyžadujú opravené jadro. Prevádzkovatelia používajúci existujúce binárne súbory môžu uplatniť rovnaké zmierňujúce opatrenie reštartovaním LND s premennou prostredia `GODEBUG=multipathtcp=0`.

● LND #11357 sprísňuje overovanie faktúr BOLT11 v súlade s BOLT

#1357 (pozri spravodaj č. 428). Namiesto použitia prvého a ignorovania zvyšku teraz odmieta duplicitné polia s platobným tajným kľúčom, čím sa zabraňuje nejednoznačnosti medzi parsermi, ktoré vyberajú rôzne výskyty. Toto nadväzuje na skoršie odmietanie duplicitných platobných hashov (pozri spravodaj č. 425). Testy pridané v rámci aktualizácie špecifikácie tiež odhalili, že existujúce požiadavky neboli dodržiavané. Dekódovač teraz odmieta nesprávne dĺžky pri analýze platobného hashu, popisu hashu, platobného tajného kľúča a verejného kľúča príjemcu, namiesto toho, aby tieto polia považoval za chýbajúce. Predtým mohlo pole verejného kľúča príjemcu s nesprávnou veľkosťou spôsobiť, že LND prešlo na obnovenie kľúča z podpisu. V prípade faktúr obsahujúcich explicitný verejný kľúč príjemcu sa vyžaduje aj podpis ECDSA s nízkou hodnotou S. Toto obmedzenie sa však nevzťahuje na prípady, keď sa verejný kľúč obnoví z podpisu (pozri spravodaj č. 381).

● LND #11413 urýchľuje čistenie uložených výsledkov odchádzajúcich platieb

pri spustení na uzloch používajúcich SQLite alebo PostgreSQL. Počas bežnej prevádzky uzol zhromažďuje výsledok pre každý vyriešený, lokálne iniciovaný pokus o HTLC. Pri spustení odstraňuje výsledky, ktoré už nie sú potrebné. Predtým čítanie a mazanie záznamov jednotlivo vyžadovalo opakované prístupy k databáze, čo mohlo spôsobiť, že čistenie trvalo hodiny na vyťaženom uzle používajúcom vzdialený PostgreSQL. Teraz čistenie zoskupuje databázové operácie do dávok, pričom zachováva výsledky potrebné na obnovenie nevybavených platieb.

● LND #11151 pridáva kontroly nadmerných poplatkov za záväzky a nedostatočných

počiatočných zostatkov pri prijímaní prichádzajúcich kanálov. LND teraz odmieta navrhovanú výšku poplatku, ktorá presahuje vyššiu z nasledujúcich hodnôt: desaťnásobok odhadu za tri bloky alebo 100 sat/vbyte. Takisto vynucuje pravidlo počiatočnej rezervy BOLT2 a samostatne odmieta kanály, pri ktorých počiatočný zostatok žiadnej zo strán neprekračuje rezervu, ktorú táto strana musí udržiavať. Hoci iniciátor platí záväzný poplatok, nadmerný poplatok môže vyčerpať jeho použiteľný zostatok, čím sa počas otvárania kanála premrhá kapacita čakajúcich transakcií príjemcu a po potvrdení finančnej transakcie zostane nepoužiteľný kanál. Toto dopĺňa kontroly minimálnej sadzby poplatkov, o ktorých sme písali v spravodajstve č. 429.

● Rust Bitcoin #7067 rozširuje pomocné funkcie pre hash podpisu taproot

(sighash) tak, aby akceptovali voliteľnú prílohu a v prípade výdavkov typu scriptpath aj pozíciu opkódu posledného OP_CODESEPARATOR vykonaného pred kontrolou podpisu. Obe ovplyvňujú správu, ku ktorej sa podpis viaže. Predtým tieto pomocné funkcie predpokladali, že neexistuje žiadna príloha a neboli vykonané žiadne `OP_CODESEPARATOR`, takže volajúci, ktorí spracovávali takéto výdavky, museli použiť všeobecnejšiu funkciu sighash, aby sa vyhli vytvoreniu nesprávneho súhrnu. Pomocné funkcie teraz prijímajú tieto hodnoty priamo, hoci volajúci musia naďalej určiť pozíciu oddeľovača. Volajúci, ktorí spracovávajú výdavky bez prílohy alebo bez vykonaného `OP_CODESEPARATOR` môžu odovzdať `None` pre nové argumenty, aby zachovali predchádzajúce správanie. Pozrite si Newsletter č. 427, kde nájdete súvisiace zmeny v rozhraní API funkcie sighash pre staršie výdavky a výdavky segwit v0 .