Zpravodaj tento týden shrnuje schéma podobné úschovnám používající zaslepený MuSig2 a popisuje návrh na možnost bitcoinových klientů oznamovat a vyjednávat o podpoře nových P2P funkcí. Též nechybí naše pravidelné rubriky s popisem diskuzí o změnách konsenzu, oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Úschovny používající zaslepené kooperativní podepisování: Jonathan T. Halseth zaslal do fóra Delving Bitcoin příspěvek o prototypu schématu podobného úschovnám, které používá zaslepené kooperativní podepisování. Na rozdíl od tradičního kooperativního podepisování používá jeho schéma zaslepenou verzi protokolu MuSig2, aby podepisující věděli co nejméně o prostředcích zapojených do podepisování. Aby nemuseli podepisující slepě podepsat cokoliv, co je jim podstrčeno, přikládá toto schéma k požadavku o podepsání navíc doklad s nulovou znalostí, který dokazuje, že transakce je validní dle předem určených pravidel (v tomto případě jsou jimi časové zámky).

    Halseth na grafu ukázal čtyři transakce, které se podepisují předem: počáteční vklad, zotavení (recovery), výběr z úschovny (unvault) a zotavení po výběru (unvault recovery). Během výběru z úschovny budou podepisující vyžadovat doklad s nulovou znalostí dokazující, že má podepisovaná transakce správně nastavený relativní časový zámek. To zaručí, že budou mít uživatelé nebo strážní věž dostatek času na zotavení v případě neautorizovaného výběru.

    Halseth též poskytl implementaci prototypu dostupnou pro regtest a signet.

  • ● Vyjednávání o schopnostech peer spojení: Anthony Towns zaslal do emailové skupiny Bitcoin-Dev příspěvek o návrhu nového BIPu, který definuje P2P zprávy umožňující spojením oznamovat a vyjednávat o podpoře nových funkcí. Myšlenka je podobná návrhu z roku 2020. Byla by přínosná pro různé navrhované P2P funkce, včetně Townsova vlastního návrhu sdílení šablon.

    Z historických důvodů se změny P2P protokolu spoléhají na navyšování čísla verze jako signalizace podpory nových funkcí. Díky tomu mohou uzly začít vyjednávat o spojení jen s kompatibilními uzly. Tento přístup však vyžaduje nadbytečnou koordinaci mezi implementacemi, obzvláště u funkcí, které nepotřebují široké nasazení.

    Tento BIP navrhuje zobecnit mechanismus z BIP339 přidáním jedné opakovaně použitelné P2P zprávy pro oznámení a vyjednávání budoucích rozšíření P2P protokolu ve fázi před zprávou verack (version acknowledgement, tedy potvrzení přijetí čísla verze). Snížil by tím potřebu koordinace, usnadnil přidávání rozšíření, zamezil tříštění sítě a maximalizoval kompatibilitu s různorodými klienty.

