Tento týden přinášíme popis návrhu nového protokolu spravovaného joinpoolu a souhrn nápadu na přeposílání transakcí pomocí protokolu Nostr. Též nechybí další příspěvek do naší krátké týdenní série o pravidlech mempoolu a naše pravidelné rubriky se souhrnem zajímavých otázek a odpovědí z Bitcoin Stack Exchange, seznamem nových softwarových vydání a popisem významných změn v populárních páteřních bitcoinových projektech.

Novinky

• ● Návrh na spravovaný joinpool protokol: tento týden zaslal Burak Keceli do emailové skupiny Bitcoin-Dev příspěvek s popisem nápadu na Ark („Archa”), nový protokol ve stylu joinpoolů, ve kterém mohou vlastníci bitcoinů volitelně využít protistranu jako spolu-podpisovatele všech transakcí v rámci určitého časového úseku. Vlastníci mohou své bitcoiny buď po uplynutí časového zámku jednostranně vybrat na blockchainu, nebo je mohou okamžitě a bez požadavku na důvěru poslat offchain protistraně před uplynutím časového zámku.

  Protistrana může, stejně jako jakýkoliv uživatel bitcoinu, kdykoliv zveřejnit transakci utrácející pouze její prostředky. Je-li výstup této transakce použit jako vstup offchainové transakce přenášející prostředky od vlastníka protistraně, bude offchain transfer zneplatněn, pokud se onchain transakce nepotvrdí během rozumně stanovené doby. V tomto případě by protistrana nepodepsala svou onchain transakci, dokud by neobdržela podepsanou offchain transakci. Tento způsob poskytuje protokol pro atomický transfer od vlastníka k protistraně v jednom směru, s jedním skokem a bez požadavku na důvěru. Keceli popisuje tři možnosti použití tohoto protokolu pro atomický transfer:

  • ● Míchání mincí: několik uživatelů v rámci joinpoolu může spolu vytvořit atomické výměny svých offchain prostředků za novou offchain hodnotu o stejné výši. Jelikož jakákoliv chyba v onchain komponentě jednoduše celou výměnu revokuje a všechny prostředky vrátí, je tato operace rychlá. Zaslepovací protokol podobný protokolu v některých existujících implementacích coinjoinu může zamezit, aby mohl kdokoliv spočítat uživateli držené bitcoiny.

  • ● Vnitřní transfery: uživatel může poslat své offchain prostředky jinému uživateli v rámci stejné protistrany. Atomicita zajišťuje, že buď příjemce dostane své peníze nebo se vrátí odesílateli. Příjemci, kteří nedůvěřují ani odesílateli, ani protistraně, budou muset čekat na stejné množství konfirmací jako v případě běžné onchain transakce.

    Keceli a jeden z diskutujících odkázali na předchozí výzkum popisující, jak neekonomické může být dvojí utrácení zero-conf plateb, pokud jsou spojeny s finančním závazkem, který si těžař může v případě dvojího utrácení přisvojit. Díky tomu by mohli příjemci akceptovat platbu za méně než sekundu i v případě nulové důvěry.

  • ● Platba LN faktur: uživatel se může rychle zavázat k platbě offchainových prostředků protistraně, pokud protistrana zná tajný kód, což umožní uživateli pomocí protistrany platit HTLC faktury podobné LN.

    Ani zde, podobně jako v případě vnitřních transferů, nemůže uživatel obdržet prostředky bez požadavku na důvěru, takže by neměl odhalit tajný kód, dokud platba neobdrží dostatečné množství potvrzení nebo není zabezpečena dostatečným finančním závazkem.

  Keceli tvrdí, že základní protokol může být nad bitcoinem implementován již dnes s využitím časté interakce mezi členy joinpoolu. Pokud by byl implementován nějaký návrh na kovenanty jako např. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT nebo OP_CAT + OP_CHECKSIGFROMSTACK, členové joinpoolu by museli interagovat s protistranou pouze v coinjoinu, posílání platby nebo obnově časového zámku offchainových prostředků.

  Každý coinjoin, platba nebo obnova vyžadují zveřejnění commitmentu v onchainové transakci, avšak jedna malá transakce může obsahovat v podstatě neomezené množství operací. K zajištění včasného dokončení operací navrhuje Keceli, aby byly onchainové transakce posílány každých pět sekund. Uživatelé by tak nemuseli čekat déle než tuto dobu. Každá transakce je oddělená, není možné zkombinovat commitmenty z několika transakcí pomocí RBF bez porušení těchto commitmentů nebo spolupráce všech uživatelů přítomných v předchozích kolech, a tedy přes 6,3 miliónů transakcí by mohlo být potřeba potvrdit každý rok pro každou protistranu. Jednotlivé transakce jsou však malé.

  Některé z komentářů zaslaných do emailové skupiny:

  • ● Požadavek na dokumentaci: přinejmenším dva diskutující si vyžádali dodatečnou dokumentaci o fungování systému. Kvůli úrovni popisu v emailové skupině jej nedokázali dostatečně analyzovat. Keceli mezitím začal publikovat návrhy specifikací.

  • ● Obavy o pomalost v porovnání s LN: několik lidí poznamenalo, že není v prvotním designu možné přijímat platbu z joinpoolu bez požadavku na důvěru (offchain ani onchain) bez čekání na dostatečné množství konfirmací. To může trvat hodiny, kdežto mnoho LN plateb je uzavřeno za méně než sekundu. I s finanční pojistkou by byla LN obecně rychlejší.

  • ● Obavy o dopad na blockchain: jeden komentující poznamenal, že v případě jedné transakce každý pět sekund by zhruba 200 protistran zabralo celý prostor v každém bloku. Jiná odpověď předpokládala, že každá z onchain transakcí protistran by byla podobně veliká jako otevírací či uzavírací transakce LN. Protistrana s miliónem uživatelů, která by vytvářela 6,3 miliónů onchain transakcí za rok, by zabrala stejné množství prostoru jako otevírací a zavírací transakce 6,3 kanálů každého z těchto uživatelů za rok. Onchain náklady na LN by tedy byly nižší, avšak pouze do určitého bodu.

  • ● Obavy o velikost horké peněženky a kapitálu: jedna reakce se zamýšlela nad nutností protistrany držet k dispozici, zřejmě v horké peněžence, množství bitcoinů rovné částce, kterou mohou uživatelé utratit v dohledné budoucnosti. Dle současného designu by po utracení protistrana těmito bitcoiny nemusela disponovat až po dobu 28 dní. Pokud by protistrana účtovala nízkou úrokovou sazbu 1,5 % za rok, rovnalo by se to 0,125% poplatku z každé transakce zprostředkované protistranou (včetně coinjoinů, interních transferů a LN plateb). Pro porovnání, veřejné statistky dostupné v době psaní (poskytnuté 1ML) ukazují, že medián jednotkového poplatku za jeden skok LN transferů je 0,0026 %, téměř 50krát nižší.

  Několik komentářů projevilo nad návrhem nadšení a těšilo se na budoucí průzkum.

