Tento týden popisujeme protokol pro zjednodušení komunikace v rámci kooperativního uzavření LN kanálu a přinášíme souhrn poznámek k nedávnému setkání vývojářů LN. Též nechybí naše pravidelné rubriky s oblíbenými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními o nových verzích a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Jednodušší zavírání LN kanálů: Rusty Russell zaslal do emailové skupiny Lightning-Dev příspěvek s návrhem na zjednodušení procesu, kterým dva LN uzly kooperativně zavírají kanál. V novém protokolu uzavírání kanálu informuje jeden z uzlů svou protistranu, že si přeje zavřít kanál, a určí výši transakčního poplatku, který zaplatí. Tento iniciátor uzavření bude zodpovědný za celý poplatek, avšak oba výstupy typické transakce kooperativního uzavření kanálu budou okamžitě utratitelné, kterákoliv strana tedy bude moci použít navýšení poplatku pomocí CPFP. Nový protokol má též kompatibilní způsob výměny informací s protokoly vícenásobného podpisu založenými na MuSig2, který jsou součástí vyvíjených vylepšení LN mající za cíl navýšení soukromí a snížení onchain nákladů.

  V době psaní neobdržel Russellův návrh v emailové skupině žádné komentáře, avšak pod jeho pull requestem se již několik reakcí objevilo.

• ● Poznámky k LN summitu: Carla Kirk-Cohen zaslala do emailové skupiny Lightning-Dev příspěvek se souhrnem diskuzí z nedávného setkání vývojářů LN v New Yorku. Mezi diskutovanými tématy bylo:

  • ● Spolehlivé potvrzování transakcí: přeposílání balíčků, přeposílání v3 transakcí, dočasné anchor výstupy, cluster mempool i další témata související s přeposíláním transakcí a těžbou byly předmětem diskuzí v kontextu hledání jasnější cesty ke spolehlivějšímu potvrzování onchain transakcí bez hrozby pinningu nebo nutnosti přeplácet během navyšování poplatků pomocí CPFP a RBF. Doporučujeme čtenářům zajímajícím se o pravidla přeposílání transakcí, která mají dopad na všechny protokoly druhé vrstvy, aby si přečetli poznámky obsahující zajímavé informace poskytnuté vývojáři LN.

  • ● Taproot a MuSig2 kanály: krátká diskuze o vývoji kanálů založených na P2TR výstupech a MuSig2 pro elektronické podpisy. Významná část poznámek se týká zjednodušeného protokolu kooperativního zavření kanálu, kterému jsme se věnovali v předchozím bodě.

  • ● Aktualizovaná oznámení o kanálech: gossip protokol LN v současnosti přeposílá oznámení o nových nebo aktualizovaných kanálech jen, pokud jsou tyto kanály financovány P2WSH výstupem se skriptem 2-ze-2 OP_CHECKMULTISIG. Abychom mohli začít používat P2TR výstupy a multisig commitmenty založené na MuSig2, musí být tento gossip protokol aktualizován. Jedním z diskutovaných témat během předchozího setkání LN vývojářů (viz zpravodaj č. 204) bylo, zda bychom měli učinit minimální aktualizaci protokolu (nazývanou gossip v1.5), která by pouze přidala P2TR výstupy, či širší aktualizaci protokolu (gossip v2.0), která by umožnila používat UTXO všech druhů. Pokud by mohl být použit jakýkoliv výstup, znamenalo by to, že výstup použitý pro oznámení kanálu nemusí být výstup, který je skutečně používán pro provoz kanálu. Tato vlastnost by porušila veřejnou vazbu mezi výstupy a financováním kanálů.

    Další diskutovanou myšlenkou bylo, zda by mělo být UTXO s hodnotou n umožněno oznamovat kanál s kapacitou větší než n. Díky tomu by mohli účastníci kanálu ponechat některé z otevíracích transakcí skryté. Například pokud by Alice a Bob spolu otevřeli dva kanály, mohli by použít jeden kanál k vytvoření oznámení s hodnotou vyšší než je hodnota tohoto kanálu. Tím by dali najevo, že mohou přeposílat platby vyšší, než kolik činí hodnota kanálu; k tomu by využívali druhého, skrytého kanálu. Díky tomu by mohli zvýšit pravděpodobnost, že kterýkoliv výstup v síti, včetně nikdy neoznámených, by mohl být používán pro LN kanál.

    Poznámka také hovoří o kompromisním rozhodnutí (gossip v1.75), které by umožnilo používat jakýkoliv skript, ale bez navýšené hodnoty.

  • ● PTLC a redundantní přeplatky: dle poznámek bylo krátce diskutováno i přidání PTLC do protokolu, hlavně v souvislosti se signature adaptors. Větší část obsahu poznámky byla věnována vylepšení, které by mělo dopad na obdobné součásti protokolu: možnost redundantního přeplacení faktury a následného vrácení většiny nebo celého přeplatku. Příklad: Alice chce zaplatit Bobovi 1 BTC. Nejprve pošle Bobovi 20 plateb s více cestami, každou o hodnotě 0,1 BTC. Díky použití buď matematiky (techniky nazývané boomerang, viz zpravodaj č. 86, angl.) nebo commitmentů s více vrstvami a jednoho kola komunikace navíc (tzv. spear) by byl Bob schopný nárokovat maximálně 10 těchto plateb. Každá další platba, která by dosáhla jeho uzlu, by byla odmítnuta. Výhodou tohoto přístupu je, že až 10 částečných plateb od Alice by mohlo selhat, aniž by byla zpožděna celá platba. Nevýhodou se jeví býti zvýšená složitost a, v případě spearu, pravděpodobně i nižší rychlost, než kterou lze dosáhnout v dnešním stavu. Účastníci diskutovali, zda by mohly být najednou učiněny změny potřebné pro PTLC i redundantní přeplatky.

  • ● Návrhy na obranu před zahlcením kanálu: podstatná část poznámek poskytla souhrn diskuze o návrzích na zabránění útoků zahlcením kanálu. Diskuze začala tvrzením, že žádné jedno řešení (jako je reputace nebo poplatek předem) nemůže úspěšně adresovat problém, aniž by nepřineslo nepřijatelné vedlejší efekty. Systém reputace musí myslet na nové uzly bez historie a na přirozenou míru neúspěšných HTLC; těchto by mohl útočník zneužít a přinést určitou míru škody, i když menší než dnes. Poplatky předem musí být nastaveny dostatečně vysoko, aby odradily útočníky, ale ne příliš, aby také neodrazovaly poctivé uživatele a aby neposkytovaly uzlům podnět k úmyslnému selhání přeposílaných plateb. Namísto toho bylo navrženo, aby se používalo několik způsobů najednou, což by umožnilo vyhnout se nejhorším scénářům.

    Dále se poznámky soustředily na podrobnosti o testování schémat lokální reputace popsaných ve zpravodaji č. 226 (angl.) a přípravy na pozdější implementaci nízkých poplatků napřed. Zdá se, že účastníci vyjádřili podporu testování těchto návrhů.

  • ● Jednodušší commitmenty: účastníci diskutovali o protokolu zjednodušených commitmentů (viz zpravodaj č. 120, angl.), který definuje, která strana je zodpovědná za návrh příští změny commitment transakce (oproti současnému stavu, kdy může změnu provést kdykoliv kterákoliv strana). Pokud by byla zodpovědnost na jedné ze stran, odstranilo by to složitost v případech existence dvou návrhu odeslaných zhruba ve stejnou dobu (např. pokud by Alice i Bob chtěli ve stejný okamžik přidat HTLC). Obzvláště komplikovaný případ je, pokud jedna ze stran nechce akceptovat návrh druhé strany. Tato situace je v současném protokolu těžko řešitelná. Nevýhodou přístupu se zjednodušenými commitmenty je v některých případech navýšení latence, jelikož by jedna strana musela před změnou požádat druhou stranu o povolení. Poznámky nezmínily žádný jasný závěr diskuze.

  • ● Proces specifikace: účastníci diskutovali o několika myšlenkách na vylepšení procesu specifikace a jeho dokumentů, včetně současných BOLTů a BLIPů. Diskuze byla, zdá se, velice pestrá a nepřinesla žádné jasné závěry.

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ů.

