Zpravodaj tento týden shrnuje aktualizaci návrhu nových zpráv oznamování LN kanálů a popisuje BIP pro posílání tichých plateb s PSBT. Též nechybí naše pravidelné rubriky s oblíbenými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními nových vydání a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Aktualizace návrhu oznamování kanálů verze 1.75: Elle Mouton zaslala do fóra Delving Bitcoin příspěvek s popisem několika změn navrhovaných pro nový protokol oznamování kanálů, který přinese podporu jednoduchých taprootových kanálů. Nejvýraznější plánovanou změnou je umožnit zprávě také oznámit současný druh P2WSH kanálů. To později uzlům umožní „začít vypínat starý protokol […], až bude většina sítě upgradována.”

  Dalším, též nedávno diskutovaným (viz zpravodaj č. 325), volitelným doplňkem do oznámení je SPV doklad, který umožní klientovi, jež má blockchain s největší provedenou prací, ověřit, že zakládající transakce kanálu byla začleněna do některého bloku. V současnosti musí lehké klienty pro provedení stejné úrovně ověření oznámení kanálu stáhnout kompletní blok.

  Příspěvek Mouton též krátce diskutuje umožnění oznamování existujících jednoduchých taprootových kanálů. Kvůli v současnosti chybějící podpoře oznámení jiných než P2WSH kanálů jsou všechny stávající taprootové kanály neoznámené. V budoucnosti by mohla být k návrhu přidána možnost oznámit svému spojení, že chce uzel převést neoznámený kanál na veřejný.

• ● Návrh BIPu na posílání tichých plateb s PSBT: Andrew Toth zaslal do emailové skupiny Bitcoin-Dev příspěvek s návrhem BIPu, který by peněženkám a podpisovým zařízením umožnil pomocí PSBT koordinovat tvorbu tiché platby. Jedná se o pokračování předchozí diskuze o dřívější iteraci tohoto návrhu, viz zpravodaje č. 304 a č. 308. Jak bylo v těchto zpravodajích zmíněno, zvláštním požadavkem tichých plateb oproti většině ostatních transakcí koordinovaných pomocí PSBT je, že jakákoliv změna vstupů transakce, která ještě není kompletně podepsaná, vyžaduje přepočet výstupů.

  Návrh pokrývá pouze očekávanou nejběžnější situaci, ve které má podepisující přístup k soukromým klíčům všech vstupů transakce. Případy s více podepisujícími, říká Toth, „budou specifikovány v následujícím BIPu.”

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

• ● Duplikované bloky v souborech blk*.dat? Pieter Wuille vysvětluje, že kromě aktuálně nejlepšího řetězce obsahují soubory také staré nepoužité bloky nebo duplikovaná data.

• ● Jak se rozhodlo o struktuře pay-to-anchor? Antoine Poinsot popisuje strukturu pay-to-anchor (P2A) výstupů, které byly představené v rámci změn pravidel v Bitcoin Core 28.0. Jako dvoubajtový witnessový program byla zvolena čitelná (v bech32m kódování) adresa bc1pfeessrawgf.

• ● Jaké výhody mají falešné pakety v BIP324? Pieter Wuille nastiňuje návrhová rozhodnutí kolem začlenění falešných paketů do specifikace BIP324. Tyto volitelné falešné pakety mohou být použité k zastření provozu a tím k zabránění rozpoznávání během výměny klíčů, vyjednávání verzí a provozu aplikace.

• ● Proč je limit opkódů 201? Vojtěch Strnad ukazuje na změny kódu, které Satoshi provedl během roku 2010 se záměrem představit limit opkódů 200. Kvůli chybě implementace ale ve skutečnosti nastavil limit na 201.

• ● Přepošle můj uzel transakci mající poplatek pod můj minimální přenosový poplatek? Murch poznamenává, že uzel přepošle pouze takové transakce, které přijme do svého vlastního mempoolu. I když může uživatel snížit hodnotu minTxRelayFee svého uzlu, aby umožnil přijetí do místního mempoolu, začlenění takové transakce do bloku by i nadále vyžadovalo, aby měl některý těžař podobné nastavení a aby klesl průměrný poplatek na tuto hodnotu.

• ● Proč peněženka Bitcoin Core nepodporuje BIP69? Murch souhlasí, že univerzální implementace řazení výstupů a vstupů transakce dle specifikace BIP69 by napomohla zabránit identifikaci otisků peněženek, avšak poznamenává, že vzhledem k nepravděpodobnému všeobecnému nasazení je implementace BIP69 sama o sobě zranitelností napomáhající identifikaci.

• ● Jak můžu s Bitcoin Core 28.0 aktivovat testnet4? Pieter Wuille zmiňuje dvě konfigurační volby, které aktivují testnet4 dle BIP94: chain=testnet4 a testnet4=1.

• ● Jaká jsou rizika zveřejnění transakce odhalující scriptPubKey s klíčem s nízkou entropií? Uživatel Quuxplusone odkazuje na nedávnou transakci spojenou se sérií bitcoinových „hádanek” z roku 2015 s obrušováním klíčů, o které se soudí, že byla nahrazena botem hledajícím v mempoolu klíče s nízkou entropií.

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 24.08.2 je údržbovým vydáním této oblíbené implementace LN, které přináší „pár oprav pádů a obsahuje vylepšení pro zapamatování a aktualizaci nápovědy kanálů během plateb.”

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, Bitcoin Inquisition a repozitáři BINANA.

• ● Eclair #2925 přináší podporu pro používání RBF se splicingovými transakcemi pomocí příkazu rbfsplice. Ten mezi spojeními spustí výměnu zpráv tx_init_rbf a tx_ack_rbf, kterými si dohodnou nahrazení transakce. Tato možnost není aktivní pro 0-conf kanály, aby se předešlo případným krádežím prostředků. Série nepotvrzených splicingových transakcí jsou v 0-conf kanálech povolené. RBF je dále blokované pro transakce nákupu likvidity pomocí protokolu inzerátů likvidity, aby se předešlo okrajovým případům, při kterých by mohl prodávající přidat likviditu do kanálu, aniž by obdržel platbu.

• ● LND #9172 přidává do příkazů lncli create a lncli createwatchonly nový příznak mac_root_key, který umožní generovat deterministické macaroony (autentizační tokeny). Externí klíče LND uzlu tak mohou být nastavené ještě před jeho samotnou inicializací. To je obzvláště užitečné v kombinaci s používáním reverzního vzdáleného podepisování navrženého v LND #8754 (viz zpravodaj č. 172, angl.).

• ● Rust Bitcoin #2960 činí z AEAD ChaCha20-Poly1305 samostatný balíček, který tak může být použit i jinými způsoby, než je přenosový protokol v2 dle specifikace v BIP324, např. payjoin v2. Kód byl optimalizován pro SIMD instrukce, čímž se zvýší výkonnost (viz zpravodaj č. 264).