From 9c12f6ec882a48a5120ce70dadc37b21cc4c4134 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Tue, 2 Dec 2025 09:19:48 -0600 Subject: [PATCH 1/9] Newsletters: add 385, the 2025 year-in-review special --- .../en/newsletters/2025-12-19-newsletter.md | 279 ++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 _posts/en/newsletters/2025-12-19-newsletter.md diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md new file mode 100644 index 000000000..3fdbc158a --- /dev/null +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -0,0 +1,279 @@ +--- +title: 'Bitcoin Optech Newsletter #385: 2025 Year-in-Review Special' +permalink: /en/newsletters/2025/12/19/ +name: 2025-12-19-newsletter +slug: 2025-12-19-newsletter +type: newsletter +layout: newsletter +lang: en + +excerpt: > + The eighth annual Bitcoin Optech Year-in-Review special summarizes + notable developments in Bitcoin during all of 2025. + +--- +{{page.excerpt}} It's the sequel to our summaries from [2018][yirs +2018], [2019][yirs 2019], [2020][yirs 2020], [2021][yirs 2021], +[2022][yirs 2022], [2023][yirs 2023], and [2024][yirs 2024]. + +## Contents + +* January + * [Updated ChillDKG draft](#chilldkg) + * [Offchain DLCs](#offchaindlcs) + * [Stats on compact block reconstruction](#compactblockstats) +* February + * [Erlay update](#erlay) + * [LN ephemeral anchor scripts](#lneas) + * [Probabilistic payments](#probpayments) +* March + * [Bitcoin Forking Guide](#forkingguide) + * [Private block template marketplace to prevent centralizing MEV](#templatemarketplace) + * [LN upfront and hold fees using burnable outputs](#lnupfrontfees) +* April + * [SwiftSync speedup for initial block download](#swiftsync) + * [DahLIAS interactive aggregate signatures](#dahlias) +* May + * [Cluster mempool](#clustermempool) + * [Increasing or removing Bitcoin Core’s OP_RETURN size limit](#opreturn) +* June + * [Calculating the selfish mining danger threshold](#selfishmining) + * [Fingerprinting nodes using addr messages](#fingerprinting) + * [Garbled locks](#garbledlocks) +* July + * [Chain code delegation](#ccdelegation) +* August + * [Utreexo draft BIPs](#utreexo) + * [Lowering the minimum relay feerate](#minfeerate) + * [Peer block template sharing](#templatesharing) + * [Differential fuzzing of Bitcoin and LN implementations](#fuzzing) +* September + * [Details about the design of Simplicity](#simplicity) + * [Partitioning and eclipse attacks using BGP interception](#eclipseattacks) +* October + * [Theoretical limitations on embedding data in the UTXO set](#arbdata) + * [Channel jamming mitigation simulation results and updates](#channeljamming) +* November + * [Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1](#secpperformance) + * [Multiple discussions about restricting data](#restrictingdata) + * [Modeling stale rates by propagation delay and mining centralization](#stalerates) + * [BIP3 and the BIP process](#bip3) +* December +* Featured summaries + * [Vulnerabilities](#vulns) + * [Quantum](#quantum) + * [Soft fork proposals](#softforks) + * [Major releases of popular infrastructure projects](#releases) + * [Bitcoin Optech](#optech) + +--- + +## January + +{:#chilldkg} +- **Updated ChillDKG draft:** ... + +{:#offchaindlcs} +- **Offchain DLCs:** ... + +{:#compactblockstats} +- **Stats on compact block reconstruction:** ... + +## February + +{:#erlay} +- **Erlay update:** ... + +{:#lneas} +- **LN ephemeral anchor scripts:** ... + +{:#probpayments} +- **Probabilistic payments:** ... + +
+ +## Summary 2025: Vulnerabilities + +... + +
+ +## March + +{:#forkingguide} +- **Bitcoin Forking Guide:** ... + +{:#templatemarketplace} +- **Private block template marketplace to prevent centralizing MEV:** ... + +{:#lnupfrontfees} +- **LN upfront and hold fees using burnable outputs:** ... + +## April + +{:#swiftsync} +- **SwiftSync speedup for initial block download:** ... + +{:#dahlias} +- **DahLIAS interactive aggregate signatures:** ... + +
+ +## Summary 2025: Quantum + +... + +
+ +## May + +{:#clustermempool} +- **Cluster mempool:** ... + +{:#opreturn} +- **Increasing or removing Bitcoin Core’s OP_RETURN size limit:** ... + +## June + +{:#selfishmining} +- **Calculating the selfish mining danger threshold:** ... + +{:#fingerprinting} +- **Fingerprinting nodes using addr messages:** ... + +{:#garbledlocks} +- **Garbled locks:** ... + +
+ +## Summary 2025: Soft fork proposals + +... + +
+ +## July + +{:#ccdelegation} +- **Chain code delegation:** ... + +## August + +{:#utreexo} +- **Utreexo draft BIPs:** ... + +{:#minfeerate} +- **Lowering the minimum relay feerate:** ... + +{:#templatesharing} +- **Peer block template sharing:** ... + +{:#fuzzing} +- **Differential fuzzing of Bitcoin and LN implementations:** ... + +## September + +{:#simplicity} +- **Details about the design of Simplicity:** ... + +{:#eclipseattacks} +- **Partitioning and eclipse attacks using BGP interception:** ... + +
+ +## Summary 2025: Major releases of popular infrastructure projects + +FIXME:Gustavojfe + +
+ +## October + +{:#arbdata} +- **Theoretical limitations on embedding data in the UTXO set:** ... + +{:#channeljamming} +- **Channel jamming mitigation simulation results and updates:** ... + +## November + +{:#secpperformance} +- **Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1:** ... + +{:#restrictingdata} +- **Multiple discussions about restricting data:** ... + +{:#stalerates} +- **Modeling stale rates by propagation delay and mining centralization:** ... + +{:#bip3} +- **BIP3 and the BIP process:** ... + +
+ +## Summary 2025: Bitcoin Optech + +FIXME:bitschmidty + +Optech was the fortunate and grateful recipient of a $20,000 USD contribution to +our work from the [Human Rights Foundation][]. The funds will be used to pay for +web hosting, email services, podcast transcriptions, and other expenses that +allow us to continue and improve our delivery of technical content to the +Bitcoin community. + +
+ +## December + +FIXME:bitschmidty + +*We thank all of the Bitcoin contributors named above, plus the many +others whose work was just as important, for another incredible year of +Bitcoin development. The Optech newsletter will return to its regular +Friday publication schedule on January 2nd.* + + + +{% include snippets/recap-ad.md when="2025-12-23 17:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} +[topics index]: /en/topics/ +[yirs 2018]: /en/newsletters/2018/12/28/ +[yirs 2019]: /en/newsletters/2019/12/28/ +[yirs 2020]: /en/newsletters/2020/12/23/ +[yirs 2021]: /en/newsletters/2021/12/22/ +[yirs 2022]: /en/newsletters/2022/12/21/ +[yirs 2023]: /en/newsletters/2023/12/20/ +[yirs 2024]: /en/newsletters/2024/12/20/ + +[Human Rights Foundation]: https://hrf.org From 918e662d896e847fc4467da84618326d1a745fb8 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Mon, 15 Dec 2025 11:44:37 -0600 Subject: [PATCH 2/9] News385: optech, compact blocks, arb data, ln eas --- .../en/newsletters/2025-12-19-newsletter.md | 186 ++++++++++++++++-- 1 file changed, 170 insertions(+), 16 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 3fdbc158a..0fd5d357b 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -8,20 +8,20 @@ layout: newsletter lang: en excerpt: > - The eighth annual Bitcoin Optech Year-in-Review special summarizes - notable developments in Bitcoin during all of 2025. - + The eighth annual Bitcoin Optech Year-in-Review special summarizes notable + developments in Bitcoin during all of 2025. --- -{{page.excerpt}} It's the sequel to our summaries from [2018][yirs -2018], [2019][yirs 2019], [2020][yirs 2020], [2021][yirs 2021], -[2022][yirs 2022], [2023][yirs 2023], and [2024][yirs 2024]. + +{{page.excerpt}} It's the sequel to our summaries from [2018][yirs 2018], +[2019][yirs 2019], [2020][yirs 2020], [2021][yirs 2021], [2022][yirs 2022], +[2023][yirs 2023], and [2024][yirs 2024]. ## Contents * January * [Updated ChillDKG draft](#chilldkg) * [Offchain DLCs](#offchaindlcs) - * [Stats on compact block reconstruction](#compactblockstats) + * [Compact block reconstructions](#compactblockstats) * February * [Erlay update](#erlay) * [LN ephemeral anchor scripts](#lneas) @@ -51,18 +51,20 @@ excerpt: > * [Details about the design of Simplicity](#simplicity) * [Partitioning and eclipse attacks using BGP interception](#eclipseattacks) * October - * [Theoretical limitations on embedding data in the UTXO set](#arbdata) + * [Discussions about arbitrary data](#arbdata) * [Channel jamming mitigation simulation results and updates](#channeljamming) * November * [Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1](#secpperformance) - * [Multiple discussions about restricting data](#restrictingdata) * [Modeling stale rates by propagation delay and mining centralization](#stalerates) * [BIP3 and the BIP process](#bip3) + * [Bitcoin Kernel C API introduced](#kernelapi) * December + * [Splicing](#lnsplicing) * Featured summaries * [Vulnerabilities](#vulns) * [Quantum](#quantum) * [Soft fork proposals](#softforks) + * [Stratum v2](#stratumv2) * [Major releases of popular infrastructure projects](#releases) * [Bitcoin Optech](#optech) @@ -77,7 +79,28 @@ excerpt: > - **Offchain DLCs:** ... {:#compactblockstats} -- **Stats on compact block reconstruction:** ... + +- **Compact block reconstructions:** January also saw the first of several items + in 2025 that revisited [previous research][news315 compact blocks] into how + effectively Bitcoin nodes reconstruct blocks using [compact block relay][topic + compact block relay] (BIP152), updating previous measurements and exploring + potential refinements. Updated statistics [published in + January][news339 compact blocks] showed that when mempools are full, + nodes more frequently need to request missing transactions. Poor + orphan resolution was identified as a possible cause, with [some + improvements][news 338] already made. + + Later in the year, analysis examined whether [compact block + prefilling strategies][news365 compact blocks] could further improve + reconstruction success. Testing suggested that selectively prefilling + transactions that were more likely to be missing from peers’ mempools could + reduce fallback requests with only modest bandwidth tradeoffs. Follow-up + research added these additional measurements and updated [real-world + reconstruction measurements][news382 compact blocks] before and after changes + to the [monitoring nodes' minimum relay feerates](#minfeerate), + showing nodes with lower `minrelayfee` have a higher reconstruction + rate. The author also [posted][news368 monitoring] about the + architecture behind his monitoring project. ## February @@ -85,7 +108,20 @@ excerpt: > - **Erlay update:** ... {:#lneas} -- **LN ephemeral anchor scripts:** ... + +- **LN ephemeral anchor scripts:** After several updates to [mempool policies in + Bitcoin Core 28.0][28.0 wallet guide], discussion began in February around + design choices for [ephemeral anchor outputs][topic ephemeral anchors] in LN + commitment transactions. Contributors [examined][news340 lneas] which script + constructions should be used as one of the outputs of [TRUC][topic v3 + transaction relay]-based commitment transactions as a replacement for + existing [anchor outputs][topic anchor outputs]. + + The tradeoffs included how different scripts affect [CPFP][topic cpfp] fee + bumping, transaction weight, and the ability to safely spend or discard anchor + outputs when they are no longer needed. [Continued discussion][news341 lneas] + highlighted interactions with mempool policy and Lightning’s security + assumptions. {:#probpayments} - **Probabilistic payments:** ... @@ -190,7 +226,16 @@ FIXME:Gustavojfe ## October {:#arbdata} -- **Theoretical limitations on embedding data in the UTXO set:** ... + +- **Discussions about arbitrary data:** Conversation in October revisited + longstanding questions about embedding arbitrary data in Bitcoin transactions + and the limits of using the UTXO set for that purpose. [One analysis][news375 + arb data] examined the theoretical constraints on storing data in UTXOs, even + under a restrictive set of Bitcoin transaction rules. + + Subsequent [discussions][news379 arb data] through the rest of the year + focused on whether consensus restrictions on data-carrying transactions should + be considered. {:#channeljamming} - **Channel jamming mitigation simulation results and updates:** ... @@ -213,14 +258,111 @@ FIXME:Gustavojfe ## Summary 2025: Bitcoin Optech -FIXME:bitschmidty - -Optech was the fortunate and grateful recipient of a $20,000 USD contribution to +In Optech's eighth year, we published 50 weekly [newsletters][] and this +Year-in-Review special. Altogether, Optech published over 80,000 English words +about Bitcoin software research and development this year, the rough equivalent +of a 225-page book. + +Each newsletter and blog post was translated into Chinese, French, and Japanese, +with other languages also receiving translations, for a total of over 150 +translations in 2025. + +In addition, every newsletter this year was accompanied by a [podcast][] +episode, totaling over 60 hours in audio form and over 500,000 words in +transcript form. Many of Bitcoin's top contributors were guests on the show, +some of them on more than one episode, with a total of 75 unique +guests in 2025: + +- 0xB10C +- Abubakar Sadiq Ismail (x3) +- Alejandro De La Torre +- Alex Myers +- Andrew Toth +- Anthony Towns +- Antoine Poinsot (x5) +- Bastien Teinturier (x3) +- Bob McElrath +- Bram Cohen +- Brandon Black +- Bruno Garcia +- Bryan Bishop +- Carla Kirk-Cohen (x2) +- Chris Stewart +- Christian Kümmerle +- Clara Shikhelman +- Constantine Doumanidis +- Dan Gould +- Daniela Brozzoni (x2) +- Daniel Roberts +- Davidson Souza +- David Gumberg +- Elias Rohrer +- Eugene Siegel (x2) +- Francesco Madonna +- Gloria Zhao (x2) +- Gregory Sanders (x2) +- Hunter Beast +- Jameson Lopp (x2) +- Jan B +- Jeremy Rubin (x2) +- Jesse Posner +- Johan Halseth +- Jonas Nick (x4) +- Joost Jager (x2) +- Jose SK +- Josh Doman (x2) +- Julian +- Lauren Shareshian +- Liam Eagen +- Marco De Leon +- Matt Corallo +- Matt Morehouse (x7) +- Moonsettler +- Naiyoma +- Niklas Gögge +- Olaoluwa Osuntokun +- Oleksandr Kurbatov +- Peter Todd +- Pieter Wuille +- PortlandHODL +- Rene Pickhardt +- Robin Linus (x3) +- Rodolfo Novak +- Ruben Somsen (x2) +- Russell O’Connor +- Salvatore Ingala (x4) +- Sanket Kanjalkar +- Sebastian Falbesoner (x2) +- Sergi Delgado +- Sindura Saraswathi (x2) +- Sjors Provoost (x2) +- Steve Myers +- Steven Roose (x3) +- Stéphan Vuylsteke (x2) +- supertestnet +- Tadge Dryja (x3) +- TheCharlatan (x2) +- Tim Ruffing +- vnprc +- Vojtěch Strnad +- Yong Yu +- Yuval Kogman +- ZmnSCPxj (x3) + +Optech was the fortunate and grateful recipient of another $20,000 USD contribution to our work from the [Human Rights Foundation][]. The funds will be used to pay for web hosting, email services, podcast transcriptions, and other expenses that allow us to continue and improve our delivery of technical content to the Bitcoin community. +### A special thank you + +After contributing as the primary author for 376 consecutive Bitcoin Optech +newsletters, Dave Harding stepped back from contributing regularly this year. We +cannot thank Harding enough for anchoring the newsletter for eight years and all of +the Bitcoin education, elucidation, and understanding he brought the community. +We are eternally grateful and wish him all the best. + ## December @@ -266,7 +408,7 @@ Friday publication schedule on January 2nd.* {% include snippets/recap-ad.md when="2025-12-23 17:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% include linkers/issues.md v=2 issues="1699,1895,1974,2004,27587,33629,1937,32406" %} [topics index]: /en/topics/ [yirs 2018]: /en/newsletters/2018/12/28/ [yirs 2019]: /en/newsletters/2019/12/28/ @@ -276,4 +418,16 @@ Friday publication schedule on January 2nd.* [yirs 2023]: /en/newsletters/2023/12/20/ [yirs 2024]: /en/newsletters/2024/12/20/ +[newsletters]: /en/newsletters/ [Human Rights Foundation]: https://hrf.org +[news315 compact blocks]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news339 compact blocks]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction +[news365 compact blocks]: /en/newsletters/2025/08/01/#testing-compact-block-prefilling +[news382 compact blocks]: /en/newsletters/2025/11/28/#stats-on-compact-block-reconstructions-updates +[news368 monitoring]: /en/newsletters/2025/08/22/#peer-observer-tooling-and-call-to-action +[28.0 wallet guide]: /en/bitcoin-core-28-wallet-integration-guide/ +[news340 lneas]: /en/newsletters/2025/02/07/#tradeoffs-in-ln-ephemeral-anchor-scripts +[news341 lneas]: /en/newsletters/2025/02/14/#continued-discussion-about-ephemeral-anchor-scripts-for-ln +[news375 arb data]: /en/newsletters/2025/10/10/#theoretical-limitations-on-embedding-data-in-the-utxo-set +[news379 arb data]: /en/newsletters/2025/11/07/#multiple-discussions-about-restricting-data +[news 338]: /en/newsletters/2025/01/24/#bitcoin-core-31397 From c84a2026312ab5d94c9483a3c7c3d2fda0dfe6bc Mon Sep 17 00:00:00 2001 From: TumaBitcoiner Date: Wed, 10 Dec 2025 10:08:42 +0100 Subject: [PATCH 3/9] News385: forking, mev, ln upfront, dahlias, selfish mining, fingerprinting, garbled, utreexo, template sharing, simplicity --- .../en/newsletters/2025-12-19-newsletter.md | 203 +++++++++++++++++- 1 file changed, 192 insertions(+), 11 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 0fd5d357b..1e0cc584a 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -137,13 +137,50 @@ excerpt: > ## March {:#forkingguide} -- **Bitcoin Forking Guide:** ... + +- **Bitcoin Forking Guide:** Anthony Towns posted to Delving Bitcoin [a + guide][news344 fork guide] on how to build community consensus for changes to + Bitcoin’s consensus rules. According to Towns, the process of establishing + consensus can be divided into four steps: [research and development][fork + guide red], [power user exploration][fork guide pue], [industry + evaluation][fork guide ie], and [investor review][fork guide ir]. However, + Towns warned readers that the guide aims to be only a high-level procedure, + and that it could work only in a cooperative environment. {:#templatemarketplace} -- **Private block template marketplace to prevent centralizing MEV:** ... + +- **Private block template marketplace to prevent centralizing MEV:** Developers + Matt Corallo and 7d5x9 posted to Delving Bitcoin [a proposal][news344 template + mrkt] that could help prevent a future in which MEVil, a form of miner + extractable value (MEV) leading to mining centralization, proliferates on + Bitcoin. The proposal, referred to as [MEVpool][mevpool gh], would allow + parties to bid in public markets for selected space within miner block + templates (e.g., "I’ll pay X [BTC] to include transaction Y as long as it + comes before any other transaction which interacts with the smart contract + identified by Z"). + + While services of preferential transaction ordering within block + templates are expected to be provided only by large miners, leading to + centralization, a trust-reduced public market would allow any miner to work on + blinded block templates, whose complete transactions aren’t revealed to miners + until they’ve produced sufficient proof of work to publish the block. The + authors warned that this proposal would require multiple marketplaces to + compete to help preserve decentralization against the dominance of a single + trusted marketplace. {:#lnupfrontfees} -- **LN upfront and hold fees using burnable outputs:** ... + +- **LN upfront and hold fees using burnable outputs:** John Law proposed [a + solution][news 347 ln fees] to [channel jamming attacks][topic channel jamming + attacks], a weakness in the Lightning Network protocol that allows an attacker + to costlessly prevent other nodes from using their funds. The proposal + summarizes a [paper][ln fees paper] he has written about the possibility for + Lightning nodes to charge two additional types of fees for forwarding + payments, an upfront fee and a hold fee. The ultimate spender would pay the + former to compensate forwarding nodes for temporarily using an [HTLC][topic + htlc] slot, while the latter would be paid by any node that delays the + settlement of an HTLC, with the fee amount scaling up with the length of the + delay. ## April @@ -151,7 +188,16 @@ excerpt: > - **SwiftSync speedup for initial block download:** ... {:#dahlias} -- **DahLIAS interactive aggregate signatures:** ... + +- **DahLIAS interactive aggregate signatures:** In April, Jonas Nick, Tim + Ruffing, and Yannick Seurin [announced][news351 dahlias] to the Bitcoin-Dev + mailing list their [DahLIAS paper][dahlias paper], the first interactive + 64-byte aggregate signature scheme compatible with the cryptographic + primitives already used in Bitcoin. Aggregate signatures are the cryptographic + requirement for [cross-input signature aggregation][topic cisa] (CISA), a + feature proposed for Bitcoin that could reduce the size of transactions with + multiple inputs, thus reducing the cost of many different types of spending, + [coinjoins][topic coinjoin] and [payjoins][topic payjoin] included.
@@ -172,13 +218,46 @@ excerpt: > ## June {:#selfishmining} -- **Calculating the selfish mining danger threshold:** ... + +- **Calculating the selfish mining danger threshold:** Antoine Poinsot provided + an [in-depth explanation][news358 selfish miner] of the math behind the + [selfish mining attack][topic selfish mining], based on the 2013 + [paper][selfish miner paper] that gave this exploit its name. Poinsot focused + on reproducing one of the paper's conclusions, proving that a dishonest miner + controlling 33% of the total network hashrate can become marginally more + profitable than the remaining miners by selectively delaying the announcement + of some of the new blocks it finds. {:#fingerprinting} -- **Fingerprinting nodes using addr messages:** ... + +- **Fingerprinting nodes using addr messages:** Developers Daniela Brozzoni and + Naiyoma presented the [results][news360 fingerprinting] of their + fingerprinting research, which focused on identifying the same node on + multiple networks using `addr` messages, which are sent by the nodes, through + the P2P protocol, to advertise other potential peers. Brozzoni and Naiyoma + were able to fingerprint individual nodes using details from their specific + address messages, allowing them to identify the same node running on multiple + networks (such as IPv4 and [Tor][topic anonymity networks]). Researchers + suggested two possible mitigations: either removing timestamps from address + messages entirely or randomizing them slightly to make them less specific to + particular nodes. {:#garbledlocks} -- **Garbled locks:** ... + +- **Garbled locks:** In June, Robin Linus presented [a proposal][news359 bitvm3] + for improving [BitVM][topic acc]-style contracts, based on an [idea][delbrag + rubin] by Jeremy Rubin. The new approach leverages [garbled circuits][garbled + circuits wiki], a cryptographic primitive that makes onchain SNARK + verification a thousand times more efficient than the BitVM2 implementation, + promising a significant reduction in the amount of onchain space required. + However, it comes at the cost of requiring a multi-terabyte offchain setup. + + Later, in August, Liam Eagen [posted][news369 eagen] to the Bitcoin-Dev mailing + list about his research [paper][eagen paper] describing a new mechanism for + creating [accountable computing contracts][topic acc] based on garbled + circuits, called Glock (garbled locks). While the approach is similar, Eagen's + research is independent from Linus'. According to Eagen, Glock allows for a + 550x reduction of onchain data compared to BitVM2.
@@ -196,21 +275,87 @@ excerpt: > ## August {:#utreexo} -- **Utreexo draft BIPs:** ... + +- **Utreexo draft BIPs:** Calvin Kim, Tadge Dryja, and Davidson Souza + co-authored [three draft BIPs][news366 utreexo] for an alternative to storing + the entire UTXO set, called [Utreexo][topic utreexo], which allows nodes to + obtain and verify information about UTXOs being spent in a transaction. The + proposal makes use of a forest of merkle trees to accumulate references to + every UTXO, allowing nodes to avoid storing the outputs. + + Since August, the proposal has received some feedback, and the BIPs have been + assigned numbers: + + * *[BIP181][bip181 utreexo]*: Describes the Utreexo accumulator and its + operations. + + * *[BIP182][bip182 utreexo]*: Defines the rules for validating blocks and + transactions using the Utreexo accumulator. + + * *[BIP183][bip183 utreexo]*: Defines the changes needed for nodes to exchange + an inclusion proof, confirming the UTXOs being spent. {:#minfeerate} - **Lowering the minimum relay feerate:** ... {:#templatesharing} -- **Peer block template sharing:** ... + +- **Peer block template sharing:** Anthony Towns proposed a [way][news366 templ + share] to improve the effectiveness of compact block reconstruction in an + environment where peers have divergent mempool policies. The proposal would + allow full nodes to send block templates to their peers, which in turn would + cache those transactions that would otherwise be rejected by their mempool + policies. The provided template contains transaction identifiers encoded in + the same format used by [compact block relay][topic compact block relay]. + + Later, in August, Towns opened [BIPs #1937][] to formally [discuss the + proposal][news368 templ share] for block template sharing. During the + discussion, several developers raised concerns about privacy and potential + node fingerprinting. In October, Towns decided to [move the draft][news376 + templ share] to the [Bitcoin Inquisition Numbers and Names Authority][binana + repo] (BINANA) repository to address these considerations and to refine the + document. The draft was given the code [BIN-2025-0002][bin]. {:#fuzzing} -- **Differential fuzzing of Bitcoin and LN implementations:** ... + +- **Differential fuzzing of Bitcoin and LN implementations:** Bruno Garcia gave + an update on the [progress and results][news369 fuzz] obtained by + [bitcoinfuzz][], a library to perform fuzz testing of Bitcoin and Lightning + implementations and libraries. Using the library, developers reported more + than 35 bugs in Bitcoin-related projects, such as btcd, rust-bitcoin, + rust-miniscript, LND, and more. + + Garcia also highlighted the importance of differential fuzzing in the + ecosystem. Developers are able to discover bugs in projects that do not + implement fuzzing at all, catch discrepancies across Bitcoin implementations, + and find gaps in the Lightning specifications. + + Finally, Garcia encouraged maintainers to integrate more projects into + bitcoinfuzz, expanding support for differential fuzzing, and provided possible + directions for the future development of the project. ## September {:#simplicity} -- **Details about the design of Simplicity:** ... + +- **Details about the design of Simplicity:** After the release of + [Simplicity][topic simplicity] on the Liquid Network, Russell O'Connor made + three posts to Delving Bitcoin to discuss the [philosophy and the + design][simplicity 370] behind the language: + + * *[Part I][simplicity I post]* examines the three major forms of composition + for transforming basic operations into complex ones. + + * *[Part II][simplicity II post]* dives into Simplicity’s type system + combinators and basic expressions. + + * *[Part III][simplicity III post]* explains how to build logical operations + starting from bits up to cryptographic operations using just computational + Simplicity combinators. + + Since September, two more posts have been published to Delving Bitcoin, [Part + IV][simplicity IV post], discussing side effects, and [Part V][simplicity V + post], dealing with programs and addresses. {:#eclipseattacks} - **Partitioning and eclipse attacks using BGP interception:** ... @@ -420,6 +565,31 @@ Friday publication schedule on January 2nd.* [newsletters]: /en/newsletters/ [Human Rights Foundation]: https://hrf.org +[news358 selfish miner]: /en/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold +[selfish miner paper]: https://arxiv.org/pdf/1311.0243 +[news360 fingerprinting]: /en/newsletters/2025/06/27/#fingerprinting-nodes-using-addr-messages +[news359 bitvm3]: /en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts +[delbrag rubin]: https://rubin.io/bitcoin/2025/04/04/delbrag/ +[garbled circuits wiki]: https://en.wikipedia.org/wiki/Garbled_circuit +[news369 eagen]: /en/newsletters/2025/08/29/#garbled-locks-for-accountable-computing-contracts +[eagen paper]: https://eprint.iacr.org/2025/1485 +[news351 dahlias]: /en/newsletters/2025/04/25/#interactive-aggregate-signatures-compatible-with-secp256k1 +[dahlias paper]: https://eprint.iacr.org/2025/692.pdf +[news344 fork guide]: /en/newsletters/2025/03/07/#bitcoin-forking-guide +[fork guide red]: https://ajtowns.github.io/bfg/research.html +[fork guide pue]: https://ajtowns.github.io/bfg/power.html +[fork guide ie]: https://ajtowns.github.io/bfg/industry.html +[fork guide ir]: https://ajtowns.github.io/bfg/investor.html +[news344 template mrkt]: /en/newsletters/2025/03/07/#private-block-template-marketplace-to-prevent-centralizing-mev +[mevpool gh]: https://github.com/mevpool/mevpool/blob/0550f5d85e4023ff8ac7da5193973355b855bcc8/mevpool-marketplace.md +[news 347 ln fees]: /en/newsletters/2025/03/28/#ln-upfront-and-hold-fees-using-burnable-outputs +[ln fees paper]: https://github.com/JohnLaw2/ln-spam-prevention +[simplicity 370]: /en/newsletters/2025/09/05/#details-about-the-design-of-simplicity +[simplicity I post]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 +[simplicity II post]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 +[simplicity III post]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 +[simplicity IV post]: https://delvingbitcoin.org/t/delving-simplicity-part-two-side-effects/2091 +[simplicity V post]: https://delvingbitcoin.org/t/delving-simplicity-part-programs-and-addresses/2113 [news315 compact blocks]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction [news339 compact blocks]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction [news365 compact blocks]: /en/newsletters/2025/08/01/#testing-compact-block-prefilling @@ -428,6 +598,17 @@ Friday publication schedule on January 2nd.* [28.0 wallet guide]: /en/bitcoin-core-28-wallet-integration-guide/ [news340 lneas]: /en/newsletters/2025/02/07/#tradeoffs-in-ln-ephemeral-anchor-scripts [news341 lneas]: /en/newsletters/2025/02/14/#continued-discussion-about-ephemeral-anchor-scripts-for-ln +[news366 utreexo]: /en/newsletters/2025/08/08/#draft-bips-proposed-for-utreexo +[bip181 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0181.md +[bip182 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0182.md +[bip183 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0183.md +[news366 templ share]: /en/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies +[news368 templ share]: /en/newsletters/2025/08/22/#draft-bip-for-block-template-sharing +[news376 templ share]: /en/newsletters/2025/10/17/#continued-discussion-of-block-template-sharing +[binana repo]: https://github.com/bitcoin-inquisition/binana +[bin]: https://github.com/bitcoin-inquisition/binana/blob/master/2025/BIN-2025-0002.md +[news369 fuzz]: /en/newsletters/2025/08/29/#update-on-differential-fuzzing-of-bitcoin-and-ln-implementations +[bitcoinfuzz]: https://github.com/bitcoinfuzz/bitcoinfuzz [news375 arb data]: /en/newsletters/2025/10/10/#theoretical-limitations-on-embedding-data-in-the-utxo-set [news379 arb data]: /en/newsletters/2025/11/07/#multiple-discussions-about-restricting-data [news 338]: /en/newsletters/2025/01/24/#bitcoin-core-31397 From e1a7d1c2b77e58395aa65b6ee873fb1f2fdb4b71 Mon Sep 17 00:00:00 2001 From: Brandon Black Date: Mon, 15 Dec 2025 22:25:04 -0800 Subject: [PATCH 4/9] News385: soft forks, chilldkg, dlcs, prob payments, quantum, cc delegation --- .../en/newsletters/2025-12-19-newsletter.md | 150 +++++++++++++++++- 1 file changed, 145 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 1e0cc584a..53a48a424 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -73,10 +73,21 @@ excerpt: > ## January {:#chilldkg} -- **Updated ChillDKG draft:** ... + +- **Updated ChillDKG draft:** Tim Ruffing and Jonas Nick + [updated][news335 chilldkg] their work on a distributed key generation + protocol (DKG) for use with the FROST [threshold signature][topic + threshold signature] scheme. ChillDKG aims to provide similar + recoverability features to existing descriptor wallets. {:#offchaindlcs} -- **Offchain DLCs:** ... + +- **Offchain DLCs:** Developer Conduition [posted about][news offchain dlc] a + new offchain DLC ([discreet log contract][topic dlc]) mechanism that enables + participants to collaborate on the creation and extension of a DLC factory, + which allows iterative DLCs that roll along until one party chooses to + resolve onchain. This contrasts with [prior work][news dlc channels] on + offchain DLCs which required interaction at each roll of the contract. {:#compactblockstats} @@ -124,7 +135,18 @@ excerpt: > assumptions. {:#probpayments} -- **Probabilistic payments:** ... + +- **Probabilistic payments:** Oleksandr Kurbatov sparked a + [discussion][delving random] on Delving Bitcoin of methods to produce random + outcomes from Bitcoin scripts. The [original][ok random] method uses + zero-knowledge proofs in a challenger/verifier arrangement and now has a + [published proof of concept][random poc]. Other methods were discussed, + [including one][waxwing random] leveraging the tree structure of + taproot, and a [method][rl random] that scripted the XOR of bits + represented by a sequence of different hashing functions to directly produce + an unpredictable bitstring. There was [discussion][dh random] of whether + such random transaction outcomes could be used to produce probabilistic + HTLCs as an alternative to [trimmed HTLCs][topic trimmed htlc] for small amounts in LN.
@@ -263,14 +285,99 @@ excerpt: > ## Summary 2025: Soft fork proposals -... +This year saw a bevvy of discussions around soft fork proposals, ranging from +the tightly scoped and minimally impactful, to the broadly scoped and +powerful. + +- *Transaction templates:* Several soft fork packages were discussed around + transaction templates. With similar scope and capability are CTV+CSFS + ([BIP119][]+[BIP348][]) and the [taproot-native re-bindable signature + package][news thikcs] ([`OP_TEMPLATEHASH`][BIPs #1974]+[BIP348][]+[BIP349][]). + These represent the minimal capability enhancement for Bitcoin Script to + enable both re-bindable signatures (signatures that do not commit to spending + a specific UTXO), and pre-commitment to spending a UTXO to a specific next + transaction (sometimes called an equality [covenant][topic covenants]). If + activated, they would enable [LN-Symmetry][ctv csfs symmetry] and [simple CTV + vaults][ctv vaults], [reduce DLC signature requirements][ctv dlcs], [reduce + interactivity for Arks][ctv csfs arks], [simplify PTLCs][ctv csfs ptlcs], and + more. One difference between these proposals is that `OP_TEMPLATEHASH` cannot + be used in the [BitVM sibling hack][ctv csfs bitvm] where CTV can, because + `OP_TEMPLATEHASH` does not commit to `scriptSigs`. + + By including [OP_CHECKSIGFROMSTACK][topic OP_CHECKSIGFROMSTACK], these + proposals also enable multi-commitments (committing to multiple related and + optionally ordered values in a locking or spend script) similar to merkle + trees through [Key Laddering][rubin key ladder]. The updated [LNHANCE][lnhance + update] proposal includes `OP_PAIRCOMMIT` ([BIPs #1699][]) to enable + multi-commitments without the additional script size and validation cost + required for Key Laddering. Multi-commitments are useful in LN-Symmetry, + complex delegations, and more. + + Some developers [expressed frustration][ctv csfs letter] about the (from their + perspective) slow progress toward a soft fork, but the volume of discussion + around this category of proposal suggests that interest and enthusiasm remain + high. + +- *Consensus cleanup:* The [consensus cleanup][topic consensus cleanup] proposal + was [updated][gcc update] based on feedback and additional research, a [draft + bip][gcc bip] was published and merged as [BIP54][] and now [includes an + implementation and test vectors][gcc impl tests]. Earlier this year, there was + [discussion][transitory cleanups] of whether such cleanups should be made + temporary in case of unintentional confiscation, but the necessity of + reevaluating such a [temporary soft fork][topic transitory soft forks] every + time it expires makes such temporary soft forks less appealing. + +- *Opcode proposals:* In addition to the bundled opcode proposals discussed + above, there were several other individual Script opcodes proposed or refined + in 2025. + + `OP_CHECKCONTRACTVERIFY` (CCV) [became][ccv bip] [BIP443][] with [refined][ccv + semantics] semantics, especially around the flow of funds. CCV enables + reactive security [vaults][topic vaults], and a wide array of other contracts + by constraining the `scriptPubKey` and amount of an input or output in certain + ways. The `OP_VAULT` proposal was [withdrawn][vault withdrawn] in favor of + CCV. For more on CCV's applications, see [Optech's topic entry][topic MATT]. + + A set of 64-bit arithmetic opcodes were [proposed][64bit bip]. Bitcoin's + current math operations are (surprisingly) not able to operate on the full + range of Bitcoin input and output amounts. Combined with other opcodes to + access and/or constrain input/output amounts, these expanded arithmetic + operations could enable new Bitcoin wallet functionality. + + A proposed [variant][txhash sponsors] of [`OP_TXHASH`][txhash] would enable + [transaction sponsorship][topic fee sponsorship]. + + Developers proposed two options for giving Script elliptic curve cryptographic + operations other than `OP_CHECKSIG` and related operations. One + [proposes][tweakadd] `OP_TWEAKADD` to enable constructing taproot + `scriptPubKeys`. The other [proposes][ecmath] more granular elliptic curve + opcodes, such as `EC_POINT_ADD`, motivated by similar functionality, but with + broader potential applications, such as new signature verifications or + multisignature functionality. Combining either of these proposals with + `OP_TXHASH` and 64-bit arithmetic (or similar opcodes) would enable + functionality similar to CCV. + +- *Script Restoration:* A series of four BIPs were [posted][gsr bips] for the + Script Restoration project. The Script changes and opcodes proposed in these + four BIPs would enable all of the functionality proposed in the above opcode + proposals while allowing more script expressivity.
## July {:#ccdelegation} -- **Chain code delegation:** ... + +- **Chain code delegation:** Jurvis Tan [posted][jt delegation] about his work + with Jesse Posner on a method (now called [Chain Code Delegation][BIPs + #2004]/BIP89) for collaborative custody where the customer, rather than the + partially trusted collaborative custody provider, generates (and keeps + private) the [BIP32][] chain code to derive child keys from the provider's + signing key. This way, the provider cannot derive the customer's full key + tree. The method can be used either blinded (for complete privacy while still + leveraging the provider's key security) or non-blinded (allowing the provider + to enforce policy at the cost of revealing the specific transactions being + signed to the provider). ## August @@ -584,12 +691,38 @@ Friday publication schedule on January 2nd.* [mevpool gh]: https://github.com/mevpool/mevpool/blob/0550f5d85e4023ff8ac7da5193973355b855bcc8/mevpool-marketplace.md [news 347 ln fees]: /en/newsletters/2025/03/28/#ln-upfront-and-hold-fees-using-burnable-outputs [ln fees paper]: https://github.com/JohnLaw2/ln-spam-prevention +[gcc update]: /en/newsletters/2025/02/07/#updates-to-cleanup-soft-fork-proposal +[gcc bip]: /en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup +[news thikcs]: /en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal +[ctv csfs symmetry]: /en/newsletters/2025/04/04/#ln-symmetry +[ctv csfs arks]: /en/newsletters/2025/04/04/#ark +[ctv vaults]: /en/newsletters/2025/04/04/#vaults +[ctv dlcs]: /en/newsletters/2025/04/04/#dlcs +[lnhance update]: /en/newsletters/2025/12/05/#lnhance-soft-fork +[rubin key ladder]: https://rubin.io/bitcoin/2024/12/02/csfs-ctv-rekey-symmetry/ +[ctv csfs ptlcs]: /en/newsletters/2025/07/04/#ctv-csfs-advantages-for-ptlcs +[ctv csfs bitvm]: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs +[ctv csfs letter]: /en/newsletters/2025/07/04/#open-letter-about-ctv-and-csfs +[gcc impl tests]: /en/newsletters/2025/11/07/#bip54-implementation-and-test-vectors +[ccv bip]: /en/newsletters/2025/05/30/#bips-1793 +[ccv semantics]: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics +[vault withdrawn]: /en/newsletters/2025/05/16/#bips-1848 +[64bit bip]: /en/newsletters/2025/05/16/#proposed-bip-for-64-bit-arithmetic-in-script +[txhash sponsors]: /en/newsletters/2025/07/04/#op-txhash-variant-with-support-for-transaction-sponsorship +[txhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo +[tweakadd]: /en/newsletters/2025/09/05/#draft-bip-for-adding-elliptic-curve-operations-to-tapscript +[ecmath]: /en/newsletters/2025/09/05/#draft-bip-for-adding-elliptic-curve-operations-to-tapscript +[gsr bips]: /en/newsletters/2025/10/03/#draft-bips-for-script-restoration +[transitory cleanups]: /en/newsletters/2025/01/03/#transitory-soft-forks-for-cleanup-soft-forks [simplicity 370]: /en/newsletters/2025/09/05/#details-about-the-design-of-simplicity [simplicity I post]: https://delvingbitcoin.org/t/delving-simplicity-part-three-fundamental-ways-of-combining-computations/1902 [simplicity II post]: https://delvingbitcoin.org/t/delving-simplicity-part-combinator-completeness-of-simplicity/1935 [simplicity III post]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 [simplicity IV post]: https://delvingbitcoin.org/t/delving-simplicity-part-two-side-effects/2091 [simplicity V post]: https://delvingbitcoin.org/t/delving-simplicity-part-programs-and-addresses/2113 +[news335 chilldkg]: /en/newsletters/2025/01/03/#updated-chilldkg-draft +[news offchain dlc]: /en/newsletters/2025/01/24/#correction-about-offchain-dlcs +[news dlc channels]: /en/newsletters/2023/07/19/#wallet-10101-beta-testing-pooling-funds-between-ln-and-dlcs [news315 compact blocks]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction [news339 compact blocks]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction [news365 compact blocks]: /en/newsletters/2025/08/01/#testing-compact-block-prefilling @@ -598,6 +731,13 @@ Friday publication schedule on January 2nd.* [28.0 wallet guide]: /en/bitcoin-core-28-wallet-integration-guide/ [news340 lneas]: /en/newsletters/2025/02/07/#tradeoffs-in-ln-ephemeral-anchor-scripts [news341 lneas]: /en/newsletters/2025/02/14/#continued-discussion-about-ephemeral-anchor-scripts-for-ln +[delving random]: https://delvingbitcoin.org/t/emulating-op-rand/1409 +[random poc]: https://github.com/distributed-lab/op_rand +[waxwing random]: /en/newsletters/2025/02/14/#suggested +[ok random]: /en/newsletters/2025/02/07/#emulating-op-rand +[rl random]: /en/newsletters/2025/03/14/#probabilistic-payments-using-different-hash-functions-as-an-xor-function +[dh random]: /en/newsletters/2025/02/14/#asked +[jt delegation]: /en/newsletters/2025/07/25/#chain-code-withholding-for-multisig-scripts [news366 utreexo]: /en/newsletters/2025/08/08/#draft-bips-proposed-for-utreexo [bip181 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0181.md [bip182 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0182.md From c07d4ad8138ae913e289d8aaaa53c63409c5473d Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 19 Dec 2025 08:01:51 -0600 Subject: [PATCH 5/9] News385: quantum Co-authored-by: Brandon Black --- .../en/newsletters/2025-12-19-newsletter.md | 87 ++++++++++++++++++- 1 file changed, 86 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 53a48a424..caf6a14dc 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -225,7 +225,75 @@ excerpt: > ## Summary 2025: Quantum -... +With the increased attention on the potential for a future [quantum][topic +quantum resistance] computer to weaken or break the Elliptic Curve Discrete +Logarithm (ECDL) hardness assumption that Bitcoin relies on to prove the +ownership of coins, several conversations and proposals were put forward +throughout the year to discuss and mitigate the impact of such a development. + +Clara Shikhelman and Anthony Milton [published][news357 quantum report] a paper +covering the impacts of quantum computing on Bitcoin and outlining potential +mitigation strategies. + +[BIP360][] was [updated][news bip360 update] and received its BIP number. This +proposal has drawn interest both as a first step toward quantum-hardening +Bitcoin and an optimization for taproot use cases that do not require an +internal key. [Research][news365 quantum taproot] later in the year confirmed +the security of these taproot commitments against manipulation by quantum +computers. Near the end of the year, the proposal was renamed to P2TSH (pay to +tapscript hash) instead of the earlier name P2QRH (pay to quantum resistant +hash), reflecting its reduced scope and increased generality. + +Jesse Posner [highlighted existing research][news364 quantum primatives] that +indicates existing Bitcoin primitives like hierarchical deterministic (HD) +wallets, [silent payments][topic silent payments], key aggregation, and +[threshold signatures][topic threshold signature] could be compatible with some +of the commonly referenced quantum-resistant signature algorithms. + +Augustin Cruz [proposed][news qr cruz] a BIP to destroy coins that are +quantum-vulnerable with certainty. Subsequently, Jameson Lopp [started a +discussion][news qr lopp1] of how quantum-vulnerable coins should be handled, +which led to several ideas ranging from letting the quantum adversary have them +to destroying them. Lopp later [proposed][news qr lopp2] a concrete [sequence of +soft forks][BIPs #1895] that Bitcoin could implement, beginning long before a +Cryptographically Relevant Quantum Computer (CRQC) is developed to gradually +mitigate the threat of a quantum adversary suddenly gaining access to many +coins, while allowing holders time to secure their coins. + +Two proposals ([1][news qr sha], [2][news qr cr]) were made to enable most +existing coins to be secured in a way that could be recovered in the event that +Bitcoin disables quantum-vulnerable spends at some later point. Briefly, the +theorized sequence of events is 0) bitcoin holders ensure that their current +wallets have some hashed secret required for some spend path +1) a CRQC is shown to be imminent, 2) Bitcoin disables elliptic curve +signatures, 3) Bitcoin enables a quantum secure signature scheme, 4) Bitcoin +enables one of these proposals enabling prepared holders to claim their +quantum-vulnerable coins. Depending on the exact implementation, any address +type (including P2TR with a scriptpath) could take advantage of these methods. + +Developer Conduition demonstrated that [`OP_CAT`][BIP347] can be used to +implement Winternitz signatures, which provide a quantum-resistant signature +check at a cost of ~2000 vbytes per input. This is less costly than the +previously [proposed][rubin lamport] `OP_CAT`-based [Lamport +signatures][lamport]. + +Matt Corallo started a [discussion][news qr corallo] around the general idea of +adding a quantum-resistant signature-checking opcode to [tapscript][topic +tapscript]. Later, Abdelhamid Bakhta [proposed][abdel stark] native STARK +verification as one such opcode, and Conduition [wrote][conduition sphincs] +about their work optimizing SLH-DSA (SPHINCS) quantum-resistant signatures as +another option. Any quantum-resistant signature checking opcode including +`OP_CAT` added to tapscript could be combined with [BIP360][] to fully +quantum-harden Bitcoin outputs. + +Tadge Dryja [proposed][news qr agg] one way in which Bitcoin could implement +general cross-input signature aggregation which would partially mitigate the +large size of post-quantum signatures. + +At the end of the year, Mikhail Kudinov and Jonas Nick [published][nick paper +tweet] a [paper][hash-based signature schemes] that provides an overview of +hash-based signature schemes and discusses how those could be adapted to suit +Bitcoin’s needs.
@@ -720,6 +788,23 @@ Friday publication schedule on January 2nd.* [simplicity III post]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 [simplicity IV post]: https://delvingbitcoin.org/t/delving-simplicity-part-two-side-effects/2091 [simplicity V post]: https://delvingbitcoin.org/t/delving-simplicity-part-programs-and-addresses/2113 +[news bip360 update]: /en/newsletters/2025/03/07/#update-on-bip360-pay-to-quantum-resistant-hash-p2qrh +[news qr sha]: /en/newsletters/2025/04/04/#securely-proving-utxo-ownership-by-revealing-a-sha256-preimage +[news qr cr]: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery +[news qr lopp1]: /en/newsletters/2025/04/04/#should-vulnerable-bitcoins-be-destroyed +[news qr lopp2]: /en/newsletters/2025/08/01/#migration-from-quantum-vulnerable-outputs +[news qr cruz]: /en/newsletters/2025/04/04/#draft-bip-for-destroying-quantum-insecure-bitcoins +[news qr corallo]: /en/newsletters/2025/01/03/#quantum-computer-upgrade-path +[rubin lamport]: https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ +[lamport]: https://en.wikipedia.org/wiki/Lamport_signature +[conduition sphincs]: /en/newsletters/2025/12/05/#slh-dsa-sphincs-post-quantum-signature-optimizations +[abdel stark]: /en/newsletters/2025/11/07/#native-stark-proof-verification-in-bitcoin-script +[news364 quantum primatives]: /en/newsletters/2025/07/25/#research-indicates-common-bitcoin-primitives-are-compatible-with-quantum-resistant-signature-algorithms +[news365 quantum taproot]: /en/newsletters/2025/08/01/#security-against-quantum-computers-with-taproot-as-a-commitment-scheme +[news357 quantum report]: /en/newsletters/2025/06/06/#quantum-computing-report +[news qr agg]: /en/newsletters/2025/11/07/#post-quantum-signature-aggregation +[nick paper tweet]: https://x.com/n1ckler/status/1998407064213704724 +[hash-based signature schemes]: https://eprint.iacr.org/2025/2203.pdf [news335 chilldkg]: /en/newsletters/2025/01/03/#updated-chilldkg-draft [news offchain dlc]: /en/newsletters/2025/01/24/#correction-about-offchain-dlcs [news dlc channels]: /en/newsletters/2023/07/19/#wallet-10101-beta-testing-pooling-funds-between-ln-and-dlcs From 5c2c98de16057cdcf5a0730a0ea1b68e7d07f409 Mon Sep 17 00:00:00 2001 From: kevkevinpal Date: Sat, 6 Dec 2025 16:52:27 -0500 Subject: [PATCH 6/9] News385: erlay, bgp, jamming, secp, stale rates --- .../en/newsletters/2025-12-19-newsletter.md | 85 +++++++++++++++++-- 1 file changed, 78 insertions(+), 7 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index caf6a14dc..1185c328e 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -116,7 +116,21 @@ excerpt: > ## February {:#erlay} -- **Erlay update:** ... + +- **Erlay update:** Sergi Delgado made [several posts][erlay optech posts] this + year about his work and progress implementing [Erlay][erlay] in Bitcoin Core. + In the first post, he gave an overview of the Erlay proposal and how the + current transaction relay mechanism ("fanout") works. In these posts, he + discussed different results he found while developing Erlay, such as that + [filtering based on transaction knowledge][erlay knowledge] was not as + impactful as expected. He also experimented with selecting [how many peers + should receive a fanout][erlay fanout amount], finding that there was a 35% + bandwidth savings with 8 outbound peers and 45% with 12 outbound peers, but + also found a 240% increase in latency. In two other experiments, he + determined the [fanout rate based on how a transaction was + received][erlay transaction received] and [when to select candidate + peers][erlay candidate peers]. These experiments, which combined fanout and + reconciliation, helped him determine when to use each method. {:#lneas} @@ -533,7 +547,14 @@ powerful. post], dealing with programs and addresses. {:#eclipseattacks} -- **Partitioning and eclipse attacks using BGP interception:** ... + +- **Partitioning and eclipse attacks using BGP interception:** Cedarctic + [posted][Cedarctic post] to Delving Bitcoin about flaws in Border Gateway + Protocol (BGP) which could be used to prevent full nodes from being able to + connect to honest peers, potentially allowing network partitions or [eclipse + attacks][eclipse attack]. Several mitigations were described by cedarctic, + with other developers in the discussion describing other mitigations and ways + to monitor for the attack.
@@ -558,18 +579,54 @@ FIXME:Gustavojfe be considered. {:#channeljamming} -- **Channel jamming mitigation simulation results and updates:** ... + +- **Channel jamming mitigation simulation results and updates:** Carla + Kirk-Cohen, in collaboration with Clara Shikhelman and elnosh, posted the + [Lightning jamming simulation results][channel jamming results] for their + updated reputation algorithm. The updates included reputation tracking for + outgoing channels and tracking incoming channel resource limitations. With + these new updates, they found that it still protects against + [resource][channel jamming resource] and [sink][channel jamming sink] attacks. + After this round of updates and simulations, they feel that [channel jamming + attack][channel jamming attack] mitigation has reached a point where it is + sufficient for implementation. ## November {:#secpperformance} -- **Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1:** ... -{:#restrictingdata} -- **Multiple discussions about restricting data:** ... +- **Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1:** + Ten years after Bitcoin Core switched from OpenSSL to libsecp256k1, Sebastian + Falbesoner [posted][openssl vs libsecp256k1] a benchmark analysis comparing + the performance of both cryptographic libraries for signature validation. + Libsecp256k1 was created in 2015 specifically for Bitcoin Core, and was + already between 2.5 and 5.5 times faster at the time. Falbesoner found the gap + has since widened to more than 8x, as libsecp256k1 continued to improve while + OpenSSL's secp256k1 performance remained static, which is unsurprising given + the curve's limited relevance outside Bitcoin. + + In the discussion, libsecp256k1 creator Pieter Wuille notes that the + benchmarks have inherent biases: all versions were tested on modern hardware + and compilers, but historical optimizations targeted the hardware and + compilers that existed at the time. {:#stalerates} -- **Modeling stale rates by propagation delay and mining centralization:** ... + +- **Modeling stale rates by propagation delay and mining centralization:** + Antoine Poinsot [posted][Antoine post] to Delving Bitcoin analyzing how block + propagation delays systematically advantage larger miners. He modeled two + scenarios in which block A goes stale. In the first, a competing block B is + found before A and propagates first. In the second, B is found shortly after + A, but the same miner also finds the next block. The first scenario is more + likely, suggesting miners benefit more from hearing others' blocks quickly + than from broadcasting their own. + + Poinsot showed that stale rates increase with propagation delay and + disproportionately affect smaller miners. He found that with 10-second + propagation, a 5 EH/s operation earning $91M annually could gain about $100k + in additional revenue by connecting to the largest pool instead of the + smallest. Since mining operates on thin margins, small revenue differences can + translate to significant profit impacts. {:#bip3} - **BIP3 and the BIP process:** ... @@ -740,6 +797,17 @@ Friday publication schedule on January 2nd.* [newsletters]: /en/newsletters/ [Human Rights Foundation]: https://hrf.org +[openssl vs libsecp256k1]: /en/newsletters/2025/11/07/#comparing-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1 +[channel jamming results]: /en/newsletters/2025/10/24/#channel-jamming-mitigation-simulation-results-and-updates +[channel jamming resource]: https://delvingbitcoin.org/t/hybrid-jamming-mitigation-results-and-updates/1147#p-3212-resource-attacks-3 +[channel jamming sink]: https://delvingbitcoin.org/t/hybrid-jamming-mitigation-results-and-updates/1147#p-3212-manipulation-sink-attack-9 +[channel jamming attack]: /en/topics/channel-jamming-attacks/ +[erlay optech posts]: /en/newsletters/2025/02/07/#erlay-update +[erlay]: /en/topics/erlay/ +[erlay knowledge]: https://delvingbitcoin.org/t/erlay-filter-fanout-candidates-based-on-transaction-knowledge/1416 +[erlay fanout amount]: https://delvingbitcoin.org/t/erlay-find-acceptable-target-number-of-peers-to-fanout-to/1420 +[erlay transaction received]: https://delvingbitcoin.org/t/erlay-define-fanout-rate-based-on-the-transaction-reception-method/1422 +[erlay candidate peers]: https://delvingbitcoin.org/t/erlay-select-fanout-candidates-at-relay-time-instead-of-at-relay-scheduling-time/1418 [news358 selfish miner]: /en/newsletters/2025/06/13/#calculating-the-selfish-mining-danger-threshold [selfish miner paper]: https://arxiv.org/pdf/1311.0243 [news360 fingerprinting]: /en/newsletters/2025/06/27/#fingerprinting-nodes-using-addr-messages @@ -808,6 +876,9 @@ Friday publication schedule on January 2nd.* [news335 chilldkg]: /en/newsletters/2025/01/03/#updated-chilldkg-draft [news offchain dlc]: /en/newsletters/2025/01/24/#correction-about-offchain-dlcs [news dlc channels]: /en/newsletters/2023/07/19/#wallet-10101-beta-testing-pooling-funds-between-ln-and-dlcs +[Cedarctic post]: /en/newsletters/2025/09/19/#partitioning-and-eclipse-attacks-using-bgp-interception +[eclipse attack]: /en/topics/eclipse-attacks/ +[Antoine post]: /en/newsletters/2025/11/21/#modeling-stale-rates-by-propagation-delay-and-mining-centralization [news315 compact blocks]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction [news339 compact blocks]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction [news365 compact blocks]: /en/newsletters/2025/08/01/#testing-compact-block-prefilling From c6671cda69e505a2a2e30646f786a07379b93272 Mon Sep 17 00:00:00 2001 From: Gustavojfe <106698848+Gustavojfe@users.noreply.github.com> Date: Thu, 18 Dec 2025 08:53:03 +0000 Subject: [PATCH 7/9] News385: vulnerabilities, releases, splicing --- .../en/newsletters/2025-12-19-newsletter.md | 237 +++++++++++++++++- 1 file changed, 232 insertions(+), 5 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 1185c328e..09e913a3a 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -164,9 +164,100 @@ excerpt: >
-## Summary 2025: Vulnerabilities - -... +## Summary 2025: Vulnerability disclosures + +In 2025, Optech summarized more than a dozen vulnerability disclosures. +Vulnerability reports help both developers and users learn from past mistakes, +and [responsible disclosures][topic responsible disclosures] ensure fixes are +released before vulnerabilities can be exploited. + +_Note: Optech only publishes the names of vulnerability discoverers if we think +they made a reasonable effort to minimize the risk of harm to users. We thank +all the individuals mentioned in this section for their insight and clear +concern for user safety._ + +In early January, Yuval Kogman [publicly disclosed][news335 coinjoin] several +longstanding deanonymization weaknesses in centralized [coinjoin][topic +coinjoin] protocols used by current versions of Wasabi and Ginger, as well as in +past versions of Samourai, Sparrow, and Trezor Suite. If exploited, a +centralized coordinator could link a user’s inputs to their outputs, effectively +removing the expected privacy benefits of the coinjoin. A similar vulnerability was +also reported in late 2024 (see [Newsletter #333][news333 coinjoin]). + +At the end of January, Matt Morehouse [announced][news339 ldk] the responsible +disclosure of a vulnerability in LDK’s claim processing during unilateral closes +with many pending [HTLCs][topic htlc]. LDK aimed to reduce fees by batching +multiple HTLC resolutions; however, if conflicts arose with confirmed +transactions from a channel counterparty, LDK could fail to update all affected +batches, leading to stuck funds and even theft risk. This issue was fixed in +LDK 0.1. + +That same week, Antoine Riard [disclosed][news339 cycling] an additional +vulnerability using the [replacement cycling][topic replacement cycling] attack. +An attacker could exploit it by [pinning][topic transaction pinning] a victim’s +unconfirmed transaction, receiving and not propagating the victim's fee-bumping +replacements, and then selectively mining the victim’s highest-fee version. This +scenario required rare conditions and would be difficult to sustain without +being detected. + +In February, Morehouse [disclosed][news340 htlcbug] a second LDK vulnerability: +if many HTLCs had the same amount and payment hash, LDK would fail to settle +all HTLCs except one, leading honest counterparties to force-close the channels. +While this didn’t enable direct theft, it resulted in extra fees and reduced +routing revenue until the bug was fixed in LDK 0.1.1 (see Newsletter [#340][news340 +htlcfix]). + +In March, Morehouse [announced][news344 lnd] the responsible disclosure of a +fixed LND vulnerability in versions before 0.18: an attacker with a +channel to the victim could cause LND to both pay and refund the same HTLC if +they could also somehow cause the victim’s node to restart. This would allow the +attacker to steal nearly the entire channel value. The disclosure also +highlighted gaps in the Lightning specification, which were later corrected (see +[Newsletter #346][news346 bolts]). + +In May, Ruben Somsen [described][news353 bip30] a theoretical consensus-failure +edge case related to BIP30’s historical handling of [duplicate][topic duplicate +transactions] coinbase transactions. With checkpoints removed from Bitcoin Core +(see [Newsletter #346][news346 checkpoints]), an extreme block reorg up to block +91,842 could leave nodes with different UTXO sets, depending on whether or not +they observed the duplicate coinbases. Several solutions were discussed, such as +hardcoding additional special-case logic for these two exceptions; however, it +wasn't deemed a realistic threat. + +Also in May, Antoine Poinsot [announced][news354 32bit] the responsible +disclosure of a low-severity vulnerability affecting Bitcoin Core versions +before 29.0 where excessive address advertisements could overflow a 32-bit +identifier and crash the node. Earlier mitigations had already made exploitation +impractically slow under the default peer limits (see Newsletters [#159][news159 +32bit] and [#314][news314 32bit]), and the issue was fully resolved by switching +to 64-bit identifiers in Bitcoin Core 29.0. + +In July, Morehouse [announced][news364 lnd] the responsible disclosure of an LND +denial-of-service issue in which an attacker could repeatedly request historic +[gossip][topic channel announcements] messages until the node exhausted its +memory and crashed. This bug was fixed in LND 0.18.3 (see [Newsletter +#319][news319 lnd]). In September, Morehouse [disclosed][news373 eclair] a +vulnerability in older versions of Eclair: an attacker could +broadcast an old commitment transaction to steal all current funds from a +channel, and Eclair would ignore it. Eclair’s fix was paired with a more +comprehensive test suite intended to catch similar potential issues. + +In October, Poinsot [published][news378 four] four low-severity, responsibly +disclosed Bitcoin Core vulnerabilities, covering two disk-filling bugs, a highly +unlikely remote crash affecting 32-bit systems, and a CPU DoS issue in +unconfirmed transaction processing. These were partially fixed in 29.1 and fully +fixed in 30.0, see Newsletters [#361][news361 four], [#363][news363 four], and +[#367][news367 four] for a few of the fixes. + +In December, Bruno Garcia [disclosed][news383 nbitcoin] a theoretical consensus +failure in the NBitcoin library related to `OP_NIP` that could trigger an +exception in a specific full-capacity stack edge case. It was found using +differential fuzzing and quickly patched. No full node is known to use NBitcoin +so there was no practical chain-split risk from the disclosure. + +In December, Morehouse also [disclosed][news384 lnd] three critical +vulnerabilities in LND including two theft-of-funds vulnerabilities and one +denial-of-service vulnerability.
@@ -560,7 +651,68 @@ powerful. ## Summary 2025: Major releases of popular infrastructure projects -FIXME:Gustavojfe +- [BDK wallet-1.0.0][] marked the first major release of this library, where the + original `bdk` crate was renamed to `bdk_wallet` with a stable API and lower + layer modules were extracted into their own crates. + +- [LDK v0.1][] added support for both sides of the LSPS channel open negotiation + protocols, [BIP353][] Human Readable Names resolution, and reduced onchain fee + costs when resolving multiple [HTLCs][topic htlc] for a single channel + force-closure. + +- [Core Lightning 25.02][] added support for [peer storage][topic peer storage], + off by default. + +- [Eclair v0.12.0][] added support for creating and managing [BOLT12 + offers][topic offers], a new channel closing protocol that supports + [RBF][topic rbf], and support for storing small amounts of data for peers + through [peer storage][topic peer storage]. + +- [BTCPay Server 2.1.0][] added several improvements for [RBF][topic rbf] and + [CPFP][topic cpfp] fee bumping, a better flow for multisig when all signers + are using BTCPay Server, and made some breaking changes for users of some + altcoins. + +- [Bitcoin Core 29.0][] replaced the UPnP feature (responsible in part for + several past security vulnerabilities) with a NAT-PMP option, improved + fetching of parents of orphan transactions for [package relay][topic package + relay], improved [timewarp][topic time warp] avoidance for miners, and + migrated the build system from `automake` to `cmake`. + +- [LND 0.19.0-beta][] added new RBF-based fee bumping for cooperative closes. + +- [Core Lightning 25.05][] introduced experimental [splicing][topic splicing] + support compatible with Eclair, and enabled peer storage by default. + +- [BTCPay Server 2.2.0][] added support for wallet policies and + [miniscript][topic miniscript]. + +- [Core Lightning v25.09][] added support to the `xpay` command for paying + [BIP353][] addresses and [offers][topic offers]. + +- [Eclair v0.13.0][] introduced an initial implementation of [simple taproot + channels][topic simple taproot channels], improvements to [splicing][topic + splicing] based on recent specification updates, and better BOLT12 support. + +- [Bitcoin Inquisition 29.1][] added support for `OP_INTERNALKEY`, an opcode + part of multiple [covenant][topic covenants] proposals. + +- [Bitcoin Core 30.0][] made multiple data carrier (OP_RETURN) outputs standard, + increased the default `datacarriersize` to 100,000, set a default [minimum + relay feerate][topic default minimum transaction relay feerates] of 0.1 + sat/vbyte, added an experimental IPC mining interface for [Stratum v2][topic + pooled mining] integrations, and removed support for creating or loading + legacy wallets. Legacy wallets can be migrated to the [descriptor][topic + descriptors] wallet format. + +- [Core Lightning v25.12][] added [BIP39][] mnemonic seed phrases as the new + default backup method and experimental [JIT channels][topic jit channels] + support. + +- [LDK 0.2][] added support for [splicing][topic splicing] (experimental), + serving and paying static invoices for [async payments][topic async payments], + and [zero-fee-commitment][topic v3 commitments] channels using [ephemeral + anchors][topic ephemeral anchors].
@@ -744,7 +896,34 @@ We are eternally grateful and wish him all the best. ## December -FIXME:bitschmidty +{:#lnsplicing} + +- **Splicing:** In December, [LDK 0.2][] was released with experimental + [splicing][topic splicing] support, making the feature available across three + major Lightning implementations: LDK, Eclair, and Core Lightning. Splicing + allows nodes to add or remove funds from a channel without closing it. + + This wrapped up a year of significant progress towards LN's splicing feature. + Eclair added [support for splicing on public channels][news340 eclairsplice] + in February and [splicing in simple taproot channels][news368 eclairtaproot] + in August. Meanwhile, Core Lightning [finalized][news355 clnsplice] + interoperability with Eclair in May and shipped it in [Core Lightning + 25.05][news359 cln2505]. + + Throughout the year, all the pieces required for the LDK implementation were + added, including [splice-out support][news369 ldksplice] in August, + [integrating][news370 ldkquiesce] splicing with the quiescence protocol in + September, and shipping numerous additional refinements before the 0.2 release. + + The implementation teams also coordinated on specification details, such as + increasing the delay before marking a channel as closed to allow for splice + propagation (raised from 12 to [72 blocks][news359 eclairdelay] per [BOLTs + #1270][]) and [reconnection logic][news381 clnreconnect] for synchronized + splice state per [BOLTs #1289][]. + + However, the main [splicing specification][bolts #1160] remains unmerged as of + the end of the year, with updates still expected and cross-compatibility + issues continuing to be resolved. *We thank all of the Bitcoin contributors named above, plus the many others whose work was just as important, for another incredible year of @@ -894,6 +1073,54 @@ Friday publication schedule on January 2nd.* [rl random]: /en/newsletters/2025/03/14/#probabilistic-payments-using-different-hash-functions-as-an-xor-function [dh random]: /en/newsletters/2025/02/14/#asked [jt delegation]: /en/newsletters/2025/07/25/#chain-code-withholding-for-multisig-scripts +[news335 coinjoin]: /en/newsletters/2025/01/03/#deanonymization-attacks-against-centralized-coinjoin +[news333 coinjoin]: /en/newsletters/2024/12/13/#deanonymization-vulnerability-affecting-wasabi-and-related-software +[news340 htlcbug]: /en/newsletters/2025/02/07/#channel-force-closure-vulnerability-in-ldk +[news340 htlcfix]: /en/newsletters/2025/02/07/#ldk-3556 +[news339 ldk]: /en/newsletters/2025/01/31/#vulnerability-in-ldk-claim-processing +[news339 cycling]: /en/newsletters/2025/01/31/#replacement-cycling-attacks-with-miner-exploitation +[news346 bolts]: /en/newsletters/2025/03/21/#bolts-1233 +[news344 lnd]: /en/newsletters/2025/03/07/#disclosure-of-fixed-lnd-vulnerability-allowing-theft +[news346 checkpoints]: /en/newsletters/2025/03/21/#bitcoin-core-31649 +[news353 bip30]: /en/newsletters/2025/05/09/#bip30-consensus-failure-vulnerability +[news354 32bit]: /en/newsletters/2025/05/16/#vulnerability-disclosure-affecting-old-versions-of-bitcoin-core +[news364 lnd]: /en/newsletters/2025/07/25/#lnd-gossip-filter-dos-vulnerability +[news319 lnd]: /en/newsletters/2024/09/06/#lnd-9009 +[news159 32bit]: /en/newsletters/2021/07/28/#bitcoin-core-22387 +[news314 32bit]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages +[news373 eclair]: /en/newsletters/2025/09/26/#eclair-vulnerability +[news378 four]: /en/newsletters/2025/10/31/#disclosure-of-four-low-severity-vulnerabilities-in-bitcoin-core +[news361 four]: /en/newsletters/2025/07/04/#bitcoin-core-32819 +[news363 four]: /en/newsletters/2025/07/18/#bitcoin-core-32604 +[news367 four]: /en/newsletters/2025/08/15/#bitcoin-core-33050 +[news383 nbitcoin]: /en/newsletters/2025/12/05/#consensus-bug-in-nbitcoin-library +[news384 lnd]: /en/newsletters/2025/12/12/#critical-vulnerabilities-fixed-in-lnd-0-19-0 +[bdk wallet-1.0.0]: /en/newsletters/2025/01/03/#bdk-wallet-1-0-0 +[ldk v0.1]: /en/newsletters/2025/01/17/#ldk-v0-1 +[core lightning 25.02]: /en/newsletters/2025/03/07/#core-lightning-25-02 +[eclair v0.12.0]: /en/newsletters/2025/03/14/#eclair-v0-12-0 +[btcpay server 2.1.0]: /en/newsletters/2025/04/11/#btcpay-server-2-1-0 +[bitcoin core 29.0]: /en/newsletters/2025/04/18/#bitcoin-core-29-0 +[lnd 0.19.0-beta]: /en/newsletters/2025/05/23/#lnd-0-19-0-beta +[core lightning 25.05]: /en/newsletters/2025/06/20/#core-lightning-25-05 +[btcpay server 2.2.0]: /en/newsletters/2025/08/08/#btcpay-server-2-2-0 +[core lightning v25.09]: /en/newsletters/2025/09/05/#core-lightning-v25-09 +[eclair v0.13.0]: /en/newsletters/2025/09/12/#eclair-v0-13-0 +[bitcoin inquisition 29.1]: /en/newsletters/2025/10/10/#bitcoin-inquisition-29-1 +[bitcoin core 30.0]: /en/newsletters/2025/10/17/#bitcoin-core-30-0 +[core lightning v25.12]: /en/newsletters/2025/12/05/#core-lightning-v25-12 +[ldk 0.2]: /en/newsletters/2025/12/05/#ldk-0-2 +[news340 eclairsplice]: /en/newsletters/2025/02/07/#eclair-2968 +[news368 eclairtaproot]: /en/newsletters/2025/08/22/#eclair-3103 +[news355 clnsplice]: /en/newsletters/2025/05/23/#core-lightning-8021 +[news359 cln2505]: /en/newsletters/2025/06/20/#core-lightning-25-05 +[news369 ldksplice]: /en/newsletters/2025/08/29/#ldk-3979 +[news370 ldkquiesce]: /en/newsletters/2025/09/05/#ldk-4019 +[news359 eclairdelay]: /en/newsletters/2025/06/20/#eclair-3110 +[news381 clnreconnect]: /en/newsletters/2025/11/21/#core-lightning-8646 +[bolts #1270]: https://github.com/lightning/bolts/pull/1270 +[bolts #1289]: https://github.com/lightning/bolts/pull/1289 +[bolts #1160]: https://github.com/lightning/bolts/pull/1160 [news366 utreexo]: /en/newsletters/2025/08/08/#draft-bips-proposed-for-utreexo [bip181 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0181.md [bip182 utreexo]: https://github.com/utreexo/biptreexo/blob/main/bip-0182.md From ce352c9ed27e567eed47928a84ad7fda5e8809de Mon Sep 17 00:00:00 2001 From: Murch Date: Wed, 17 Dec 2025 08:03:44 -0800 Subject: [PATCH 8/9] News385: cluster mempool, opreturn, minrelay, bip3 --- .../en/newsletters/2025-12-19-newsletter.md | 90 ++++++++++++++++++- 1 file changed, 86 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 09e913a3a..8ee0ac7f6 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -405,10 +405,51 @@ Bitcoin’s needs. ## May {:#clustermempool} -- **Cluster mempool:** ... + +- **Cluster mempool:** Early in the year, Stefan Richter prompted excitement by + [discovering][news340 richter ggt] that an efficient algorithm for the + _maximum-ratio closure problem_ from a 1989 research paper could be applied to + cluster linearization. Pieter Wuille was already investigating a linear + programming approach as a potential improvement over the initial candidate-set + search and incorporated exploration of the minimal-cut-based approach as a + third option into his research. A little later, Wuille [walked][news341 + pr-review-club txgraph] the Bitcoin Core PR Review Club through the newly + introduced `TxGraph` class which distills transactions to only weight, fees, + and relationships for efficient interaction with the mempool graph. In May, + Wuille published benchmarks for and described the [tradeoffs][news352 wuille + linearization techniques] of the three cluster linearization approaches, + determining that both advanced approaches were far more efficient than the + simple candidate-set search, but that his linear programming-based + spanning-forest linearization algorithm would be more practical than the + min-cut-based approach. In the fall, Abubakar Sadiq Ismail [described][news377 + ismail template improvement] how the cluster mempool could be leveraged to + track when the mempool content had significantly improved upon a prior block + template. Near the end of the year, the cluster mempool implementation was + [completed][news382 cluster mempool completed], staging it to be released with + Bitcoin Core 31.0. Work to replace the initial candidate-set search + linearization algorithm with the spanning-forest linearization algorithm is + ongoing. {:#opreturn} -- **Increasing or removing Bitcoin Core’s OP_RETURN size limit:** ... + +- **Increasing or removing Bitcoin Core’s OP_RETURN policy limit:** In April, + protocol developers discovered that the OP_RETURN output policy limits caused + a malincentive to embed data in payment outputs under some circumstances. In + addition to the observation that the original motivations for the policy had + been outgrown by the network, this prompted a proposal to drop the OP_RETURN + mempool policy limits. This proposition kicked off a heated [debate][news352 + OR debate] about the efficacy of mempool policy, the purpose of Bitcoin, and + the responsibility of Bitcoin developers to regulate or refrain from + regulating usage of Bitcoin. Bitcoin Core contributors argued that economic + incentives made it unlikely that OP_RETURN outputs would see drastically more + use and considered the change to be fixing the incentive bug. Critics + interpreted the removal of the limits as an endorsement of data embedding, but + also agreed that it is economically unattractive to be used that way. + Eventually, the Bitcoin Core 30.0 release shipped an [updated policy][Bitcoin + Core #32406], to allow multiple OP_RETURN outputs and remove the policy limit + on size for OP_RETURN output scripts. After the release, several soft fork + proposals have been put forth, proposing to [curb data embedding](#arbdata) at + the consensus level. ## June @@ -576,7 +617,21 @@ powerful. an inclusion proof, confirming the UTXOs being spent. {:#minfeerate} -- **Lowering the minimum relay feerate:** ... + +- **Lowering the minimum relay feerate:** After lowering the minimum transaction + relay feerate had been [discussed several times][news340 lowering feerates] in + the past years, late in June, some miners suddenly started including + transactions paying less than the default minimum relay feerate of 1 sat/vbyte + in their blocks. By the end of July, [85% of the hashrate][mononautical 85] + had adopted lower minimum feerates and low-feerate transactions were + organically (albeit unreliably) propagating on the network due to node + operators manually configuring lower limits. By mid August, [over 30% of + confirmed transactions][mononautical 32] paid feerates lower than 1 sat/vbyte. + Bitcoin protocol developers observed that the high rate of missing low-feerate + transactions was [causing decreased compact block reconstruction rates][0xb10c + delving] and [proposed][news366 lower feerate] adjusting the default minimum + relay feerate. The Bitcoin Core 29.1 release lowered the default minimum relay + feerate to 0.1 sat/vbyte in early September. {:#templatesharing} @@ -781,7 +836,20 @@ powerful. translate to significant profit impacts. {:#bip3} -- **BIP3 and the BIP process:** ... + +- **BIP3 and the BIP process:** In 2025, work on an updated BIP process proposal + advanced significantly. BIP3 was [assigned][news341 bip3 assigned] a number in + January, published in February, and advanced to Proposed in April. Further + review was followed by a few more updates, in which SPDX License Expressions + were introduced, some Preamble headers were updated, and several + clarifications were worked into the proposals. In November, Murch [motioned to + activate][news382 motion to activate bip3] the proposal, by requesting that + readers review the proposal within another four weeks and comment on whether + BIP3 should be activated. A flurry of subsequent review resulted in a few more + improvements and the reversion of controversial guidance disallowing the use + of LLMs in crafting BIPs. As the year closes out, all review has been + addressed, and BIP3 is [seeking rough consensus][bip3 feedback addressed] for + activation again.
@@ -1035,6 +1103,11 @@ Friday publication schedule on January 2nd.* [simplicity III post]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 [simplicity IV post]: https://delvingbitcoin.org/t/delving-simplicity-part-two-side-effects/2091 [simplicity V post]: https://delvingbitcoin.org/t/delving-simplicity-part-programs-and-addresses/2113 +[news340 richter ggt]: /en/newsletters/2025/02/07/#discovery-of-previous-research-for-finding-optimal-cluster-linearization +[news341 pr-review-club txgraph]: /en/newsletters/2025/02/14/#bitcoin-core-pr-review-club +[news352 wuille linearization techniques]: /en/newsletters/2025/05/02/#comparison-of-cluster-linearization-techniques +[news377 ismail template improvement]: /en/newsletters/2025/10/24/#detecting-block-template-feerate-increases-using-cluster-mempool +[news382 cluster mempool completed]: /en/newsletters/2025/11/28/#bitcoin-core-33629 [news bip360 update]: /en/newsletters/2025/03/07/#update-on-bip360-pay-to-quantum-resistant-hash-p2qrh [news qr sha]: /en/newsletters/2025/04/04/#securely-proving-utxo-ownership-by-revealing-a-sha256-preimage [news qr cr]: /en/newsletters/2025/07/04/#commit-reveal-function-for-post-quantum-recovery @@ -1058,6 +1131,10 @@ Friday publication schedule on January 2nd.* [Cedarctic post]: /en/newsletters/2025/09/19/#partitioning-and-eclipse-attacks-using-bgp-interception [eclipse attack]: /en/topics/eclipse-attacks/ [Antoine post]: /en/newsletters/2025/11/21/#modeling-stale-rates-by-propagation-delay-and-mining-centralization +[news340 lowering feerates]: /en/newsletters/2025/02/07/#discussion-about-lowering-the-minimum-transaction-relay-feerate +[mononautical 85]: https://x.com/mononautical/status/1949452588992414140 +[mononautical 32]: https://x.com/mononautical/status/1958559008698085551 +[news366 lower feerate]: /en/newsletters/2025/08/08/#continued-discussion-about-lowering-the-minimum-relay-feerate [news315 compact blocks]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction [news339 compact blocks]: /en/newsletters/2025/01/31/#updated-stats-on-compact-block-reconstruction [news365 compact blocks]: /en/newsletters/2025/08/01/#testing-compact-block-prefilling @@ -1066,6 +1143,9 @@ Friday publication schedule on January 2nd.* [28.0 wallet guide]: /en/bitcoin-core-28-wallet-integration-guide/ [news340 lneas]: /en/newsletters/2025/02/07/#tradeoffs-in-ln-ephemeral-anchor-scripts [news341 lneas]: /en/newsletters/2025/02/14/#continued-discussion-about-ephemeral-anchor-scripts-for-ln +[news341 bip3 assigned]: /en/newsletters/2025/02/14/#updated-proposal-for-updated-bip-process +[news382 motion to activate bip3]: /en/newsletters/2025/11/28/#motion-to-activate-bip3 +[bip3 feedback addressed]: https://groups.google.com/g/bitcoindev/c/j4_toD-ofEc/m/8HTeL2_iAQAJ [delving random]: https://delvingbitcoin.org/t/emulating-op-rand/1409 [random poc]: https://github.com/distributed-lab/op_rand [waxwing random]: /en/newsletters/2025/02/14/#suggested @@ -1135,3 +1215,5 @@ Friday publication schedule on January 2nd.* [news375 arb data]: /en/newsletters/2025/10/10/#theoretical-limitations-on-embedding-data-in-the-utxo-set [news379 arb data]: /en/newsletters/2025/11/07/#multiple-discussions-about-restricting-data [news 338]: /en/newsletters/2025/01/24/#bitcoin-core-31397 +[news352 OR debate]: /en/newsletters/2025/05/02/#increasing-or-removing-bitcoin-core-s-op-return-size-limit +[0xb10c delving]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/35 \ No newline at end of file From bc49132153ddbf255b21f01ff8c0a083e3ce34b5 Mon Sep 17 00:00:00 2001 From: stickies-v Date: Mon, 15 Dec 2025 18:08:24 +0000 Subject: [PATCH 9/9] News385: swiftsync, kernel, sv2 --- .../en/newsletters/2025-12-19-newsletter.md | 101 +++++++++++++++++- 1 file changed, 100 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2025-12-19-newsletter.md b/_posts/en/newsletters/2025-12-19-newsletter.md index 8ee0ac7f6..9533bdee8 100644 --- a/_posts/en/newsletters/2025-12-19-newsletter.md +++ b/_posts/en/newsletters/2025-12-19-newsletter.md @@ -312,7 +312,21 @@ denial-of-service vulnerability. ## April {:#swiftsync} -- **SwiftSync speedup for initial block download:** ... + +- **SwiftSync speedup for initial block download:** Sebastian Falbesoner + [posted][news349 swiftsync] to Delving Bitcoin a sample implementation and + results of a >5x speedup of _initial block download_ (IBD) through SwiftSync, + an idea initially [proposed][swiftsync ruben gh] by Ruben Somsen. + + The speedup is achieved during IBD by only adding coins to the UTXO set when + they will still be in the UTXO set at the end of IBD. This knowledge of the + final UTXO set state is compactly encoded in a minimally trusted, + pre-generated hints file. In addition to minimizing overhead of chainstate + operations, SwiftSync enables further performance improvements by allowing + parallel block validation. + + Work on a Rust implementation was [announced][swiftsync rust impl] in + September. {:#dahlias} @@ -669,6 +683,52 @@ powerful. bitcoinfuzz, expanding support for differential fuzzing, and provided possible directions for the future development of the project. +
+ +## Summary 2025: Stratum v2 + +[Stratum v2][topic pooled mining] is a mining protocol designed to replace the +original Stratum protocol used between miners and mining pools. One of its key +advantages is that it can allow individual pool members to choose which +transactions to include in their blocks, improving Bitcoin's censorship +resistance by distributing transaction selection across many independent miners. + +Throughout 2025, Bitcoin Core received several updates to better support Stratum +v2 implementations. Some improvements earlier in the year were focused on the +mining RPCs, [upgrading them][news339 sv2fields] with `nBits`, `target`, and +`next` fields, useful for constructing and validating block templates. + +The most significant work focused on Bitcoin Core's experimental inter-process +communication (IPC) interface, which allows an external Stratum v2 service to +interact with Bitcoin Core's block validation without using the slower JSON-RPC +interface. A new [`waitNext()`][news346 waitnext] method was introduced to the +`BlockTemplate` interface that returns a new template only when the chain tip +changes or when mempool fees increase significantly, reducing unnecessary +template generation. [`checkBlock`][news360 checkblock] was then added, enabling +pools to validate miner-provided templates via IPC. IPC was also +[enabled][news369 ipc] by default, and the new `bitcoin-node` and other +multiprocess binaries were added to release builds. A new `bitcoin` wrapper +executable was [added][news357 wrapper] to easily discover and launch an +increasing number of binaries, and a follow-up [implemented][news374 ipcauto] +automatic multiprocess selection, removing the need for the `-m` startup flag. +This year's IPC improvements were wrapped up by [reducing CPU +consumption][news377 ipclog] for multiprocess logging and [ensuring][news381 +witness] that blocks submitted via IPC have their witness commitment +revalidated. + +[Bitcoin Core 30.0][news376 30], released in October, was the first release to +include the experimental IPC mining interface, first [introduced][news323 +miningipc] last year. + +In June, StarkWare [demonstrated][news359 starkware] a modified Stratum v2 +client using STARK proofs to prove that a block's fees belong to a valid +template without revealing the block's transactions. Two new Stratum v2-based +mining pools also launched: [Hashpool][news346 hashpool], which represents +mining shares as [ecash][topic ecash] tokens, and [DMND][news346 dmnd], which +expanded from solo mining to pooled mining. + +
+ ## September {:#simplicity} @@ -851,6 +911,22 @@ powerful. addressed, and BIP3 is [seeking rough consensus][bip3 feedback addressed] for activation again. +{:#kernelapi} + +- **Bitcoin Kernel C API introduced:** [Bitcoin Core #30595][news380 kernel] + introduced a C header that serves as an API for [`bitcoinkernel`][Bitcoin Core + #27587], enabling external projects to interface with Bitcoin Core’s block + validation and chainstate logic via a reusable C library. Currently, it is + limited to operations on blocks and has feature parity with the now-defunct + `libbitcoin-consensus` (see [Newsletter #288][news288 lib]). + + Use cases for `bitcoinkernel` include alternative node implementations, an + Electrum server index builder, a [silent payment][topic silent payments] + scanner, a block analysis tool, and a script validation accelerator, among + others. Several language bindings are in development, including for + [Rust][kernel rust], [Go][kernel go], [JDK][kernel jdk], [C#][kernel csharp], + and [Python][kernel python]. +
## Summary 2025: Bitcoin Optech @@ -1074,6 +1150,15 @@ Friday publication schedule on January 2nd.* [mevpool gh]: https://github.com/mevpool/mevpool/blob/0550f5d85e4023ff8ac7da5193973355b855bcc8/mevpool-marketplace.md [news 347 ln fees]: /en/newsletters/2025/03/28/#ln-upfront-and-hold-fees-using-burnable-outputs [ln fees paper]: https://github.com/JohnLaw2/ln-spam-prevention +[news349 swiftsync]: /en/newsletters/2025/04/11/#swiftsync-speedup-for-initial-block-download +[swiftsync ruben gh]: https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd +[swiftsync rust impl]: https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562/18 +[news288 lib]: /en/newsletters/2024/02/07/#bitcoin-core-29189 +[kernel rust]: https://github.com/sedited/rust-bitcoinkernel +[kernel go]: https://github.com/stringintech/go-bitcoinkernel +[kernel jdk]: https://github.com/yuvicc/bitcoinkernel-jdk +[kernel csharp]: https://github.com/janb84/BitcoinKernel.NET +[kernel python]: https://github.com/stickies-v/py-bitcoinkernel [gcc update]: /en/newsletters/2025/02/07/#updates-to-cleanup-soft-fork-proposal [gcc bip]: /en/newsletters/2025/04/04/#draft-bip-published-for-consensus-cleanup [news thikcs]: /en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal @@ -1103,6 +1188,17 @@ Friday publication schedule on January 2nd.* [simplicity III post]: https://delvingbitcoin.org/t/delving-simplicity-part-building-data-types/1956 [simplicity IV post]: https://delvingbitcoin.org/t/delving-simplicity-part-two-side-effects/2091 [simplicity V post]: https://delvingbitcoin.org/t/delving-simplicity-part-programs-and-addresses/2113 +[news339 sv2fields]: /en/newsletters/2025/01/31/#bitcoin-core-31583 +[news346 waitnext]: /en/newsletters/2025/03/21/#bitcoin-core-31283 +[news360 checkblock]: /en/newsletters/2025/06/27/#bitcoin-core-31981 +[news359 starkware]: /en/newsletters/2025/06/20/#stratum-v2-stark-proof-demo +[news369 ipc]: /en/newsletters/2025/08/29/#bitcoin-core-31802 +[news374 ipcauto]: /en/newsletters/2025/10/03/#bitcoin-core-33229 +[news376 30]: /en/newsletters/2025/10/17/#bitcoin-core-30-0 +[news377 ipclog]: /en/newsletters/2025/10/24/#bitcoin-core-33517 +[news381 witness]: /en/newsletters/2025/11/21/#bitcoin-core-33745 +[news346 hashpool]: /en/newsletters/2025/03/21/#hashpool-v0-1-tagged +[news323 miningipc]: /en/newsletters/2024/10/04/#bitcoin-core-30510 [news340 richter ggt]: /en/newsletters/2025/02/07/#discovery-of-previous-research-for-finding-optimal-cluster-linearization [news341 pr-review-club txgraph]: /en/newsletters/2025/02/14/#bitcoin-core-pr-review-club [news352 wuille linearization techniques]: /en/newsletters/2025/05/02/#comparison-of-cluster-linearization-techniques @@ -1143,6 +1239,9 @@ Friday publication schedule on January 2nd.* [28.0 wallet guide]: /en/bitcoin-core-28-wallet-integration-guide/ [news340 lneas]: /en/newsletters/2025/02/07/#tradeoffs-in-ln-ephemeral-anchor-scripts [news341 lneas]: /en/newsletters/2025/02/14/#continued-discussion-about-ephemeral-anchor-scripts-for-ln +[news380 kernel]: /en/newsletters/2025/11/14/#bitcoin-core-30595 +[news357 wrapper]: /en/newsletters/2025/06/06/#bitcoin-core-31375 +[news346 dmnd]: /en/newsletters/2025/03/21/#dmnd-launching-pooled-mining [news341 bip3 assigned]: /en/newsletters/2025/02/14/#updated-proposal-for-updated-bip-process [news382 motion to activate bip3]: /en/newsletters/2025/11/28/#motion-to-activate-bip3 [bip3 feedback addressed]: https://groups.google.com/g/bitcoindev/c/j4_toD-ofEc/m/8HTeL2_iAQAJ