Tento týden přeposíláme žádost o poskytnutí zpětné vazby k návrhu na odstranění podpory BIP35 P2P zprávy mempool v Bitcoin Core. Dále nechybí naše pravidelné rubriky s oblíbený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í bitcoinových páteřních projektech.

Novinky

• ● Návrh na odstranění BIP35 P2P zprávy mempool: Will Clark zaslal do emailové skupiny Bitcoin-Dev příspěvek o PR, který otevřel za účelem odstranění podpory pro P2P zprávu mempool, která byla původně specifikována v BIP35. Dle původní implementace by uzel po obdržení zprávy mempool měl odpovědět zprávou inv obsahující ID všech transakcí v jeho mempoolu. Uzel, který odeslal původní požadavek, by poté mohl běžnou zprávou getdata požádat o data kterékoliv transakce. BIP popisuje tři důvody pro existenci této zprávy: diagnostika síťového provozu, možnost odlehčených klientů žádat o nepotvrzené transakce a možnost těžařů požádat po restartu o nepotvrzené transakce (v té době Bitcoin Core ještě neukládal mempool na disk).

  Avšak později byly vyvinuty techniky, které zneužívaly zprávy mempool a getdata k určení, který uzel jako první odeslal nějakou transakci. Pro zlepšení soukromí odesílatele transakcí byla později odstraněna možnost požádat jiné uzly o neoznámené transakce a zpráva mempool mohla být použita pouze s bloom filtry transakcí (dle BIP37). Ještě později Bitcoin Core ve výchozím stavu bloom filtr neaktivoval (viz zpravodaj č. 56, angl.) a umožnil jej používat pouze se spojeními, která měla aktivovanou volbu whitelist (zpravodaj č. 60, angl.). To ve svém důsledku znamená, že i zpráva mempool je ve výchozím stavu neaktivní.

  Clarkův pull request do Bitcoin Core obdržel podporu, avšak někteří z podporujících soudí, že by měly být nejprve odstraněny BIP37 bloom filtry. Zatím jediná reakce v emailové skupině poznamenává, že odlehčené klienty, které se připojují k důvěryhodným uzlům, mohou v současnosti využívat BIP35 a BIP37 jako nejefektivnějšího způsobu, jak se mohou dozvědět o nepotvrzených transakcích. Autor příspěvku navrhl, aby Bitcoin Core před odstraněním současného rozhraní nejdříve poskytl alternativní způsob.

  Lidé, kteří používají BIP35 zprávu mempool, jsou žádáni o poskytnutí zpětné vazby buď v emailové skupině nebo PR.

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

• ● Kolik sigops je v nevalidním bloku 783426? Vojtěch Strnad poskytl skript, který prochází všechny transakce v bloku a počítá sigops (opkódy, které ověřují elektronické podpisy). Napočítal 80 003 sigops, což blok činí nevalidním.

• ● Jak by mohl útočník až 500krát zvýšit poplatek potřebný k nahrazení transakce? Michael Folkson poukazuje na návrh BIP pro dočasné anchor výstupy („ephemeral anchors”) a táže se, jakým způsobem je možné 500krát navýšit poplatek vyžadovaný pro nahrazení transakce. Antoine Poinsot poskytuje příklad, jak by útočník mohl zneužít pravidla navýšení poplatku pomocí Replace-By-Fee (RBF) k vyžádání dodatečných transakcí, které by platily výrazně vyšší poplatky.

• ● Jak nejlépe na vícenásobné CPFP a CPFP + RBF? Sdaftuar vysvětluje techniku navyšování poplatků pomocí RBF a CPFP (Child Pays For Parent) v situaci, kdy prvotní pokus o navýšení pomocí CPFP selže z důvodu nedostatečného jednotkového poplatku.

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.

• ● LDK 0.0.115 je vydáním této knihovny pro stavbu peněženek a aplikací s LN. Obsahuje několik nových funkcí a oprav chyb, včetně lepší podpory pro experimentální protokol nabídek a vylepšené bezpečnosti a soukromí.

• ● LND v0.16.1-beta je vydáním této implementace LN, která obsahuje několik oprav a další vylepšení. Poznámky o vydání zmiňují, že CLTV delta byla navýšena ze 40 bloků na 80 (viz zpravodaj č. 40, který se zabývá předchozí změnou výchozí hodnoty).

• ● Core Lightning 23.05rc1 je kandidátem na vydání příští verze této implementace LN.

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.

• ● LND #7564 nyní umožňuje, aby uživatelé backendů poskytujících přístup do mempoolu mohli monitorovat nepotvrzené transakce obsahující předobraz HTLC svých kanálů. Díky tomu může uzel rychleji vyřídit HTLC, jelikož nemusí čekat na potvrzení transakce.

• ● LND #6903 přidává do RPC volání openchannel novou volbu fundmax, která alokuje všechny prostředky kanálu na nový kanál. Vyňaty jsou částky potřebné k přidání poplatků pomocí anchor výstupů.

• ● LDK #2198 prodlužuje dobu, po kterou LDK čeká, než odešle gossip zprávu oznamující nedostupnost kanálu (např. kvůli nedostupnému spojení). V předešlé verzi čekalo LDK zhruba minutu, avšak jiné implementace čekají déle. Existující návrh doporučuje používat počet bloků namísto unixové času, což by si vynutilo aktualizaci gossip zpráv jednou za blok (průměrně zhruba každých deset minut). Ač PR poznamenává, že pomalejší odesílání aktualizací má klady i zápory, nastavuje novou hodnotu na deset minut.

• ● Bitcoin Inquisition #23 přidává částečnou podporu dočasných anchor výstupů. Nepřináší podporu přeposílání v3 transakcí, kterou dočasné anchor výstupy potřebují k zabránění transaction pinning útokům.