Zpravodaj tento týden odkazuje na diskuzi o inkrementálním mutačním testování v Bitcoin Core a ohlašuje nasazení nového procesu přijímání BIPů. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a s popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Inkrementální mutační testování v Bitcoin Core: Bruno Garcia zaslal do fóra Delving Bitcoin příspěvek o své práci na zlepšení mutačního testování v Bitcoin Core. Mutační testování je technika, která vývojářům umožňuje vyhodnotit efektivitu testů tím, že záměrně do kódu přidává drobné chyby zvané mutanti (mutants). Pokud test selže, je mutant považován za zabitý, čímž signalizuje, že test tuto chybu dokáže odchytit. V opačném případě mutant přežije a odhalí tak možnou chybu v testu.

  Mutační testování přineslo významné výsledky, které vedly k otevření pull requestů opravujících některé z mutantů. Avšak tento proces je náročný na zdroje; dokončit jej na části kódu trvá přes 30 hodin. To je důvod, proč se Garcia zabývá inkrementálním mutačním testováním, které aplikuje mutační testování postupně na základě změn v kódu od poslední analýzy. Ačkoliv je tento proces rychlejší, stále trvá příliš dlouho.

  A proto Garcia pracuje na zefektivnění inkrementálního mutačního testování Bitcoin Core na základě studie od Googlu. Tento přístup je založen na následujících principech:

  • Vyhýbat se nevhodným mutantům, např. takovým, které nemá smysl opravovat.

  • Sbírat odezvu od vývojářů s cílem upřesnit generování mutantů.

  • Reportovat pouze omezené množství nezabitých mutantů (sedm dle výzkumu Googlu).

  Garcia tento přístup otestoval na osmi různých pull requestech, posbíral zpětnou odezvu a navrhl změny na řešení mutantů.

  Na závěr Garcia vývojáře požádal, aby mu dali vědět, pokud by chtěli spustit na svých PR mutační test a poskytnout zpětnou odezvu.

• ● Aktualizace procesu přijímání BIPů: Po více než dvou měsících probíhající diskuze v emailové skupině a po dalším kole změn návrhu bylo tento týden zřejmé, že BIP3 dosáhl hrubého konsenzu. BIP3 nasazený ve středu tak nahradil BIP2 jako průvodce procesu přijímání BIPů. I když z velké části zůstává podoba procesu zachována, přináší BIP3 několik změn.

  Mimo jiné byl zavržen systém komentování, počet stavů BIPu byl snížen z devíti (Draft, Proposed, Active, Final, Rejected, Deferred, Withdrawn, Replaced a Obsolete) na čtyři (Draft, Complete, Deployed a Closed), byly změněny hlavičky preambule, typ BIPu Standards Track byl nahrazen typem Specification a některá subjektivní rozhodnutí byla přeřazena z editorů BIPů na autory či čtenáře.

  Přehled všech změn lze nalézt v BIP3.

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 30.2 je údržbovým vydáním opravujícím chybu, která mohla způsobit smazání celého adresář wallets během migrování nepojmenované zastaralé peněženky (viz zpravodaj č. 387). Též obsahuje několik dalších vylepšení a oprav (viz poznámky k vydání).

• ● BTCPay Server 2.3.3 je menším vydáním tohoto platebního procesoru s možností vlastního hostování. Přináší podporu pro transakce se studenou peněženkou pomocí API Greenfield (viz níže), odstraňuje zdroje kurzů pocházejících od CoinGecko a opravuje několik chyb.

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, Lightning BLIPs, Bitcoin Inquisition a repozitáři BINANA.

• ● Bitcoin Core #33819 přidává do rozhraní Mining (viz zpravodaj č. 310) novou metodu getCoinbaseTx(), která vrací všechna pole potřebná pro konstrukci mincetvorné transakce. Stávající metoda getCoinbaseTx() (která vracela serializovanou maketu transakce, kterou klient musel načíst a upravit) byla přejmenována na getCoinbaseRawTx a zastarána spolu s getCoinbaseCommitment() a getWitnessCommitmentIndex().

• ● Bitcoin Core #29415 přidává do RPC volání sendrawtransaction nový booleovský příznak privatebroadcast, který zveřejní transakci skrz krátkodobé Tor nebo I2P spojení, popř. skrz Tor proxy k jinému IPv4/IPv6 peer spojení. Cílem je ochrana soukromí původce transakce díky utajení jeho IP adresy a použití nových spojení pro každou transakci, což pomůže narušit vazby.

• ● Core Lightning #8830 přidává do nástroje hsmtool (viz zpravodaj č. 73, angl.) příkaz getsecret, který nahrazuje stávající příkaz getsecretcodex a přidává podporu pro obnovení uzlů vytvořených po změnách z verze 25.12 (viz zpravodaj č. 383, angl.). U nových uzlů vypíše tento nový příkaz BIP39 mnemonickou frázi pro daný soubor hsm_secret a u starších uzlů vypíše Codex32 řetězce. Plugin recover byl rozšířen o možnost používat mnemonické fráze.

• ● Eclair #3233 počíná používat nakonfigurované výchozí jednotkové poplatky v případě, kdy Bitcoin Core nemůže na testnet3 nebo testnet4 odhadnout poplatky kvůli nedostatečným datům. Tyto výchozí poplatky jsou aktualizovány, aby lépe odrážely aktuální hodnoty.

• ● Eclair #3237 předělává události životního cyklu kanálů, aby byly v souladu se splicingem a zero-conf kanály. Přidává události channel-confirmed, která signalizuje, že otevírací transakce nebo splice byly potvrzeny, a channel-ready, která signalizuje připravenost kanálu pro platby. Odstraněna byla událost channel-opened.

• ● LDK #4232 přidává podporu pro experimentální signalizační příznak accountable, který nahrazuje HTLC atestace dle návrhů BLIPs #67 a BOLTs #1280. LDK nastaví tento signál odpovědnosti na nulu u vlastních plateb a u přeposílaných plateb bez signalizace; u příchozích plateb tuto hodnotu odpovědnosti zkopíruje, pokud je přítomná. Podobné změny byly dříve učiněné též v Eclair a LND (viz zpravodaj č. 387).

• ● LND #10296 přidává do RPC příkazu EstimateFee pole inputs, které umožní odhadnout poplatek pro konkrétní vstupy namísto vstupů automaticky zvolených peněženkou.

• ● BTCPay Server #7068 přidává podporu pro transakce se studenou peněženkou pomocí API Greenfield. To umožňuje uživatelům generovat nepodepsaná PSBT a zveřejňovat externě podepsané transakce. Tato funkcionalita nabízí zvýšenou bezpečnost v automatizovaných prostředích a umožňuje sestavy, které splňují vysoké požadavky na dodržování právních předpisů.

• ● BIPs #1982 přidává BIP433, který specifikuje standardní výstup Pay-to-Anchor (P2A) a označuje utrácení tohoto výstupu za standardní.