Tento týden přinášíme souhrn návrhu na vzdálené ovládání LN uzlů pomocí hardwarových podpisových zařízení, popis výzkumu a kódu umožňující LN uzlům dynamicky dělit platby a pohled na návrh zlepšení LN likvidity umožněním skupině uzlů sdílet prostředky odděleně od svých běžných kanálů. Též nechybí naše pravidelné rubriky s oznámeními nových verzí a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Zabezpečené vzdálené ovládání LN uzlů: Bastien Teinturier zaslal do emailové skupiny Lightning-Dev příspěvek o návrhu BLIPu, který by specifikoval možnost uživatelů posílat z hardwarových podpisových zařízení podepsané příkazy svým LN uzlům nebo jiným peněženkám. Podpisové zařízení by muselo implementovat pouze tento BLIP a komunikaci dle BOLT8 a LN uzel by musel implementovat pouze BLIP. Jedná se o mechanismus podobný Core Lightning pluginu commando (viz zpravodaj č. 210, angl.), který umožňuje téměř kompletní vzdálené ovládání LN uzlu. Avšak Teinturier vidí tuto funkci primárně jako způsob provádění nejcitlivějších úkonů jako autorizace platby, tedy úkonů, pro které by byl uživatel ochoten projít připojením a odemčením hardwarového zařízení. Mohlo by to koncovým uživatelům usnadnit zabezpečení svých prostředků v LN stejným zařízením jako zabezpečení onchain prostředků.

  • ● Dělení a přepínání plateb: Gijs van Dam zaslal do emailové skupiny Lightning-Dev příspěvek o pluginu, který napsal pro Core Lightning, a o souvisejícím výzkumu, který provedl. Plugin umožňuje přeposílajícím uzlům informovat svá spojení, že podporují dělení a přepínání plateb („přepínání” ve smyslu síťových přepínačů, tedy switchů; PSS, „payment splitting and switching“). Nechť Alice sdílí s Bobem kanál a oba podporují PSS. Když potom Alice obdrží platbu, která má být přeposlána Bobovi, může ji plugin rozdělit na dvě či více částí. Jedna z těchto částí může být přeposlána Bobovi běžným způsobem, avšak ostatní části mohou následovat alternativní cesty (například přes Carol). Bob počká, až obdrží všechny části, a potom platbu dále přepošle běžným způsobem.

    Hlavní výhoda tohoto přístupu spočívá ve ztížení provádění útoků odhalující zůstatky (BDA, „Balance Discovery Attacks”), při kterých mohou třetí strany opakovaně sondovat kanál a sledovat jeho zůstatek. Pokud je BDA prováděn pravidelně, může sledovat hodnoty plateb procházející kanálem. Pokud je prováděn na mnoho kanálů, může sledovat konkrétní platbu napříč sítí. Pokud by bylo použito PSS, útočník by musel vedle zůstatku kanálu Alice–Bob také sledovat kanály Alice–Carol a Carol–Bob, aby mohl platbu sledovat. I kdyby útočník sledoval zůstatek ve všech těchto kanálech, výpočetní náročnost sledování platby by se zvyšovala spolu s pravděpodobností, že by mohly být platby jiných uživatelů chybně pokládány za části původní, sledované platby. Van Damův výzkum ukazuje 62% redukci v množství informací, které by útočník mohl po nasazení PSS získat.

    Van Dam zmiňuje dvě další výhody PSS: navýšení propustnosti LN a jeho použití jako část opatření proti útoku zahlcením kanálu. V době psaní zpravodaje obdržel nápad malé množství reakcí.

  • ● Sdílená likvidita pro LN: ZmnSCPxj zaslal do emailové skupiny Lightning-Dev příspěvek s návrhem na jím zvané sidepooly. Ty by umožnily skupinám spolupracujících přeposílajících uzlů vložit prostředky do stavového kontraktu, tedy do offchain kontraktu (ukotveného onchain podobně jako LN kanál), který by umožnil prostředky převádět mezi účastníky aktualizováním jeho offchain stavu. Například úvodní stav přiznávající Alici, Bobovi a Carol každému 1 BTC by mohl být aktualizován na nový stav, který dává Alici 2 BTC, Bobovi 0 BTC a Carol 1 BTC.

    Přeposílající uzly by nadále mohly používat běžné LN kanály mezi páry uzlů. Například tito tři uživatelé by mohli mít tři oddělené kanály: Alice s Bobem, Bob s Carol a Carol s Alicí. Běžným způsobem by těmito kanály přeposílali platby.

    Pokud by se jeden či více z těchto běžných kanálů staly nevyváženými, například by příliš mnoho prostředků v kanálu mezi Alicí a Bobem náleželo Alici, mohl by tento nepoměr být vyřešen provedením offchain peerswapu ve stavovém kontraktu. Například by mohla Carol Alici poskytnout nějaké prostředky ve stavovém kontraktu výměnou za stejnou částku zaslanou Alicí Carol přes Boba v běžném LN kanálu. Tím by byla v LN kanálu mezi Alicí a Bobem znovu nastolena rovnováha.

    Jednou z výhod tohoto přístupu je, že nikdo kromě účastníků nemusí o stavovém kontraktu vědět. Pro všechny běžné uživatele LN a všechny ostatní přeposílající uzly bude LN fungovat podle současného protokolu. Další výhodou v porovnání s existujícími způsoby rebalancování kanálů je umožnění velkému množství přeposílajících uzlů zachovat přímá spojení výměnou za malý onchain prostor. To by mohlo odstranit jakékoliv onchain rebalanční poplatky mezi těmito spojeními. Díky zachování minimálních rebalančních poplatků mohou přeposílající uzly udržovat své kanály v rovnováze, což zlepší jejich možnost výdělku a učiní posílání plateb LN sítí spolehlivější.

    Nevýhodou přístupu je nutnost udržovat stavový kontrakt s více účastníky, což, pokud víme, zatím nebylo v produkčním prostředí implementováno. ZmnSCPxj zmiňuje dva protokoly, které mohou sloužit jako základ: LN-Symmetry a duplexní platební kanály. LN-Symmetry by vyžadoval změnu konsenzu, což se zřejmě v blízké budoucnosti nestane, proto se v následném příspěvku ZmnSCPxj soustředí na duplexní platební kanály (které ZmnSCPxj nazývá „Decker-Wattenhofer” podle autorů prvního návrhu). Nevýhodou duplexních platebních kanálů je, že nemohou zůstat otevřené nastálo, i když dle ZmnSCPxjovy analýzy pravděpodobně mohou být otevřené dostatečně dlouho a projít dostatečným množstvím změn stavu, aby byly jejich náklady efektivně amortizovány.

    V době psaní zpravodaje neobdržel příspěvek žádné veřejné reakce, avšak ze soukromé korespondence se ZmnSCPxjem víme, že tuto myšlenku dále rozvíjí.

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.

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

  • ● Eclair #2756 přináší monitorování splicingových operací. Sbírány jsou informace o iniciátorovi operace a typ: splice-in, splice-out či splice-cpfp.

  • ● LDK #2486 přidává podporu zakládání více kanálů jednou transakcí. Garantuje přitom atomicitu, tedy založeny budou buď všechny kanály, nebo žádný.

  • ● LDK #2609 umožňuje vyžádat deskriptory, které byly v minulosti použity pro obdržení platby. Dříve je museli uživatelé ukládat sami, aktualizované API umožní z různých uložených dat deskriptory rekonstruovat.