Tento týden přinášíme popis nápadu na nakládání se zodpovědností strážních věží a připojujeme naše pravidelné rubriky s oznámeními o vydání nových verzí a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Zodpovědnost strážních věží: Sergi Delgado Segura zaslal minulý týden do emailové skupiny Lightning-Dev příspěvek o způsobech, kterými by strážní věže („watchtowers”) nesly zodpovědnost za selhání zabránit pokusům o narušení protokolu. Příklad: Alice poskytne strážní věži data pro detekci a zabránění potvrzení neplatného stavu LN kanálu. Později je tento neplatný stav potvrzen, ale strážní věž nereaguje. Alice by chtěla, aby měla možnost toto selhání veřejně prokázat a tím vedla strážní věž k zodpovědnosti.

  Nejjednodušším řešením by bylo, aby měla strážní věž všeobecně známý veřejný klíč, jehož soukromý klíč by generoval podpisy akceptovaných podkladů pro detekci narušení. V případě selhání strážní věže zabránit narušení protokolu by mohla Alice tato data a podpis zveřejnit. Avšak, jak Delgado poznamenává, má toto řešení svá úskalí:

  • ● Požadavky na úložiště: tento mechanismus by po Alici vyžadoval ukládání dodatečného podpisu za každý požadavek strážní věži, což by u aktivních LN kanálů bylo celkem často.

  • ● Nemožnost mazání: tento způsob by zřejmě vyžadoval, aby strážní věže nikdy nemazaly podklady pro detekci narušení. Avšak to může být v rozporu s jejich potřebami, např. pokud jsou jejich služby účtovány za určité období.

  Delgado navrhuje použití kryptografických akumulátorů, které by poskytly praktické řešení obou problémů. Akumulátory umožňují v kompaktní formě prokázat, že určitý prvek je součástí velké množiny prvků a nevyžadují po každém vložení nového prvku přepočítání celé datové struktury. Některé akumulátory umožňují i smazání prvků bez přepočítání. Delgado v gistu nastiňuje konstrukci několika možných akumulátorů.

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.

• ● LND v0.16.0-beta je beta verzí nové hlavní verze této populární implementace LN. Poznámky k vydání zmiňují množství nových funkcí, oprav chyb a zlepšení výkonu.

• ● 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 #5967 přidává RPC volání listclosedchannels, které poskytuje data o uzavřených kanálech včetně důvodu zavření. Informace o dřívějších spojeních se nyní též ukládají.

• ● Eclair #2566 přidává podporu pro přijímání nabídek. Nabídky musí být registrovány pluginem, který poskytuje handler reagující na žádosti o faktury spojené s těmito nabídkami a přijímající platby. Eclair zajišťuje, že požadavky a platby jsou v souladu s protokolem, handler musí jen rozhodnout, zda produkty či služby mohou být poskytnuty. Díky tomu může být odbavování nabídek libovolně komplexní, aniž by mělo dopad na vnitřní logiku Eclairu.

• ● LDK #2062 implementuje BOLT #1031 (viz zpravodaj č. 226, angl.), #1032 (viz zpravodaj č. 225, angl.) a #1040, které umožňují konečnému příjemci platby (HTLC) akceptovat větší částku a delší expirační lhůtu, než které byly požadovány. Snižuje to schopnost přeposílajícího uzlu určit použitím drobných úprav parametrů, zda je následující uzel v trase konečným příjemcem. Díky této změně může také plátce zaslat příjemci mírně vyšší částku v případě používání zjednodušených plateb s více cestami. To může být nutné v případech, kdy zvolená trasa využívá kanály požadující minimální částku. Příklad: Alice chce rozdělit platbu ve výši 900 sat na dvě části, ale obě jí zvolené cesty požadují pro přeposlání minimálně 500 sat. Po této změně specifikace může odeslat dvě 500sat platby, a tedy přeplatit 100 sat za možnost použít jí preferovanou trasu.

• ● LDK #2125 přidává pomocné funkce pro určení času zbývajícího do expirace faktury.

• ● BTCPay Server #4826 umožňuje, aby service hooks mohly vytvářet a přijímat LNURL faktury. Důvodem změny bylo přidání podpory pro NIP-57 „zap” do BTCPay Server.

• ● BTCPay Server #4782 přidává na účtenku důkaz o proběhlé platbě. Pro onchain platby je důkazem ID transakce, pro LN platby předobraz HTLC.

• ● BTCPay Server #4799 přidává možnost exportovat štítky transakcí ve formátu specifikovaném v BIP329. Budoucí PR může přidat podporu pro export i jiných druhů štítků, např. adres.

• ● BOLTs #765 přidává do LN specifikace zaslepení tras, které bylo poprvé popsáno ve zpravodaji č. 85 (angl.). Umožňuje uzlu přijmout platbu nebo onion zprávu bez nutnosti odhalit odesílateli či plátci svůj identifikátor či jakoukoliv jinou informaci vedoucí k jeho identifikaci. Zaslepená trasa umožňuje příjemci zvolit si několik posledních uzlů, přes které bude platba nebo zpráva směrována. Ty jsou zašifrované stejným způsobem jako běžné trasovací informace. Zaslepená trasa je poskytnuta plátci nebo odesílateli, který odešle platbu na její první uzel. Ten data odšifruje a pokračuje v přeposílání směrem k příjemci. Během procesu se odesílatel nedozví informace o cílovém uzlu.