Zpravodaj Bitcoin Optech č. 430

Tento týdenní zpravodaj shrnuje pokračující diskusi o využití techniky „TCP hole punching“ k zajištění dostupnosti uzlů za domácími routery a popisuje návrh BIP zaměřený na standardizaci pravidel utrácení, která spolupodepisovatelé uplatňují při emulaci smluvních ujednání. Dále jsou zde zahrnuty naše pravidelné rubriky shrnující návrhy a diskuse o změnách konsensuálních pravidel bitcoinu, oznamující nové verze a kandidátské verze a popisující významné změny v populárním softwaru bitcoinové infrastruktury.

Novinky

• ● Pokračující diskuse o TCP hole punching pro domácí uzly: V návaznosti na

naše květnové shrnutí vlákna „Delving Bitcoin“ od 0xB10C o využití hole punching k tomu, aby uzly za domácími routery mohly přijímat spojení mezi sebou, 0xB10C zveřejnil, že práce na specifikaci a experimentální implementaci v Bitcoin Core byly obnoveny. Domácí uzly obvykle mohou navazovat pouze odchozí připojení a zapnutí mapování portů NAT-PMP ve výchozím nastavení v Bitcoin Core 30.0 nezajistilo, že by se z nich stalo mnohem více dostupných, jak se doufalo. „Hole punching“, při kterém dva domácí uzly naváží vzájemné spojení ve stejném okamžiku, aby každý router propouštěl provoz toho druhého, by byl doplňkem k přesměrování portů na základě principu „best-effort“. Větší počet dostupných poctivých uzlů by ztížilo útočníkům, jejichž uzly jsou snáze dosažitelné, zaplnit sloty pro odchozí připojení uzlu.

0xB10C shrnul čtyři dosud diskutované návrhy a navrhl novou variantu, která nevyžaduje koordinátora: uzel oznámí svou adresu pro „punch“ a dočasný veřejný klíč v novém typu addr v2 a každá dvojice uzlů odvodí stejný seznam kandidátů a načasování „punch“ ze svého sdíleného tajemství a z každého nového bloku. V reakci na námitku Anthonyho Townse, že útočník by mohl systém zaplavit skutečnými adresami, a poté, co později zjistil, že nedosažitelné uzly přijímají taková oznámení mnohem méně spolehlivě než naslouchající uzly, načrtl alternativu v podobě „nástěnky“, ve které naslouchající uzly uchovávají ověřené adresy domovských uzlů hledajících partnera.

Towns zpochybnil, zda náhodná příchozí připojení domácím uzlům vůbec pomáhají, a argumentoval, že „hole punching“ usnadňuje útočníkovi přímý přístup k poctivým uzlům, zatímco jen málo přispívá k zajištění připojení k poctivému uzlu. Odhadl, že útočník inzerující přibližně 10 000 adres by byl pro většinu poctivých uzlů snadným terčem, a navrhl krátkodobá připojení k náhodným partnerům jako alternativu s nižším rizikem . Jonathan Harvey-Buschel citoval data ukazující, že poctivé uzly jsou hůře dosažitelné než ty ovládané útočníky, a upřednostňoval koordinaci prostřednictvím vlastní služby Tor daného uzlu. Towns se později zeptal, zda nedávné zranitelnosti TCP a protokolů nedělají z nepřijímání příchozích připojení bezpečnější výchozí nastavení pro domácí uživatele. Diskuse pokračuje.

• ● Návrh BIP pro standardizované zásady utrácení spolupodepisovatelů: Luke Carriere

zveřejnil na webu Delving Bitcoin svůj návrh na standardizaci zásad utrácení prosazovaných spolupodepisovateli při emulaci smlouv. Několik nedávných návrhů, včetně Halsetha s anonymními spolupodepisovateli a delegací řetězcového kódu, definují každý své vlastní zásady, takže peněženka vytvořená pro jeden návrh nemůže používat spolupodepisovatele nebo orákulum vytvořené pro jiný návrh. Carriere nepožaduje pro tento návrh přidělení čísla BIP a zeptal se, zda je toto správná úroveň pro standardizaci.

