Running in pruned mode

Its that time of the year again

Bitcoin Optech's 2025 Year-in-Review

nostr:note158qkuyfqdl3qmev54wyr2xcszt8u3f9w9larlqxlf0hpm3x6nvcq68tzm3

Congrats Max and team!

Murch and I cover a lot of Bitcoin technical developments on the

Bitcoin Optech podcast each week.

But there is a lot going on in Bitcoin that we don’t cover.

What are you curious about? Drop a question below and join us for a Twitter/X Space tomorrow and we will get to as many as we can.

https://x.com/i/spaces/1OwxWeWXMoVGQ

Got it. I personally don’t have any time to allocate for that. But I’d be happy to chat with a group that gets established for this if it would help

What did you have in mind?

They did BSV https://github.com/trailofbits/publications?tab=readme-ov-file#bitcoin--derivatives

As part of Brink's mission to ensure the safety and robustness of the open-source Bitcoin Core software, we recently sponsored an independent security audit of the Bitcoin Core codebase.

This represents the first public, third-party audit of Bitcoin Core.

https://brink.dev/blog/2025/11/19/bitcoin-core-security-audit/

The assessment was conducted by Quarkslab and was coordinated with the help of the Open Source Technology Improvement Fund (OSTIF). Funding was provided by Brink with the support of our donors, with technical collaboration from Brink engineer, Niklas Gögge, and Chaincode Labs engineer, Antoine Poinsot.

Why Brink funded this work

The project has a strong security track record, but it has never undergone an external security assessment. We wanted to provide an additional layer of assurance for developers, node operators, holders, and businesses who rely on Bitcoin Core every day

What the audit involved

The focus was on the most security-critical components of the software, including the peer-to-peer networking layer, mempool, chain management, and consensus logic and included:

- Manual code review

- Static and dynamic analysis

- Advanced fuzz testing

What the auditors found

The auditors at Quarkslab reported no critical, high, or medium-severity issues. They identified two low-severity findings and thirteen informational recommendations, none of which were classified as security vulnerabilities under Bitcoin Core’s criteria.

Funding independent reviews like this is just one way we help ensure Bitcoin doesn’t break and continues to serve the world as a secure, reliable monetary network.

Independent review only strengthens that confidence.

Thank you to Quarkslab, the OSTIF, Niklas, and Antoine for their work on this project.

The full report is publicly available here:

https://ostif.org/wp-content/uploads/2025/11/25-05-2133-REP-bitcoincore-security-assessment-V1.3.pdf

Meanwhile…

The decade-long engineering efforts toward libsecp256k1, a minimal from scratch Bitcoin-specific library, result in an 800% speed up over OpenSSL while also:

- removing a problematic dependency

- avoiding side channel attacks

- being fully deterministic

Sebastian Falbesoner via

https://bitcoinops.org/en/newsletters/2025/11/07/#comparing-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1

“Where is the public roadmap for Bitcoin Core?”

This sentiment from Zach is common and Ill give my own thoughts on it

https://x.com/zachherbert/status/1976726178376696016

The subprojects that individual Bitcoin Core engineers contribute to reflect the project’s *software development priorities* which can include things like testing improvements, refactors, features, maintenance, or performance improvements.

These software engineering efforts are distinct from the Bitcoin *protocol*, whose consensus rules change only through broad community agreement and network adoption, not by decisions made exclusively within the Bitcoin Core repository.

If I were looking to derive a shorter term “public roadmap for Bitcoin Core” (again, the Bitcoin Core software, not Bitcoin protocol), there are a few places to look.

**Working Groups**

Contributors actively working on similar efforts form working groups to implement and review projects in Bitcoin Core. A list of the current working groups is on the Bitcoin Core Wiki:

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Working-Groups#current-working-groups

From here we can see interest in: Erlay, Fuzzing, Kernel, Benchmarking, Silent Payments, Cluster Mempool, Stratum v2, Multiprocess, QML GUI, and Net Split

These working groups also provide updates at the weekly Bitcoin Core developer meetings on IRC: https://bitcoincore.org/en/meetings/ This is another place to see current work.

**Tracking issues**

Many subprojects within Bitcoin Core have a place to track a todo list of code changes that roll up into that project.

Here are just a few examples (search the GitHub for “tracking issue” for more):

Multiprocess - https://github.com/bitcoin/bitcoin/issues/28722

Mining interface - https://github.com/bitcoin/bitcoin/issues/33777

MuSig2 - https://github.com/bitcoin/bitcoin/issues/31246

Cluster mempool - https://github.com/bitcoin/bitcoin/issues/30289

Erlay - https://github.com/bitcoin/bitcoin/issues/30249

Bitcoin Kernel Library - https://github.com/bitcoin/bitcoin/issues/27587

SENDTEMPLATE - https://github.com/bitcoin/bitcoin/issues/33691

**Core Dev meetups**

What developers discuss at recent in-person meetings is another data point. Here are transcripts from the

October 2025 meeting - https://btctranscripts.com/bitcoin-core-dev-tech/2025-10

February 2025 meeting - https://btctranscripts.com/bitcoin-core-dev-tech/2025-02

**Merged PRs**

As code changes are merged into the Bitcoin Core GitHub before the next release you can see precisely what will be in the upcoming release. These code changes include PRs related to projects above, but also more general changes unrelated to a particular project, like maintenance work, additional testing, one-off features, etc.

https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Amerged

Likewise Optech has a weekly notable code segment that picks interesting code merges to cover: https://bitcoinops.org/

**Release Milestones**

As Bitcoin Core progresses toward a new release, PRs can be tagged with a milestone representing that release.

