Zpravodaj tento týden popisuje návrh na přeposílání slabých bloků za účelem vylepšení výkonnosti kompaktních bloků v síti s rozmanitými pravidly mempoolu a oznamuje přidání pětice editorů BIPů. Též nechybí naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními o nových vydáních a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Implementace ověření konceptu slabých bloků: Greg Sanders zaslal do fóra Delving Bitcoin příspěvek o použití slabých bloků (weak blocks) za účelem vylepšení přeposílání kompaktních bloků, obzvláště ve stavu roztříštěnosti těžby a pravidel pro přeposílání transakcí. Slabý blok je blok po všech stránkách validní, který však nemá dostatečný proof of work (PoW) na to, aby se stal příštím blokem. Těžaři produkují slabé bloky poměrně k procentu požadovaného PoW každého bloku. Například těžař vyprodukuje v průměru devět slabých bloků při požadovaných deseti procentech PoW na každý jím vyprodukovaný blok s plným PoW.

  Těžaři neví, kdy vyprodukují slabý blok. Každý jejich kandidát na blok má shodnou šanci dosáhnout plného PoW; některé z těchto kandidátů se namísto toho stanou slabými bloky. Jediným způsobem, jak slabý blok vytvořit, je provádět stejnou práci nutnou pro blok s plným PoW. Slabý blok tedy přesně odráží, které transakce se těžař pokoušel vytěžit v čase, kdy byl slabý blok vytvořen. Například jedinou možností, jak zahrnout nevalidní transakci do slabého bloku, je riskovat vytvoření bloku s plným PoW se stejnou nevalidní transakcí. Tento nevalidní blok by plné uzly odmítly a těžař by neobdržel odměnu. Samozřejmě těžař, který by nechtěl publikovat, jaké transakce se pokoušel vytěžit, může jednoduše odmítnout své slabé bloky zveřejnit.

  Díky vysoké obtížnosti vytváření desetiprocentních slabých bloků a vysokým nákladům na vytváření slabých bloků s nevalidními transakcemi by byly slabé bloky silně odolné vůči útokům odepřením služby, které by se mohly pokusit o plýtvání velkého množství šířky pásma uzlu, procesoru a paměti.

  Jelikož jsou slabé bloky standardními bloky s mírně nedostatečným PoW, mají i stejnou velikost jako běžné bloky. Když bylo přeposílání slabých bloků před deseti lety poprvé popsáno, znamenalo to, že by přeposílání desetiprocentních slabých bloků zvýšilo objem dat potřebných pro přeposílání bloků až desetkrát. Avšak před mnoha lety začal Bitcoin Core používat přeposílání kompaktních bloků, které v rámci bloku nahrazuje transakce krátkými identifikátory. To umožňuje přijímajícímu uzlu vyžádat si pouze ty transakce, které zatím neviděl. V běžném případě to snižuje objem přenášených dat o více než 99 %. Sanders poznamenává, že by to stejným způsobem fungovalo i v případě slabých bloků.

  U bloků s plným PoW nejenže přeposílání kompaktních bloků snižuje nároky na přenosové pásmo, ale též výrazně urychluje propagaci bloků. Čím méně dat (tedy méně kompletních transakcí) je potřeba poslat, tím rychleji mohou být zbývající data poslána. Rychlejší propagace nových bloků je důležitá pro decentralizaci těžby: těžař, který nalezne nový blok, může na jeho následníkovi začít pracovat okamžitě, ale ostatní těžaři musí čekat, až ze sítě nový blok obdrží. To dává výhodu velkým těžařským poolům a vytváří to nezamýšlený druh útoku, sobecké těžby (viz zpravodaj č. 244). Tento problém byl před příchodem přeposílání kompaktních bloků běžný a vedl k centralizaci těžby do velkých poolů a k používání problematických technik, jako je podloudná těžba vedoucí v červenci 2015 k štěpením blokchainu.

  Přeposílání kompaktních bloků šetří přenosové pásmo a urychluje propagaci bloků pouze, pokud příjemce nového bloku již viděl většinu jeho transakcí. Avšak jak Sanders poznamenává, někteří těžaři v současnosti vytváří bloky s mnoha transakcemi, které se mezi uzly nešíří. To snižuje účinnost přeposílání kompaktních bloků a zvyšuje riziko výskytu stejných problémů, které existovaly před příchodem kompaktních bloků. Jako řešení navrhuje přeposílání slabých bloků:

  • Těžaři, kteří vytvoří slabé bloky (např. desetiprocentní), by je příležitostně přeposlali uzlům. Příležitostně znamená, že by byl přenos považován za běžný P2P síťový provoz, podobně jako přeposílání nových, nepotvrzených transakcí, a nikoliv jako prioritní provoz, který využívají například nové bloky.

  • Uzly by příležitostně tyto slabé bloky přijaly a validovaly. Ověření PoW je triviální a nastalo by okamžitě. Poté by byl blok dočasně uložen v paměti, zatímco by byly ověřovány jeho transakce. Validní transakce z tohoto slabého bloku by byly přidány do mempoolu. Transakce, které validací neprojdou, by byly uloženy do vyhrazené mezipaměti. Podobné mezipaměti již Bitcoin Core používá k dočasnému uložení transakcí, které do mempoolu přidány být nemohou (např. mezipaměť osiřelých transakcí).

  • Další příchozí slabé bloky by mempool a mezipaměť aktualizovaly.

  • Když uzel pomocí kompaktního přeposílání obdrží blok s plným PoW, mohl by využít transakce uložené v mempoolu a mezipaměti slabých bloků. Potřeba další prodlevy a přenosového pásma by tak byla minimalizovaná. Díky tomu by mohla síť, ve které se vyskytuje mnoho uzlů s roztříštěnými pravidly, i nadále využívat výhod kompaktních bloků.

  Dále Sanders poukazuje na předchozí diskuzi o slabých blocích (viz zpravodaj č. 173, angl.) popisující, jak by mohly slabé bloky pomoci v boji proti pinningovým útokům a ve vylepšení odhadu poplatků. Používání slabých bloků bylo též dříve zmíněno v diskuzi o přeposílání transakcí protokolem Nostr (viz zpravodaj č. 253).

  Sanders napsal „základ ověření konceptu s jednoduchými testy, které ukazují jádro myšlenky.“ Diskuze v době psaní zpravodaje nadále probíhala.

