Zpravodaj tento týden odkazuje na informace o dlouhodobé deanonymizační zranitelnosti v software používajícím centralizované coinjoinové protokoly a shrnuje aktualizaci návrhu schématu ChillDKG – protokolu distribuovaného generování klíčů kompatibilního s bezskriptovým prahovým podepisováním. Též nechybí naše pravidelné rubriky se souhrnem diskuzí o změnách pravidel bitcoinového konsenzu, 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

  • ● Deanonymizační útoky proti centralizovaným coinjoinům: Yuval Kogman zaslal do emailové skupiny Bitcoin-Dev příspěvek s popisem několika zranitelností, které snižují soukromí účastníků centralizovaných coinjoinových protokolů používaných aktuálními verzemi peněženek Wasabi a Ginger a předchozími verzemi softwarových peněženek Samourai, Sparrow a Trezor Suite. Kogman pomohl navrhnout protokol WabiSabi používaný ve Wasabi a Ginger (viz zpravodaj č. 102, angl.), ale „na protest odešel ještě před jeho vydáním.” V případě zneužití mohou tyto zranitelnosti umožnit centrálním koordinátorům zjistit, který uživatel obdržel které výstupy. Tím by odpadly všechny důvody používání sofistikovaného protokolu nad jednoduchým webovým serverem. Kogman poskytl důkazy, že tyto zranitelnosti byly několika vývojářům peněženek známy několik let. Podobná zranitelnost postihující některé z těchto aplikací byla zmíněna ve zpravodaji č. 333.

  • ● Aktualizace návrhu ChillDKG: Tim Ruffing a Jonas Nick zaslali do emailové skupiny Bitcoin-Dev příspěvek s odkazem na aktuální návrh BIPu na ChillDKG, který popisuje protokol pro distribuované generování klíčů. Protokol je kompatibilní s bitcoinovými bezskriptovými prahovými podpisy FROST. Po svém prvním oznámení (viz zpravodaj č. 312) opravili bezpečnostní zranitelnost, přidali krok, který může odhalit nesprávně fungující účastníky, a zjednodušili provádění záloh a obnov. Změny koordinovali spolu se Sivaramem Dhakshinamoorthym a jeho návrhem na FROST podepisování kompatibilní s bitcoinem (viz zpravodaj č. 315).

