Zpravodaj tento týden shrnuje návrh na rozšíření protokolu Stratum v2 pro odměňování těžařů na základě transakčních poplatků obsažených v použitých šablonách bloků, oznamuje fond na výzkum navrhovaného opkódu OP_CAT a popisuje diskuzi o zabraňování zranitelnostem Merkleova stromu s případným soft forkem. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Rozšíření pro Stratum v2 pro sdílení výdělků: Filippo Merli zaslal do fóra Delving Bitcoin příspěvek o rozšíření protokolu Stratum v2, které umožní sledovat množství poplatků začleněných v share v případech, kdy share obsahují transakce vybrané jednotlivými těžaři. Může to být použito k úpravě výplaty těžařům, kdy by těžaři vybírající transakce s vyššími poplatky mohli být placeni více.

    Merli odkazuje na článek, jehož je spoluautorem, který zkoumá obtíže vyplácení různých odměn různým těžařům podle vybraných transakcí. Článek navrhuje schéma, které je kompatibilní se schématem PPLNS (pay per last N shares, platba podle posledních N share). Jeho příspěvek dále odkazuje na dvě vyvíjené implementace.

  • ● Fond na výzkum OP_CAT: Victor Kolobov zaslal do emailové skupiny Bitcoin-Dev příspěvek s oznámením fondu ve výši 1 miliónu dolarů určeného pro výzkum navrhovaného soft forku na přidání opkódu OP_CAT. „Mezi možná témata patří: dopady aktivace OP_CAT na bezpečnost bitcoinu, logika výpočetních i platebních skriptů založených na OP_CAT, aplikace a protokoly používající OP_CAT v bitcoinu a všeobecný výzkum související s OP_CAT a jeho dopady.” Přihlášky musí být obdrženy do 1. ledna 2025.

  • ● Zabraňování zranitelnostem Merkleova stromu: Eric Voskuil poslal do vlákna o návrhu na pročištění konsenzu (viz zpravodaj č. 296) ve fóru Delving Bitcoin žádost o úpravu návrhu v reakci na nedávnou diskuzi v emailové skupině Bitcoin-Dev. Konkrétně nevidí „důvod k existenci navrhovaného zákazu 64bajtových transakcí,” neboť dle něj zákaz 64bajtových transakcí nepřináší v porovnání s jinými kontrolami (které nevyžadují změnu konsenzu a které jsou prováděny již nyní) plným uzlům v ochraně před zranitelnostmi Merkleova stromu jako CVE-2012-2459 žádná zlepšení výkonnosti. Hlavní obhájce pročištění konsenzu Antoine Poinsot zjevně s tímto aspektem souhlasí: „Výhoda, kterou jsem původně zmínil, tedy že zakázání 64bajtových transakcí by mohlo pomoci zaznamenat chyby bloků v dřívější fázi, není správná.”

    Avšak Poinsot i jiní dříve také navrhli zákaz 64bajtových transakcí k ochraně softwaru ověřujícího Merkleovy důkazy proti CVE-2017-12842. Tato zranitelnost postihuje lehké peněženky, které používají zjednodušené ověřování plateb (simplified payment verification, SPV), jak bylo popsané v původním článku o bitcoinu. Může také postihovat sidechainy, které provádí SPV, a některé navrhované druhy kovenantů, které pro aktivaci vyžadují soft fork.

    Od zveřejnění CVE-2017-12842 je známo, že SPV může být bezpečné, pokud validace navíc ověřuje hloubku coinbasové transakce v bloku. Voskuil odhaduje, že by to v průměru vyžadovalo dodatečných 576 bajtů u běžných moderních bloků, což je jen malý nárůst množství přenášených dat. Poinsot argumenty shrnul a Anthony Towns přidal informace k části o složitosti provádění dodatečného ověření hloubky.

    Voskuil dále odkázal na dřívější návrh Sergia Demiana Lernera, dle kterého by po soft forku měnícím konsenzus hlavičky bloků zavazovaly hloubce svého Merkleova stromu. To by též chránilo před CVE-2017-12842, nevyžadovalo by zákaz 64bajtových transakcí a umožnilo maximální efektivitu SPV dokladů.

    Diskuze v době psaní nadále probíhala.

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 je vydáním nové hlavní verze této oblíbené implementace LN uzlu přinášející novinky a opravy chyb.

  • ● LDK 0.0.124 je novým vydáním této knihovny pro budování lightningových aplikací.

  • ● LND v0.18.3-beta.rc2 je kandidátem na vydání opravné verze této populární implementace LN uzlu.

  • ● BDK 1.0.0-beta.2 je kandidátem na vydání této knihovny pro budování peněženek a jiných bitcoinových aplikací. Původní rustový balíček bdk byl přejmenován na bdk_wallet a moduly nižší úrovně byly extrahovány do samostatných balíčků: bdk_chain, bdk_electrum, bdk_esplora a bdk_bitcoind_rpc. Balíček bdk_wallet „je první verzí nabízející stabilní 1.0.0 API.”

  • ● Bitcoin Core 28.0rc1 je kandidátem na vydání příští hlavní verze této převládající implementace plného uzlu. Průvodce testování je k dispozici.

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.

