Zpravodaj tento týden oznamuje odhalení zranitelnosti postihující starší verze LND a shrnuje diskuzi o prioritách projektu Bitcoin Core. Též nechybí naše pravidelné rubriky s popisem diskuzí o změnách konsenzu, oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Odhalení opravené zranitelnosti v LND umožňující krádež: Matt Morehouse zaslal do fóra Delving Bitcoin příspěvek s odhalením zodpovědně nahlášené zranitelnosti, která postihovala verze LND před 0.18. Doporučuje se upgrade na 0.18 nebo (ideálně) na aktuální verzi. Útočník, který s obětí sdílí kanál a který v určitou dobu může přimět oběť k restartování svého uzlu, může klamem přinutit LND k platbě i refundaci jednoho HTLC, což útočníkovi umožní ukrást téměř kompletní hodnotu kanálu.

  Morehouse poznamenává, že všechny ostatní LN implementace tuto zranitelnost nezávisle objevily a opravily, některé už v roce 2018 (viz zpravodaj č. 17, angl.). LN specifikace však správné chování nepopisuje (může dokonce doporučovat nesprávné chování), Morehouse proto otevřel PR s aktualizací specifikace.

• ● Diskuze o prioritách Bitcoin Core: vlákno ve fóru Delving Bitcoin odkázalo na několik blogových příspěvků od Antoine Poinsota o budoucnosti projektu Bitcoin Core. V prvním příspěvku popisuje Poinsot výhody dlouhodobých cílů a náklady ad-hoc rozhodnutí. Ve druhém příspěvku soudí, že „by měl být Bitcoin Core robustní oporou bitcoinové sítě, která hledá rovnováhu mezi bezpečností Bitcoin Core a přidáváním nových funkcí posilňujících a vylepšujících celou síť.“ Ve třetím příspěvku doporučuje rozdělit existující projekt na tři části: uzel, peněženku a grafické rozhraní. Tato možnost je nyní na dosah díky několikaletému úsilí stojícímu za podprojektem rozdělení aplikace do více běžících procesů (ve zpravodaji byl tento podprojekt poprvé zmíněn v č. 39, angl.).

  Anthony Towns pochybuje, že by běh ve více procesech opravdu umožnil efektivní rozdělení, neboť jednotlivé komponenty by nadále zůstaly úzce provázané. Mnoho změn učiněných v jednom projektu by si vyžádalo změny i v ostatních. Bylo by však jasnou výhrou, pokud by byly funkce, které nevyžadují uzel, extrahovány do nějaké knihovny nebo nástroje, jež by mohly být udržovány nezávisle. Dále popisuje, jak někteří lidé používají uzly s mezivrstvou, která jim usnadňuje připojit jejich peněženky k vlastním uzlům pomocí indexů blockchainu (v podstatě osobních prohlížečů bloků); Bitcoin Core v minulosti odmítl přidat podobnou funkci přímo do svého uzlu. Nakonec poznamenává, že dle něj „poskytování funkce peněženky (ve větší míře) a GUI (v menší míře) je způsob, jak držet směr bitcoinu jako použitelného decentralizovanou skupinou hackerů oproti něčemu, co můžou používat jen finanční velryby nebo zavedené korporace ochotné investovat ve velkém.”

  David Harding vyjádřil obavy, že změna zaměření hlavního projektu pouze na kód konsenzu a P2P přeposílání ztíží běžným uživatelům používání plného uzlu pro validování svých vlastních příchozích transakcí. Žádá Poinsota a jiné přispěvatele, aby namísto toho zvážili zaměřit se na snadnost používání Bitcoin Core. Popisuje sílu validování plným uzlem: ti, kteří provozují plné uzly validující převládající množství ekonomické aktivity, drží schopnost definovat bitcoinová pravidla konsenzu. Na příkladu ukazuje, že i pouhá 30minutová změna výběru vynucovaných pravidel může vést k politicky trvalému zničení opěvovaných vlastností bitcoinu, jako je omezení na 21 miliónů BTC. Věří, že každodenní uživatelé mají silnější motivaci zachovat vlastnosti bitcoinu než organizace provozující uzly pro své klienty. Pokud si vývojáři Bitcoin Core cení současných pravidel konsenzu, je dle Hardinga pro bezpečnost stejně důležité usnadňovat běžným uživatelům osobně ověřovat své transakce, jako je bránění a odstraňování chyb, které by mohly vést k vážným zranitelnostem.

