Tento týden přinášíme popis nápadu na zabránění pinningu coinjoinových transakcí a návrhu na spekulativní využití vysněných změn konsenzu. Též nechybí další příspěvek do naší krátké týdenní série o pravidlech mempoolu a pravidelné rubriky s populárními otázkami a odpověďmi z Bitcoin Stack Exchange, novými vydáními a změnami v populárním páteřním bitcoinovém software.

Novinky

  • ● Přeposílání v3 transakcí zabraňuje pinningu coinjoinu: Greg Sanders ve svém příspěvku do emailové skupiny Bitcoin-Dev popsal, jak by mohla navrhovaná pravidla přeposílání v3 transakcí pomoci vytvářet coinjoinové transakce s více stranami, které by nebyly náchylné k transaction pinningu. Hrozba pinningu spočívá v možnosti jednoho z účastníků použít svůj vstup k vytvoření konfliktní transakce, která by zabránila coinjoinové transakci v konfirmaci.

    Sanders navrhuje, že by se mohly coinjoinové transakce této hrozbě vyhnout tím, že by přiměly všechny účastníky nejprve utratit své bitcoiny na skript, který by bylo možné utratit buď podpisy všech účastníků coinjoinu nebo pouze tímto účastníkem po expiraci časového zámku. V případě koordinovaného coinjoinu by musel koordinátor podepsat spolu s účastníkem (nebo účastník sám po uplynutí časového zámku).

    Chtěl-li by účastník podepsat konfliktní transakci před uplynutím časového zámku, musel by získat podpisy buď ostatních účastníků nebo koordinátora, což by se mu podařilo jen v případě, kdy by podepsání bylo v zájmu všech (např. v případě navýšení poplatků).

  • ● Spekulativní využívání vysněných změn konsenzu: Robin Linus zaslal do emailové skupiny Bitcoin-Dev příspěvek s nápadem na utracení peněz na fragment skriptu, který nebude moci být spuštěn po dlouhou dobu (např. 20 let). Byl-li by tento fragment interpretován podle současných pravidel konsenzu, umožnil by těžařům za 20 let nárokovat všechny prostředky. Fragment je však navržen tak, aby změna pravidel konsenzu dala fragmentu odlišný význam. Linus dává za příklad opkód OP_ZKP_VERIFY, který by v případě přidání do bitcoinu umožnil nárokovat prostředky komukoliv, kdo poskytne důkaz s nulovou znalostí (Zero-Knowledge Proof) na program s určitým hashem.

    Tento mechanismus by umožnil lidem utratit dnes bitcoin na jeden z těchto skriptů a za důkaz o tomto utracení obdržet ekvivalentní množství bitcoinů na sidechainu nebo alternativním chainu (jednosměrný peg). Bitcoiny na druhém chainu by mohly být opakovaně utráceny po dobu 20 let, dokud by neexpiroval časových zámek. Poté by mohl současný vlastník bitcoinů na druhém chainu vygenerovat ZKP důkaz, že bitcoiny vlastnil, a použít jej k vyzvednutí uzamčeného vkladu na bitcoinovém mainnetu (obousměrný peg). S dobrým návrhem ověřovacího programu by bylo vyzvednutí snadné a flexibilní.

    Autoři poznamenávají, že lidé benefitující z tohoto konstruktu (např. příjemci bitcoinů na druhém chainu) by se v podstatě sázeli, že nastane změna pravidel konsenzu (např. že bude přidán OP_ZKP_VERIFY). To jim dává podnět, aby změnu propagovali. Příliš silná propagace však může ostatní odrazovat. Tento nápad v době psaní neobdržel žádné reakce.

Čekání na potvrzení 7: síťové zdroje

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.

Předchozí článek popisoval ochrany zdrojů uzlu. Jelikož mohou být zdroje u každého uzlu jedinečné, mohou být konfigurovatelné. Též jsme přednesli argumenty, proč je lepší konvergovat k jednomu souboru pravidel. Co by však mělo být součástí těchto pravidel? Tento článek vysvětlí koncept celosíťových zdrojů kritických pro škálovatelnost, aktualizovatelnost a přístupnost nastartování a udržování plného uzlu.