Poznámka: commity do Bitcoin Core zmíněné níže se vztahují na jeho master vývojovou větev. Tyto změny pravděpodobně nebudou vydány do doby kolem šesti měsíců od vydání připravované verze 28.

  • ● Bitcoin Core #30454 a #30664 přidávají sestavovací systém založený na CMake (viz zpravodaj č. 316) a odstraňují předchozí systém založený na autotools. Viz též následná PR #30779, #30785, #30763, #30777, #30752, #30753, #30754, #30749, #30653, #30739, #30740, #30744, #30734, #30738, #30731, #30508, #30729 a #30712.

  • ● Bitcoin Core #22838 implementuje deskriptory s více derivačními cestami (BIP389), které umožňují jednomu deskriptoru specifikovat dvě souvislé derivační cesty: první pro příjem plateb a druhou pro interní použití (např. pro zbytek). Viz též zpravodaje č. 211 (angl.) a č. 258.

  • ● Eclair #2865 přidává možnost probudit odpojený mobilní uzel mobilní notifikací a připojit se na jeho poslední známou IP adresu. To je užitečné obzvláště u asynchronních plateb, kde místní uzel drží platbu nebo onion zprávu, které doručí po opětovném připojení vzdáleného uzlu. Viz též zpravodaj č. 232.

  • ● LND #9009 přináší mechanismus omezování spojení za posílání nevalidních oznámení o kanálech, např. takových, jejichž financující transakce neexistuje, je již utracená nebo má nevalidní výstupy. S omezenými spojeními bude nakládat v závislosti na jejich vztahu:

    • spojení bez sdíleného kanálu budou odpojena

    • od spojení se sdíleným kanálem bude na 48 hodin ignorovat oznámení

  • ● LDK #3268 přidává ConfirmationTarget::MaximumFeeEstimate nabízející během kontroly poplatků protistrany konzervativnější odhad poplatků u výpočtů s neekonomickými výstupy (dust). Tím zabrání zbytečným vynuceným zavřením kanálu v době s vysokými poplatky. PR dále rozděluje ConfirmationTarget::OnChainSweep na UrgentOnChainSweep a NonUrgentOnChainSweep za účelem rozlišení mezi časově citlivými (např. expirující HTLC) a neurgentními vynucenými zavřeními.

  • ● HWI #742 přidává podporu pro hardwarové podpisové zařízení Trezor Safe 5.

  • ● BIPs #1657 přidává do PSBT výstupů nové standardní pole pro DNSSEC doklady použitelné s BIP353. Externí zařízení jako podpisový hardware mohou z PSBT výstupů obdržet důkazy formátované dle RFC 9102, které zajistí, že akceptované budou pouze validní důkazy s vynucenými časovými limity. Viz též zpravodaj č. 307.