Zpravodaj tento týden popisuje, jak lze vypočítat práh nebezpečí sobecké těžby, shrnuje nápad na zabraňování filtrování transakcí s vysokými poplatky, žádá o zpětnou vazbu k návrhu na změnu musig() v BIP390 deskriptorech a ohlašuje novou knihovnu pro šifrování deskriptorů. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními nových vydání a popisem nedávných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Výpočet prahu sobecké těžby: Antoine Poinsot zaslal do fóra Delving Bitcoin příspěvek, ve kterém rozšiřuje matematický základ z článku z roku 2013, který dal své jméno útoku sobeckou těžbou (i když samotný útok byl popsán již v roce 2010). Dále poskytuje zjednodušený simulátor těžby a přeposílání bloků, který umožňuje s útokem experimentovat. Soustředí se na zopakování jednoho ze závěrů článku: že nepoctivý těžař (nebo kartel propojených těžařů) ovládající 33 % celkového hashrate bez dalších výsad může v dlouhodobém výhledu vydělávat nepatrně více než těžaři ovládající 67 % hashrate. 33% menšina toho dosáhne tím, že bude cíleně zpožďovat oznámení některých nově nalezených bloků. S hashratem zvyšujícím se nad 33 % se činnost stává více a více profitabilní, až přesáhne 50% hashrate a může zabránit ostatním účastníkům v připojování jejich bloků.

    Poinsotův příspěvek jsme podrobně neanalyzovali, ale jeho přístup se nám jevil rozumný a doporučili bychom ho k přečtení každému se zájmem získat lepší porozumění.

  • ● Synchronizace vrcholu mempoolu pro odolnost vůči cenzuře : Peter Todd zaslal do emailové skupiny Bitcoin-Dev příspěvek o mechanismu, který by uzlům umožnil zahazovat spojení, která filtrují transakce s vysokými poplatky. Tento mechanismus závisí na mempoolu clusterů a mechanismu synchronizování množin (set reconciliation) jako např. v erlay. Uzel by pomocí mempoolu clusterů vypočítal nejvýhodnější množinu nepotvrzených transakcí, které by se mohly vměstnat do (na příklad) 8 000 000 váhových jednotek (maximum 8 MB). Každé ze spojení uzlu by též vypočítalo horních 8 000 000 váhových jednotek nepotvrzených transakcí. Pomocí efektivního algoritmu jako minisketch by mohl uzel synchronizovat svou množinu transakcí se svými spojeními. Tím by se přesně dozvěděl, které transakce mají spojení na vrcholu svých mempoolů. Uzel by pravidelně odpojoval spojení, která mají v průměru nejméně profitabilní mempool.

    Zbavením se nejméně profitabilních spojení by uzel postupně našel taková spojení, která by nejméně pravděpodobně filtrovala transakce s vysokými poplatky. Todd doufá, že bude moci po začlenění mempoolu clusterů do Bitcoin Core na implementaci pracovat. Nápad přisuzuje Gregorymu Maxwellovi a jiným. Optech myšlenku poprvé zmínil ve zpravodaji č. 9 (angl.).

  • ● Opakovaný veřejný klíč v musig() v BIP390: Ava Chow zaslala do emailové skupiny Bitcoin-Dev příspěvek s dotazem, zda-li by někdo namítal, aby BIP390 umožňoval výrazům musig() v deskriptorech výstupních skriptů obsahovat stejný veřejný klíč více než jednou. Vedlo by to k jednodušší implementaci a je to explicitně povoleno ve specifikaci MuSig2 v BIP327. V době psaní zpravodaje námitky nikdo nevyjádřil a Chow tedy otevřela pro změnu specifikace BIP390 nový pull request.

  • ● Knihovna pro šifrování deskriptorů: Josh Doman zaslal do fóra Delving Bitcoin příspěvek s ohlášením své knihovny, která přítomnými veřejnými klíči šifruje citlivé části deskriptoru výstupních skriptů nebo miniscriptu. Popisuje, které informace jsou potřebné k dešifrování:

    • Pokud tvoje peněženka vyžaduje k utracení 2-ze-3 klíčů, bude potřebovat přesně 2-ze-3 klíčů k dešifrování.

    • Pokud tvoje peněženka používá komplexní mininiscriptová pravidla jako „buď 2 klíče NEBO (časový zámek A jiný klíč),“ šifrování následuje stejnou strukturu, jako by byly všechny časové zámky uspokojené.

    Tento návrh se liší od schématu záloh diskutovaných ve zpravodaji č. 351, kde znalost kteréhokoliv veřejného klíče z deskriptoru postačovala k jeho dešifrování. Doman tvrdí, že jeho schéma poskytuje více soukromí v případech, kdy je šifrovaný deskriptor zálohován ve veřejných či poloveřejných zdrojích, jako je blockchain.

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

Vyčleň z validačních funkcí přístup do množiny UTXO („Separate UTXO set access from validation functions”) je PR od TheCharlatan, které umožňuje volat validační funkce předáním pouze vyžadovaných UTXO namísto celé množiny UTXO. Jedná se o součást projektu bitcoinkernel, která je důležitým krokem na cestě k použitelnosti knihovny pro implementace plného uzlu, které neimplementují množinu UTXO, jako jsou Utreexo nebo SwiftSync (viz zpravodaj č. 349).

V prvních čtyřech commitech snižuje PR závislost mezi funkcemi provádějícími validaci transakcí a množinou UTXO. Nově vyžaduje, aby volající funkce nejprve načetla potřebné objekty Coin nebo CTxOut a potom je předala validační funkci (dříve validační funkce sama přímo přistupovala do množiny UTXO.)