Návrh se řídí několika návrhovými principy:

Vše, co lze vynutit pomocí skriptu Bitcoin, musí být vynuceno tam, přičemž zásady spolupodepisovatelů definují pouze to, co skript nedokáže.

• Vždy musí být k dispozici alespoň jedna cesta pro utracení, která nevyžaduje spolupodepisovatele.

Jak

• Způsob, jakým spolupodepisovatel ověřuje výdaj, a to, co zaručuje jeho poctivost, jsou

modulární profily volené podle jednotlivých zásad.

• Spolupodepisovatelé musí akceptovat osvědčení orákula ve formátu

DLC, aby již dostupná orákula mohla být znovu použita bez jakýchkoli úprav.

Zásada se skládá z pěti částí. Výstup definuje deskriptor Taproot, který obsahuje prostředky, skupina spolupodepisovatelů určuje, kteří spolupodepisovatelé se účastní a kolik z nich musí podepsat, šablony uvádějí seznam transakcí, které mohou spolupodepisovatelé podepsat, včetně jejich přesných výstupů, podmínky stanovují, co musí být splněno, než může být každá šablona podepsána, a profily určují režim ověřování, formáty důkazů a případný systém odpovědnosti. Některé body zůstávají otevřené, například zda pro serializaci použít JSON nebo TLV, zda by se mělo specifikovat slepé ověřování již nyní, nebo počkat na více zkušeností s implementací, zda specifikovat formát osvědčení výpisu v návrhu nebo ve specifikacích DLC a zda musí být záložní cesta časově uzamčena.

V následující diskusi PREDGE poukázalo na to, že jeden z profilů důkazů , nazvaný `statement-v0`, postrádá příznak konečnosti, což znamená, že spolupodepisovatel by mohl jednat na základě prozatímního osvědčení, které bylo později opraveno. Kromě toho tehiyadu uvedl, že hash politiky by se měl zavázat k přesné sémantice ověřovatele, aby se zabránilo tomu, že různé implementace přijímají stejné bajty, zatímco vynucují odlišné podmínky. Carriere s oběma body souhlasil a uvedl, že přidá příznak konečnosti a upřesní pravidla ověřovatele.

Změna konsensu

*Měsíční rubrika shrnující návrhy a diskusi o změně pravidel konsensu bitcoinu.*

• ● Pokračující diskuse o BIP54: Antoine Riard zveřejnil na