• ● Přeposílání transakcí po Nostru: Joost Jager zaslal do emailové skupiny příspěvek se žádostí o poskytnutí zpětné vazby k nápadu Bena Carmana navrhující použít protokol Nostr k přeposílání transakcí, které mají potíže s propagací v bitcoinové P2P síti.

  Konkrétně se Jager zamýšlí nad možností použít Nostr pro přeposílání balíčků transakcí, jako je například přeposílání rodičovské transakce s příliš nízkým jednotkovým poplatkem spolu s jejím potomkem, který by svým poplatkem rodiče kompenzoval. To by učinilo CPFP spolehlivějším a efektivnějším pro navyšování poplatků. Tato schopnost se nazývá přeposílání balíčků („package relay”) a vývojáři Bitcoin Core již pracují na její implementaci pro P2P síť. Revizi návrhu a implementace přeposílání balíčků ztěžuje nutnost ujistit se, že nepřinesou nové možnosti odepření služby (DoS) jednotlivým uzlům ani těžařům (nebo obecně celé síti).

  Jager též poznamenal, že přeposílající servery Nostru mají možnost snadno používat jiné druhy ochrany proti DoS, jako např. požadavek malé platby. To by mohlo učinit přeposílání balíčků či jiných alternativních transakcí praktické, i kdyby zlomyslné transakce nebo balíčky vedly k drobnému plýtvání zdroji.

  V Jagerově příspěvku nechybí odkaz na video, ve kterém tuto funkci předvádí. Jeho příspěvek obdržel v době psaní pouze několik reakcí, byť pozitivních.

