Zpravodaj tento týden popisuje myšlenku na urovnávání LN kanálů mobilními peněženkami bez potřeby mít UTXO navíc a shrnuje pokračující diskuzi o přidání příznaku quality of service pro hledání cest v LN. Též nechybí naše pravidelné rubriky s popisem nedávných změn ve službách, klientech a populárním bitcoinovém páteřním software.

Novinky

  • ● Možnost mobilních peněženek urovnat kanál bez nutnosti mít UTXO navíc: Bastien Teinturier zaslal do fóra Delving Bitcoin příspěvek o volitelné variantě v3 commitmentů pro LN kanály, která by mobilním peněženkám umožnila pomocí prostředků kanálu uzavřít kanály i v případech, kdy je krádež možná, aniž by musely mít k dispozici onchain UTXO na zaplacení poplatků.

    Teinturier začíná vyjmenováním čtyř případů, ve kterých musí mobilní peněženka zveřejnit transakci:

    1. Protistrana zveřejní revokovanou commitment transakci, např. se pokouší ukrást peníze. V tomto případě získává peněženka okamžitě možnost utratit všechny prostředky kanálu a použít je na zaplacení poplatků.

    2. Mobilní peněženka odeslala platbu, která ještě nebyla urovnaná. V tomto případě je krádež vyloučena, jelikož protistrana by mohla platbu nárokovat pouze poskytnutím předobrazu HTLC (tedy důkazu o platbě konečnému příjemci). Jelikož není krádež možná, mobilní peněženka nemusí s hledáním UTXO na zaplacení poplatků za uzavření kanálu pospíchat.

    3. Žádné platby na vyrovnání nečekají, ale vzdálená strana nereaguje. Ani zde není krádež možná, mobilní peněženka má na zavření kanálu čas.

    4. Mobilní peněženka je příjemcem HTLC. V tomto případě může vzdálená strana obdržet předobraz HTLC (což jí umožní nárokovat prostředky od spojení proti směru toku), ale zůstatek kanálu neaktualizuje a HLTC revokuje. V tento okamžik musí mobilní peněženka vynuceně kanál uzavřít během relativně nízkého počtu bloků. Zbytek příspěvku se zabývá právě tímto případem.

    Teinturier navrhuje, aby vzdálená strana podepsala dvě různé verze každého HTLC, které mobilní peněžence platí: verzi s nulovým poplatkem dle výchozích pravidel commitmentů s nulovými poplatky a verzi platící takový poplatek, který jí aktuálně umožní rychlé potvrzení. Poplatky jsou odečteny z hodnoty HTLC platící mobilní peněžence, vzdálenou stranu tedy nabízení této možnosti nestojí nic navíc a mobilní peněženka má motivaci ji použít jen v nezbytných případech. Teinturier poznamenává, že vzdálená strana musí dát pozor na výšku poplatků, očekává však snadné řešení.

  • ● Pokračující diskuze o příznaku quality of service v LN: Joost Jager zaslal do fóra Delving Bitcoin příspěvek navazující na diskuzi o přidání QoS příznaku (Quality of Service) do LN protokolu, kterým by mohly uzly signalizovat vysokou dostupnost svých kanálů, tedy schopnost přeposílat platby do určité výše se 100% spolehlivostí (viz též zpravodaj č. 239). Pokud si plátce zvolí kanál nabízející vysokou dostupnost a jeho platba selže, může plátce provozovatele potrestat tím, že jeho kanál již nikdy nepoužije. Nově Jager navrhl signalizování na úrovni uzlů, např. jednoduše připojením „HA” (high availability) k aliasu uzlu, a dodal, že aktuální chybová hlášení nezaručují detekci kanálu, ve kterém platba selhala, proto nebude možné vysokou dostupnost signalizovat a používat na zcela libovolném základě (tedy bez široké dohody). Signalizování by tedy měl být pro zachování kompatibility specifikováno, i když ho nakonec bude používat jen velmi málo uzlů.

    Matt Corallo odpověděl, že hledání tras v LN funguje v současnosti dobře a odkázal na podrobný dokument popisující hledání tras v LDK: rozšiřuje způsob původně popsaný René Pickhardtem a Stefanem Richterem (viz zpravodaj č. 163, angl., a dva body ve zpravodaji č. 270). Obává se ale, že QoS příznak bude nabádat budoucí software k implementaci méně spolehlivého hledání tras a k používání pouze vysoce dostupných kanálů. V takovém případě by mohly velké uzly uzavírat s vlastníky svých velkých kanálů dohody o dočasném používání likvidity založeném na důvěře, pokud se kanál vyčerpá. Malé uzly závislé na kanálech bez požadavku na důvěru budou muset používat drahý JIT rebalancing – jejich kanály budou vydělávat méně (pokud náklady pohltí) nebo budou méně žádané (pokud náklady přenesou na plátce).

    Jager a Corallo v diskuzi pokračovali bez jasného závěru.

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.

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, Lightning BLIPs, Bitcoin Inquisition a repozitáři BINANA.

  • ● Bitcoin Core #27432 přidává pythonový skript, který převádí serializovanou množinu UTXO vygenerovanou RPC příkazem dumptxoutset (navržený pro AssumeUTXO snapshoty) na SQLite3 databázi. I když byla zvažována integrace exportu do SQLite3 přímo do RPC příkazu, nakonec byla kvůli zvýšené zátěži na údržbu zavržena. Skript nevyžaduje žádné dodatečné závislosti a výsledná databáze má zhruba dvojnásobnou velikost oproti serializaci.

  • ● Bitcoin Core #30529 opravuje chování negovaných voleb jako noseednode, nobind, nowhitebind, norpcbind, norpcallowip, norpcwhitelist, notest, noasmap, norpcwallet, noonlynet a noexternalip. Dříve způsobilo negování těchto voleb zmatečné a nedokumentované vedlejší efekty, nyní jednoduše vrací volby na jejich výchozí hodnoty.

  • ● Bitcoin Core #31384 řeší problém, kdy 4 000 váhových jednotek (WU) rezervovaných na hlavičku bloku, počet transakcí a mincetvornou transakci bylo neúmyslně počítáno dvakrát, čímž byla snížena maximální velikost šablony bloku o nadbytečných 4 000 WU na 3 992 000 WU (viz zpravodaj č. 336). Kromě samotné opravy přináší změna novou volbu -blockreservedweight, která uživatelům umožní rezervovanou váhu nastavit. Bitcoin Core se nespustí pokud není nastavena na hodnotu mezi 2 000 WU and 4 000 000 WU.

  • ● Core Lightning #8059 nebude v pluginu xpay (viz zpravodaj č. 330) používat platbu s více cestami (multipath payment, MPP), pokud BOLT11 faktura neindikuje její podporu. Stejná logika bude rozšířena i na BOLT12 faktury, ale bude muset počkat na příští vydání, neboť toto PR také umožňuje předat pluginům funkcionalitu aktivovanou v BOLT12 fakturách (např. právě možnost použít MPP pro její placení).

  • ● Core Lightning #7985 přidává podporu pro placení BOLT12 faktur v pluginu renepay (viz zpravodaj č. 263). Umožňuje routování zaslepeným cestami a interně nahrazuje používání sendpay příkazem sendonion.

  • ● Core Lightning #7887 přidává podporu pro používání nových BIP353 polí pro překlad čitelných jmen (Human Readable Name resolution, HRN), aby odpovídal posledním aktualizacím BOLTů (viz zpravodaje č. 290 a č. 333). PR dále do faktur přidává pole invreq_bip_353_name, vynucuje omezení v přicházejících BIP353 jmenných polích a umožňuje uživatelům používat BIP353 jména v RPC fetchinvoice.

  • ● Eclair #2967 přidává podporu protokolu option_simple_close dle specifikace v BOLTs #1205. Tato zjednodušená varianta protokolu vzájemného uzavření kanálu je potřebná pro jednoduché taprootové kanály. Umožňuje uzlům během shutdown, closing_complete a closing_sig bezpečnou výměnu noncí, které jsou potřeba pro MuSig2.

  • ● Eclair #2979 ověřuje před pokusem o přeposlání trampolínové platby, že následující přímé spojení podporuje probuzení pomocí notifikace (viz zpravodaj č. 319). U standardních plateb není tato kontrola nutná, neboť BOLT11 i BOLT12 faktury již příznak podpory těchto notifikací obsahují.

  • ● Eclair #3002 pro navýšení spolehlivosti přidává sekundární mechanismus zpracovávání bloků a jejich transakcí, které mohou spustit návazné procesy. To je obzvláště důležité v případě utracení kanálu, kdy uzel neviděl příslušnou transakci v mempoolu před tím, než ji obdržel v bloku. Běžně to má na starosti ZMQ a jeho topic rawtx, ale při používání vzdáleného bitcoind může být nespolehlivé a může tiše zahazovat zprávy. U každého nově nalezeného bloku tento sekundární systém vyžádá posledních N bloků (6 ve výchozím nastavení) a jeho transakce zpracuje znovu.

  • ● LDK #3575 implementuje protokol peer storage, který uzlům umožňuje ukládat protistranám svých kanálů jejich zálohy. Přináší dva nové typy zpráv PeerStorageMessage a PeerStorageRetrievalMessage a metody pro jejich zpracování. Data jsou uložena v PeerState v ChannelManageru.

  • ● LDK #3562 přidává novou funkci hodnocení výkonu (viz zpravodaj č. 308), která z externích zdrojů slučuje výkonové testy založené na častém sondování skutečných platebních cest. Díky tomu mohou lehké uzly, které mají omezený přehled o síti, použít data poskytnutá např. poskytovateli lightningových služeb (Lightning Service Provider, LSP) a navýšit tím úspěšnost plateb. Data z externích zdrojů mohou být s místními sloučena nebo je mohou zcela nahradit.

  • ● BOLTs #1205 začleňuje protokol option_simple_close, který je zjednodušenou variantou protokolu vzájemného uzavření kanálu vyžadovanou pro jednoduché taprootové kanály. Změny se týkají BOLT2 a BOLT3.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 25. 2. v 17:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.