Zpravodaj tento týden shrnuje diskuzi o možných dopadech informací o původci chyb na soukromí v LN. Též nechybí naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními nových vydání a popisem nedávných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Snižují informace o původci chyb soukromí v LN? Carla Kirk-Cohen zaslala do fóra Delving Bitcoin příspěvek s analýzou možných dopadů na soukromí odesílatelů a příjemců v LN, pokud by síť začala používat informace o původci chyb (attributable failures), obzvláště informování odesílatele o počtu pokusů o přeposlání v každém skoku. Na základě několika citovaných článků popisuje dva druhy deanonymizačních útoků:

    • Útočník provozující jeden či více přeposílajících uzlů může měřením času určit počet skoků použitých platbou (HTLC), což může v kombinaci se znalostí topografie veřejné sítě zúžit seznam možných příjemců.

    • Útočník používající směrovač IP síťového provozu (autonomní systém) může pasivně monitorovat provoz a zkombinovat ho se znalostí latence IP sítě mezi uzly (např. měřením času ping) a topografie veřejné sítě LN.

    Dále popisuje možná řešení, včetně:

    • vyzývání příjemců, aby zpozdili přijetí HTLC o drobný náhodný čas, čímž by zabránili útokům měřením času k odhalení identity uzlu příjemce.

    • vyzývání odesílatelů, aby zpozdili opakované odesílání chybných plateb (nebo MPP částí) o drobný náhodný čas a používali alternativní cesty, čímž by zabránili útokům měřením času a vyvoláním selhání k odhalení identity uzlu odesílatele.

    • častějšího dělení platby pomocí MPP, což by ztížilo odhad celkové částky.

    • možnosti odesílatelů zpomalit přeposílání svých plateb, jak bylo již dříve navrženo (viz zpravodaj č. 208, angl.). To by mohlo být zkombinováno s dávkováním HTLC, které LND již podporuje (avšak přidání náhodného zpoždění by soukromí dále navýšilo).

    • snížení přesnosti časových razítek v informacích o původci chyby. Tím by nebyly přeposílající uzly přidávající drobná náhodná zpoždění penalizovány.

    Účastníci diskuze podrobněji hodnotili riziko a navrhovaná řešení a hovořili o další možných útocích a opatřeních.

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.

  • ● Core Lightning 25.05rc1 je kandidátem na vydání další hlavní verze této oblíbené implementace LN uzlu.

  • ● LDK 0.1.3 a 0.1.4 jsou vydáními této populární knihovny pro budování aplikací s LN. Verze 0.1.3, otagována jako vydání na GitHubu tento týden ale datovaná minulý měsíc, obsahuje opravu útoku odepřením služby. Verze 0.1.4, nejnovější vydání, „opravuje zranitelnost umožňující v extrémně vzácných případech krádež prostředků.” Obě vydání obsahují i další opravy.

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 #31622 přidává do PSBT pole druhu haše podpisu (sighash), je-li odlišné od SIGHASH_DEFAULT či SIGHASH_ALL. Podpora pro MuSig2 vyžaduje, aby všichni podepsali stejným druhem haše, proto musí v PSBT toto pole být přítomné. Dále bude RPC descriptorprocesspsbt používat funkci SignPSBTInput, která zajistí, aby druh haše v PSBT odpovídal volbě poskytnuté v CLI.

  • ● Eclair #3065 přidává podporu informací o původci selhání (attributable failures, viz zpravodaj č. 224, angl.) dle specifikace v BOLTs #1044. Ve výchozím nastavení je neaktivní, protože specifikace není ještě finalizována, může být aktivována nastavením volby eclair.​features.​option_attributable_failure na optional. Úspěšně otestována byla kompatibilita s LDK; zpravodaj č. 349 poskytuje o implementaci v LDK a fungování protokolu více informací.

  • ● LDK #3796 zpřísňuje kontrolu zůstatku kanálu, aby měla zakládající strana dostatečné prostředky na pokrytí poplatku commitment transakce, dvou 330satových anchor výstupů a rezervy kanálu. Dříve bylo možné pro zaplacení dvou anchorů sáhnout do rezerv kanálu.

  • ● BIPs #1760 začleňuje BIP53, který specifikuje soft fork konsenzu zakazující 64bajtové transakce (bez dat witnessu). Toto pravidlo zabrání jednomu druhu zranitelnosti Merkleova stromu, které lze zneužít proti SPV klientům. PR navrhuje podobnou opravu jako soft fork pročištění konsenzu.

  • ● BIPs #1850 odstraňuje nedávnou změnu BIP48, která rezervovala hodnotu typu skriptu 3 pro taprootové (P2TR) derivace (viz zpravodaj č. 353). Důvodem je, že tapscript nepodporuje OP_CHECKMULTISIG, a proto výstupní skript v BIP67 (na kterém BIP48 závisí) nemůže být v P2TR vyjádřen. PR dále mění stav BIP48 na Final, čímž indikuje, že jeho účelem bylo definovat používání derivačních cest (m/48') v hierarchických deterministických peněženkách v době představení BIPu a ne předepisovat nové chování.

  • ● BIPs #1793 začleňuje BIP443 navrhující opkód OP_CHECKCONTRACTVERIFY (OP_CCV). Ten umožňuje ověřit, zda nějaký veřejný klíč (vstupů či výstupů) zavazuje nějakým libovolným datům. Viz též zpravodaj č. 348, který o tomto navrhovaném kovenantu poskytuje další informace.