Tento týden popisujeme implementaci dočasných anchor výstupů a přinášíme naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o nových vydáních a popisem významných změn populárních páteřních bitcoinových projektů.

Novinky

• ● Implementace dočasných anchor výstupů: Greg Sanders v emailové skupině Bitcoin-Dev oznámil, že vytvořil implementaci svého nápadu na dočasné („ephemeral”) anchor výstupy (viz zpravodaj č. #223, angl.). Anchor výstupy jsou existující technika dostupná díky CPFP carve out a používaná v LN protokolu k zajištění, aby obě strany kontraktu mohly pomocí CPFP navýšit poplatek transakcí spojených s tímto kontraktem. Anchor výstupy mají několik nevýhod; některé principální (viz zpravodaj č. #224, angl.), avšak jiné mohou být řešeny.

  Dočasné anchor výstupy staví na návrhu přeposílání v3 transakcí. Díky němu mohou v3 transakce obsahovat výstup s nulovou hodnotou platící skriptu, který je v podstatě jen OP_TRUE. Kdokoliv s utratitelným UTXO může takové transakci navýšit poplatek pomocí CPFP. Potomek transakce, který navýšení provádí, může sám mít poplatek navýšen pomocí RBF kýmkoliv jiným s utratitelným UTXO. To by v kombinaci s dalšími částmi návrhu přeposílání v3 transakcí mělo odstranit veškeré obavy o transaction pinning útoky, tedy útoky na transakce protokolů chytrých kontraktů citlivých na načasování.

  Protože poplatek transakce s dočasným anchor výstupem může být navýšen kýmkoliv, mohou být použity na protokoly chytrých kontraktů s více než dvěma účastníky. Existující pravidlo carve out v Bitcoin Core funguje spolehlivě pouze pro dva účastníky a předchozí pokusy tento počet navýšit vyžadovaly stanovení maximálního počtu účastníků.

  Sandersova implementace dočasných anchor výstupů umožňuje začít tento nápad testovat spolu s dalšími funkcemi přeposílání v3 transakcí dříve implementovanými autorem tohoto návrhu.

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í.

Navyš poplatky nepotvrzených rodičů na úroveň cílového poplatku je PR autorů Xekyo (Murch) a glozow, který zvyšuje přesnost kalkulace poplatku v případě, kdy jsou jako vstupy zvoleny nepotvrzená UTXO. Bez této změny dochází k nastavení příliš nízkého poplatku, je-li některá nepotvrzená transakce použita jako vstup a je-li její jednotkový poplatek nižší než poplatek právě vytvářené transakce. PR řeší tento problém přidáním dostatečného poplatku, aby tato zdrojová transakce s nízkým poplatkem dosáhla stejného cílového jednotkového poplatku jako nová transakce.

I bez tohoto PR se proces výběru mincí snaží vyvarovat utrácení nepotvrzených transakcí s nízkým jednotkovým poplatkem. Změna přinese výhody v případech, kdy není zbytí.

Úprava poplatku na základě těchto rodičovských transakcí se ukázala být podobná výběru transakcí, které budou začleněny do bloku; proto tato změna přináší novou třídu nazvanou MiniMiner.

Sezení se událo během dvou týdnů.

• Jaký problém tento PR řeší?

  Odhad poplatku peněženkou nebere v potaz potřebu platit také všechny nepotvrzené rodičovské transakce, které mají nastavený nižší poplatek, než je cílový. ➚

• Z čeho se skládá cluster transakce?

  Množina transakcí obsahuje samotnou transakci a všechny „připojené” transakce. Zahrnují všechny předky i potomky, ale též sourozence a sestřenice, tedy potomky rodičů, kteří nemusí být ani předky, ani potomky dané transakce. ➚

• Tento PR přináší MiniMiner, který duplikuje některé algoritmy skutečné těžby. Nebylo by lepší spojit tyto dvě implementace?

  Potřebujeme pracovat pouze s clusterem, nikoliv s kompletním mempoolem. Též nepotřebujeme provádět žádné kontroly jako BlockAssembler. Někdo dokonce navrhl učinit všechny výpočty bez zámku mempoolu. Museli bychom také změnit block assembler, aby spíše sledoval navýšení poplatků než konstrukci šablony bloku. Množství práce potřebné pro refaktorování by bylo stejné jako přepsání. ➚

• Proč vyžaduje MiniMiner kompletní cluster? Nestačil by jen výčet všech předků každé transakce?

  Někteří předci mohou mít již poplatek navýšený jiným potomkem, a není tedy třeba dalšího navyšování. Proto potřebujeme ve výpočtech zahrnout i tyto potomky. ➚

• Má-li transakce X vyšší jednotkový poplatek předků než nezávislá transakce Y, je možné, že by těžař upřednostnil Y před X (tj. zařadil Y do bloku dříve než X)?

  Ano. Má-li některý z předků transakce Y, které mají nízké poplatky, i jiné potomky s vysokým poplatkem, Y za předky platit nemusí. Množina předků transakce Y je aktualizována, aby byly vyloučeny transakce, které v důsledku navyšují poplatky předků transakce Y. ➚

• CalculateBumpFees() může nadhodnotit, podhodnotit, obé či ani jedno? O kolik?

  K nadhodnocení dojde, jsou-li vybrány dva výstupy s překrývajícími se předky, neboť každé navýšení bere v potaz své předky nezávisle a neuvažuje se možnost společných předků. Účastníci došli k závěru, že podhodnocení navýšení poplatků možné není. ➚

• MiniMinerobdrží seznam UTXO (výstupů), které by peněženka chtěla utratit. Jakých pěti možných stavů může daný výstup nabývat?

  Může být (1) potvrzený a neutracený, (2) potvrzený a právě utrácený existující transakcí v mempoolu, (3) nepotvrzený (v mempoolu) a neutracený, (4) nepotvrzený, ale již utracený existující transakcí v mempoolu nebo (5) to může být výstup, o kterém jsme nikdy neslyšeli. ➚

• Jaký přístup zaujímá commit “Navyš poplatky nepotvrzených rodičů na úroveň cílového poplatku”?

  Tento commit je hlavní změnou chování tohoto PR. MiniMiner provádí výpočet navýšení poplatků (tak, aby příslušní předci nabyli cílového jednotkového poplatku) každého UTXO a odečítá je od jejich efektivní hodnoty. Poté následuje běžný výběr mincí. ➚

• Jak tento PR řeší utrácení nepotvrzených UTXO s překrývajícími se předky?

  Po výběru mincí spustíme nad jeho výsledkem variantu algoritmu MiniMineru. Tím obdržíme přesnou hodnotu navýšení poplatku. Pokud je kvůli společným předkům navýšení příliš velké, můžeme poplatek snížit navýšením zbytku po platbě (pokud existuje) nebo přidáním zbytku (pokud neexistuje). ➚

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.

• ● BTCPay Server 1.7.1 je nejnovějším vydáním nejrozšířenějšího serveru pro zpracování bitcoinových plateb.

• ● Core Lightning 22.11 je příští hlavní verzí CLN. Je také první verzí, která bude používat nový systém číslování verzí.¹ Součástí vydání je několik nových funkcí včetně nového správce rozšíření a opravy několika chyb.

• ● LND 0.15.5-beta je údržbové vydání LND. Dle poznámek k vydání obsahuje pouze opravy drobných chyb.

• ● BDK 0.25.0 je novým vydáním této knihovny pro tvorbu peněženek.

Významné změny v kódu a dokumentaci

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) a Lightning BOLTs.