mailing listu Bitcoin-Dev svůj pohled na stav soft forku pro vyčištění konsensu (BIP54). Zákaz transakcí, jejichž velikost bez svědectví je přesně 64 bajtů, je stále nejkontroverznějším pravidlem. Implementace v Bitcoin Core je v současné době posuzována a testována a jedná se o referenční implementaci, na kterou odkazuje BIP (Bitcoin Core #35793). Tento PR povoluje nová pravidla v regtestu bez aktivace v mainnetu. Poukázal také na práci na interoperabilitě v btcd (btcd #2537) a uvedl, že neví o žádné implementaci v libbitcoin. Podle jeho názoru zbývá ještě další přezkoumání a testování, dokumentace, aby peněženky věděly o navrhovaném limitu 2 500 podpisových operací ve skriptu pre-segwit a o pravidle 64 bajtů, a teprve poté logika aktivace. Hovořil pouze za sebe a domníval se, že by bylo realistické začít uvažovat o aktivaci ve druhé polovině roku 2027, pokud se na tom do té doby komunita shodne.

Pieter Wuille aktualizoval své vlákno „Delving Bitcoin“ o tom, jak dvě pravidla časových razítek BIP54 omezují délku řetězce (viz Newsletter č. 425). První příspěvek nyní obsahuje přesný vzorec pro dolní hranici práce a jak tento vzorec, tak desetinná aproximace jsou nyní ověřeny v odkazovaném kódu Lean.

Riard navázal na námitku vznesenou během návrhu BIP54: že oprava chyby časového posunu by znemožnila změnu konsensu ve stylu Marka Friedenbacha forward blocks pro zbytek budoucí historie bitcoinu. Jelikož oprava manipulaci s časovými razítky spíše omezuje, než aby ji zcela odstranila, bylo by stále možné implementovat mnohem omezenější návrh „forward blocks“. Odhadl, že 7 200sekundové okno, které oprava stále umožňuje, by mohlo snížit obtížnost přibližně o 0,60 % za každé období přenastavení a zvýšit rychlost tvorby bloků přibližně o stejnou hodnotu, což je daleko od zvýšení kapacity původního návrhu. Riard také argumentoval, že tento nápad je neudržitelný i při starých pravidlech: validátoři by zpracovávali transakce jednou na dopředném řetězci a podruhé při synchronizaci na kompatibilním řetězci, a to za stejné poplatky, pokud by uživatelé neplatili dvakrát, a uzly, které neprovedly upgrade, by i tak musely stahovat nadbytečná data. Riard navrhne krátkou poznámku pod čarou k BIP54, ve které tento argument předloží, a požádá Friedenbacha o protiargumenty.

• ●

Prototyp ochrany proti opakovanému přehrání s možností zapnutí (opt-in) : Sjors Provoost navázal na vlákno na Delving Bitcoin o ochraně proti opakovanému přehrání s možností zapnutí v případě rozdělení řetězce (viz zpravodaj č. 420 ) s prototypem, který využívá novou verzi svědka. Příloha , jejíž užitečné zatížení začíná bajtem 0x01, označuje blok pomocí 4-bajtové výšky, a každý podpis na tomto vstupu se zavazuje k hashi bloku v požadovaném řetězci. Samotný hash v transakci není obsažen. Dodatečné náklady odhadl na 1,75 vbytes. Pojmenovaný blok musí být starý alespoň 100 bloků, což je stejný horizont jako splatnost coinbase. Uvedl, že pokud by se hashrate rozdělil rovnoměrně, čekání na rozdělení mincí by v nejhorším případě trvalo dva dny, protože pravidlo musí platit pouze na jedné straně. Navrhl vydat verzi witness společně s jiným návrhem, který ji vyžaduje, jako je CISA (BIP460), BIP360 nebo výstup ve stylu P2TRv2

s klíčovou cestou, kterou lze později deaktivovat.

Anthony Towns odpověděl, že nová verze s witnessem je zbytečná a že by stačilo nové kódování veřejného klíče pro kontrolu podpisu Taproot ve stylu BIP118. Provoost odpověděl, že toto kódování zvážil a považoval ho za provizorní řešení, a že podle jeho chápání by nefungovalo pro výdaj pomocí klíčové cesty.

Moonsettler zpochybnil, zda je požadavek na 100 bloků žádoucí v případě rozdělení, kde by na této funkci záleželo nejvíce, a navrhl, aby toto zpoždění zůstalo jako pravidlo, které by bylo možné uvolnit. Provoost odpověděl, že poté, co se coiny přesunou na rychlejší stranu a nashromáždí potvrzení, pomalejší strana již tuto ochranu nepotřebuje. Provoost také napsal, že očekává, že pravidlo bude nasazeno před sporným hard forkem, aby ho obě strany zdědily a aby ho žádná strana nemohla snadno zrušit: hash bloku je pouze ve zprávě podpisu, takže odstranění pravidla znamená změnu serializace transakce tak, aby obsahovala hash.

• ● QSAVE pro nemigrované coiny: James Tagg zveřejnil na

mailing listu Bitcoin-Dev pět návrhů BIP pro QSAVE (Quantum Secure Asset Verification and Escrow), což je postkvantový přechod, při kterém nedochází ke spálení coinů. Popsal je jako alternativu k BIP361 a k Hourglass. Z hlediska prosazování, které by mohlo být kdykoli aktivováno jako soft fork, by jakýkoli vstup, který není v registru známých postkvantových typů, byl považován za nemigrovaný, včetně neznámých a budoucích typů skriptů. Nemigrovaný vstup by i nadále musel splňovat podmínky svého uzamykacího skriptu a také druhý faktor: buď důkaz s nulovou znalostí, že jedno semeno odvozuje jak skript pro utracení, tak postkvantový klíč, nebo postkvantovou vazbu potvrzenou před datem ukončení. Pokud jakémukoli nemigrovanému vstupu v transakci chybí tento druhý faktor, musí být každý utratitelný výstup výstupem pro obnovení. V systému QSAVE neexistuje žádné časové omezení, takže chybějící druhý faktor minci nezničí. Důkaz v řetězci ji může vždy utratit přímo, bez zapojení třetí strany. Jinak popsal mimořetězcový proces pro ztracený majetek, jehož právní a ekonomické zacházení umístil mimo konsenzus, v němž by skupina decentralizovaných správců držela výstupy pro obnovení, s záložním správcem a kontrolorem s právem veta, a prostředky by mohly vynášet konzervativní výnos 0,5 % směřující na charitu. Návrhy také specifikují vodoznaky před cut-offem, volitelný klíč ML-DSA-87, který nazval QD5, a zk-STARK výdajový list pro výstupy BIP360 (P2MR) .

• ● Důkaz úbytku (Proof-of-decay) pro nemigrované výstupy: bitKingAE

zveřejnil na webu Delving Bitcoin návrh na zmenšování výstupů vystavených postkvantovým útokům, jako jsou rané P2PK mince, které nejsou přesunuty během ochranné lhůty. Po uplynutí ochranné lhůty by hodnota výstupu klesala podle harmonogramu v závislosti na výšce bloku. Ztracené satoshi by byly spáleny nebo vyplaceny jako odměny za těžbu, namísto toho, aby byly mince zmrazeny nebo ponechány tomu, kdo dokáže vytvořit podpis. Příklad v příspěvku počítal s malým procentem zůstatku každých 50 000 bloků. Vinicius Cestari odpověděl třemi námitkami: kvantový útočník může počkat až do konce lhůty a zmizet vystavené výstupy dříve, než k výraznému poklesu hodnoty dojde; náhlé zlepšení kvantových útoků je může vyčerpat ještě dříve; a tento plán snižuje zůstatek pasivního majitele, včetně toho, jehož klíče již byly odcizeny.

• ● Cenzura balíčků BIP300: Ori Newman argumentoval na

mailing listu Bitcoin-Dev, že těžař s 26 % hashrate může v návrhu drivechains (BIP300) na neurčito cenzurovat platný balíček výběrů. Napsal, že pokud těžař s 26 % hashrate odešle ALARM v každém bloku, který vytěží, každý z těchto bloků sníží skóre každého čekajícího balíčku o 1. Pokud by zbývajících 74 % hashrate hlasovalo pro balíček v každém bloku, jeho očekávané skóre by na konci 26 300 bloků činilo 12 624, což je méně než požadovaných 13 150. Navrhl zakázat ALARM a jakékoli jiné negativní hlasování, což by obnovilo předpoklad poctivé většiny: balíček podporovaný 51 % hashrate by téměř jistě prošel a ten podporovaný 49 % by téměř jistě neprošel. Pokud je současné pravidlo záměrné, požádal, aby BIP místo toho stanovil předpoklad poctivé většiny na 75 %. Označil to za výrazný odklon od bezpečnostního modelu bitcoinu a uvedl, že jedním z argumentů pro to je, že krádež prostředků by byla pro útočníka s méně než 75 % hashrate obtížnější.

Vydání a kandidátské verze

*Nové verze a kandidátské verze populárních projektů bitcoinové infrastruktury . Zvažte prosím upgrade na nové verze nebo pomoc s testováním kandidátských verzí.*

• ● LND v0.21.6-beta a v0.20.7-beta jsou bezpečnostní

verze pro větve 0.21 a 0.20 této oblíbené implementace uzlu LN . Obě obsahují opatření proti zranitelnosti jádra Linuxu CVE-2026-98432 popsané níže v LND #11456. Provozovatelé v systému Linux by měli provést aktualizaci, deaktivovat MPTCP na hostitelském počítači, aby ochránili ostatní služby, a nainstalovat opravené jádro, protože opatření LND neodstraňuje samotnou základní zranitelnost.

• ● Core Lightning 26.06.10 je bezpečnostní vydání této populární implementace uzlu LN

. Opravuje zranitelnosti v oblasti duálního financování, spojování transakcí, vyhodnocování HTLC v řetězci, řízení přístupu a dalších komponent. Zdrojový kód bezpečnostních oprav je k dispozici, zatímco související testy jsou dočasně pozastaveny, aby měli uživatelé více času na aktualizaci. Projekt důrazně doporučuje provést aktualizaci.

-

● BTCPay Server 2.4.7 je bezpečnostní aktualizace tohoto platebního procesoru pro vlastní provoz. Opravuje 85 bezpečnostních nálezů nahlášených programem OSS Scanner, včetně problémů týkajících se limitů výplat, přístupu k datům jiných obchodů, autentizace a vyčerpání zdrojů. Opravuje také problémy s účtováním plateb a spolehlivostí. Aktualizace se důrazně doporučuje, zejména u serverů sdílených více obchodníky.

Významné změny v kódu a dokumentaci

*Významné nedávné změny 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 pro nepodepsané transakce

a navýšení poplatků exportované z grafického uživatelského rozhraní. Bitcoin Core 32.1 exportoval tyto PSBT pomocí verze 2, což uživatelům znemožňovalo je podepisovat pomocí nástrojů, které podporují pouze verzi 0. Samostatný pracovní postup s externím podepisovačem nakonfigurovaný pomocí `-signer` (viz zpravodaj č. 138) nadále používá PSBTv2, takže tito uživatelé potřebují externí podpisový nástroj, který jej podporuje, například HWI 2.1.0 nebo novější.

• ● Bitcoin Core #35714 opravuje chybu, při které uzel mohl aktualizovat svůj index bloků

a databázi UTXO poté, co se nepodařilo zapsat data o blocích nebo zpětných operacích na disk. Ačkoli selhání signalizovalo uzlu, aby se vypnul, kód zpracovávající tyto zápisy mohl stále aktualizovat databáze předtím, než se uzel zastavil. Pokud by tyto aktualizace proběhly úspěšně, databáze by mohly zaznamenat stav, pro který podpůrný blok nebo data pro vrácení zpět ještě nebyla bezpečně uložena. To by mohlo vést k nekonzistentnímu lokálnímu stavu uzlu a zkomplikovat obnovu. Kód nyní při neúspěšném pokusu o vyprázdnění tyto zápisy do databáze přeskočí. To doplňuje dřívější ochrany pořadí vyprázdňování pro volitelné indexy, o nichž se psalo v zpravodaji č. 414.

• ● Bitcoin Core #35492 opravuje chybu, kdy `bitcoin-wallet dump` (viz

Newsletter č. 130) mohl hlásit úspěch i po zápisu neúplného exportu peněženky. Dříve příkaz kontroloval, zda se mu podaří otevřít cílový soubor, ale nezachytil následné chyby zápisu, jako například nedostatek místa na disku. V důsledku toho se uživatelé mohli mylně domnívat, že export byl dokončen, a teprve při pokusu o obnovení peněženky zjistili, že data chybí. Nyní příkaz ověřuje zápis, vyprázdnění a uzavření souboru. Hlásí selhání a odstraňuje neúplné soubory výpisu.

