V tomto čísle našeho zpravodaje popisujeme návrh k zamezení útoku zahlcením kanálu v Lightning Network pomocí osvědčení o reputaci. Dále přinášíme naše pravidelné rubriky s oznámeními o nových vydáních a významných změnách oblíbeného bitcoinového páteřního software.

Novinky

• ● Návrh na použití osvědčení o reputaci k zamezení zahlcování LN: Antoine Riard poslal do emailové skupiny Lightning-Dev návrh na systém osvědčení o reputaci jako prostředku k předcházení tzv. útoků zahlcením kanálu („channel jamming attacks”). Tento typ útoku způsobuje dočasné zablokování platebních slotů (HTLC), a znemožňuje tak poctivým uživatelům posílat platby.

  V rámci Lightning Network volí odesílatel trasu ze svého uzlu do uzlu příjemce za použití několika kanálů provozovaných nezávislými prostředníky. Odesílatel generuje sadu instrukcí, které popisují, kam má každý prostředník platbu dále přeposlat. Tyto instrukce jsou zašifrovány tak, aby se každý z prostředníků dozvěděl pouze informace nezbytně nutné k provedení úkolu.

  Riard navrhuje, aby každý prostředník akceptoval pouze takové žádosti o přeposlání, které obsahují osvědčení vydané tímto prostředníkem. Tato osvědčení sestávají ze zaslepených elektronických podpisů, které nedovolují prostředníkům napřímo určit jejich držitele. Identita odesílatele tak zůstane před prostředníky utajena. Každý uzel si může stanovit svá pravidla vydávání osvědčení, Riard však navrhuje několik způsobů jejich distribuce:

  • ● Předplatné: chce-li Alice poslat platbu přes Bobův uzel, může nejdřív od Boba zakoupit osvědčení (přes LN).

  • ● Předchozí úspěšná platba: Bobův uzel může Alici poslat osvědčení (jedno nebo více) za úspěšně provedenou platbu. Díky těmto osvědčením může Alice opět v budoucnu poslat platby přes Bobův uzel.

  • ● Důkazy vlastnictví UTXO: někteří prostředníci mohou experimentovat s vydáváním osvědčení každému, kdo předloží důkaz o vlastnictví bitcoinového UTXO. Lze například udělit více osvědčení za starší nebo hodnotnější UTXO. Jelikož si každý prostředník sám zvolí pravidla udělování osvědčení, mohou být použita i jakákoliv jiná kritéria.

  Clara Shikhelman, která je spoluautorkou podobného návrhu částečně založeného na lokální reputaci popsaného ve zpravodaji č. 226 (angl.), se dotázala, zda by tato osvědčení byla přenositelná mezi uživateli a zda by to mohlo vést k vytvoření trhu s osvědčeními. Též se ptala, jak by Riardův návrh fungoval se zaslepenými trasami, kde odesílatel nezná kompletní trasu k příjemci.

  Riard odpověděl, že by bylo složité redistribuovat osvědčení a vytvořit pro ně trh, neboť by každý přenos vyžadoval důvěru. Napříkad chtěla-li by Alice prodat Carol osvědčení vydané Bobovým uzlem, neexistuje žádný způsob, kterým by Alice mohla dokázat Carol, že se nebude po prodeji snažit osvědčení sama používat.

  Co se týče zaslepených tras, jeví se, že by příjemce mohl poskytnout veškerá potřebná osvědčení v zašifrované podobě.

  V příslušném pull requestu obdržel tento návrh další zpětnou vazbu.

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 0.15.5-beta.rc2 je kandidátem na údržbové vydání LND. Podle plánovaných poznámek vydání obsahuje pouze opravy drobných chyb.

• ● Core Lightning 22.11rc3 je kandidátem na vydání příští hlavní verze CLN. Tímto vydáním přejde CLN na nový model číslování verzí, avšak nadále bude používat sémantické verzování.

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) a Lightning BOLTs.

• ● Core Lightning #5727 začíná v JSON prosazovat textové identifikátory namísto zastaralých číselných. Do dokumentace byly přidány informace o výhodách textových identifikátorů a o jejich správném vytváření a interpretování.

• ● Eclair #2499 umožňuje v žádostech o platbu v rámci BOLT12 nabídek nastavit zaslepenou trasu („blinded route”). Ta spočívá v přidání dodatečných uzlů za adresátův uzel, které však nebudou použity. Jejich účelem je ztížení odesílateli určit, jak daleko je adresát od posledního nezaslepeného uzlu v trase.

• ● LND #7122 přidává do lncli podporu pro zpracování binárních PSBT souborů. BIP174 určuje, že PSBT, neboli částečně podepsané transakce, mohou být zakódovány buď jako binární soubor nebo pomocí Base64 jako text. LND již dříve umožňovalo import PSBT zakódovaných pomocí Base64 ze souboru nebo přímo z textu.

• ● LDK #1852 akceptuje navýšení jednotkového poplatku („feerate”) navržené jedním z účastníků kanálu, i když není tento poplatek dostatečně vysoký, aby v dané chvíli bezpečně udržel kanál otevřený. I když nový jednotkový poplatek není zcela bezpečný, jeho vyšší hodnota v porovnání s předchozí hodnotou znamená, že je bezpečnější oproti stávající situaci. Je tedy lepší jej akceptovat, než pokoušet se zavřít kanál s jeho stávajícím (nižším) jednotkovým poplatkem. Budoucí změny LDK mohou zavírat i kanály, které mají poplatky příliš nízké. Navíc díky práci na návrzích jako je přeposílání balíčků (viz též překlad zpravodaje č. 201 a č. 204) mohou být anchor výstupy a podobné techniky dostatečně flexibilní, aby zcela odstranily obavy o výši poplatků.

• ● Libsecp256k1 #993 přidává do výchozího nastavení sestavení moduly pro práci s extrakeys (funkce pro práci s x-only veřejnými klíči), ECDH a Schnorrovými podpisy. Modul pro rekonstrukci veřejného klíče z elektronického podpisu není nadále součástí výchozího nastavení, „neboť nedoporučujeme, aby nově vznikající protokoly obsahovaly ECDSA obnovu kvůli náchylnosti API ke zneužití. Ponouká totiž volajícího, aby přeskočil kontrolu veřejného klíče a automaticky jej pokládal za platný.”