Čekání na potvrzení 3: aukce blokového prostoru

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 zmínili, že transakce neplatí poplatky dle přenášené hodnoty, ale za použitý prostor v bloku. Také jsme vysvětlili, že těžaři vybírají transakce takový způsobem, aby poplatky činily co největší částku. Vyplývá z toho, že v nově nalezeném bloku jsou potvrzeny pouze transakce z vrcholu mempoolu. V tomto příspěvku popíšeme strategie optimalizace poplatků. Předpokládáme, že máme vyhovující zdroj odhadu výše jednotkového poplatku (příští týden si povíme více o odhadování jednotkového poplatku).

Během konstrukce transakcí jsou některé její součásti flexibilnější než jiné. Každá transakce musí mít hlavičku, výstupy (určené jednotlivými platbami) a výstup pro drobné. Odesílatel i příjemce by měli upřednostňovat takové typy výstupů, které jsou efektivní z hlediska využitého prostoru, aby snížili budoucí náklady na utracení svých výstupů. Konečnou podobu a váhu však dává transakci výběr vstupů. Jelikož transakce mezi sebou soutěží jednotkovým poplatkem (poplatek / váha), lehčí transakce vyžadují k dosažení stejného jednotkového poplatku nižší celkový poplatek.

Některé peněženky, například Bitcoin Core, se snaží zkombinovat vstupy takovým způsobem, aby se zcela vyhnuly nutnosti vytvářet výstup s drobnými. To vede nejen ke snížení váhy nyní, ale také ke snížení budoucích nákladů utracení tohoto výstupu. Bohužel takové kombinace vstupů jsou jen zřídka možné, pokud peněženka nemá k dispozici velké množství UTXO s různorodými částkami.

Moderní druhy výstupů jsou prostorově efektivnější než starší typy. Například utracení P2TR vstupu přispěje méně než dvěma pětinami váhy P2PKH vstupu (viz kalkulátor velikosti transakce). Multisig peněženky mohou těžit z nedávno dokončeného schématu MuSig2 a protokolu FROST, díky kterým mohou být multisig operace kódovány způsobem, který připomíná běžný vstup s jedním podpisem. Peněženky používající moderní druhy výstupů mohou obzvláště v době vysoké poptávky po blokovém prostoru dosáhnout vysokých úspor.

Chytré peněženky mění strategii výběru na základě jednotkového poplatku: při vyšších jednotkových poplatcích dosahují použitím méně vstupů a moderních druhů vstupů nejnižší možnou váhu pro danou množinu vstupů. Vybírat pokaždé nejlehčí množinu vstupů by sice minimalizovalo náklady na tuto aktuální transakci, ale také by štěpilo zásobu UTXO na malé fragmenty. To by si později mohlo vynutit transakce s příliš velkou množinou vstupů v době s vysokým jednotkovým poplatkem. Je tedy prozíravé, aby peněženky v dobách s nízkým jednotkovým poplatkem také vybíraly více těžších vstupů, aby dosáhly konsolidace prostředků do menšího množství moderních výstupů a tím se připravily na pozdější vysokou poptávku po blokovém prostoru.

Vysoce používané peněženky často slučují několik plateb do jediné transakce, aby dosáhly snížení váhy transakce na platbu. Vyhnou se tak platbě za hlavičku a výstup pro drobné za každou platbu; namísto toho všechny platby sdílí tento náklad pouze jednou. Sloučení několika málo plateb rychle snižuje náklady za platbu:

