The eighth annual Bitcoin Optech Year-in-Review special summarizes notable developments in Bitcoin during all of 2025. It’s the sequel to our summaries from 2018, 2019, 2020, 2021, 2022, 2023, and 2024.

Contents

January

  • ● Updated ChillDKG draft: Tim Ruffing and Jonas Nick updated their work on a distributed key generation protocol (DKG) for use with the FROST threshold signature scheme. ChillDKG aims to provide similar recoverability features to existing descriptor wallets.
  • ● Offchain DLCs: Developer Conduition posted about a new offchain DLC (discreet log contract) 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 on offchain DLCs which required interaction at each roll of the contract.

  • ● Compact block reconstructions: January also saw the first of several items in 2025 that revisited previous research into how effectively Bitcoin nodes reconstruct blocks using compact block relay (BIP152), updating previous measurements and exploring potential refinements. Updated statistics published in January 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 already made.

    Later in the year, analysis examined whether compact block prefilling strategies 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 before and after changes to the monitoring nodes’ minimum relay feerates, showing nodes with lower minrelayfee have a higher reconstruction rate. The author also posted about the architecture behind his monitoring project.

February

  • ● LN ephemeral anchor scripts: After several updates to mempool policies in Bitcoin Core 28.0, discussion began in February around design choices for ephemeral anchor outputs in LN commitment transactions. Contributors examined which script constructions should be used as one of the outputs of TRUC-based commitment transactions as a replacement for existing anchor outputs.

    The tradeoffs included how different scripts affect CPFP fee bumping, transaction weight, and the ability to safely spend or discard anchor outputs when they are no longer needed. Continued discussion highlighted interactions with mempool policy and Lightning’s security assumptions.

  • ● Probabilistic payments: Oleksandr Kurbatov sparked a discussion on Delving Bitcoin of methods to produce random outcomes from Bitcoin scripts. The original method uses zero-knowledge proofs in a challenger/verifier arrangement and now has a published proof of concept. Other methods were discussed, including one leveraging the tree structure of taproot, and a method that scripted the XOR of bits represented by a sequence of different hashing functions to directly produce an unpredictable bitstring. There was discussion of whether such random transaction outcomes could be used to produce probabilistic HTLCs as an alternative to trimmed HTLCs for small amounts in LN.

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 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 several longstanding deanonymization weaknesses in centralized 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).

At the end of January, Matt Morehouse announced the responsible disclosure of a vulnerability in LDK’s claim processing during unilateral closes with many pending HTLCs. 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 an additional vulnerability using the replacement cycling attack. An attacker could exploit it by 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 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).

In March, Morehouse announced 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).