Diskuze o změnách konsenzu

Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel bitcoinového konsenzu.

• ● Průvodce forkováním bitcoinu: Anthony Towns ve fóru Delving Bitcoin ohlásil průvodce budováním komunitního konsenzu pro změny bitcoinových pravidel konsenzu. Rozděluje sociální konsenzus do čtyř fází: výzkum a vývoj, zkoumání pokročilými uživateli, vyhodnocování průmyslem a posuzování investory. Dále se krátce zabývá technickými kroky, které přichází na konci procesu v rámci aktivace změn v bitcoinovém software.

  Jeho příspěvek poznamenává, že „je to jen průvodce cestou spolupráce, kde děláte změny, které zlepší život všech, a víceméně všichni se na tom nakonec shodnou.” Též varuje, že „průvodce hledí z dost velké výšky.”

• ● Aktualizace BIP360 pay-to-quantum-resistant-hash (P2QRH): vývojář Hunter Beast zaslal do emailové skupiny Bitcoin-Dev aktualizaci svého výzkumu kvantové rezistence pro BIP360. Změnil obsah seznamu kvantově bezpečných algoritmů, které navrhuje používat, hledá advokáta vývoje schématu pay-to-taproot-hash (P2TRH, viz též zpravodaj č. 141, angl.) a zvažuje zaměřit se na stejnou bezpečnostní úroveň, jakou poskytuje současný bitcoin (NIST Ⅱ), namísto vyšší úrovně (NIST Ⅴ), která by vyžadovala více blokového prostoru a procesoru během validace. Jeho příspěvek obdržel několik reakcí.

• ● Tržiště se soukromými šablonami bloků jako obrana před centralizujícím MEV: Matt Corallo a vývojář 7d5x9 zaslali do fóra Delving Bitcoin příspěvek o veřejných aukcích vybraného prostoru uvnitř šablon bloků. Příklad: „zaplatím X BTC za začlenění transakce Y, pokud bude před jakoukoliv transakcí chytrého kontraktu Z.” Toto již dnes chtějí tvůrci transakcí některých bitcoinových protokolu (např. určité protokoly s obarvenými mincemi) a pravděpodobně to bude v budoucnosti ještě žádanější v nových protokolech (včetně návrhů vyžadujících změnu konsenzu jako některé kovenanty).

  Pokud by služba preferenčního pořadí transakcí v bloku nebyla poskytována veřejným trhem redukujícím potřebu důvěry, je pravděpodobné, že by byla poskytována velkými těžaři, kteří by soupeřili s uživateli rozličných protokolů. To si od těžařů vyžádá obdržet velké množství kapitálu a technologie, což jim zřejmě umožní vydělávat mnohem více než menším těžařům bez podobných schopností. To povede k centralizaci těžby a umožní velkým těžařům snadněji cenzurovat bitcoinové transakce.

  Vývojáři navrhují umožnit těžařům pracovat na zaslepených šablonách bloků, jejichž kompletní transakce jim nebudou odhaleny, dokud nevyprodukují proof of work dostatečný ke zveřejnění bloku. Vývojáři navrhují dva mechanismy, které nevyžadují žádné změny konsenzu:

  • ● Důvěryhodné šablony bloků: těžař se připojí k tržišti, zvolí nabídky, které chce začlenit do bloku, a požádá tržiště o konstrukci šablony bloku. Tržiště odpoví hlavičkou bloku, mincetvornou transakcí a částečnou Merkleovou větví, které těžařovi umožní generovat šabloně proof of work, aniž by se dozvěděl její obsah. Pokud těžař vyprodukuje cílové množství proof of work, odešle tržišti hlavičku a mincetvornou transakci. Tržiště ověří proof of work, přidá ho do šablony a block zveřejní. Tržiště může začlenit transakci platící těžařovi přímo v šabloně nebo mu může zaplatit později.

  • ● Důvěryhodné spouštěcí prostředí: těžaři obdrží zařízení se zabezpečnou enklávou důvěryhodného spouštěcího prostředí (trusted execution environment, TEE), připojí se k tržišti, vyberou si nabídky, které chtějí začlenit do svých bloků, a obdrží transakce z těchto nabídek zašifrované klíčem z TEE. Šablona bloku je zkonstruována uvnitř TEE a TEE poskytne hlavičku bloku, mincetvornou transakci a částečnou Merkleovu větev. Pokud je vygenerován dostatečný proof of work, těžař ho poskytne TEE, které ho ověří a vrátí kompletní nešifrovanou šablonu bloku, do které může těžař přidat hlavičku a zveřejnit. I zde může šablona bloku obsahovat transakci platící těžařovi z UTXO patřícímu tržišti nebo tržiště může těžařovi zaplatit později.

  Obě schémata by v důsledku vyžadovala několik soupeřících tržišť. Návrh zmiňuje očekávání, že někteří členové komunity a organizace by provozovali nevýdělečná tržiště, aby bránili vzniku dominantního tržiště a napomohli tak zachovat decentralizaci.

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.02 je vydáním další hlavní verze tohoto oblíbeného LN uzlu. Přináší vedle vylepšení a oprav i podporu peer storage používaného pro ukládání zašifrovaných trestných transakcí, které mohou být vyžádány a dešifrovány jako druh strážních věží.

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.

