Zpravodaj tento týden oznamuje návrh BIPu pro formát kvantově bezpečných bitcoinových adres a obsahuje naše pravidelné rubriky se souhrnem Bitcoin Core PR Review Clubu, oznámeními nových vydání a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

Bitcoin Core PR Review Club

V této měsíční rubrice shrnujeme nedávné sezení Bitcoin Core PR Review Club a vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.

Nemaž opakovaně indexy při pokračování předchozí reindexace je PR od TheCharlatan, které snižuje startovací dobu, pokud uživatel restartuje uzel ještě před dokončením reindexace.

Bitcoin Core implementuje pět indexů. Vyžadované jsou indexy množiny UTXO a bloků, indexy transakcí, filtru kompaktních bloků a coinstats index jsou volitelné. Pokud je program spuštěn s volbou -reindex, všechny indexy jsou vymazány a přepočítány. Tento proces může trvat dlouho a není zaručeno, že skončí před ukončením programu.

Jelikož uzel potřebuje aktuální množinu UTXO a index bloků, je stav jejich reindexace zapisován na disk. Na začátku reindexace je aktivován příznak a deaktivován bude pouze po dokončení reindexace. Tímto způsobem může uzel při svém startu detekovat, že by měl pokračovat v reindexaci, i když uživatel neposkytl volbu.