• ● BIP #2205, #2210 a #2212 přidávají tři návrhy

specifikací pro agregaci podpisů napříč vstupy. BIP458 specifikuje neinteraktivní poloviční agregaci, kombinující `n` stávající podpisy podle BIP340 do `32 × (n + 1)` bajtů namísto `64 × n` bajtů. BIP459 specifikuje DahLIAS, interaktivní protokol, který vytváří jediný 64-bajtový agregovaný podpis pro více klíčů a zpráv. BIP460 navrhuje použití těchto schémat pro výdaje typu keypath u výstupů nové verze svědka 2 výstupů, přičemž zachovává individuální podpisy pro výdaje typu „scriptpath“ a umožňuje vstupům typu „keypath“ se z agregace odhlásit. Od doby, kdy byl návrh popsán v zpravodaji č. 417 , byly odhlášené vstupy upraveny tak, aby používaly běžné podpisy podle BIP341 bez speciálního označení, což peněženkám umožňuje přijmout nový typ výstupu a zároveň znovu využít svou stávající logiku podepisování. To by snížilo velikost transakcí a poplatky u transakcí s více účastnícími se vstupy, včetně coinjoinů a payjoinů . Nasazení navrhované agregace transakcí by vyžadovalo soft fork. BIP460 ponechává mechanismus aktivace a parametry nespecifikované.

