Zpravodaj tento týden oznamuje odhalení zranitelnosti umožňující cenzurování transakcí a shrnuje diskuzi o návrhu soft forku na pročištění konsenzu. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Zranitelnost umožňující cenzurování transakcí: Antoine Riard zaslal do emailové skupiny Bitcoin-Dev příspěvek s popisem metody na zabránění uzlu v odeslání transakce patřící připojené peněžence. Patří-li připojená peněženka uživatelovu LN uzlu, může být útok použit k zabránění zabezpečení prostředků, které mu patří, před vypršením časové lhůty. Tím by protistrana mohla tyto prostředky ukrást.

    Existují dvě verze útoku, z nichž obě zneužívají limity v Bitcoin Core spojené s maximálním počtem nepotvrzených transakcí, které uzel během určitého časového období rozešle nebo přijme. Tyto limity chrání spojení uzlu před nadměrnou zátěží a před útoky odepřením služby.

    První verze útoku nazývaná Riardem horní přetečení (high overflow) zneužívá skutečnosti, že Bitcoin Core najednou odešle svým spojením maximálně 1 000 oznámení o nepotvrzených transakcích. Čeká-li ve frontě na odeslání více než 1 000 transakcí, jsou nejdříve oznámeny transakce s nejvyššími jednotkovými poplatky. Po odeslání dávky oznámení čeká Bitcoin Core před odesláním dalších transakcí, dokud nedosáhne průměrná rychlost odesílání oznámení sedm transakcí za sekundu.

    Pokud z prvních 1 000 oznámení platí všechny vyšší jednotkové poplatky než transakce, kterou chce oběť odeslat, a pokud útočník nadále posílá uzlu oběti nejméně sedm transakcí s vyšším jednotkovým poplatkem za sekundu, může útočník ve zveřejnění transakce bránit donekonečna. Většina útoků na LN by potřebovala pozdržet zveřejnění na 32 bloků (výchozí nastavení Core Lightning) až 140 bloků (výchozí nastavení Eclair), což by při 10 sat/vbyte mohlo stát mezi 1,3 BTC (3 000 000 Kč) a 5,9 BTC (14 000 000 Kč), ačkoliv Riard poznamenává, že opatrný útočník, který je dobře připojený k jiným přeposílajícím uzlům (nebo přímo k velkým těžařům), by mohl tyto náklady výrazně snížit.

    Druhá verze útoku, kterou Riard nazývá spodní přetečení (low overflow), zneužívá omezení Bitcoin Core, které nepovolí umístit do fronty více než 5 000 nevyžádaných transakcí na jedno spojení. Útočník pošle oběti obrovské množství transakcí s minimálním jednotkovým poplatkem. Oběť je oznámí svým čestným spojením a ta zařadí oznámení do fronty. Opakovaně se potom pokouší frontu vyprázdnit vyžadováním transakcí, avšak deficit se navyšuje, dokud nedosáhne limitu 5 000 oznámení. V ten okamžik začnou spojení další oznámení ignorovat, dokud se fronta částečně nevyprázdní. Je-li čestná transakce oběti oznámena během této doby, spojení ji budou ignorovat. Tento útok může být výrazně levnější než horní přetečení, neboť útočníkovy škodlivé transakce mohou platit minimální poplatek nutný pro přeposílání. Útok však může být méně spolehlivý, útočník tak může ztratit peníze utracené za poplatky, aniž by krádeží něco získal.

    V normální situaci se tyto útoky nejeví jako příliš vážné. Jen velmi málo kanálů bude mít platby čekající na vyřízení, které by převyšovaly náklady na útok. Riard doporučuje, aby uživatelé LN kanálů s vysokou hodnotou provozovali další plné uzly, včetně takových, které by neakceptovaly příchozí spojení a které by přijímaly a přeposílaly pouze bloky, aby bylo zaručené, že budou přeposílat nepotvrzené transakce pouze od vlastní peněženky. Sofistikovanější útoky, které umí náklady snížit, nebo útoky, které používají stejnou sadu škodlivých transakcí k útoku na více LN kanálů najednou, by mohly mít dopad i na kanály s nižšími hodnotami. Riard navrhuje LN implementacím několik opatření. Možné změny P2P protokolu v Bitcoin Core, které by tento problém adresovaly, ponechává na pozdější diskuzi.

    Poznámka čtenářům: omlouváme se, pokud jsou v tomto popisu nějaké chyby. O tomto odhalení jsme se dozvěděli jen krátce před zveřejněním tohoto čísla zpravodaje.

  • ● Pokračuje diskuze o návrhu soft forku na pročištění konsenzu: Antoine Poinsot připojil do existujícího vlákna ve fóru Delving Bitcoin o navrhovaném soft forku pročištění konsenzu nový příspěvek, ve kterém vedle již navržené opravy klasické zranitelnosti způsobené ohýbáním času navrhuje též přidat opravu nedávno objeveného Zawyho-Murchova ohýbání času (viz zpravodaj č. 316). Upřednostňoval by opravu, kterou původně navrhl Mark „Murch” Erhardt: „požadovat, aby poslední blok periody měl vyšší časové razítko než první blok stejné periody.”

    Anthony Towns vyjádřil preferenci nad jiným řešením, které navrhl Zawy. Toto řešení by zakázalo blokům tvrdit, že byly vytvořené více než dvě hodiny před kterýmkoliv předchozím blokem. Zawy poznamenal, že jeho řešení by těžařům zvýšilo riziko ztráty peněz v případě používání staršího software, avšak na druhou stranu by zpřesnilo časová razítka pro jiné účely, jako jsou časové zámky.

    Poinsot dále ve fóru Delving Bitcoin i v emailové skupině Bitcoin-Dev žádal o poskytnutí zpětné vazby k výběru řešení pro zabránění bloku 1 983 702 a několika pozdějších v duplikaci předchozí coinbasové transakce (což by mohlo vyústit ve ztrátu peněz a k tvorbě nových útoků). Prezentovány jsou čtyři návrhy řešení, z nichž každé by mělo přímý dopad na těžaře. Jejich zpětná vazba je tedy obzvláště žádoucí.

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.

  • ● Bitcoin Core #30708 přidává RPC příkaz getdescriptoractivity, který v rámci stanovené množiny bloků vyhledá všechny transakce spojené s deskriptorem. Peněženky tím budou moci s Bitcoin Core komunikovat bezstavově. Příkaz je obzvláště užitečný ve spolupráci se scanblocks (viz zpravodaj č. 222, angl.), který vrátí seznam hašů bloků obsahujících transakce asociované s deskriptorem.

  • ● Core Lightning #7832 utrácí z anchor výstupů též u transakcí neurgentních jednostranných zavření kanálu. Na začátku bude cílit 2016 bloků (zhruba dva týdny), postupně se cíl bude snižovat až na 12 bloků. Tyto hodnoty budou ukládány, aby se zachovala konzistence mezi restarty. Dříve tento druh transakcí ve výchozím stavu z anchor výstupů neutrácel a bylo obtížné tak učinit manuálně a nemožné navýšit poplatek pomocí CPFP.

  • ● LND #8270 implementuje protokol chvíle ticha (channel quiescence) dle specifikace v BOLT2 (viz zpravodaj č. 309). Podpora protokolu je předpokladem pro dynamické commitmenty a pro splicing. Umožňuje uzlu reagovat na žádost protistrany o chvíli ticha i tento proces iniciovat pomocí nových operací v ChannelUpdateHandler. PR též přidává nastavitelnou lhůtu pro nakládání se spojeními, které dlouho neodpovídají. Taková spojení budou odpojena, pokud chvíle ticha trvá příliš dlouho.

  • ● LND #8390 přináší podporu pro nastavení a šíření hodnoty pole pro signalizaci experimentálních HTLC atestací ve zprávách update_add_htlc. Cílem změny je výzkum prevence útoku zahlcením kanálu. Pokud uzel obdrží HTLC s tímto signalizačním polem, přepošle jej beze změny, jinak nastaví jeho hodnotu na nulu. Tato funkce je ve výchozím nastavení aktivní, avšak lze ji vypnout.

  • ● BIPs #1534 začleňuje BIP349 specifikující nový tapscriptový (BIP342) opkód OP_INTERNALKEY, který umístí taprootový interní klíč do zásobníku. Autoři skriptů potřebují znát interní klíč před tím, než mohou na výstup platit. Tento mechanismus poskytuje alternativu k přidání interního klíče přímo do skriptu, čímž při každém použití ušetří 8 vbyte a skripty budou moci být snáze opakovaně použitelné (viz zpravodaj č. 285).