Jak bylo popsáno v předchozích příspěvcích, distribuovaná struktura bitcoinové sítě je zásadní pro dosažení jeho ideologických cílů. Peer-to-peer podstata bitcoinu umožňuje, aby pravidla sítě vyvstávala z hrubého konsenzu voleb jednotlivých provozovatelů uzlů, a omezuje pokusy o získání nepatřičného vlivu v síti. Tato pravidla jsou vynucována jednotlivě každým uzlem ověřujícím každou transakci. Různorodá a zdravá populace uzlů vyžaduje, aby byly náklady na provozování uzlů nízké. Je náročné škálovat v globálním měřítku jakýkoliv projekt, ale činit tak bez obětování decentralizace je jako bojovat s jednou rukou za zády. Bitcoin se snaží o udržení rovnováhy nekompromisní ochranou svých sdílených síťových zdrojů: množiny UTXO, datové stopy na blockchainu spolu s výpočetními nároky vyžadované na jejich zpracování a systém evoluce protokolu.

Není nutné znovu připomínat celou válku o velikost bloků, abychom si uvědomili, že omezení nárůstu blockchainu je nezbytné k zachování přístupnosti provozování vlastního uzlu. Na úrovni pravidel také existuje prostředek pro omezování růstu blockchainu v podobě minRelayTxFee, tedy minimálního poplatku nutného pro přeposlání transakce ve výši 1 sat/vbyte. Toto pravidlo zajišťuje existenci minimálních nákladů k omezení „bezmezné poptávky po trvalém vysoce replikovaném úložišti.”

Původně se pro sledování stavu sítě uchovávaly všechny transakce, které měly neutracené výstupy. Nově představená množina UTXO jako prostředek sledování prostředků přinesla významnou redukci dat. Od té doby se množina UTXO stala ústřední datovou strukturou. Vyhledání UTXO tvoří hlavní podíl všech přístupů do paměti, obzvláště během prvotního stahování bloků. Bitcoin Core již pro UTXO mezipaměť používá optimalizovanou datovou strukturu, avšak velikost množiny UTXO určuje, jaká její část se do mezipaměti nevměstná. Větší množina UTXO znamená více cache miss, což zpomaluje validaci bloků, prvotní stahování a validaci transakcí. „Dust limit” je příkladem pravidla, které omezuje tvorbu neutratitelných UTXO, jejichž hodnota je nižší než náklady na utracení. I přes to se „prachové bouře” s tisíci transakcemi objevily dokonce i v roce 2020.

Když se použití bare multisigu stalo populárním způsobem publikování dat na blockchainu, upravila se definice standardní transakce, aby jako alternativu povolovala jeden OP_RETURN výstup. Lidé si uvědomili, že by bylo nemožné zabránit uživatelům v publikování dat na blockchainu, avšak alespoň by tato data, uložena v neutratitelných výstupech, nemusela být navždy udržována v množině UTXO. Bitcoin Core 0.13.0 přinesl volbu -permitbaremultisig, která umožňuje uživatelům odmítnout nepotvrzené transakce obsahující výstupy s bare multisig.

I když pravidla konsenzu povolují ve výstupech jakékoliv skripty, Bitcoin Core přeposílá pouze několik známých vzorů skriptů. Díky tomu je snazší porozumět dopadům na síť, včetně nákladů na validaci a upgrade protokolu. Například transakce se vstupním skriptem obsahujícím op-kódy, P2SH vstupem s více než 15 podpisy nebo P2WSH vstupem, jehož witness by tvořil v zásobníku více než 100 položek, by všechny byly označeny za nestandardní. (Přehled pravidel obsahuje příklady a jejich motivace.)

Bitcoinový protokol je žijícím softwarovým projektem, který se musí nadále vyvíjet, aby odpovídal na budoucí potíže či potřeby uživatelů. Pro tento účel obsahuje konsenzus několik nepoužívaných děr („upgrade hooks”), jako je příloha („annex”), verze taprootových listů, verze witnessů, OP_SUCCESS a množství NOOP op-kódů. Avšak podobně jako absence centrálních bodů selhání brání útokům, vyžadují i celosíťové upgrady software koordinaci desítek tisíc nezávislých provozovatelů uzlů. Uzly nepřeposílají transakce, které používají některé z rezervovaných děr, dokud nebude jejich význam definován. Tento postup má odrazovat aplikace, aby nezávisle tvořily konfliktní standardy, což by vedlo k nemožnosti začlenit do konsenzu standard jedné aplikace bez zneplatnění standardu aplikace jiné. A pokud změna konsenzu nastane, uzly, které okamžitě neupgradují a tedy neví o nových pravidlech konsenzu, nemohou být přinuceny k akceptování zatím nevalidních transakcí do svých mempoolů. Tento způsob odrazování vede k dopředné kompatibilitě uzlů a umožňuje síti bezpečně upgradovat pravidla konsenzu bez nutnosti vyžadovat synchronizovanou aktualizaci software.

