Tento týden přinášíme souhrn diskuze o rozšíření BOLT11 faktur o požadavek na dvě platby. Též nechybí další příspěvek do naší krátké týdenní série o pravidlech mempoolu a naše pravidelné rubriky popisující změny v klientech a službách, nová vydání a změny v populárních bitcoinových páteřních projektech.

Novinky

• ● Návrh na rozšíření BOLT11 faktur o požadavek na dvě platby: Thomas Voegtlin zaslal do emailové skupiny Lightning-Dev příspěvek s návrhem, aby byly BOLT11 faktury rozšířeny o volitelnou možnost odesílatele vyžádat od plátce dvě oddělené platby, každou s vlastním tajným kódem a částkou. Voegtlin vysvětluje užitečnost návrhu pro submarine swaps a JIT kanály:

  • ● Submarine swaps v případě, kdy platba offchain LN faktury vyústí v přijetí onchain prostředků (opačný směr zde neuvažujeme). Onchain příjemce zvolí tajný kód a offchain plátce zaplatí HTLC s hashem tohoto kódu, které je směrováno po LN k poskytovateli submarine swap. Tento poskytovatel obdrží offchain HTLC a vytvoří onchain transakci platící za toto HTLC. Až bude uživatel považovat onchain transakci za zabezpečenou, odhalí tajný kód k vyrovnání onchain HTLC, což umožní poskytovateli vyrovnat offchain HTLC (a kteroukoliv další platbu v LN závislou na stejném tajném kódu).

    Pokud však příjemce tajný kód neodhalí, neobdrží poskytovatel žádnou kompenzaci a bude muset utratit právě vytvořený onchain výstup, což mu přinese nadbytečné náklady. Aby předešly tomuto zneužití, požadují existující poskytovatelé po plátci LN poplatek (zaslaný před vytvořením onchain transakce), který může být zcela či zčásti vrácen po vyrovnání onchain HTLC. Tento poplatek a submarine swap obsahují odlišné částky a musí být vyrovnány v odlišných časech, musí tedy použít i odlišný tajný kód. Současná BOLT11 faktura může obsahovat pouze jeden commitment k tajnému kódu a jednu částku. Každá peněženka poskytující submarine swaps tedy musí buď interakci se serverem obstarat sama nebo nechat dokončení tohoto postupu na plátci a příjemci.

  • ● Just-in-Time (JIT) kanály, kde uživatel bez kanálů (nebo bez likvidity) vytvoří s poskytovatelem služeb virtuální kanál. V okamžiku přijetí první platby do tohoto virtuálního kanálu vytvoří poskytovatel onchain transakci, která kanál otevře a zároveň provede tuto platbu. Tato offchain platba je jako kterékoliv jiné HTLC učiněna oproti tajnému kódu, který zná jen příjemce (uživatel). Je-li uživatel ujištěn, že otevření JIT kanálu je zajištěno, odhalí tajný kód a platbu nárokuje.

    Pokud však opět uživatel tajný kód neodhalí, neobdrží poskytovatel kompenzaci a vyvstanou mu dodatečné onchain náklady. Voegtlin věří, že existující poskytovatelé JIT kanálů se tomuto problému vyhýbají tím, že vyžadují odhalení tajného kódu před tím, než je otevírací transakce zajištěna, což podle něj může vytvářet problémy se zákonem a zabraňuje nekustodiálním peněženkám podobnou službu nabízet.

  Voegtlin věří, že kdyby BOLT11 faktura obsahovala dva separátní commitmenty, každý na jinou částku a k jinému tajnému kódu, umožnilo by to použít jeden kód a částku na poplatek placený dopředu (za onchain transakci) a druhý kód a částku na vlastní submarine swap nebo otevření JIT kanálu. Návrh obdržel několik komentářů, o některých se zde krátce zmíníme:

  • ● Logika speciálně pro submarine swaps: Olaoluwa Osuntokun poznamenal, že příjemce submarine swap musí vytvořit tajný kód, distribuovat ho a vyrovnat oproti němu platbu onchain. Nejlevnějším způsobem tohoto vyrovnání je interakce s poskytovatelem swapu. Pokud plátce i příjemce musí s poskytovatelem tak jako tak komunikovat, což se s existujícími implementacemi často děje, nemusí si předávat dodatečné informace v rámci faktury. Voegtlin odpověděl, že tuto interakci může obstarat vyhrazený software a nebude tedy potřeba přidávat logiku do offchain peněženky, která platí prostředky, a onchain peněženky, která je přijímá. To by však bylo možné jen, pokud by LN peněženka mohla učinit dvě oddělené platby v rámci jedné smlouvy.

  • ● Stabilita BOLT11: Matt Corallo odpověděl, že všechny LN implementace stále ještě nemají podporu pro faktury bez částky (k umožnění spontánních plateb), nemyslí si tedy, že by přidání dalšího pole bylo nyní dobrým přístupem. Bastien Teinturier odpověděl podobně a navrhl raději přidat podporu do nabídek. Voegtlin nesouhlasí a myslí si, že přidání podpory je praktické.

  • ● Splice-out jako alternativa: Corallo se dále táže, proč by měl být protokol pozměněn, aby podporoval submarine swaps, pokud by byly dostupné splice outs. V konverzaci to nebylo zmíněno, avšak submarine swaps i splice outs umožňují přesunout offchain prostředky na onchain výstup, ale splice outs mohou být efektivnější onchain a netrpí problémem nekompenzovaného poplatku. Voegtlin odpověděl, že submarine swaps umožňují uživatelům LN navýšit svou kapacitu pro přijímání LN plateb, což splicing neumožňuje.

  V době psaní byla diskuze stále aktivní.

