Tento týden popisujeme návrh na odstranění některých drobností ze specifikace LN, které již nejsou relevantní, a přinášíme předposlední část naší krátké týdenní série o pravidlech mempoolu. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o nových vydáních a kandidátech na vydání a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Návrh na pročištění specifikace LN: Rusty Russell zaslal do emailové skupiny Lightning-Dev příspěvek s odkazem na PR, ve kterém navrhuje odstranit některé funkce, které již nejsou podporovány v moderních implementacích LN, a ponechané funkce označit jako navždy podporované. Russell dále poskytl výsledky svého výzkumu podporovaných funkcí veřejnými uzly dle jejich gossip zpráv. Výsledky naznačují, že téměř všechny uzly podporují následující funkce:

  • ● Onion zprávy s proměnlivou velikostí: součástí specifikace jsou od roku 2019 (viz zpravodaj č. 58, angl.), tedy od doby, kdy byly také představeny Type-Length-Value (TLV) pole. Tím byl nahrazen původní formát šifrovaného onion routingu, který vyžadoval použití zpráv o pevné délce a omezoval počet skoků na 20. Díky formátu s proměnlivou velikostí je snazší přeposílat konkrétním skokům libovolná data. Jedinou nevýhodou je, že celková velikost zprávy zůstává konstantní, čili nárůst v objemu posílaných dat snižuje maximální počet skoků.

  • ● Gossip dotazy: součástí specifikace od roku 2018 (viz BOLTs #392). Umožňují uzlu vyžádat od svých spojení pouze podmnožinu gossip zpráv poslaných jinými uzly v síti. Uzel může vyžádat například pouze nejnovější aktualizace a ignorovat starší, čímž ušetří na datovém přenosu a čase zpracování.

  • ● Ochrana před ztrátou dat: součástí specifikace od roku 2017 (viz BOLTs #240). Uzly používající tuto funkci posílají před novým připojením informace o svém posledním stavu kanálu. Díky tomu může uzel detekovat, že přišel o data. Dále nabádá uzel, který o data nepřišel, aby kanál uzavřel ve svém posledním stavu. Viz zpravodaj č. 31 (angl.) pro další informace.

  • ● Statické klíče vzdálené strany: součástí specifikace od roku 2019 (viz zpravodaj č. 67, angl.), umožňují uzlu požadovat, aby každý channel update zavazoval k posílání neHTLC prostředků na stejnou adresu. Předtím mohla být v každém channel update použita jiná adresa. Po této změně uzel, který používá tento protokol a ztratí data, nakonec téměř vždy obdrží alespoň část svých prostředků na zvolenou adresu, jako je například adresa v HD peněžence.

  První odpovědi k návrhu na pročištění byly pozitivní.

Čekání na potvrzení 9: návrhy 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ý příspěvek popsal anchor výstupy a CPFP carve out zajišťující, že kterákoliv strana kanálu může navýšit poplatek sdílené commitment transakce bez nutnosti spolupráce. Tento přístup stále obsahuje několik nevýhod: prostředky kanálu jsou svázané, aby mohly vytvořit anchor výstupy, jednotkový poplatek commitment transakce je většinou o trochu vyšší, aby byl vyšší než minimální poplatek mempoolu, a CPFP carve out povoluje pouze jednoho potomka navíc. Anchor výstupy nemohou zajistit podobnou dostupnost navýšení poplatků transakcí sdílených mezi více než dvěma stranami, jako je coinjoin nebo protokoly s více účastníky. Tento příspěvek zkoumá současné snahy adresovat tato i jiná omezení.

Přeposílání balíčků obsahuje P2P protokol a změny pravidel, které umožní transport a validaci skupin transakcí. Díky tomu by mohly být poplatky commitment transakcí navýšeny potomkem, i kdyby nesplňovaly požadavek minimálního jednotkového poplatku mempoolu. Dále by RBF balíčku umožnilo potomkovi navyšujícímu poplatek zaplatit za nahrazení transakcí, se kterými jsou jeho rodiče v konfliktu. Přeposílání balíčků je navrženo tak, aby odstranilo obecná omezení na základní vrstvě protokolu. Avšak díky jeho použití pro navyšování poplatků sdílených transakcí byly na jeho základě představeny pokusy o eliminaci pinningu v některých konkrétních případech. Například by RBF balíčku umožnil commitment transakcím nahrazení sebe navzájem, pokud by byly zveřejněny spolu se svými potomky navyšujícími poplatek. Díky tomu by nebylo potřeba mít v každé commitment transakci několik anchor výstupů.

Drobným zádrhelem je, že existující pravidla pro RBF vyžadují, aby nahrazující transakce platila vyšší absolutní poplatek než součet poplatků placených všemi nahrazovanými transakcemi. Toto pravidlo napomáhá prevenci odepření služby opakovanými nahrazeními, ale umožňuje záškodníkům zvýšit náklady na nahrazení transakce připojením potomka, který má vysoký poplatek, ale nízký jednotkový poplatek, což zamezuje transakci ve vytěžení. Tomuto druhu pinningu se často říká „pinning třetího pravidla.”

Vývojáři též navrhli zcela odlišné způsoby přidávání poplatků předem podepsaným transakcím. Například podepsání vstupů transakce s SIGHASH_ANYONECANPAY | SIGHASH_ALL by umožnilo odesílateli transakce poskytnout poplatek připojením dodatečných vstupů, avšak se zachováním výstupů. Jelikož však nemá RBF žádná pravidla vyžadující, aby měla nahrazující transakce vyšší „těžební skóre” (tj. byla by rychleji vybrána do bloku), mohl by útočník „přišpendlit” tento druh transakcí vytvořením nahrazení zatíženého předky s nízkými jednotkovými poplatky. Existující limity předků a potomků nejsou dostatečné, aby omezily výpočetní náročnost této kalkulace, což ztěžuje přesný odhad těžebního skóre transakcí a balíčků transakcí. Jakékoliv připojené transakce mohou ovlivnit pořadí, ve kterém jsou transakce vybírány do bloku. Komponenta, která je plně propojena (nazývající se cluster), může mít jakoukoliv velikost danou současnými limity předků a potomků.

Dlouhodobým řešením adresování některých nedostatků mempoolu a RBF pinning útoků je v mempoolu předělat strukturu dat, aby se sledovaly clustery namísto pouhých množin předků a potomků. Tyto clustery by byly omezeny ve velikosti. Limity clusterů by omezily způsob, kterým by mohli uživatelé utrácet nepotvrzená UTXO, ale díky nim by mohl být celý mempool linearizován použitím těžebního algoritmu založeném na skóre předků, tvorba šablon bloků by byla extrémně rychlá a mohl by být přidán požadavek, aby nahrazující transakce měly vyšší těžební skóre než transakce, které chtějí nahradit.

I přesto je možné, že žádná jedna sada pravidel nemůže uspokojit širokou řadu potřeb a očekávání přeposílání transakcí. Například zatímco pro příjemce dávkové platby je výhodné, že mohou utratit své nepotvrzené výstupy, uvolněné limity potomků vytváří prostor pro pinning RBF balíčků sdílené transakce skrz absolutní poplatky. Návrh na pravidla přeposílání v3 transakcí byl vyvinut, aby umožnil protokolům s kontrakty volitelně používat striktnější sadu limitů balíčků. V3 transakce by povolovaly pouze balíčky o velikosti dva (jeden předek, jeden potomek) a omezovaly váhu potomka. Tyto limity by zabraňovaly RBF pinningu skrz absolutní poplatky a nabídly by některé z výhod mempoolu clusterů bez nutnosti restrukturovat mempool.

Ephemeral anchors dále vylepšují anchor výstupy na základě vlastností přeposílání v3 transakcí a balíčků. Anchor výstupy patřící v3 transakci s nulovým poplatkem budou mít výjimku z limitu neutratitelnosti („dust limit”), pokud jsou utráceny potomkem navyšujícím poplatek. Jelikož transakce s nulovým poplatkem musí mít poplatek navýšený právě jedním potomkem (jinak by neměl těžař motivaci ji začlenit do bloku), je tento anchor výstup dočasný („ephemeral”) a nestane se součástí množiny UTXO. Tento návrh na ephemeral anchors implicitně zabraňuje neanchor výstupům, aby byly utraceny, dokud jsou nepotvrzené a nemají 1 OP_CSV časové zámky, neboť potomek musí tento anchor výstup utratit. Díky tomu by také byl proveditelný LN symmetry (eltoo), který by mohl využít CPFP jako mechanismu poskytování poplatků transakcím uzavírajícím kanál. Dále by mohl být tento mechanismus použit u transakcí sdílených mezi více než dvěma účastníky. Vývojáři používají k nasazení ephemeral anchors a navrhovaných soft forků bitcoin-inquisition, v jehož rámci budují a testují tyto změny na signetu.

Problém pinningu, popsaný mimo jiné v tomto příspěvku, stál loni za množstvím diskuzí a návrhů vylepšení pravidel RBF v emailových skupinách, pull requestech, sociálních médiích a při osobních setkáních. Vývojáři navrhli a implementovali řešení v různých škálách, od malých úprav až po kompletní předělání. Volba -mempoolfullrbf, jejímž účelem je potýkat se s problémem pinningu a nesouladem v BIP125 implementacích, nám připomenula náročnost a důležitost spolupráce v rámci pravidel přeposílání transakcí. A i když byly upřímné snahy o zapojení komunity použitím obvyklých prostředků včetně konverzace v emailové skupině Bitcoin-Dev rok dopředu, bylo zřejmé, že existující způsoby komunikace a rozhodování nevyústily v zamýšlený výsledek a potřebovaly doladit.

Decentralizované rozhodování je náročným, ale nezbytným procesem v podpoře různorodého ekosystému protokolů a aplikací, které používají bitcoinovou síť. Příští týden bude náš poslední příspěvek v této sérii, ve kterém, doufáme, se nám podaří zapojit čtenáře a zlepšit tento proces.

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

Přestaň přeposílat transakce mimo mempool je PR od Marca Falkeho (MarcoFalke) zjednodušující klienta Bitcoin Core odstraněním paměťové datové struktury mapRelay, která může způsobit vysokou spotřebu paměti a není již více potřebná, respektive poskytuje pouze zcela okrajové benefity. Tato mapa obsahuje transakce, které mohou či nemusí být také v mempoolu. Někdy se používá pro generování odpovědi na požadavek getdata.

• Jaké důvody stojí za odstraněním mapRelay?

  Spotřeba paměti této datové struktury je neomezená. I když v běžném případě nespotřebovává tolik paměti, je na pováženou, je-li velikost jakékoliv datové struktury určena chováním vnějších entit (spojení) a nemá žádné maximum. Takové případy mohou vnést DoS zranitelnosti. ➚

• Proč je těžké určit spotřebu paměti mapRelay?

  Každý prvek v mapRelay je ukazatelem na transakci (CTransaction), který může být sdílen s mempoolem. Druhý ukazatel na stejný objekt používá velmi málo dodatečného prostoru v porovnání s jedním ukazatelem. Je-li sdílená transakce odstraněna z mempoolu, veškerý jeho použitý prostor lze připsat mapRelay. Čili spotřeba paměti mapRelay nezávisí pouze na počtu a velikosti transakcí, ale také na tom, kolik jeho transakcí již není v mempoolu. Toto není snadné dopředu určit. ➚

• Jaký problém řeší přidaný m_most_recent_block_txs? (Toto je seznam pouze těch transakcí, které jsou v posledním obdrženém bloku.)

  Jelikož mapRelay není již k dispozici, nemohli bychom bez něj posílat právě vytěžené transakce (z posledního bloku) spojením, která o něj požádají. Tyto transakce již nejsou v našem mempoolu. ➚

• Považujete za nezbytné přidávat m_most_recent_block_txs, či by bylo možné odstranit mapRelay bez náhrady?

  Mezi účastníky review klubu panovala u této otázky nejistota. Někdo navrhl, že by mohl m_most_recent_block_txs vylepšit rychlost propagace bloků, protože pokud naše spojení stále neobdrželo blok, který my jsme právě obdrželi, může schopnost našeho uzlu poskytnout své transakce pomoci zkompletovat našemu spojení kompaktní blok. Jiný návrh byl, že může pomoci v případě chain splitu; pokud by naše spojení bylo na jiném chainu než my, možná obdrželo transakci jinak než z bloku. ➚

• Jaké jsou paměťové požadavky m_most_recent_block_txs v porovnání s mapRelay?

  Počet položek v m_most_recent_block_txs je ohraničen počtem transakcí v bloku. Avšak paměťové požadavky jsou ještě menší, neboť položky v m_most_recent_block_txs jsou sdílené ukazatele na transakce, na které již ukazuje m_most_recent_block. ➚

• Existují případy, ve kterých by v důsledku této změny byly transakce dostupné po kratší nebo delší dobu než předtím?

  Delší, pokud je doba od posledního bloku delší než 15 minut (což je čas, po který zůstávají položky uloženy v mapRelay), jinak kratší. To je přijatelné, neboť volba 15 minut byla spíše nahodilá. Avšak tato změna může snížit dostupnost transakcí v případě chain splitu hlubšího než jeden blok (ty jsou extrémně vzácné), protože neuchováváme transakce, které jsou obsaženy pouze v bloku, jež není v našem řetězci. ➚

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.4-beta je údržbovým vydáním tohoto uzlu, které opravuje memory leak postihující některé uživatele.

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.

• ● Bitcoin Core #27869 zobrazuje během načítání zastaralé peněženky varování v rámci pokračující snahy popsané v Bitcoin Core #20160, jejímž cílem je pomoci uživatelům migrovat zastaralé peněženky na peněženky s deskriptory, jak bylo zmíněno ve zpravodajích č. 125, č. 172 (oba angl.) a č. 230.