• ● Core Lightning #9419 přidává volitelné `failure_reason` pole do

`listforwards` RPC a `forward_event` oznámení pro lokálně neúspěšné pokusy o předání. Dříve se na stejný kód selhání protokolu vztahovalo několik různých problémů, což operátorům ztěžovalo určení příčiny neúspěšného předání. Nové pole rozlišuje mezi příčinami, jako je nedostatečná odchozí likvidita, offline odchozí peer a limity na počet nebo celkovou hodnotu čekajících HTLC.

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

tak, aby se po dvojím vrácení `unknown_next_peer`. Dříve každé selhání vylučovalo pouze nahlášený kanál, takže následné pokusy mohly nadále vybírat jiné kanály přes stejný uzel, dokud nevypršela doba pro opakování platby. Nyní, po druhém selhání ze stejného uzlu, `xpay` vyloučí tento uzel na úrovni soukromého `askrene` směrovací vrstvu. Tato heuristika může vyloučit použitelné kanály, ale omezuje opakované pokusy přes stejný uzel.

• ● LDK #5089 aktualizuje zvyšování poplatků při nuceném uzavření kanálů s

kotevními výstupy. Pokud LDK nemůže získat potřebné prostředky pro podřízenou transakci CPFP, která utratí kotevní výstup, vysílá nyní pouze závazkovou transakci. Dříve mohlo toto selhání vést k tomu, že nebyly vyslány žádné transakce, což zpožďovalo obnovení prostředků v kanálu. Závazek již obsahuje poplatek, který může být stále dostatečný pro potvrzení, pokud byl odhad poplatku konzervativní nebo pokud klesne poptávka v síti. Tento záložní postup však vylučuje závazkové transakce s nulovým poplatkem, které pro přenos vyžadují podřízenou transakci s poplatkem. Problém nahlásil Project Loupe.

