Tento týden přinášíme popis diskuze o LN splicingu a odkazujeme na návrh BIP pro doporučenou terminologii v rámci transakcí. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o vydáních, včetně bezpečnostní aktualizace libsecp256k1, a popisem významných změn v populárních páteřních bitcoinových projektech.

Novinky

• ● Diskuze o specifikaci splicingu: několik vývojářů LN informovalo tento týden emailovou skupinu Lightning-Dev o pokračující práci na návrhu specifikace splicingu, díky kterému je možné utratit část prostředků LN kanálu na blockchainu (splice-out) či prostředky z blockchainu přidat do LN kanálu (splice-in). Kanál může během čekání na dostatečné množství konfirmací splicingové transakce nadále fungovat bez přerušení.

  Na následujícím diagramu jsou šedě označeny potvrzené transakce a přerušovanou čarou transakce, které prozatím zůstávají offchain.

  

  Některé z diskuzí:

  • ● Které podpisy commitmentů mají být poslány: po vytvoření splicu bude uzel držet paralelní commitment transakce; jedna utrácí původní otvírací výstup a druhá utrácí každý nový otvírací výstup všech nevyřízených spliců. Během každé změny stavu kanálu musí být aktualizovány také všechny paralelní commitment transakce. Jednoduchým způsobem by bylo rozeslat stejnou zprávu – která by byla jinak určená samotné commitment transakci – také všem paralelním commitment transakcím.

    Původní návrh specifikace splicingu (viz zpravodaje č. 17 a č. 146, angl.) obsahoval právě takové řešení. Avšak jak Lisa Neigut tento týden vysvětlila, vytvoření nového splicu vyžaduje podepsání nové odvozené commitment transakce. V posledním návrhu specifikace vyžaduje každé odeslání podpisu také poslání podpisů všech aktuálních commitment transakcí. To je však nadbytečné, neboť podpisy ostatních commitment transakcí již byly odeslány dříve. Navíc jelikož v současném LN protokolu potvrzují jednotlivé strany obdržené podpisy zasláním dat pro anulování předchozí commitment transakce, dochází i zde k opakovanému přenosu stejných dat. Tato činnost není škodlivá, avšak vyžaduje více přenosové a výpočetní kapacity. Výhodou je, že provádění stejné operace ve všech případech zjednodušuje specifikaci a tím i složitost implementace a testování.

    Jinou možností je během vyjednávání o splicu posílat pouze nezbytné minimum podpisů a potvrzení přijetí. I přes přidanou složitost se jedná o mnohem efektivnější řešení. Je dobré míti na paměti, že LN uzly musí držet paralelní commitment transakce pouze do získání dostatečného množství konfirmací splicingové transakce.

  • ● Relativní částky a splicing bez konfirmací: Bastien Teinturier zaslal příspěvek s několika návrhy změn specifikace. Kromě výše uvedené změny podpisů commitmentů též doporučuje, aby výzva ke splicingu používala relativní částky, např. „200 000 sat” pro přidání částky do kanálu (splice-in) nebo „−50 000 sat” pro odeslání z kanálu (splice-out). Teinturier se též bez dalších podrobností zmínil o svých obavách souvisejících se splicingem bez konfirmací.

• ● Návrh BIPu s terminologií transakcí: Mark „Murch” Erhardt zaslal do emailové skupiny Bitcoin-Dev návrh na informační BIP s doporučenou nomenklaturou součástí transakcí a konceptů s nimi spojených. V době psaní tohoto zpravodaje byly všechny odpovědi souhlasné.

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

Nestahuj witnessy pro domněle validní bloky v ořezaném režimu je PR od Niklase Göggeho (dergoegge), které zrychluje prvotní stahování bloků tím, že nebude stahovat witnessy u uzlů nastavených v ořezaném režimu a používajících assumevalid (nastavení, kdy uzel přeskočí validaci některých starých transakcí). Tato optimalizace byla diskutována v nedávné otázce na Stack Exchange.

• Proč musí uzel, který má nastaven assumevalid ale ne ořezávání, stahovat witnessy, i když je nebude validovat? Mělo by PR tuto situaci také řešit?

  Data witnessů jsou potřeba, protože spojení si mohou vyžádat i staré bloky (uzel nepracuje v ořezaném režimu). ➚

