Zpravodaj tento týden shrnuje analýzu několika návrhů na upgradování LN kanálů bez nutnosti je zavřít a znovu otevřít, diskutuje obtíže v zajištění korektních výplat odměn těžařům v poolech, odkazuje na diskuzi o bezpečném používání PSBT pro tiché platby, oznamuje návrh BIPu pro miniscript a shrnuje návrh na využívání časté změny zůstatku LN kanálu k simulaci kontraktů s cenovými futures. Též nechybí naše pravidelné rubriky se souhrnem změn ve službách a klientech, 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

  • ● Upgradování existujících LN kanálů: Carla Kirk-Cohen zaslala do fóra Delving Bitcoin příspěvek, ve kterém shrnuje a analyzuje současné návrhy na upgradování existujících LN kanálů. Upgrade slouží k přidání podpory nových funkcí. Zkoumá řadu rozličných případů, např:

    • ● Změny parametrů: v současnosti jsou některá nastavení kanálu dojednána mezi stranami a nemohou být později změněna. Změna parametrů by umožňovala případné nové vyjednávání o nastavení, například by mohly uzly chtít změnit množství satoshi, při kterém začnou ořezávat HTLC, nebo výši rezerv kanálu, kterou od protistrany očekávají jako pojistku proti jeho zavření ve starém stavu.

    • ● Změny commitmentů: commitment transakce v LN umožňují, aby jednotlivec mohl poslat současný stav kanálu do blockchainu. Změny commitmentů by umožnily kanálům založeným na P2WSH přepnout na anchor výstupy a v3 transakce a jednoduchým taprootovým kanálům na PTLC.

    • ● Obměna financování: LN kanály jsou v blockchainu ukotvené ve financující transakci, jejíž výstup je offchain opakovaně utrácen jako commitment transakce. Původně používaly všechny financující transakce P2WSH výstup, avšak novější možnosti jako PTLC vyžadují P2TR výstupy.

    Kirk-Cohen srovnává předchozí tři návrhy upgradování kanálů:

    • ● Dynamické commitmenty: jak popisuje návrh specifikace, umožňují změnit téměř všechny parametry kanálu a navíc poskytují všeobecný způsob upgradování financování a commitment transakcí díky nové „kickoff” transakci.

    • ● Upgrade po splicu: tato myšlenka umožňuje, aby splicingová transakce, která již nezbytně aktualizuje onchain financování kanálu, mohla též změnit typ použitého financování a volitelně formát commitment transakce. Přímo se netýká změn parametrů kanálu.

    • ● Upgrade při opakovaném navázání spojení: jak popisuje návrh specifikace, tento způsob umožňuje změnit několik parametrů kanálu během opakovaného navázání spojení mezi dvěma uzly. Přímo se netýká financování a upgradu commitment transakce.

    Kirk-Cohen dále v tabulce porovnává všechny možnosti: vypisuje jejich onchain náklady, výhody a nevýhody. Též je porovnává s onchain náklady v případě, pokud žádný upgrade nenastane. Mezi jejími závěry nechybí: „Myslím, že má smysl začít pracovat na upgradování parametrů i commitmentů pomocí dynamických commitmentů, bez ohledu na naši volbu způsobu upgradování na taprootové kanály. To nám dává možnost upgradovat na option_zero_fee_htlc_tx anchor kanály a poskytnout mechanismus upgradování formátů commitmentů, který může být použit pro V3 kanály (jakmile budou specifikovány).”

  • ● Obtíže s odměňováním těžařů v poolech: Ethan Tuttle zaslal do fóra Delving Bitcoin příspěvek s návrhem, aby mohly těžební pooly odměňovat těžaře ecashovými tokeny poměrně k počtu vytěžených share. Těžaři by hned nato mohli tokeny prodat či přeposlat nebo by mohli počkat, až pool vytěží blok, načež by pool směnil tokeny za satoshi.

    Mezi reakcemi nechyběla kritika i další návrhy. Obzvláště zajímavou jsme shledali reakci Matta Coralla, ve které popisuje základní problém: neexistují standardizované platební metody implementované velkými pooly, které by těžařům umožnily v krátkých intervalech spočítat své odměny. Dva rozšířené způsoby výplat odměn jsou:

    • ● Platba za share (PPS): vyplácí těžařovi odměnu v poměru za množství vykonané práce, i pokud není nalezen žádný blok. Spočítat poměrnou výši odměny těžařovi za odměnu za vytěžený blok je snadné, avšak spočítat ji za transakční poplatky je složitější. Corallo poznamenává, že většina poolů používá průměr poplatků posbíraných během dne, ve kterém byl share vytvořen. Znamená to, že výše odměny za share nemůže být ve stejný den spočítána. Pooly mohou navíc průměrem poplatků různými způsoby manipulovat.

    • ● Platba za posledních n share (PPLNS): odměňuje těžaře za share nalezené blízko okamžiku nalezení bloku. Avšak těžař si může být jist, že pool nalezl blok, pouze, pokud jej nalezl tento těžař sám. Neexistuje způsob (v krátkém časovém horizontu), kterým by mohl běžný těžař ověřit, že mu pool vyplácí korektní odměny.

    Kvůli těmto chybějícím informacím nejsou těžaři schopni rychle přepínat mezi jednotlivými pooly, pokud zjistí, že jejich hlavní pool je začíná na odměnách krátit. Stratum v2 řešení nenabízí, avšak čestné pooly mohou použít standardizované zprávy k informování těžařů, že se chystají přestat za share platit. Corallo dále odkazuje na návrh změny Stratum v2, která by těžařům umožnila ověřit, že za své share obdrželi korektní odměny, což by alespoň těžařům poskytlo možnost po delší době (hodiny až dny) odhalit, že je pool krátí na výplatách.

    V době psaní diskuze stále probíhala.

  • ● Diskuze o PSBT pro tiché platby: Josie Baker započal na fóru Delving Bitcoin diskuzi o rozšíření PSBT pro tiché platby (SP) dle návrhu specifikace od Andrew Totha. PSBT pro SP mají tato dvě hlediska:

    • ● Platby na SP adresy: výstupní skript transakce závisí zároveň na adrese tiché platby a na vstupech transakce. Jakákoliv změna vstupů v PSBT může potenciálně způsobit, že nebudou standardní peněženky schopné SP výstup utratit. Je tedy nutná dodatečná validace PSBT. Některé druhy vstupů nemohou být v SP používané, i toto musí být validováno.

      Pro vstupy, které použité být mohou, potřebuje mít SP logika přístup k jejich soukromým klíčům, které však peněženka nemusí mít k dispozici, jsou-li její klíče uložené v hardwarovém podpisovém zařízení. Baker popisuje schéma, které by plátci umožnilo vytvořit SP výstupní skript bez soukromého klíče, avšak hrozí s ním možnost úniku soukromého klíče, implementace v hardwarových podpisových zařízeních se tedy zřejmě neuskuteční.

    • ● Utracení dříve obdržených SP výstupů: PSBT budou must obsahovat sdílený tajný kód, který se používá k tweaknutí klíče pro utracení. Může se jednat o nové PSBT pole.

    Diskuze v době psaní nadále probíhala.

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.

  • ● Zdroje k tichým platbám: Bylo ohlášeno několik nových zdrojů na téma tiché platby včetně informační webové stránky silentpayments.xyz, dvou typescriptových knihoven, backendu založeného na Go, webové peněženky a dalších. Doporučujeme opatrnost, neboť většina tohoto software je nová, v beta verzi či v aktivním vývoji.

  • ● Cake Wallet přidává tiché platby: Cake Wallet nedávno ohlásila, že její nejnovější beta verze podporuje tiché platby.

  • ● Ověření konceptu coinjoinu bez koordinátora: Emessbee je ověřením konceptu pro vytváření coinjoinových transakcí bez ústředního koordinátora.

  • ● OCEAN přidává podporu pro BOLT12: Těžební pool OCEAN používá jako součást svého řešení výplat po LN podepsané zprávy pro propojení bitcoinové adresy a BOLT12 nabídky.

  • ● Coinbase přidává podporu pro Lightning: Coinbase přidal podporu pro lightningové vklady a výběry za pomoci lightningové infrastruktury od Lightspark.

  • ● Ohlášeny nástroje pro bitcoinová svěřenectví: Tým BitEscrow ohlásil sadu vývojových nástrojů pro implementování nekustodiálních bitcoinových svěřenectví třetí stranou (escrow).

  • ● Block žádá těžařskou komunitu o zpětnou vazbu: V aktualizaci o vývoji svého 3nm čipu vyzývá Block těžařskou komunitu o poskytnutí zpětné vazby mimo jiné k funkcím software těžebního hardware a údržbě.

  • ● Vydána peněženka Sentrum: Sentrum je peněženka umožňující pouze sledování (watch-only), která podporuje různé kanály pro notifikace.

  • ● Stack Wallet přidává podporu pro FROST: Stack Wallet v2.0.0 přidává podporu pro FROST, schéma prahového vícenásobného elektronického podpisu, díky použití rustové knihovny Modular FROST.

  • ● Ohlášen nástroj pro zveřejňování transakcí: Pushtx je jednoduchý rustový program, který odesílá transakce přímo do bitcoinové P2P sítě.

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 Inquisition 27.0 je nejnovějším hlavním vydáním tohoto forku Bitcoin Core navrženého pro testování soft forků a jiných významných změn protokolu na signetu. Novinkou tohoto vydání je vynucování OP_CAT dle specifikace v BIN24-1 a BIP347. Dále byl přidán „do bitcoin-util nový příkaz evalscript, který může otestovat chování opkódu skriptu.” Odstraněna byla podpora pro annexdatacarrier a pseudo dočasné anchory (viz zpravodaje č. 244 a č. 248).

  • ● LND v0.18.0-beta.rc2 je kandidátem na vydání příští hlavní verze této populární implementace LN uzlu.

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 #27101 přináší podporu pro požadavky a odpovědi dle JSON-RPC 2.0. Server nově vždy vrátí HTTP 200 "OK", pokud nenastane chyba HTTP nebo není chybně formátovaný požadavek. Vrací buď pole error nebo result, nikdy však oboje. Jediný i dávkovaný požadavek používají stejný způsob nakládání s chybami. Není-li v těle požadavku specifikována verze 2.0, bude použit stávající protokol JSON-RPC 1.1.

  • ● Bitcoin Core #30000 používá pro indexování záznamů v TxOrphanage wtxid namísto txid, aby mohl obsahovat skupinu transakcí se stejným txid. Sirotčinec (orphanage) je prostor s omezenou velikostí, který Bitcoin Core používá k ukládání transakcí odkazující na rodičovské transakce, ke kterým aktuálně nemá Bitcoin Core přístup. Přijme-li později odkazovanou rodičovskou transakci, může tohoto potomka dále zpracovat. Příležitostné přijetí balíčku s jedním rodičem a jedním potomkem (1p1c) pošle nejdříve potomka (v očekávání, že bude uložen v sirotčinci) a nato pošle rodiče; díky tomu je možné zvážit jejich poplatek dohromady.

    Avšak když byl kód příležitostného 1p1c začleněn (viz zpravodaj č. 301), bylo známo, že může útočník čestnému uživatelovi zabránit v používání této možnosti tím, že zveřejní verzi potomka transakce s nevalidními daty ve witnessu. Tento znetvořený potomek by měl stejné txid jako čestný potomek, ale neprošel by po přijetí rodiče validací. Kvůli tomu by nemohl potomek přispět na poplatek (CPFP), který by byl nutný pro akceptování balíčku.

    Jelikož byly dříve transakce v sirotčinci indexovány pomocí txid, byla v sirotčinci uložena první přijatá verze transakce s konkrétním txid. Útočník, který byl schopen zveřejnit transakce rychleji a častěji než čestný uživatel, tak mohl čestného uživatele donekonečna blokovat. Po této změně může být přijato více transakcí se shodnými txid, které se však liší v obsahu witnessu a generují tak odlišná wtxid. V okamžiku přijetí rodičovské transakce má uzel dostatek informací na odstranění znetvořeného potomka a může tak akceptovat potomka validního. Toto PR bylo dříve diskutováno v PR Review Clubu shrnutém ve zpravodaji č. 301.

  • ● Bitcoin Core #28233 stavějící na #17487 odstraňuje každodenní periodické zapisování na disk a čistění mezipaměti horkých mincí (UTXO). Před #17487 snižovalo časté zapisování na disk riziko, že by bylo po pádu uzlu či hardwaru nutné podstoupit zdlouhavý process obnovy indexu. Po #17487 mohou být nová UTXO zapsána na disk bez nutnosti vyprázdnění mezipaměti (ta i nadále musí být vyprázdněna v případě nedostatku paměti). Horká mezipaměť ve výchozím nastavení téměř zdvojnásobuje rychlost validace bloku, vyšších rychlostí je možné dosáhnout alokováním dodatečné paměti.

  • ● Core Lightning #7304 přidává řešení pro situace, kdy invoice_requests nemůže nalézt cestu k uzlu určenému v reply_path. Démon connectd otevře k dotyčnému uzlu dočasné TCP/IP spojení a doručí onion zprávu obsahující fakturu. Tato změna navyšuje interoperabilitu s LDK a navíc umožňuje používat onion zprávy i v situacích, kdy jsou podporovány pouze několika málo uzly (viz zpravodaj č. 283).

  • ● Core Lightning #7063 činí bezpečnostní multiplikátor poplatků dynamickým, aby lépe odrážel předpokládané nárůsty poplatků. Multiplikátor se snaží zajistit, aby transakce platily dostatečně vysoké poplatky na dosažení včasné konfirmace, ať napřímo (u transakcí, jejichž poplatky nemohou být navýšeny později) či pomocí navyšování poplatků. Multiplikátor nyní začíná na dvojnásobku aktuálního odhadu v době nízkých poplatků (1 sat/vbyte) a s poplatky blížícími se k maxfeerate se postupně snižuje až na 1,1násobek.

  • ● Rust Bitcoin #2740 přidává do modulu pow funkci from_next_work_required, která z předaného CompactTarget (předchozí cíl složitosti), timespan (časový rozdíl mezi aktuálním a předchozími bloky) a Params (parametry sítě) vypočítá nový CompactTarget představující příští cíl složitosti. Algoritmus implementovaný touto funkcí je založen pow.cpp z Bitcoin Core.