Tento týden přinášíme další příspěvek do naší krátké týdenní série o pravidlech mempoolu. Též nechybí naše pravidelné rubriky s oznámeními o nových vydáních a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

V emailových skupinách Bitcoin-Dev a Lightning-Dev se tento týden neobjevily žádné významné novinky.

Čekání na potvrzení 8: pravidla jako rozhraní

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.

V této sérii jsme zatím prozkoumali motivace a záludnosti spojené s decentralizovaným přeposíláním transakcí, které vedou k lokální i globální poptávce po přísnějších pravidlech validace, než je konsenzus. Jelikož mohou mít změny pravidel přeposílání transakcí v Bitcoin Core dopad na přeposílání transakcí, vyžadují nejdříve dosažení společenského přijetí v rámci širší bitcoinové komunity. Podobně musí být i aplikace a protokoly na druhé vrstvě navrženy tak, aby se vyhnuly odmítání svých transakcí.

Protokoly s kontrakty jsou ještě závislejší na pravidlech spojených s prioritizací, protože vymahatelnost onchain závisí na možnosti mít transakce rychle potvrzené. V nepřátelském prostředí mohou mít podvádějící protistrany zájem na zdržení konfirmace, musíme tedy také uvažovat, jak by mohly být drobnosti v pravidlech přeposílání transakcí použity proti uživateli.

Transakce v lightning network se drží pravidel standardnosti zmíněných v předchozích článcích. Například jeho peer-to-peer protokol obsahuje ve zprávě open_channel volbu dust_limit_satoshis určující práh neutratitelnosti. Jelikož transakce obsahující výstup s hodnotou nižší než tento práh by nebyly uzly přeposlány, jsou tyto platby považovány za „nevymahatelné onchain” a jsou z commitment transakcí vyřazeny.

Protokoly s kontrakty často používají časové zámky, aby poskytly každému účastníkovi možnost zpochybnit stav publikovaný onchain. Pokud by transakce dotčeného uživatele nebyla potvrzena před uplynutím doby zámku, mohl by přijít o prostředky. Proto jsou poplatky extrémně důležitým nástrojem pro navýšení priority konfirmace. Odhad jednotkového poplatku je ztížen tím, že transakce budou zveřejněny v neznámém čase, uzly jsou často provozovány jako lehké klienty a některé možnosti navyšování poplatků nemusí být k dispozici. Například byl-li by jeden z účastníků LN kanálu offline, mohl by ten druhý jednostranně zveřejnit předem podepsanou commitment transakci a tím dosáhnout vyrovnání společných prostředků onchain. Žádná ze stran nemůže sama utratit společné UTXO, je-li tedy jedna strana offline, podepsání nahrazující transakce pro navýšení poplatku commitment transakce je nemožné. Namísto toho mohou commitment transakce obsahovat anchor výstupy, které pomohou účastníkům kanálu připojit v době zveřejnění potomka navyšujícího poplatek (CPFP).

Tento způsob navyšování poplatků má ale také svá omezení. Jak bylo zmíněno v předchozím příspěvku, přidání CPFP transakce není efektivní, pokud minimální jednotkový poplatek mempoolu přeroste poplatek commitment transakce. Musí tedy i tak být podepsány s mírně přeceněným jednotkový poplatkem pro případ navýšení minimálního poplatku mempoolu. Dále během vývoje anchor výstupů byly také zohledněny případy, kdy může být v zájmu jedné strany konfirmaci pozdržet. Například jedna strana (Alice) může zveřejnit svou commitment transakci před vypnutím uzlu. Pokud by byl jednotkový poplatek této commitment transakce příliš nízký pro dosažení okamžité konfirmace a pokud by Bob, Alicina protistrana, její transakci neobdržel, mohl by být zmaten, proč zveřejnění jeho verze commitment transakce není úspěšně propagováno v síti. Každá commitment transakce má dva anchor výstupy, takže každá strana může použít CPFP na kteroukoliv commitment transakci, například Bob může zkusit naslepo zveřejnit navýšení poplatku Aliciny verze commitment transakce, i když si není jist, zda předtím ona svou verzi zveřejnila. Každý anchor výstup disponuje malou hodnotou nad prahem neutratitelnosti. Po nějaké době ji může nárokovat kdokoliv jako opatření před zahlcením množiny UTXO.

