Zpravodaj tento týden popisuje možná řešení problému identifikace uzlů a odkazuje na diskuzi o používání veřejných dokladů o podvodu pro zlepšení incentiv u just-in-time kanálů. Též nechybí naše pravidelné rubriky s popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Možné ochrany proti identifikaci uzlu: Naiyoma zaslala do fóra Delving Bitcoin příspěvek o možném řešení problému identifikace shodných uzlů napříč sítěmi pomocí časového razítka ve zprávě addr (viz zpravodaj č. 360).

    Od poslední aktualizace získali výzkumníci nové poznatky o problému a identifikovali nové faktory, které je třeba vzít v úvahu. Jeden z klíčových poznatků byl spojen s AddrManem (kódem, který spravuje adresy). AddrMan považuje adresy za nepoužívané, pokud je jejich časové razítko starší než 30 dní, obvykle kvůli offline peer spojení. Kvůli tomu hrají důležitou roli dva faktory: změna starých časových razítek na novější může způsobit opakované šíření starých adres a změna na starší časová razítka může způsobit předčasný konec jejich šíření. To vedlo k vyloučení některých dříve uvažovaných řešení a k poskytnutí nových:

    1. Náhodnost: Náhodné zkreslení časových razítek v rozsahu mezi −5 až +5 dny. Zkreslení se však v průběhu času může zprůměrovat.

    2. Pevně daná časová razítka napříč sítěmi: Během odpovídání na požadavek je skutečné časové razítko zachováno pro tu konkrétní síť, ale pro ostatní sítě jsou časová razítka zvolená náhodně z minulosti. Staré adresy však mohou zůstat v oběhu déle, než je nutné.

    3. Náhodnost – adresy pouze starší: Adresy se stávají pouze staršími, nikdy novějšími, aplikováním náhodného zkreslení v rozsahu 1 až 10 dní. Adresy však mohou dosáhnout 30denního limitu příliš rychle.

    4. Náhodnost – adresy převážně starší: Aplikace náhodného zkreslení v rozsahu −1 až +5 dní. Adresy se tak stávají hlavně staršími, novějšími pouze s malou pravděpodobností. Staré adresy však mohou zůstat v oběhu déle, než je nutné.

    5. Kombinace: Poslední možností je zkombinovat předchozí dva přístupy.

    Naiyoma dále požádala o zpětnou vazbu a odkázala na PR, ve kterém testovala řešení č. 2.

  • ● Just-in-time kanály a veřejné doklady o podvodu: Thomas Voegtlin zaslal do fóra Delving Bitcoin příspěvek o novém návrhu na vylepšení teorie her stojící za just-in-time (JIT) kanály použitím veřejných dokladů o podvodu, které mohou prokázat nevhodné chování LSP.

    Alice vyjedná otevření JIT kanálu s LSP (Bobem). Až bude Alice potřebovat přijmout satoshi od Carol, vytvoří předobraz. Carol pošle Bobovi HTLC. Alice Bobovi odhalí předobraz s očekáváním, že LSP zveřejní otevírací transakci kanálu. Co se stane, pokud Bob nárokuje HTLC, aniž by s Alicí otevřel kanál?

    Voegtlin navrhuje používat řetězec jako veřejný prostor pro rozhodování sporů. Alice by měla předobraz zveřejnit v OP_RETURN, aby mohl kdokoliv jeho odhalení ověřit a datovat. Na své straně by Bob vytvořil závazek pro UTXO platný až na počet bloků n. Pokud toto UTXO utratí v jiné transakci, než ke které se zavázal, nebo otevírací transakci nezveřejní, nebo pokud se pokusí transakci dvojitě utratit, vytvořil by tím doklad o podvodu. Tím by došlo k poškození jeho reputace jako LSP, aniž by museli ostatní klienti důvěřovat Alici.

    Voegtlin nabídl článek obsahující podrobné vysvětlení a vyzval ostatní vývojáře k poskytnutí zpětné vazby.

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 #33796 přidává do C API libbitcoinkernel (viz zpravodaj č. 380, angl.) funkci btck_check_transaction(), která provede bezkontextové kontroly struktury transakce na úrovni konsenzu. Odmítne transakce bez vstupů a výstupů, s neplatnou délkou scriptSig v mincetvorné transakci, s duplikovanými vstupy, bez odkazu na předchozí výstup v jiné než mincetvorné transakci či s hodnotami výstupů mimo platný rozsah. Ke kontrole není třeba mít k dispozici stav řetězce, množinu UTXO ani ověřování skriptu.

  • ● Bitcoin Core #21283 implementuje podporu pro PSBTv2 dle BIP370. Zpětná kompatibilita s PSBTv0 zůstává zachována. PSBTv2 ukládá data potřebná ke konstrukci transakce, jako jsou verze, locktime, vstupy, výstupy a modifikovatelnost transakce, přímo v PSBT polích namísto v kompletní nepodepsané transakci.

  • ● BIPs #2150 přidává BIP451, specifikaci protokolu pro likvidaci UTXO s prachem (Dust UTXO Disposal Protocol). Ten definuje standard pro peněženky, jak bezpečně nakládat s nechtěnými UTXO s prachem: utratit je do jediného OP_RETURN výstupu s nulovou hodnotou a použít celou hodnotou vstupu na transakční poplatky. Protokol obsahuje pravidla konstrukce pro zachování soukromí, jako je likvidace potvrzených UTXO po jednotlivých adresách a podpisy s ALL|ANYONECANPAY, které umožní čekajícím nesouvisejícím transakcím likvidujícím prach dávkování pomocí RBF.

  • ● Eclair #3144 aktualizuje jednoduché taprootové kanály. Nově používají oficiální feature bit a jsou ve výchozím nastavení aktivní (zatím bez odpory jejich oznamování). Byla přidána testovací data pro zajištění souladu s BOLT specifikacemi a implementací v LND (viz zpravodaj č. 401).

  • ● Eclair #2887 přidává podporu oficiálního protokolu splicingu, který je součástí BOLT specifikace (viz zpravodaj č. 398). Kompatibilita s dřívější experimentální implementací zůstává zachována.

  • ● LDK #4592 začíná během kontroly, zda má uzel před otevřením nového kanálu s commitmentem s nulovým poplatkem (0FC) dostatečné rezervy, počítat tyto kanály jako anchor kanály. Dříve byly počítány pouze takové kanály, které používaly starší anchors_zero_fee_htlc_tx, což uzlům umožňovalo otevřít více 0FC kanálů, než pro kolik mohla peněženka bezpečně navýšit poplatky během současných vynucených zavření.

  • ● LND #9153 přidává do zprávy Route pole source_pub_key. Tím umožní konstruovat a deserializovat cesty z perspektivy jiného než místního uzlu. Pokud toto pole není nastaveno, LND bude i nadále používat místní uzel.

  • ● Rust Bitcoin #5835 přidává konstruktor pro V1MessageHeader, který počítá čtyřbajtový kontrolní součet dat používaný v hlavičkách P2P zpráv. Tím je konstrukce síťových zpráv jednodušší, neboť volající mohou dopředu sestavit hlavičku serializovaných přenášených dat.

  • ● BOLTs #995 přidává rozšiřující BOLT pro jednoduché taprootové kanály s feature bity 80/81. Specifikace definuje minimální druh kanálu založený na taprootu, který v otevírací transakci používá P2TR výstup s MuSig2 agregací klíčů, v commitmentu a HTLC používá taprootové skripty a definuje nová TLV pole pro výměnu částečných podpisů a noncí pro MuSig2 během otevírání kanálu, aktualizací commitmentu, kooperativních uzavření kanálu a opakovaných připojení. Nonce v revoke_and_ack a channel_reestablish jsou sdružené dle txid, aby bylo možné mít několik aktivních commitment transakcí (např. během splicingu). Záměrně nebyly přidány změny gossip protokolu; oznamování taprootových kanálů tak čeká na vyřešení v budoucnosti.

  • ● BOLTs #1228 specifikuje kanály s commitmenty s nulovými poplatky (0FC) a přiřazuje jim feature bity 40/41. Tento druh kanálů má feerate_per_kw nastaven na nulu, commitment a HTLC transakce používají přeposílání transakcí v3 (TRUC) a těžební poplatky jsou poskytovány potomky pomocí CPFP. Commitment transakce obsahují sdílený pay-to-anchor (P2A) výstup financovaný z ořezaných výstupů (max. 240 sat), což ve většině případů umožňuje rodičovské transakci neplatit napřímo žádný poplatek. Specifikace dále omezuje počet HTLC na 114 kvůli omezení velikosti TRUC transakcí (10 kvB).

  • ● BOLTs #1327 aktualizuje pravidla navyšování poplatků pomocí RBF, aby byla v souladu s pravidly nahrazování dle BIP125 během období s nízkými poplatky. Namísto pouhého aplikování stávajícího činitele 25/24 specifikace nově vyžaduje, aby byl jednotkový poplatek nahrazující transakce navýšen o vyšší z těchto dvou hodnot: zmíněného činitele nebo dodatečných 25 sat/kw. Tím dosáhne chování LDK popsaného ve zpravodaji č. 400.