Tento týden přinášíme souhrn diskuze z emailové skupiny o použití návrhu MATT ke správě joinpoolů a napodobení funkcí navrhovaného OP_CHECKTEMPLATEVERIFY. Též nechybí další příspěvek do krátké týdenní série o pravidlech mempoolu a naše pravidelné rubriky s oznámeními o vydání software a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Využití MATT k napodobení CTV a správě joinpoolů: Johan Torås Halseth zaslal do emailové skupiny Bitcoin-Dev příspěvek o možnosti využít opkód OP_CHECKOUTPUTCONTRACTVERIFY (COCV) z navrhovaného konceptu Merklize All The Things (MATT, „všechno to zmerklujte“, viz zpravodaje č. 226, angl., a č. 249) k napodobení funkcionality jiného návrhu OP_CHECKTEMPLATEVERIFY. Pro vytvoření commitmentu transakce s více výstupy by každý výstup vyžadoval zvláštní COCV opkód (pro porovnání: jediný CTV by stačil na commitment všech výstupů). To činí COCV méně efektivním, avšak „dost jednoduchým na to, aby byl zajímavý.”

  Kromě popisu funkcionality nabízí Halseth také demo s použitím Tapsim, nástroje pro „debugování tapscriptových transakcí […] zaměřený na vývojáře, kteří si chtějí hrát se skriptem, debugovat a pozorovat stav VM během výkonu skriptu.”

  V jiném vlákně popsal Halseth použití MATT s OP_CAT k vytvoření joinpoolu (též nazývaného coinpool nebo payment pool). I zde poskytuje interaktivní demo pomocí Tapsim. Také na základě svých experimentů navrhl několik změn opkódů v MATT. Salvatore Ingala, původní autor návrhu MATT, se v odpovědi vyjádřil pozitivně.

Čekání na potvrzení 4: odhad poplatků

Krátká týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Minulý týden jsme prozkoumali techniky minimalizace poplatků placených za transakci při daném jednotkovém poplatku. Avšak jaký by tento jednotkový poplatek měl být? Nejlépe co nejnižší, abychom ušetřili peníze, ale dostatečně vysoký, aby nám zajistil místo v bloku podle uživatelovy časové preference.

Cílem odhadu (jednotkového) poplatku je převést cílený časový rámec pro konfirmaci na nejnižší jednotkový poplatek, který by transakce měla zaplatit.

Jednou z komplikací odhadu poplatku je nepravidelnost produkce blokového prostoru. Řekněme, že aby obdržel zboží, potřebuje uživatel obchodníkovi zaplatit během jedné hodiny. Uživatel očekává, že každých deset minut bude vytěžený jeden blok, a tak bude cílit pozici uvnitř příštích šesti bloků. Avšak je možné, že jeden z bloků bude nalezen až za 45 minut. Odhady poplatků musí vzít do úvahy uživatelovu naléhavost nebo časový rámec (ve smyslu „chci, aby byla tato transakce potvrzena do konce pracovního dne”) a nabídku blokového prostoru (počet bloků). Aby se s těmito obtížemi algoritmy odhadování poplatků vypořádaly, vyjadřují cíle konfirmací v čase i počtu bloků.

Naivní odhad poplatku lze postavit na historických údajích o výši poplatků, které postačují na začlenění do bloků. Jelikož takový odhad nezahrnuje transakce čekající v mempoolech na potvrzení, dosahoval by velmi nepřesných výsledků v dobách s neočekávaně vysokou fluktuací poptávky po blokovém prostoru a občasných dlouhých intervalech mezi bloky. Další slabostí je závislost na informacích zcela ovládaných těžaři, kteří by mohli dosáhnout zvyšování poplatků začleňováním falešných transakcí s vysokými jednotkovými poplatky do svých bloků.

Naštěstí trh blokového prostoru není aukcí naslepo. V našem prvním příspěvku jsme zmínili, že vedení mempoolu a účast v P2P síti přeposílání transakcí umožňuje uzlu vidět nabídky ostatních uživatelů. Odhad poplatků v Bitcoin Core používá k výpočtu pravděpodobnosti začlenění transakce s poplatkem f v příštích n blocích i historická data, avšak zaměřuje se hlavně na výšky, ve kterých uzel transakci poprvé zaznamená a kdy se potvrdí. Tato metoda ignoruje aktivitu, která se děje mimo veřejný trh. Pokud těžaři začleňují do svých bloků transakce s uměle nafouknutými poplatky, tento odhad poplatků by tím ovlivněn nebyl, neboť používá jen data transakcí, které byly před potvrzením veřejně šířeny.