I když mnoho peněženek jednotkový poplatek nadsazuje, někdy transakce čeká na potvrzení déle, než se plánovalo. V takových případech může odesílatel nebo příjemce změnit transakci prioritu.

Uživatelé mají zpravidla k dispozici dva nástroje, které jim pomohou navýšit prioritu transakce: CPFP (child pays for parent, potomek platí za předka) a RBF (replace by fee, nahrazení poplatkem). V případě CPFP utrácí uživatel svůj výstup, aby tím vytvořil potomka této transakce, který bude mít vyšší jednotkový poplatek. V minulém příspěvku jsme si vysvětlili, že je v zájmu těžařů vybrat rodičovskou transakci do bloku, aby mohl být začleněn i její potomek s vysokým poplatkem. CPFP je dostupné každému, komu je platba v transakci směrována, čili buď příjemce nebo odesílatel (pokud vytvořil i výstup pro drobné).

V případě RBF připraví odesílatel transakci s vyšším jednotkovým poplatkem, která nahradí transakci původní. Nahrazující transakce musí použít alespoň jeden vstup shodný s původní transakcí; tento konflikt zaručí, že pouze jediná z těchto dvou transakcí bude začleněna do blockchainu. Obvykle tato nahrazující transakce obsahuje platby z původní transakce, ale odesílatel by též mohl prostředky přesměrovat jinam či zkombinovat platby z více transakcí do jedné. V minulém příspěvku jsme popsali, že uzly vyloučí původní transakci z mempoolu, neboť je pro ně výhodnější začlenit nahrazující transakci.

I když je poptávka i produkce blokového prostoru mimo naši kontrolu, mají peněženky k dispozici mnoho prostředků, kterými mohou dosáhnout efektivního využití blokového prostoru. Peněženky mohou ušetřit na poplatcích vytvářením lehčích transakcí eliminací výstupu pro drobné, utrácením nativních segwit výstupů a defragmentací svého UTXO setu v době nízkých poplatků. Peněženky, které podporují CPFP a RBF, mohou také začít s konzervativnějším jednotkovým poplatkem a bude-li potřeba, mohou transakci pomocí CPFP nebo RBF navýšit prioritu.

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

• ● Testování ořezávací logiky s bitcoind Lightlike poukazuje na debugovací volbu -fastprune, která pro testovací účely používá menší soubory bloků a nižší minimální ořezávací výšku.

• ● Jaká je hlavní motivace existence omezení počtu potomků? Sdaftuar vysvětluje, že jelikož těžba i algoritmy vyloučení z mempoolu (viz zpravodaj č. 252) mají kvadratický čas 0(n²) závislý na počtu předků nebo potomků, byly zavedeny tyto konzervativní limity.

• ● Jak prospívá bitcoinové síti, provozuji-li uzel s větším než výchozím mempoolem? Andrew Chow a Murch poznamenávají potenciální nevýhody mempoolu s větší kapacitou než je výchozí nastavení. Mezi ně patří zhoršení propagace znovu posílaných transakcí a propagace nahrazovaných transakcí bez signalizace.

• ● Jaký je nejvyšší možný počet vstupů a výstupů transakce? Murch poskytuje počty vstupů a výstupů po aktivaci taprootu: maximálně 3 223 (P2WPKH) výstupů nebo 1 738 (P2TR keypath) vstupů.

• ● Mohou být 2-ze-3 multisig prostředky obdrženy bez jednoho z xpubů? Murch vysvětluje, že multisig sestavy, které nepoužívají holý („bare”) multisig nebo které nebyly dříve použité ve stejném multisig výstupním skriptu, musí dát pro utracení k dispozici všechny veřejné klíče. Poznamenává, že „zálohy multisig peněženek musí zachovat jak soukromé klíče, tak i výstupní skripty“ a doporučuje pro skripty používat deskriptory.

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.

