Tento týden přinášíme popis článku o protokolu PoWswap a naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o nových verzích a popisem významných změn v populárních páteřních bitcoinových projektech. Též nechybí krátká část oslavující pět let Bitcoin Optech a naše 250. číslo.

Novinky

  • ● Článek o protokolu PoWswap: Thomas Hartman zaslal do emailové skupiny Bitcoin-Dev příspěvek o článku, který napsal s Glebem Naumenkem a Antoinem Riardem, věnující se protokolu PoWSwap poprvé navrženém Jeremy Rubinem. PoWswap umožňuje vytvářet onchainové kontrakty vztažené ke změně hash rate. Základní myšlenka spočívá ve využití vztahu mezi časem a produkcí bloků, který lze ověřovat na úrovni protokolu, spolu s možností vyjádřit časové zámky buď formou času nebo počtu bloků. Mějme například následující skript:

    OP_IF
  <Alicin klíč> OP_CHECKSIGVERIFY <čas> OP_CHECKLOCKTIMEVERIFY
OP_ELSE
  <Bobův klíč> OP_CHECKSIGVERIFY <výška> OP_CHECKLOCKTIMEVERIFY
OP_ENDIF

    Představme si, že aktuální čas je t a aktuální výška bloků je x. Předpokládejme, že bloky jsou produkovány průměrně v desetiminutových intervalech. Nastavíme-li <čas> na t + 1 000 minut a <výška> na x + 50, můžeme očekávat, že Bob by byl schopen utratit výstup kontrolovaný výše uvedeným skriptem v průměru 500 minut před tím, než by ho mohla utratit Alice. Avšak pokud by se produkce bloků zrychlila více než dvakrát, mohla by Alice utratit výstup před Bobem.

    Lze si představit několik aplikací takového kontraktu:

    • ● Pojištění proti navýšení hash rate: těžaři musí zakoupit vybavení před tím, než najisto vědí, jaký příjem jim bude generovat. Například se může stát, že těžař zakoupí dost vybavení, aby obdržel jedno procento současných odměn. Tento těžař by jistě nepřivítal, kdyby ve stejné době jiný těžař zakoupil vybavení, kterým by zdvojnásobil celkový hash rate a tím by snížil jeho odměny na 0,5 %. Náš těžař by mohl pomocí PoWswap uzavřít kontrakt s někým, kdo je ochoten mu zaplatit v případě navýšení hash rate před určitým datem, čímž by vyrovnal těžařův neočekávaně nízký příjem. Výměnou by tento těžař souhlasil zaplatit větší částku, pokud by hash rate zůstal stejný nebo se snížil.

    • ● Pojištění proti poklesu hash rate: množství známých problémů bitcoinu by vyústilo ve velký pokles celkového hash rate. Hash rate by se snížil, pokud by těžaři byli zavírání nějakými mocnými stranami nebo pokud by se mezi zavedenými těžaři náhle začal ve velké míře objevovat fee sniping anebo pokud by hodnota BTC, který těžaři obdrží, náhle poklesla. Držitelé bitcoinu, kteří by se chtěli proti takovým situacím pojistit, by mohli uzavřít s těžaři nebo třetími stranami podobný kontrakt.

    • ● Kurzové kontrakty: obecně chtějí v případě navýšení kupní síly bitcoinu těžaři navýšit jimi poskytovaný hash rate, aby obdrželi více na odměnách. V případě poklesu kupní síly potom hash rate klesá. Lidé by mohli uzavírat kontrakty navázané na budoucí kupní sílu bitcoinu.

    I když se o PoWswap hovoří již několik let, tento článek poskytuje množství podrobností a analýz, které jsme do této doby neviděli.

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

Přidej getprioritisationmap, odstraň položku z mapDeltas pokud delta==0 je PR od Glorie Zhao (glozow) vylepšující funkci Bitcoin Core, která těžařům umožňuje upravit efektivní poplatek konkrétní transakce v mempoolu (viz RPC volání prioritisetransaction), a tím zvýšit či snížit prioritu její těžby. Hodnota, která navýší poplatek (je-li kladná) či sníží poplatek (je-li záporná), se nazývá fee delta. Hodnoty prioritizace transakcí jsou ukládány na disk do souboru mempool.dat a jsou v případě restartu obnoveny.

Jednou ze situací, kdy těžař využije prioritizaci transakcí, je obdržení externí platby poplatku. Poplatek takové transakce se potom bude během těžby považovat za vyšší.