• ● Aktualizace o editorech BIPů: po veřejné diskuzi (viz zpravodaje č. 292, č. 296 a č. 297) byli představeni noví editoři BIPů: Bryan „Kanzure“ Bishop, Jon Atack, Mark „Murch” Erhardt, Olaoluwa „Roasbeef” Osuntokun a Ruben Somsen.

Vybrané otázky a odpovědi z Bitcoin Stack Exchange

Bitcoin Stack Exchange je jedním z prvních míst, kde hledají přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme některé z otázek a odpovědí, které obdržely vysoký počet hlasů.

• ● Kde přesně je ve výpočtu obtížnosti off-by-one chyba? Antoine Poinsot vysvětluje off-by-one chybu (o jedničku vedle) ve výpočtu nové hodnoty obtížnosti, která umožňuje útok ohýbáním času („time warp attack”). Tuto chybu se snaží adresovat návrh na pročištění konsenzu (viz zpravodaj č. 296).

• ● Jak je z vývojářova pohledu v používání opkódů odlišné P2TR oproti P2PKH? Murch usuzuje, že by skript z příkladu použitý jako P2PKH výstup byl nestandardní a dražší než P2TR, ale validní z pohledu konsenzu.

• ● Jsou nahrazující transakce větší než jejich předchůdci a neRBF transakce? Vojtěch Strnad poznamenává, že transakce signalizující RBF mají stejnou velikost jako nesignalizující transakce. Dále uvádí scénáře, ve kterých by nahrazující transakce mohla být buď stejně velká, větší či menší než původní, nahrazovaná transakce.

• ● Jsou bitcoinové podpisy stále zranitelné opakovaným používáním nonce? Pieter Wuille potvrzuje, že Schnorrovy podpisy i ECDSA podpisy – včetně jejich multisig variant – jsou zranitelné vůči opakovanému používání nonce.

• ● Jak těžaři ručně přidávají transakce do šablony bloku? Ava Chow nastiňuje odlišné přístupy, kterých by těžař mohl využít k začlenění transakcí do bloku, které by v něm po použití volání Bitcoin Core getblocktemplate jinak chyběly:

  • voláním sendrawtransaction přidat transakci do těžařova mempoolu a nato upravit její zjevný absolutní poplatek pomocí prioritisetransaction
  • použít upravenou implementaci getblocktemplate nebo zvláštní software pro tvorbu bloků

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.17.5-beta je údržbovým vydáním, které přináší kompatibilitu s Bitcoin Core 27.x.

  Jak bylo vývojářům LND reportováno, starší verze LND závisející na starší verzi btcd zamýšlela nastavit maximální jednotkový poplatek na 10 miliónů sat/kB (0,1 BTC/kB). Avšak Bitcoin Core vyžaduje jednotkové poplatky v BTC/kvB; maximální jednotkový poplatek byl tedy nastaven na 10 miliónů BTC/kvB. Bitcoin Core 27.0 obsahuje PR, které omezuje maximální jednotkový poplatek na 1 BTC/kvB, aby předešel některým problémům. Předpokládá, že pokud by někdo nastavoval vyšší hodnotu, pravděpodobně by to bylo kvůli chybě (pokud by opravdu vyšší hodnotu zamýšlel, mohl by nastavit parametr na 0 a tím kontrolu obejít). V tomto případě LND (via btcd) opravdu chybu činilo, ale změna v Bitcoin Core zabraňovala LND v odesílání onchain transakcí. To může být pro LN uzel nebezpečné, neboť někdy spoléhá na časově citlivé transakce. Toto údržbové vydání správně nastavuje maximální hodnotu na 0,1 BTC/kvB v souladu s novými verzemi Bitcoin Core.

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

• ● Bitcoin Core #29850 omezuje maximální počet IP adres akceptovaný od jednoho DNS seedu na 32 na dotaz. Při dotazování DNS přes UDP omezuje maximální velikost paketu tento počet na 33, avšak alternativní dotazování DNS přes TCP může nyní vrátit mnohem vyšší počet výsledků. Aby posbíraly IP adresy, připojují se nové uzly k několika DNS seedům. Poté náhodně vyberou některé z těchto adres a připojí se k nim. Pokud tento uzel obdrží od každého seedu zhruba stejný počet IP adres, je nepravděpodobné, že by všechny zvolené uzly, ke kterým se připojí, pocházely od stejného seedu. To napomáhá zajisti, aby měl uzel rozmanitý pohled na síť a nebyl náchylný k útokům zastíněním.

  Avšak pokud by některý ze seedů vrátil mnohem větší počet IP adres než ostatní, existovala by vysoká pravděpodobnost, že by tento uzel náhodně zvolil množinu IP adres pocházejících právě od toho seedu. Pokud by měl tento seed zlé úmysly, mohl by uzel izolovat od čestné sítě. Testování ukázalo, že všechny seedy v té době vracely 50 či méně výsledků, ačkoliv byl maximální povolený počet 256. Toto začleněné PR omezuje maximální počet na podobnou velikost, kterou současné seedy vrací.