Zpravodaj tento týden oznamuje nový protokol pro agregaci podpisů kompatibilní s secp256k1 a popisuje standardizovaný systém záloh pro deskriptory peněženek. Též nechybí naše pravidelné rubriky se souhrnem nedávný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 páteřním bitcoinovém software.

Novinky

• ● Interaktivní agregované podpisy kompatibilní s secp256k1: Jonas Nick, Tim Ruffing, Yannick Seurin zaslali do emailové skupiny Bitcoin-Dev příspěvek s ohlášením jejich článku o 64bajtových agregovaných podpisech kompatibilních s již používanými kryptografickými primitivy. Agregované podpisy jsou nezbytností pro agregaci podpisů napříč vstup (cross-input signature aggregation, CISA). Tato navrhovaná funkcionalita by mohla snížit velikost transakcí s více vstupy, což by snížilo náklady na používání mimo jiné i coinjoinů a payjoinů, tedy systémů pro navýšení soukromí.

  Kromě schématu na agregaci podpisů, jako je DahLIAS navržený zmíněnými autory, by přidání podpory pro CISA do bitcoinu vyžadovalo změnu konsenzu. Dále bude potřeba zkoumat i možné interakce mezi agregací podpisů a jinými navrženými změnami konsenzu.

• ● Standardizované zálohování deskriptorů peněženek: Salvatore Ingala zaslal do fóra Delving Bitcoin příspěvek s popisem kompromisů během zálohování deskriptorů peněženek. Dále popsal návrh schématu, který by měl být užitečný pro mnoho rozličných druhů peněženek včetně těch používajících složité skripty. Jeho schéma šifruje deskriptory pomocí deterministicky generovaného 32bajtového tajného klíče. Pro každý veřejný klíč (nebo rozšířený veřejný klíč) v deskriptoru je kopie tajného klíče xorována s určitou variantou tohoto veřejného klíče, což vytvoří n 32bajtových „šifrovaných” tajných klíčů při n veřejných klíčích. Kdokoliv se znalostí jednoho z těchto veřejných klíčů použitých v deskriptorech ho může xorovat s 32bajtovým „šifrovaným” tajným klíčem a získat tak 32bajtový tajný klíč, který může deskriptor dešifrovat. Toto jednoduché a efektivní schéma umožňuje komukoliv uložit množství zašifrovaných kopií deskriptoru napříč médii a lokacemi a poté – v případě ztráty dat peněženky – vygenerovat pomocí BIP32 seedu xpub a deskriptory dešifrovat.

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ů.

• ● Praktičnost poloagregovaných Schnorrových podpisů? Fjahr diskutuje, proč nejsou nezávislé neagregované podpisy pro validaci poloagregovaných podpisů v agregaci podpisů napříč vstupy (cross-input signature aggregation, CISA) vyžadovány a proč jsou neagregované podpisy ve skutečnosti problematické.

• ● Jaká je vůbec největší vytvořená OP_RETURN zpráva? Vojtěch Strnad odkazuje na transakci metaprotokolu Runes se 79 870 bajty, která obsahuje největší OP_RETURN.

• ● Vysvětlení pay-to-anchor bez odkazování na LN? Murch popisuje motivace a strukturu pay-to-anchor (P2A) výstupních skriptů.

• ● Aktualizované statistiky reorganizací řetězce? 0xb10c a Murch odkazují na zdroje dat o reorganizacích včetně repozitáře stale-blocks a stránek forkmonitor.info a fork.observer.

• ● Jsou ligthningové kanály vždy P2WSH? Polespinasa poznamenává, že probíhá vývoj P2TR jednoduchých taprootových kanálů, a shrnuje aktuální podporu mezi implementacemi.

• ● Child-pays-for-parent jako obrana proti dvojímu utracení? Murch vyjmenovává komplikace s používáním CPFP potomka s vysokým poplatkem jako incentivy pro reorganizaci blockchainu ve snaze o nápravu již potvrzeného dvojitě utraceného výstupu.

• ● Jaké hodnoty hašuje CHECKTEMPLATEVERIFY? Average-gray vypisuje pole, kterým OP_CHECKTEMPLATEVERIFY zavazuje: nVersion, nLockTime, počet vstupů, haš sekvencí, počet výstupů, haš výstupů, index vstupu a někdy haš scriptSigu.

• ● Proč nemohou lightningové uzly dobrovolně odhalit zůstatky v kanálu pro lepší routování? Rene Pickhardt vysvětluje obavy o neaktuálnosti a důvěryhodnosti těchto dat a dopady na soukromí a odkazuje na podobný návrh z roku 2020.

• ● Vyžaduje kvantová odolnost hard fork nebo soft fork? Vojtěch Strnad nastiňuje přístup, kterým by mohlo být kvantově rezistentní (PQC) schéma podepisování aktivováno jako soft fork, a jak by mohl hard fork nebo soft fork uzamknout kvantově slabé mince.

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.

• ● LND 0.19.0-beta.rc3 je kandidátem na vydání tohoto oblíbeného LN uzlu. Jedním významným vylepšením, které by si zasloužilo důkladné testování, je nové schéma RBF navyšování poplatků během kooperativního zavření kanálu.

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, Lightning BLIPs, Bitcoin Inquisition a repozitáři BINANA.

• ● Bitcoin Core #31247 přidává podporu serializace a parsování MuSig2 PSBT polí dle specifikace v BIP373, čímž umožní peněženkám podepisovat a utrácet MuSig2 vstupy. Na straně vstupů jsou mezi těmito poli veřejné klíče účastníků a pro každého podepisujícího ještě veřejný nonce a částečný podpis. Na straně výstupů jsou to veřejné klíče účastníků nového UTXO.

• ● LDK #3601 přidává nový výčtový typ LocalHTLCFailureReason reprezentující standardní BOLT4 chybové kódy a několik dodatečných variant poskytujících uživatelům dodatečné informace.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 29. 4. v 15:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.