Zpravodaj tento týden shrnuje příspěvek o onchain sázení o případném soft forku bez požadavku na důvěru a odkazuje na podrobný přehled Chia Lispu pro bitcoinery. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními o nových vydáních a popisem významných změně v populárním bitcoinovém páteřním software.

Novinky

  • ● Onchain sázky na případné soft forky bez požadavku na důvěru: ZmnSCPxj zaslal do fóra Delving Bitcoin příspěvek s popisem protokolu předávajícího kontrolu nad UTXO straně, která správně předpoví aktivaci nějakého konkrétního soft forku. Pro příklad uvažujme, že Alice věří v aktivaci konkrétního soft forku a chtěla by získat nějaké bitcoiny. Bob má stejný zájem, avšak domnívá se, že soft fork aktivován nebude. Kooperativně shromáždí určité množství bitcoinů v předem domluveném poměru (např. 1:1). Pokud by soft fork byl aktivován před určitým časovým limitem, Alice by obdržela kombinovanou částku. V opačném případě by připadla Bobovi. Pokud by před vypršením časového limitu došlo k trvalému štěpení blockchainu (jeden by fork aktivoval, druhý zakazoval), obdržela by Alice kombinovanou částku v aktivovaném blockchainu a Bob v blockchainu zakazujícím aktivaci.

    Základní myšlenka byla již dříve navržena (příklad), avšak ZmnSCPxjova verze se umí vypořádat se specifiky očekávanými v minimálně jednom případném budoucím soft forku: OP_CHECKTEMPLATEVERIFY. ZmnSCPxj též krátce uvažuje o potížích generalizace této myšlenky na jiné navrhované soft forky, obzvláště ty, které mění definici opkódu OP_SUCCESSx.

  • ● Chia Lisp pro bitcoinery: Anthony Towns zaslal do fóra Delving Bitcoin příspěvek s podrobným přehledem varianty Lispu používané kryptoměnou Chia. Towns již dříve navrhl přidat soft forkem do bitcoinu skriptovací jazyk založený na Lispu (viz zpravodaj č. 191, angl.). Lidem se zájmem o toto téma doporučujeme si jeho příspěvek přečíst.

Bitcoin Core PR Review Club

V této měsíční rubrice shrnujeme nedávné sezení Bitcoin Core PR Review Club a vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.

Opět aktivuj OP_CAT je PR od Armina Sabouriho (0xBEEFCAF3 na GitHubu), které vrací opkód OP_CAT, avšak pouze na signetový Bitcoin Inquisition a pro tapscript (taproot script). Satoshi Nakamoto tento opkód v roce 2010 pravděpodobně z přílišné opatrnosti deaktivoval. Operace nahrazuje první dva prvky v zásobníku jejich spojením („concatenation”).

Motivace pro OP_CAT diskutovány nebyly.

  • Za jakých podmínek může provedení OP_CAT vyústit v chybu?

    Méně než dva prvky v zásobníku, přílišná velikost výsledného prvku, zakázání nastavovacími příznaky (protože například ještě nebyl aktivován soft fork) a pokud se objevuje v netaprootovém skriptu (witness verze 0 nebo zastaralé typy). ➚

  • OP_CAT mění definici jednoho z OP_SUCCESSx opkódů. Proč však nemění definici jednoho z OP_NOPx opkódů (které též byly v minulosti používané na soft forky)?

    Opkódy OP_SUCCESSx a OP_NOPx mohou být předefinovány za účelem implementace soft forku, protože zpřísňují pravidla validace (volání jsou vždy úspěšná, zatímco po redefinici mohou selhat). Jelikož vykonávání skriptu pokračuje i po OP_NOP, nesmí předefinované OP_NOP opkódy ovlivňovat zásobník (jelikož by skripty, které dříve selhávaly, mohly končit úspěšně, což by pravidla zmírňovalo). Předefinované opkódy OP_SUCCESS mohou zásobník ovlivňovat, jelikož OP_SUCCESS vykonávání skriptu okamžitě úspěšně ukončuje. Jelikož OP_CAT zásobník mění, nemůže redefinovat OP_NOP opkód. ➚

  • Toto PR přidává SCRIPT_VERIFY_OP_CAT i SCRIPT_VERIFY_DISCOURAGE_OP_CAT. Proč jsou obě volby potřebné?

    Umožňují, aby byl soft fork nasazen po částech. Nejprve jsou obě nastavené na true (aktivace na úrovni konsenzu, ale žádné přeposílání ani těžba), dokud neupgraduje většina sítě. Poté je SCRIPT_VERIFY_DISCOURAGE_OP_CAT nastaven na false, aby umožnil používání. Pokud by experiment v Bitcoin Inquisition selhal, může být proces vrácen stejnými kroky v opačném směru. Pokud by byly obě volby nastavené na false, byl by OP_CAT jen pouhým opkódem OP_SUCCESS. ➚

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.

  • ● Core Lightning v24.02.1 je menší aktualizací tohoto LN uzlu přinášející „opravy několika drobných chyb a vylepšení nákladové funkce algoritmu routování.“

  • ● Bitcoin Core 26.1rc1 je kandidátem na vydání údržbové verze této převládající implementace plného uzlu.

  • ● Bitcoin Core 27.0rc1 je kandidátem na vydání příští hlavní verze této převládající implementace plného uzlu.

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.

  • ● LND #8136 přidává do RPC volání EstimateRouteFee fakturu a časový limit. Když je vybrána trasa pro platbu faktury, zašle se po ní sonda. Pokud sonda ukončí činnost před vypršením časového limitu, jsou vráceny náklady na vybranou trasu. V opačném případě bude vyvolána chyba.

  • ● LND #8499 přináší významné změny typů založených na TLV (Type-Length-Value) používaných pro jednoduché taprootové kanály. Účelem je zlepšení souvisejícího API. Nejsme si vědomi žádné jiné implementace, která by v současnosti nabízela jednoduché taprootové kanály, ale pokud je někdo používá, vězte, že se může jednat o zpětně nekompatibilní změnu.

  • ● LDK #2916 přidává jednoduché API pro převod předobrazu platby do jejího hashe. LN faktura obsahuje hash platby a aby bylo možné platbu nárokovat, musí konečný příjemce odhalit předobraz, který tomuto hashi odpovídá. Každý uzel po trase obdrží tento předobraz od uzlu po směru toku platby a může s jeho pomocí nárokovat platbu od uzlu proti směru toku platby. Jelikož lze hash z předobrazu odvodit (nikoliv však naopak), příjemci a přeposílající uzly potřebují ukládat pouze předobraz. Díky tomuto API mohou kdykoliv dle potřeby hash odvodit.