Zpravodaj tento týden shrnuje diskuzi o zlepšení situace s nejhorší možnou efektivitou skenování tichých plateb a popisuje myšlenku na možnost stanovit mnoho podmínek utrácení v jediném klíči. 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

  • ● BLISK, logika booleovských obvodů integrovaná do jediného klíče: Oleksandr Kurbatov zaslal do fóra Delving Bitcoin příspěvek o BLISKu, protokolu navrženém na vyjádření komplexních autorizačních pravidel pomocí booleovské logiky. BLISK (Boolean circuit Logic Integrated into the Single Key) má za cíl vyřešit omezení existujících pravidel utrácení. Na příklad protokoly jako MuSig2, ač efektivní a zachovávající soukromí, jsou schopné vyjádřit kardinalitu (k z n), avšak neumí určit, „kdo” může utrácet.

    BLISK vytváří jednoduché AND/OR booleovské obvody a mapuje logická hradla na známé kryptografické techniky. Konkrétně: AND hradla vznikají aplikací n z n vícenásobného podpisu, kde každý účastník musí přispět validním podpisem. Na druhou stranu, OR hradla vznikají použitím protokolu výměny klíčů, jako je ECDH, kde kterýkoliv účastník může odvodit sdílený tajný kód použitím svého soukromého klíče a veřejného klíče kteréhokoliv z ostatních účastníků. Dále také využívá neinteraktivního dokladu s nulovou znalostí, aby umožnil ověřit výsledek obvodu a tím zabránil podvodům. Výsledkem řešení obvodu BLISKu je jediný klíč pro ověřování podpisu. Díky tomu je potřeba ověřit jen jeden Schnorrův podpis oproti jednomu veřejnému klíči.

    Další výhodou BLISKu oproti jiným přístupům je odstranění nutnosti generovat čerstvý klíč, jelikož umožňuje připojit existující klíč ke konkrétní instanci podpisu.

    Kurbatov poskytl pro tento protokol ověřovací implementaci, i když uvedl, že zatím nedosáhla produkční kvality.

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.

  • ● Bitcoin Core 29.3 je údržbovým vydáním předchozí hlavní verze, které přináší opravu několika chyb v migrování peněženek (viz zpravodaj č. 387), přidává vyrovnávací paměť mezistavu sighashe vstupů (snižuje dopady kvadratického algoritmu v zastaralých skriptech, viz zpravodaj č. 367, angl.) a odstraňuje systém hodnocení špatného chování peer spojení za nevalidní transakce (viz zpravodaj č. 367, angl.). Poznámky k vydání obsahují další podrobnosti.

  • ● LDK 0.2.2 je údržbovým vydáním této knihovny pro budování aplikací s podporou LN. Mění příznak podpory splicingu na produkční feature bit (63), opravuje chybu, která mohla po restartování způsobit zamrznutí databázových asynchronních operací ChannelMonitorUpdate, což vedlo k vynucenému zavření kanálu, a opravuje chybu debug assertu, která se objevila po přijetí nevalidní splicingové zprávy.

  • ● HWI 3.2.0 je vydáním tohoto balíčku poskytujícího jednotné rozhraní k několika hardwarovým podpisovým zařízením. Nové vydání přidává podporu pro zařízení Jade Plus a BitBox02 Nova a podporu pro MuSig2 PSBT pole dle specifikace v BIP373.

  • ● Bitcoin Inquisition 29.2 je vydáním tohoto signetového plného uzlu určeného pro experimentování s návrhy soft forků a jinými významnými změnami protokolu. Je založeno na Bitcoin Core 29.3r2, implementuje návrh BIP54 (pročištění konsenzu) a deaktivuje testnet4.

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 #32420 přestává v Mining IPC rozhraní (viz zpravodaj č. 310) přidávat do scriptSig mincetvorné transakce falešný extraNonce. Do CreateNewBlock() přidává novou volbu include_dummy_extranonce a IPC ji nastavuje na false. Klienty Stratum v2 obdrží v scriptSig pouze výšku, jak konsenzus dle BIP34 požaduje, a nemusí tato extra data odstraňovat nebo ignorovat.

  • ● Core Lightning #8772 odstraňuje podporu zastaralého formátu onion plateb. I když CLN přestal staré onion používat v roce 2022 (viz zpravodaj č. 193, angl.), přidal ve verzi 24.05 překladovou vrstvu, která se starala o několik zbývajících zastaralých onion zpráv produkovaných staršími LND. Ty nejsou od LND verze 0.18.3 vytvářeny, podpora již proto není potřebná. Tento zastaralý formát byl z BOLT specifikace odstraněn v roce 2022 (viz zpravodaj č. 220, angl.).

  • ● LND #10507 přidává do odpovědi na RPC volání GetInfo příznak wallet_synced, který určuje, zda peněženka dokončila synchronizaci s aktuálním vrcholem řetězce. Na rozdíl od stávajícího příznaku synced_to_chain toto nové pole nevyžaduje, aby router grafu kanálů (který validuje oznámení kanálů), ani blockbeat dispatcher (podsystém, který koordinuje události bloků) synchronizaci již dokončily.

  • ● LDK #4387 mění příznak podpory splicingu z provizorního feature bitu 155 na produkční bit 63. LDK verze 0.2 používala bit 155, který používá též Eclair pro vlastní implementaci splicingu ve Phoenixu, která předchází současný návrh specifikace a není s ní v souladu. Kvůli tomu se Eclair uzly snažily provádět splicing pomocí vlastního protokolu, což vedlo s LDK uzly k chybám deserializace a odpojování.

  • ● LDK #4355 přidává asynchronní podepisování commitmentů u interaktivně otevíraných transakcí. Děje se tak během splicingu i oboustranně financovaných kanálů. Po obdržení EcdsaChannelSigner::sign_counterparty_commitment asynchronní podepisující objekt okamžitě vrátí a ozve se přes callback ChannelManager::signer_unblocked, když je podpis hotov. Oboustranně financované kanály vyžadují pro plnou podporu asynchronního podepisování další práci.

  • ● LDK #4354 mění výchozí hodnotu volby negotiate_anchors_zero_fee_htlc_tx na true, čímž budou standardně vytvářeny kanály s anchor výstupy. Automatické přijímání kanálů bylo odstraněno, všechny příchozí žádosti o kanál tak musí být schválené manuálně. To zajistí, že peněženka má v případě vynuceného zavření kanálu dostatek onchain prostředků na pokrytí poplatků.

  • ● LDK #4303 opravuje dvě chyby, které mohly způsobit dvojité přeposlání HTLC po restartu ChannelManager: poprvé, když bylo odchozí HTLC stále v interní frontě, ale nedošlo na něj, a podruhé, když bylo již přeposláno, urovnáno a odstraněno z odchozí fronty, ale příchozí interní fronta pro něj stále měla urovnání. PR dále odstraní příchozí HTLC onion zprávy poté, co jsou definitivně přeposlané.

  • ● HWI #784 přidává do PSBT podporu pro serializaci a deserializaci MuSig2 polí včetně veřejných klíčů účastníků, veřejných noncí a částečných podpisů dle specifikace v BIP327.

  • ● BIPs #2092 přiřazuje zprávě feature jednobajtové ID pro použití s v2 P2P transport protokolem a BIP434. Do BIP324 přidává nový soubor zaznamenávající přiřazená ID napříč BIPy, který by měl vývojářům pomoci vyvarovat se konfliktů. Soubor též zaznamenává navrhovaná přiřazení pro Utreexo.

  • ● BIPs #2004 přidává BIP89 pro Chain Code Delegation (viz zpravodaj č. 364, angl.), mechanismus pro společnou správu prostředků (collaborative custody), kde delegující nesdělí delegovanému BIP32 chain code, avšak sdílí s ním pouze informace nutné pro podepsání; tyto informace nejsou dostatečné pro sledování ostatních adres.

  • ● BIPs #2017 přidává BIP110, který specifikuje dočasný soft fork pro redukci dat (Reduced Data Temporary Softfork, RDTS). Tento návrh má za cíl dočasně, na zhruba jeden rok, konsenzem omezit části transakcí sloužících pro přenos libovolných dat. Pravidla by zneplatnila scriptPubKey překračující 34 bajtů (kromě OP_RETURN s maximálně 83 bajty), pushdata a položky v zásobníku witnessů překračující 256 bajtů, utrácení nedefinovaných witness verzí, přílohy taprootu, kontrolní bloky překračující 257 bajtů, opkódy OP_SUCCESS a OP_IF/OP_NOTIF v tapscriptech. Vstupy utrácející UTXO vytvořená před aktivací mají výjimku. Aktivace používá modifikovaný BIP9 se sníženým 55% prahem signalizace těžařů a povinnou fixací zhruba před zářím 2026. Viz též zpravodaj č. 379 (angl.), který tento návrh již dříve popisoval.

  • ● Bitcoin Inquisition #99 přidává na signet implementaci BIP54, soft forku pročištění konsenzu. Implementuje čtyři opatření: omezuje počet potenciálně spuštěných zastaralých operací nad podpisy (sigops) za každou transakci, zabraňuje útokům ohýbáním času (timewarp attacks) pomocí dvouhodinového přechodného období (společně s nemožností negativních intervalů úpravy složitosti), vyžaduje nastavení časového zámku mincetvorné transakce na výšku bloku a zneplatňuje 64bajtové transakce.

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 17. 2. v 17:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.