• ● Jak můžu ručně (na papíře) spočítat ze soukromého klíče klíč veřejný? Andrew Poelstra nejprve poskytuje přehled manuálních ověřovacích technik, jako je codex32, a poté nabízí kroky k ruční derivaci veřejného klíče z klíče soukromého. Podle jeho odhadu by tento proces i s různými optimalizacemi trval nejméně 1 500 hodin.

• ● Proč existuje 17 verzí nativního segwitu? Murch vysvětluje, že segwit definoval pro verzi witnessu 17 hodnot (0–16), aby využil existující opkódy konstant OP_0 … OP_16. Dále poznamenává, že další čísla by vyžadovala použití méně datově efektivnějších opkódů OP_PUSHDATA.

• ● Vynucuje 0 OP_CSV, aby utrácející transakce signalizovala nahraditelnost podle BIP125? Murch poukazuje na diskuzi potvrzující, že jelikož časový zámek OP_CHECKSEQUENCEVERIFY (CSV) i nahrazení poplatkem (RBF) jsou vynucovány použitím pole nSequence, musí transakce s výstupem s 0 OP_CSV signalizovat nahraditelnost dle BIP125.

• ● Jak ovlivňují návrhy tras hledání cesty? Christian Decker vysvětluje dva důvody, proč by příjemce v LN poskytl odesílateli návrhy tras. Jeden důvod je, pokud by příjemce používal neoznámené kanály. Druhým důvodem je poskytnutí odesílateli seznamu kanálů, které mají dostatečný zůstatek pro dokončení platby. O této technice hovoří jako o „route boost.”

• ● Co znamená, že zabezpečení 256bitových ECDSA, a tedy i bitcoinových klíčů je 128 bitů? Pieter Wuille objasňuje, že 256bitová ECDSA poskytuje pouze 128bitové zabezpečení kvůli algoritmům, které mohou derivovat soukromý klíč z veřejného klíče efektivněji než hrubou silou. Pokračuje vysvětlením rozdílu mezi zabezpečením jednotlivých klíčů a zabezpečením seedu.

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.

• ● HWI 2.3.0 je vydáním tohoto middleware umožňujícího softwarovým peněženkám komunikovat s podpisovými zařízeními. Přidává podporu pro osobně sestrojená zařízení Jade a binárku pro běh hlavního programu hwi na zařízeních Apple Silicon s MacOS 12.0+.

• ● LDK 0.0.116 je vydáním tého knihovny pro tvorbu LN software. Obsahuje podporu pro anchor výstupy a platby s více cestami s keysend.

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 GUI #740 aktualizuje dialog pro používání PSBT. Nově označuje výstupy platící vlastní peněžence jako „vlastní adresa.” To usnadní porozumění importovaných PSBT obzvláště v situacích, ve kterých transakce vrací zbytek odesílateli.