Zpravodaj tento týden popisuje, jak může identifikace peněženek narušovat soukromí payjoinu, a shrnuje návrh na formát metadat záloh peněženek. Též nechybí naše pravidelné rubriky se souhrnem návrhů a diskuzí o změnách pravidel konsenzu, s oznámeními nových vydání a s popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Riziko identifikace peněženky použité pro payjoin: Armin Sabouri zaslal do fóra Delving Bitcoin příspěvek popisující, jak rozdíly mezi implementacemi payjoinu umožňují detekovat payjoinové transakce a mohou tak narušit jejich soukromí.

    Sabouri tvrdí, že i když by payjoinové transakce měly být nerozeznatelné od běžných transakcí, mohou obsahovat stopy po spolupráci mezi více účastníky:

    • V rámci transakce

      • Řadí vstupy a výstupy dle vlastníka.

      • Rozdíly v kódování vstupů.

      • Velikost vstupů v bajtech.

    • Mezi transakcemi

      • Zpětně: Každý vstup byl vytvořen předchozí transakcí, která nese své vlastní charakteristiky.

      • Dopředně: Každý výstup může být utracen budoucí transakcí, která charakteristiky odhalí.

    Dále prozkoumal tři implementace payjoinu: Samourai, demo PDK a Cake Wallet (posílající do Bull Bitcoin Mobile). V každém z těchto příkladů nalezl několik odlišností, které umožňují odhalit použitou implementaci. Mezi těmito znaky byly například:

    • Rozdíly v kódování podpisů vstupů.

    • SIGHASH_ALL bajt v jednom vstupu, ale ne v ostatních.

    • Volba výstupní hodnoty.

    Sabouri uzavírá tvrzením, že některé z těchto charakteristik peněženek je možné snadno odstranit, jiné jsou svázané s designem peněženky. Vývojáři peněženek by si měli být během přidávání podpory pro payjoin do svých peněženek těchto vlastností vědomi.

