Zpravodaj tento týden popisuje práci Hornet Node na deklarativní spustitelné specifikaci pravidel konsenzu a shrnuje diskuzi o zahlcování onion zprávami v lightningové síti. Též nechybí naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, s oznámeními nových vydání a s popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Hornet Node a deklarativní specifikace pravidel bitcoinového konsenzu: Toby Sharp zaslal do fóra Delving Bitcoin a do emailové skupiny Bitcoin-Dev příspěvek o aktualizaci projektu Hornet. Sharp dříve popsal novou implementaci uzlu, která snížila čas úvodního stahování bloků ze 167 minut na 15 minut. V této aktualizaci představuje dokončení deklarativní specifikace pravidel validace neskriptových objektů bloku sestávající se z 34 sémantických neměnných kombinovaných pomocí jednoduché algebry.

    Sharp dále nastínil budoucí práci, včetně rozšíření specifikace o validaci skriptů, a diskutoval možné porovnání s implementacemi, jako je libbitcoin, v odpovědi na zpětnou vazbu od Erica Voskuila.

  • ● Zahlcování lightningové sítě onion zprávami: Erick Cestari zaslal do fóra Delving Bitcoin příspěvek o problému zahlcování lightningové sítě onion zprávami (onion message jamming). BOLT4 přiznává, že jsou onion zprávy nespolehlivé, a doporučuje implementacím používat techniky omezování rychlosti. Dle Cestariho jsou právě tyto techniky tím, co zahlcování umožňuje. Útočníci mohou rozběhnout škodící uzly a zahltit síť nevyžádanými zprávami, které aktivují omezení rychlosti u peer spojení, čímž je donutí zahazovat legitimní zprávy. BOLT4 navíc nevynucuje maximální délku zprávy, což útočníkům umožňuje maximalizovat dosah jediné zprávy.

    Cestari prozkoumal několik opatření proti zahlcování onion zprávami a poskytl přehled technik, které jsou dle něj vhodné:

    • ● Poplatky předem: Tuto techniku poprvé navrhla Carla Kirk-Cohen v BOLTs #1052 jako řešení zahlcování kanálů, avšak může být snadno rozšířena. Uzly by inzerovaly pevný poplatek za zprávu, který by byl zaplacen každému skoku. Pokud by poplatek zaplacen nebyl, zpráva by byla zahozena. Metoda má několik omezení, jako schopnost přeposílat zprávy pouze spojením kanálu a zvýšený P2P provoz.

    • ● Omezení skoků a přeposílání na základě podílu v kanálu: Tuto techniku navrhli Bashiri a Khabbazian. Sestává ze dvou komponent:

      • Omezení počtu skoků: Buď nastavení maximálního počtu skoků, které může zpráva provést (např. tři skoky), nebo vyřešení hádanky s proof of work, jejíž náročnost se zvyšuje exponenciálně s počtem skoků.

      • Síla přeposílání na základě podílu: Každý uzel nastaví pro spojení omezení rychlosti na základě zůstatku kanálu (proof of stake), čímž dostanou dobře financované uzly více možnosti přeposílání.

      Tento přístup přijímá některé kompromisy vztažené k centralizačnímu tlaku, jelikož staví velké uzly do výhody a omezení na tři skoky by mohlo snížit anonymizační množinu.

    • ● Placení za přenosové pásmo: Tato technika (bandwidth metered payment), kterou navrhl Olaoluwa Osuntokun, je podobná poplatkům předem, avšak přidává pro každé sezení stav a urovnává přes AMP platby. Odesílatel by nejdříve poslal AMP platbu, jejíž poplatek se každým krokem snižuje a která doručí identifikátor sezení. Odesílatel by dále přiložil tento identifikátor do onion zprávy. Známá omezení tohoto přístupu se vztahují k schopnosti přeposílat zprávy pouze spojením kanálu a k možnosti spojit všechny zprávy do stejného sezení.

    • ● Rychlostní limit založený na zpětné propagaci: Tento přístup navrhl Bastien Teinturier. Používá backpressure, který je statisticky schopen vysledovat spam k jeho zdroji. Když peer spojení dosáhne rychlostního limitu, pošle uzel drop zprávu odesílateli, který ji nato přepošle poslednímu spojení, které původní zprávu přeposlalo. Tím sníží rychlostní limit na polovinu. Původní odesílatel je identifikován statisticky, penalizován by tak mohl být nesprávný peer. Navíc by útočník mohl falšovat drop zprávy a snižovat rychlostní limity poctivých uzlů.

    Nakonec Cestari vyzval LN vývojáře k diskuzi. Dodal, že stále je čas pro opatření, než vážné DDoS zasáhnou síť, jako se nedávno stalo Toru.

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

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.

  • ● Bitcoin Core 31.0 je novým vydáním hlavní verze této převládající implementace plného uzlu. Poznámky k vydání popisují několik významných vylepšení, včetně implementace mempoolu clusterů, nové volby -privatebroadcast pro sendrawtransaction (viz zpravodaj č. 388), dat asmap volitelně přidaných do binárky pro ochranu před útoky zastíněním a navýšení výchozí hodnoty -dbcache na 1024 MiB na systémech s více než 4096 MiB paměti.

  • ● Core Lightning 26.04 je hlavním vydáním této populární implementace LN uzlu. Přináší ve výchozím nastavení aktivní splicing, nové příkazy splicein a spliceout včetně režimu cross-splice, který použije druhý kanál jako cíl pro splice out, předělaný design bkpr-report pro souhrn příjmů, paralelní hledání cest a opravy několika chyb v askrene, přidává do RPC offer a nastavení payment-fronting-node volbu fronting_nodes a odstraňuje podporu pro zastaralý formát onionu. Poznámky k vydání popisují další podrobnosti.

  • ● LND 0.21.0-beta.rc1 je prvním kandidátem na vydání příští hlavní verze tohoto populárního LN uzlu. Uživatelé provozující uzly s příznakem --db.use-native-sql s SQLite nebo PostgreSQL by měli vědět, že tato verze migruje úložiště plateb z key-value formátu na nativní SQL (s možností přeskočit migraci volbou --db.skip-native-sql-migration). Viz též poznámky k vydání.

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 #33477 mění, jak režim rollback RPC příkazu dumptxoutset (viz zpravodaj č. 72, angl.) sestavuje export množiny historických UTXO používaných pro assumeUTXO snapshoty. Namísto vrácení hlavního stavu (chainstate) pomocí invalidace bloků nově Bitcoin Core vytvoří dočasnou UTXO databázi, vrátí ji na požadovanou výšku a vytvoří snapshot z této dočasné databáze. Tím je hlavní stav zachován a není třeba pozastavit síťovou aktivitu ani riskovat potíže s větvením řetězce. Cenou je dodatečný prostor na disku a pomalejší proces exportování. Nová volba in_memory bude držet dočasnou UTXO databázi pouze v paměti. To zvýší rychlost za cenu mít k dispozici více než 10 GB (na mainnetu) volné paměti. Pro práci s větší hloubkou je doporučeno nepoužívat RPC timeout (bitcoin-cli -rpcclienttimeout=0), neboť operace může trvat několik minut.

  • ● Bitcoin Core #35006 přidává do bitcoin-cli volbu -rpcid, která nastaví daný řetězec jako id v JSON-RPC žádosti namísto pevně dané hodnoty 1. Tím mohou být žádosti a odpovědi korelované během více paralelních volání. Identifikátor je také zapsán do serverového logu.

  • ● BIPs #1895 zveřejňuje BIP361, který představuje abstraktní návrh na postkvantovou migraci a ukončení zastaralých podpisů. Za předpokladu, že je standardizováno a nasazeno nějaké postkvantové (PQ) schéma podpisů, tento návrh předkládá migraci z ECDSA/Schnorra v několika fázích. Současná verze návrhu je rozdělena do dvou fází. Fáze A zakazuje posílat prostředky na kvantově zranitelné adresy, čímž urychlí používání PQ adres. Fáze B omezuje utrácení ECDSA/Schnorra vnuceným kvantově bezpečným záchranným protokolem, který by krádeži kvantově zranitelných UTXO zabránil.

  • ● BIPs #2142 přidává do BIP352, návrhu na tiché platby, testovací data pro odeslání a přijímání v krajním případě, kdy průběžný součet vstupních klíčů dosáhne po dvou vstupech nuly, i když celkový součet všech vstupů je nenulový. Tato data zachytí případ, kdy implementace ukončí výpočet příliš brzy.

  • ● LDK #4555 opravuje, jak přeposílající uzly vynucují max_cltv_expiry u zaslepených platebních cest. Toto pole má zajistit, aby byly expirované zaslepené cesty odmítnuté úvodním skokem a nebyly přeposlané zaslepeným segmentem. Dříve LDK tuto hodnotu porovnávalo s výchozí CLTV hodnotou skoku, nově kontroluje příchozí.

  • ● LND #10713 přidává omezení rychlosti, globální a na spojení, příchozích onion zpráv. Nadměrný provoz se zahodí hned na začátku, ještě před zpracováním zprávy. Tím se navýší robustnost nedávno přidané podpory přeposílání onion zpráv (viz zpravodaj č. 396) s lepší ochranou proti zneužití. Omezení mají stejné hodnoty jako dříve představené limit gossip zpráv (viz zpravodaj č. 370, angl.).

  • ● LND #10754 přestává přeposílat onion message, pokud je zvolený příští skok stejné peer spojení, které zprávu doručilo.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 28. 4. v 16:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.