Zpravodaj tento týden oznamuje odhalení útoku plýtvajícího přenosovým pásmem Bitcoin Core a jeho spojení, popisuje několik vylepšení myšlenky na sponzorování poplatků transakcí a shrnuje diskuzi o používání živých dat mempoolu k vylepšení odhadu poplatků v Bitcoin Core. Též nechybí naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními o nových vydáních a významnými změnami populárních bitcoinových páteřních projektů.

Novinky

  • ● Odhalení free relay útoku: Peter Todd zaslal do emailové skupiny Bitcoin-Dev příspěvek s popisem útoku plýtvajícího přenosovým pásmem, který předtím zodpovědně nahlásil vývojářům Bitcoin Core. Ve zkratce: Mallory pošle jednu verzi transakce Alici a jinou verzi Bobovi. Transakce jsou navrženy tak, aby Bob neakceptoval Alicinu verzi jako RBF nahrazení a naopak. Mallory nato odešle Alici nahrazení, které ona akceptuje, ale Bob ne. Alice přepošle nahrazení Bobovi, které Bob odmítne, což vyústí v plýtvání přenosového pásma (tomuto plýtvání se říká free relay, „přeposílání zdarma”). Mallory může postup opakovat několikrát, dokud se jeho transakce nepotvrdí. V každém kole cyklu Alice nahrazení akceptuje, pošle ji Bobovi (použití přenosového pásma) a ten ji odmítne. Následky útoku mohou být znásobeny, pokud by Mallory paralelně posílal několik podobně zkonstruovaných transakcí a Alice měla několik spojení tato nahrazení odmítajících.

    Útok je omezen náklady na poplatky, které Mallory zaplatí v případě potvrzení některé z transakcí. Peter Todd však poznamenává že náklady mohou být v podstatě nulové, pokud by Mallory stejně transakci plánoval odeslat. Maximální množství přenosového pásma, kterým lze plýtvat, je omezeno stávajícími limity přeposílání transakcí v Bitcoin Core, ačkoliv je možné, že mnohonásobné paralelní provádění tohoto útoku by zpozdilo propagaci legitimních nepotvrzených transakcí.

    Peter Todd též zmiňuje jiný známý druh plýtvání přenosového pásma uzlu, při kterém uživatel zveřejní sadu velkých transakcí a poté ve spolupráci s těžařem vytvoří blok, který obsahuje relativně malou transakci kolidující se všemi přeposlanými transakcemi. Například transakce o velikost 29 000 vbyte by mohla z mempoolu každého přeposílajícího uzlu odstranit 200 megabajtů transakcí. Říká, že existence útoků umožňujících plýtvání přenosového pásma znamená, že povolit určité množství přeposílání zdarma by bylo rozumné, jak umožňuje například navrhované nahrazování jednotkovým poplatkem (viz zpravodaj č. 288).

  • ● Vylepšení sponzorování transakčních poplatků: Martin Habovštiak zaslal do emailové skupiny Bitcoin-Dev příspěvek s nápadem umožnit transakci zvýšit prioritu jiné, nesouvisející transakce. Fabian Jahr poznamenal, že v jádru je tato myšlenka podobná sponzorování transakčních poplatků, které v roce 2020 navrhl Jeremy Rubin (viz zpravodaj č. 116, angl.). V Rubinově původním návrhu sponzorující transakce zavazovala posilované transakci pomocí výstupního skriptu nulové hodnoty o velikosti kolem 42 vbyte za jedno sponzorství a kolem 32 vbyte za každé dodatečné sponzorství. V Haboštiakově verzi zavazuje sponzorující transakce posilované transakci pomocí taprootové přílohy (annex), která používá 8 vbyte za jedno sponzorství a 8 vbyte za každé další.

    Záhy po zveřejnění Habovštiakovy myšlenky zaslal David Harding do fóra Delving Bitcoin příspěvek s popisem způsobu navýšení efektivity, který s Rubinem v lednu vyvinul. Sponzorující transakce zavazuje posilované transakci pomocí signature commitment zprávy, která nikdy nebude publikována onchain, nezabírá tedy žádný blokový prostor. Sponzorující transakce se však musí objevit v blocích a zprávách přeposílání balíčků okamžitě po posilované transakci. To umožní ověřujícím plným uzlům během ověřování sponzorující transakce odvodit txid posilované transakce.

    V případech, kdy by blok obsahoval více sponzorujících transakcí zavazujících stejné posilované transakci, by nebylo možné jednoduše umístit sérii posilovaných transakcí přímo před jejich sponzory, proto není možné mít kompletně odvoditelné závazky. Harding popisuje jednoduchou alternativu, která zabírá pouze 0,5 vbyte za posilovanou transakci. Anthony Towns myšlenku dále vylepšuje: v jeho verzi by to nikdy nebylo více než 0,5 vbyte za posílení, ve většině případů by používala prostoru méně.

    Habovštiak i Harding poukazují na možnost outsourcingu: každý, kdo plánuje tak jako tak zveřejnit nějakou transakci (nebo kdo má nepotvrzenou transakci a je ochoten ji nahradit poplatkem), může navýšit její jednotkový poplatek a posílit jinou transakci. Dodatečné náklady by byly nízké, pouze 0,5 vbyte či méně za každé posílení. Pro porovnání: 0,5 vbyte je kolem 0,3 % transakce s jedním vstupem a dvěma P2TR výstupy. Bohužel, jak oba varují, neexistuje pohodlný způsob, kterým za posílení transakce třetí straně zaplatit bez požadavku na důvěru. Avšak jak Habovštiak dodává, kdokoliv platící přes LN obdrží doklad platby, mohl by tedy prokázat podvod.

    Towns dále poznamenává, že sponzorování transakcí se zdá být kompatibilní s návrhem cluster mempoolu a že nejefektivnější verze sponzorování by představovaly drobné potíže při cachování ověřování transakcí. Na závěr ukazuje tabulku srovnávající relativní blokový prostor spotřebovávaný současnými i navrhovanými technikami navyšování poplatků. Lepší než sponzorování s 0,5 vbyte nebo méně za jedno posílení je pouze nejlepší scénář s RBF (0 vbyte) a placení těžařům stranou. Jelikož sponzorování poplatků umožňuje dynamické navyšování a je téměř tak efektivní jako placení stranou, může pomoci vyřešit velký problém protokolů, které závisí na exogenních poplatcích.

    V probíhající diskuzi zveřejnil krátce před publikováním zpravodaje Suhas Daftuar obavy, že sponzorování by mohlo přinést problémy, které cluster mempool snadno řešit neumí a které by mohly dále způsobit potíže uživatelům, které sponzorování nepotřebují. Naznačil, že pokud by bylo sponzorování poplatků do bitcoinu přidáno, mělo by se týkat pouze transakcí, které jej povolí.

  • ● Odhad poplatků založený na mempoolu: Abubakar Sadiq Ismail zaslal do fóra Delving Bitcoin příspěvek s popisem vylepšení odhadu jednotkových poplatků v Bitcoin Core pomocí dat z lokálního mempoolu. V současnosti Bitcoin Core odhaduje poplatky zaznamenáním výšky bloku, kdykoliv se objeví nepotvrzená transakce, výšky bloky, když se transakce potvrdí, a jejího jednotkového poplatku. Jsou-li všechny tyto informace známy, je rozdíl mezi výškou během přijetí a výškou během potvrzení použit k aktualizaci exponenciálně váženého klouzavého průměru v různých přihrádkách jednotkových poplatků. Například transakce, která dosáhne potvrzení za 100 bloků s jednotkovým poplatkem 1,1 sat/vbyte, bude zařazena do průměru v přihrádce 1 sat/vbyte.

    Výhodou tohoto přístupu je jeho odolnost vůči manipulaci: všechny transakce musí být přeposlány (jsou tedy dostupné všem těžařům) a potvrzeny (neporušují pravidla konsenzu). Nevýhodou je, že k aktualizaci dochází pouze jednou za blok a může zaostávat za jinými metodami odhadu, které používají aktuální informace z mempoolu.

    Ismail se účastnil předešlé diskuze o začlenění dat z mempoolu do odhadu poplatku, předběžně napsal nějaký kód a provedl analýzu porovnávající současný algoritmus s novým (bez začlenění bezpečnostních kontrol). Jedna odpověď ve vlákně navíc odkázala na předešlé bádání Kalleho Alma a vedla k diskuzi o tom, zda by informace z mempoolu měly být použity pro zvyšování i snižování odhadů poplatků nebo pouze pro snižování. Výhodou použití pro obě varianty je, že díky tomu bude odhad poplatku užitečnější. Výhodou pouze snižování (a zvyšování pomocí stávajících odhadů) je, že by bylo odolnější vůči manipulaci cyklů s pozitivní odezvou.

    V době psaní zpravodaje diskuze stále probíhala.

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

  • ● Jaká rizika přináší provozování předsegwitového uzlu (0.12.1)? Michael Folkson, Vojtěch Strnad a Murch vyjmenovávají nevýhody provozování Bitcoin Core 0.12.1 včetně zvýšeného rizika akceptování nevalidní transakce či bloku, zvýšené zranitelnosti vůči útokům dvojího utracení, zvýšené závislosti na validaci prováděné ostatními účastníky sítě, výrazně pomalejší validace bloků, chybějících vylepšení výkonnosti, nemožnosti používat přeposílání kompaktních bloků, nemožnosti přeposílat kolem 95 % současných nepotvrzených transakcí a zranitelností způsobených (dnes již opravenými) bezpečnostními chybami. Uživatelé peněženky v 0.12.1 by také postrádali novinky kolem miniscriptu, deskriptorových peněženek a úspory na poplatcích a další vylepšení skriptovacích možností, které přinesly segwit, taproot a Schnorrovy podpisy. Mezi dopady na bitcoinovou síť by v případě širšího nasazení Bitcoin Core 0.12.1 patřily vyšší pravděpodobnost přijetí nevalidních bloků a s ním spojeného rizika reorganizací, tlak na centralizaci těžby a snížené odměny těžařům provozujícím tuto verzi.

  • ● Kdy je OP_RETURN levnější než OP_FALSE OP_IF? Vojtěch Strnad ukazuje, jaké náklady přináší šíření dat v OP_RETURN a v OP_FALSE OP_IF. Na závěr vysvětluje, že „OP_RETURN je levnější pro data menší než 143 bajtů.”

  • ● Proč BIP-340 používá secp256k1? Pieter Wuille vysvětluje důvody zvolení secp256k1 na úkor Ed25519 pro Schnorrovy podpisy dle BIP340. Přidává další důvody: „znovupoužitelnost stávající infrastruktury odvozování klíčů” a „zachování bezpečnostních předpokladů.”

  • ● Jaká kritéria používá Bitcoin Core pro tvorbu šablon bloků? Murch vysvětluje stávající algoritmus Bitcoin Core pro výběr transakcí do kandidáta na blok založený na jednotkových poplatcích předků. Dále zmiňuje probíhající práce na cluster mempoolu přinášející rozličná vylepšení.

  • ● Jak funguje pole initialblockdownload v RPC volání getblockchaininfo? Pieter Wuille vyjmenovává dvě podmínky, které musí být splněny, aby mělo pole initialblockdownload po spuštění uzlu hodnotu false:

    1. „Současný aktivní řetězec má alespoň tolik kumulativního PoW jako pevně zakódovaná konstanta”
    2. „Časové razítko současného aktivního vrcholu řetězce není více než 24 hodin v minulosti”

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 kódu a dokumentace

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, Bitcoin Inquisition a repozitáři BINANA.

