Zpravodaj tento týden shrnuje nápady na kvantové zabezpečení šifrovaného přenosu dle BIP324 a popisuje návrh na standardizaci podepisování pomocí QR kódů pro miniscriptové peněženky. Též nechybí naše pravidelné rubriky se souhrnem návrhů a diskuzí o změnách pravidel bitcoinového 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

  • ● Kudy k postkvantovému BIP324: Olaoluwa Osuntokun zaslal do emailové skupiny Bitcoin-Dev příspěvek s úvahou o možných změnách BIP324 pro navýšení kvantové bezpečnosti. BIP324 přinesl do P2P protokolu šifrovaný přenos, čímž uživatelům během výměny zpráv zlepšuje zabezpečení a soukromí. Je navržen tak, aby úvodní navázání spojení i celkový provoz vypadaly pro vnější pozorovatele k nerozeznání od náhodných dat. Dle Osuntokuna nevyžaduje změna P2P protokolu širokou shodu jako změna konsenzu, mohlo by se tedy jednat o snazší první krok na cestě ke kvantově bezpečnému bitcoinu.

    Před návrhem formálního BIPu vyzval Osuntokun k diskuzi o dvou hlavních návrhových bodech. První z nich se týká výběru mechanismu zapouzdření klíče (Key-Encapsulation Mechanism, KEM): buď hybridní, nebo čistě postkvantový. Oba jsou založené na novém primitivu nazývaném modulový mřížkový KEM (Module-Lattice-based KEM, ML-KEM). Druhý návrhový bod řeší otázku, zda by mělo být úvodní navázání spojení i nadále nerozeznatelné od náhodných dat.

    K prvnímu bodu autor tvrdí, že hybridní přístup (kombinace současného ECDH a ML-KEM) by mohl nabídnout lepší záruky, jelikož by poskytoval ochranu i v případě, kdyby byl jeden z těchto dvou algoritmů prolomen. I když by ECDH mohl být prolomen budoucím kryptoanalyticky relevantním kvantovým počítačem (Cryptographically Relevant Quantum Computer, CRQC), kvantově bezpečné algoritmy ještě nejsou osvědčené širokým nasazením a mohly by obsahovat matematické slabiny.

    Ke druhému bodu Osuntokun poskytl možné alternativy, pokud bude potřeba zachovat nerozlišitelnost navázání spojení od náhodných dat. Prvním přístupem by bylo používat současné BIP324 navázání k otevření klasického kanálu, kterým by mohly strany vyjednat postkvantový kanál. Druhý přístup je založen na principu Outer Encrypts Inner Nested Combiner (OEINC), kde vnější KEM by šifroval jiný, vnitřní KEM, čímž by přinesl postkvantový kanál v jediném kroku.

  • ● Diskuze o podepisování QR kódem pro miniscriptové peněženky: Pyth zaslal do fóra Delving Bitcoin příspěvek s návrhem na standardizaci formátu dat vyměňovaných mezi peněženkami a odpojenými podpisovými zařízeními pomocí QR kódů, pokud jsou používána miniscriptová pravidla utrácení. I když stávající protokoly používající QR kódy zvládnou standardní m z n vícenásobné podpisy, pravidla miniscriptu vyžadují schopnosti, které současná schémata nenabízí. Jeho návrh definuje druh přenášených dat pro získávání xpub, registraci deskriptoru, ověřování adres a podepisování. Pyth žádá o poskytnutí zpětné vazby od vývojářů podpisových zařízení a peněženek.

