Tento týden přinášíme souhrn diskuze o umožnění přeposílání transakcí obsahující data v taprootové příloze a odkazujeme na návrh BIP na tiché platby. Též nechybí další příspěvek v naší krátké týdenní sérii o pravidlech mempoolu a pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Clubu, oznámeními o nových vydáních a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Diskuze o taprootových přílohách: Joost Jager zaslal do emailové skupiny Bitcoin-Dev příspěvek s žádostí o změnu v pravidlech přeposílání transakcí a těžby v Bitcoin Core, aby umožnily ukládání libovolných dat v rámci přílohy („annex”) v taprootu. Toto pole je volitelnou součástí dat witnessu taprootových transakcí. Je-li přítomno, musí se podpisy v taprootu a tapscriptu týkat i jeho dat (aby je nemohla třetí strana změnit, přidat nebo odebrat), ale v současnosti nemá definovaný žádný další význam. Je rezervováno pro budoucí upgrady protokolu, obzvláště soft forky.

    I když se v minulosti objevily návrhy na definování formátu přílohy, nedočkaly se obecného přijetí ani implementace. Jager navrhuje dva formáty (1, 2), které by mohly být použity k přidání libovolných dat způsobem, jež by výrazně nekomplikoval pozdější pokusy o standardizaci svázanou s případným soft forkem.

    Greg Sanders se v odpovědi tázal, jaká data by chtěl Jager konkrétně v příloze ukládat, a popsal své vlastní využívání přílohy v rámci testování protokolu LN-Symmetry s návrhem soft forku SIGHASH_ANYPREVOUT pomocí Bitcoin Inquisition (viz zpravodaj č. 244). Sanders také popsal problém s přílohami: v protokolech s více stranami (jako je coinjoin) zavazuje každý podpis k příloze vstupu obsahující tento podpis a ne k přílohám ostatních vstupů ve stejné transakci. To znamená, že pokud by Alice, Bob a Mallory spolu podepsali coinjoin, nemohou Alice ani Bob zabránit Mallorymu ve zveřejnění verze transakce s větší přílohou, která by zpozdila konfirmaci. Jelikož Bitcoin Core a ostatní implementace plných uzlů v současnosti nepřeposílají transakce obsahující přílohy, nepředstavuje to zatím žádný problém. Jager odpověděl, že chce ukládat podpisy dočasných klíčů pro druh úschoven, který nevyžaduje soft fork, a navrhl, že tento problém s přeposíláním příloh v některých protokolech s více stranami by mohl řešit předchozí pokus v Bitcoin Core.

Čekání na potvrzení 5: pravidla pro ochranu zdrojů uzlů

Krátká týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Na počátku naší série jsme uvedli, že většina ochrany soukromí a odolnost vůči cenzuře pramení z decentralizace bitcoinové sítě. Uživatelé provozující uzly napomáhají k redukci počtu slabých míst, špehování a cenzury. Vyplývá z toho, že jedním z hlavních cílů designu software bitcoinového uzlu je jeho vysoká dostupnost. Pokud by byli uživatelé nuceni pořídit si drahý hardware, používat konkrétní operační systém nebo platit měsíčně stovky dolarů za jeho provozování, počet uzlů v síti by nejspíš klesl.

Navíc je takový uzel bitcoinové sítě připojen pomocí internetu k neznámým entitám, které mohou spustit útok odepření služby (DoS) a způsobit tím pád uzlu vyčerpáním paměti nebo plýtvání výpočetními a přenosovými zdroji. Jelikož jsou tyto entity anonymní, nemohou naše uzly před připojením určit, které uzly budou poctivé a které zlomyslné, a nemohou je ani po detekci útoku účinně zakázat. Je tedy nutné, aby byla implementována pravidla, která chrání před DoS a omezují náklady na provozování plného uzlu.

