Zpravodaj tento týden ohlašuje návrh BIPu pro odkazování na neutratitelné klíče v deskriptorech, zkoumá, jak implementace používají PSBTv2, a přináší důkladnou korekci našeho popisu nového offchain DLC protokolu z minulého týdne. Též nechybí naše pravidelné rubriky s popisem změn ve službách a klientském software, oznámeními nových vydání a souhrnem nedávných změn v populárním bitcoinovém páteřním software.

Novinky

  • ● Integrační test PSBTv2: Sjors Provoost zaslal do emailové skupiny Bitcoin-Dev příspěvek s dotazem na software, který již implementoval podporu PSBT verze 2 (viz zpravodaj č. 141, angl.) a pomohl by otestovat PR přidávající stejnou podporu do Bitcoin Core. Aktuální seznam software s podporou lze nalézt na Bitcoin Stack Exchange. Dvě odpovědi nás zaujaly:

    • ● Merklizované PSBTv2: Salvatore Ingala vysvětluje, že Ledger Bitcoin App převádí pole PSBTv2 na Merkleův strom a posílá do hardwarového zařízení Ledger nejprve pouze kořen. Když potřebuje konkrétní pole, jsou do něj odeslána spolu s Merkleovým důkazem. To zařízení umožňuje bezpečnou práci nezávisle s každou dílčí informací bez nutnosti ukládat v jeho omezené paměti celé PSBT. S PSBTv2 je to možné, neboť již obsahuje všechny části nepodepsané transakce v oddělených polích. U původního PSBT formátu (v0) by to vyžadovalo dodatečné zpracování.

    • ● Tiché platby a PSBTv2: BIP352, který tiché platby specifikuje, explicitně závisí na specifikaci BIP370 PSBTv2. Andrew Toth vysvětluje, že tiché platby potřebují PSBTv2 pole PSBT_OUT_SCRIPT, jelikož výstupní skript, který bude v tiché platbě použit, nemůže být znám, dokud všichni podepisující PSBT nezpracují.

  • ● Oprava textu o offchain DLC: v popisu offchain DLC v předchozím zpravodaji jsme pomíchali nové schéma, které navrhl vývojář conduition, s již existujícím schématem offchain DLC. Mezi nimi jsou význačné a zajímavé rozdíly:

    • ● Protokol DLC kanálů zmíněný ve zpravodajích č. 174 (angl.) a č. 260 používá mechanismus podobný LN-Penalty, ve kterém se strany podpisem zavazují k novému stavu a poté anulují starý stav odevzdáním tajného kódu, který by protistraně umožnil starou verzi stavu kompletně utratit v případě zveřejnění onchain. Díky tomu mohou strany DLC interaktivně obnovit. Na příklad mohou Alice a Bob učinit následující:

      1. Okamžitě se shodnout na DLC o ceně BTC/USD po uplynutí jednoho měsíce.

      2. O tři týdny později se shodnout na DLC o ceně BTC/USD po uplynutí dvou měsíců od dnešního dne a zároveň anulovat předchozí DLC.

    • Nový protokol DLC továren v době nabytí splatnosti kontraktu automaticky oběma stranám odebírá možnost zveřejňovat stav onchain. Jako tajný kód umožňující kompletně utratit soukromý stav v případě zveřejnění onchain lze použít jakoukoliv atestaci od orákula. V důsledku se tím automaticky ruší staré stavy, což bez další interakce umožní následná DLC podepsat již během vytváření továrny. Na příklad Alice a Bob mohou:

      1. Okamžitě se shodnout na DLC o ceně BTC/USD po uplynutí jednoho měsíce.

      2. Též okamžitě se shodnout na DLC o ceně BTC/USD po uplynutí dvou měsíců od dnešního dne s použitím transakce s časovým zámkem, která nemůže být zveřejněna před uplynutím jednoho měsíce. Pokračovat mohou s měsícem tři, čtyři atd.

    V protokolu DLC kanálů nemohou Alice s Bobem vytvořit druhý kontrakt, dokud nejsou připraveni anulovat první kontrakt, což si v té době mezi nimi vyžádá interakci. V protokolu DLC továren mohou být všechny kontrakty vytvořené v době vytvoření továrny a další interakce není vyžadována. Každá strana však i nadále může sérii kontraktů přerušit a zveřejnit onchain aktuální, správný stav.

    Pokud spolu mohou účastníci továrny po založení kontraktu interagovat, mohou kontrakt rozšířit, nemohou se však rozhodnout používat jiný kontrakt nebo jiná orákula, dokud všechny dříve podepsané kontrakty nedosáhnou splatnosti (nebo nejsou zveřejněny onchain). Ačkoliv je možné tento nedostatek odstranit, v současnosti se jedná o zvolený kompromis výměnou za nižší interaktivitu v porovnání s DLC kanály, které umožňují kdykoliv libovolně změnit kontrakt oboustrannou anulací.

    Děkujeme conduitionovi za upozornění na naši chybu v minulém zpravodaji a za trpělivé odpovědi na naše dotazy.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

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.

  • ● BTCPay Server 2.0.6 přináší kromě několika nových funkcí a oprav chyb „bezpečnostní opravu pro obchodníky používající systém onchain refundací s automatickým zpracováním 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.

  • ● Bitcoin Core #31397 zlepšuje řešení sirotků sledováním a používáním všech potenciálních spojení, která mohou chybějící rodičovské transakce poskytnout. Dříve proces řešení spoléhal pouze na spojení, které osiřelou transakci poskytlo. Pokud toto spojení neodpovídalo nebo vrátilo zprávu notfound, pokusy o získání rodičovské transakce se již neopakovaly. Nový přístup se pokusí rodičovskou transakci získat od všech vhodných spojení. Přitom je zachována efektivita využívání přenosového pásma, odolnost vůči cenzuře a vyrovnané rozložení zátěže. Nová metoda je obzvláště výhodná pro přeposílání balíčků s jedním rodičem a jedním potomkem (1p1c) a budoucí přeposílání balíčků předků dle BIP331.

  • ● Eclair #2896 aktivuje ukládání částečných MuSig2 podpisů protistrany vedle tradičních 2-ze-2 vícenásobných podpisů. MuSig2 částečné podpisy budou používány budoucí implementací jednoduchých taprootových kanálů. Jejich ukládání umožní uzlu v případě potřeby jednostranně zveřejnit commitment transakce.

  • ● LDK #3408 přidává do ChannelManager pomocné funkce pro vytváření statických faktur a nabídek pro podporu asynchronních plateb v BOLT12 dle specifikace v BOLTs #1149. Na rozdíl od vytváření běžné nabídky, u které musí být příjemce online, aby mohl reagovat na žádosti o fakturu, nová funkcionalita je užitečná pro příjemce, kteří jsou často offline. Toto PR dále přidává chybějící testy placení statických faktur (viz zpravodaj č. 321) a zajišťuje, aby příjemce mohl po opětovném připojení obdržet žádosti o fakturu.

  • ● LND #9405 přináší konfigurovatelnost parametru ProofMatureDelta, který určuje počet konfirmací, které jsou vyžadované pro zpracování oznámení o kanálu. Výchozí hodnota je 6.

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