• ● Eclair #3019 upřednostňuje v případě jednostranného zavření kanálu druhou stranou commitment transakci protistrany (z mempoolu) před zveřejněním místní transakce. Dříve uzel zveřejnil svou místní commitment transakci, což mohlo způsobit soupeření obou transakcí. Volba commitment transakce vzdálené strany je pro místní uzel výhodná, protože neobsahuje prodlevu místního OP_CHECKSEQUENCEVERIFY (CSV) časového zámku a nepotřebuje dodatečné transakce pro vyřešení čekajících HTLC.

• ● Eclair #3016 přináší nízkoúrovňové metody pro vytváření lightningových transakcí v jednoduchých taprootových kanálech. Žádné změny funkčnosti představeny nebyly. Skripty jsou vygenerovány z miniscriptu a odlišují se od specifikace v BOLTs #995.

• ● LDK #3342 přidává strukturu RouteParametersConfig, která uživatelům umožňuje upravit parametry routování v BOLT12 platbách. Nově tak lze nastavit max_total_cltv_expiry_delta, max_path_count a max_channel_saturation_power_of_half. Tato změna odpovídá podobnému nastavení v BOLT11.

• ● Rust Bitcoin #4114 snižuje minimální velikost transakce bez witnessů z 85 na 65 bajtů podobně jako Bitcoin Core (viz zpravodaje č. 222, angl., a č. 232). Nově tak budou povolené i transakce s jedním vstupem a jedním OP_RETURN výstupem.

• ● Rust Bitcoin #4111 přidává podporu nového standardního výstupu P2A představeného v Bitcoin Core 28.0 (viz zpravodaj č. 315).

• ● BIPs #1758 aktualizuje BIP374, který definuje doklady rovnosti diskrétních logaritmů (Discrete Log Equality Proofs, DLEQ; viz též zpraovdaj č. 335). Do výpočtu rand nově přidává zprávu. Změna brání možnému úniku soukromého klíče a, který mohl nastat, pokud byly dva doklady zkonstruovány se shodnými a, b a g, ale s odlišnými zprávami a nulovým r.

• ● BIPs #1750 aktualizuje BIP329, který definuje formát pro exportování štítků peněženek. Přidává volitelné pole asociované s adresami, transakcemi a výstupy.

• ● BIPs #1712 a BIPs #1771 přidávají BIP3, který nahrazuje BIP2. Mezi změny procesu schvalování BIP patří redukce hodnot stavu z devíti na čtyři, možnost zavřít návrh BIPu po roce nečinnosti a bez potvrzení autora o probíhající práci, možnost BIPu zůstat ve stavu Complete navždy, možnost dalších změn procesu schvalování, možnost delegovat některá editorská rozhodnutí na autory či čtenáře, odstranění systému komentářů a nutnost držet se tematického obsahu jako předpokladu pro obdržení čísla. Dále byly učiněny změny formátu a preambule.