• ● LND #11456 ve výchozím nastavení deaktivuje posluchače Multipath TCP (MPTCP), aby

zmírnil dopad CVE-2026-98432, zranitelnosti jádra Linuxu, u níž bylo pomocí MPTCP demonstrováno vzdálené spuštění kódu. Go 1.24 a novější tyto posluchače ve výchozím nastavení na podporovaných systémech Linux povolují, což by mohlo vystavit provozovatele LND riziku, i když MPTCP výslovně nenakonfigurují. Tato změna nastavuje `multipathtcp=0` výchozí nastavení LND v Go. Tím se zablokuje prokázaná cesta zneužití prostřednictvím posluchačů LND, ale neopravuje se základní chyba jádra. Postižené systémy stále vyžadují opravené jádro. Provozovatelé používající stávající binární soubory mohou uplatnit stejné zmírnění restartováním LND s proměnnou prostředí `GODEBUG=multipathtcp=0`.

• ● LND #11357 zpřísňuje ověřování faktur BOLT11 v návaznosti na BOLT

#1357 (viz Newsletter #428). Místo použití prvního a ignorování zbytku nyní odmítá duplicitní pole platebního tajemství, čímž zabraňuje nejednoznačnosti mezi parsery, které vybírají různé výskyty. Toto navazuje na dřívější odmítání duplicitních platebních hashů (viz zpravodaj č. 425). Testy přidané v rámci aktualizace specifikace rovněž odhalily, že stávající požadavky nebyly dodržovány. Dekodér nyní odmítá nesprávné délky při analýze platebního hash, popisu hash, platebního tajemství a veřejného klíče příjemce, místo aby tato pole považoval za chybějící. Dříve mohlo pole veřejného klíče příjemce s nesprávnou délkou způsobit, že LND přešlo k obnovení klíče z podpisu. U faktur obsahujících explicitní veřejný klíč příjemce je rovněž vyžadován podpis ECDSA s nízkou hodnotou S. Toto omezení však neplatí, pokud je veřejný klíč obnoven z podpisu (viz zpravodaj č. 381).

