Tento týden přinášíme oznámení o nadcházejících změnách v emailové skupině Bitcoin-Dev a krátký souhrn návrhu na agregaci několika HTLC dohromady. Též nechybí 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 v populárním bitcoinovém páteřním software.

Novinky

  • ● Hosting emailové skupiny: administrátoři emailové skupiny Bitcoin-Dev oznámili, že organizace, která skupinu na svých serverech hostuje, tak přestane po novém roce činit. Archiv emailů by měl na současných webových adresách v dohledné době zůstat. Předpokládáme, že stejným způsobem bude postižena i skupina Lightning-Dev, která je hostována stejnou organizací.

    Administrátoři žádali komunitu o poskytnutí zpětné vazby ohledně možností, mezi kterými je i migrace skupiny do Google Groups. Pokud by takový přechod nastal, Optech by jej začal používat jako jeden ze svých zdrojů.

    Jsme si vědomi, že před několika měsíci začali někteří etablovaní vývojáři experimentovat s diskuzemi na webovém fóru DelvingBitcoin. Optech okamžitě začne toto fórum monitorovat.

  • ● Agregace HTLC pomocí kovenantů: Johan Torås Halseth zaslal do emailové skupiny Lightning-Dev příspěvek s návrhem na agregaci několika HTLC do jediného výstupu pomocí kovenantu. Takový výstup by mohl být v případě znalosti všech předobrazů utracen najednou. Pokud by utrácející neznal všechny předobrazy, mohl by nárokovat jen ty, které zná, a zůstatek by byl zaslán druhé straně. Halseth poznamenává, že tento způsob by byl efektivnější onchain a mohl by ztížit provádění určitého druhu útoku zahlcením kanálu.

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

Aktualizace odhadu poplatku z Validation rozhraní/CScheduler vlákna je PR od Abubakara Sadiqa Ismaila (ismaelsadeeq), které upravuje způsob, jímž je aktualizován odhad poplatků za transakce. (Odhad poplatků se používá, když vlastník uzlu vytváří transakci.) Dříve probíhaly aktualizace odhadu poplatků synchronně během aktualizací mempoolu (když byly transakce přidány nebo odebrány), nově by se tak mělo dít asynchronně. I když tento způsob přidává na složitosti, zvyšuje výkonnost v kritické cestě (což následující diskuze ozřejmí).

Když je nalezen nový blok, jeho transakce jsou spolu s konfliktními transakcemi odstraněny z mempoolu. Jelikož je zpracování bloků a jejich přeposílání kritické z hlediska výkonnosti, je výhodné snížit během zpracování nového bloku množství požadované práce, jako jen například aktualizace odhadu poplatků.

  • Proč je výhodné odstranit z CTxMempool závislost na CBlockPolicyEstimator?

    V současnosti je po přijetí nového bloku jeho zpracování blokováno, dokud se nedokončí aktualizace odhadu poplatků. To má za následek delší zpracování a prodlevu v přeposílání. Odstraněním závislosti na CBlockPolicyEstimator z CTxMempool může být odhad poplatků aktualizován asynchronně, tj. z jiného vlákna. Validace a přeposílání tak mohou být dokončeny rychleji. Navíc testování CTxMempool může být snazší. V budoucnu to také umožní používat složitější algoritmy odhadu poplatků, aniž by měly dopad na rychlost validace a přeposílání. ➚

  • Není odhad poplatků aktualizován synchronně pokaždé, když jsou transakce přidány či odebrány z mempoolu, bez ohledu na to, zda uzel obdržel nový blok?

    Ano, ale výkonnost není tak kritická jako během validace a přeposílání. ➚

  • Nabízí současný stav, tedy CBlockPolicyEstimator uvnitř CTxMempool a synchronní aktualizace, nějaké výhody? Přináší jeho odstranění nějaké nevýhody?

    Synchronní kód je jednodušší a srozumitelnější. Odhad poplatků má navíc větší vhled do celého mempoolu. Na druhou stranu je nutné zapouzdřit všechny informace pro odhad poplatků do struktury NewMempoolTransactionInfo. Odhad poplatků však mnoho informací nepotřebuje. ➚

  • Jaké jsou podle vás výhody a nevýhody přístupu tohoto PR oproti PR 11775, které rozděluje CValidationInterface?

    I když rozdělení vypadá atraktivně, ve skutečnosti části stále sdílely backend (aby byly události patřičně seřazené), nebyly tedy na sobě zcela nezávislé. Nezdá se, že by z praktického hlediska přinášelo rozdělení významné výhody. Toto PR je ve svém záběru užší a s menším dopadem. ➚

  • Proč je implementace rozhraní CValidationInterface ekvivalentní odebírání událostí?

    Všechny třídy implementující CValidationInterface jsou klienty. Třída může implementovat všechny nebo jen některé metody (callbacky) z CValidationInterface, například připojení či odpojení bloku nebo přidání či odebrání transakce z mempoolu. Po registraci (voláním RegisterSharedValidationInterface()) budou implementované metody vykonány pokaždé, když je callback zavolán pomocí CMainSignals. Callbacky jsou zavolány, kdykoliv nastane odpovídající událost. ➚

  • BlockConnected a NewPoWValidBlock jsou rozdílné callbacky. Který z nich je asynchronní a který synchronní? Jak to lze poznat?

    BlockConnected je asynchronní, NewPoWValidBlock je synchronní. Asynchronní callback přidá do fronty „událost,“ která bude později vykonána v rámci vlákna CScheduler. ➚

  • Proč přidáváme v commitu 4986edb nový callback MempoolTransactionsRemovedForConnectedBlock namísto použití BlockConnected (který navíc také indikuje, že byla transakce odstraněna z mempoolu)?

    Algoritmus odhadu poplatku musí vědět, kdy jsou transakce z jakéhokoliv důvodu odstraněny z mempoolu, tedy nejen v případě připojení bloku. Odhad poplatku též potřebuje znát bázový poplatek transakce a ten BlockConnected (který zpřístupňuje CBlock) nenabízí. Mohli bych přidat bázový poplatek do položek block.vtx (seznam transakcí), ale není žádoucí z tohoto důvodu měnit tak důležitou a všudypřítomnou datovou strukturu. ➚

  • Proč nepoužíváme std::vector<CTxMempoolEntry> jako parametr callbacku MempoolTransactionsRemovedForBlock? Mohlo by to odstranit požadavek na novou strukturu, která by držela transakční informace potřebné pro odhad poplatků.

    Odhad poplatků nepotřebuje všechna pole obsažená v CTxMempoolEntry. ➚

  • Jak je počítán bázový poplatek CTransactionRef?

    Jedná se o součet vstupních hodnot minus součet výstupních hodnot. Callback ale nemá přístup ke vstupním hodnotám, neboť jsou uloženy ve výstupech předchozí transakce (k nimž callback přístup nemá). Proto je bázový poplatek obsažen ve struktuře TransactionInfo. ➚

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.