Zpravodaj tento týden oznamuje nadcházející odhalení zranitelností postihujících starší verze Bitcoin Core, popisuje návrh BIPu pro novou verzi testnetu, shrnuje návrh na kovenanty založené na funkcionálním šifrování, zkoumá aktualizaci návrhu na provádění 64bitové aritmetiky v bitcoinovém Scriptu, odkazuje na skript validující proof of work na signetu pomocí opkódu OP_CAT a nahlíží na navrhovanou aktualizaci specifikace BIP21 URI ve tvaru bitcoin:. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Nadcházející odhalení zranitelností postihujících staré verze Bitcoin Core: několik členů projektu Bitcoin Core diskutovalo na IRC o navrhovaných pravidlech pro odhalování zranitelností, které postihovaly starší verze Bitcoin Core. V případě zranitelností s nízkou závažností budou podrobnosti odhaleny dva týdny po vydání první verze Bitcoin Core, která zranitelnost odstraňuje či dostatečně zmírňuje její dopad. Většina ostatních zranitelností bude s podrobnostmi odhalena poté, co poslední verze Bitcoin Core postižená zranitelností dosáhne end-of-life (což je zhruba 1,5 roku po vydání). U výjimečných kritických zranitelností budou členové bezpečnostního týmu Bitcoin Core soukromě diskutovat nejvhodnější postup odhalení.

    Po dostatečném prodiskutování těchto pravidel je záměrem projektu začít odhalovat zranitelnost postihující Bitcoin Core 24.x a nižší. Důrazně se doporučuje, aby během následujících dvou týdnů všichni uživatelé a správci upgradovali na Bitcoin Core 25.0 nebo vyšší. V ideálním případě (pokud je to možné) by měly být používány poslední verze, ať již absolutně poslední verze (v době psaní 27.0) nebo poslední verze konkrétní série (např. 25.2 u série 25.x nebo 26.1 u série 25.x).

    Jak je naší politikou, Optech poskytne souhrn všech významných bezpečnostních odhalení postihujících páteřní projekty, které monitorujeme (včetně Bitcoin Core).

  • ● BIP a experimentální implementace testnet4: Fabian Jahr zaslal do emailové skupiny Bitcoin-Dev příspěvek s oznámením návrhu BIPu pro testnet4, novou verzi testnetu navrženou na odstranění některých problémů se stávajícím testnet3 (viz zpravodaj č. 297). Jahr též odkazuje na pull request Bitcoin Core s návrhem implementace. Testnet4 se od testnet3 odlišuje ve dvou významných aspektech:

    • ● Méně často difficulty-1: bývalo snadné (nahodile či záměrně) redukovat složitost (difficulty) celé periody 2 016 bloků na její minimum (difficulty-1). Postačovalo k tomu vytěžit poslední blok periody s časovým razítkem o více než 20 minut vyšším, než měl předposlední blok. Nově se může složitost snížit pouze stejným způsobem jako na mainnetu, ačkoliv je stále možné vytěžit všechny jednotlivé bloky (kromě prvního bloku periody) s difficulty-1, mají-li časová razítka o více než 20 minut vyšší než přecházející blok.1

    • ● Ohýbání času opraveno: zneužitím útoku ohýbáním času (time warp attack) bylo na testnet3 (i na mainnetu) možné produkovat bloky výrazně rychleji než jednou za 10 minut, aniž by byla zvýšena složitost. Testnet4 nově implementuje řešení ohýbání času, které bylo navrženo v rámci mainnetového soft forku pročištění konsenzu.

    Návrh BIPu též zmiňuje dodatečné a alternativní nápady určené pro testnet4, o kterých se diskutovalo, avšak nakonec použity nebyly.

  • ● Kovenanty s použitím funkcionálního šifrování: Jeremy Rubin zaslal do fóra Delving Bitcoin příspěvek s myšlenkou na přidání celého souboru kovenantů do bitcoinu pomocí funkcionálního šifrování a bez nutnosti změn konsenzu. Toto řešení by po uživatelích kovenantů požadovalo důvěřovat třetí straně, ačkoliv tato důvěra by mohla být distribuována mezi několik jednotek a stačilo by, aby jen jeden z nich jednal v daný čas čestně.

    V zásadě by funkcionální šifrování umožnilo vytvořit veřejný klíč, který by odpovídal určitému programu. Strana, která by program dokázala úspěšně spustit, by byla schopna vytvořit podpis odpovídající tomuto veřejnému klíči (a odpovídající soukromý klíč by se nikdy nedozvěděla).

    Rubin poznamenává, že má toto schéma oproti existujícím návrhům na kovenanty výhodu v tomu, že všechny operace (kromě ověření výsledného podpisu) se dějí offchain a žádná data (kromě veřejného klíče a podpisu) nemusí být publikována onchain. To vždy znamená více soukromí a méně zabraného prostoru. Jeden skript může obsahovat více kovenantových programů tím, že provede více ověření podpisů.

    Kromě potřeby důvěryhodné strany popisuje Rubin i další významnou nevýhodu funkcionálního šifrování jako „nevyvinutou kryptografii, která není v současnosti prakticky použitelná.”

  • ● Změny navrhovaného soft forku pro 64bitovou aritmetiku: Chris Stewart zaslal do fóra Delving Bitcoin příspěvek oznamující aktualizaci jeho návrhu na přidání schopnosti pracovat v bitcoinovém Scriptu s 64bitovými čísly (viz zpravodaje č. 285 a č. 290). Hlavním změnami jsou:

    • ● Aktualizace stávajících opkódů: namísto přidání nových opkódů jako OP_ADD64 byly stávající opkódy (např. OP_ADD) aktualizovány, aby fungovaly s 64bitovými čísly. Jelikož se kódování velkých čísel od současného liší, budou muset být části skriptů, které mají nově velká čísla používat, revidovány. Stewart jako příklad uvádí OP_CHECKLOCKTIMEVERIFY, která by nově vyžadovala osmibajtový parametr namísto pětibajtového.

    • ● Výsledek přidává booleovou hodnotu: úspěšná operace nejen, že umístí do zásobníku výsledek, ale navíc přidá i boolevou hodnotu indikující, zda operace proběhla úspěšně. Častým důvodem selhání operace může být výsledek mající větší než 64 bitů, čímž by přetekla velikost pole. Kód může pro zajištění úspěšného dokončení použít OP_VERIFY.

    Anthony Towns ve své reakci volal po alternativním přístupu, kde by opkódy v případě přetečení selhaly. Skripty by tak nemusely provádět nadbytečné ověření úspěšného provedení. Pro případy, kde by bylo testování přetečení výsledku užitečné, by mohly být zpřístupněny nové opkódy jako například ADD_OF.

  • ● Skript s OP_CAT validující proof of work: Anthony Towns zaslal do fóra Delving Bitcoin příspěvek o signetovém skriptu používajícím OP_CAT, který umožní komukoliv pomocí proof of work (PoW) utratit mince zaslané na tento skript. Může to být použito jako decentralizovaný zdroj pro signetové mince: má-li těžař nebo uživatel nepotřebné signetové mince, může je poslat na tento skript. Chce-li někdo získat více signetových mincí, může mezi UTXO nalézt platby na tento druh skriptu, vygenerovat PoW a vytvořit transakci, která tento PoW používá jako doklad nároku na mince.

    Townsův příspěvek popisuje zmíněný skript a důvody stojící za některými rozhodnutími.

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.

  • ● Core Lightning #7252 mění chování lightningd, aby během kooperativního zavírání kanálu ignoroval nastavení ignore_fee_limits. Odstraňuje tím problém, kdy CLN uzel, který otevře kanál s LDK, přeplácí na poplatcích. V tomto scénáři CLN uzel Bob otevřel kanál k LDK uzlu Alici. Když Alice zahájí kooperativní zavření kanálu a započne vyjednávání o poplatku, Bob kvůli ignore_fee_limits akceptuje cokoliv mezi min_sats a max_channel_size. LDK „vždy vybere nejvyšší možnou částku” (v rozporu s BOLT specifikací), proto Bob zvolí horní hranici a Alice ji přijme, načež Alice transakci zveřejní s výrazným přeplatkem.

  • ● LDK #2931 přidává do logování během hledání cest více dat o přímých kanálech, např. zda chybí či jaká je jejich minimální a maximální částka HTLC. Cílem je snazší hledání příčin chyb routování.

  • ● Rust Bitcoin #2644 přidává do bitcoin_hashes HKDF, funkci pro derivování klíčů pomocí HMAC, která je potřebná pro implementaci BIP324. HKDF se používá pro bezpečné standardní odvozování kryptografických klíčů z nějakého zdroje dat. BIP324 (v2 P2P transport) je způsob pro vzájemnou komunikaci uzlů šifrovaným spojením (v Bitcoin Core je ve výchozím nastavení aktivní).

  • ● BIPs #1541 přidává BIP431 se specifikací do potvrzení topologicky omezených transakcí (Topologically Restricted Until Confirmation, TRUC, též v3 transakce), které jsou podmnožinou standardních transakcí s dodatečnými pravidly určenými k umožnění nahrazování transakcí a minimalizaci nákladů na obranu před pinningovými útoky.

  • ● BIPs #1556 přidává BIP337 se specifikací komprimovaných transakcí, serializačního protokolu pro kompresi bitcoinových transakcí, který sníží jejich velikost až o polovinu. Komprese je vhodná pro úzká přenosová pásma, jako je satelit, HAM rádio či steganografie. Navrženy jsou dva RPC příkazy: compressrawtransaction a decompressrawtransaction. Zpravodaj č. 267 obsahuje podrobnější vysvětlení.

  • ● BLIPs #32 přidává BLIP32 popisující, jak mohou být navrhované čitelné bitcoinové platební instrukce založené na DNS (viz zpravodaj č. 290) použité s onion zprávami pro posílání plateb na adresy jako bob@example.com. Například Alice chce pomocí svého LN klienta zaplatit Bobovi. Její klient není schopen bezpečně přeložit DNS adresy přímo, ale může pomocí onion zprávy kontaktovat jednoho ze svých spojení inzerujících tuto službu. Spojení obdrží DNS TXT záznam pro položku bob v example.com a vrátí výsledek Alici spolu s DNSSEC podpisem. Alice výsledek ověří a pomocí něj a protokolu nabídek požádá Boba o fakturu.

Poznámky

  1. Tento odstavec byl upraven po zveřejnění. Korekci navrhl Mark „Murch” Erhardt, děkujeme. ↩