Diskuze o změnách konsenzu

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

  • ● Migrace na uint64 kvůli přetečení časových razítek v roce 2106: Asher Haim zaslal do emailové skupiny Bitcoin-Dev příspěvek se žádostí, aby se bitcoinoví vývojáři neprodleně začali připravovat na migraci časových razítek bloků z typu uint32 na uint64. Haim objasňuje důvody nutnosti jednat neodkladně v souvislosti s dlouhodobými finančními kontrakty, které se mohou již překvapivě brzy týkat bitcoinu po roce 2106. Nejedná se zatím o konkrétní návrh v podobě BIPu. Vyžadovalo by to vyřešit mnoho dílčích problémů souvisejících s časovými zámky a dalšími oblastmi bitcoinového ekosystému. Návrh BitBlend z ledna 2024 je jedním z možných konkrétních řešení.

  • ● Zmírnění omezení časových razítek v BIP54 pro možný 2106 soft fork: Josh Doman zaslal příspěvek do emailové skupiny Bitcoin-Dev a fóra Delving Bitcoin s dotazem, zda by stálo za snahu upravit návrh pročištění konsenzu tak, aby byl shovívavější k neobvyklým časovým razítkům bloku, což by umožnilo nasadit řešení problému přetečení časového razítka bloku v roce 2016 pomocí případného soft forku. ZmnSCPxj již v roce 2021 podobnou myšlenku představil. Diskuze v obou fórech se soustředila na otázku, zda vyhýbání se hard forku stojí za námahu, když existují pádné inženýrské důvody, proč o něj usilovat. Greg Maxwell napsal, že riziko neopravení útoků ohýbáním času, jehož řešení si BIP54 klade za cíl, představuje dostatečný důvod, proč se o zmírnění omezení nepokoušet.

  • ● Ochrana před CTV pastí: Chris Stewart zaslal do fóra Delving Bitcoin příspěvek diskutující nebezpečnou past (footgun) v OP_CHECKTEMPLATEVERIFY (CTV). Pokud je na scriptPubKey, který bezpodmínečně vyžaduje CTV haš, zaslána částka nižší než součet výstupních částek určených v jednovstupovém CTV haši, je výsledný výstup natrvalo neutratitelný. Navrhuje, že tomu mohou uživatelé CTV zabránit, pokud by všechny jejich CTV haše zavazovaly dvěma nebo více vstupům. Tímto způsobem je vždy možné zkonstruovat dodatečný vstup, díky kterému lze takové výstupy utratit.

    Greg Sanders ve své odpovědi přednesl některá omezení tohoto přístupu a 1440000bytes zmínil, že toto je možné pouze, pokud je šablona následné transakce bezpodmínečně vynucena. Dle Grega Maxwella bychom se z tohoto důvodu měli vyhnout celé třídě kovenantů používajících šablony transakcí. Brandon Black potvrdil, že používaní CTV na příjmové adresy je vskutku rizikové a že jiný opkód, jako OP_CHECKCONTRACTVERIFY (BIP443), by v kombinaci s CTV umožnil bezpečnější aplikace.

  • ● Setkání o aktivaci CTV: Vývojář 1440000bytes uspořádal setkání o aktivaci CTV (BIP119). Účastníci souhlasili, že klient aktivující CTV by měl používat BIP9 a konzervativní parametry (tedy s dlouhými signalizačními a aktivačními fázemi). V době psaní zpravodaje se v emailové skupině nevyjádřili žádní jiní vývojáři.

  • ● OP_CHECKCONSOLIDATION umožní levnější konsolidace: billymcbip navrhl nový opkód určený pro konsolidace. OP_CHECKCONSOLIDATION (CC) by vrátil 1 pouze, pokud byl spuštěn na vstupu se stejným scriptPubKey jako předchozí vstup ve stejné transakci. Mnoho se diskutovalo o nutnosti používat stejný scriptPubKey, což by navádělo k opakovanému používání adres a narušování soukromí. Brandon Black navrhl podobnou (avšak ne tak prostorově optimální) funkcionalitu použitím OP_CHECKCONTRACTVERIFY (BIP443). Tento návrh je podobný i jinému, který navrhl Tadge Dryja během práce na OP_CHECKINPUTVERIFY, avšak je výrazně úspornější a méně obecný.

  • ● Bitcoinové podpisy založené na hašování v postkvantové budoucnosti: Mikhail Kudinov a Jonas Nick zaslali do emailové skupiny Bitcoin-Dev příspěvek popisující jejich práci vyhodnocující podpisy založené na hašování pro použití v bitcoinu. Nalezli slibné příležitosti pro optimalizaci velikosti podpisů v porovnání se současnými standardními přístupy, ale nenalezli vhodné alternativy k BIP32, BIP327 či FROST. Několik vývojářů se zapojilo do diskuze o tomto projektu i o jiných schématech postkvantového podepisování a o možných směrech budoucího vývoje.

    Též se diskutovalo, zda je vhodné porovnávat nové mechanismy ověřování podpisů dle počtu procesorových cyklů na bajt nebo na podpis. Používání cyklů na bajt se jeví lépe použitelné, pokud by bylo ověřování nových podpisů omezeno stávajícími váhovými limity a multiplikátory, a to za cenu nižší propustnosti plateb. Cykly na podpis by byly příhodnější, pokud by nové podpisy měly i nové limity umožňující propustnost plateb blízkou současné.

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.

  • ● BTCPay Server 2.3.0 je vydáním tohoto oblíbeného platebního procesoru s možností vlastního hostování. Do uživatelského rozhraní a API přidává novou funkci Subscriptions (viz zpravodaj č. 379, angl.) a vylepšuje žádosti o platbu. Též obsahuje několik dalších novinek a oprav chyb.

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. BINANAs._

  • ● Bitcoin Core #33657 přináší nové RESTové rozhraní /rest/blockpart/<BLOCKHASH>.bin?offset=X&size=Y, které vrací část bajtů bloku. Umožní externím indexům jako Electrs obdržet pouze konkrétní transakce namísto stahování celého bloku.

  • ● Bitcoin Core #32414 přidává pravidelně se opakující zapsání mezipaměti UTXO na disk během opakovaného indexování, stejně jako se již děje během úvodního stahování bloků. Dříve došlo k zapsání na disk až po dosažení vrcholu řetězce, což v případě pádu aplikace a velké dbcache mohlo znamenat zmařenou práci.

  • ● Bitcoin Core #32545 nahrazuje dřívější algoritmus linearizace clusterů (viz zpravodaj č. 314) algoritmem linearizace koster grafu (spanning-forest linearization, SFL) navrženým pro efektivnější zpracování náročných clusterů. Testování na historických datech z mempoolů ukazuje, že nový algoritmus umí linearizovat všechny nalezené clustery s až 64 transakcemi v desítkách milisekund. Jedná se o součást projektu mempoolu clusterů.

  • ● Bitcoin Core #33892 uvolňuje pravidla přeposílání, aby umožňovala příležitostné přeposílání balíčků s jedním rodičem a jedním potomkem (1p1c), kde rodič platí na poplatcích méně, než je minimum pro přeposílání, aniž by tato rodičovská transakce musela být TRUC. Jednotkový poplatek balíčku musí přesáhnout výši minimálního poplatku pro přeposílání a potomek nesmí mít žádné další potomky s poplatkem pod minimem. Dříve bylo toto možné pouze u TRUC transakcemi, aby bylo jednodušší rozhodování o ořezávání mempoolu; s mempoolem clusterů to však již není potřeba.

  • ● Core Lightning #8784 přidává do RPC příkazu xpay (viz zpravodaj č. 330) pole payer_note, které plátcovi umožní během žádosti o fakturu přidat k platbě popisek. Příkaz fetchinvoice již podobné pole payer_note obsahuje, tato změna ho tedy přidává i do xpay a tyto dvě hodnoty spojuje dohromady.

  • ● LND #9489 a #10049 přinášejí experimentální gRPC podsystém switchrpc s příkazy BuildOnion, SendOnion a TrackOnion, které umožní externímu software zajistit hledání cesty a správu životního cyklu plateb, zatímco LND se postará o doručování HTLC. Funkcionalita je ukryta pod příznakem kompilátoru switchrpc (ve výchozím nastavení je vypnutý). LND #10049 konkrétně přidává základy pro sledování externí činnosti a připravuje prostor pro budoucí idempotentní verzi. V současnosti je používání bezpečné pouze při jediné entitě používající tento podsystém v jeden okamžik, jinak hrozí ztráta prostředků.

  • ● BIPs #2051 provádí několik změn ve specifikaci BIP3: opět odstraňuje nedávno přidané doporučení proti používání LLM (viz zpravodaj č. 378, angl.), rozšiřuje formáty referenčních implementací, přidává historii změn a několik dalších zlepšení a objasnění.

  • ● BOLTs #1299 odstraňuje ze specifikace BOLT3 nejasnou poznámku o používání localpubkey (bod na eliptické křivce, odlišný pro každý commitment) ve výstupu, který platí protistraně to_remote. S volbou option_static_remotekey to již není platné, protože to_remote výstup by měl používat příjemcův statický payment_basepoint, aby bylo možné zachránit prostředky bez localpubkey.

  • ● BOLTs #1305 objasňuje specifikaci BOLT11 ohledně pole n (33bajtový veřejný klíč uzlu příjemce), které není povinné. Dřívější verze nesprávně tvrdila, že pole je povinné.