Dále máme dobrý přehled o způsobu vybírání transakcí do bloků. V předchozím příspěvku jsme zmínili, že uzly emulují pravidla těžařů, aby ve svých mempoolech držely výhodné transakce. Díky tomu můžeme postavit algoritmus odhadu poplatků, který simuluje chování těžařů. Abychom nalezli jednotkový poplatek, za který by byla transakce potvrzena během příštích n bloků, mohli bychom díky použití algoritmu sestavování bloků a vlastního mempoolu navrhnout příštích n bloků a spočítat, jaký poplatek by porazil poslední transakce, které by se dostaly do bloku n.

Je zřejmé, že účinnost tohoto odhadu poplatků závisí na podobnosti obsahu našeho mempoolu a mempoolu těžařů, což nikdy nelze zaručit. Dále nemůže zohlednit transakce, které těžař může začlenit na základě externích podnětů, např. vlastní těžařovy transakce či transakce, jejíž poplatky za potvrzení byly zaplaceny jiným způsobem. Algoritmus také musí zohlednit dodatečné transakce, které se objeví. Může tak učinit snížením velikosti navržených bloků, ale o kolik?

Tato otázka opět vyzdvihuje užitečnost historický dat. Chytrý model může zahrnout vzory aktivity a zohlednit vnější události ovlivňující poplatky jako jsou pracovní doba, plánované konsolidace UTXO či reakce na změny ceny bitcoinu. Problematika předpovídání poptávky po blokovém prostoru je a nadále zůstane předmětem studií a zkoumání.

Odhadování poplatků je mnohostranný a složitý problém. Špatný odhad může přivést plýtvání prostředky, zhoršit použitelnost bitcoinu pro placení a způsobit ztrátu peněz uživatelům vrstev nad bitcoinem, kteří kvůli nevhodnému poplatku zmeškají okno časového zámku UTXO. Dobrý odhad poplatků umožňuje uživatelům jasně a přesně sdělovat těžařům naléhavost transakce a díky CPFP a RBF mohou aktualizovat své nabídky v případě podhodnocených původních odhadů. Díky pravidlům a politikám mempoolu zohledňujícím výhodnost transakcí, dobře navrženým nástrojům pro odhadování poplatků a peněženkám se mohou uživatelé účastnit efektivní veřejné aukce blokového prostoru.

Odhady poplatků obvykle nenabízí hodnoty pod 1 sat/vB, bez ohledu na délku časového horizontu či množství transakcí čekající na potvrzení. Mnozí považují 1 sat/vB za nejnižší jednotkový poplatek v bitcoinové síti, neboť většina uzlů (včetně těžařů) nikdy neakceptuje nic pod touto hodnotou. Příští týden prozkoumáme pravidla uzlu a další důvody pro zohledňování jednotkových poplatků přeposílaných transakcí: ochrana před vyčerpáním zdrojů.

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.

• ● LND 0.16.3-beta je údržbovým vydáním této populární implementace LN. Poznámky k vydání uvádí, že „obsahuje pouze opravy chyb a má za cíl optimalizovat nedávno přidanou logiku sledování mempoolu a také opravit několik možných vektorů neúmyslného vynuceného zavření kanálu.” Pro více informací o logice sledování mempoolu, viz zpravodaj č. 248.

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

• ● Bitcoin Core #26485 umožňuje RPC metodám, které jako parametr přijímají objekt options, přijmout stejné položky jako jmenné parametry. Například bumpfee může být voláno jako src/bitcoin-cli -named bumpfee txid fee_rate=10 namísto dřívějšího src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 10}'.

• ● Eclair #2642 přidává RPC volání closedchannels, které poskytuje data o vlastních zavřených kanálech. Viz též podobná změna v Core Lightning popsaná ve zpravodaji č. 245.

• ● LND #7645 přidává kontrolu, že jakýkoliv jednotkový poplatek poskytnutý uživatelem v rámci RPC volání OpenChannel, CloseChannel, SendCoins a SendMany není nižší než hodnota relay fee rate (jednotkový poplatek přeposílání). V poznámce je uvedeno: „Relay fee rate má pro různé backendy trochu jiný význam. V bitcoind je to v podstatě max(relay fee, min mempool fee).“

• ● LND #7726 bude vždy utrácet všechna HTLC platící místnímu uzlu, pokud kanál potřebuje vyrovnat zůstatky na blockchainu, včetně HTLC, jejichž hodnota je nižší než hodnota poplatku za transakci. Porovnejte se změnou v Eclair, již jsme popsali minulý týden, která programu zabrání nárokovat neekonomická HTLC. Komentáře pod PR zmiňují, že LND pracuje na dalších změnách, které vylepší jeho schopnost kalkulovat náklady a zisky vztažené k vyrovnávání HTLC (offchain i onchain), což mu v budoucnosti umožní činit optimální rozhodnutí.

• ● LDK #2293 odpojí a znovu připojí uzly, které přestanou odpovídat. Má to zabránit problémům jiného LN software, které občas přestane odpovídat a vynutí si zavření kanálů.