Zpravodaj tento týden oznamuje vydání beta verze plného uzlu s podporou utreexo a shrnuje dvě navrhovaná rozšíření BIP119 OP_CHECKTEMPLATEVERIFY. 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

  • ● Vydání beta verze utreexod: Calvin Kim zaslal do emailové skupiny Bitcoin-Dev příspěvek s oznámením vydání beta verze utreexod, plného uzlu s podporou utreexo. Utreexo umožňuje uzlu namísto kompletní množiny UTXO ukládat pouze malé závazky (commitmenty) jejího stavu. Závazek může mít pouhých 32 bajtů, což jej činí při současné velikosti plné množiny kolem 12 GB řádově miliardkrát menším. Za účelem snížení používání přenosového pásma může utreexo ukládat další dodatečné commitmenty; zvýší se sice používání diskového prostoru, ale bude i přesto řádově milionkrát nižší než u tradičních plných uzlů. Utreexový uzel, který navíc ořezává staré bloky, může být provozován s malým konstantním diskovým prostorem. To je výhodné v porovnání s běžným ořezaným plným uzlem, který může vyžadovat prostor větší, než je disková kapacita zařízení.

    Kimovy poznámky k vydání naznačují, že uzel je kompatibilní s peněženkami založenými na BDK a mnoha dalšími, které podporují Electrum personal server. Uzel podporuje přeposílání transakcí díky rozšíření P2P protokolu, které umožňuje přeposílání utreexo důkazů. Podporovány jsou běžné i přemosťovací utreexo uzly; běžné utreexo uzly používají utreexo commitmenty za účelem šetření diskovým prostorem, přemosťovací uzly ukládají kompletní stav UTXO s dodatečnými daty a jsou schopné připojit utreexo důkazy k blokům a transakcím, které byly vytvořené uzly bez podpory utreexo.

    Utreexo nevyžaduje změnu konsenzu a utreexo uzly nekolidují s uzly bez utreexo podpory, avšak běžné utreexo uzly se mohou spojit pouze s jinými utreexo uzly, běžnými či přemosťovacími.

    Kim ke svému oznámení připojuje několik varování: „kód ani protokol neprošly důkladnou revizí, […] přijdou změny bez zpětné kompatibility […] a utreexod je založen na btcd, které může být nekompatibilní s konsenzem.”

  • ● Rozšířený BIP119 s menšími hašemi a závazky libovolným datům: Jeremy Rubin zaslal do emailové skupiny Bitcoin-Dev příspěvek s návrhem BIPu rozšiřujícího navrhovaný opkód OP_CHECKTEMPLATEVERIFY (OP_CTV) dvěma novými možnostmi:

    • ● Podpora pro hašovací funkci HASH160: jedná se o haše používané pro P2PKH, P2SH a P2WPKH adresy. Mají 20 bajtů narozdíl od 32bajtových hašů používaných v návrhu BIP119. V naivních protokolech s více stranami může být útok hledáním kolize na 20bajtové haše proveden zhruba s 280 operacemi hrubé síly, což je v dosahu vysoce motivovaného útočníka. Z tohoto důvodu moderní bitcoinové opkódy obvykle používají 32bajtové haše. Avšak zabezpečení protokolů s jedním účastníkem nebo dobře navržených protokolů s více stranami používajících 20bajtové haše může být navýšeno tak, že jeho kompromitace v méně než 2160 operacích je nepravděpodobná. Díky tomu mohou protokoly vyžadovat o 12 bajtů na haš méně. Jedním příkladem, kde to může být přínosné, je implementace protokolu eltoo (viz zpravodaj č. 284).

    • ● Podpora pro více druhů commitmentů: OP_CTV skončí úspěšně, je-li spuštěn v transakci, jejíž vstupy a výstupy jsou zahašovány do stejných hodnot jako poskytnuté otisky. Jedním z těchto výstupů by mohl být OP_RETURN, který zavazuje nějakým datům, která chce autor skriptu publikovat na blockchainu, například data nezbytná pro obnovení LN kanálu ze zálohy. Avšak umístit tato data ve witnessu by bylo výrazně levnější. Navržená rozšířená forma OP_CTVumožňuje autorovi skriptu požadovat, aby byla během hašování vstupů a výstupů použita i část dat ze zásobníku witnessu. Tato data budou porovnána s otiskem poskytnutým autorem skriptu. Díky tomu budou mít data publikovaná v blockchainu minimální váhu.

    Návrh neobdržel v době psaní tohoto čísla žádné reakce.

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 #29845 mění v několika RPC voláních typu get*info pole warnings. Namísto jednoduchého řetězce nově obsahuje pole řetězců, aby mohlo vrátit více než jedno varování.

  • ● Core Lightning #7111 zpřístupňuje pluginům RPC příkaz check. Možnosti příkazu byly dále rozšířeny o check setconfig, které kontroluje platnost konfiguračních voleb, a check keysend zjišťující, zda by hsmd danou transakci schválilo. Byla přidána předinicializační zpráva s přednastavenými vývojovými HSM příznaky. O příkazu check jsme se též zmiňovali ve zpravodajích č. 25 a č. 47 (oba angl.).

  • ● Libsecp256k1 #1518 přidává funkci secp256k1_pubkey_sort, která kanonicky seřadí množinu veřejných klíčů. To je užitečné pro MuSig2, tiché platby a zřejmě i mnoho dalších protokolů používajících více klíčů.

  • ● Rust Bitcoin #2707 upravuje API pro tagované haše představené jako součást taprootu tím, že ve výchozím stavu očekává otisky v interním pořadí bajtů. Dříve API očekávalo haše v pořadí bajtů pro zobrazování, které lze nově vyžádat atributem #[hash_newtype(backward)]. Z historických důvodů jsou haše použité jako txid a identifikátory bloků uložené v transakcích a blocích v jednom pořadí bajtů (interní), ale zobrazovány jsou v opačném pořadí (pořad pro zobrazování). Toto PR se snaží zabránit, aby i další haše měly v různých případech různá pořadí bajtů.

  • ● BIPs #1389 přidává BIP388, které popisuje „pravidla peněženek pro deskriptorové peněženky.” Jedná se o sadu šablon deskriptorů výstupních skriptů, které mohou širokému spektru peněženek usnadnit jejich podporu v kódu a uživatelském rozhraní. Deskriptory mohou být náročné na implementaci v hardwarových peněženkách s omezenými zdroji a zobrazovacím prostorem. Pravidla dle BIP388 umožní software i hardware přijmout zjednodušující předpoklady o tom, jak budou deskriptory používány. Dosáhnou tak redukce potřebného kódu a množství detailů, které musí uživatelé ověřit. Software, který vyžaduje kompletní podporu deskriptorů, je může nadále používat nezávisle na BIP388. Další podrobnosti přinesl zpravodaj č. 200.

  • ● BIPs #1567 přidává BIP387 popisující nové deskriptory multi_a() a sortedmultia_a(), které poskytují možnosti skriptovaných multisig operací uvnitř tapscriptu. BIP uvádí příklad fragmentu deskriptoru: multi_a(k,KEY_1,KEY_2,...,KEY_n) vyprodukuje skript KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL. Dále viz zpravodaje č. 191 (angl.), č, 227 a č. 273.

  • ● BIPs #1525 přidává BIP347, který navrhuje opkód OP_CAT. Tento opkód by mohl být v případě aktivace v soft forku používán v tapscriptech. Dále viz zpravodaje č, 274, č. 275 a č. 293.

Změna času publikace zpravodaje

V následujících týdnech bude Optech experimentovat s alternativním časem publikování. Nebuďte prosím překvapeni, pokud obdržíte zpravodaj o několik dní dříve či později. Během krátké doby věnované experimentu budou zpravodaje zaslané emailem obsahovat trasovací kód, který nám pomůže určit jeho čtenost. Sledování můžete zabránit předchozím zákazem načítání externích zdrojů. Pokud vyžadujete více soukromí, doporučujeme odebírat náš RSS feed přes dočasné Tor spojení. Za jakékoliv nesnáze se omlouváme.