Čekání na potvrzení 6: konzistence pravidel

Krátká týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Minulý týden jsme si představili soubor pravidel pro validaci transakcí používaných nad rámec pravidel konsenzu. Tato pravidla nejsou aplikována na transakce v blocích, uzel tedy může zůstat v konsenzu s ostatními, i když se jeho pravidla liší. Stejně jako se může provozovatel uzlu rozhodnout nepodílet se na přeposílání transakcí, může si též svobodně zvolit svá pravidla či žádná pravidla vůbec nevynucovat (a tím se vystavit riziku DoS). Z toho vyplývá, že nemůžeme předpokládat jednotnost mempoolů v síti. Avšak aby mohla být naše transakce přijata těžařem, musí nejdříve projít cestou uzlů, které ji přijmou do svých mempoolů; jakákoliv odchylka pravidel mezi těmito uzly má přímý dopad na přeposílání transakcí.

Hraničním příkladem odlišnosti pravidel mezi uzly budiž situace, ve které si každý provozovatel uzlu zvolí náhodné číslo, které bude jako jediné přijímat v nVersion. Jelikož by většina peer-to-peer relací měla nekompatibilní pravidla, transakce by se k těžařům nedostávaly.

Na druhou stranu shodná pravidla napříč sítí napomáhají sjednocování obsahu mempoolů. Síť se shodnými mempooly nejlépe přeposílá transakce a je též ideální pro odhad poplatků a přeposílání kompaktních bloků, jak bylo zmíněno v předchozích příspěvcích.

Vzhledem ke složitosti validace mempoolu a obtížím spojených s rozdílností pravidel je Bitcoin Core konzervativní v možnostech konfigurování pravidel. I když mohou uživatelé snadno nastavit způsob počítání sigops (bytespersigop) či omezit množství dat v OP_RETURN výstupech (datacarriersize a datacarrier), nemohou se bez změny kódu vyvázat z maximální standardní váhy 400 000 váhových jednotek či používat odlišný soubor pravidel pro RBF.

Některá z nastavení pravidel v Bitcoin Core existují pro přizpůsobení se odlišným provozním prostředím či důvodům provozování uzlu. Například těžařovy hardwarové zdroje a důvody pro držení mempoolu jsou odlišné od běžného uživatele provozujícího lehký uzel na laptopu nebo Raspberry Pi. Těžař může chtít navýšit kapacitu mempoolu (maxmempool) nebo čas expirace (mempoolexpiry), aby mohl během špičky ukládat transakce s nízkým jednotkovým poplatkem, které by mohl těžit v čase nižšího provozu. Webové stránky nabízející vizualizace, archívy či statistiky mohou provozovat několik uzlů, aby sbíraly co nejvíce dat a zobrazovaly výchozí chování mempoolu.

Co se týče jednotlivých uzlů, nastavení kapacity mempoolu ovlivňuje dostupnost nástrojů k navýšení poplatků. Roste-li minimální jednotkový poplatek mempoolu kvůli vysokému počtu příchozích transakcí, nemohou být poplatky navyšovány pomocí CPFP transakcím vyloučeným z mempoolu či transakcím novým majícím jednotkový poplatek pod tímto minimem.