Následné commity závislost ConnectBlock() na množině UTXO odstraňují kompletně. Za tímto účelem extrahují zbývající logiku, která potřebuje s množinou UTXO pracovat, do metody SpendBlock().

  • Proč je v tomto PR oddělení nové funkce SpendBlock() z ConnectBlock() užitečné? Jak byste porovnali smysl těchto dvou funkcí?

    Funkce ConnectBlock() původně prováděla validaci bloku i změny množiny UTXO. Tento refaktoring obě zodpovědnosti odděluje: ConnectBlock() nově obsahuje pouze logiku validace, která množinu UTXO nepotřebuje, a nová funkce SpendBlock() obstarává veškerou interakci s UTXO množinou. Díky tomu je možné provést validaci bloku pomocí ConnectBlock() bez množiny UTXO. ➚

  • Jaké další výhody tohoto oddělení vidíte?

    Vedle možnosti používat jádro v projektech bez množiny UTXO usnadňuje toto oddělení testování a údržbu. Jeden účastník též poznamenal, že odstranění potřeby přístupu k množině UTXO otevírá dveře k paralelní validaci bloků, což je důležitá funkce SwiftSyncu. ➚

  • SpendBlock() má parametry CBlock block, CBlockIndex pindex a uint256 block_hash, všechny odkazující na utrácený blok. Proč k tomu potřebujeme tři parametry?

    Kód validace je z hlediska výkonnosti kritický, neboť má dopad na příklad na rychlost propagace bloků. Počítání haše bloku z CBlock nebo CBlockIndex není zadarmo, protože hodnota se nekešuje. Proto se autor rozhodl upřednostnit výkonnost tím, že předává již spočítaný haš bloku jako samotný parametr. Podobně by mohl být i pindex získán z indexu bloku, ale to by znamenalo nadbytečné vyhledání v mapě navíc.
    Poznámka: autor později přístup změnil a block_hashodstranil. ➚

  • První commit tohoto PR odstraňuje CCoinsViewCache ze signatury několika validačních funkcí. Drží CCoinsViewCache celou množinu UTXO? Proč to je/není problém? Mění PR toto chování?

    CCoinsViewCache nedrží celou množinu UTXO; jedná se o mezipaměť, která je umístěna před CCoinsViewDB, která ukládá celou množinu UTXO na disk. Pokud není požadovaná mince v mezipaměti, musí být načtena z disku. Toto PR samotné chování kešování nemění. Odstraněním CCoinsViewCache ze signatur je závislost na UTXO explicitní, jelikož od volající funkce požaduje, aby mince před voláním validační funkce sama načetla. ➚

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.

  • ● Core Lightning 25.05rc1 je kandidátem na vydání příští hlavní verze této oblíbené implementace LN uzlu.

  • ● LND 0.19.1-beta je kandidátem na vydání údržbové verze této populární implementace LN uzlu. Obahuje opravy několika chyb.

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, Lightning BLIPs, Bitcoin Inquisition a repozitáři BINANA.

  • ● Bitcoin Core #32406 odstraňuje omezení velikosti OP_RETURN výstupu (pravidlo standardnosti). Navyšuje výchozí nastavení -datacarriersize z 83 na 100 000 bajtů (nejvyšší možná velikost transakce). Volby -datacarrier a -datacarriersize zůstávají zachované, jsou však označené jako zastaralé a očekává se jejich odstranění v nějakém budoucím vydání. Dále toto PR odstraňuje omezení jednoho OP_RETURN výstupu na transakci a stanovuje omezení velikosti na všechny takové výstupy. Zpravodaj č. 352 přináší další informace o této změně.

  • ● LDK #3793 přidává novou zprávu start_batch, která signalizuje spojením, aby považovala příštích n (batch_size) zpráv za jedinou logickou jednotku. Dále aktualizuje PeerManager, aby používal tuto zprávu pro zprávy commitment_signed namísto přidávání TLV a batch_size do každé jednotlivé zprávy. Jedná se o pokus umožnit dávkování i jiným zprávám LN protokolu.

  • ● LDK #3792 přináší úvodní podporu (za testovacím příznakem) v3 commitment transakcí (viz zpravodaj č. 325), která spoléhá na TRUC transakce a dočasné anchory. Uzel bude nově odmítat návrhy open_channel, které nastavují nenulový jednotkový poplatek, ujistí se, že nikdy podobné kanály nebude sám navrhovat a přestane automaticky akceptovat v3 kanály, dokud nejprve nezarezervuje UTXO pro pozdější navyšování poplatků. PR dále snižuje HTLC limit na kanál z 483 na 114, protože TRUC transakce musí zůstat pod 10 kvB.

  • ● LND #9127 přidává do příkazu lncli addinvoice volbu --blinded_path_incoming_channel_list, která příjemci umožní přidat jeden či více preferovaných kanálů, přes které by odesílatel mohl směrovat zaslepenou cestu.

  • ● LND #9858 signalizuje produkční feature bit 61 pro kooperativní zavírání kanálu s RBF (viz též zpravodaj č. 347). Tím zajistí fungování s Eclairem. Zachovává testovací bit 161 pro uzly testující tuto funkcionalitu.

  • ● BOLTs #1243 mění ve specifikaci BOLT11 nakládání s poli faktury. Nově odesílatel nesmí platit fakturu, pokud nemají povinná pole jako p (platební haš), h (haš popisky) nebo s (tajný kód) správnou délku. Dříve mohl uzel tyto problémy ignorovat. Změna dále mezi příklady přidává poznámku vysvětlující, že podpisy s nižším R nejsou specifikací vynucované, i když šetří jeden bajt.