Tento týden přinášíme pokračování několika nedávných diskuzí o návrzích změn bitcoinového skriptovacího jazyka. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Diskuze o změnách ve skriptu pokračují: do diskuzí v emailové skupině Bitcoin-Dev, kterým jsme se věnovali dříve, přibylo několik nových reakcí.

    • ● Výzkum kovenantů: Anthony Towns zaslal odpověď na příspěvek od Rustyho Russella, který jsme zmínili v minulém čísle. Towns porovnává Russellův přístup s jinými přístupy – zaměřenými zvláště na úschovny založené na kovenantech – a považuje ho za neatraktivní. V následující odpovědi Russell poznamenává, že pro úschovny existují různé návrhy a že jsou úschovny v porovnání s jinými druhy transakcí neoptimální. Dále vyvozuje, že optimalizace není pro uživatele úschoven kritická. Tvrdí, že návrh úschoven dle BIP345 je vhodnější jako formát adres spíše než soubor opkódů. Podle našeho soudu tento výrok znamená, že BIP345 dává větší smysl jako šablona (podobně jako P2WPKH) navržená pro jednu funkci než jako soubor opkódů, který je navržen pro tu jednu funkci, ale který má možnost spolupracovat se zbytkem skriptu potenciálně nepředpokládanými způsoby.

      Towns rovněž uvažuje nad použitím Russellova přístupu jako způsobu, jak obecně umožnit experimentování, a myslí si, že je „sice zajímavější […], ale pořád dost kulhá.” Připomíná čtenářům svůj předešlý návrh na alternativu bitcoinového Scriptu ve stylu Lispu (viz zpravodaj č. 191, angl.) a ukazuje, jak by mohl přinést větší flexibilitu a možnosti v provádění introspekce transakcí během vyhodnocování witnessů. Poskytuje odkazy na svůj testovací kód a ukazuje na příklady, které napsal. Russell odpověděl: „Stále věřím, že než ho budeme muset nahradit, existuje prostor pro zlepšení. Je těžké porovnávat belhající se [S]cript v dnešní podobě s alternativami, protože ty nejzajímavější případy jsou nemožné.“

      Towns a Russel též v krátkosti hovořili o OP_CHECKSIGFROMSTACK, jmenovitě o jeho schopnosti umístit autentizovaná data od orákulí přímo do zásobníku.

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.

  • ● LDK 0.0.118 je nejnovějším vydáním této knihovny pro budování LN aplikací. Obsahuje vedle dalších nových funkcí a oprav chyb i částečnou experimentální podporu protokolu nabídek.

  • ● Rust Bitcoin 0.31.1 je nejnovějším vydáním této knihovny pro práci s bitcoinovými daty. Pro seznam nových funkcí a oprav chyb viz poznámky k vydání.

Poznámka: Bitcoin Core 26.0rc1, který jsme zmínili v předešlém čísle, má ve zdrojovém kódu svůj štítek, avšak binární sestavení nebyla zveřejněna kvůli změně od Apple, která zabraňuje vytvoření reprodukovatelných binárek pro macOS. Vývojáři Bitcoin Core pracují na odstranění problému v rámci druhého kandidáta na vydání.

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 #28685 opravuje chybu ve výpočtu hashe množiny UTXO, kterou jsme zmínili v předchozím čísle. Obsahuje nekompatibilní změnu v RPC volání gettxoutsetinfo, ve kterém nahrazuje pole hash_serialized_2 novým polem hash_serialized_3 obsahujícím správný hash.

  • ● Bitcoin Core #28651 umožňuje miniscriptu přesněji odhadovat nejvyšší počet bytů, které bude nutné začlenit do struktury witnessu, aby mohl být taprootový výstup utracen. Zvýšená přesnost pomůže Bitcoin Core zabránit přeplácení na poplatcích.

  • ● Bitcoin Core #28565 staví nad #27511 a přidává RPC volání getaddrmaninfo zobrazující počet adres spojení, která jsou buď „new” (nová) nebo „tried” (vyzkoušená), seskupených dle sítě (IPv4, IPv6, Tor, I2P, CJDNS). Pro motivaci, která stojí za tímto členěním, viz zpravodaj č. 237 a podcast č. 237.

  • ● LND #7828 vyžaduje, aby spojení odpovídala na zprávy ping v rozumné době, jinak budou odpojena. Pomůže to zajistit, aby spojení zůstávala aktivní (což sníží pravděpodobnost, že by mrtvé spojení pozdrželo platbu a vynutilo si tak nežádoucí zavření kanálu). Existuje mnoho dalších výhod posílání pingů a pongů: mohou pomoci zastřít síťovou aktivitu, ztížit trasování plateb (jelikož ping, pong i platby jsou šifrované), pomáhají častěji obměňovat šifrovací klíče (viz BOLT1) a LND používá zprávy pong k zabránění útoků zastíněním („eclipse attacks”, viz zpravodaj č. 164, angl.).

  • ● LDK #2660 poskytuje volajícím více flexibility ve výběru jednotkového poplatku pro onhcain transakce, včetně nastavení pro absolutní minimum, nízký poplatek způsobující i více než den čekání na potvrzení, normální prioritu a zvýšenou prioritu.

  • ● BOLTs #1086 stanovuje, že uzly by měly odmítnout (refundovat) HTLC a vrátit chybu expiry_too_far, pokud by instrukce pro vytvoření přeposílaného HTLC požadovaly, aby místní uzel čekal více než 2 016 bloků, než by si mohl nárokovat refundaci. Snížení tohoto nastavení redukuje nejhorší možnou ztrátu příjmu uzlu způsobenou útokem zahlcením kanálu („channel jamming attack”) nebo dlouhotrvající pozdrženou fakturou („hold invoice”). Navýšení tohoto nastavení umožňuje platbám, aby byly přeposlány více kanály za použití nastavení stejných maximálních HTLC delta (nebo stejný počet skoků s vyšším maximálním HTLC delta, což může zlepšit obranu proti určitým útokům, jako je replacement cycling popsaný v minulém čísle).