In May, Ruben Somsen described a theoretical consensus-failure edge case related to BIP30’s historical handling of duplicate coinbase transactions. With checkpoints removed from Bitcoin Core (see Newsletter #346), 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 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 and #314), and the issue was fully resolved by switching to 64-bit identifiers in Bitcoin Core 29.0.

In July, Morehouse announced the responsible disclosure of an LND denial-of-service issue in which an attacker could repeatedly request historic gossip messages until the node exhausted its memory and crashed. This bug was fixed in LND 0.18.3 (see Newsletter #319). In September, Morehouse disclosed 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 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, #363, and #367 for a few of the fixes.

In December, Bruno Garcia disclosed 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 three critical vulnerabilities in LND including two theft-of-funds vulnerabilities and one denial-of-service vulnerability.

March

  • ● Bitcoin Forking Guide: Anthony Towns posted to Delving Bitcoin a 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, power user exploration, industry evaluation, and investor review. 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.

  • ● Private block template marketplace to prevent centralizing MEV: Developers Matt Corallo and 7d5x9 posted to Delving Bitcoin a proposal 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, 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.

  • ● LN upfront and hold fees using burnable outputs: John Law proposed a solution to 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 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 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

  • ● SwiftSync speedup for initial block download: Sebastian Falbesoner posted to Delving Bitcoin a sample implementation and results of a >5x speedup of initial block download (IBD) through SwiftSync, an idea initially proposed 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 in September.

  • ● DahLIAS interactive aggregate signatures: In April, Jonas Nick, Tim Ruffing, and Yannick Seurin announced to the Bitcoin-Dev mailing list their 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 (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 and payjoins included.

Summary 2025: Quantum

With the increased attention on the potential for a future quantum 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 a paper covering the impacts of quantum computing on Bitcoin and outlining potential mitigation strategies.

BIP360 was updated 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 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 that indicates existing Bitcoin primitives like hierarchical deterministic (HD) wallets, silent payments, key aggregation, and threshold signatures could be compatible with some of the commonly referenced quantum-resistant signature algorithms.

Augustin Cruz proposed a BIP to destroy coins that are quantum-vulnerable with certainty. Subsequently, Jameson Lopp started a discussion 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 a concrete sequence of soft forks 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, 2) 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 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 OP_CAT-based Lamport signatures.

Matt Corallo started a discussion around the general idea of adding a quantum-resistant signature-checking opcode to tapscript. Later, Abdelhamid Bakhta proposed native STARK verification as one such opcode, and Conduition wrote 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 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 a paper that provides an overview of hash-based signature schemes and discusses how those could be adapted to suit Bitcoin’s needs.

May

  • ● Cluster mempool: Early in the year, Stefan Richter prompted excitement by discovering 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 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 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 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, 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.
  • ● 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 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, 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 at the consensus level.

June

  • ● Calculating the selfish mining danger threshold: Antoine Poinsot provided an in-depth explanation of the math behind the selfish mining attack, based on the 2013 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 nodes using addr messages: Developers Daniela Brozzoni and Naiyoma presented the results 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). Researchers suggested two possible mitigations: either removing timestamps from address messages entirely or randomizing them slightly to make them less specific to particular nodes.

  • ● Garbled locks: In June, Robin Linus presented a proposal for improving BitVM-style contracts, based on an idea by Jeremy Rubin. The new approach leverages garbled circuits, 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 to the Bitcoin-Dev mailing list about his research paper describing a new mechanism for creating accountable computing contracts 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.

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 (OP_TEMPLATEHASH+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). If activated, they would enable LN-Symmetry and simple CTV vaults, reduce DLC signature requirements, reduce interactivity for Arks, simplify PTLCs, and more. One difference between these proposals is that OP_TEMPLATEHASH cannot be used in the BitVM sibling hack where CTV can, because OP_TEMPLATEHASH does not commit to scriptSigs.

    By including 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. The updated LNHANCE 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 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 proposal was updated based on feedback and additional research, a draft bip was published and merged as BIP54 and now includes an implementation and test vectors. Earlier this year, there was discussion of whether such cleanups should be made temporary in case of unintentional confiscation, but the necessity of reevaluating such a temporary soft fork 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 BIP443 with refined semantics, especially around the flow of funds. CCV enables reactive security 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 in favor of CCV. For more on CCV’s applications, see Optech’s topic entry.

    A set of 64-bit arithmetic opcodes were proposed. 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 of OP_TXHASH would enable transaction sponsorship.

    Developers proposed two options for giving Script elliptic curve cryptographic operations other than OP_CHECKSIG and related operations. One proposes OP_TWEAKADD to enable constructing taproot scriptPubKeys. The other proposes 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 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

  • ● Chain code delegation: Jurvis Tan posted about his work with Jesse Posner on a method (now called Chain Code Delegation/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

  • ● Utreexo draft BIPs: Calvin Kim, Tadge Dryja, and Davidson Souza co-authored three draft BIPs for an alternative to storing the entire UTXO set, called 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: Describes the Utreexo accumulator and its operations.

    • BIP182: Defines the rules for validating blocks and transactions using the Utreexo accumulator.

    • BIP183: Defines the changes needed for nodes to exchange an inclusion proof, confirming the UTXOs being spent.

  • ● Lowering the minimum relay feerate: After lowering the minimum transaction relay feerate had been discussed several times 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 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 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 and proposed 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.

  • ● Peer block template sharing: Anthony Towns proposed a way 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.

    Later, in August, Towns opened BIPs #1937 to formally discuss the proposal 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 to the Bitcoin Inquisition Numbers and Names Authority (BINANA) repository to address these considerations and to refine the document. The draft was given the code BIN-2025-0002.

  • ● Differential fuzzing of Bitcoin and LN implementations: Bruno Garcia gave an update on the progress and results 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.

Summary 2025: Stratum v2

Stratum v2 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 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() 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 was then added, enabling pools to validate miner-provided templates via IPC. IPC was also enabled by default, and the new bitcoin-node and other multiprocess binaries were added to release builds. A new bitcoin wrapper executable was added to easily discover and launch an increasing number of binaries, and a follow-up implemented automatic multiprocess selection, removing the need for the -m startup flag. This year’s IPC improvements were wrapped up by reducing CPU consumption for multiprocess logging and ensuring that blocks submitted via IPC have their witness commitment revalidated.

Bitcoin Core 30.0, released in October, was the first release to include the experimental IPC mining interface, first introduced last year.

In June, StarkWare demonstrated 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, which represents mining shares as ecash tokens, and DMND, which expanded from solo mining to pooled mining.

September

  • ● Details about the design of Simplicity: After the release of Simplicity on the Liquid Network, Russell O’Connor made three posts to Delving Bitcoin to discuss the philosophy and the design behind the language:

    • Part I examines the three major forms of composition for transforming basic operations into complex ones.

    • Part II dives into Simplicity’s type system combinators and basic expressions.

    • Part III 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, discussing side effects, and Part V, dealing with programs and addresses.

  • ● Partitioning and eclipse attacks using BGP interception: Cedarctic posted 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. Several mitigations were described by cedarctic, with other developers in the discussion describing other mitigations and ways to monitor for the attack.

October

  • ● 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 examined the theoretical constraints on storing data in UTXOs, even under a restrictive set of Bitcoin transaction rules.

    Subsequent discussions through the rest of the year focused on whether consensus restrictions on data-carrying transactions should be considered.

  • ● Channel jamming mitigation simulation results and updates: Carla Kirk-Cohen, in collaboration with Clara Shikhelman and elnosh, posted the Lightning jamming simulation 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 and sink attacks. After this round of updates and simulations, they feel that channel jamming attack mitigation has reached a point where it is sufficient for implementation.

November

  • ● Comparing performance of ECDSA signature validation in OpenSSL vs. libsecp256k1: Ten years after Bitcoin Core switched from OpenSSL to libsecp256k1, Sebastian Falbesoner posted 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.

  • ● Modeling stale rates by propagation delay and mining centralization: Antoine Poinsot posted 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 and the BIP process: In 2025, work on an updated BIP process proposal advanced significantly. BIP3 was 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 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 for activation again.

  • ● Bitcoin Kernel C API introduced: Bitcoin Core #30595 introduced a C header that serves as an API for bitcoinkernel, 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).

    Use cases for bitcoinkernel include alternative node implementations, an Electrum server index builder, a silent payment scanner, a block analysis tool, and a script validation accelerator, among others. Several language bindings are in development, including for Rust, Go, JDK, C#, and Python.

Summary 2025: Bitcoin Optech

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

  • ● Splicing: In December, LDK 0.2 was released with experimental 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 in February and splicing in simple taproot channels in August. Meanwhile, Core Lightning finalized interoperability with Eclair in May and shipped it in Core Lightning 25.05.

    Throughout the year, all the pieces required for the LDK implementation were added, including splice-out support in August, integrating 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 per BOLTs #1270) and reconnection logic for synchronized splice state per BOLTs #1289.

    However, the main splicing specification 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 Bitcoin development. The Optech newsletter will return to its regular Friday publication schedule on January 2nd.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 17:30 UTC on December 23. The discussion is also recorded and will be available from our podcasts page.