For example, here are the items tagged for the previous v30 release:

https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+milestone%3A30.0

And here are considerations for the v31 release: https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+milestone%3A31.0

**TLDR, just tell me what will be in v31**

Sorry, there isn’t a definitive authoritative answer for a decentralized open source project like this. But also in the spirit of decentralization, I can provide my own guesses of what might be in there.

Kernel API - modular use of Bitcoin’s consensus and validation logic outside the full node

MuSig2 (in wallet) - fee-efficient, privacy-preserving multi-signature support

Cluster mempool - makes transaction relay and block assembly more efficient, predictable, and network reliability.

ASMap - help diversify peer connections, strengthening network resilience against eclipse attacks

Static builds - reproducible, portable binaries that enhance security, verifiability, and ease of deployment

I’ll emphasize that while these projects took a ton of work to get where they are, there will also be a majority of PRs in v31 that will not be part of a “project”. They will simply be general improvements, bug fixes, and maintenance work (see https://x.com/bitschmidty/status/1976692672023667057 for examples)

Last week many Bitcoin Core developers met up in Frankfurt, Germany as part of their regular twice-yearly in person meetings.

Attendees volunteered to take notes on the unconference-style sessions and I have a pull request to add the notes to the BTC transcripts website:

- ASMap

- Batch Validation

- Secp256k1 and quantum

- CISA

- Cluster mempool

- CMake

- CoreCheck

- Debugging

- Fuzzamoto

- Libsha

- Multiprocess and Mining Interface

- Fingerprinting

- Net / net_processing split

- Package relay

- Private broadcast

- Security audit

- Subject matter experts and working groups

- Sockets abstraction

Additional informal discussions, code reviews, working groups, or other sessions occurred on:

- BIP 3

- Wallet priorities

- Compact Block prefills

- Silent Payments

- btck

- CI

- SwiftSync

- Benchmarking and IBD

- When do Bitcoin Core users upgrade?

- MuSig2

- Kernel

- Working in-person

- Complications with fuzz testing

- BlockTemplateManager

- QML GUI

- Shared Templates BIP

- Headers-first sync

- Batch Validation

- FIBRE

- Consensus Cleanup

- Silent payments libsecp256k1 light client

- Better communicating with the broad community

- Discussion on block 920138 and Bitcoin Core #33687

- Mempool and relay policy

- CI with CTest and CDash

This meeting was sponsored by BTrust who provided the funding for the venue, food, supplies, etc to facilitate the meeting (thank you!).

JD (from localhost research), Emily (from Brink) and myself organized.

A list of previous meetings is here: https://coredev.tech

The PR to the http://btctranscripts.com website is open here, pending approval:

https://github.com/bitcointranscripts/bitcointranscripts/pull/593

Bitcoin Core v30: a deeper look

Link to the tweet

https://x.com/bitschmidty/status/1976692672023667057

Non Twitter link

https://twitter-thread.com/t/1976692672023667057

Yeah that title was a bit dramatic based on the content we actually covered

https://www.youtube.com/watch?v=6BCTVfxxBlc

I know there is work on differential fuzzing for Bitcoin node implementations to surface incompatibilities. Same for Lightning I think. I dont know about SRI/SV2 work in this regard.

A literal phd in fuzzing. Pretty incredible.

Fuzz testing and Bitcoin Core...

We received a pretty overwhelming response to our recent job post for a Bitcoin Core Fuzzing Internship at Brink.

Brink received over 70 applications for the role with many qualified candidates.

After the results of a coding challenge, we decided to actually move forward with two engineers for the 3 month role.

Dongjia Zhang is a Ph.D. fuzzing researcher and maintainer of the LibAFL fuzzing library used to fuzz test Bitcoin Core.

Stratos has a background in vulnerability research and will join Dongjia in working with Niklas (@dergoegge) in the coming months to enhance the fuzz testing capabilities in Bitcoin Core.

Fuzz testing is the idea of throwing a bunch of quasi-random inputs at various functions of a codebase and seeing if anything abnormal happens. Think of it like mining for bugs.

There is work in both the Bitcoin Core codebase as well as fuzz tooling (like fuzzamoto) in order to test more and more of Bitcoin Core in this way.

Here is a bit more about fuzz testing in Bitcoin Core: https://brink.dev/blog/2023/07/14/fuzzing/

Here is a conversation we had with Matt Morehouse on fuzz testing the Lightning Network:

https://brink.dev/blog/2024/06/25/eng-call-fuzz-testing-lightning/

Marco (@macrohead7) recently completed his year long onsite fuzzing fellowship at Brink and provided some thoughts as well: https://brink.dev/blog/2025/07/31/marco-fuzzing-fellowship/

Brink is proud to support the build out of further fuzzing capabilities in the Bitcoin Core codebase as well as other ecosystem softwares. We have not had intern roles before either and are excited to see how it works out.

Welcome Dongjia and Stratos!

A real example and opportunity of non-development contributions.

Jan B just created a testing guide for the Bitcoin Core v30 release. It outlines the updates in the release as well instructions for testing each.

Testing is an important aspect of software development that anyone can participate in.

The Bitcoin Core v30.0 Release Candidate Testing Guide:

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/

nostr:nevent1qvzqqqqqqypzq9pe402znqgkt6kve5zxh4t94tge7gc54yadn0gf4kp7xdptajvlqqsfyz47ezmals5q8uan4xxqrmxw982ehvu47v6dfdpk3jh8c27u4ssxgyx0n

Nice. Did you happen to use the testing guide?

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/

https://bitcoin.design/