PR přidává nové RPC volání getprioritisationmap, které vrací seznam prioritizovaných transakcí. PR dále odstraňuje již nepotřebné položky prioritizace, je-li jejich delta nastavena na nulu.

  • Co je datová struktura mapDeltas a proč ji potřebujeme?

    Ukládá hodnoty prioritizace transakcí. Tyto hodnoty ovlivňují rozhodování o lokální těžbě, zahazování transakcí a také kalkulaci poplatků rodičů a potomků. ➚

  • Ovlivňuje prioritizace transakcí algoritmus odhadování poplatků?

    Ne. Odhad poplatků musí přesně předpovídat očekávaná rozhodnutí těžařů (v tomto případě se jedná o ostatní těžaře) a tito těžaři nemají stejnou prioritizaci jako my. Prioritizace je lokální. ➚

  • Jak jsou do mapDeltas položky přidávány? Kdy jsou odstraněny?

    Jsou přidávány RPC voláním prioritisetransaction a také během restartu ze souboru mempool.dat. Odstraněny jsou v okamžiku začlenění bloku s transakcí do blockchainu nebo když je transakce nahrazena (RBF). ➚

  • Proč bychom neměli odstranit položku z mapDeltas, když je její transakce odstraněna z mempoolu (např. protože její čas vypršel nebo byla vyhozena kvůli nízkému poplatku)?

    Transakce se může vrátit zpět do mempoolu. Pokud by byla položka z mapDeltas ostraněna, musel by uživatel opět nastavit prioritizaci této transakce. ➚

  • Je-li transakce odstraněna z mapDeltas z důvodu začlenění do bloku a tento blok je následně obětí reorganizace, nebude se muset znovu nastavit prioritizace transakce?

    Ano, ale reorganizace by měly nastávat zřídka. Navíc externí platby mohou být ve formě bitcoinové transakce a ta také může vyžadovat prioritizaci. ➚

  • Proč bychom měli umožnit prioritizaci transakce, která není přítomna v mempoolu?

    Protože tato transakce nemusí být v mempoolu prozatím. A nemusí se do mempoolu ani dostat kvůli vlastnímu poplatku (bez prioritizace). ➚

  • Jaký problém nastává, když mapDeltas nepročišťujeme?

    Hlavním problémem je zbytečná alokace paměti. ➚

  • Kdy se mempool.dat (včetně mapDeltas) zapisuje na disk?

    V případě řádného ukončení nebo RPC voláním savemempool. ➚

  • Jak před tímto PR těžaři pročišťovali mapDeltas?

    Jediným způsobem bylo uzel restartovat, jelikož během restartu nejsou nulové prioritizace do mapDeltas vkládány. Díky PR jsou nulové položky z mapDeltas odstraněny okamžitě a nejsou tak ani zapisovány na disk. ➚

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 #26094 přidává do volání getbalances, gettransactiona getwalletinfo hash a výšku bloku. Tato volání zamykají chainstate, aby garantovala aktuální stav, začlenění validního hashe a výšky bloku do odpovědi je pro ně tedy výhodné.

  • ● Bitcoin Core #27195 umožňuje odstranit všechny externí příjemce transakce, která je nahrazována pomocí volání bumpfee z interní peněženky Bitcoin Core. Uživatel tak učiní tím, že jediný výstup nahrazující transakce platí na jeho vlastní adresu. Po potvrzení nahrazující transakce nemůže dojít k zaplacení původním příjemcům. Této technice se někdy říká „zrušení” bitcoinové platby.

  • ● Eclair #1783 přidává API cpfpbumpfees pro navýšení poplatku jedné nebo více transakcí pomocí CPFP. PR také aktualizuje seznam doporučených parametrů pro provoz Bitcoin Core tak, aby navyšování poplatků bylo možné.

  • ● LND #7568 přidává možnost definovat během startu dodatečné feature bity. Dále odstraňuje možnost deaktivovat jakékoliv pevně zakódované nebo definované feature bity během provozu (ale dodatečné bity mohou být přidány a později odstraněny). Navázaný návrh v BLIPs #24 poznamenává, že uživatelské BOLT11 feature bity jsou omezeny na maximální hodnotu 5114.

  • ● LDK #2044 přináší několik změn v doporučeních tras v rámci BOLT11 faktur, tedy mechanismu, kterého může příjemce využít k návrhu tras, které může odesílatel použít. V rámci této změny jsou pro doporučení použity pouze první tři kanály (z důvodu efektivity a soukromí) a je vylepšena podpora phantom uzlů (viz zpravodaj č. 188, angl.). Diskuze pod PR obsahuje několik užitečných komentářů o dopadech používání doporučených tras na soukromí.

Oslavujeme zpravodaj číslo 250

Bitcoin Optech byl zčásti založen, aby „pomohl vylepšit vztahy mezi byznysem a open source komunitou.” Tento týdenní zpravodaj byl vytvořen, aby poskytl vedení a vývojářům v bitcoinových firmách přehled o výsledcích snah open source komunity. Proto jsme se v počátcích soustředili na dokumentování činnosti, která může mít vliv na byznys.

Brzy jsme zjistili, že o tyto informace měli zájem nejen čtenáři z řad byznysu. Mnoho přispěvatelů do bitcoinových projektů nemělo čas na čtení všech diskuzí v emailových skupinách nebo na monitorování významných změn jiných projektů. Rádi by, kdyby je někdo informoval o změnách, které by je mohli zajímat či mít dopad na jejich práci.

Je nám potěšením již téměř pět let poskytovat tuto službu. Snažíme se tuto jednoduchou misi rozšiřovat a proto také poskytujeme průvodce kompatibilitou peněženek, rejstřík více než 100 témat a týdenní diskuzní podcast s hosty, mezi kterými nechyběli mnozí z těch, o kterých máme tu čest psát.

Nic z toho by nebylo možné bez našich přispěvatelů, mezi kterými byli za poslední rok: Adam Jonas, Copinmalin, David A. Harding, Gloria Zhao, Jiri Jakes, Jon Atack, Larry Ruane, Mark „Murch” Erhardt, Mike Schmidt, nechteme, Patrick Schwegler, Shashwat Vangani, Shigeyuki Azuchi, Vojtěch Strnad, Zhiwei „Jeffrey” Hu a několik dalších, kteří přispěli k jednotlivým tématům.

Též zůstáváme navždy vděčni našim zakládajícím sponzorům Wencesovi Casaserovi, Johnovi Pfefferovi, Alexovi Morcosovi a mnoha těm, kteří přispěli finančně.

Děkujeme vám za čtení. Doufáme, že v tom budete během následujících 250 zpravodajů pokračovat.