Všeobecné ochrany proti DoS a vyčerpání zdrojů jsou vestavěné přímo do software uzlů. Například obdrží-li Bitcoin Core od jediného spojení velké množství zpráv, zpracuje pouze první z nich, zbytek uloží do fronty a zpracuje je pouze, až obdrží a zpracuje zprávy od jiných spojení. Uzly také obvykle nejdříve stáhnou pouze hlavičku bloku, ověří její Proof of Work (PoW) a teprve potom stáhnou a ověří zbytek bloku. Útočník, který by chtěl vyčerpat zdroje uzlu v rámci přeposílání bloků, by tak nejdříve musel věnovat nepřiměřené množství vlastních zdrojů k výpočtu validního PoW. Tato asymetrie mezi obrovskými náklady na výpočet PoW a minimálními náklady na jeho ověření poskytuje přirozený způsob ochrany DoS v rámci přeposílání bloků. Tuto vlastnost však nemá přeposílání nepotvrzených transakcí.

Všeobecné ochrany proti DoS však neposkytují dostatečné překážky proti jiným druhům útoků. Útočník může například zbastlit maximálně výpočetně náročnou validní transakci, jako byla 1MB „megatransakce” v bloku 364292, jejíž validace trvala mimořádně dlouho dobu kvůli ověřování podpisů a kvadratickému sighashingu. Útočník může také za řadu validních podpisů přidat jeden nevalidní, kvůli čemuž stráví uzel nad transakcí několik minut, aby zjistil, že se jedná o zmetka. Během té doby uzel nepracuje na novém bloku. Můžeme si představit, že takový druh útoku by cílil na konkurenční těžaře, aby jim zpozdil počátek hledání nového bloku.

Ve snaze vyhnout se práci na výpočetně velmi náročných transakcích omezují uzly s Bitcoin Core maximální velikost a počet operací s podpisy (tzv. „sigops”) v každé transakci více, než jsou limity konsenzu. Uzly s Bitcoin Core také vynucují omezení na velikost balíčků předků a potomků, díky čemuž jsou produkce šablon bloků a algoritmy vylučování účinnější a výpočetní náročnost přidání do a odebírání z mempoolu nižší. I když kvůli těmto pravidlům mohou být vyloučeny některé validní transakce, očekává se, že podobné případy budou vzácné.

Tato pravidla jsou příklady pravidel přeposílání transakcí („transaction relay policy”), jež existují nad rámec pravidel konsenzu a týkají se nepotvrzených transakcí.

Ve výchozím stavu neakceptuje Bitcoin Core transakce s nižším jednotkovým poplatkem než 1 sat/vB („minrelaytxfee”), neověřují žádné podpisy před ověřením tohoto požadavku a nepřeposílají transakce, dokud nejsou přijaty do jejich vlastních mempoolů. Ve své podstatě stanovuje toto pravidlo minimální „cenu” za validaci a přeposílání. Netěžící uzly nikdy poplatky neobdrží, pouze těžař, který transakci potvrdí, dostane zaplaceno. Poplatky však přináší náklady útočníkovi. Kdo posílá extrémní množství transakci a „plýtvá” tak síťovými zdroji, brzy přijde platbou poplatků o všechny peníze.

Pravidla nahrazování poplatkem („replace by fee”) implementována v Bitcoin Core vyžadují, aby nahrazující transakce platila vyšší jednotkový poplatek než kterákoliv transakce, se kterou je v přímém konfliktu, a také aby celkový poplatek byl vyšší než poplatek za všechny transakce, které nahrazuje. Dodatečné poplatky vydělené virtuální velikostí nahrazující transakce musí být vyšší než 1 sat/vB. Jinými slovy, bez ohledu na jednotkový poplatek původní a nahrazující transakce musí nová transakce zaplatit „nové” poplatky, aby pokryla své vlastní přenosové náklady za cenu 1 sat/vB. Hlavní důvod tohoto pravidla je zdražit opakované útoky plýtvající přenosovým pásmem, např. takové, kdy každé další nahrazení přidává jediný satoshi.

Uzel, který kompletně validuje bloky a transakce, vyžaduje zdroje včetně paměti, výpočetních zdrojů a přenosového pásma. Musíme zajistit, aby požadavky na zdroje byly co nejnižší a aby tak bylo provozování uzlu přístupné a odolné vůči vykořisťování. Všeobecné DoS ochrany nejsou dostatečné, proto uzly vedle pravidel konsenzu aplikují během validace nepotvrzených transakcí navíc i pravidla přeposílání transakcí. Jelikož však pravidla nejsou konsenzem, dva uzly mohou mít pravidla nastavena odlišně a i tak mohou dojít ke shodě na stavu blockchainu. Příští týden popíšeme pravidla jako individuální volbu.

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

