Zpravodaj tento týden přináší popis protokolu pro distribuované generování klíčů pro schéma bezskriptového prahového elektronického podpisu FROST a odkazuje na podrobný úvod do linearizace clusterů. Též nechybí naše pravidelné rubriky s popisem nedávných významných změn ve službách, klientech a populárních bitcoinových páteřních projektech.

Novinky

  • ● Protokol pro distribuované generování klíčů pro FROST: Tim Ruffing a Jonas Nick zaslali do emailové skupiny Bitcoin-Dev příspěvek s návrhem BIPu a referenční implementací protokolu ChillDKG pro bezpečné generování klíčů, které mohou být používány pro bezskriptové prahové elektronické podpisy kompatibilní se Schnorrovými podpisy. Jedním příkladem takového schématu je FROST.

    Bezskriptové prahové elektronické podpisy jsou kompatibilní s vytvořením n klíčů, z nichž kterýchkoliv t může být kooperativně použito k vytvoření validního podpisu. Například schéma 2-ze-3 vytvoří tři klíče, z nichž kterékoliv dva mohou vytvořit validní podpis. Bezskriptové znamená, že schéma zcela závisí na operacích mimo konsenzus a blockchain, což je opakem vestavěných skriptových prahových podpisů (např. pomocí OP_CHECKMULTISIG).

    Podobně jako při generování běžného bitcoinového soukromého klíče musí i zde každý účastník vygenerovat velké náhodné číslo, které nikomu nesmí sdělit. Avšak každý účastník musí navíc rozeslat ostatním účastníkům kódy odvozené z těchto náhodných čísel, aby mohla patřičná část z nich (daná hodnotou prahu) podpis vytvořit, i kdyby byl jeho klíč nedostupný. Každý uživatel musí ověřit, že informace obdržené od všech ostatních byly vygenerované správně. Existuje několik protokolů pro generování klíčů, avšak předpokládají, že uživatelé mají přístup k šifrovanému a autentizovanému komunikačnímu kanálu mezi jednotlivými uživateli, který navíc umožňuje necenzurovatelné autentizované šíření zpráv od každého uživatele všem ostatním. Protokol ChillDKG kombinuje známý algoritmus generování klíčů pro FROST s dalšími moderními kryptografickými primitivy a jednoduchými algoritmy, které poskytnou nezbytnou bezpečnou, autentizovanou a doložitelně necenzurovanou komunikaci.

    Šifrování a autentizace mezi účastníky začíná výměnou klíčů pomocí Diffieho-Hellmannova protokolu nad eliptickými křivkami (ECDH). Každý účastník vytvoří doklad absence cenzury tím, že svým klíčem podepíše transkript sezení od začátku až do vytvoření bezskriptového prahového veřejného klíče (kterým sezení končí). Všichni ostatní tento podpis ověří, než prahový veřejný klíč přijmou.

    Cílem je poskytnout zcela obecný protokol, který by byl použitelný ve všech případech, kdy chtějí lidé generovat klíče pro bezskriptové prahové elektronické podpisy založené na FROSTu. Navíc tento protokol nabízí možnost snadno ukládat zálohy: uživatel pouze potřebuje svůj soukromý seed a data pro obnovu, která nejsou citlivá na bezpečnost (ale mají dopad na soukromí). V následné zprávě Jonas Nick zmínil, že uvažují nad rozšířením protokolu o šifrování dat pro obnovu klíčem odvozeným ze seedu. Díky tomu by jedinými daty, které uživatel musí chránit, byl seed.

  • ● Úvod do linearizace clusterů: Pieter Wuille zaslal do fóra Delving Bitcoin příspěvek s podrobným popisem všech hlavních částí linearizace clusterů, která tvoří základ mempoolu clusterů. V minulých číslech zpravodaje jsme se toto téma pokoušeli představit v době, kdy byly vyvíjeny a publikovány klíčové koncepty. Tento přehled je však mnohem podrobnější. Postupně seznamuje čtenáře se vším od základních konceptů po konkrétní implementované algoritmy. Na závěr uvádí odkazy na několik pull requestů Bitcoin Core, které části cluster mempoolu implementují.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

  • ● ZEUS přidává podporu pro BOLT12 nabídky a BIP353: Vydání v0.8.5 využívá službu TwelveCash pro podporu nabídek a BIP353 (viz zpravodaj č. 307).

  • ● Phoenix přidává podporu pro BOLT12 nabídky a BIP353: Vydání Phoenix 2.3.1 přidalo podporu pro nabídky a Phoenix 2.3.3 přidalo podporu pro BIP353.

  • ● Stack Wallet přidává podporu pro RBF a CPFP: Vydání Stack Wallet v2.1.1 přidalo podporu pro navýšení poplatku pomocí RBF a CPFP a také podporu pro Tor.

  • ● BlueWallet přidává podporu pro posílání tichých plateb: Ve vydání v6.6.7 přidala BlueWallet možnost platit na adresy tichých plateb.

  • ● Ohlášen BOLT12 Playground: Strike ohlásil testovací prostředí pro BOLT12 nabídky. Projekt pomocí Dockeru vytváří a automatizuje peněženky, kanály a platby napříč různými LN implementacemi.

  • ● Ohlášen testovací repozitář Moosig: Ledger zveřejnil testovací repozitář založený na Pythonu určený k používání MuSig2 a pravidel peněženek pro deskriptorové peněženky (BIP388).

  • ● Vydán nástroj pro vizualizaci protokolu Stratum v reálném čase: Webová stránka stratum.work založená na předchozím bádání zobrazuje v reálném čase Stratum zprávy od různých bitcoinových těžebních poolů. K dispozici je zdrojový kód.

  • ● Ohlášen BMM 100 Mini Miner: Těžební zařízení od Braiins přichází s podmnožinou funkcí Stratum V2, jehož podpora je ve výchozím nastavení aktivní.

  • ● Coldcard zveřejňuje specifikaci publikování transakcí založeného na URL: Protokol umožňuje zveřejňovat bitcoinové transakce pomocí HTTP GET požadavku; mimo jiné může být protokol použit hardwarovými podpisovými zařízeními založenými na NFC.

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 #26596 používá nový parser zastaralých databází k migrování zastaralých peněženek na deskriptorové. Změna ponechává podporu pro zastaralé peněženky i zastaralý typ BerkeleyDatabase. Byla přidána třída LegacyDataSPKM, která obsahuje pouze data a funkce nezbytné pro nahrávání zastaralých peněženek určených k migraci. Zpravodaj č. 305 představil BerkeleyRODatabase.

  • ● Core Lightning #7455 přidává do connectd přeposílání onion zpráv pomocí short_channel_id (SCID) i node_id (viz zpravodaj č.307, který popisuje podobnou změnu v LDK). Onion zprávy jsou nově vždy aktivní, příchozí zprávy jsou omezeny na čtyři za sekundu.

  • ● Eclair #2878 přináší volitelnou podporu zaslepených cest a quiescence (chvíle ticha) protokolu. Obě funkce jsou již plně implementované a mají své BOLT specifikace (viz zpravodaje č. 245 a č. 309). Eclair uzel inzeruje podporu pro obě funkce, avšak route_blinding (zaslepené cesty) je ve výchozím nastavení neaktivní, neboť neumí přeposílat zaslepené platby, které nepoužívají trampolínového routování.

  • ● Rust Bitcoin #2646 přidává do struktur Script a Witness nové inspektory jako redeem_script (ověřující shodu s BIP16 pravidly ohledně utrácení P2SH), taproot_control_block a taproot_annex (ověřující shodu s BIP341) a witness_script (shoda s BIP141). Viz též zpravodaj č. 309.

  • ● BDK #1489 přináší do bdk_electrum používání Merkleových důkazů během zjednodušeného ověřování plateb (simplified payment verification, SPV). Vedle transakcí stáhne též Merkleovy důkazy a hlavičky bloků a ověří, že transakce jsou obsažené v potvrzených blocích. PR dále představuje nový typ ukotvení bloků ConfirmationBlockTime, který nahrazuje předchozí typy.

  • ● BIPs #1599 přidává BIP46 popisující schéma derivace pro HD peněženky, které vytváří adresy s časovým zámkem používané pro finanční závazky (fidelity bonds), které jsou používány při párování nabídek v online tržištích s coinjoiny ve stylu JoinMarket. Finanční závazky zlepšují odolnost vůči sybil útokům, protože přináší systém reputace, ve kterém tvůrci nabídek dokládají svou serióznost záměrnou obětí v podobě časově uzamčených bitcoinů.

  • ● BOLTs #1173 činí pole channel_update v chybových onion zprávách volitelným. Uzly nově toto pole mimo aktuální platbu ignorují, aby pomohly chránit identitu odesílatelů HTLC. Změna má za cíl eliminovat zdržování plateb kvůli neaktuálním parametrům kanálu, avšak ponechává uzlům se starými gossip daty možnost v případě potřeby aktualizace přijímat.

  • ● BLIPs #25 přidává BLIP25 popisující, jak umožnit přeposílání HTLC, která platí nedostatečně vzhledem k zakódované hodnotě. Například Alice chce, aby jí Bob poslal peníze, avšak nemá žádný platební kanál. Alicino LSP Carol otevře JIT kanál. Aby mohla Carol nárokovat poplatek za službu a pokrytí svých onchain nákladů, využije tohoto protokolu a pošle Alici HTLC, které platí nedostatečně vzhledem k zakódované hodnotě. Viz též zpravodaj č. 257, který popisuje implementaci v LDK.