Sixteen connections. Roughly 3.2 gigabytes of additional memory.
** That was the result one reviewer reported** while testing a buffering problem in Bitcoin Core’s new HTTP infrastructure. After a fix, the same reviewer reported about 3 megabytes of memory growth over 90 seconds with sixteen REST connections. The fix was merged on September 5, before the first release candidate.
An ordinary software problem, found through unusually useful scrutiny.
And a reminder of something that disappears from view whenever we talk about Bitcoin as though mathematics alone keeps it running: cryptography does not manage a network buffer. It does not check every wallet workflow. It does not make an operating system interpret a string safely.
People have to do that work.
On September 14, Bitcoin Core tagged v32.0rc1, the first release candidate for its next major version. The project’s schedule targets October 10, 2026, for the final release. That leaves roughly four weeks for broader testing, with the date explicitly described as an aim.
The invitation is simple: run the candidate in a suitable testing environment, examine what changed, and find the things that still fail.
There is something reassuring about that invitation. The people developing software used to verify Bitcoin are asking others to challenge their confidence before the release is final.
The price chart will get more attention. It usually does.
But this is where a different kind of value gets protected: the ability to use Bitcoin without handing someone else the job of checking it for you.
Sam Altman cites AI safety. With a potential $1 trillion valuation and $750 billion in projected compute spending, investors need to know how much of the AI revolution will become profit.
A release candidate is an admission of uncertainty.
The developers believe they have something that could become the final release. Now they want a wider set of people, machines, configurations, and applications to test that belief.
** Bitcoin Core 32 entered feature freeze on August 20.** The September 14 milestone separated the
32.x
release branch from ongoing development, while work toward version 33 could continue on master
. The release branch concentrates on fixes.That changes the question reviewers need to answer. During feature development, a proposal can justify itself by making the software more useful. During stabilization, a change also has to justify the risk of disturbing something close to release.
A fix can introduce a regression. A cleaner implementation can behave differently with an older client. An optimization can improve one machine’s performance while exposing a problem on another.
RC1 gives people a common version to examine. If important problems emerge, another candidate may be necessary. The process continues until maintainers judge the release ready; reaching a calendar date cannot prove that judgment correct.
The most valuable outcome of the testing window may be a problem that delays the release.
That can be inconvenient for everyone involved. It can also be the reason a much larger group of users never experiences the problem.
One fix in this development cycle deserves a place outside the release notes.
On non-Windows systems, an authenticated RPC user permitted to create wallets could supply a specially crafted wallet name that interfered with command substitution in -walletnotify
. Under a suitable notification configuration, that could cause additional shell commands to execute with the privileges of the Bitcoin Core process. ** The fix was merged on September 2**.
The conditions matter. Exploitation required authenticated access, wallet-creation permission, and the relevant notification setup. The developer report explicitly states that the issue was unreachable through ordinary peer-to-peer communication or an unauthenticated network peer.
The mechanism was nevertheless striking: text intended to identify a wallet could affect an operating-system command.
Think about how far that sits from the Bitcoin security debate most people recognize. We argue about mining concentration, quantum computing, and the cost of attacking consensus. Those questions deserve attention. Meanwhile, practical security also depends on what happens when one function hands a string to another.
Strong cryptography can coexist with vulnerable surrounding software. Understanding that makes it easier to ask useful questions about security.
It also makes it harder to dismiss maintenance as housekeeping.
Bitcoin Core 32 replaces the libevent-based HTTP server used for RPC and REST with an implementation inside the Core codebase. These interfaces let other software request information from a node and, where authorized, ask it to perform operations.
That makes the rewrite relevant to applications that depend on Core even when their users never open Bitcoin Core themselves.
