Zpravodaj tento týden odkazuje na vzdělávací implementaci kryptografie nad eliptickou křivkou secp256k1 používanou v bitcoinu. 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

  • ● Vzdělávací a experimentální implementace secp256k1: Sebastian Falbesoner, Jonas Nick a Tim Ruffing zaslali do emailové skupiny Bitcoin-Dev příspěvek s ohlášením pythonové implementace rozličných kryptografických funkcí používaných v bitcoinu. Varují, že implementace „NENÍ BEZPEČNÁ” (verzálky v originále) a je „určená pro prototypování, experimenty a studium.”

    Dále poznamenávají, že referenční a testovací kód několika BIPů (340, 324, 327 a 352) již obsahuje „vlastní a někdy se drobně lišící implementace secp256k1.” Doufají, že tuto situaci vylepší a začnou snad nadcházejícím BIPem pro ChillDKG (viz zpravodaj č. 312).

Diskuze o změnách konsenzu

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

  • ● Několik diskuzí o krádeži kvantovými počítači a obraně: několik diskuzí zkoumalo, jak by bitcoineři reagovali, kdyby schopnosti kvantových počítačů umožnily krádež bitcoinů.

    • ● Měly by být zranitelné bitcoiny zničeny? Jameson Lopp zaslal do emailové skupiny Bitcoin-Dev několik důvodů pro zničení bitcoinů náchylných na kvantovou krádež poté, co je nastolena cesta ke kvantové odolnosti, a po uplynutí dostatečné doby pro osvojení uživateli. Mezi některé důvody patří:

      • ● Sdílená preference: Lopp věří, že většina lidí by raději preferovala, aby byly jejich prostředky zničeny, než ukradeny někým s rychlým kvantovým počítačem, obzvláště když by to byl zloděj z „úzké skupinky privilegovaných lidí, kteří se ke kvantovým počítačům dostanou brzy.”

      • ● Obecná škoda: mnoho z ukradených bitcoinů by byly buď ztracené mince nebo mince určené pro dlouhodobé držení. Na druhou stranu by zloději rychle ukradené bitcoiny utratili, čímž by se snížila kupní síla ostatních bitcoinů (podobně jako u inflace peněžní zásoby). Poznamenává, že nižší kupní síla bitcoinů vede k nižším příjmům těžařů, což snižuje bezpečnost sítě a (dle Loppa) i ochotu obchodníků bitcoin přijímat.

      • ● Minimální výhody: i když by existence možnosti krádeže mohla vést k financování vývoje kvantových počítačů, krádež mincí neposkytuje poctivým účastníkům bitcoinového protokolu žádné přímé výhody.

      • ● Jasná lhůta: nikdo nemůže dopředu znát den, kdy někdo s kvantovým počítačem bude moci začít s krádeží bitcoinů, avšak datum, kdy by byly zranitelné mince zničeny, může být ohlášeno dlouho dopředu s dokonalou přesností. Tato jasná lhůta poskytne uživatelům více podnětů k včasnému zabezpečení jejich bitcoinů a zajistí minimální ztrátu mincí.

      • ● Podněty těžařů: jak bylo poznamenáno výše, kvantová krádež by pravděpodobně snížila příjmy těžařů. Trvalá většina hašovacího výkonu může cenzurovat platby kvantově zranitelnými bitcoiny, což mohou dělat, i kdyby měl zbytek bitcoinerů jiné preference.

      Lopp dále poskytuje několik argumentů proti destrukci zranitelných bitcoinů, ale na závěr se vyjadřuje ve prospěch zničení.

      Nagaev Boris se ptá, zda UTXO, která mají časový zámek za lhůtou, by měla být také zničena. Lopp poznamenává stávající potíže s dlouhými časovými zámky a říká, že se osobně cítí „při zamykání na déle než rok nebo dva trochu nervózní.”

    • ● Bezpečné doložení vlastnictví UTXO odhalením SHA256 předobrazu: Martin Habovštiak zaslal do emailové skupiny Bitcoin-Dev příspěvek s myšlenkou, která by komukoliv umožnila doložit kontrolu nad nějakým UTXO, i kdyby nebyly ECDSA a Schnorrovy podpisy bezpečné (např. po příchodu rychlých kvantových počítačů). Pokud by UTXO obsahovalo SHA256 (nebo jiný kvantově bezpečný) commitment k předobrazu, který nikdy předtím odhalen nebyl, mohl by být pro zabránění kvantové krádeže použit vícekrokový protokol (v kombinaci se změnou konsenzu) odhalující tento předobraz. Jedná se v základu o stejný nápad popsaný v dřívějším návrhu Tima Ruffinga (viz zpravodaj č. 141, angl.), který se obecně nazývá podpisové schéma Guy Fawkes. Jedná se také o variantu schématu, které Adam Back vymyslel v roce 2013 pro zlepšení ochrany proti cenzurujícím těžařům. Ve stručnosti funguje protokol takto:

      1. Alice obdrží prostředky na výstup, který nějakým způsobem vytváří SHA256 závazek. Může to být přímo hašovaný výstup (P2PKH, P2SH, P2PWPKH, P2WSH) nebo P2TR výstup se skriptem.

      2. Pokud Alice obdrží několik plateb na stejný výstupní skript, musí se ujistit, že buď neutratí ani jednu z nich, dokud nebude připravena utratit všechny (určitě nutné pro P2PKH a P2WPKH, pravděpodobně v praxi potřebné též pro P2SH a P2WSH), nebo musí zajistit, že alespoň jeden předobraz zůstane po jejích platbách neodhalený (snadné s P2TR platbou klíčem oproti platbě skriptem).

      3. Je-li Alice připravena provést platbu, běžným způsobem vytvoří transakci, avšak nezveřejní ji. Dále získá nějaký bitcoin s kvantově bezpečným podpisovým algoritmem na zaplacení poplatků.

      4. V transakci posílající některé z kvantově bezpečných bitcoinů vytvoří závazek kvantově nezabezpečeným bitcoinům, které chce poslat, a také závazek nezveřejněné transakci (stále ji neodhaluje). Počká na dostatečný počet potvrzení transakce.

      5. Je-li Alicina transakce již dostatečně hluboko, odhalí předobraz a kvantově nezabezpečenou platbu.

      6. Uzly v síti hledají první transakci, která tomuto předobrazu zavazuje. Zavazuje-li tato transakce Alicině kvantově nezabezpečené platbě, její platbu provedou. Jinak nedělají nic.

      Tyto kroky zajistí, aby Alice nemusela odhalovat kvantově slabé informace, dokud si není jista, že její verze platby bude upřednostněna před pokusem o platbu nějakého provozovatele kvantového počítače. Přesnější popis protokolu lze nalézt v Ruffingově příspěvku z roku 2018. Věříme, že takový protokol by mohl být nasazen jako soft fork (avšak nasazení se ve vlákně neprobíralo).

      Habovštiak říká, že by bitcoiny, které je možné bezpečně utratit použitím tohoto protokolu (např. pokud jejich předobrazy ještě nebyly odhaleny), neměly být zničeny, i kdyby se komunita rozhodla pro zničení kvantově zranitelných bitcoinů. Dále tvrdí, že možnost v naléhavých případech bezpečně utratit bitcoin snižuje urgentnost nasazení kvantově odolného schématu v blízké budoucnosti.

      Lloyd Fournier říká: „jestli se tento přístup přijme, myslím, že hlavní věcí pro uživatele je přesunout se na taprootovou peněženku“ pro její schopnost plateb klíčem pod současnými pravidly konsenzu včetně případů opakovaného použití adresy, ale i pro odolnost vůči kvantové krádeži, pokud by byly platby klíčem později zakázány.

      V jiném vlákně (viz další položku) Pieter Wuille poznamenal, že UTXO zranitelná vůči kvantové krádeži také obsahují klíče, které nebyly veřejně použité, ale které jsou známé více stranám, jako jsou různé formy vícenásobného podpisu (LN, DLC či služby svěřenectví).

  • ● Několik diskuzí o soft forku CTV+CSFS: několik konverzací zkoumalo rozličné aspekty soft forků pro přidání opkódů OP_CHECKTEMPLATEVERIFY (CTV) a OP_CHECKSIGFROMSTACK (CSFS).

    • ● Kritika motivace CTV: Anthony Towns zaslal kritiku motivace BIP119, která by dle něj byla přidáním CTV s CSFS do bitcoinu podryta. Několik dní po začátku diskuze přinesl autor BIP119 aktualizaci odstraňující většinu (možná i všechny) kontroverzních výroků. Ve zpravodaji č. 347 jsme přinesli souhrn této změny, viz též starší verzi BIP119. Mezi diskutovaná témata patřilo:

      • ● CTV+CSFS umožňuje vytváření nekonečných kovenantů: Motivace CTV říká: „Kovenanty jsou historicky považované za nevhodné pro bitcoin, protože jsou příliš složité na implementaci a hrozí redukce zaměnitelnosti dotčených mincí. Tento BIP přináší jednoduchý kovenant nazvaný šablona, která umožňuje omezenou sadu vysoce hodnotných případů použití bez vážných rizik. Šablony dle BIP119 umožňují nerekurzivní kovenanty bez dynamického stavu, které musí být po jednom vyjmenované” (zdůraznění v původním textu).

        Towns popisuje skript používající CTV i CSFS a odkazuje na transakci na signetu MutinyNetu, která může být utracena pouze zasláním shodné částky zpět stejnému skriptu. Ačkoliv se vedla o definicích debata, autor CTV již dříve popsal funkčně identický konstrukt jako rekurzivní kovenant a Optech tuto konvenci ve svém souhrnu (angl.) následoval.

        Olaoluwa Osuntokun obhajoval motivaci CTV, jelikož skripty musí „být po jednom vyjmenované” a „bez dynamického stavu.” To je podobné argumentům autora CTV Jeremyho Rubina z roku 2022, kdy nazýval tento druh kovenantů platících sobě samým „rekurzivní, ale po jednom vyjmenovaný.” Towns reagoval, že přidání CSFS tento benefit (po jednom vyjmenované) podrývá. Požadoval úpravu BIPů CTV nebo CSFS, aby obsahoval popis „případu, který je nějakým způsobem hrozivý, ale kombinace CTV a CSFS mu zabraňuje.” Možná se tak stalo v nedávné aktualizaci BIP119, která popisuje „samoreprodukující automaty (obecně nazývané SpookChains),“ které by byly možné s SIGHASH_ANYPREVOUT, ale ne s CTV+CSFS.

      • ● Nástroje pro CTV a CSFS: Towns poznamenal, že používání stávajících nástrojů pro vývoj jeho rekurzivního skriptu je náročné. Ukazuje tím na nepřipravenost pro nasazení. Osuntokun řekl, že nástroj, který používá, „je hezky přímočarý.” Towns ani Osuntokun neuvedli, jaké nástroje používají. Nadav Ivgi poskytl příklad používání jeho jazyka Minsc a řekl, že „pracuje na vylepšení Minscu, aby byly tyhle věci snazší. Podporuje Taproot, CTV, PSBT, deskriptory, miniscript, Script, BIP32 a další.” Přiznává však, že „hodně z toho stále nemá dokumentaci.”

      • ● Alternativy: Towns přirovnává CTV+CSFS ke svému Basic Bitcoin Lisp Language (bll) i Simplicity, které by mohly poskytnout alternativní skriptovací jazyk. Antoine Poinsot říká, že alternativní jazyk, který je jednoduchý na porozumění, může být méně riskantní než malá změna do současného systému. Vývojář Moonsettler tvrdí, že díky inkrementálnímu přidávání nových schopností do bitcoinového skriptu je bezpečnější přidat nové funkce v budoucnu, neboť díky každému nárůstu expresivity je méně pravděpodobné, že narazíme na překvapení.

        Osuntokun a James O’Beirne připravenost bll a Simplicity v porovnání s CTV a CSFS kritizovali.

    • ● Výhody CTV+CSFS: Steven Roose zaslal do fóra Delving Bitcoin příspěvek s návrhem na přidání CTV a CSFS do bitcoinu jako první krok před dalšími změnami, které by expresivitu navýšily ještě dále. Většina diskuze se soustředila na výčet možných výhod, které CTV, CSFS nebo oba dohromady poskytují. Mezi ně patří:

      • ● DLC: CTV i CSFS jednotlivě mohou snížit počet podpisů potřebných pro vytváření DLC, obzvláště DLC pro podepisování velkého množství variant kontraktu (např. cenový kontrakt na BTC–USD vyčíslený v jednodolarových přírůstcích). Antoine Poinsot odkázal na nedávné oznámení ukončení provozu jednoho poskytovatele DLC služeb jako důkaz, že bitcoinoví uživatelé nemají příliš zájem o DLC. Dále odkázal na několik měsíců starý příspěvek od Jonase Nicka, dle kterého „se DLC v bitcoinu neshledala s významným osvojením a nezdá se, že by jejich nízké používání pramenilo z výkonnostních limitů.” Odpovědi odkazovaly na jiné dosud funkční služby, včetně jedné, která tvrdí, že vybrala „30 miliónů dolarů na financování.“

      • ● Úschovny: CTV zjednodušuje implementaci úschoven (vaults), které jsou možné i dnes s použitím předem podepsaných transakcí a (volitelně) vymazání soukromých klíčů. Anthony Towns tvrdí, že tento typ úschoven není příliš zajímavý. James O’Beirne odpovídá, že CTV či něco podobného je prerekvizitou pro budování pokročilejších typů úschoven, jako např. jeho BIP345 OP_VAULT.

      • ● Kontrakty s odpovědnými výpočty: CSFS může odstranit mnoho kroků v kontraktech s odpovědnými výpočty (accountable computing contracts) jako BitVM, které aktuálně vyžadují používat Script pro provádění Lamportových podpisů. CTV by mohlo snížit počet kroků ještě více. Poinsot opět pátrá po výrazné poptávce po BitVM. Gregory Sanders odpovídá, že by mohlo být užitečné pro obousměrné přemosťování tokenů v Shielded client-side validation (viz zpravodaj č. 322). Avšak též poznamenává, že CTV ani CSFS výrazně nevylepšují model důvěry v BitVM; pro to by byly potřebné další změny.

      • ● Vylepšení skriptů s časovými zámky v Liquid: James O’Beirne přeposílá komentáře dvou inženýrů z Blockstream, že by dle jeho slov CTV mohlo „drasticky zlepšit skripty s časovými zámky v Liquid (od Blockstreamu), které vyžadují, aby byly mince pravidelně přesouvány.” Po žádostech o objasnění vysvětlil bývalý inženýr Blockstreamu Sanket Kanjalkar, že tou výhodou by bylo výrazné snížení transakčních poplatků. O’Beirne dále sdílel další podrobnosti od Andrew Poelstry, ředitele výzkumu v Blockstream.

      • ● LN-Symmetry: CTV spolu s CSFS mohou být použity k implementaci typu LN-Symmetry, který odstraňuje některé z nedostatků LN-Penalty kanálů aktuálně používaných v LN a který by mohl umožnit vytváření kanálů s více než dvěma stranami (efektivnější pro správu likvidity a onchain). Gregory Sanders, který naimplementoval experimentální verzi LN-Symmetry (viz zpravodaj č. 284) pomocí SIGHASH_ANYPREVOUT (APO), poznamenává, že verze LN-Symmetry s CTV+CSFS neposkytuje tolik funkcí jako APO verze a vyžaduje několik kompromisů. Anthony Towns dodává, že nikdo ještě neaktualizoval Sandersův experimentální kód s APO, aby běžel s moderním software a používal čerstvé funkce jako TRUC a dočasné anchory, natož aby používal CTV+CSFS. Tím je naše schopnost hodnotit tuto kombinaci pro LN-Symmetry omezená.

        Poinsot se ptá, zda by implementace LN-Symmetry byla pro vývojáře LN prioritou, pokud by ji nějaký soft fork umožnil. Citace od dvou vývojářů Core Lightning (a též spoluautorů článku, který představil LN-Symmetry) naznačily, že pro ně to prioritou je. Na druhou stranu vedoucí vývojář LDK Matt Corallo již dříve řekl: „LN-Symmetry mi nepřijde tak zajímavá, abychom ji ‚museli hned dokončit’.”

      • ● Ark: Roose je šéfem firmy budující implementaci Arku. Říká, že „CTV je pro Ark převratnou novinkou, výhody CTV jsou pro uživatele nesporné a není pochyb, že obě implementace Arku začnou CTV používat, jakmile bude dostupné.” Towns poznamenává, že nikdo Ark pro testování s APO či CTV nenaimplementoval. Roose krátce nato napsal kód, který přesně to činil. Dle něj je „pozoruhodně přímočarý” a prošel existujícími integračními testy. Vyčíslil dále některá z vylepšení: při přechodu na CTV „bychom mohli odstranit kolem 900 řádků kódu, snížit počet výměn v každém kole ze tří na dvě a snížit datový přenos, protože by nebylo nutné předávat nonce a částečné podpisy.”

        Roose později začal nové vlákno s diskuzí o výhodách CTV pro uživatele Arku (viz náš souhrn níže).

    • ● Výhody CTV pro uživatele Arku: Steven Roose zaslal do fóra Delving Bitcoin krátký popis protokolu Ark aktuálně nasazeného na signetu nazvaného bezkovenantový Ark (covenantless Ark, clArk). Dále popsal, jak by dostupnost opkódu OP_CHECKTEMPLATEVERIFY (CTV) mohla použitelnost jeho kovenantové verze pro uživatele zlepšit.

      Jedním z cílů Arku je umožnit asynchronní platby, tedy platby provedené v okamžiku, kdy je příjemce offline. V clArku za tímto účelem odesílatel a Ark server rozšíří odesílatelův stávající řetězec předem podepsaných transakcí, což nakonec příjemci umožní získat nad prostředky exkluzivní kontrolu. Taková platba v Arku se nazývá mimo kolo (out-of-round, arkoor). Když se příjemce opět připojí, může si zvolit, co dále dělat:

      • ● Vystoupit (exit) po prodlevě: zveřejnit kompletní řetězec předem podepsaných transakcí a tím vystoupit z joinpoolu (nazývaného Ark, čili archa). To si vyžádá počkat na vypršení časového zámku odsouhlaseného odesílatelem. Jakmile získá předem podepsaná transakce dostatečné množství potvrzení, může si být příjemce jist, že má nad prostředky výhradní kontrolu. Ztrácí tím však výhody účasti v joinpoolu, jako jsou rychlé platby a nižší poplatky díky sdílení UTXO. Navíc musí platit transakční poplatky za potvrzení.

      • ● Nic: v běžném případě nakonec předem podepsaná transakce v řetězci transakcí expiruje a odesílatel si bude moci prostředky nárokovat. Nejedná se o krádež, ale o očekávanou součást protokolu. Server se může rozhodnout část nebo všechny prostředky nějakým způsobem uživatelovi vrátit. Dokud expirace nenastane, příjemce může jednoduše čekat.

        V krajním případě se mohou server a plátce v kterýkoliv okamžik tajně dohodnout a podepsat alternativní řetězec transakcí a ukrást tím prostředky zaslané příjemci. Poznámka: díky vlastnostem bitcoinu mohou server a plátce být stejná osoba, tajná dohoda tedy nemusí být ani potřeba. Avšak pokud příjemce drží kopii řetězce transakcí podepsaného spolu se serverem, může doložit, že server prostředky ukradl. To může stačit k odrazení ostatních od používání tohoto serveru.

      • ● Obnovit (refresh): ve spolupráci se serverem může příjemce atomicky přesunout vlastnictví prostředků v transakci podepsané spolu s plátcem na jinou předem podepsanou transakci, kterou příjemce spolupodepsal. Tím se prodlouží expirační lhůta a eliminuje se možnost serveru a předchozího plátce ukrást dříve zaslané prostředky. Avšak obnovování vyžaduje, aby server držel obnovované prostředky až do jejich expirace, což snižuje likviditu serveru. Proto server po příjemci požaduje platbu úroku (čas expirace je pevně daný, proto může být zaplacen předem).

      Dalším cílem návrhu Arku je umožnit účastníkům přijímat LN platby. Ve svém původním příspěvku a v odpovědi Roose vysvětluje, že stávající účastníci, kteří již prostředky v joinpoolu mají, mohou být penalizováni až do výše nákladů na onchain transakci, pokud řádně neprovedou interakci vyžadovanou pro příjem LN platby. Avšak ti, kteří prostředky v joinpoolu nemají, penalizováni být nemohou, proto mohou odmítat provádět vyžadované kroky a tím bez nákladů vytvářet problémy poctivým účastníkům. Zdá se, že to ve svém důsledku zabraňuje uživatelům Arku přijímat LN platby, doku nevloží na vybraný Ark server určité množství prostředků.

      Roose dále popisuje, jak by dostupnost CTV tento protokol vylepšila. Hlavní změnou je způsob vytváření kol. Kolo v Arku (round) sestává z malé onchain transakce, která zavazuje stromu offchain transakcí. Těmi jsou v případě clArku předem podepsané transakce, což vyžaduje během provádění tohoto kola dostupnost všech plátců pro podepsání. S dostupným CTV by mohla každá větev ve stromu transakcí zavazovat svým potomkům pomocí CTV, bez podepisování. Tím by mohly být transakce vytvářené i pro účastníky, kteří nejsou v okamžiku vytváření kola dostupní. Přináší to tyto výhody:

      • ● Neinteraktivní platby uvnitř kol: namísto platby mimo kolo (arkoor) může plátce, který je ochoten čekat na příští kolo, poslat peníze uvnitř kola (in-round). To příjemcovi poskytuje jednu velkou výhodu: po dostatečném množství konfirmací získá výhradní kontrolu nad obdrženými prostředky (až do expirace, kdy může buď vystoupit nebo levně obnovit). Namísto čekání na potvrzení se může příjemce rozhodnout ihned důvěřovat protokolu Arku a incentivám serveru provozovat poctivě (viz též zpravodaj č. 253). Na jiném místě Roose poznamenal, že tyto neinteraktivní platby mohou být navíc dávkované a lze tak poslat peníze více příjemcům najednou.

      • ● Příjem LN plateb uvnitř kola: uživatel může požádat o zaslání LN platby (HTLC) na Ark server, který potom tuto platbu drží do dalšího kola. Do něj by pomocí CTV tuto HTLC platbu začlenil, načež by mohl uživatel předobraz HTLC odhalit a platbu nárokovat. Avšak Roose poznamenává, že by to stále vyžadovalo „nějaká opatření proti zneužití” (věříme, že důvodem je riziko, že příjemce předobraz neodhalí, kvůli čemuž by zůstaly prostředky serveru uzamčené do konce kola, které by se mohlo prodloužit na dva i více měsíců).

        David Harding v odpovědi Roose žádá o další podrobnosti a přirovnává tuto situaci k JIT kanálům, které mají podobný problém s neodhalenými předobrazy ztěžující práci poskytovatelům lightningových služeb (LSP). LSP aktuálně řeší tento problém mechanismem založeným na důvěře (viz zpravodaj č. 256). Pokud by bylo možné použít stejné řešení v CTV-Arku, mohlo by zřejmě umožnit bezpečný příjem LN plateb uvnitř kola také v clArku.

      • ● Méně kol, méně podpisů, méně ukládání: clArk používá MuSig2 a každá strana se musí účastnit více kol. Tím je potřeba generovat množství částečných podpisů a ukládat kompletní podpisy. S CTV by bylo generováno a ukládáno méně data a bylo by vyžadováno méně interakce.

  • ● Sémantika OP_CHECKCONTRACTVERIFY: Salvatore Ingala zaslal do fóra Delving Bitcoin příspěvek s popisem sémantiky navrhovaného opkódu OP_CHECKCONTRACTVERIFY (CCV), s odkazem na první návrh BIPu a s odkazem na návrh implementace pro Bitcoin Core. Jeho popis začíná přehledem chování CCV: umožňuje zkontrolovat, že veřejný klíč zavazuje nějakým libovolným datům. Může zkontrolovat veřejný klíč utráceného i vytvářeného taprootového výstupu. Tím lze zajistit, že data z utráceného výstupu jsou přenesena do vytvářeného výstupu. V taprootu může tweak výstupu zavazovat listům tapscriptu. Pokud tweak zavazuje jednomu nebo více tapscriptům, klade na výstup platební podmínku (encumbrance; též „břemeno”), což umožní, aby byly podmínky kladené na utrácený výstup přenesené na výstup vytvářený – obecně (byť kontroverzně) se mu říká kovenant. Kovenant může platební podmínku naplnit nebo pozměnit, což by kovenant ukončilo nebo pozměnilo jeho podmínky pro budoucí iterace. Ingala popisuje některé výhody a nevýhody tohoto přístupu:

    • ● Výhody: přímé používání taprootu, nezvyšuje velikost taprootových položek v množině UTXO a pokud nejsou vyžadována extra data, nemusí být do witnessů začleňována (a tedy v takových případech žádné dodatečné náklady).

    • ● Nevýhody: funguje pouze s taprootem, kontrola tweaků vyžaduje operace nad eliptickou křivkou, které jsou nákladnější než např. SHA256 operace.

    Samotný přenos platebních podmínek z utráceného výstupu na vytvářený výstup může být užitečný, avšak mnoho kovenantů bude chtít zajistit, aby byly všechny nebo některé bitcoiny z utráceného výstupu předány na vytvářený výstup. Ingala popisuje tři možnosti, jak s částkami naložit:

    • ● Ignorovat: částky nekontrolovat.

    • ● Odečíst: částka vytvářeného výstupu s konkrétním indexem (např. třetí výstup) je odečtena z částky utráceného výstupu se stejným indexem. Zbytky jsou uloženy na později. Příklad: má-li utrácený výstup s indexem tři hodnotu 100 BTC a vytvářený výstup s indexem tři hodnotu 70 BTC, potom si kód zapamatuje zbytek 30 BTC. Transakce je označena za nevalidní, pokud je vytvářený výstup větší než utrácený výstup (což by snížilo zbytek, třeba i pod nulu).

    • ● Výchozí: označit transakci za nevalidní, pokud není částka vytvářeného výstupu s konkrétním indexem větší než částka utráceného výstupu plus součet předchozích zbytků, které nebyly ještě s výchozí kontrolou použité.

    Transakce je validní, pokud je některý výstup zkontrolován dvakrát s odečíst nebo pokud jsou odečíst a výchozí použité na stejný výstup.

    Ingala poskytuje několik vizuálních příkladů kombinací těchto operací. Následuje náš textový popis jeho příkladu „pošli část hodnoty,” který by mohl být užitečný pro úschovny: transakce má jeden vstup (utrácí jeden výstup) o hodnotě 100 BTC a dva výstupy, jeden s 70 BTC a druhý s 30 BTC. CCV je během validace transakce proveden dvakrát:

    1. CCV provede odečíst na index 0: 100 BTC utrácených, 70 BTC vytvářených, zbytek 30 BTC. V úschovně typu BIP345 by CCV vracelo těchto 70 BTC zpět na stejný skript.

    2. Podruhé použije výchozí na index 1. I když existuje vytvářený výstup s indexem 1, žádný vstup mu neodpovídá, implicitně je tedy použita hodnota 0. K této nule je připočten zbytek 30 BTC z odečíst na indexu 0, což si vyžádá, aby byl tento vytvářený výstup roven 30 BTC (nebo vyšší). V úschovně typu BIP345 by CCV mohl tweaknout výstupní skript, aby umožnil utratit tuto hodnotu na libovolnou adresu po vypršení časového zámku nebo ho kdykoliv vrátit na uživatelovu adresu hlavní úschovny.

    V příspěvku a v odpovědích se diskutují i alternativní přístupy, které Ingala zvažoval a zavrhl. Píše: „Myslím, že tato dvě chování (výchozí a odečíst) jsou velmi ergonomická a v praxi pokrývají většinu požadovaných kontrol částek.“

    Dále poznamenává, že „naimplementoval kompletní úschovny pomocí OP_CCV s OP_CTV, které jsou zhruba na úrovni [… BIP345 …]. Navíc je méně vybavená verze používající jen OP_CCV naimplementovaná jako funkční test v Bitcoin Core implementaci OP_CCV.”

  • ● Zveřejněn návrh BIPu na pročištění konsenzu: Antoine Poinsot zaslal do emailové skupiny Bitcoin-Dev příspěvek s odkazem na svůj návrh BIPu pro soft fork pročištění konsenzu (consensus cleanup). Obsahuje několik oprav:

    • ● Opravy dvou různých útoků ohýbáním času, kterými by mohla většina hašovacího výkonu produkovat bloky zrychleným tempem.

    • Limit na provádění operací s podpisy (sigops) u zastaralých typů transakcí, který zabrání vytváření bloků s přespříliš pomalou validací.

    • ● Oprava jedinečnosti mincetvorné transakce dle BIP34, která by měla zcela zabránit duplikovaným transakcím.

    • Zneplatnění budoucích 64bajtových transakcí pro zabránění určitého druhu zranitelnosti Merkleova stromu.

    Technicky zaměřené odpovědi byly nakloněné všem částem návrhu kromě dvou. První námitka se týkala zneplatnění 64bajtových transakcí. Odpovědi opakovaly předchozí kritiku (viz zpravodaj č. 319). Existuje alternativní metoda řešení zranitelností Merkleova stromu, která je poměrně snadno použitelná pro lehké (SPV) peněženky, ale může být náročná pro SPV validaci chytrých kontraktů, jako jsou přemostění mezi bitcoinem a jinými systémy. Sjors Provoost navrhl, aby někdo implementující takové přemostění poskytl kód ilustrující rozdíl mezi dvěma možnostmi: předpokládat, že 64bajtové transakce neexistují, a muset použít alternativní metodu pro odstranění zranitelností.

    Druhá námitka se týkala pozdní změny, která byla popsána v Poinsotově příspěvku v Delving Bitcoin. Změna požaduje, aby měly bloky vytvořené po aktivaci soft forku nastavený příznak, který by aktivoval vynucování časových zámků jejich mincetvorných transakcí. Jak bylo již dříve navrženo, mincetvorné transakce v blocích po aktivaci budou mít časový zámek nastaven na výšku bloku (mínus 1). Tato změna znamená, že žádný těžař nebude moci vytvořit časný alternativní bitcoinový blok, který používá poaktivační časový zámek a také nastavuje příznak vynucování (protože pokud by tak učinil, jeho mincetvorná transakce by nebyla kvůli použití budoucího časového zámku platná v bloku, který ji obsahuje). Nemožnost použít přesně ty stejné hodnoty v minulých mincetvorných transakcích jako v budoucích zabrání problému duplikovaných transakcí. Námitka proti tomuto návrh byla, že není jasné, zda budou všichni těžaři schopni nastavit příznak vynucování časového zámku.

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.2.0 přidává flexibilitu při posílání plateb na uživatelské skripty, opravuje okrajový případ související s mincetvornými transakcemi a obsahuje další novinky a opravy chyb.

  • ● LDK v0.1.2 je vydáním této knihovny pro budování aplikací s LN. Obsahuje několik vylepšení výkonnosti a oprav chyb.

  • ● Bitcoin Core 29.0rc3 je kandidátem na vydání příští hlavní verze tohoto převládajícího plného uzlu. Prosíme, přečtěte si průvodce testováním verze 29.

  • ● LND 0.19.0-beta.rc1 je kandidátem na vydání tohoto oblíbeného LN uzlu. Jedním významným vylepšením, které by si zasloužilo důkladné testování, je nové schéma RBF navyšování poplatků během kooperativního zavření kanálu.

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 #31363 přidává třídu TxGraph (viz zpravodaj č. 341), lehký model transakcí v mempoolu, který sleduje pouze jednotkové poplatky a závislosti mezi transakcemi. Přináší funkce pro modifikace jako AddTransaction, RemoveTransaction a AddDependency a funkce pro inspekci jako GetAncestors, GetCluster a CountDistinctClusters. TxGraph též podporuje přípravnou fázi změn s funkcemi commit nebo abort. Jedná se o součást projektu mempoolu clusterů a je přípravou na budoucí vylepšení vylučování z mempoolu, řešení reorganizací a těžební logiky se znalostí clusterů.

  • ● Bitcoin Core #31278 zastarává RPC příkaz settxfee a volbu -paytxfee, které umožňují nastavit všem transakcím statický poplatek. Uživatelé by měli spoléhat na odhad poplatků nebo nastavit poplatek pro každou transakci zvlášť. Budou odstraněné v Bitcoin Core 31.0.

  • ● Eclair #3050 mění způsob přeposílání hlášení o selhání BOLT12 plateb v případech, kdy je příjemce přímo připojeným uzlem. Nově bude vždy zprávu přeposílat namísto posílání nečitelné chyby invalidOnionBlinding. Pokud chyba obsahuje channel_update, Eclair ji promění v TemporaryNodeFailure, aby neodhaloval údaje o neoznámených kanálech. U zaslepených cest obsahujících jiné uzly bude Eclair nadále posílat invalidOnionBlinding. Všechny chybové zprávy jsou šifrované pomocí blinded_node_id.

  • ● Eclair #2963 implementuje přeposílání balíčků s jedním rodičem a jedním potomkem (1p1c). Za tímto účelem volá během vynucených zavření kanálů RPC příkaz Bitcoin Core submitpackage. Tím zveřejní commitment transakci i její anchor najednou. Díky tomu mohou být commitment transakce propagované, i když je jejich jednotkový poplatek pod minimem mempoolu. Vyžaduje však, aby byl uzel připojen ke spojením s Bitcoin Core 28.0 nebo novějším. Tato změna odstraňuje potřebu dynamicky nastavovat poplatek commitment transakcí a zajišťuje, že se vynucená zavření nezaseknou, pokud se uzly nemohou shodnout na aktuálním poplatku.

  • ● Eclair #3045 mění pole ve vnější payment_secret onion datové části na volitelné u trampolínových plateb s jedinou částí. Dříve každá trampolínová platba obsahovala payment_secret, i když se nejednalo o platbu s více částmi (multipath payment, MPP). Jelikož platební tajné kódy mohou být vyžadované při zpracování moderních BOLT11 faktur, Eclair během dešifrování vloží maketu, pokud je potřeba.

  • ● LDK #3670 přidává podporu pro přijímání a zpracování trampolínových plateb, ale zatím pro ně neposkytuje routování. Jedná se o předpoklad pro nasazení asynchronních plateb.

  • ● LND #9620 přidává podporu pro testnet4.