• ● Bitcoin Core 25.0 je vydáním další hlavní verze Bitcoin Core. Vydání přidává nové RPC volání scanblocks, zjednodušuje používání bitcoin-cli, přidává do volání finalizepsbt podporu miniscriptu, ve výchozím nastavení snižuje paměťové nároky s aktivovanou volbou blocksonly a zrychluje reskenování peněženky po aktivaci kompaktních filtrů bloků a další nové funkce, zlepšení výkonnosti a opravy chyb. Další podrobnosti lze najít v poznámkách k vydání.

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 #27469 zrychluje prvotní stahování bloků (IBD, „Initial Block Download”), pokud jsou používány peněženky. S touto změnou budou transakce peněženky v bloku skenovány jen, pokud byl blok vytěžen po vzniku peněženky.

• ● Bitcoin Core #27626 povoluje spojení, které náš uzel požádalo o poskytování přeposílání kompaktních bloků ve velkokapacitním režimu, vyžádat až tři transakce z posledního bloku, o kterém jsme toto spojení informovali. Náš uzel pošle odpověď, i když jsme jim kompaktní blok neposkytli. To umožní spojení, které obdrží kompaktní blok od jiného svého spojení, vyžádat od nás kteroukoliv chybějící transakci. To může být užitečné, pokud ono jiné spojení nereaguje. Naše spojení může díky tomu validovat blok rychleji, a tak jej může dříve použít v časově kritických funkcích, jako je těžba.

• ● Bitcoin Core #25796 přidává nové volání descriptorprocesspsbt, které může být použito k přidání informací do PSBT, které jim později usnadní podepsání nebo finalizování. Deskriptor předaný tomuto volání se použije k získání informací z mempoolu a množiny UTXO (a také kompletní potvrzené transakce, pokud má uzel aktivovánu volby txindex). Obdržené informace budou posléze použity k doplnění PSBT.

• ● Eclair #2668 zabraňuje Eclairu pokoušet se zaplatit za nárokování HTLC větší poplatky, než kolik činí hodnota tohoto HTLC.

• ● Eclair #2666 umožňuje vzdálenému spojení přijímajícímu HTLC jej akceptovat, i kdyby potřebný poplatek za transakci snížil zůstatek na straně spojení pod minimální rezervu kanálu. Rezerva kanálu existuje, aby spojení ztratilo alespoň malé množství peněz v případě pokusu o zavření kanálu se starým stavem. Avšak akceptuje-li spojení HTLC, které mu v případě úspěšného vyřešení platí, budou mít více než je rezerva. A v případě neúspěchu budou mít stejně jako před HTLC.

  Jedná se o řešení problému uvízlých prostředků, který se objevuje, když by strana zodpovědná za placení poplatku musela platit větší hodnotu, než je její aktuální zůstatek, i když je tato strana příjemcem prostředků. Předchozí diskuzi o tomto problému lze nalézt ve zpravodaji č. 85.

• ● BTCPay Server 97e7e počíná nastavovat BIP78 parametr minfeerate (minimální jednotkový poplatek) pro payjoin platby. Viz též hlášení o chybě, které vedlo k této změně.

• ● BIPs #1446 činí drobou změnu a několik přídavků do BIP340, specifikace Schnorrových podpisů pro bitcoinové protokoly. Změna povoluje, aby podepisovaná zpráva měla libovolnou délku (předchozí verze vyžadovaly 32 bytů). Viz související změna v knihovně Libsecp256k1 popsaná ve zpravodaji č. 157. Změna nemá dopad na způsob používání BIP340 v aplikacích, neboť podpisy používané v taprootu i tapscriptu (BIP 341, resp. 342) používají 32bytové zprávy.

  Přidán byl popis efektivního použití zpráv o libovolné délce a doporučení o používání hashovaných tagovaných prefixů. Též poskytuje doporučení pro zvýšení bezpečnosti během používání stejného klíče v různých doménách (např. podepisování transakcí vs. podepisování prostého textu).