Zpravodaj tento týden oznamuje opravenou zranitelnost postihující starší verze Bitcoin Core, poskytuje aktualizaci hybridní ochrany před zahlcováním kanálu, shrnuje článek o efektivnější a soukromější validaci na straně klienta a oznamuje návrh na změnu procesu přijímání BIPů. Též nechybí naše pravidelné rubriky se souhrnem oblíbených otázek a odpovědí z Bitcoin Stack Exchange, 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

  • ● Odhalení zranitelnosti postihující Bitcoin Core před verzí 24.0.1: Antoine Poinsot zaslal do emailové skupiny Bitcoin-Dev příspěvek s odkazem na oznámení zranitelnosti, která postihovala starší verze Bitcoin Core s ukončenou podporou nejméně od prosince 2023. Předchozím odhalením starších zranitelností jsme se věnovali ve zpravodajích č. 310 a č. 314.

    Nové odhalení se zaobírá dlouho známou metodou způsobující pád plných uzlů Bitcoin Core: poslat jim dlouhé sekvence hlaviček bloků, které se budou ukládat v paměti. Každá hlavička bloku má 80 bajtů a bez dalších ochran by bylo možné je vytvářet s minimální námahou. Útočník by jich mohl s moderními ASIC zařízeními produkovat milióny za sekundu. Bitcoin Core je proti tomu již mnoho let chráněn díky vedlejšímu efektu kontrolních bodů přidaných v raných verzích. Útočník tak musí vyvinout značné úsilí k vytvoření vysokého proof of work, za který by ale mohl být placen, pokud by vytvářel validní bloky.

    Avšak poslední kontrolní bod byl přidán před více než deseti lety a vývojáři Bitcoin Core se nemají k přidání nových, neboť by to dávalo chybný dojem, že konečnost transakcí závisí na vývojářích a kontrolních bodech. Díky vývoji těžebního vybavení a nárůstu celkového hashrate v síti se náklady na generování falešných řetězců hlaviček snížily. Jak se náklady snižovaly, výzkumníci David Jaenson a Braydon Fuller nezávisle útok zodpovědně nahlásili vývojářům Bitcoin Core. Vývojáři odpověděli, že o problému ví a vybídli v roce 2019 Fullera ke zveřejnění článku o útoku.

    V roce 2022 se náklady na provedení útoku dále snížily a skupina vývojářů začala pracovat na řešení, které nevyžadovalo kontrolní body. Bitcoin Core PR #25717 (viz zpravodaj č. 216, angl.) byl výsledkem této snahy. Později Niklas Gögge odhalil v logice opravy chybu a otevřel PR #26355 s opravou. Obě opravy byly začleněny a vydány v Bitcoin Core 24.0.1.

  • ● Testování a obměna hybridní ochrany před zahlcováním: Carla Kirk-Cohen zaslala do fóra Delving Bitcoin příspěvek popisující rozličné pokusy o proražení této ochrany proti útokům zahlcením kanálu, kterou původně navrhli Clara Shikhelman a Sergei Tikhomirov. Hybridní ochrana před zahlcením spočívá v kombinaci HTLC atestací a drobného poplatku předem, který se bezpodmínečně zašle bez ohledu na úspěch či selhání platby.

    Několik vývojářů bylo vyzváno k pokusu o zahlcení kanálu na jednu hodinu, zatímco Kirk-Cohen a Shikhelman zkoumaly slibné druhy útoků. Většina útoků selhala; buď proto, že útočník utratil více než s jiným druhem útoku, nebo proto, že oběť útoku nakonec obdržela více peněz, než kolik by získala běžným přeposíláním.

    Jeden útok byl úspěšný: sink attack, který „má za cíl snížit reputaci spojení cíleného uzlu. Dosahuje toho vytvářením kratších a levnějších cest v síti a sabotováním plateb směrovaných přes jeho kanály. Tím se sníží reputace všech uzlů, které ho v cestě předcházejí.” Pro mitigaci útoku přidaly Kirk-Cohen a Shikhelman do způsobu evaluace HTLC atestací obousměrnou reputaci. Když Bob obdrží od Alice platbu, která má být přeposlána Carol (např. A -> B -> C), Bob jednak zváží, zda Alice obvykle posílá HTLC, která jsou rychle urovnána (jako u stávajících HTLC atestací), ale také zda Carol obvykle obdrží HTLC, která jsou rychle urovnána (toto je novinka). Nyní když Bob obdrží od Alice HTLC s atestací:

    • Pokud Bob věří, že Alice a Carol jsou spolehlivé, přepošle Carol Alicino HTLC spolu s atestací .

    • Pokud si Bob myslí, že pouze Alice je spolehlivá, nepřepošle Alicino HTLC s atestací. Okamžitě jej odmítne a umožní propagovat chybu zpět k odesílateli, který bude moci provést platbu znova po jiné trase.

    • Pokud si Bob myslí, že pouze Carol je spolehlivá, přijme Alicino HTLC s atestací, má-li kapacitu navíc, ale sám atestaci během přeposílání směrem ke Carol nepřipojí.

    Jelikož nastala v návrhu tato změna, plánují Kirk-Cohen a Shikhelman další experimenty, aby zaručily, že vše funguje dle očekávání. Dále též odkázaly na příspěvek od Jima Posena z května 2018, který popisuje obousměrný systém reputací pro zabránění útoků zahlcením (tehdy nazývaných cyklické útoky, loop attacks), jako příklad dřívějšího uvažování nad řešením tohoto problému.

  • ● Shielded client-side validation (CSV): Jonas Nick, Liam Eagen a Robin Linus zaslali do emailové skupiny Bitcoin-Dev příspěvek o novém protokolu validace na straně klienta. Validace na straně klienta umožňuje zabezpečit přenos tokenů bitcoinovým proof of work bez nutnosti zveřejňovat jakékoliv informace o těchto tokenech či jejich pohybu. Validace na straně klienta je klíčovou komponentou protokolů jako RGB či Taproot Assets.

    Nevýhodou existujících protokolů je množství dat, která musí být klientem validována. V nejhorším případě to může být až celá historie každého transferu daného tokenu plus všech tokenů s ním souvisejících. Jinými slovy by u tokenů tak často posílaných jako bitcoiny musel klient validovat historii zhruba stejně velkou, jako je celý bitcoinový blockchain. Vedle nákladů na přenos těchto dat a na procesorový čas snižuje nutnost přenášet plnou historii soukromí předchozích příjemců tokenů. Na druhou stranu, Shielded CSV používá důkazy s nulovou znalostí. Pro ověření je tak potřeba pevně dané množství zdrojů bez nutnosti odhalit předchozí transfery.

    Dalším záporem stávajících protokolů je, že každý transfer tokenu vyžaduje přidat data do nějaké bitcoinové transakce. Shielded CSV umožňuje sloučit několik přesunů dohromady do 64 bajtů. Díky tomu mohou být přidáním 64 bajtů do jediné bitcoinové transakce potvrzeny tisíce transferů.

    Článek přináší další podrobnosti. Obzvláště zajímavé jsme shledali myšlenky přemostění bitcoinu z hlavního blockchainu na Shielded CSV a zpět bez požadavku na důvěru a bez nutnosti změny konsenzu pomocí BitVM, používání účtů (sekce 2), diskuzi o dopadech reorganizace blockchainu na účty a přenosy (též sekce 2), související diskuzi o závislosti na nepotvrzených transakcích (sekce 5.2) a seznam možných rozšíření (příloha A).

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.

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

  • ● Bitcoin Core 28.0rc2 je kandidátem na vydání příští hlavní verze této převládající implementace plného uzlu. K dispozici je průvodce testování.

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.

  • ● Eclair #2909 přidává do RPC příkazu createinvoice parametr privateChannelIds, který slouží k přidání návrhů tras do BOLT11 faktur. Tím se opravuje chyba, která zabránila uzlům majícím pouze soukromé kanály obdržet jakékoliv platby. Pro zachování soukromí by se měl používat scid_alias.

  • ● LND #9095 a LND #9072 přináší úpravy v modifikátoru HTLC a otevírání a zavírání doplňkových kanálů a integrují uživatelská data do RPC/CLI. Jedná se o součást iniciativy uživatelských kanálů sloužící k vylepšení podpory taproot assets. Toto PR umožní, aby byla uživatelská data pro konkrétní aktiva předána RPC příkazy. Dále přidá podporu pro správu doplňkových kanálů přes příkazovou řádku.

  • ● LND #8044 přidává nové typy zpráv announcement_signatures_2, channel_announcement_2 a channel_update_2 pro podporu nového gossip protokolu v1.75 (viz zpravodaj č. 261). Umožní uzlům oznamovat a ověřovat taprootové kanály. Dále byly provedeny úpravy v existujících zprávách jako channel_ready a gossip_timestamp_range navyšující efektivitu a bezpečnost v práci s taprootovými kanály.