Na druhou stranu, jelikož vstupy odstraněných transakcí už nejsou utráceny žádnou transakcí v mempoolu, může být nově možné navýšit poplatek pomocí RBF. Nová transakce ve skutečnosti v mempoolu nic nenahrazuje, nemusí tedy uvažovat běžná pravidla RBF. Avšak uzly, které původní transakci z mempoolu neodstranily (kvůli vyšší kapacitě), považují tuto novou transakci za možnou nahrazující transakci a vynucují pravidla RBF. Pokud odstraněná transakce nesignalizovala možnost nahrazení (BIP125) či poplatek nové transakce nesplňuje kritéria RBF navzdory vysokému jednotkovému poplatku, nemusí těžař tuto novou transakci akceptovat. Peněženky musí s odstraněnými transakcemi nakládat opatrně, neboť výstupy transakce nemohou být pokládány za utratitelné a rovněž vstupy jsou podobně nedostupné k dalšímu použití.

Na první pohled se může zdát, že díky větší kapacitě mempoolu je pro uzel CPFP užitečnější a RBF méně užitečné. Avšak přeposílání transakcí je předmětem aktuálního chování sítě a cesta od uživatele k těžařovi, ve které všechny uzly toto CPFP akceptují, nemusí existovat. Uzly běžně přeposílají transakce až po akceptování do vlastního mempoolu a ignorují oznámení o transakcích, která již ve svém mempoolu mají. Uzly, které ukládají více transakcí, se chovají jako černé díry, když se k nim tyto transakce dostanou. Dokud celá síť nenavýší kapacitu svých mempoolů, což by bylo signálem pro změnu výchozí hodnoty, přinese navýšení kapacity jednotlivým uživatelům jen málo výhod. Minimální jednotkový poplatek mempoolu omezuje ve výchozím stavu užitečnost používání CPFP během špiček. Uživatel, jehož CPFP transakci vlastní uzel přijme díky navýšené kapacitě, si nemusí všimnout, že tuto transakci nikdo jiný nepřijal.

Síť přeposílání transakcí sestává z jednotlivých uzlů, které se k síti dynamicky připojují a odpojují. Každý z nich musí sám sebe chránit před zneužitím. Proto nemůžeme zaručit, že se každý uzel dozví o každé nepotvrzené transakci. Zároveň bitcoinové síti prospívá, konvergují-li uzly ke shodné množině pravidel přeposílání transakcí, díky které mají mempooly stejnorodý obsah. Příští článek osvětlí, jaká pravidla byla přijata pro co nejlepší fungování celé sítě.

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.

• ● Knihovny Greenlight open source: Nekustodiální CLN poskytovatel služeb Greenlight zveřejnil repozitář klientských knihoven, jazykových rozhraní a také průvodce testovacím frameworkem.

• ● Debugger tapscriptu Tapsim: Tapsim je nástrojem pro debugování (viz zpravodaj č. 254) a vizualizaci tapscriptu používající btcd.

• ● Oznámen Bitcoin Keeper 1.0.4: Bitcoin Keeper je mobilní peněženka podporující multisig, hardwarová podpisová zařízení, BIP85 a díky poslednímu vydání také coinjoin používající protokol Whirlpool.

• ● Oznámena lightningová peněženka EttaWallet: Nedávno byla oznámena mobilní EttaWallet s LN (díky LDK) a důrazem na použitelnost inspirovanou referenčním designem daily spending wallet od Bitcoin Design Community.

• ● Oznámeno ověření konceptu synchronizace hlaviček bloků založených na zkSNARKs: BTC Warp je ověřením konceptu lehkého synchronizačního klienta používajícího zkSNARKs k prokázání a ověření řetězce hlaviček bitcoinových bloků. Více podrobností lze nalézt v blogovém příspěvku.

• ● Vydán lnprototest v0.0.4: Projekt lnprototest je testovacím nástrojem pro LN včetně „sady pomocných funkcí napsaných v Python3 navržených k usnadnění psaní nových testů navrhovaných změn protokolu LN a testů existujících implementací.”

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.

• ● Eclair v0.9.0 je novým vydáním této implementace LN, které „obsahuje hodně přípravných prací důležitých (a složitých) lightningových funkcí: dual-funding, splicing a BOLT12 nabídky.” Tyto funkce jsou prozatím experimentální. Vydání také „dává nové schopnosti pluginům, přináší opatření proti několika typům DoS a zlepšuje výkonnost v mnoha oblastech.”

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.

• ● LDK #2294 přidává podporu pro přehrávání onion zpráv a přináší LDK blíže k plné podpoře nabídek.

• ● LDK #2156 přidává podporu keysend plateb, které používají zjednodušené platby s více cestami. LDK dříve podporovalo obě tyto technologie, avšak pouze pokud byly použité odděleně. Platby s více cestami musí používat skrytá data, ale LDK dříve odmítalo keysend platby se skrytými daty. Byla také přidána chybová hlášení, nastavení a varování, aby potenciálním problémům zabránila.