Když je uzel restartován (bez volby -reindex) po nedokončené reindexaci, jsou vyžadované indexy zachovány a bude se v nich pokračovat. Před tímto PR byly volitelné index vymazány znovu. Díky Bitcoin Core #30132 může být start uzlu efektivnější, jelikož tyto volitelné index nejsou vymazány, pokud to není nutné.

  • Jakou změnu chování přináší toto PR?

    Chování se mění ve třech aspektech. Zaprvé, dle záměru tohoto PR, se již při restartu po nedokončené reindexaci nebudou mazat volitelné indexy. Tím bude chování volitelných indexů totožné s vyžadovanými. Zadruhé pokud uživatel vyvolá reindexaci přes GUI, nebude již tento požadavek ignorován. Tím se opraví nenápadná chyba představená v b47bd95. Zatřetí je odstraněna logovací zpráva “Initializing databases…\n”. ➚

  • Jakými dvěma způsoby zpracovávají volitelné indexy nové bloky?

    Když se inicializuje volitelný index, zkontroluje, zda-li je jeho nejvyšší blok shodný s aktuálním nejvyšším blokem blockchainu. Pokud není, nejdříve zpracuje všechny chybějící bloky v rámci synchronizace na pozadí (pomocí BaseIndex::StartBackgroundSync()). Další bloky bude potom zpracovávat rozhraním validace pomocí ValidationSignals::BlockConnected. ➚

  • Jaký dopad má toto PR na logiku zpracovávání nových bloků u volitelných indexů?

    Před tímto PR vymazání volitelných indexů bez vymazání stavu řetězce znamenalo, že byly tyto indexy považovány za nesynchronizované. Dle předchozí otázky to znamená, že nejdříve provedou synchronizaci na pozadí a poté přepnou do rozhraní validace. S tímto PR zůstávají volitelné indexy synchronizované se stavem řetězce, žádná synchronizace na pozadí tak není potřebná. Poznámka: synchronizace na pozadí začíná až po dokončení reindexace, zpracování validačních událostí se děje paralelně. ➚

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.

  • ● Core Lightning 24.05 je vydáním příští hlavní verze této populární implementace LN uzlu. Obsahuje vylepšení, díky kterým lépe funguje s ořezanými plnými uzly (viz zpravodaj č. 300), umožňuje RPC volání check fungovat s pluginy (viz zpravodaj č. 302), přináší vylepšení stability (popsáno například ve zpravodajích č. 303 a č. 304), umožňuje robustnější doručování nabídek (viz zpravodaj č. 304) a opravuje přeplácení na poplatcích, pokud je použita konfigurační volba ignore_fee_limits (viz zpravodaj č. 306).

  • ● Bitcoin Core 27.1 je údržbovým vydáním této převládající implementace plného uzlu, která obsahuje opravy několika 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, Bitcoin Inquisition a repozitáři BINANA.

  • ● Bitcoin Core #29496 navyšuje hodnotu konstanty TX_MAX_STANDARD_VERSION na 3, čímž činí standardními do potvrzení topologicky omezené (TRUC) transakce. Je-li verze transakce rovná hodnotě 3, bude s ní nakládáno jako s TRUC transakcí dle specifikace v BIP431. Hodnota CURRENT_VERSION zůstává 2, peněženka tedy TRUC transakce zatím vytvářet nebude.

  • ● Bitcoin Core #28307 opravuje chybu, která aplikovala maximální velikost P2SH skriptu (520 bajtů) i na redeem skripty u P2SH-segwit i bech32. Díky opravě je možné vytvářet multisig deskriptory výstupů s více než 15 klíči (až do 20 klíčů, což je limit konsenzu pro OP_CHECKMULTISIG) včetně jejich podepisování.

  • ● Bitcoin Core #30047 refaktoruje reprezentaci limitu počtu znaků (charlimit) bech32 kódování z konstanty 90 na výčtový typ. Díky tomu je snadné podporovat nové typy adres, které používají bech32 kódování, ale nemají stejný limit počtu znaků, jako definuje BIP173. Například bude možné zpracovávat adresy tichých plateb, které vyžadují až 118 znaků.

  • ● Bitcoin Core #28979 přidává do dokumentace RPC příkazu sendall (viz zpravodaj č. 194, angl.) informaci, že vedle potvrzených výstupů utrácí i nepotvrzené. Jsou-li nepotvrzené výstupy utracené, kompenzuje jakýkoliv schodek poplatku (viz zpravodaj č. 269). Tento odstavec byl po publikaci opraven.1

  • ● Eclair #2854 a LDK #3083 implementují BOLTs #1163, který odstraňuje požadavek na zaslání zprávy channel_update po neúspěšném doručení onion zprávy. Tento požadavek umožňoval útok, ve kterém přeposílající uzel, který vygeneroval chybový status neúspěšného doručení, mohl identifikovat odesílatele HTLC díky channel_update, čímž narušil odesílatelovo soukromí.

  • ● LND #8491 přidává do lncli RPC příkazů addinvoice a addholdinvoice volbu cltv_expiry, která umožní uživatelům nastavit hodnotu min_final_cltv_expiry_delta (CLTV expiry delta pro poslední část cesty). V popisu změny není uvedena motivace, mohlo by to však být v reakci na nedávné navýšení výchozí hodnoty z 9 na 18 bloků dle BOLT2 specifikace (viz zpravodaj č. 284).

  • ● LDK #3080 rozděluje create_blinded_path v MessagerRouter do dvou metod: jednu pro tvorbu kompaktních zaslepených cest a druhou pro běžné zaslepené cesty. Volající si tedy může zvolit podle potřeby. Kompaktní zaslepené cesty používají krátké identifikátory kanálů (SCID), které odkazují na financující transakci (nebo alias kanálu) a mají obvykle 8 bajtů. Běžné zaslepené cesty odkazují na LN uzel jeho 33bajtovým veřejným klíčem. Kompaktní cesty mohou být neaktuální, pokud je kanál uzavřen nebo podstoupil splicing, jsou tedy vhodnější pro krátkodobé QR kódy nebo odkazy, kde se nižší prostor ocení. Běžné cesty se upřednostňují u dlouhodobých případů použití včetně nabídek založených na onion zprávách, kde díky použití identifikátorů uzlů lze přeposílat zprávy spojením, ke kterým již neexistuje kanál (onion zprávy kanály nevyžadují). ChannelManager bude nově používat kompaktní zaslepené cesty pro krátkodobé nabídky a refundace, cesty pro odpovědi budou používat běžné zaslepené cesty.

  • ● BIPs #1551 přidává BIP353 se specifikací DNS platebních instrukcí. Tento protokol kóduje BIP21 adresy do TXT záznamů DNS. Protokol nabízí čitelnost instrukcí a možnost soukromého dotazování. Například example@example.com by mohl být přeložen na DNS adresu example.user._bitcoin-payment.example.com, která vrátí TXT záznam podepsaný pomocí DNSSEC a obsahující BIP21 URI, například bitcoin:bc1qexampleaddress0123456. Zpravodaj č. 290 obsahuje popis a minulé číslo zmiňuje začlenění BLIPu.

Poznámky

  1. Náš původní, zveřejnění popis Bitcoin Core #28979 tvrdil, že utrácení nepovrzených transakcí pomocí sendall byla změna chování. Děkujeme Gustavo Floresovi za jeho původní, správný popis (chybu zanesl editor zpravodaje). Mark „Murch” Edhardt chybu nahlásil, též mu děkujeme. ↩