Zpravodaj tento týden nahlíží na některá témata diskutovaná během nedávného setkání vývojářů LN. Též nechybí naše pravidelné rubriky s popisem změn v oblíbených klientech a službách, oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • Poznámky z LN summitu 2024: Olaoluwa Osuntokun zaslal do fóra Delving Bitcoin příspěvek se souhrnem svých poznámek (a dodatečným komentářem) z nedávné konference vývojářů LN. Mezi diskutovaná témata patřilo:

    • Commitment transakce verze 3: vývojáři diskutovali, jak používat nové možnosti v P2P včetně TRUC transakcí a P2A výstupů pro navýšení bezpečnosti LN commitment transakcí, které mohou být použity pro jednostranné uzavření kanálu. Diskuze se soustředila na rozličné kompromisy během navrhování.

    • PTLC: jsou dlouho navrhované jako způsob pro navýšení soukromí v LN i pro další možné účely jako například stuckless transactions. Byl diskutován nedávný průzkum kompromisů ohledně možných implementací PTLC (viz zpravodaj č. 268). Zvláštní důraz byl kladen na konstrukci signature adaptorů (např. pomocí skriptového multisigu v kontrastu s bezskriptovým MuSig2) a jejich dopadu na protokol commitmentů (viz další bod).

    • Protokol aktualizování stavu: byl diskutován návrh na změnu současného protokolu aktualizace stavu kanálů. Nyní je možné, aby kterákoliv strana navrhla aktualizaci stavu; nově by to měla být v danou chvíli jen jedna strana (viz též zpravodaje č. 120, angl., a č. 261). Je-li oběma stranám umožněno navrhnout aktualizaci, můžou návrh podat obě strany najednou. Takové situace by byly náročné na řešení a mohly by vést k nezamýšlenému zavření kanálu. Alternativou je, aby v daný okamžik mohla navrhnout aktualizaci jen jedna ze stran. Např. zprvu je pouze Alici umožněno navrhnout aktualizaci stavu. Pokud žádný návrh nepodá, může připustit k navrhování Boba. Když Bob ukončí své návrhy, může předat kontrolu zpět Alici. Takový protokol je snadnější na uchopení, odstraňuje problémy vzniklé souběžnými návrhy a usnadňuje protistraně nechtěné návrhy odmítnout. Podobný protokol by byl navíc lépe v souladu se signature adaptory založenými na MuSig2.

    • SuperScalar: vývojář návrhu jednoho konstruktu továren kanálů přednesl svůj návrh a obdržel zpětnou vazbu. Optech v budoucím čísle představí SuperScalar podrobněji.

    • Upgrade gossip protokolu: vývojáři diskutovali aktualizace gossip protokolu pro LN. Převážně jsou potřebné pro podporu nových typů zakládajících transakcí (např. jednoduché taprootové kanály), ale mohou být užitečné též pro přidání jiných schopností. Jedna z nich, o které se také diskutovalo, bylo přidání SPV dokladu (nebo jeho závazku) do zpráv oznamujících kanály. Díky tomu by mohly lehké klienty ověřit, že byla financující (nebo sponzorující) transakce začleněna do nějakého bloku.

    • Výzkum fundamentálních limitů: byl představen výzkum o platebních tocích, které kvůli limitům v síti (např. kanály s nedostatečnou kapacitou) nemohou skončit úspěšně (viz též zpravodaj č. 309). V případě nerealizovatelné LN platby mohou účastníci vždy přistoupit k onchain platbě. Avšak počet onchain plateb je omezen maximální vahou bloku, je tedy možné vypočítat maximální propustnost (počet plateb za sekundu) bitcoinu a LN dohromady vydělením maximálního počtu onchain plateb počtem neproveditelných LN plateb. Z tohoto hrubého vztahu vychází, že pro dosažení maximální propustnosti kolem 47 000 plateb za sekundu musí být poměr neproveditelnosti pod 0,29 %. Byly diskutovány dvě techniky redukce poměru neproveditelnosti: za prvé virtuální či skutečné kanály s více než dvěma účastníky, neboť více stran znamená více prostředků pro přeposílání a tedy vyšší míru proveditelnosti. Za druhé kanály s kreditem, kde důvěryhodné strany mohou mezi sebou přeposílat platby, aniž by je mohly vynutit onchain (ostatní jim stále důvěřovat nemusí).

    Osuntokun vyzval ostatní účastníky o korekce a rozšíření.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

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.

  • 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 #30955 přidává do rozhraní Mining (viz zpravodaj č. 310) dvě nové metody vyžadované pro podporu Stratum V2. Metoda submitSolution() umožňuje těžařům odeslat řešení bloku efektivněji: namísto celého bloku se odesílají pouze nonce, časové razítko, pole s verzemi a coinbasová transakce. Druhou metodou je getCoinbaseMerklePath(), která vrátí cestu Merkleovým stromem požadovanou zprávou NewTemplate. PR dále do kódu vrací BlockMerkleBranch odstraněnou v Bitcoin Core #13191.

  • Eclair #2927 přidává vynucování doporučených jednotkových poplatků (viz zpravodaj č. 323) při financování za běhu (viz zpravodaj č. 323) tím, že bude odmítat zprávy open_channel2 a splice_init, pokud používají jednotkový poplatek nižší.

  • Eclair #2922 odstraňuje podporu pro splicing bez předem iniciované chvíle ticha (quiescence, viz zpravodaj č. 309). Bude tak odpovídat poslední verzi protokolu z BOLTs #1160, která po každém uzlu požaduje během splicingu používat chvíli ticha.

  • LDK #3235 přidává do události ChannelForceClosed pole last_local_balance_msats, které obsahuje místní zůstatek uzlu těsně před vynuceným zavřením kanálu. Uživatel tak bude moci zjistit ztrátu milisatoshi způsobenou zaokrouhlováním.

  • LND #8183 přidává do struktury chanbackup.Single volitelné pole CloseTxInputs, které umožní přidat do souboru se statickou zálohou kanálu vstupy potřebné pro vygenerování transakce vynuceného zavření. Díky tomu budou moci uživatelé manuálně obdržet od offline spojení prostředky pomocí příkazu chantools scbforceclose jako poslední možnost. Uživatelé by měli být obzvláště opatrní, neboť by tato akce mohla vést ke ztrátě prostředků v případě, pokud od poslední zálohy nastala změna. PR dále přidává metodu ManualUpdate, která aktualizuje zálohu kanálů během ukončování LND.

  • Rust Bitcoin #3450 přidává v3 jako novou variantu verze transakce. Bitcoin Core nově považuje tyto transakce, označované též jako transakce do potvrzení topologicky omezené (TRUC), za standardní. Viz též zpravodaj č. 307.