Zpravodaj tento týden varuje před chybou v migraci peněženek v Bitcoin Core, shrnuje příspěvek o používání protokolu Ark jako továrny LN kanálů a odkazuje na návrh BIPu pro deskriptory tichých plateb. Též nechybí naše pravidelné rubriky s popisem kandidátů na vydání a významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Chyba v migraci peněženky v Bitcoin Core: Bitcoin Core zveřejnil poznámku o chybě v procesu migrace zastaralého druhu peněženek ve verzích 30.0 a 30.1. Pokud se uživatelé zastaralých peněženek v Bitcoin Core, kteří používají nepojmenovanou peněženku a dosud nemigrovali na deskriptorovou peněženku, pokusí o migraci v těchto verzích, mohl by jejich adresář s peněženkami být smazán, což by mohlo vést až ke ztrátě prostředků. Tito uživatelé by se neměli pokoušet o migraci prostřednictvím grafického rozhraní či RPC, dokud nebude vydána verze 30.2 (viz Bitcoin Core 30.2rc1 níže). Uživatelé, kteří se na migraci zastaralého druhu peněženky nechystají, mohou nadále bez obav tyto verze používat.

• ● Ark jako továrna kanálů: René Pickhardt popsal ve fóru Delving Bitcoin své myšlenky a diskuzi nad otázkou, zda Ark není vhodnější jako flexibilní továrna kanálů než jako řešení poskytující platby přímo koncovým uživatelům. Pickhardtův dřívější výzkum se soustředil na optimalizaci úspěšnosti plateb v Lightning Network pomocí hledání tras a rebalancování kanálů. Struktury ve stylu Arku obsahující lightningové kanály byly již dříve popsané např. v 1, 2 a 3.

  Pickhardtovy myšlenky se soustředí na možnost dávkově provádět množství operací měnících likviditu kanálů (tedy otevření a zavření kanálů a splicing) používáním struktury vTXO jako způsobu výrazného snížení onchain nákladů na provozování Lightning Network. Cenou by byly vyšší nároky na likviditu v čase mezi zřeknutím se jednoho kanálu a kompletní expirací jeho arkové dávky. Používáním arkových dávek jako efektivních továren kanálů by mohli poskytovatelé lightningových služeb (LSP) účinněji poskytovat likviditu více konečným uživatelům. Vestavěná expirace těchto dávek by zaručila, že LSP může získat zpět likviditu z nepoužívaného kanálu bez nutnosti provést nákladný onchain proces vynuceného zavření kanálu. Pro routovací uzly by byla výhodná možnost v pravidelných dávkách přesouvat likviditu mezi jednotlivými kanály bez nutnosti provádět jednotlivé splicingové operace.

  Greg Sanders se v odpovědi vyjádřil, že se zabývá podobnými možnostmi, konkrétně jak pomocí hArku provádět (převážně) online přesuny stavu lightningového kanálu mezi dávkami. hArk by vyžadoval CTV, OP_TEMPLATEHASHnebo podobný opkód.

• ● Návrh BIPu pro deskriptory tichých plateb: Craig Raw zaslal do emailové skupiny Bitcoin-Dev příspěvek s návrhem BIPu, který definuje sp(), nový deskriptor pro výstupní skripty nejvyšší úrovně pro tiché platby. Dle Rawa poskytuje standardizovaný způsob reprezentace výstupů tichých plateb v rámci výstupních deskriptorů.

  Výraz sp() vyžaduje jako argument jeden ze dvou výrazů určujících klíč:

  • spscan1q..: Soukromý klíč pro skenování a veřejný klíč pro utrácení kódované pomocí bech32m; znak q reprezentuje tiché platby verze 0.

  • spspend1q..: Soukromý klíč pro skenování a soukromý klíč pro utrácení kódované pomocí bech32m; znak q reprezentuje tiché platby verze 0.

  Volitelně lze do sp() přidat další argumenty: BIRTHDAY, definovaný jako kladné celé číslo reprezentující výšku bloku, při které by skenování mělo začít (musí být vyšší než 842 579, tj. výška, při které byl BIP352 začleněn), a libovolné množství argumentů LABEL jako celých čísel používaných peněženkou.

  Výstupní skripty vytvořené deskriptorem sp() tvoří taprootové výstupy dle BIP341 specifikované v BIP352.

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.