Diskuze o změnách konsenzu

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

  • ● Ověření konceptu úschovny vyžadující pouze CTV: Ademan ve fóru Delving Bitcoin ohlásil vydání verze 0.1.0 jeho projektu úschoven s CTV (BIP119) nazvaného MCCV (More Complicated CTV Vault). MCCV implementuje několik přístupů budování plnohodnotných úschoven (komplexnějších než simple-ctv-vault od Jamese O’Beirna, viz též zpravodaj č. 191, angl.) bez nutnosti složitějších opkódů jako OP_VAULT (BIP345) nebo OP_CHECKCONTRACTVERIFY (BIP443). Konkrétně MCCV používá orientovaný acyklický graf (DAG) CTV transakcí pro vytvoření úschovny s jediným UTXO. To může existovat během mnoha interakcí předtím, než je ho nakonec možné utratit použitím klíčů pro obnovu (recovery). MCCV implementuje řízení četnosti požadavků (rate limiting) pomocí taprootového stromu všech možných skriptů pro vybrání z úschovny, každý s vlastní hodnotou a časovým zámkem. Ve stromu skriptů jsou též CTV haše pro vkládání, které umožní do úschovny přidat dodatečné prostředky o různých hodnotách. MCCV se vyhýbá základním problémům kombinování vstupů z úschoven, které BIPy 345 a 443 pomáhají řešit, tím, že používá pouze jediné UTXO, které je rozšiřováno nebo zužováno, namísto používání více UTXO. Jako u všech návrhů CTV úschoven, i u MCCV musí být částky pro výběry i vklady předem přesně určené a vyjmenované během vytváření (BIPy 345 a 443 tuto podmínku nemají). Řízení četnosti požadavků není zcela možné u úschoven s více UTXO. MCCV může být též implementováno s OP_TEMPLATEHASH (BIP446).

  • ● Diskuze o postkvantové Lightning Network: Olaoluwa Osuntokun (roasbeef) zaslal do fóra Delving Bitcoin příspěvek zobrazující, jak by mohla postkvantová Lightning Network vypadat na jednotlivých vrstvách. Osuntokun vyjmenovává dostupné postkvantové kryptosystémy a spojuje je s vrstvami Lightning Network a potřebnými kryptografickými primitivy. Postkvantová LN by si mohla zachovat svou celkovou strukturu, ale zřejmě se bude muset vzdát jediného klíče uzlu, na který v současnosti spoléhá. Žádný postkvantový kryptosystém ani klíč by nebyl schopen nabídnout všechna požadovaná primitiva. Osuntokun zjistil, že pro určité funkce LN, včetně výměny klíčů, se nejlépe hodí kryptografie založená na mřížkách. Dále poznamenává, že kvůli velikosti postkvantových kryptografických prvků by zřejmě dávalo smysl nadále paralelně používat kryptografii založenou na eliptických křivkách pro případ, že by se v postkvantových schématech objevily zranitelnosti.

  • ● Teorie her kvantového útoku: Jameson Lopp zaslal do fóra Delving Bitcoin příspěvek o svém blogovém příspěvku popisujícím teorii her kvantových útoků. Lopp popisuje potenciální podněty a činy různých účastníků trhu v případě zkonstruování kvantového počítače, který by mohl z veřejných klíčů odhalit soukromé. Scénáře, které popisuje, jsou nepředvídatelné, neboť kvantoví útočníci mohou rychle získat přístup k velkým částkám bitcoinu bez nutnosti vynaložit práci a kapitál, s nimiž jsou jiní držitelé svázáni.

  • ● BIP54 a 64bajtové transakce s možnými legitimními důvody používání: Jeremy Rubin zaslal do emailové skupiny Bitcoin-Dev příspěvek o možném legitimním důvodu používání 64bajtových transakcí bez započítaných witnessů. Návrh pročištění konsenzu (BIP54) přináší zneplatnění 64bajtových transakcí bez započítaných witnessů. Tato změna má za cíl znemožnit určitou skupinu zranitelností Merkleova stromu a tím navýšit bezpečnost zjednodušených ověření plateb či podobných schémat pro ověřování plateb založených na hlavičkách. Jelikož mohou mít 64bajtové transakce nejvýš jeden vstup a jeden výstup utratitelný kýmkoliv, považovali je autoři BIP54 za nehodné ochrany. Rubin navrhuje několik potenciálních scénářů, kde by současné nebo budoucí protokoly mohly takové transakce používat.

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.

  • ● Core Lightning 26.06 je vydání hlavní verze této oblíbené implementace LN uzlu. Obsahuje nová RPC volání graceful, sendamount a xkeysend, započíná cyklus zastarání příkazu pay ve prospěch xpay a přidává podporu pro BOLT12 dokladů o platbě. Seznam změn obsahuje další podrobnosti.

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 #35269 opravuje podepisování PSBT s MuSig2. Nově přidává do interního identifikátoru sezení MuSig2 procesu veřejná nonce každého účastníka. Dříve mohlo volání walletprocesspsbt více než jednou nad stejným PSBT bez noncí generovat nová veřejná nonce se stejným interním identifikátorem sezení, což vyvolalo assert kontrolu, která měla opakovanému používání noncí zabránit. Nový identifikátor sezení i nadále vyvolá assert kontrolu v případě opakovaného použití noncí, čímž napomůže zabránit úniku soukromého klíče.

  • ● Bitcoin Core #34644 přidává do IPC rozhraní Mining (viz zpravodaje č. 310 a č. 323) metodu submitBlock, která umožní klientům Stratum v2 odeslat kompletní blok pro validaci a další zpracování. Tato metoda je užitečná pro případy, kdy Stratum v2 obdrží již vyřešený blok, pro který nemá Bitcoin Core odpovídající objekt BlockTemplate, a stávající metoda submitSolution je tudíž nedostatečná (viz též zpravodaj č. 325). Nová metoda je podobná RPC volání submitblock, avšak vrací booleovskou hodnotu a popis případného odmítnutí (duplikovaný, nevalidní či neprůkazný blok). Na rozdíl od RPC volání musí být v případě IPC odeslán kompletní blok včetně witnessu mincetvorné transakce, pokud je přítomen i commitment witnessů.

  • ● Bitcoin Core #34198 opravuje chybu migrace postihující velmi staré peněženky vytvořené předtím, než peněženky začaly v roce 2011 ukládat záznamy o nejlepším bloku. Nově je možné migrovat peněženky, které tento záznam postrádají, na deskriptorovou peněženku, avšak pro dokončení migrace je potřeba proskenovat celý řetězec.

  • ● LND #10813 odstraňuje podporu pro vytváření Tor v2 onion služeb, které byly zastarané ve verzi LND 0.20 (viz zpravodaj č. 375, angl.). Zastaraná volba tor.v2 je odstraněna, avšak v2 adresy jsou v oznámeních zachovány, aby mohly být stávající gossip zprávy nadále ověřované a přeposílané. Tor v2 onion služby jsou od října 2021 nahrazené Tor v3.

  • ● Rust Bitcoin #6250 počíná ověřovat, že vstup mincetvorné transakce rezervuje 32 bajtů pro witness, pokud transakce také obsahuje commitment witnessů. Tím získává validace bloků v rust-bitcoin soulad s BIP141. Dříve rust-bitcoin provedl tuto kontrolu jen tehdy, pokud blok obsahoval další segwitové transakce. Mohl tedy přijmout blok s commitmentem witnessů v mincetvorné transakci, avšak bez rezervovaných bajtů pro witness mincetvorné transakce.

  • ● BOLTs #1338 přidává do BOLT2 požadavek, aby uzly čekaly alespoň sto bloků před odesláním channel_ready, pokud je otevírací transakce kanálu mincetvornou transakcí. Tím zabraňuje těžařům v používání nezralých výstupů k otevření LN kanálu.

  • ● BOLTs #1326 umožňuje v BOLT4 i koncovým uzlům, a ne jen přeposílajícím, aby vrátily chyby invalid_onion_version, invalid_onion_hmac nebo invalid_onion_key. Dříve byly tyto chyby nesprávně umístěny pod pravidlem, že je koncové uzly nesmí používat. PR dále objasňuje, že přeposílající uzly nesmí zpracovávat již zaplacené platební haše jako koncové uzly.

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