Tento týden popisujeme několik diskuzí o navrhovaném cluster mempoolu a shrnujeme výsledky testu provedeného pomocí warnetu. 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

  • ● Diskuze o cluster mempoolu: vývojáři Bitcoin Core pracující na cluster mempoolu ustanovili v rámci fóra Delving Bitcoin svou pracovní skupinu. Cluster mempool je návrh na usnadnění práce s mempoolem za zachování požadovaného řazení transakcí. Validní řazení bitcoinových transakcí požaduje, aby byli předkové potvrzeni dříve než potomci. Toho lze dosáhnout začleněním předka v dřívějším bloku nebo na dřívější pozici v rámci stejného bloku. Dle návrhu cluster mempoolu jsou clustery jedné nebo více souvisejících transakcí rozděleny do chunků seřazených dle jednotkového poplatku. Kterýkoliv chunk může být začleněn do bloku (až do maximální váhy bloku), pokud jsou všechny předchozí nepotvrzené chunky (s vyššími jednotkovými poplatky) zařazeny dříve do stejného bloku.

    Jakmile jsou všechny transakce seřazeny do clusterů a clustery rozděleny do chunků, je jednoduché vybrat transakce pro začlenění do bloku: stačí zvolit chunk s nejvyšším jednotkovým poplatkem, potom s druhým nejvyšším a tak dále až do zaplnění bloku. Je-li použit tento algoritmus, je zřejmé, že chunk s nejnižším jednotkovým poplatkem je také chunk, který má do začlenění do bloku nejdále. Můžeme tedy použít převrácený algoritmus na vypořádání se s plným mempoolem, kdy je potřeba vyhodit některé transakce: vyhoďme chunk s nejnižším jednotkovým poplatkem, potom druhým nejnižším a tak dále, dokud není náš mempool opět pod svou zamýšlenou nejvyšší velikostí.

    Archiv pracovní skupiny je nyní přístupný všem, avšak pouze pozvaní členové mohou přispívat. Vybíráme některá zajímavá diskutovaná témata:

    • ● Definice a teorie cluster mempoolu přináší definice termínů použitých v návrhu cluster mempoolu. Též přináší několik vět, které demonstrují užitečné vlastnosti tohoto návrhu. Tento jediný příspěvek vlákna (v době psaní zpravodaje) je užitečný k porozumění dalších debat pracovní skupiny, ačkoliv jeho autor (Pieter Wuille) varuje, že je stále „velice neúplný.”

    • ● Sloučení neporovnatelných linearizací zkoumá, jak sloučit dvě odlišené sady chunků (chunkování, „chunkings”) shodných množin transakcí, které jsou neporovnatelné. Porovnáním dvou odlišných sad chunků (chunkování) bychom mohli určit, která z nich by byla pro těžaře výhodnější. Chunkování by mohla být porovnána, pokud by jedno z nich vždy akumulovalo shodnou nebo vyšší výši poplatků v rámci libovolné hodnoty vbyte (diskrétní podle velikost chunku). Například:

      Comparable chunkings

      Naopak neporovnatelná by byla, pokud by jedno z nich akumulovalo větší výši poplatků v rámci určitého rozmezí vbyte, a to druhé větší výši poplatků v jiném rozmezí, například:

      Incomparable chunkings

      Jak poznamenává jedna z vět zmíněná v předchozím příspěvku, „existují-li dvě neporovnatelná chunkování, potom musí existovat třetí, které je lepší než obě.” To znamená, že efektivní způsob, jakým sloučit dvě odlišná, neporovnatelná chunkování může být mocným nástrojem pro zvýšení těžařovy profitability. Příklad: je přijata nový transakce, která souvisí s jinou transakcí z mempoolu. Její cluster musí být aktualizován, a tedy i její chunkování musí být upraveno. Mohou být provedeny dva různé způsoby této úpravy:

      1. Je spočítáno nové chunkování pro aktualizovaný cluster. Pro velké clustery může být nalezení optimálního chunkování výpočetně nepraktické, nové chunkování tedy může být méně optimální než staré.

      2. Předchozí chunkování z předchozího clusteru je aktualizováno vložením nové transakce na místo, které je validní (předci před potomky). Výhodou je, že jakékoliv stávající optimalizace zůstávají nedotčené, na druhou stranu by transakce mohla být umístěna v neoptimálním místě.

      Když jsou obě metody vykonány, můžeme porovnáním zjistit, že výsledek jedné je lepší, může tedy být použit. Avšak jsou-li obě aktualizace neporovnatelné, lze použít metodu, která zaručuje ekvivalentní nebo lepší výsledek sloučení, k vytvoření třetího chunkování, které obsáhne nejlepší součásti obou přístupů: použitím nových chunkování, pokud jsou lepší, nebo zachování předchozích, pokud ta se blíží optimu.

    • ● RBF balíčku v době clusterů se zabývá alternativami k pravidlům používaným v současnosti pro nahrazování poplatkem. Obdrží-li uzel validní nahrazení jedné nebo více transakcí, může být vytvořena dočasná verze všech dotčených clusterů a odvozeno jejich nové chunkování. To potom může být porovnáno s chunkováním původních clusterů v mempoolu (bez nahrazení). Pokud chunkování s nahrazením přináší vždy stejně nebo více na poplatcích než originální pro jakýkoliv počet vbyte, a pokud navyšuje celkovou hodnotu poplatků v mempoolu natolik, aby zaplatilo za své poplatky, potom může být začleněno do mempoolu.

      Toto vyhodnocování založené na důkazech by mohlo nahradit několik heuristik, které jsou v současnosti v Bitcoin Core používány k určení, zda má být transakce nahrazena. To by mohlo v několika oblastech zlepšit pravidla RBF, včetně navrhovaného přeposílání balíčků pro nahrazování. Několik dalších vláken se též zabývalo tímto tématem.

  • ● Testování s warnetem: Matthew Zipkin zaslal do Delving Bitcoin příspěvek s výsledky simulací, které provádí pomocí warnetu, programu spouštějícímu velké množství bitcoinových uzlů s definovanými vzájemnými spojeními (obvykle v testovací síti). Zipkinovy výsledky ukazují, jaká paměť navíc by byla potřeba, pokud by bylo přijato několik navrhovaných změn kódu správy spojení (ať již nezávisle nebo spolu). Dále poznamenává, že by rád prováděl testovací simulace i dalších navrhovaných změn a měřil dopad navrhovaných útoků.

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

