Zpravodaj tento týden oznamuje plánované odhalení bezpečnostní zranitelnosti a připojuje naše pravidelné rubriky s popisem nových vydání a významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Nadcházející odhalení bezpečnostní zranitelnosti btcd: Antoine Poinsot zaslal do fóra Delving Bitcoin příspěvek s oznámením odhalení chyby konsenzu postihující plné uzly btcd plánované na 10. října. Z hrubého průzkumu aktivních plných uzlů Poinsot odhaduje, že kolem 36 btcd uzlů je stále zranitelných (i když 20 z nich též trpí zranitelností, která byla již odhalena, viz zpravodaj č. 286). V odpovědi potvrdil vývojář btcd Olaoluwa Osuntokun existenci zranitelnosti a její opravení ve verzi 0.24.2. Provozovatelé starší verze btcd jsou nabádáni k upgradu na poslední verzi, která byla označena za kritickou opravu.

Vydání nových verzí

Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, zvažte upgrade či pomoc s testováním.

  • ● Bitcoin Core 28.0 je nová hlavní verze této převládající implementace plného uzlu. Jedná se o první vydání podporující testnet4, příležitostné přeposílání balíčku s jedním rodičem a jedním rodičem (one-parent-one-child package relay, 1p1c). Dále přináší aktivované přeposílání transakcí do potvrzení topologicky omezených (TRUC), aktivované přeposílání pay-to-anchor transakcí, omezené RBF přeposílání balíčků a aktivovaný full-RBF. Byly přidány výchozí parametry pro assumeUTXO, což umožní použít RPC příkaz loadtxoutset k načtení množiny UTXO stažené mimo bitcoinovou síť (např. přes torrent). Vydání též obsahuje mnoho dalších vylepšení a oprav chyb. Pro podrobnosti viz poznámky k vydání.

  • ● BDK 1.0.0-beta.5 je kandidátem na vydání této knihovny pro budování peněženek a jiných aplikací s podporou bitcoinu. Tento kandidát „aktivuje ve výchozím nastavení RBF a klient bdk_esplora se bude po selhání opakovaně zkoušet znovu připojit. Balíček bdk_electrum také nově nabízí konfigurační příznak use-openssl.”

Významné změny kódu a dokumentace

Významné změny z tohoto týdne v Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Bitcoin Inquisition a repozitáři BINANA.

  • ● Bitcoin Core #30043 přináší vestavěnou implementaci Port Control Protocol (PCP) s podporou IPv6 pinholingu, který uzlům umožní dostupnost bez manuální konfigurace routeru. Tato změna nahrazuje stávající závislost libnatpmp pro mapování IPv4 portů s PCP a zároveň implementuje záložní mechanismus pro NAT Port Mapping Protocol (NAT-PMP). Ačkoliv je PCP / NAT-PMP ve výchozím nastavení neaktivní, v budoucích vydáních se to může změnit. Viz též zpravodaj č. 131 (angl.).

  • ● Bitcoin Core #30510 přidává k rozhraní Mining (viz zpravodaj č. 310) wrapper meziprocesové komunikace (IPC). To oddělenému Stratum v2 procesu umožní vytvářet, spravovat a odesílat šablony bloků připojením k procesu bitcoin-node (viz též zpravodaj č. 320). Bitcoin Core #30409 rozhraní Mining rozšiřuje o novou metodu waitTipChanged(), která detekuje nově příchozí blok a pošle tento blok připojeným klientům. RPC metody waitfornewblock, waitforblock a waitforblockheight nově tuto metodu používají.

  • ● Core Lightning #7644 přidává do nástroje hsmtool příkaz nodeid, který pro daný záložní soubor hsm_secret vrací identifikátor uzlu. Cílem je předejít nejasnostem při párování uzlů a jejich záloh.

  • ● Eclair #2848 implementuje rozšiřitelné inzeráty likvidity (liquidity advertisements) dle návrhu v BOLTs #1153. Umožní prodejcům ve svých zprávách node_announcement inzerovat ceny, za kterých jsou ochotni prodat likviditu. Kupující se potom k těmto uzlům mohou připojit a o likviditu požádat. Použity mohou být též k vytváření kanálů s oboustranným financováním či pro přidání likvidity k existujícím kanálům pomocí splicingu.

  • ● Eclair #2860 přidává volitelnou zprávu recommended_feerates, kterou mohou uzly použít k informování svých spojení o poplatcích, které považují za akceptovatelné a které si přejí použít pro otevírací transakce. Pokud uzel odmítne žádost o otevření, bude zřejmé, že tak bylo na základě nesouladu představ o poplatcích.

  • ● Eclair #2861 implementuje financování za běhu dle specifikace v BLIPs #36. Umožní klientům s nedostatečnou příchozí likviditou požádat o dodatečnou likviditu pomocí protokolu inzerování likvidity (viz PR výše) a platbu tak obdržet. Prodejce likvidity platí poplatky za onchain transakce u kanálů s oboustranným financováním nebo splicingu, ale později během routování platby je kupující zaplatí zpět. Pokud není platba za poplatek dostatečná, prodejce může transakci utratit podruhé a použít likviditu jinde.

  • ● Eclair #2875 implementuje kredit pro placení poplatku za otevření kanálu dle specifikace v BLIPs #41. Umožní klientům s financováním za běhu (viz PR výše) přijmout platby, které jsou příliš nízké na pokrytí onchain poplatků. Jakmile je nashromážděn dostatečný kredit na poplatky, může být použit k vytvoření onchain transakce např. pro financování či splicing. Klienti spoléhají, že poskytovatelé likvidity budou v budoucích transakcích tento kredit ctít.

  • ● LDK #3303 přidává do příchozí platby nové pole typu PaymentId. Záměrem je zlepšit idempotenci zpracování událostí, patřičné události během restartu uzlu tak budou zpracovány pouze jednou. Dříve se používal haš platby, který mohl vést k duplikovaným událostem. PaymentId je autentizační kód zprávy založený na haši (HMAC) identifikátoru kanálu a HTLC obsažených v těle platby.

  • ● BDK #1616 ve výchozím stavu signalizuje RBF v TxBuilder. Volající může signál změnit patřičným číslem sekvence.

  • ● BIPs #1600 přináší několik změn do specifikace BIP85, mezi které patří např. objasnění, že drng_reader.read (pro čtení náhodných čísel) je identifikátor funkce a ne její volání, a jasnější je také nakládání s pořadím bajtů. Dále byla přidána podpora pro testnet (včetně nově referenční implementace v Pythonu), upřesněno bylo vysvětlení formátu WIF pro import seedu do hierarchické deterministické peněženky, byl přidán kód pro portugalštinu a opravy se dočkaly testovací vektory. Byl též určen nový reprezentant této specifikace.

  • ● BOLTs #798 začleňuje specifikaci protokolu nabídek jako BOLT12. Též přináší několik aktualizací BOLT1 a BOLT4.