Diskuze o změnách konsenzu

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

  • ● Opkódy rozšiřující CTV: vývojář moonsettler zaslal příspěvek do emailové skupiny Bitcoin-Dev i do fóra Delving Bitcoin obsahující návrh na dva nové opkódy pro použití s navrhovaným OP_CHECKTEMPLATEVERIFY:

    • OP_TEMPLATEHASH převádí vybrané části transakce na haš kompatibilní s CTV. Díky tomu mohou zásobníkové operace určit, kolik a které vstupy se mají použít, jaký časový zámek, které hodnoty a skripty výstupů, jaký počet výstupů a které verze transakce.

    • OP_INPUTAMOUNTS umístí do zásobníku hodnotu všech nebo vybraných vstupů v satoshi. Hodnoty potom mohou být použité jako parametr pro OP_TEMPLATEHASH (vyžadující na příklad hodnotu shodnou s výstupem).

    Tyto dva opkódy mohou spolu vytvořit úschovny s podobnými vlastnostmi jako v případě OP_VAULT z BIP345. Opkódy mohou být mimo jiné užitečné pro implementaci odpovědných výpočtů (accountable computing), která by mohla být efektivnější onchain. Diskuze ve fóru Delving Bitcoin v době psaní zpravodaje nadále probíhala.

  • ● Změny složitosti za hranicí 256 bitů: Anders zaslal do emailové skupiny Bitcoin-Dev příspěvek vyjadřující obavy z úprav složitosti proof of work (PoW) za hranicí 256 bitů, které jsou dostupné v hlavičce bloku. Vyžadovalo by to nepředstavitelné navýšení hashrate (zhruba 2176-krát více, než je dostupno nyní), avšak pokud by se tak stalo, mohl by se ve forku přidat sekundární cíl složitosti, jak poznamenává Michael Cassano. Aby byl blok validní, musely by být naplněny oba cíle. Tento způsob je podobný návrhu na obranu před útokem zadržováním bloků (viz zpravodaj č. 315). Tyto druhy forků, včetně návrhů jako dopředné bloky (forward blocks, viz zpravodaj č. 16, angl.), jsou sice technicky vzato soft forky, jelikož pouze upevňují stávající pravidla, avšak někteří vývojáři od tohoto označení odrazují, neboť kvůli nim mohou neaktualizované plné uzly a potenciálně i všechny lehké (SPV) klienty snadno uvěřit, že má nějaká transakce stovky či tisíce potvrzení, ačkoliv nemá ve skutečnosti žádné nebo je v konfliktu s jinou, již potvrzenou transakcí.

  • ● Přechodné soft forky pro čistící soft forky: Jeremy Rubin zaslal do fóra Delving Bitcoin příspěvek o pouze dočasném aplikování pravidel konsenzu navržených k zabraňování nebo opravě zranitelností. Myšlenka byla již dříve navržena pro soft forky, které přidávají nové funkce (viz zpravodaj č. 197, angl.), avšak nesetkal se s podporou zastánců nových funkcí ani nezaujatých členů komunity. Rubin navrhuje, že by se tato myšlenka lépe aplikovala na soft forky, které se pokouší opravit zranitelnosti, ale u kterých hrozí, že by mohly neúmyslně zabránit uživatelům v utracení svých bitcoinů (tzv. hrozba konfiskace) nebo omezit schopnost snadno opravit budoucí zranitelnosti. David Harding projevil názor, že myšlenka dočasných soft forků se nesetkala s podporou, protože ani zastánci ani nezaujatí členové nebyli ochotní se každých pár let účastnit dohadů o změně konsenzu. Tato námitka platí bez ohledu na to, zda změna přidává funkce nebo adresuje zranitelnosti.

  • ● Jak upgradovat pro kvantové počítače: Matt Corallo zaslal do emailové skupiny Bitcoin-Dev příspěvek o přidání kvantově odolného opkódu do tapscriptu pro validaci podpisů, který by umožnil utratit prostředky, i kdyby byly operace pracující s ECDSA a Schnorrovými podpisy deaktivovány kvůli hrozbě tvorby padělků rychlými kvantovými počítači. Luke Dashjr poznamenal, že soft fork není v současné době nezbytný, pokud existuje všeobecný souhlas, jak bude kvantově odolný opkód v budoucnosti fungovat. Uživatelé se k němu pouze potřebují zavázat jako k možnosti, která se může v budoucnosti stát dostupnou. Tadge Dryja navrhl přechodný soft fork, který by dočasně omezil používání kvantově neodolných ECDSA a Schnorrových podpisů, pokud by se zdálo, že by kvantové počítače byly blízko schopnosti ukrást bitcoiny. Pokud by poté někdo splnil onchain hádanku, která by byla řešitelná pouze kvantovým počítačem (nebo díky objevu fundamentální kryptografické zranitelnosti), přechodný soft fork by se automaticky mohl stát trvalým. V opačném případě by mohl být přechodný soft fork obnoven nebo ukončen (čímž by byly bitcoiny chráněné ECDSA nebo Schnorrem opět utratitelné).

  • ● Přechodné období proti ohýbání času v rámci pročištění konsenzu: Sjors Provoost zaslal do fóra Delving Bitcoin příspěvek s připomínkou k návrhu, aby soft fork pročištění konsenzu bránil útoku ohýbáním času tím, že by zakázal prvnímu bloku nové periody mít časové razítko více než 600 sekund před posledním blokem předchozí periody. Provoost se obává, že by poctivý těžař, který používá modifikace časového razítka k rozšíření prostoru nonce (tzv. time rolling), mohl neúmyslně vyprodukovat blok, který uzly s pomalými hodinami nemusí ihned přijmout. Tím by se zpomalila propagace tohoto bloku v porovnání s konkurenčními bloky s méně variabilními časovými razítky vyprodukovanými ve stejné době. Pokud by konkurenční blok zůstal v nejlepším řetězci, přišel by těžař s time rollingem o odměnu. Provoost namísto toho navrhuje méně omezující limity, na příklad zákaz na časové razítko jdoucí více než 7 200 sekund (dvě hodiny) do minulosti. Antoine Poinsot volbu 600 sekund obhajuje jako vyhýbající se všem známým problémům a poskytující nejsilnější obranu proti ohýbání času v budoucnosti.

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.

  • ● BDK wallet-1.0.0 je prvním hlavním vydáním této knihovny pro budování bitcoinových peněženek a jiných podobných aplikací. Původní rustový balíček bdk byl přejmenován na bdk_wallet (jeho API by mělo být stabilizované). Nižší vrstvy byly extrahovány do balíčků bdk_chain, bdk_electrum, bdk_esplora a bdk_bitcoind_rpc.

  • ● LND 0.18.4-beta je menším vydáním této oblíbené implementace LN, které „vedle funkcí pro budování nastavitelných kanálů přináší obvyklé opravy chyb a navýšení stability.”

  • ● Core Lightning v24.11.1 je menším vydáním, které zlepšuje kompatibilitu mezi experimentálním pluginem xpay a starším RPC příkazem pay. Též přináší několik vylepšení pro uživatele xpay.

  • ● Bitcoin Core 28.1rc2 je kandidátem na vydání údržbové verze této převládající implementace plného uzlu.

  • ● LDK v0.1.0-beta1 je kandidátem na vydání této knihovny pro budování peněženek a aplikací s podporou LN.

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 #31223 mění způsob, kterým uzel odvozuje P2P port torové onion služby (viz zpravodaj č. 118, angl.). Nově bude namísto 8334 používat hodnotu o jedna vyšší, než kolik je specifikováno volbou -port (pokud je poskytnuta). Řeší tím problém, kdy se více místních uzlů snažilo poslouchat na portu 8334, čímž došlo z důvodu kolize k pádu. Kolize může i nadále nastat, pokud jsou dvěma místním uzlům pomocí -port předány po sobě jdoucí hodnoty. Obecně je však moudré se takovým případům vyhýbat.

  • ● Eclair #2888 přidává podporu pro protokol peer storage dle specifikace v BOLTs #1110. Protokol umožňuje uzlům na žádost ukládat zašifrované zálohy (ve výchozím nastavení až 65 kB) svých protistran. Tato funkcionalita je zamýšlena pro poskytovatele lightningových služeb (LSP) obsluhujících mobilní peněženky. Má konfigurovatelné nastavení, které provozovatelům umožňuje určit dobu uložení dat. Po CLN (viz zpravodaj č. 238) je Eclair druhou implementací s podporou tohoto protokolu.

  • ● LDK #3495 zpřesňuje model vyhodnocující historickou pravděpodobnost úspěšného nalezení cesty v LN vylepšením hustoty pravděpodobnosti a souvisejících parametrů na základě reálných dat sesbíraných sondami. Změna sbližuje historické a a priori modely se skutečným světem a vylepšuje výchozí hodnoty trestů a hledání cest.

  • ● LDK #3436 přesouvá balíček lightning-liquidity do repozitáře rust-lightning. Balíček poskytuje typy a primitiva pro integraci LDK uzlu s LSP.

  • ● LDK #3435 přidává do kontextu zaslepených cest pole, do kterého může plátce přidat autentizační kód zprávy založený na haši (HMAC) spolu s noncem, díky kterým může příjemce odesílatele autentizovat. Opravuje tím problém, kdy mohl útočník vzít payment_secret z BOLT11 faktury vydané uzlem oběti a zfalšovat platbu, i když částka neodpovídala nabídce. Změna také pomůže zabránit deanonymizačním útokům používajícím stejnou techniku.

  • ● LDK #3365 zajistí, aby byl holder_commitment_point při upgradech označen jako Available namísto zanechání jej v předchozím stavu PendingNext. Změna zabraňuje vynuceným uzavřením kanálu během upgradů uzlu, kdy uzel obdrží zprávu commitment_signed, která vyžaduje, aby byl příští commitment point (bod na eliptické křivce sloužící pro odvozování commitmentů) dostupný.

  • ● LDK #3340 přináší dávkování onchain nárokujících transakcí s výstupy, které mohou být obětí pinningu. Tím lze dosáhnout redukce použitého blokového prostoru a poplatků během vynuceného zavření kanálu. Dříve byly výstupy dávkované pouze, pokud je mohl uzel nárokovat exkluzivně, tedy pokud nemohlo dojít k pinningu. Nově je každý výstup, který může protistrana utratit do 12 bloků, považován za možný cíl pinningu a je dávkován, pokud mohou být časové zámky jejich HTLC zkombinované.

  • ● BDK #1670 přináší nový lineární algoritmus kanonizace transakcí. Identifikuje kanonické transakce a odstraňuje z peněženky nepotvrzené konfliktní transakce, které se zřejmě nepotvrdí. Algoritmus nahrazuje starší, kvadratickou metodu get_chain_position, která může v některých případech představovat riziko DoS.

  • ● BIPs #1689 začleňuje BIP374 specifikující standardní způsob generování a ověřování dokladů rovnosti diskrétních logaritmů (Discrete Log Equality Proofs, DLEQ) nad eliptickou křivkou secp256k1. Motivací BIPu je možnost vytvářet tiché platby s několika nezávislými podepisujícími entitami. DLEQ umožní všem podepisujícím doložit, že je jejich podpis validní a nepředstavuje hrozbu ztráty prostředků.

  • ● BIPs #1697 přidává do BIP388 podporu pro MuSig úpravou gramatiky šablon deskriptorů výstupních skriptů.

  • ● BLIPs #52 přidává BLIP50 specifikující protokol pro komunikaci mezi LSP a jejími klienty. Zprávy jsou přenášené v rámci JSON-RPC pomocí peer-to-peer zpráv dle BOLT8. Jedná se o součást sady BLIPů pocházejících z repozitáře specifikace LSP. Jsou považovány za stabilní, neboť jsou nasazeny v produkci u několika LSP a v implementacích klientů.

  • ● BLIPs #54 přidává BLIP52 specifikující protokol pro JIT kanály, které umožňují klientům bez LN kanálů začít přijímat platby. Když LSP přijme příchozí platbu, otevře ke klientovi kanál, jehož náklady na otevření jsou odečteny z první platby. Jedná se též o součást sady BLIPů pocházejících z repozitáře specifikace LSP.