• O kolik může být díky tomuto vylepšení snížen datový přenos? Jinými slovy, jaká je celková velikost všech witnessů až po nějaký nedávný blok, řekněme 781213?

  110,6 GB, což je zhruba čtvrtina celkového objemu dat. Jeden účastník poznamenal, že 110 GB je zhruba 10 % jeho měsíčního limitu. Jedná se tedy o významnou redukci. Účastníci předpověděli ještě větší ušetření, vzhledem k rozšířenému používání witnessů v poslední době. ➚

• Může tato změna snížit množství stahovaných dat všech bloků?

  Ne, pouze od aktivace segwitu (výška 481824). Předchozí bloky neměly witnessy. ➚

• Toto PR implementuje dvě hlavní změny: logiky požadavků na bloky a validace bloků. V čem tyto změny spočívají?

  Je-li během validace přeskočeno ověření skriptu, je též přeskočeno ověření Merkleova stromu witnessů. V logice požadavků na bloky je vyňat příznak MSG_WITNESS_FLAG, aby spojení neposílala data witnessů. ➚

• Před touto změnou byla validace skriptů (během assumevalid) přeskočena, ale ostatní ověření dat witnessů přeskočena nebyla. Jaká ověření budou po této změně přeskočena?

  Merkleův kořen coinbasové transakce, velikost witnessů, maximální počet prvků v zásobníku a váha bloku. ➚

• Toto PR neobsahuje žádnou změnu kódu pro přeskočení všech nadbytečných ověření popsaných v předchozí otázce. Jak to tedy funguje?

  Tato ověření se přeskočí vždy, když neexistuje žádný witness. Jelikož byl segwit soft forkem, dává to smysl. Až do bodu, který považujeme za validní, tedy v podstatě předstíráme, že jsme předsegwitový uzel. ➚

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.

• ● Libsecp256k1 0.3.1 je bezpečnostním vydáním opravujícím kód, který by měl běžet v konstantním čase, ale neběžel, když byl použit Clang 14 nebo vyšší. Tato zranitelnost mohla umožnit druh útoku postranními kanály spojený s časováním operací. Autoři doporučují provést aktualizaci.

• ● BDK 1.0.0-alpha.0 je testovacím vydáním velkých změn přicházejících do BDK popsaných ve zpravodaji č. 243. Vývojáři projektů používajících BDK jsou vyzváni, aby započali s testováním integrace.

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.

• ● Core Lightning #6012 implementuje několik významných vylepšení v pythonové knihovně pro psaní pluginů (viz zpravodaj č, 26, angl.). Díky změnám mohou pluginy lépe pracovat s úložištěm gossip zpráv a umožňují tak snadnější tvorbu analytických nástrojů.

• ● Core Lightning #6124 přidává možnost blokovat runy (autorizační tokeny) pluginu commando (umožňující spouštět příkazy na straně spojení) a udržovat seznam všech run.

• ● Eclair #2607 přidává nové RPC volání listreceivedpayments, které vrací seznam všech plateb přijatých uzlem.

• ● LND #7437 přidává podporu souborové zálohy jediného kanálu.

• ● LND #7069 umožňuje klientům požádat svou strážní věž („watchtower”) o ukončení sledování. Tím věž přestane monitorovat transakce zavírající kanál v neplatném stavu a její nároky na úložiště a procesor se sníží.

• ● BIPs #1372 přiřazuje protokolu MuSig2 číslo BIP327. Protokol lze využít pro vytváření elektronických podpisů s více účastníky, které mají uplatnění v taprootu a jiných systémech používajících Schnorrovy podpisy dle BIP340. Jak je popsáno v BIPu, mezi výhody patří neinteraktivní agregace klíčů a nutnost provést pro podpis pouze dvě kola vzájemné komunikace. Je též možné provést neinteraktivní podepisování, mají-li účastníci určité nastavení. Protokol nabízí všechny výhody schémat vícenásobných podpisů, jako jsou významná redukce datové stopy na blockchainu a vylepšení soukromí pro účastníky i ostatní uživatele sítě.