Zaručit každé straně možnost navýšit poplatek transakce pomocí CPFP je však mnohem složitější, než přiřadit každé straně anchor výstup. Jak bylo zmíněno v předchozím příspěvku, jako ochranu před DoS omezuje Bitcoin Core počet a celkovou velikost potomků, kteří mohou být přiřazeni nepotvrzené transakci. Jelikož má každá protistrana možnost přidat potomky sdíleným transakcím, mohla by jedna z nich zablokovat CPFP transakci té druhé vyčerpáním tohoto limitu a tím jí zabránit v propagaci. Přítomnost těchto potomků tak v mempoolech „přišpendlí” tuto commitment transakci na pozici s nízkou prioritou.

Na zabránění tohoto potenciálního útoku je navrhováno, aby byly všechny ostatní výstupy omezeny relativním časovým zámkem, což by zabránilo v jejich utracení před konfirmací. Dále byla upravena pravidla v Bitcoin Core, aby bylo možné přidat ještě jednoho potomka (CPFP carve out), pokud je tento potomek malý a nemá žádné další předky. Tato kombinace změn v obou protokolech zajišťuje, že alespoň dva účastníci ve sdílené transakci by mohli v čase zveřejnění upravit jednotkový poplatek, aniž by významně navýšili možnost DoS útoku.

Zabránění CPFP naplněním omezení počtu potomků je příkladem pinning útoků. Tyto útoky zneužívají omezení v pravidlech mempoolu, aby transakcím zabránily v přístupu do mempoolu nebo v potvrzení. V tomto případě představují pravidla mempoolu kompromis mezi odolností vůči DoS a incentivami. Nějaký kompromis musí být učiněn: uzel by měl zvažovat navýšení poplatků, ale nemůže zpracovávat nekonečně mnoho potomků. CPFP carve out upravuje tento kompromis pro konkrétní případ použití.

Vedle vyčerpání limitu potomků existují i další pinning útoky, které zabraňují použití RBF, činí RBF příliš drahým či zneužívají RBF ke zpoždění konfirmace ANYONECANPAY transakcí. Pinning je problémem pouze v případech, kdy více stran spolupracuje na vytvoření společné transakce nebo kde má nedůvěryhodná strana prostor upravovat transakci. Minimalizace přístupu transakce nedůvěryhodným stranám je obecně dobrým způsobem vyhýbání se pinningu.

Tyto třecí plochy zdůrazňují nejen důležitost pravidel jako rozhraní pro aplikace a protokoly v rámci ekosystému bitcoinu, ale také ukazují místa, která potřebují vylepšit. Příští týden se podíváme na návrhy pravidel a otevřené otázky.

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.

• ● Core Lightning 23.05.2 je údržbovým vydáním této implementace LN uzlu, které obsahuje opravy několika chyb, které mohou mít vliv na uživatele produkčních nasazení.

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 #24914 načítá záznamy z databáze peněženky seřazené podle druhu namísto procházení celé databáze dvakrát za účelem detekce závislostí. Po této změně již nemusí být některé peněženky s poškozenými záznamy načteny, avšak mohou být načteny předchozí verzí Bitcoin Core a migrovány na novou verzi.

• ● Bitcoin Core #27896 odstraňuje experimentální sandboxing systémových volání (syscall; viz zpravodaj č. 170, angl.). Související report a jeho komentáře hovoří o nevýhodách této funkce včetně udržovatelnosti seznamu volání a podpory OS, alternativy s lepší podporou a úvahy, zda by syscall sandboxing měl být zodpovědností Bitcoin Core.

• ● Core Lightning #6334 upravuje a rozšiřuje experimentální podporu anchor výstupů (viz prvotní implementace ve zpravodaji č. 111, angl.). PR dále obsahuje aktivaci experimentální podpory HTLC anchors s nulovými poplatky a přidání nastavitelných kontrol, které zajistí, že má uzel dostatek prostředků, pokud by potřeboval provozovat anchor kanál.

• ● BIPs #1452 přidává do specifikace BIP329 pro exportní formát popisků peněženek nový volitelný štítek spendable, který určuje, zda je připojený výstup peněženkou utratitelný. Mnoho peněženek implementuje funkce kontroly mincí, které uživateli umožňují určit, které výstupy nemá algoritmus výběru mincí zvažovat pro utracení, například výstupy redukující soukromí uživatelů.

• ● BIPs #1354 přidává BIP389 pro deskriptory s více derivačními cestami popsané ve zpravodaji č. 211 (angl.). Umožňuje jedinému deskriptoru specifikovat dvě svázané BIP32 cesty pro generování hierarchických deterministických klíčů: jednu pro příchozí platby, druhou pro interní platby (např. drobné).