• ● Bitcoin Core #19762 upravuje rozhraní RPC (a potažmo i bitcoin-cli) přidáním možnosti použít poziční i jmenné argumenty dohromady. Tato změna usnadňuje použití jmenných parametrů bez nutnosti jmenovat je všechny.

• ● Core Lightning #5722 přidává dokumentaci o používání rozšíření GRPC rozhraní.

• ● Eclair #2513 upravuje způsob používání peněženek Bitcoin Core, aby zajistil, že vždy používají bech32 adresy. Je to důsledkem změny Bitcoin Core #23789 (viz zpravodaj č. 181, angl.), ve které byl adresovány obavy o ztrátu soukromí uživateli nových typů výstupů (např. taproot). Nastavil-li uživatel v předchozích verzích ve své peněžence taproot jako výchozí typ adresy, byly automaticky nastaveny na taproot také adresy pro zaslání zbytku po platbě („drobné”). Poslal-li platbu někomu, kdo taproot nepoužíval, mohly třetí strany snadno odhadnout, který výstup byla platba (netaproot) a co byly drobné (taproot). Po zmíněné změně se Bitcoin Core snaží použít pro zbytek stejný druh výstupu jako pro platbu. Zbytek po platbě na nativní segwit adresu by tak byl poslán též na nativní segwit výstup.

  LN protokol však vyžaduje určité druhy výstupů. Například P2PKH výstup nemůže být použit na otevření LN kanálu. Z tohoto důvodu musí uživatelé Eclair s Bitcoin Core zajistit, aby negenerovali adresy pro zaslání zbytku nekompatibilní s LN.

• ● Rust Bitcoin #1415 začíná používat Kani Rust Verifier, který umožní dokázat některé vlastnosti kódu. Doplňuje tak další testy prováděné v rámci průběžné integrace, jako je např. fuzzing.

• ● BTCPay Server #4238 přidává možnost refundovat fakturu pomocí Greenfield API, což je novější API odlišné od původního API inspirovaného BitPayem.

Poznámky

1. Předchozí vydání našeho zpravodaje tvrdila, že Core Lightning používá sémantické verzování a že nové verze jej budou používat i nadále. Rusty Russell vysvětlil, proč se nemůže CLN zcela držet tohoto systému. Děkujeme Mattovi Whitlockovi za upozornění na naši chybu. ↩