Zpravodaj tento týden přináší souhrn diskuze o proti-exfiltračnímu protokolu, který vyžaduje pouze jedno kolo komunikace mezi peněženkou a podpisovým zařízením. Též nechybí naše pravidelné rubriky s popisem změn v klientech a službách, oznámeními nových vydání a souhrnem nedávných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Jednoduchý (ale nedokonalý) proti-exfiltrační protokol: vývojář Moonsettler zaslal do fóra Delving Bitcoin příspěvek s popisem proti-exfiltračního protokolu. Shodný protokol byl již dříve popsán (viz zpravodaje č. 87 a č. 88, oba angl.), Pieter Wuille odkázal na první známý popis této techniky uvedený v příspěvku Gregoryho Maxwella z roku 2014.

    Protokol používá sign-to-contract, který umožňuje softwarové peněžence přispět entropií do nonce vybraného hardwarovým podpisovým zařízením způsobem, který později softwarové peněžence umožní ověřit, zda tato entropie byla použita. Sign-to-contract je variantou pay-to-contract: u pay-to-contract je tweaknutý veřejný klíč příjemce, u sign-to-contract je tweaknutý nonce podpisu plátce.

    Výhodou tohoto protokolu v porovnání s protokolem implementovaným v hardwarových podpisových zařízeních BitBox02 a Jade (viz zpravodaj č. 136, angl.) je potřeba pouze jediného kola komunikace mezi softwarovou peněženkou a hardwarovým podpisovým zařízením. Toto jedno kolo může být zkombinováno s jinými procesy potřebnými pro podepsání transakce, na obvyklé postupy uživatelů tak tato technika nemá žádný dopad. Aktuálně nasazená technika, která je též založená na sign-to-contract, vyžaduje dvě kola komunikace. To je více, než kolik dnes většina uživatelů vyžaduje, ačkoliv více kol komunikace může být vyžadováno pro uživatele, kteří upgradují na bezskriptové vícenásobné podpisy a bezskriptové prahové podpisy. Pro uživatele, kteří připojují svá podpisová zařízení k počítačům přímo či pomocí bezdrátových protokolů jako Bluetooth, počet kol komunikace nehraje roli. Avšak pro uživatele, kteří zařízení připojovat nechtějí, znamená každé další kolo dva ruční zásahy. To se může rychle proměnit v nepříjemné množství práce, pokud podepisují často nebo používají více zařízení pro skriptové vícenásobné podpisy.

    Nevýhodu tohoto protokolu zmínil Maxwell ve svém původním popisu: „ponechává otevřený postranní kanál, který má exponenciální náklady za každý další bit, použitím obrušování (grinding)[…], ale odstraňuje zjevné a hodně účinné útoky, kde všechno unikne v jediném podpisu. Je to jistě méně dobré, ale jedná se pouze o dvoukolový protokol, takže hodně míst, která by nad protiopatřeními neuvažovala, by mohla tohle bez práce převzít jako jeden bod ve specifikaci protokolu.”

    Použití tohoto protokolu má jasné výhody oproti nepoužívání žádné anti-exfiltrace. Pieter Wuille dále poznamenává, že se možná jedná o nejlepší možnou anti-exfiltraci s jedním kolem podepisování. Avšak Wuille obhajuje nasazený dvoukolový proti-exfiltrační protokol, který umí zabránit i exfiltraci založené na obrušování.

    Diskuze v době psaní nadále probíhá.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

  • ● Ohlášena Proton Wallet: Proton ohlásil svou open-source Proton Wallet s podporou více peněženek, bech32, dávkových plateb, BIP39 frází a s integrací svého emailu.

  • ● Ohlášen testnet CPUNet: Přispěvatel z braidpool, implementace těžebního poolu, ohlásil testovací síť CPUNet. Uživatelé CPUNet používají modifikovaný proof of work, který vylučuje těžaře s ASIC. Záměrem je dosáhnout konzistentnější míry tvorby bloků, než je pro testnet typické.

  • ● Spuštěn Lightning.Pub: Lightning.Pub poskytuje správu LND uzlu, která umožňuje sdílený přístup a koordinaci likvidity kanálů. Pro šifrovanou komunikaci a identity založené na klíčích používá nostr.

  • ● Vydán Taproot Assets v0.4.0-alpha: Vydání v0.4.0-alpha podporuje protokol Taproot Assets na mainnetu, kde umí vydávat onchain aktiva a provádět atomické směny pomocí PSBT, a posílání aktiv přes Lightning Network.

  • ● Vydán nástroj pro měření výkonnosti Stratum v2: První vydání 0.1.0 podporuje testování, reportování a porovnávání výkonu mezi protokoly Stratum v1 a Stratum v2 v různých scénářích.

  • ● Ověření konceptu STARK verifikací na signetu: StarkWare ohlásil STARK verifier ověřující důkazy s nulovou znalostí na testovací síti signet pomocí opkódu OP_CAT (viz zpravodaj č. 304).

  • ● Vydán SeedSigner 0.8.0: Bitcoinové hardwarové podpisové zařízení SeedSigner přidalo ve vydání 0.8.0 podepisování P2PKH a P2SH multisig, rozšířilo podporu PSBT a aktivovalo podporu taprootu ve výchozím nastavení.

  • ● Vydána Floresta 0.6.0: Ve vydání 0.6.0 přidává Floresta podporu pro filtry kompaktních bloků, doklady o podvodu na signetu a florestad, démon pro integraci existujících peněženek a klientských aplikací.

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.

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 #28553 přidává parametry mainnetového bloku 840 000 do assumeUTXO snapshotu: haš bloku, počet transakcí až po tento blok a SHA256 haš serializované množiny UTXO až po tento blok. Několik přispěvatelů testováním potvrdilo, že dosáhli stejného souboru snapshotu s očekávaným kontrolním součtem a že tento snapshot bylo možné načíst.

  • ● Bitcoin Core #30246 přidává do nástroje asmap-tool podpříkaz diff_addrs, který uživatelům umožní porovnat dvě mapy autonomních systémů (ASMap) a spočítat statistky o adresách uzlů, které byly přiřazeny do jiných čísel autonomních systémů (Autonomous System Number, ASN). Tato funkce měří degradaci ASMap během času, což je důležitým krokem na cestě k přibalení předem spočítaných ASMap do vydání Bitcoin Core. Účelem je zvýšení odolnosti vůči útokům zastíněním. Viz též zpravodaj č. 290.

  • ● Bitcoin Core GUI #824 mění položku menu Migrate Wallet na podmenu, což uživatelům umožní migrovat kteroukoliv zastaralou peněženku v adresáři, včetně takových, které již není možné načíst. Tato změna je přípravou na možnou budoucnost, kdy budou používány pouze deskriptorové peněženky a staré typy peněženek nebude možné načíst. Po zvolení peněženky k migraci se GUI zeptá uživatele na případné heslo.

  • ● Core Lightning #7540 vylepšuje vzorec, kterým se počítá pravděpodobnost úspěšného nalezení cesty v renepay pluginu (viz zpravodaj č. 263). Přidává konstantní multiplikátor reprezentující pravděpodobnost, že náhodně zvolený kanál v síti je schopen přeposlat nejméně 1 msat. Výchozí hodnota je nastavena na 0,98, může se však v budoucnosti změnit.

  • ● Core Lightning #7403 přidává do pluginu renepay filtr, který ignoruje kanály s velmi nízkým max_htlc. V budoucnosti může být filtr rozšířen o další parametry: vysoký poplatek, nízká kapacita, vysoká latence. Uzly či kanály mohou být manuálně vyloučeny volbou exclude.

  • ● LND #8943 přidává do kódu Alloy modely, počínaje modelem pro Linear Fee Function pro navyšování poplatků (inspirováno opravou chyby v LND #8751). Alloy poskytuje lehkotonážní formální metodu pro ověřování správnosti systémových komponent, což během implementace pomáhá hledat chyby. Narozdíl od plnohodnotných formálních metod, které se snaží dokázat, že je model vždy správný, operuje Alloy nad vstupem množiny omezených parametrů a iterací a snaží se najít protipříklady danému tvrzení. Modely mohou být též použity pro specifikaci protokolů v P2P systémech, což je pro Lightning Network zvláště vhodné.

  • ● BDK #1478 přináší několik změn do struktur FullScanRequest a SyncRequest v bdk_chain: přináší builder vzor, mění pole chain_tip na volitelné (uživatelé tak nemusí být informováni o změnách LocalChain, což je užitečné pro používání bdk_esplora) a zlepšuje ergonomii sledování postupu synchronizace. Dále bdk_esplora automaticky přidává do TxGraph předchozí výstupy.

  • ● BDK #1533 umožňuje pomocí Wallet::create_single vytvářet peněženky s jediným deskriptorem. Tato změna revertuje předchozí update, kterým struktura Wallet vyžadovala přítomnost interního deskriptoru pro zbytky. Důvodem předchozí změny byla ochrana soukromí adres pro zbytky během používání veřejných Electrum či Esplora serverů, avšak nyní převážila potřeba podporovat více případu použití.

  • ● BOLTs #1182 zlepšuje srozumitelnost a úplnost částí specifikace BOLT4 věnujících se zaslepování cest a onion zprávám: přesouvá sekci o zaslepování cest o jednu úroveň výše (aby bylo zřejmé, že se týká i plateb a ne jen onion zpráv), poskytuje konkrétnější detaily o datovém typu blinded_path a jeho požadavcích, rozšiřuje popis zodpovědností, rozděluje sekci příjemce na blinded_path a encrypted_recipient_data, zlepšuje vysvětlení konceptu blinded_path, přidává doporučení pro používání falešného skoku, přejmenovává onionmsg_hop na blinded_path_hop a další.

  • ● BLIPs #39 přidává BLIP39 specifikující volitelné pole b v BOLT11 fakturách, které určuje zaslepenou cestu pro platbu. LND již toto pole implementuje (viz zpravodaj č. 315). Záměrem je toto pole používat, dokud se protokolu nabídek nedostane širokého nasazení.