Tento týden přinášíme popis aktualizace návrhu dočasných anchorů a začleňujeme externí terénní zprávu o miniscriptu od vývojáře pracujícího ve Wizardsardine. Též nechybí naše pravidelné rubriky s oznámeními o nových vydáních a souhrnem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Odstranění poddajnosti dočasných anchorů: Gregory Sanders zaslal do fóra Delving Bitcoin příspěvek s úpravou navrhovaných dočasných anchorů („ephemeral anchors”). Návrh by umožnil, aby transakce obsahovaly výstup s nulovou hodnotou a anyone-can-spend výstupním skriptem. Protože by tento výstup mohl utratit kdokoliv, kdokoliv by také mohl transakci, která výstup vytvořila, navýšit poplatek pomocí CPFP. To je výhodné pro protokoly s kontrakty s více účastníky jako LN, kde se transakce často podepisují před tím, než je možné přesně určit, jaký jednotkový poplatek by měly platit. Dočasné anchory umožňují, aby kterákoliv strana kontraktu přidala takový poplatek, jaký považuje za nezbytný. Pokud by kterákoliv strana (nebo z jakéhokoliv důvodu i kterýkoliv jiný uživatel) chtěla přidat vyšší poplatek, mohou navýšení pomocí CPFP nahradit svým vlastním CPFP navýšením.

    Jako anyone-can-spend skript je navrhován výstupní skript obsahující ekvivalent OP_TRUE, který lze utratit vstupem s prázdným vstupním skriptem. Jak Sanders tento týden poznamenal, zastaralý druh výstupního skriptu znamená, že potomek, který jej utrácí, bude mít poddajné txid, tedy kterýkoliv těžař může do vstupního skriptu přidat data, aby tím změnil txid potomka. Kvůli tomu by nebylo moudré použít potomka k jinému účelu, než je navýšení poplatku, neboť v opačném případě by mohl být potvrzen s jiným txid, což by tranzitivně zneplatnilo jakéhokoliv potomka tohoto potomka.

    Sanders proto navrhuje použití jednoho z výstupních skriptů, které byly rezervovány pro budoucí upgrady segwitu. Sice by to vyžadovalo o trochu více blokového prostoru (čtyři byty u segwitu oproti jednomu bytu v případě holého OP_TRUE), ale na druhou stranu by to odstranilo rizika poddajnosti transakce. Později Sanders navrhl možnost používat obě varianty: OP_TRUE, pokud uživatele poddajnost nezajímá, ale chce co nejmenší velikost transakce, a segwitovou verzi, která je větší, avšak nedovoluje pozměnit potomka. Diskuze ve vlákně se dále soustředila na výběr bytů v segwitové variantě tak, aby vznikaly zapamatovatelné bech32m addresy.

Terénní zpráva: Cesta k miniscriptu

napsal Antoine Poinsot z Wizardsardine

Z praktického hlediska jsme se o miniscript začali zajímat počátkem roku 2020 během navrhování Revault. Jedná se o systém úschovny s více účastníky využívající pouze tehdy dostupná skriptová primitiva.

V první fázi jsme pracovali s pevně daným počtem účastníků. Když jsme se pokoušeli o generalizaci našeho přístupu na více účastníků, narazili jsme na překážky.

  • Jsme si opravdu jisti, že skript, který jsme používali během předvádění, je bezpečný? Je možné jej opravdu utratí všemi inzerovanými způsoby? Neexistuje i jiná, nám neznámá možnost utracení?
  • A i kdyby existovala, jak zaručit bezpečnost při generalizaci na různé počty účastníků? Jak můžeme provádět optimalizace a přitom zajistit, aby se neměnila sémantika výsledného skriptu?
  • Revault používá předem podepsané transakce (by mohl vynutit pravidla utracení). Jak můžeme dopředu vědět, jaký rozpočet v závislosti na nastavení skriptu je potřeba alokovat na navyšování poplatků? Jak můžeme zajistit, aby jakákoliv transakce utrácející tyto skripty splňovala základní pravidla standardnosti?
  • A konečně, i kdybychom předpokládali, že naše skripty fungují, jak bylo zamýšleno, a lze je vždy utratit, jak konkrétně je možné je utratit? Jak můžeme sestavit witness, který bude uspokojovat každou možnou konfiguraci? A jak zajistit kompatibilitu hardwarových podpisových zařízení s našimi skripty?

Bez existence miniscriptu bychom se přes tyto otázky nedostali. Dva chlápci v garáži by nebyli schopni napsat software, který by za běhu vytvořil nějaký skript, doufali by, že se nic nestane, a navrch by jej mohli označovat za bezpečnou bitcoinovou peněženku. Naším záměrem bylo založit kolem vývoje Revault firmu, ale bez poskytnutí nějaké záruky investorům, že jsme schopni dodat na trh bezpečný produkt, bychom na prostředky nedosáhli.