• ● LND #11413 urychluje úklid uložených výsledků odchozích plateb

při spuštění na uzlech používajících SQLite nebo PostgreSQL. Během běžného provozu uzel shromažďuje výsledek pro každý vyřešený, lokálně iniciovaný pokus o HTLC. Při spuštění odstraní výsledky, které již nejsou potřebné. Dříve vyžadovalo individuální čtení a mazání záznamů opakované databázové cykly, což mohlo způsobit, že čištění na vytíženém uzlu používajícím vzdálený PostgreSQL trvalo i několik hodin. Nyní čištění seskupuje databázové operace do dávek a zároveň zachovává výsledky potřebné k obnovení nevyřízených plateb.

• ● LND #11151 přidává kontroly nadměrných poplatků za závazky a nedostatečných

počátečních zůstatků při přijímání příchozích kanálů. LND nyní odmítá navrhovanou sazbu poplatku vyšší než desetinásobek odhadu za tři bloky nebo 100 sat/vbyte, podle toho, která hodnota je vyšší. Rovněž prosazuje pravidlo počáteční rezervy BOLT2 a samostatně odmítá kanály, u nichž počáteční zůstatek žádné ze stran nepřesahuje rezervu, kterou daná strana musí udržovat. Ačkoli iniciátor hradí závazný poplatek, nadměrný poplatek může vyčerpat jeho použitelný zůstatek, čímž se plýtvá kapacitou čekajícího kanálu příjemce během otevírání a po potvrzení finanční transakce zůstane nefunkční kanál. Toto doplňuje kontroly minimální sazby poplatků popsané v zpravodaji č. 429.

• ● Rust Bitcoin #7067 rozšiřuje pomocné funkce pro hash podpisu taproot

(sighash) tak, aby akceptovaly volitelnou přílohu a, v případě výdajů typu scriptpath, pozici opkódu posledního OP_CODESEPARATOR provedeného před kontrolou podpisu. Obojí ovlivňuje zprávu, ke které se podpis zavazuje. Dříve tyto pomocné funkce předpokládaly, že neexistuje žádný příloha a žádný provedený `OP_CODESEPARATOR`, takže volající, kteří zpracovávali takové výdaje, museli použít obecnější funkci sighash, aby se vyhnuli vytvoření nesprávného souhrnu. Pomocné funkce nyní tyto hodnoty přijímají přímo, i když volající musí stále určit pozici oddělovače. Volající, kteří zpracovávají výdaje bez přílohy nebo bez provedeného `OP_CODESEPARATOR` mohou předat `None` pro nové argumenty, aby zachovali předchozí chování. Viz Newsletter č. 427, kde jsou popsány související změny API funkce `sighash` pro starší výdaje a výdaje segwit v0 .