Zpravodaj tento týden shrnuje pokračující diskuzi o pravděpodobnostních platbách, přednáší další názory o dočasných anchor skriptech pro LN, odkazuje na statistiky o vylučování sirotků v Bitcoin Core a oznamuje aktualizovaný návrh revidovaného procesu přijímání BIPů. Též nechybí naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními nových vydání a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Pokračující diskuze o pravděpodobnostních platbách: v návaznosti na příspěvek Oleksandra Kurbatova ve fóru Delving Bitcoin o emulaci opkódu OP_RAND (viz zpravodaj č. 340) vzešlo několik nových diskuzí:

    • Vhodnost jako alternativy k ořezaným HTLC: Dave Harding se zeptal, zda je Kurbatovova metoda vhodná pro použití v LN-Penalty nebo LN-Symmetry platebních kanálech pro směrování HTLC, která jsou aktuálně neekonomická a která jsou v současnosti řešena pomocí ořezaných HTLC (trimmed HTLCs), jejichž hodnota je ztracena, pokud během vynuceného uzavření kanálu stále čekají na vyřízení. Anthony Towns si nemyslí, že by to v existujícím protokolu fungovalo, neboť jeho role jsou opačné než odpovídající role při řešení HTLC. Myslí si však, že by změny protokolu mohly pomoci.

    • ● Nutný nultý krok: Towns zjistil, že původně zveřejněný protokol postrádal jeden krok. Kurbatov souhlasil.

    Diskuze v době psaní dále probíhala.

  • ● Pokračující diskuze o dočasných anchor skriptech pro LN: Matt Morehouse přidal odpověď do vlákna o výběru dočasných anchor skriptů pro budoucí kanály v LN (viz zpravodaj č. 340). Vyjádřil obavy o možném zneužívání transakčních poplatků (fee griefing) třetími stranami u P2A výstupů.

    Anthony Towns poznamenal, že obtěžování (griefing) protistranami je vážné, jelikož protistrana bude mít lepší příležitost ukrást prostředky, pokud není kanál včas uzavřen nebo uveden do správného stavu. Třetí strany, které vaši transakci zdržují nebo se pokouší o nárůst jejího poplatku, mohou ztratit část svých peněz bez přímé možnosti na vás vydělat.

    Greg Sanders navrhl uvažovat v pravděpodobnostech: pokud to nejhorší, čeho může třetí strana dosáhnout, je navýšit náklady vaší transakce o 50 %, ale používání odolných metod stojí zhruba 10 % navíc, opravdu očekáváte, že vás bude třetí strana obtěžovat častěji než jedno vynucené zavření z každých pěti, obzvláště, pokud může ztratit peníze a finančně neprofituje?

  • ● Statistiky vylučování sirotků: vývojář 0xB10C zaslal do fóra Delving Bitcoin příspěvek se statistikami počtu transakcí vyloučených ze sirotčinců jeho uzlů. Osiřelé transakce jsou nepotvrzené transakce, pro které uzel ještě nemá všechny jejich rodičovské transakce, bez nichž nemohou být transakce začleněny do bloku. Bitcoin Core ve výchozím nastavení drží až 100 osiřelých transakcí. Pokud nová osiřelá transakce přijde poté, co je sirotčinec již plný, jeden dříve přijatý sirotek je vyloučen.

    0xB10C zjistil, že někdy jeho uzly vyloučí více než deset miliónů sirotků s vrcholem přes 100 000 vyloučení za minutu. Po zkoumání zjistil, že „přes 99 % z nich jsou podobné této transakci, která vypadá jako z runestone mincoven [NFT protokolů].” Zdá se, že bylo opakovaně vyžadováno mnoho stejných osiřelých transakcí, které byly náhodně vyloučeny a po chvilce opět vyžádány.

  • ● Aktualizace návrhu aktualizace BIP procesu: Mark „Murch” Erhardt zaslal do emailové skupiny Bitcoin-Dev příspěvek oznamující, že jeho návrh BIPu pro změnu procesu navrhování a schvalování BIPů obdržel identifikátor BIP3 a je připraven pro další revizi, snad již poslední před začleněním a aktivací. V případě zájmu zanechte zpětnou vazbu v příslušné žádosti o začlenění.

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

Cluster mempool: přidej TxGraph je PR od Pietera Wuilleho (sipa), které přináší třídu TxGraph. Třída zapouzdřuje znalosti (efektivních) poplatků, velikostí a závislostí mezi všemi transakcemi v mempoolu. Je součástí projektu mempoolu clusterů a přináší srozumitelné rozhraní umožňující interakci s grafem mempoolu za použití mutací, inspektorů a přípravných funkcí.