Poznámka: commity do Bitcoin Core uvedené níže se vztahují na jeho vývojovou, master větev. Nebudou tedy pravděpodobně vydány před uplynutím zhruba šesti měsíců po vydání nadcházející verze 27.

  • ● Bitcoin Core #28950 přidává do RPC volání submitpackage parametry maxfeerate a maxburnamount, které vyvolají chybu, pokud by měl poskytnutý balíček agregovaný jednotkový poplatek nad stanoveným maximem nebo pokud by posílal více než stanovenou hodnotu známému tvaru neutratitelného výstupu.

  • ● LND #8418 přidává pravidelné načítání hodnot BIP133 feefilter od připojeného bitcoinového klienta. Zpráva feefilter umožňuje uzlu informovat spojení o nejnižších jednotkových poplatcích, které akceptuje pro přeposílání transakcí. LND použije tuto informaci, aby zabránilo odesílání transakcí s příliš nízkým poplatkem. Použity jsou pouze hodnoty pro odchozí spojení, protože to jsou spojení vybraná a iniciovaná uzlem, je tedy menší pravděpodobnost, že jsou pod kontrolou útočníka.

  • ● LDK #2756 přidává do svých zpráv podporu pro pakety trampolínového routování. Nepřidává tím plnou podporu pro používání trampolínového routování nebo poskytování jeho služeb, usnadňuje však přidání podpory uživatelům LDK.

  • ● LDK #2935 přidává podporu pro posílání keysend plateb na zaslepené trasy. Keysend platby jsou bezpodmínečné platby poslané bez faktury. Zaslepené trasy skrývají poslední skoky platební cesty. Zaslepené trasy jsou obvykle zakódovány ve faktuře, nejsou tedy obvykle kombinovány s keysend platbami, avšak mohou být užitečné v případech, kdy poskytovatel lightningových služeb (LSP) nebo nějaký jiný uzel chtějí poskytnout obecnou fakturu pro konkrétního adresáta bez odhalení identifikátoru adresátova uzlu.

  • ● LDK #2419 přidává automat (state machine) pro interaktivní konstrukci transakcí, která je nutná pro kanály s dvojí financováním a pro splicing.

  • ● Rust Bitcoin #2549 upravuje API pro práci s relativními časovými zámky.

  • ● BTCPay Server #5852 přidává podporu pro skenování animovaných QR kódů BBQr (viz zpravodaj č. 281) pro PSBT.