Pohleďte na miniscript, „jazyk pro psaní (podmnožiny) bitcoinových skriptů strukturovaným způsobem, umožňující analýzu, kompozici, generické podepisování a další. […] Má strukturu umožňující kompozici. Je jednoduché staticky analyzovat různé jeho vlastnosti (platební podmínky, správnost, bezpečnost, poddajnost atd.).” Přesně to jsme potřebovali. S tímto mocným nástrojem jsme mohli nabídnout našim investorům silnější garance [0], vybrat finance a začít Revault vyvíjet.

V té době nebyl miniscript ještě zdaleka tím řešením, po kterém by se vývojáři bitcoinových aplikací otáčeli. (Čtete-li tento text jako čerstvý bitcoinový vývojář po roce 2023, věřte, že bývaly doby, kdy jsme psali bitcoinové skripty RUČNĚ.) Museli jsme začlenit miniscript do Bitcoin Core (viz PR #24147, #24148 a #24149), který jsme pro peněženku Revault používali jako backend, a přesvědčit výrobce podpisových zařízení, aby přidali podporu do svých firmware. To druhé se ukázalo jako nejtěžší.

Byl to problém slepice a vejce: malá poptávka od uživatelů nepřinášela výrobcům k implementaci miniscriptu dostatečně silný podnět. A bez podporu podpisových zařízení jsme Revault vydat nemohli. Naštěstí byla nakonec tato smyčka přerušena, když v březnu 2021 přinesl Stepan Snigirev podporu pro miniscriptové deskriptory do Specter DIY. Specter DIY byl však po dlouhou dobu prezentován jako pouhý „funkční prototyp.” Byl to v roce 2022 až Salvatore Ingala, který přinesl miniscript do produkčního podpisového zařízení Ledger Nano S(+) v rámci nové bitcoinové aplikace. Ta byla vydána v lednu 2023 a umožnila nám zveřejnit peněženku Liana s podporou nejpopulárnějšího podpisového zařízení.

Zbývá ještě pokrýt náš poslední vývoj. Liana je bitcoinová peněženka zaměřená na možnosti obnovy. Umožňuje uživatelům specifikovat podmínky obnovy s časovým zámkem (například obnovovací klíč poskytnutý třetí stranou, který nemůže prostředky normálně utratit, nebo multisig měnící počet potřebných podpisů během času). Miniscript byl na počátku dostupný pouze pro P2WSH skripty. Téměř dva roky po aktivaci taprootu je bohužel nutné s každou platbou publikovat onchain své obnovovací skripty. Pracujeme proto na portování miniscriptu do tapscriptu (viz jedno PR a druhé PR).

Budoucnost je nadějná. Většina podpisových zařízení již podporu miniscriptu obsahuje, další pracují na její implementaci (nedávno například Bitbox a Coldcard). Tvorba bitcoinových kontraktů s bezpečnými primitivy je dostupnější než kdykoliv předtím.

Je zajímavé pozorovat, jak financování open source nástrojů a frameworků snižuje inovativním společnostem vstupní bariéry. Tento trend, který v posledních letech zrychluje, nám může v této oblasti přinést naději.

[0] Pochopitelně stále existují rizika. Ale přinejmenším jsme věřili, že se dostaneme přes tento onchain milník. Offchain bude, nepřekvapivě, mnohem náročnější.

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 a Bitcoin Inquisition.

  • ● Bitcoin Core #28207 upravuje způsob, kterým je mempool uložen na disku (což se děje během vypínání uzlu, ale lze též vynutit RPC voláním savemempool). Dříve byl uložen jako prostá serializovaná data v paměti. Nově je tato serializovaná struktura XORována hodnotou náhodně vygenerovanou každým uzlem, aby tím byla data zatemněna. Během zapínání uzlu jsou zatemněná data XORována stejnou hodnotou. Zatemnění zabraňuje vložení určitých dat do transakce, která by se potom objevila mezi uloženými daty mempoolu a která by mohly antivirové a podobné programy označit za nebezpečná. Stejná metoda byla již dříve použita na ukládání množiny UTXO v PR #6650. Software, který potřebuje data mempoolu z disku načíst, by měl být sám schopen provést XOR nebo použít konfigurační volbu -persistmempoolv1, která bude ukládat data v nezatemněném formátu. Tato volba bude v budoucím vydání odstraněna.

  • ● LDK #2715 umožňuje uzlu volitelně přijmout menší hodnotu HTLC, než která má být doručena. To je užitečné, pokud spojení proti směru toku platí uzlu přes nový JIT kanál, za jehož onchain náklady musí platit a odečíst tyto náklady z hodnoty HTLC. Viz zpravodaj č. 257 pro detaily o implementaci druhé části této vlastnosti.