• ● Bitcoin Core 30.2rc1 je kandidátem na vydání menší verze opravující chybu (viz Bitcoin Core #34156), která mohla během migrace nepojmenované zastaralé peněženky smazat celý adresář wallets (viz výše).

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 #34156 a Bitcoin Core #34215 opravují chybu ve verzích 30.0 a 30.1, která mohla způsobit nezamýšlené smazání celého adresáře wallets. Pokud migrace zastaralé, nepojmenované peněženky selže, měla by čisticí funkce odstranit pouze nově vytvořený adresář deskriptorové peněženky. Jelikož je však nepojmenovaná peněženka uložena na nejvyšší úrovni v adresáři wallets, je smazán celý adresář. Druhá změna se týká podobné chyby v případě použití příkazu createfromdump nástroje wallettool (viz též zpravodaje č. 45 a č. 130, oba angl.), je-li název peněženky prázdný řetězec a soubor má nesprávný kontrolní součet. Obě opravy zajišťují, že jsou smazány pouze nově vytvořené soubory.

• ● Bitcoin Core #34085 integruje dosud samostatnou funkci FixLinearization() do Linearize(). TxGraph nově odloží fixaci clusterů (tedy úpravu linearizace tak, aby respektovala topologický řád) až do doby jejich první relinearizace. Počet volání PostLinearize se tak sníží, neboť algoritmus linearizace koster grafu (spanning-forest linearization, SFL; viz též zpravodaj č. 386) provádí během načítání stávající linearizace podobnou operaci. Jedná se o součást projektu mempoolu clusterů.

• ● Bitcoin Core #34197 odstraňuje z RPC odpovědi na getpeerinfo pole startingheight, čímž ho prakticky zastarává. Toto pole je možné opět zobrazit přidáním volby deprecatedrpc=startingheight. Pole startingheight nastavuje druhá strana na výšku řetězce v okamžiku navázání spojení. Toto zastarání je založeno na myšlence, že počáteční výška uvedená ve zprávě VERSION od peer spojení je nespolehlivá. V příští hlavní verzi bude pole zcela odstraněno.

• ● Bitcoin Core #33135 přidává varování, pokud je příkaz importdescriptors volán s miniscriptovým deskriptorem, který v older() (určujícím časový zámek) obsahuje hodnotu, jež v rámci konsenzu dle BIP68 (relativní časové zámky) a BIP112 (OP_CSV) nedává smysl. Ačkoliv některé protokoly, jako je např. Lightning Network, záměrně přiřazují nestandardním hodnotám nový význam, je tato praxe považována za riskantní, neboť taková hodnota se může jevit jako dlouhodobý časový zámek, ačkoliv ve skutečnosti neznamená žádné zdržení.

• ● LDK #4213 přidává výchozí nastavení pro zaslepené cesty. Při sestavování zaslepené cesty, která není určena pro nabídky, je použita nekompaktní zaslepená cesta se zarovnáním na čtyři skoky (včetně příjemce) pro co nejvyšší soukromí. Pokud je zaslepená cesta určena pro nabídku, cílem je sestavit kompaktní zaslepenou cestu se sníženým zarovnáním minimalizující velikost v bajtech.

• ● Eclair #3217 přidává signál odpovědnosti (accountability) za HTLC, čímž nahrazuje mechanismus experimentálních HTLC atestací (HTLC endorsements). Tento krok je v souladu s poslední aktualizací specifikace BOLTs #1280 bránící před zahlcením kanálu. Nový návrh pokládá tento signál za příznak odpovědnosti během používání omezených zdrojů; indikuje, že je používána chráněná HTLC kapacita a že následné uzly mohou zodpovídat za včasné vyřízení.

• ● LND #10367 přejmenovává experimentální signál endorsement (BLIP4) na accountable v souladu s posledním návrhem z BLIPs #67 založeným na BOLTs #1280.

• ● Rust Bitcoin #5450 přidává do dekodéru transakcí validaci, která na základě pravidel konsenzu odmítne běžnou transakci (tedy ne mincetvornou) mající null jako předchozí výstup.

• ● Rust Bitcoin #5434 přidává do dekodéru transakcí validaci, která odmítne mincetvornou (coinbase) transakci se scriptSig o délce mimo rozsah 2–100 bajtů.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 13. 1. v 17:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.