Zpravodaj tento týden ohlašuje rychlejší metodu exfiltrace seedu nazvanou Dark Skippy, shrnuje diskuzi o útocích zadržováním bloků a navrhovaných řešeních, sdílí statistiky o rekonstruování kompaktních bloků, popisuje útok cyklickým nahrazováním proti transakcím s pay-to-anchor výstupy, zmiňuje nový BIP specifikující prahové podepisování s FROST a tlumočí oznámení o vylepšeném Eftrace, které umožňuje optimisticky ověřit důkazy s nulovou znalostí pomocí dvou navrhovaných soft forků.

Novinky

  • ● Rychlejší exfiltrace seedu: Lloyd Fournier, Nick Farrow a Robin Linus zveřejnili Dark Skippy, vylepšený způsob exfiltrace klíčů z bitcoinových podpisových zařízení. Před zveřejněním jej zodpovědně nahlásili přibližně patnácti různým výrobcům hardwarových podpisových zařízení. Exfiltrace klíčů nastává, když kód podepisování transakcí záměrně vytváří podpisy způsobem, který umožňuje únik informací o tajných datech, jako jsou soukromé klíče či seed BIP32 hierarchické peněženky. Po získání uživatelova seedu může útočník ukrást jeho prostředky v libovolné výši a v libovolný čas (včetně prostředků utracených v transakci, která exfiltraci provádí, pokud útočník jedná rychle).

    Autoři zmiňují, že nejlepší předchozí známý útok exfiltrací klíčů vyžadoval k exfiltraci jednoho BIP32 seedu desítky podpisů. S Dark Slippy jim postačují dva podpisy, které mohou patřit jediné transakci s dvěma vstupy. Uživatelovy prostředky mohou tedy být v ohrožení od okamžiku prvního pokusu o poslání peněz.

    Exfiltrace klíčů může být vykonána kteroukoliv logikou, která vytváří podpisy, včetně softwarových peněženek, avšak obecně se očekává, že softwarová peněženka se zákeřným kódem jednoduše útočníkovi pošle seed přes internet. Exfiltrace se převážně považuje za hrozbu hardwarovým podpisovým zařízením, které nemají přístup na internet. Zařízení s podvrácenou logikou, ať již ve firmwaru či přímo v hardwaru, je nyní schopné rychle exfiltrovat seed, aniž by kdy bylo připojeno k počítači (např. jsou-li všechna data přenášena pomocí NFC, SD karet či QR kódů).

    Způsoby podepisování v bitcoinu, které jsou odolné vůči exfiltraci, již byly diskutovány (včetně zpravodajů Optechu sahajících až ke zpravodaji č. 87, angl.) a pokud víme, jsou v současnosti implementovány ve dvou hardwarových podpisových zařízeních (viz zpravodaj č. 136, angl.). Tato používaná metoda vyžaduje jedno kolo komunikace navíc oproti standardnímu podepisování s jedním podpisem. To však nemusí být považováno za nevýhodu, pokud si uživatelé zvyknou na jiné druhy podepisování, jako jsou bezskriptové vícenásobné podpisy, které též vyžadují více komunikace. Jsou známé i jiné způsoby odolného podepisování, které nabízejí odlišné kompromisy, avšak pokud víme, žádný z nich nebyl v bitcoinových podpisových zařízeních implementován.

    Optech doporučuje každému, kdo používá hardwarová podpisová zařízení k ochraně významného množství peněz, aby se před podvodným hardwarem či firmwarem chránil, například používáním podpisů odolných vůči exfiltraci nebo používáním několika nezávislých zařízení (např. se skriptovými či bezskriptovými vícenásobnými podpisy nebo s prahovým podepisováním).

  • ● Útoky zadržováním bloků a možná řešení: Anthony Towns zaslal do emailové skupiny Bitcoin-Dev příspěvek o útoku zadržováním bloků, s ním souvisejícím útoku nevalidních share a o možných řešeních obou útoků, mimo jiné znemožněním výběrů transakcí klienty ve Stratum v2 nebo pomocí zapomnětlivých share.

    Těžaři v poolu jsou placeni za posílání jednotek práce, kterým se říká share, z nichž každý je kandidátem na blok obsahující určité množství proof of work (PoW). Očekává se, že určitý známý podíl těchto share bude obsahovat dostatečný PoW na začlenění do blockchainu. Například mají-li share PoW tisícinu PoW validního bloku, pool očekává, že bude za každý validní blok platit v průměru za tisíc share. Klasický útok zadržováním bloků nastává, když těžař v poolu neodešle tento tisící share s validním blokem, ale odešle zbývajících 999 share, které validními bloky nejsou. To umožňuje těžařovi obdržet peníze za 99,9 % své práce, ale nedovolí poolu od tohoto těžaře získat jakýkoliv příjem.

    Stratum v2 umožňuje, aby pool povolil těžařům začleňovat do svých bloků odlišnou množinu transakcí, než kterou navrhuje pool. Těžař v poolu se může dokonce pokoušet těžit transakce, které pool nezná. Tím může být pro pool ověřování share nákladné: každý share může obsahovat i několik megabajtů transakcí, které pool nikdy předtím neviděl a které mohou být vytvořené pro zpomalení validace. Infrastruktura poolu tak může být snadno přetížena, což mu znemožní přijímat share od čestných uživatelů.

    Pooly se mohou tomuto problému vyhnout tím, že budou validovat pouze PoW každého share namísto validace transakcí. To by však umožnilo těžařům v poolu obdržet platby za odeslání nevalidních share ve 100 % případů, což je ještě horší než zhruba 99,9 % případů, ve kterých mohou obdržet platby během klasického útoku zadržováním bloků.

    Tímto mají pooly motivaci buď výběr transakcí klientům zakázat nebo vyžadovat, aby se těžaři v poolu spolehlivě identifikovali (například jménem z dokumentu vydaného vládou), aby mohli být nečestní hráči vylučováni.

    Jedním z řešení navržených Townsem je, aby pooly nabízely k výběru více šablon bloků. Podobný systém dnes používá Ocean Pool. Takové share mohou být validovány rychle a s využitím minimálního množství přenosového pásma. To zabrání 100% výplatám za posílání nevalidních bloků, ale nepomůže útokům zadržováním bloků, které dosahují kolem 99,9% profitu.

    Pro zabránění útoku zadržováním bloků navrhuje Towns upravený nápad původně navržený Menim Rosenfeldem v roce 2011, dle kterého by koncepčně jednoduchý hard fork mohl zabránit těžařovi v poolu, aby se dozvěděl, zda množství vykonaného PoW konkrétního share stačilo na validní blok. Takový share se nazývá zapomnětlivý share (oblivious share). Útočník, který není schopen rozlišit mezi PoW validního bloku a běžného share může pool obrat o příjem stejnou měrou jako sám sebe. Tento přístup má několik nevýhod:

    • ● Hard fork s dopadem na SPV: všechny návrhy hard forků vyžadují upgrade po všech plných uzlech. Avšak mnoho z nich (například návrhy na navýšení velikosti bloku jako BIP103) nevyžadují upgrade lehkých klientů, které používají zjednodušené ověřování plateb (simplified payment validation, SPV). Tento návrh mění interpretaci polí v hlavičce bloku a vyžadoval by tak upgrade od všech lehkých klientů. Towns nabízí alternativu, která by po lehkých klientech nevyžadovala upgrade, ale výrazně by snížila jejich bezpečnost.

    • ● Vyžaduje od těžařů v poolu používat tajnou šablonu: nejen by byla tato šablona vyžadována, aby mohlo být zabráněno útoku 100% nevalidními share, ale pool by navíc musel tuto šablonu před těžaři držet v tajnosti až do doby, kdy pool obdrží všechny share používající tuto šablonu. Pool by toho mohl využít jako lsti k donucení těžařů věnovat PoW k těžení transakcí, ke kterým by měli výhrady. Expirované šablony by ale mohly být publikovány pro účely auditu. Většina moderních poolů generuje nové šablony každých několik sekund, auditování by tak mohlo být prováděno téměř v reálném čase. Záškodnický pool by tak mohl klamat těžaře jen více než pár sekund.

    • ● Vyžaduje zasílání share: jednou z výhod Stratum v2 (v určitých režimech provozu) je, že čestní těžaři, kteří pro pool naleznou blok, jej mohou okamžitě zveřejnit v P2P síti. Tím může propagace bloku začít ještě před tím, než se share dostane k serveru poolu. Se zapomnětlivými share by share musely být nejdříve přijaty poolem, přeměněny do kompletního bloku a teprve tehdy by mohl být blok zveřejněn.

    Towns uzavírá popisem motivace bránění útoku: postihuje malé pooly více než velké a útoky na pooly s anonymními těžaři nestojí téměř nic, zatímco pooly vyžadující identifikaci těžařů mohou útočníky zabanovat. Oprava zadržování bloků by mohla rozvinout anonymnější a více decentralizovanou těžbu.

  • ● Statistika rekonstruování kompaktních bloků: vývojář 0xB10C zaslal do fóra Delving Bitcoin příspěvek popisující spolehlivost rekonstruování kompaktních bloků. Mnoho přeposílajících plných uzlů používá kompaktní bloky dle BIP152 již od doby, kdy byly v roce 2016 do Bitcoin Core 0.13.0 přidány. Pokud dva spojené uzly již oba znají některé nepotvrzené transakce, mohou po potvrzení v novém bloku na tyto transakce odkázat krátkou referencí namísto opakovaného přeposlání celé transakce. To výrazně snižuje požadované přenosové pásmo a latenci, díky čemuž se nové bloky propagují rychleji.

    Rychlejší propagace nových bloků snižuje množství nahodilých štěpení blockchainu. Méně štěpení redukuje plýtvání proof of work (PoW) a snižuje počet výskytů honby za bloky (block races) nahrávajících větším těžebním poolům. Tím přispívá k většímu zabezpečení a větší decentralizaci bitcoinu.

    Avšak někdy bloky obsahují transakce, které uzel předtím neviděl. V takovém případě musí obvykle uzel přijímající kompaktní blok požádat posílající uzel o kompletní transakce a poté počkat na odpověď. To propagaci nových bloků zpomaluje. Dokud uzel neobdrží všechny transakce bloku, nemůže jej validovat a rozeslat dále. Počet nahodilých štěpení blockchainu se tím zvyšuje, zabezpečení PoW se snižuje a roste tlak na centralizaci.

    Z tohoto důvodu je užitečné sledovat, jak často poskytují kompaktní bloky všechny informace potřebné k okamžité validaci nového bloku bez nutnosti potřeby požádat o dodatečné transakce (úspěšná rekonstrukce). Gregory Maxwell nedávno reportoval o poklesu počtu úspěšných rekonstrukcí u uzlů provozujících Bitcoin Core ve výchozím nastavení, obzvláště v porovnání s uzly aktivujícími volbu mempoolfullrbf.

    Vývojář 0xB10C tento týden poskytl přehled počtu úspěšných rekonstrukcí, které zaznamenaly jeho uzly s různými nastaveními. Některá data sahala až šest měsíců do minulosti. Čerstvější údaje o dopadu aktivovaného mempoolfullrbf zabírají pouze poslední týden, avšak shodují se s Maxwellovým pozorováním. To přispělo k úvahám o přijetí pull requestu, který by v nadcházejících verzích Bitcoin Core volbu mempoolfullrbf aktivoval ve výchozím nastavení.

  • ● Cyklické nahrazování útočící na pay-to-anchor: Peter Todd zaslal do emailové skupiny Bitcoin-Dev příspěvek o výstupu typu pay-to-anchor (P2A), který je součástí návrhu na dočasné anchory (ephemeral anchors). P2A je výstupem transakce, který může utratit kdokoliv. To může být užitečné u navyšování poplatků pomocí CPFP, obzvláště u protokolů s více účastníky jako LN. Avšak CPFP navyšování je v současnosti v LN náchylné na útok cyklickým nahrazováním (replacement cycling attack), při kterém záškodnická protistrana provádí dvoukrokový proces. V prvním kroku protistrana nahradí transakci čestného uživatele svou verzí. Nahrazenou transakci potom nahradí transakcí, která se nevztahuje ani na jednu z verzí. V případě, kdy má LN kanál nevyřízená HTLC, může úspěšně provedený útoky umožnit protistraně ukrást prostředky čestné strany.

    Pokud je použit současný druh kanálů s anchor výstupy, může útok provést pouze protistrana. Avšak Todd poznamenává, že jelikož P2A výstup může utratit kdokoliv, může také kdokoliv provést útok cyklickým nahrazením proti transakcím, které P2A používají. I tehdy však může na útoku vydělat pouze protistrana, neexistuje tedy pro třetí strany přímá motivace k útoku na P2A výstupy. Útok může být dokonce zdarma v případě, kdy útočník plánuje zveřejnit svou vlastní transakci s jednotkovým poplatkem vyšším, než jaký má P2A čestného uživatele, a kdy se útočníkovi podaří úspěšně dokončit cyklus nahrazení, aniž by byl jejich mezistav potvrzen těžaři. Všechna současná opatření v LN proti útokům cyklickým nahrazením (viz zpravodaj č. 274) budou srovnatelně účinná i v případě P2A.

  • ● Optimistické ověřování důkazů s nulovou znalostí pomocí CAT, MATT a Elftrace: Johan T. Halseth zaslal do fóra Delving Bitcoin příspěvek s oznámením, že jeho nástroj Elftrace má nově schopnost ověřovat důkazy s nulovou znalostí (zero-knowledge proofs, ZKP). Pro používání onchain bude potřeba aktivovat soft forky OP_CAT a MATT.

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řidej PayToAnchor(P2A), OP_1 <0x4e73>, jako standardní výstupní skript pro platby je PR od instagibbs, které přináší nový typ výstupního skriptu TxoutType::ANCHOR. Anchor výstupy mají výstupní skript OP_1 <0x4e73> (což odpovídá adrese bc1pfeessrawgf). Po označení těchto výstupů za standardní budou moci být vytvářené a přeposílané platby z anchor výstupů.

  • Jakým TxoutType byl před tímto PR klasifikován scriptPubKey OP_1 <0x4e73>?

    Jelikož sestává z jednobajtového push kódu (OP_1) a dvoubajtových dat (0x4e73), jedná se o validní v1 witness výstup. Protože nemá 32 bajtů, nelze jej označit za WITNESS_V1_TAPROOT, proto je typu TxoutType::WITNESS_UNKNOWN. ➚

  • Na základě odpovědi na předchozí otázku, bylo by standardní vytvořit výstup tohoto druhu? Jak by to bylo s jeho utracením? (Tip: jak s tímto typem nakládají IsStandard a AreInputsStandard?)

    Protože IsStandard (používaný pro kontrolu výstupů) považuje za nestandardní pouze TxoutType::NONSTANDARD, vytváření by bylo standardní. Protože AreInputsStandard považuje transakci utrácející z TxoutType::WITNESS_UNKNOWN za nestandardní, nebylo by standardní tento výstup utrácet. ➚

  • Jaké výstupy mohly být před tímto PR ve výchozím nastavení vytvořené ve standardní transakci? Jsou stejné jako typy skriptů, které mohou být ve standardní transakci utracené?

    Vytvořené mohou být všechny TxoutType kromě TxoutType::NONSTANDARD. Utracené mohou být všechny TxoutType kromě TxoutType::NONSTANDARD a TxoutType::WITNESS_UNKNOWN (ačkoliv utratit TxoutType::NULL_DATA je nemožné). ➚

  • Definujte anchor výstup, aniž byste zmínili transakce v Lightning Network (pojměte to obecně).

    Anchor výstup je dodatečný výstup vytvořený v předem podepsané transakci, který v době zveřejnění umožňuje přidat poplatky pomocí CPFP. Pro více informací viz téma anchor výstupů. ➚

  • Proč záleží na velikosti výstupního skriptu anchor výstupu?

    Kvůli velkému výstupnímu skriptu by bylo nákladnější transakci přeposílat a prioritizovat. ➚

  • Kolik virtuálních bajtů je potřeba pro vytvoření a utracení P2A výstupu?

    Vytvoření P2A výstupu vyžaduje 13 vbyte. Utracení 41 vbyte. ➚

  • Třetí commit přidává do IsWitnessStandard klauzuli if (prevScript.IsPayToAnchor()) return false. Co to znamená a proč je to potřeba?

    Zajišťuje, že anchor výstup může být utracen pouze bez witnessů. To zabraňuje útočníkovi vzít čestnou transakci, přidat data witnessu a dále ji distribuovat s vyšším absolutním, avšak nižším jednotkovým poplatkem. To by nutilo čestného uživatele platit víc a víc na její nahrazení. ➚

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.

  • ● Libsecp256k1 0.5.1 je menším vydáním této knihovny bitcoinových kryptografických funkcí. Mění výchozí velikost předem vypočítané tabulky pro podepisování na stejnou velikost jako v Bitcoin Core a přidává příklad pro výměnu klíčů založenou na ElligatorSwift (protokol používaný v šifrovaném P2P přenosu verze 2).

  • ● BDK 1.0.0-beta.1 je kandidátem na vydání této knihovny pro budování peněženek a jiných bitcoinových aplikací. Původní rustový crate bdk byl přejmenován na bdk_wallet a moduly nižší úrovně byly extrahovány do vlastních crate: bdk_chain, bdk_electrum, bdk_esplora a bdk_bitcoind_rpc. bdk_wallet je „první verzí se stabilním 1.0.0 API.”

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.

  • ● Bitcoin Core #30493 přináší aktivní full RBF jako výchozí nastavení. I nadále umožní provozovatelům uzlů jej vypnout. Full RBF umožňuje nahrazení jakékoliv nepotvrzené transakce i bez BIP125 signalizace. Volbu bylo možné aktivovat od července 2022 (viz zpravodaj č. 208, angl.), ale byla ve výchozím nastavení neaktivní. Zpravodaj č. 263 popisuje diskuzi o aktivaci ve výchozím nastavení.

  • ● Bitcoin Core #30285 přidává do cluster mempoolu dva klíčové algoritmy linearizace clusterů: MergeLinearizations pro kombinaci dvou existujících linearizací a PostLinearize pro modifikaci linearizace přidáním dodatečného zpracování. PR staví na práci představené minulý týden ve zpravodaji č. 314.

  • ● Bitcoin Core #30352 přináší nový typ výstupu Pay-To-Anchor (P2A) a označuje jeho utracení za standardní. Tento typ výstupu může být utracen kýmkoliv. Umožňuje kompaktní anchory pro navyšování poplatků dle CPFP, které jsou odolné vůči poddajnosti txid (viz zpravodaj č. 277). V kombinaci s TRUC transakcemi přináší pokrok v implementaci dočasných anchorů, které v LN nahradí anchor výstupy založené na CPFP výjimce z pravidel přeposílání.

  • ● Bitcoin Core #29775 přidává konfigurační volbu testnet4, která nastaví síť na testnet4 dle specifikace v BIP94. Testnet4 obsahuje opravy několika problémů s předchozím testnet3 (viz zpravodaj č. 306). Stávající konfigurační volba Bitcoin Core testnet (pro testnet3) zůstává dostupná, ale očekává se, že bude v budoucích vydáních odstraněna.

  • ● Core Lightning #7476 implementuje do nabídek nedávné změny BOLT12 specifikace. Nově bude v nabídkách a žádostech o fakturu odmítat zaslepené cesty nulové délky. Dále umožní vynechat v nabídkách pole offer_issuer_id, pokud je poskytnuta zaslepená cesta. V takových případech bude finální zaslepený klíč shodný s klíčem, který podepíše fakturu. Očekává se, že autor nabídky má k tomuto klíči přístup.

  • ● Eclair #2884 implementuje BLIP4 pro HTLC atestace (HTLC endorsements), čímž se stává jejich první LN implementací. HTLC atestace slibují částečně bránit útokům zahlcením kanálu. PR aktivuje volitelné přeposílání příchozích atestací. Přeposílající uzly samy určí, zda atestaci během přeposílání HTLC připojit. Pokud by v síti došlo k širokému nasazení HTLC atestací, mohla by taková HTLC obdržet preferenční zacházení, například přístup k vzácným síťovým zdrojům. Implementace staví na předchozí práci popsané ve zpravodaji č. 257.

  • ● LND #8952 refaktoruje komponentu channel v lnwallet. Nově bude používat typovaný List. Jedná se o součást série PR implementující dynamické commitmenty, jeden druh upgradu commitmentů kanálu.

  • ● LND #8735 přidává možnost generovat faktury se zaslepenými cestami pomocí příznaku -blind příkazu addinvoice. Dále též umožňuje za takové faktury zaplatit. Jedná se pouze o implementaci pro BOLT11, neboť BOLT12 není ještě v LND implementován. LND #8764 k předchozímu PR přidává možnost použít během platby faktury více zaslepených cest pro vykonání plateb s více cestami (MPP).

  • ● BIPs #1601 začleňuje BIP94, který přidává specifikaci testnet4, nové verze testnetu. Obsahuje vylepšení pravidel konsenzu, která by měla zabránit snadným útokům na síť. Všechny předchozí mainnetové soft forky jsou v testnet4 aktivní od prvního bloku a ve výchozím nastavení je použit port 48333. Zpravodaje č. 306 a č. 311 poskytují více informací o problémech testnet3 a změnách v testnet4.