Tento týden přinášíme oznámení o zodpovědném zveřejnění zranitelnosti postihující staré LN implementace a souhrn návrhu na mix opkódů pro kovenanty. Též nechybí naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními o nových vydáních a souhrnem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Zveřejnění proběhlé zranitelnosti LN spojené s falešným financováním: Matt Morehouse zaslal do emailové skupiny Lightning-Dev příspěvek s popisem zranitelnosti, kterou předtím zodpovědně zveřejnil a kterou ve svých posledních vydáních adresují všechny populární implementace LN. Abychom zranitelnosti porozuměli, představme si, že Bob provozující LN uzel obdrží od Malloryho žádost o otevření nového kanálu. Absolvují proces otevření kanálu až do bodu, ve kterém se od Malloryho očekává zveřejnění transakce financující kanál. Aby bylo možné kanál později používat, musí Bob uložit relevantní data a sledovat nové bloky pro dostatečné potvrzení této transakce. Pokud však Mallory transakci nikdy nezveřejní, plýtvá Bob úložištěm a zdroji vynaloženými na sledování bloků. Opakuje-li Mallory tento process tisíckrát nebo milionkrát, může přivést Bobův uzel až do bodu, kdy jej není možné vůbec používat a to včetně provádění citlivých operací nutných pro zabránění ztráty peněz.

    Během testování svého vlastního uzlu byl Morehouse schopen způsobit výrazné problémy Core Lightningu, Eclairu, LDK i LND, a to včetně dvou případů, které mohly podle našeho názoru vést ke ztrátě peněz mnoha uzlů. Morehousův popis odkazuje na PR, která tento problém adresují (včetně PR zmíněných ve zpravodajích č. 237 a č. 240) a vyjmenovává vydání, která tuto zranitelnost opravují:

    • Core Lightning 23.02
    • Eclair 0.9.0
    • LDK 0.0.114
    • LND 0.16.0

    V emailové skupině i na IRC se objevilo množství reakcí.

  • ● Kovenanty namíchané z TXHASH a CSFS: Brandon Black zaslal do emailové skupiny Bitcoin-Dev příspěvek s návrhem na variantu OP_TXHASH (viz zpravodaj č. 185, angl.) zkombinovanou s OP_CHECKSIGFROMSTACK, která by mohla poskytnout většinu funkcí OP_CHECKTEMPLATEVERIFY (CTV) a SIGHASH_ANYPREVOUT (APO) bez velkých nadbytečných onchain nákladů oproti původním jednotlivým návrhům. I když je návrh zajímavý sám o sobě, jeho vznik byl částečně motivován snahou „objasnit naše uvažování o [CTV a APO] jednotlivě i dohromady a potenciálně nás posunout směrem ke konsenzu na cestě […] k úžasným budoucím možnostem používání bitcoinu.” Návrh obdržel v emailové skupině několik reakcí, další příspěvky a diskuze se objevily ve fóru Delving Bitcoin.

Vybrané otázky a odpovědi z Bitcoin Stack Exchange

Bitcoin Stack Exchange je jedním z prvních míst, kde hledají přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme některé z otázek a odpovědí, které obdržely vysoký počet hlasů.

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 23.08 je nejnovějším hlavním vydáním této oblíbené implementace LN uzlu. Mezi novými funkcemi a opravami chyb je možnost změnit několik položek konfigurace uzlu bez nutnosti jej restartovat, podpora pro zálohu a obnovu seedu pomocí Codex32, nový experimentální plugin pro vylepšené hledání cest, experimentální podpora pro splicing a možnost platit lokálně generované smlouvy.

  • ● LND v0.17.0-beta.rc1 je kandidátem na vydání příští hlavní verze této populární implementace LN uzlu. Významnou novou experimentální funkcí plánovanou pro toto vydání, které by testování prospělo, je podpora „jednoduchých taprootových kanálů” popsaných v LND PR #7904 v rubrice s významnými změnami.

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

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 a Bitcoin Inquisition.

  • ● Bitcoin Core #27460 přidává nové RPC volání importmempool. Volání načte soubor mempool.dat a pokusí se do mempoolu přidat načtené transakce.

  • ● LDK #2248 přináší vestavěný systém, který může projektům používajícím LDK poskytnout sledování UTXO odkazovaných v gossip zprávách. LN uzly, které gossip zpracovávají, musí akceptovat pouze zprávy podepsané klíčem přidruženým k nějakému UTXO, jinak by mohly být donuceny zpracovávat a přeposílat spam nebo přeposílat platby přes neexistující kanály (což by vždy selhalo). Nový vestavěný UtxoSource funguje s LN uzly připojenými k lokální instanci Bitcoin Core.

  • ● LDK #2337 usnadňuje používání LDK pro budování strážních věží, které běží nezávisle na uživatelově peněžence, ale které mohou od uživatelova uzlu přijímat zašifrované transakce s LN pokutami. Strážní věž může z každé transakce v novém bloku extrahovat informace a pokusit se díky nim dešifrovat data přijatá dříve. Pokud rozšifrování uspěje, může strážní věž trestnou transakci zveřejnit. To chrání uživatele před protistranami publikujícími starý, neplatný stav kanálu v době uživatelovy nedostupnosti.

  • ● LDK #2411 a #2412 přidávají API pro konstrukci platebních cest pro zaslepené platby. PR odděluje kód pro onion zprávy (které zaslepené cesty používají) od samotných zaslepených cest. Následující PR #2413 vlastní podporu pro zaslepené cesty přidává.

  • ● LDK #2507 obchází dlouhotrvající problémy jiné implementace, které vedou ke zbytečnému nucenému zavření kanálu.

  • ● LDK #2478 přidává událost, která poskytuje informace o přeposílaném HTLC, které již bylo vyrovnáno, včetně kanálu, ze kterého přišlo, částky a velikosti poplatku.

  • ● LND #7904 přidává experimentální podporu „jednoduchých taprootových kanálů,” která umožní používat P2TR pro otevírací a commitment transakce. To s sebou také přináší podporu bezskriptového podepisování vícenásobnými elektronickými podpisy dle MuSig2. Sníží to váhu transakce a vylepší soukromí v případě kooperativního zavření. LND nadále používá výhradně HTLC, díky čemuž mohou být platby začínající v taprootovém kanálu i nadále přeposílány i uzly, které taproot kanály nepodporují.

    Toto PR sestává z 134 commitů, které byly předtím začleněny do pracovní větve z následujících PR: #7332, #7333, #7331, #7340, #7344, #7345, #7346, #7347 a #7472.