Diskuze o změnách konsenzu

Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel bitcoinového konsenzu.

  • ● Úsporné izogenní PQC může nahradit hierarchické peněženky, tweakování klíčů, tiché platby: Conduition zaslal do fóra Delving Bitcoin příspěvek o svém výzkumu udržitelnosti kryptografie založené na izogenii (Isogeny-Based Cryptography, IBC) jako postkvantového kryptografického systému pro bitcoin. I když problém diskrétního logaritmu nad eliptickými křivkami se může v postkvantovém světě stát nezabezpečeným, obecně není na matematice eliptických křivek nic rozbitého. Ve stručnosti je izogenie funkcí z jedné eliptické křivky na jinou. IBC předpokládá, že je obtížné vypočítat izogenii mezi jednou eliptickou křivkou určitého druhu a jednou další. Vytvořit izogenii a křivku, na kterou mapuje, je však snadné. Tajné klíče v IBC jsou tak izogenie a veřejné klíče jsou křivky, na které mapuje.

    Je možné, stejně jako u ECDLP, spočítat nové soukromé a veřejné klíče nezávisle ze stejné soli (např. BIP32 derivací) a řádně podepsat výsledným soukromým klíčem pro výsledný veřejný klíč. Tato vlastnost, kterou Conduition nazývá opakovanou randomizací (rerandomization), umožňuje BIP32, BIP341 a BIP352 (pravděpodobně spolu s některými dalšími kryptografickými inovacemi).

    Zatím neexistují pro IBC žádné protokoly agregace podpisů, jako jsou MuSig či FROST, proto conduition vyzývá bitcoinové vývojáře, aby prozkoumali možnosti.

    Klíče a podpisy ve známých IBC systémech jsou zhruba dvakrát větší než klíče v ECDLP systémech a mnohem menší než systémy založené na hašování nebo mřížkové kryptografii. Ověřování je nákladné i na desktopových počítačích (v řádu jedné milisekundy na jedno ověření), podobně jako u hašování nebo mřížkové kryptografie.

  • ● Rozpočet varops operací a tapscriptový list 0xc2 („skriptové obrození”) mají BIP 440 a 441: Rusty Russell zaslal do emailové skupiny Bitcoin-Dev zprávu, že byly odeslány k očíslování první dva BIPy velkého skriptového obrození (GSR, Great Script Restoration či Grand Script Renaissance). Následně obdržely čísla 440 a 441. BIP440 obnovuje dříve deaktivované opkódy. Díky systému pro hlídání nákladů každé varops operace (opkód, jehož náklady závisí na velikosti vstupu) je zaručeno, že náklady na validaci skriptů v bloku nepřekročí náklady na validaci bloku obsahujícího nejvyšší možný počet operací s podpisy. BIP441 popisuje validaci nové verze tapscriptu, která obnovuje opkódy deaktivované Satoshim v roce 2010.

  • ● SHRIMPS: postkvantový podpis s 2,5 kB napříč více zařízení se stavem: Jonas Nick zaslal do fóra Delving Bitcoin příspěvek o novém konstruktu podpisů pro postkvantový bitcoin založeném na hašování a částečném stavu. SHRIMPS využívá skutečnosti, že velikost podpisů SPHINCS+ je úměrná maximálnímu počtu podpisů pro daný klíč, které mohou být vytvořeny při zachování dané úrovně zabezpečení.

    Podobně jako SHRINCS se i SHRIMPS klíče sestávají ze dvou klíčů zahašovaných dohromady. V tomto případě jsou oba klíče bezstavovými SPHINCS+ klíči, avšak s různými parametry. První klíč je bezpečný pouze pro malý počet podpisů a je proto určený pro první podpis (nebo pár prvních podpisů) každého podpisového zařízení, které tento klíč používá. Druhý klíč je bezpečný pro mnohem větší počet podpisů (v bitcoinu v podstatě neomezený) a každé zařízení ho začne používat po určitém počtu (potenciálně zvoleném uživatelem) podpisů z tohoto zařízení. V důsledku tak v běžném případě, kde každý klíč (kterých může být z jednoho seedu generováno mnoho) podepisuje pouze párkrát, mohou téměř všechny podpisy mít méně než 2,5 kB, a přitom nemusí být jejich počet omezen ani v případě mnohonásobného opakovaného použití za cenu velikosti kolem 7,5 kB. SHRIMPS má částečný stav v tom smyslu, že sice není nutné udržovat globální stav, ale každé podpisové zařízení musí ukládat pár bitů stavu pro každý klíč, se kterým podepisuje (a jen jediný bit, pokud pouze první podpis každého klíče ze zařízení využívá výhody malých podpisů).

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 31.0rc2 je kandidátem na vydání příští hlavní verze této převládající implementace plného uzlu. Dostupný je průvodce testováním.

  • ● Core Lightning 26.04rc2 je kandidátem na vydání příští hlavní verze této populární implementace LN uzlu. Přináší další aktualizace splicingu a opravuje chyby z předchozích kandidátů.

  • ● BTCPay Server 2.3.7 je menším vydáním tohoto platebního procesoru s možností vlastního hostování. Migruje projekt na .NET 10, zlepšuje předplatné a platby fakturami a přidává několik dalších vylepšení a oprav chyb. Vývojáři rozšíření by měli následovat průvodce migrace na .NET 10.

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 #32297 přidává do bitcoin-cli volbu -ipcconnect, aby se mohl připojit a ovládat bitcoin-node instanci přes meziprocesovou komunikaci (IPC) přes unixový soket namísto HTTP, pokud je Bitcoin Core sestaven s příznakem ENABLE_IPC a uzel je spuštěn s -ipcbind (viz též zpravodaje č. 320 a č. 369, angl.). I když je volba -ipcconnect vynechána, zkusí bitcoin-cli nejdřív použít IPC. Pokud není dostupné, použije HTTP. Jedná se o součást projektu oddělení do více procesů.

  • ● Bitcoin Core #34379 opravuje chybu způsobující selhání, pokud bylo RPC gethdkeys (viz zpravodaj č. 297) voláno s private=true a pokud peněženka obsahovala nějaký deskriptor, pro který měla jen některé, ale ne všechny soukromé klíče. Podobně jako oprava pro listdescriptors (zpravodaj č. 389) i toto PR vrací dostupné soukromé klíče. Volání gethdkeys private=true nad peněženkami pouze pro čtení nadále selhává.

  • ● Eclair #3269 přidává automatické znovuzískání likvidity z nečinného kanálu. Když PeerScorer zjistí, že celkový objem plateb kanálu spadne v obou směrech pod 5 % jeho kapacity, postupně sníží jeho poplatky za přeposílání směrem k nastavenému minimu. Pokud jsou poplatky v minimu nejméně pět dní a objem nezačne růst, Eclair tento kanál zavře, pokud je pro peer spojení nadbytečný. Kanály jsou zavřeny pouze, pokud uzel drží alespoň 25 % prostředků a místní zůstatek převyšuje existující nastavení localBalanceClosingThreshold.

  • ● LDK #4486 začleňuje rbf_channel do splice_channel jako jediného styčného bodu pro vytváření nových spliců a pro navyšování poplatků pro stávající. Pokud splice již probíhá, návratová hodnota FundingTemplate ze splice_channel vrací PriorContribution, aby mohli uživatelé navýšit poplatek splicu bez výběru mincí. Viz též zpravodaj č. 397 pro související chování RBF během splicingu.

  • ● LDK #4428 přidává podporu pro otevírání a přijímání kanálů s nulovou rezervou pro důvěryhodná peer spojení pomocí nové metody create_channel_to_trusted_peer_0reserve. Kanály s nulovou rezervou umožňují protistraně kompletně utratit zůstatek kanálu. Je to umožněno pro kanály s anchor výstupy i pro kanály s commitmenty bez poplatků (viz zpravodaj č. 371, angl.).

  • ● LND #9982, #10650 a #10693 zlepšují nakládání s MuSig2 noncemi u taprootových kanálů: do ChannelReestablish přidává pole LocalNonces, aby mohla spojení koordinovat více noncí u aktualizací souvisejících se splicingem. lnwire validuje veřejné MuSig2 nonce během dekódování TLV u zpráv, které nonce přenášejí, a dekódování LocalNoncesData validuje každý vstup.

  • ● LND #10063 rozšiřuje kooperativní zavření kanálu s RBF na jednoduché taprootové kanály použitím MuSig2. Zprávy přenášejí nonce a částečné podpisy specifické pro taproot a stavový automat používá MuSig2 sezení s just-in-time noncemi pro shutdown, closing_complete a closing_sig (viz též zpravodaj č. 347, který popisuje pozadí kooperativního zavření s RBF).