Umožni příchozím whitebind spojením agresivněji vyhazovat spojení během plných slotů je PR od Matthew Zipkina (pinheadmz), které zlepšuje možnosti provozovatele uzlu v určitých případech nastavit žádoucí spojení uzlu. Konkrétně pokud operátor explicitně povolí potenciální příchozí spojení (například lehkého klienta pod jeho kontrolou), mohlo by se bez tohoto PR stát, že by mu byl v určitém stavu odepřen pokus o připojení.

Toto PR zvyšuje pravděpodobnost, že by bylo toto žádoucí spojení úspěšně navázáno. Činí tak tím, že by vyhodilo jiné příchozí spojení, které bylo před PR nevyhoditelné.

  • Proč se toto PR týká pouze žádostí o příchozí připojení?

    Náš uzel iniciuje odchozí spojení; toto PR mění způsob, kterým uzel reaguje na žádost o příchozí spojení. Odchozí uzly mohou být též vyhozeny, ale to má na starosti zcela odlišný algoritmus. ➚

  • Jaký dopad na návratovou hodnotu funkce SelectNodeToEvict() má parametr force?

    Nastavení force na true zajišťuje, že je vráceno příchozí spojení bez noban, pokud existuje, i když by bylo jinak před vyhozením chráněno. Bez tohoto PR by funkce nevrátila nic, pokud jsou všechna spojení před vyhozením chráněna. ➚

  • Jak se tímto PR mění signatura funkce EraseLastKElements()?

    Místo void vrací funkce poslední položku, která byla ze seznamu kandidátů pro vyhození odstraněna. (Tento „chráněný” uzel může být v případě potřeby vyhozen.) Avšak v důsledku diskuze pod sezením review clubu bylo toto PR později zjednodušeno a tato funkce zůstala nakonec nezměněna. ➚

  • EraseLastKElements bývalo template funkcí, toto PR však odstraňuje dva template argumenty. Proč? Jaké jsou zápory této změny?

    Tato funkce byla a (tímto PR) je volána s jedinečnými template argumenty, není tedy potřeba, aby zůstala template. Nakonec byly změny této funkce revertovány, neboť byly mimo rámec PR. ➚

  • Předpokládejme, že předáme funkci SelectNodeToEvict() seznam 40 kandidátů na vyhození. Jaký je před a po PR teoretický maximální počet Tor uzlů, které mohou být chráněny před vyhozením?

    Před i po PR je počet 34 ze 40 za předpokladu, že nejsou příchozí a nemají noban. ➚

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 23.05.1 je údržbovým vydáním této implementace LN. Poznámky k vydání udávají: „vydání obsahuje pouze opravy chyb způsobující několik pádů. Doporučuje se upgrade z v23.05.”

Významné změny v kódu a dokumentaci

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.

  • ● Bitcoin Core #27501 přidává RPC volání getprioritisedtransactions, které vrací mapu všech fee delta vytvořených uživateli pomocí prioritisetransaction s txid jako klíči. Mapa též ukazuje, jsou-li transakce v mempoolu. Viz též zpravodaj č. 250.

  • ● Core Lightning #6243 mění RPC volání listconfigs. Nově budou všechny konfigurační informace obsaženy v jediném slovníku. Dále bude stav všech konfiguračních voleb předávat restartovaným pluginům.

  • ● Eclair #2677 navyšuje výchozí max_cltv z 1 008 bloků (zhruba jeden týden) na 2 016 bloků (zhruba dva týdny). Rozšiřuje tím maximální povolený počet bloků před tím, než platba expiruje. Změna byla motivována uzly rozšiřujícími svá rezervovaná časová okna, aby řešily HTLC expirující (cltv_expiry_delta) kvůli vysokým onchain poplatkům. Podobné změny byly začleněny do LND i CLN.

  • ● Rust bitcoin #1890 přidává metodu pro spočítání operací s podpisy (sigops) v netapscriptových skriptech. Počet sigops v bloku je omezen a kód výběru transakcí během těžby v Bitcoin Core zachází s transakcemi s vysokým poměrem sigops a velikosti (váhy), jakoby byly větší, čímž v důsledku snižuje jejich jednotkový poplatek. Tato metoda může být důležitá pro všechny, kdo vytváří nové transakce.