400 Bitcoin Optech newsletters! Thank you to all who have contributed over these 8 years: Optech contributors, researchers whose work we have covered, engineers joining us on the podcast, and readers/listeners. 🧡 (Yes, its actually 401 newsletters, we started at Newsletter #0) View quoted note →

With an increasing number of discussions around the BIP54 “Consensus Cleanup” soft fork proposal, I helped put together an information site about BIP54. “Bitcoin has four known vulnerabilities that have gone unfixed for 15 years. BIP54, "Consensus Cleanup", proposes four narrowly-scoped changes to address these issues in Bitcoin's consensus rules that date back to the original version of Bitcoin in 2009.”

BIP54.org - The Consensus Cleanup

BIP54 proposes four narrowly-scoped changes to address vulnerabilities in Bitcoin

Today we’re publishing Brink's 2025 Engineering Impact Report covering the work of the eight Bitcoin Core engineers we funded last year and why we think this work is important.

Brink

A detailed look at the contributions Brink

We highlight the broader categories of work that Brink engineers performed in 2025 including: * Code Review * Testing and Bug Fixes * Fuzzamoto * The First Independent Security Audit of Bitcoin Core * Release Management * Build System * Libsecp256k1 * Bitcoin Kernel * Building on Bitcoin's Existing Capabilities We’ve included a selection of highlighted contributions for each engineer we fund: * Marco De Leon * Sebastian Falbesoner * Michael Ford * Niklas Gögge * Fabian Jahr * Eugene Siegel * Hennadii Stepanov * Stéphan Vuylsteke The full report includes more details on the projects, PRs, and accomplishments of each Brink engineer in 2025 and why we think this work is important and impactful to Bitcoin. https://brink.dev/assets/files/brink-engineering-report-2025.pdf For those wanting an even deeper look, we have compiled companion reports for each engineer: * A markdown file explaining all authored PRs * A CSV containing each authored PR * A CSV linking to each PR reviewed None of this work would be possible without the generosity of Bitcoiners who share our mission of strengthening Bitcoin by ensuring that Bitcoin's codebase continues to be maintained, tested, reviewed, and improved in a “Move slow, fix things” fashion. Thank you.

Fuzzamoto is a fuzz testing tool for Bitcoin full nodes. For the last year, Niklas Gögge (@Niklas) has been building Fuzzamoto with the goal of: “an external testing suite that gets as close as possible to taking production binaries as input and producing bugs as output” Part 1 of Brink’s blog series on Fuzzamoto provides an introduction of Fuzzamoto including its motivation, a design overview, and the first bugs found.

Fuzzamoto: Introduction

Part 1 of our series on Fuzzamoto, a fuzz testing tool for Bitcoin full nodes. This post provides an introduction of Fuzzamoto including its motiva...

See our previous discussion with Niklas for further background on fuzz testing:

Niklas Gögge on Fuzz Testing

Niklas Gögge on Fuzz Testing.

Its that time of the year again Bitcoin Optech's 2025 Year-in-Review View quoted note →

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

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.

An Independent Security Audit of Bitcoin Core

As part of Brink

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

Bitcoin Optech

Bitcoin Optech Newsletter #379

This week’s newsletter shares an analysis comparing the historical performance of the OpenSSL and libsecp256k1 libraries. Also included are our r...

“Where is the public roadmap for Bitcoin Core?” This sentiment from Zach is common and Ill give my own thoughts on it

X (formerly Twitter)

Zach Herbert 🇺🇸 (@zherbert) on X

Where is the public roadmap for Bitcoin Core? Bitcoin is already a multi trillion dollar asset and will continue to rapidly grow. Where is the de...

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:

GitHub

Working Groups

Wiki for Bitcoin Core development. Contribute to bitcoin-core/bitcoin-devwiki development by creating an account on GitHub.

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:

Bitcoin Core

IRC Meetings

IRC 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 -

GitHub

Multiprocess tracking issue · Issue #28722 · bitcoin/bitcoin

This issue will be updated to reflect the current state of bitcoin core multiprocess support. PRs for review related to building & releasing: #3497...

Mining interface -

GitHub

Mining interface tracking issue · Issue #33777 · bitcoin/bitcoin

The mining interface is defined in: https://github.com/bitcoin/bitcoin/blob/master/src/interfaces/mining.h https://github.com/bitcoin/bitcoin/blob/...

MuSig2 -

GitHub

MuSig2 Tracking Issue · Issue #31246 · bitcoin/bitcoin

Current PR to review: #34141 libsecp: libsecp module: bitcoin-core/secp256k1#1479 libsecp named structs: bitcoin-core/secp256k1#1628 libsecp subtre...

Cluster mempool -

GitHub

Cluster mempool tracking issue · Issue #30289 · bitcoin/bitcoin

Plan: Lowest level: generic utilities: #29242 FeeFrac type #30535 Add FeeFrac::EvaluateFee #32240 Fix integer overflow in FeeFrac fuzz test #32300 ...

Erlay -

GitHub

Erlay Project Tracking · Issue #30249 · bitcoin/bitcoin

This issue will be edited frequently to reflect the current status of the project. What should I review now? 👇 👇 👇 👇 👇 👇 👇 #30...

Bitcoin Kernel Library -

GitHub

Bitcoin Kernel Library Project Tracking · Issue #27587 · bitcoin/bitcoin

Project Board for pull requests past and present: https://github.com/orgs/bitcoin/projects/3 This is the tracking issue for the bitcoin kernel libr...

SENDTEMPLATE -

GitHub

Template Sharing Tracking Issue · Issue #33691 · bitcoin/bitcoin

Plan: Protocol specification BIN25-2 and BIP153 PR#1937 Implementation: (See comments below) Live tests (See comments below) inquisition.bitcoin-si...

**Core Dev meetups** What developers discuss at recent in-person meetings is another data point. Here are transcripts from the October 2025 meeting -

Bitcoin Core Dev Tech 2025 (Oct)

A collection of technical bitcoin and lightning transcripts

February 2025 meeting -

Bitcoin Core Dev Tech 2025 (Feb)

A collection of technical bitcoin and lightning transcripts

**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.

GitHub

Pull requests · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

Likewise Optech has a weekly notable code segment that picks interesting code merges to cover:

Bitcoin Optech

Bitcoin Optech

Helping Bitcoin-based businesses integrate scaling technology.

**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:

GitHub

Pull requests · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

And here are considerations for the v31 release:

GitHub

Pull requests · bitcoin/bitcoin

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

**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

X (formerly Twitter)

Mike Schmidt (@bitschmidty) on X

Bitcoin Core v30: a deeper look What is in Bitcoin Core v30? One way to answer this is to review the release notes and discuss features. A few con...

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:

CoreDev Events and Conferences

Invitation only developer events for hacking together on Bitcoin Core and related projects. No politics. Just code.

The PR to the

Bitcoin Transcripts

A collection of technical bitcoin and lightning transcripts

website is open here, pending approval:

GitHub

add coredev oct 2025 by bitschmidty · Pull Request #593 · bitcointranscripts/bitcointranscripts

A treasure trove of transcripts associated with Bitcoin and Lightning Network - add coredev oct 2025 by bitschmidty · Pull Request #593 · bitcoin...

Bitcoin Core v30: a deeper look Link to the tweet

X (formerly Twitter)

Mike Schmidt (@bitschmidty) on X

Bitcoin Core v30: a deeper look What is in Bitcoin Core v30? One way to answer this is to review the release notes and discuss features. A few con...

Non Twitter link

Twitter Thread Reader & Converter

Bitcoin Core v30: a deeper look by @bitschmidty(Schmidty) | Twitter Thread Reader

Bitcoin Core v30: a deeper look What is in Bitcoin Core v30? One way to answer this is to review the release notes and discuss features. A few con...

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:

Niklas Gögge on Fuzz Testing

Niklas Gögge on Fuzz Testing.

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

Matt Morehouse on Fuzz Testing the Lightning Network

Matt Morehouse presents the state of fuzz testing in Lightning.

Marco (@macrohead7) recently completed his year long onsite fuzzing fellowship at Brink and provided some thoughts as well:

Marco

Marco De Leon recounts his experiences and accomplishments during his year long 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!

The topic of non-developer contributions to Bitcoin and Bitcoin Core came up in a thread the other day. So I wanted to elevate this list, in case people are interested. Ways to contribute other than code: Education / Outreach Optech Conferences Saving Satoshi Fundraising Bitdevs User feedback Reproducing issues Priorities? Security Dependency auditing CVE disclosure Mailing list Pen testing Dev Tooling CI Signet Fuzzing Drahtbot Corecheck,dev Bitcoin dev wiki Mentoring Developer hubs Review clubs Release Process Testing guide Building binaries Signing binaries translations Packaging for distro Monitoring b10c stuff etc Standardization BIPs Bolts etc Events Coredev Online communication channels Mailing list Delving IRC Twitter / etc Stack exchange

Bitcoin Core

Bitcoin

Bitcoin

Backups of stuff Dev Infrastructure Fuzzing Devops stuff Dns seeds User feedback Outward Talk to miners? Exchanges? Surveys Research BRW Janitor work Reproducing Other items listed: Coredev conference BIPs (review, reading) Stack exchange CI Fuzzer machines Devops Monitoring

Bitcoin Core

Bitcoin

Bitcoin

maintaining/hosting Signet / inquisition Utilities for interacting with Bitcoin (Core) Educational stuff like saving satoshi Delving Mailing list Backup of delving/mailing list/github comments IRC and logs Drahtbot / meetingbot Bitcoinacks (?) Fundraising Developer hubs Review clubs Technical talks / podcasts / outreach Bitdevs Deterministic builds (running) Dns seed Dependency auditing/pruning Architecture CI doesn’t account for Reproducing issues Moderation of github Research Week Twitter threads Translations Security Security mailing list CVE management / disclosure etc Pen testing

corecheck - Test Coverage

Core dev wiki Bitcoin wiki Summaries of communal knowledge Optech Release packaging for distros Janitoring old issues/PRs BOSS program Summer of Bitcoin Original:

Non-development Contributions

Many people, myself included, tout the importance of software maintenance in the context of Bitcoin Core. It is easy to throw out "maintenance!" and most people will nod their head in agreement, but I think its helpful to have some examples to understand the depth of this work and risks of not doing it. There are many categories of maintenance work, today I am just going to zoom in on one: minimizing dependencies. Recently someone attempted to put in a backdoor into XZ, a library used by softwares in hundreds of millions of computers around the world. Even a couple weeks ago hackers slipped malicious code into dozens of NPM packages that receive millions of downloads each week. Bitcoin Core and other Bitcoin software are not immune to these kinds of attacks. While Bitcoin Core has a robust culture of code review and testing, Bitcoin Core uses third-party libraries as well. Code from these libraries is run, in addition to Bitcoin Core's code, when you are running your node. Any bug, vulnerability, or performance issue in these libraries (dependencies) can cause issues for Bitcoin Core. Updates to these dependencies of Bitcoin Core are a potential risk and need to be regularly tracked and reviewed. From a security perspective, these dependencies should also be minimized and eliminated where possible. Bitcoin Core developers have spent years minimizing the number of dependencies of the project. In some cases replacing them with minimal, in-house alternatives that achieve the same function in order to reduce attack surface. In this latest Brink blog, we outline the risks of using dependencies as well as several examples of Bitcoin Core removing problematic or unnecessary dependencies of the project.

The importance of minimizing dependencies in Bitcoin Core

Relying on external code is a risk. We look at the work in Bitcoin Core to minimize these kind of dependencies.

Russell O’Connor joined Brink to explain his work on formal verification of software, the process of mathematically proving that a program satisfies its specification. - Overview of formal verification of software - Walkthrough w/ libsecp256k1 - Coq, Rocq, Clightgen - SafeGCD - Q&A

Russell O

Russell O

Jameson Lopp and Tim Ruffing on quantum Steven Roose on the OP_TEMPLATEHASH soft fork bundle David Gumberg on compact block prefilling Lauren Shareshian from Block on mempool fee estimation View quoted note →

One year ago Marco De Leon embarked on a year long Brink fellowship in our London office. Today, after a year of progress and contributions, we’re happy to bring him on as a full-time Bitcoin Core engineer! "The idea of diving into a codebase as critical and complex as Bitcoin Core’s was intimidating, and frankly, I was a bit worried I didn’t have enough experience to contribute meaningfully. The fellowship provided the perfect bridge..."

Marco

Marco De Leon recounts his experiences and accomplishments during his year long fellowship.

Marco, with guidance from his mentor Niklas Gögge, focused his fellowship on fuzz testing, a technique for catching subtle bugs and security vulnerabilities.

Niklas Gögge on Fuzz Testing

Niklas Gögge on Fuzz Testing.

His work took him from improving existing fuzz tests, to removing the longstanding mainnet checkpoints, to improving type safety in the Bitcoin Core codebase. We are proud of Marco and Niklas for their efforts this past year. Bitcoin is more secure because of Marco's contributions and Bitcoin is stronger with another experienced engineer working on security into the future. If you're interested in fuzzing and a career as an open source Bitcoin engineer, like Marco, we are pleased to offer, in addition to the fellowship, a new Bitcoin Core Fuzzing Internship at Brink Join us and contribute to Bitcoin security through fuzzing!

Bitcoiner Jobs

Bitcoiner Jobs | Engineering Jobs

Find Engineering jobs working with Bitcoiners.

The CTV and CSFS open letter segment got a little spicy with some real talk We really dug in on Tadge's commit/reveal scheme for quantum as well View quoted note →