Zpravodaj tento týden popisuje hašovací funkci s odolností vůči kolizím používající bitcoinový Script a shrnuje pokračující diskuzi o analýze provozu Lightning Network. Též nechybí naše pravidelné rubriky s 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

  • ● Hašovací funkce s odolností vůči kolizím pro bitcoinový Script: Robin Linus zaslal do fóra Delving Bitcoin příspěvek o Binohashi, nové hašovací funkci pro bitcoin s odolností vůči kolizím. V článku Linus uvádí, že Binohash umožňuje omezenou introspekci transakcí bez nutnosti změn konsenzu. Tím by mohly protokoly jako BitVM disponovat – podobně jako kovenanty – introspekcí řetězce bez potřeby důvěřovat orákulím.

    Navrhovaná hašovací funkce nepřímo odvozuje otisk po dvou krocích:

    • Fixace polí transakce: Pole transakce jsou svázána s několika výpočetními problémy nad podpisy, které musí plátce vyřešit. Každý problém vyžaduje W1 bitů práce, čímž jsou neautorizované změny výpočetně nákladné.

    • Odvození haše: haš se vypočítá využitím FindAndDelete v zastaralém OP_CHECKMULTISIG. Vytvoří se zásobník noncí s n podpisy. Plátce připraví podmnožinu s t podpisy, které jsou ze zásobníku pomocí FindAndDelete vyňaty, a poté spočítá sighash zbývajících podpisů. Proces se opakuje, dokud nenalezne podpis řešící výpočetní problém. Výsledný otisk (Binohash) je složen z t indexů nalezené podmnožiny.

    Výsledný otisk má tři vlastnosti: může být extrahován a ověřen v bitcoinovém skriptu, poskytuje odolnost vůči kolizím kolem 84 bitů a může být podepsán Lamportovým podpisem pro použití v BitVM. Dohromady tyto vlastnosti znamenají, že vývojáři mohou již dnes konstruovat protokoly používající onchain data z transakcí za použití pouze současně dostupných skriptových primitiv.

  • ● Aktualizace nástroje analyzování provozu Gossip Observer: V listopadu Jonathan Harvey-Buschel ohlásil Gossip Observer, nástroj pro sběr dat o provozu lightningového gossip protokolu a výpočet metrik. Snahou je posoudit nahrazení současného systému zaplavování sítě zprávami novým protokolem založeným na synchronizaci množin (set reconciliation).

    Od té doby se do vlákna připojil Rusty Russell a jiní, aby diskutovali o výběru nejlepšího způsobu posílání skečů (sketch; kompaktní datová struktura reprezentující pravděpodobnostní zastoupení prvků v množině a umožňující efektivní porovnávání). Jedním návrhem bylo přeskočit obousměrnou zprávu GETDATA a použít číslo bloku. Tím se odstraní zbytečná výměna požadavku a odpovědi v případech, kdy příjemce již může odvodit kontext relevantního bloku.

    V návaznosti aktualizoval Harvey-Buschel svou verzi Gossip Observeru, kterou provozuje a která sbírá data. Podělil se o analýzu průměrných každodenních zpráv a popsal model detekovaných komunit a zpoždění propagace.

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.

  • ● BDK wallet 3.0.0-rc.1 je kandidátem na vydání nové hlavní verze této knihovny pro budování peněženek. Mezi hlavní změny patří uzamykání UTXO napříč restarty aplikace, strukturované události vyvolané při změnách řetězce a používání NetworkKind napříč API pro rozlišování mezi mainnetem a testovacími sítěmi. Vydání dále přidává podporu pro exportní formát Caravan (viz zpravodaj č. 77, angl.) a migrační nástroj pro SQLite databáze z verzí před 1.0.

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 #26988 nově vrací na CLI příkaz -addrinfo (viz zpravodaj č. 146, angl.) kompletní seznam známých adres. Dříve vracel jen podmnožinu na základě kvality a aktuálnosti. Interně se namísto RPC příkazu getnodeaddresses (viz zpravodaj č. 14, angl.) používá getaddrmaninfo (viz též zpravodaj č. 275). Počet vrácených záznamů se nyní rovná počtu adres, mezi kterými se hledá odchozí spojení.

  • ● Bitcoin Core #34692 navyšuje na 64bitových systémech s více než 4 GiB paměti výchozí hodnotu dbcache z 450 MiB na 1 GiB. V ostatních situacích zůstává na 450 MiB. Změna se týká pouze bitcoind, knihovna jádra ponechává výchozí nastavení na 450 MiB.

  • ● LDK #4304 rozšiřuje přeposílání HTLC o podporu několika příchozích a odchozích HTLC v rámci jednoho přeposlání. Staví tím základy pro trampolínové trasování. Na rozdíl od běžného přeposílání může trampolínový uzel představovat MPP bod (pro platby s více cestami) pro oba směry: shromažďuje příchozí části, hledá trasy pro následující skoky a rozděluje částku mezi více odchozích HTLC. Nová varianta HTLCSource::TrampolineForward sleduje všechna HTLC pro trampolínová přeposlání. Nárokování i chyby jsou řádně řešené a monitor kanálů správně při restartování rekonstruuje stav.

  • ● LDK #4416 umožňuje akceptorovi finančně přispět, pokud se obě strany pokoušejí iniciovat splice ve stejný okamžik. Tím v podstatě přidává podporu pro oboustranné financování během splicingu. Pokud obě strany zahájí splice, protokol chvíle ticha (quiescence) vybere jednu z nich jako iniciátora. Dříve mohl přidat prostředky pouze iniciátor a akceptor musel čekat na další splice, aby mohl také přispět. Jelikož byl akceptor připraven jednat jako iniciátor, jsou poplatky upraveny z iniciátorovy sazby (která pokrývá běžná pole v transakci) na akceptorovu sazbu. API splice_channel též nově obdrží parametr max_feerate.

  • ● LND #10089 přidává podporu pro přeposílání onion zpráv, jejíž základy byly představeny ve zpravodaji č. 377 (angl.). Přináší zprávu OnionMessagePayload a každému peer spojení přiřazuje aktora, který zabezpečuje dešifrování a přeposílání. Funkcionalitu lze deaktivovat příznakem --protocol.no-onion-messages. Jedná se o součást práce na podpoře BOLT12 nabídek.

  • ● Libsecp256k1 #1777 přidává nové API secp256k1_context_set_sha256_compression(), které aplikacím umožní za běhu dodat vlastní kompresní funkci pro SHA256. Díky tomu je možné v prostředích, jako je Bitcoin Core, směrovat hašování na hardware bez nutnosti překompilovat knihovnu.

  • ● BIPs #2047 zveřejňuje BIP392, který definuje formát deskriptorů pro peněženky podporující tiché platby. Nový deskriptor sp() předepisuje peněženkám, jak skenovat a utrácet výstupy tichých plateb. Ty specifikuje BIP352 jako P2TR výstupy. Verze s jedním argumentem přebírá jediný bech32m klíč: spscan obsahující soukromý klíč pro skenování a veřejný klíč pro utrácení (nelze s ním utrácet) či spspend kódující soukromé klíče pro skenování i utrácení. Formát se dvěma argumenty sp(KEY,KEY) obsahuje jako první výraz soukromý klíč pro skenování a další oddělený klíč pro utrácení: buď veřejný klíč, nebo soukromý s podporou MuSig2 agregace dle BIP390. Viz zpravodaj č. 387, který popisoval úvodní diskuzi v emailové skupině.

  • ● BOLTs #1316 objasňuje, že pokud je v BOLT12 nabídce přítomna volba offer_amount, musí být vyšší než nula. Na nabídku se nesmí odpovědět, pokud je částka nula. Byla též přidána testovací data pro nevalidní nabídky s nulovou částkou.

  • ● BOLTs #1312 přidává testovací data BOLT12 nabídek s nevalidním bech32 zarovnáním. Tím zdůrazňuje, že takové nabídky musí být dle BIP173 odmítnuté. Problém byl objeven během fuzz testování napříč lightningovými implementacemi, které odhalilo, že CLN a LDK nabídky s nevalidním zarovnáním akceptovaly, zatímco Eclair a Lightning-KMP je správně odmítaly. Zpravodaj č. 390 popisuje opravu v LDK.

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 17. 3. v 16:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.