Sezení review klubu Testování kandidátů na vydání Bitcoin Core 26.0 se nezabývalo konkrétním PR, ale společným testováním.

Důsledné testování členy komunity před každým hlavním vydáním Bitcoin Core je nezbytné. Z tohoto důvodu sepíše dobrovolník průvodce testování kandidáta na vydání, aby mohlo co nejvíce lidí efektivně testovat, aniž by museli sami zjišťovat, co je nového, co se změnilo a jaké kroky je potřeba podniknout k jejich otestování.

Testování může být náročné, protože nemusí být v případě neočekávaného chování jasné, zda se jedná o chybu programu či omyl v testování. Reportování chyb, které nejsou skutečnými chybami, plýtvá časem vývojářů. Sezení review klubu se zabývá konkrétním kandidátem na vydání (v tomto případě 26.0rc2), aby se předešlo podobným problémům.

Průvodce testováním kandidáta na vydání 26.0 napsal Max Edwards, který se též zhostil vedení sezení review klubu. Pomáhal mu Stéphan (stickies-v).

Účastníci byli dále vyzýváni, aby se čtením poznámek k vydání 26.0 sami inspirovali k nápadům na testování.

Toto sezení klubu se zabývalo dvěma RPC voláními: getprioritisedtransactions (bylo též předmětem jednoho z předchozích sezení, ačkoliv tehdy ještě pod jiným názvem) a importmempool. Tato i další nová volání jsou popsána v sekci poznámek k vydání New RPCs. Sezení se dále zabývalo přenosem verze 2 (BIP324) a zamýšlelo též pokrýt TapMiniscript, ale z časových důvodů se na toto téma nedostalo.

  • Které operační systémy lidé používají?

    Ubuntu 22.04 na WSL (Windows Subsystem for Linux); macOS 13.4 (M1 chip). ➚

  • Jaké byly výsledky vašeho testování getprioritisedtransactions?

    Účastníci hlásili, že fungovalo dle očekávání, avšak jeden z nich si povšiml, že se důsledek prioritisetransaction sčítal: pokud bylo voláno dvakrát pro stejnou transakci, poplatek se zdvojil. Toto chování je dle očekávání. Poplatek v argumentu je přičten ke stávající prioritě transakce. ➚

  • Jakých výsledků testování importmempool jste dosáhli?

    Jeden z účastníku obdržel chybu “Importovat mempool lze až po stažení bloků a synchronizaci”, avšak po dvou minutách čekání bylo volání úspěšné. Jiný účastník poznamenal, že to trvá dlouho. ➚

  • Co se stane, pokud během importu přerušíme CLI proces a potom jej bez zastavení bitcoind restartujeme?

    Toto nezpůsobilo žádné potíže, druhý požadavek o import se dokončil podle očekávání. Zdá se, že proces importování pokračoval i po přerušení CLI příkazu a druhý požadavek nezpůsobil, aby dvě vlákna importu běžela najednou a kolidovala se sebou. ➚

  • Jaký byl výsledek provozování přenosu verze 2?

    Účastníci nebyli schopni připojit se ke známému uzlu s V2 na mainnetu. Zdálo se, že nepřijímal žádná spojení. Je možné, že všechny příchozí sloty uzlu již byly obsazené. Z tohoto důvodu nedošlo během sezení k testování P2P. ➚

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.

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 #28848 upravuje chybová hlášení RPC volání submitpackage. Namísto vrácení JSONRPCError s první chybou nově vrací výsledek za každou transakci.

  • ● LDK #2540 staví na posledním vývoji zaslepených cest v LDK (viz zpravodaje č. 257 a č. 266) a přidává podporu pro přeposílání jako první uzel v zaslepené cestě. Změna je součástí vývoje podpory nabídek dle BOLT12.