The State of Bitcoin Core

Bitcoin Core is the most widely used implementation of the bitcoin protocol — the software that most full nodes run to validate the blockchain, relay transactions, and (optionally) manage a wallet. It is maintained by a loose, volunteer group of contributors who coordinate in the open. Roughly twice a year those contributors gather in person at an event called Dev Tech to discuss work in progress. This page synthesizes the notes from the May 2026 Dev Tech meeting to give a plain-language snapshot of where the project's attention is. It is a picture of active work and open debate, not a list of shipped features: much of what follows is exploratory, contested, or explicitly unfinished.

A caveat on sourcing: the underlying material is community-maintained meeting notes, which are summaries rather than verbatim transcripts and rarely attribute statements to named people. Treat specifics (PR numbers, percentages, target releases) as reported at the meeting, not as commitments.

Project health and contributor capacity

A recurring theme, stated bluntly, is that reviewer attention is the project's scarcest resource — and that LLMs are straining it. Maintainers reported roughly 15–20 AI-generated ("slop") pull requests per week and rising, increasingly hard to tell apart from genuine work, which drains the time of regular contributors.1 No policy was settled; ideas ranged from aggressively closing low-quality PRs to disclosure requirements and vouch-style gates, balanced against the cost of wrongly turning away sincere newcomers (including those using LLMs to overcome a language barrier).1 The same capacity strain shows up elsewhere: the BIPs (Bitcoin Improvement Proposals) repository saw more submissions but had only one regularly active editor early in the year, prompting a call for a new editor team and broader review participation.2

On the quality-assurance side, two efforts aim to catch regressions earlier. A Bitcoin Core-specific mutation-testing tool, bcoremutation, deliberately injects bugs to find gaps where no test would catch them, with the goal of running incrementally on each PR.3 And a CDash dashboard — set up during the meeting itself — collects build and test results from nightly, continuous, and deliberately unusual configurations, the aim being to surface breakages on exotic hardware so they can be fixed.4

Modularization: the "kernel" and library-ification

The largest architectural thread is the long effort to carve Bitcoin Core's consensus-validation logic into a reusable kernel library. Its public interface was merged about eight months before the meeting, and early users already include the Floresta light client, a Rust full node, and SwiftSync tooling.5 But the meeting was candid that the kernel is far from its ideal. Contributors want a pure, IO-free validation library, yet the existing threading model — script-verification threads, UTXO-set mutation, per-transaction caches — and years of accreted optimization debt stand in the way; a guiding principle voiced repeatedly is that if Core itself does not use the library, the library is doomed.6 A "laundry list" of about ten supporting tasks captures the granular work: returning proper error codes instead of strings, removing translations from the kernel, splitting the chainstate relationship, and making a key file-write mutex non-recursive (a step toward parallel block writes).7

Several smaller cleanups share this modularization spirit. The coins (UTXO) cache interface is being narrowed so that callers can only do what their context permits — read versus write, thread-safe versus not — after years of append-only growth that "promised too much."8 Logging is moving toward structured, machine-parseable output rather than the kernel emitting bare strings every consumer must parse.9 An exploratory effort would replace the int64_t money type with a dedicated Amount class to make a category of arithmetic mistakes impossible to compile, though existing tooling already does well here and the rollout would be gradual.10 Looking further ahead, contributors sketched what a modern, formally verifiable post-quantum crypto library would need to be mergeable — no dependencies, constant-time, ideally verified — and debated whether it should be written in Rust or C.11

Networking, relay, and privacy

The peer-to-peer (P2P) layer drew a cluster of sessions. Erlay, a bandwidth-saving relay technique, is being rethought: rather than a complex "full Erlay," the simpler proposal is to add dedicated reconciliation-only connections for partition resistance — weighed against significant per-connection memory cost.12 Package relay (relaying a low-fee parent with a fee-paying child) remains at its "1-parent-1-child" stage, which covers an estimated 90% of the need; a known "package relay jam" attack and a shrinking contributor pool push the focus toward narrow, pragmatic wins rather than a general design — especially now that cluster mempool may have changed the right approach.13 A related rework would replace per-peer transaction-announcement queues with a single global, feerate-sorted backlog to bound memory as peer counts grow.14

Privacy featured prominently. Follow-up work on private broadcast would let a node send its own transactions (and their ancestors) with a smaller fingerprint of which node originated them, optionally with decoys.15 A wider discussion of BIP 324 — Bitcoin's encrypted P2P transport — mapped what a passive network observer can still infer from packet size and timing, and where Core's responsibility ends and Tor's begins; targeted measures like shaping transaction relay and randomizing the listening port were favored over reinventing Tor.16 Two reachability and integrity efforts round this out: TCP hole punching to make more home nodes reachable behind NAT without weakening the network's trust assumptions,17 and ASMap, the autonomous-system map that hardens peer selection, which now ships in releases but faces open questions about reproducibility and a release-attestation process.18 Separately, the aging libevent networking dependency is on track for removal as Core gains its own HTTP server and CLI client.19

Mempool, mining, sync, and the wallet

Following the large cluster mempool change, work is adding asynchronous notifications that emit fee-rate "diagrams" on each mempool update, so mining and fee estimation can react efficiently without rebuilding the block template every second.20 On initial sync, SwiftSync uses a compact "hints file" (squeezed from ~450 MB toward ~90 MB) to speed validation; a notable insight is an overlap with Utreexo accumulators that enables a "proofless" variant and, eventually, fully-validating fast sync via the kernel.21 For wallets, silent payments continue toward a reusable static address that preserves privacy — pairing well with human-readable BIP353 names — with the main libsecp256k1 change on its fourth review iteration and still lacking a security proof.22

Interfaces and the GUI

How external software talks to Bitcoin Core is itself under review. A survey of the external interfaces — JSON-RPC, REST, ZMQ, the newer high-performance IPC, and shell notifications — wrestled with reducing duplication, whether to deprecate ZMQ in favor of IPC, and how to evaluate new endpoint requests consistently.23

The desktop GUI is at an inflection point. The QML rewrite has accelerated dramatically — with LLMs cited as a major reason for the pace — to the point that it could fully replace the old Qt Widgets interface, possibly by release 0.33, with test builds planned mid-year.24 The accompanying plan covers a new automated test framework and a staged preview/beta/v1 release process, alongside a needed desktop redesign since the app was first built for mobile.25 That progress reframes an older organizational question — whether the GUI belongs in its separate repository — which the group resolved by agreeing to archive that repo once QML lands.26 On the margins, a small terminal UI for a node is moving toward user-scriptable Lua tabs,27 and the push toward fully static builds is nearly there for bitcoind and the utilities, with the GUI's runtime resource loading the main thing keeping it separate.28

Consensus and script

Consensus-layer change moves slowly and cautiously, but one proposal had concrete momentum: TemplateHash, a covenant primitive in the CheckTemplateVerify lineage that lets a transaction commit to details of its child. It has been merged as a proposed opcode and is headed for testing on Bitcoin Inquisition, motivated chiefly by Ark and simpler Lightning constructions — with progress gated on contributor bandwidth and on whether those use cases take off.29

The throughline

Across these sessions, two pressures recur. The first is modularization — pulling validation, the mempool, networking, and the GUI into cleaner, reusable pieces — pursued unevenly and often blocked by hard-to-review, large refactors. The second is contributor capacity: nearly every thread, from package relay to the GUI to AI slop, returns to the same constraint that review and maintenance attention, not ideas, is the binding limit on what Bitcoin Core can do. The state of Bitcoin Core in 2026 is a mature project doing deep structural work under a real and openly acknowledged resource ceiling.