Jak můžeme vidět, používání pravidel k ochraně sdílených síťových zdrojů napomáhá k ochraně vlastností celé sítě a zároveň ponechává otevřené dveře k budoucímu vývoji protokolu. Také vidíme, jak třenice mezi růstem sítě a striktním omezením váhy bloků vedla k osvojení nejlepších postupů, dobrého technického designu a inovací. Příští týden prozkoumáme pravidla mempoolu jako vstupní brány protokolů druhé vrstvy a systémů chytrých kontraktů.

Vybrané otázky a odpovědi z Bitcoin Stack Exchange

Bitcoin Stack Exchange je jedním z prvních míst, kde hledají přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme některé z otázek a odpovědí, které obdržely vysoký počet hlasů.

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.

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 #6303 přidává nové RPC volání setconfig, které umožňuje měnit některá nastavení bez restartování démonu.

  • ● Eclair #2701 zaznamenává, kdy je přijato HTLC a kdy je urovnáno. To umožňuje sledovat, jak dlouho bylo z pohledu uzlu HTLC vyřizováno. Je-li mnoho HTLC nebo několik HTLC s vysokou hodnotou vyřizováno po dlouhou dobu, může to značit probíhající útok zahlcením kanálu. Sledování trvání HTLC napomáhá k odhalování podobných útoků a může je omezovat.

  • ● Eclair #2696 mění způsob nastavení jednotkových poplatků uživateli. V předchozích verzích mohli uživatelé určit jednotkové poplatky zvolením cíle bloku, např. nastavení na 6 znamenalo, že se Eclair pokusí o potvrzení transakce během šesti bloků. Nově uživatel zvolí mezi „pomalu,” „středně” a „rychle,” což se přeloží do konkrétního jednotkového poplatku použitím konstanty nebo cíle.

  • ● LND #7710 dává pluginům a samotnému démonu přístup k datům obdrženým dříve v rámci HTLC. To je nezbytné pro zaslepování tras a může být mimo jiné použito různými opatřeními proti zahlcení kanálu.

  • ● LDK #2368 umožňuje akceptovat nové kanály vytvořené spojením, které používá anchor výstupy, ale vyžaduje, aby měl ovládající program možnost každý kanál zvlášť akceptovat. Důvodem je, že řádné vyrovnání anchor kanálů může po uživateli vyžadovat vlastnictví jednoho či více UTXO s dostatečnou hodnotou. LDK jako knihovna netuší, jaká UTXO mimo LN uživatelova peněženka vlastní. Tento mechanismus dává programu možnost ověřit přítomnost tohoto UTXO.

  • ● LDK #2367 zpřístupňuje anchor výstupy běžnému uživateli API.

  • ● LDK #2319 umožňuje spojení vytvářet HTLC, které je zavázáno k platbě nižší než je původní částka určená odesílatelem. Zbytek si může spojení přisvojit jako poplatek. Tato možnost je užitečná pro vytváření JIT kanálů, ve kterých spojení obdrží HTLC pro příjemce, který ještě nemá kanál. Spojení vytvoří onchain transakci, která financuje kanál a zavazuje k HTLC uvnitř tohoto kanálu, ale způsobuje dodatečné náklady na poplatky při vytváření onchain transakce. Tento nový poplatek může sloužit jako kompenzace.

  • ● LDK #2120 přidává podporu pro hledání trasy k příjemci, který používá zaslepné cesty.

  • ● LDK #2089 přidává funkci pro zpracování událostí, která usnadní peněženkám navýšit poplatek za HTLC, která musí být urovnána onchain.

  • ● LDK #2077 refaktoruje velké množství kódu pro snadné budoucí přidání podpory kanálů s oboustranným vkladem.

  • ● Libsecp256k1 #1129 implementuje techniku ElligatorSwift přinášející 64bytové kódování veřejného klíče, které je výpočetně nerozeznatelné od náhodných dat. Modul ellswift poskytuje funkce pro kódování a dekódování veřejných klíčů v novém formátu, funkce pro generování nových náhodných klíčů a pro provádění ECDH výměny klíčů s tímto kódováním. ECDH založené na ellswift bude použito v navazování spojení v rámci protokolu P2P šifrovaného transportu verze 2 (BIP324).