Za zmínku stojí, že TxGraph nemá žádnou znalost o transakcích, vstupech, výstupech, txid, wtxid, prioritizaci, validitě, pravidlech apod. Díky tomu je snazší (téměř) plně specifikovat chování třídy a vytvářet testy založené na simulacích (které jsou součástí PR).

  • Co je „graf” mempoolu a do jaké míry je součástí kódu mempoolu v master větvi?

    V masteru existuje graf mempoolu implicitně v podobě množiny objektů typu CTxMemPoolEntry jako uzlů, jejichž vztahy mohou být rekurzivně procházeny pomocí GetMemPoolParents() a GetMemPoolChildren(). ➚

  • Jaké výhody, dle vašich vlastních slov, TxGraph přináší? Má i nějaké nevýhody?

    Výhody: 1) TxGraph umožní implementovat mempool clusterů se všemi jeho výhodami. 2) Lepší zapouzdření kódu mempoolu a efektivnější datové struktury. 3) Zjednodušuje práci s mempoolem, odstiňuje od detailů topologie jako např. nutnost nepočítat nahrazené transakce dvakrát.

    Nevýhody: 1) Kvůli velkým změnám potřeba vynaložit mnoho úsilí na revizi a testování kódu. 2) Omezuje, jak může validace určovat transakcím topologické limity, jako např. u TRUC a jiných pravidel. 3) Drobný dopad na výkonnost způsobený překladem z a na ukazatele TxGraph::Ref*. ➚

  • V kolika Clusterech může být v rámci TxGraph jednotlivá transakce součástí?

    Ačkoliv koncepčně může transakce patřit pouze do jediného clusteru, odpověď je 2. Důvodem je, že TxGraph může obsahovat dva paralelní grafy: hlavní (main) a volitelný přípravný (staging). ➚

  • Co znamená, když je TxGraph přeplněn (oversized)? Je to stejné, jako když je mempool plný?

    TxGraph je přeplněn, když minimálně jeden z jeho Clusterů překračuje MAX_CLUSTER_COUNT_LIMIT. Není to stejné, jako když je mempool plný, protože TxGraph může mít více než jeden Cluster. ➚

  • Je-li TxGraph přeplněn, které funkce mohou být nadále volány a které nemohou?

    Operace, které by vyžadovaly vytvoření přeplněného clusteru, a funkce, které vyžadují O(n2) nebo horší, nejsou v přeplněném TxGraphu povolené. Mezi tyto operace patří mimo jiné počítání předků a potomků transakce. Měnitelné operace (AddTransaction(), RemoveTransaction(), AddDependency() a SetTransactionFee()) a operace jako Trim() (zhruba O(n log n)) jsou nadále povoleny. ➚

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 v0.18.5-beta je opravné vydání této populární implementace LN uzlu. Opravy jsou v poznámkách o vydání popsané jako „důležité” a „kritické.“

  • ● Bitcoin Inquisition 28.1 je menším vydáním tohoto signetového plného uzlu navrženého pro experimentování s návrhy soft forků a jinými významnými změnami protokolu. Obsahuje opravy chyb z Bitcoin Core 28.1 a podporu pro dočasný prach (ephemeral dust).

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 #25832 přidává pět nových trasovacích bodů (a jejich dokumentaci) pro monitorování P2P událostí jako doba spojení, četnost opakovaných spojování podle IP a sítě, odrazování od spojení, vylučování, špatné chování apod. Uživatelé Bitcoin Core, kteří mají aktivované trasování pomocí Extended Berkeley Packet Filter (eBPF), ho mohou použít ke sledování použitím přiložených nebo vlastních skriptů (viz též zpravodaje č. 160, angl., a č. 244).

  • ● Eclair #2989 přidává do routeru podporu pro dávkové splicy, což umožní sledovat více kanálů účastnících se jediné splicingové transakce. Kvůli nemožnosti deterministicky spojit nové oznámení kanálu s odpovídajícím kanálem aktualizuje router pouze první kanál, který nalezne.

  • ● LDK #3440 ověřuje odesílatelovu žádost o fakturu z HTLC onion zprávy a generuje správný PaymentPurpose pro nárokování platby. Tím dokončuje podporu přijímání asynchronních plateb. Pro přicházející asynchronní zprávy je nově nastavena absolutní expirační lhůta, což zabrání nekonečnému sondování online stavu uzlu. Dále byla přidána komunikační procedura nezbytná pro uvolnění HTLC drženého předešlým uzlem, když se uzel opět připojí. Pro kompletní implementaci asynchronních plateb musí být uzly schopné jednat jako LSP, který doručuje faktury namísto příjemců.

  • ● LND #9470 přidává do RPC příkazů BumpFee a BumpForceCloseFee parametr deadline_delta, který určuje počet bloků, během kterých bude daný rozpočet plně alokován na navyšování poplatků a RBF bude proveden. Dále byl předefinován parametr conf_target jako počet bloků, který bude použit jako cíl při zjišťování aktuálního poplatku, u obou zmíněných příkazů a u již zastaralého BumpCloseFee.

  • ● BTCPay Server #6580 odstraňuje kontrolu přítomnosti a korektnosti haše popisku (description_hash) v BOLT11 fakturách při platbách s LNURL-pay. Tato změna je v souladu s navrženým zastaráním v LNURL Documents (LUD) specifikaci, dle kterého nabízí tento požadavek minimální bezpečnostní benefity, ale významně ztěžuje implementování LNURL-pay. Pole s hašem deskriptoru je implementováno v Core-Lightning (viz též zpravodaje č. 194, angl., a č. 232).

Korekce

V poznámce v minulém zpravodaji jsme nesprávně napsali: „Co se týče P2SH a navrhovaného počítání sigops vstupů, OP_CHECKMULTISIG s více než 16 veřejnými klíči se počítá jako 20 sigops.” Jedná se o přílišné zjednodušení. Příspěvek od Anthonyho Townse popisuje přesná pravidla.