Decent Newsroom
Sign In

The Patch Is Not the Upgrade

By Roger October 29, 2026
Bitcoin Core fixed three AI-found bugs in five days and disclosed them the day the fixes shipped. Sixteen hours later, 3.5 per cent of reachable nodes ran a patched version and half still ran a release that will never get the fix. The disclosure policy moved the secret; it did not move the install base.
The Patch Is Not the Upgrade

The Patch Is Not the Upgrade

Sixteen hours after Bitcoin Core told the world about three memory bugs, 568 of the 16,283 reachable nodes that identify as Bitcoin Core reported a version carrying the fix. That is 3.5 per cent. A single older release, 31.1.0, accounted for 8,080 nodes, half the network, and 4,965 nodes ran a version the project had declared end-of-life one day earlier.

The five-day story is true. On 23 October an automated scanner found a bug that lets any connected peer crash a Windows, macOS or BSD node. On 26 October the fix was opened, merged and backported. On 27 October versions 31.2 and 32.1 shipped. On 28 October 29.5 and 30.4 followed, and the advisories went public in the same hour. Discovery to disclosure in five days, with no embargo in between.

What that timeline does not measure is the part that decides whether anyone is safer. Code can be fixed in a day; a fleet cannot. The vulnerability window is now set by three clocks running at different speeds, and the policy change that Bitcoin Core merged on 22 October only touched the first one.

Who is running the fix: reachable Bitcoin Core nodes by patch status on 29 October 2026

Three bugs, one scanner

The advisories matter less for what they contain than for what produced them. All three fall under the new “easily discoverable” tier, and two of the three were found by Project Loupe, an automated LLM scanning tool built by Elias Rohrer at Spiral. Gregory Sanders validated the findings and passed them to the security team.

A medium-severity bug is also the cleanest example of how a subtle assumption becomes a remote crash. Bitcoin Core limits how much data it will queue per peer, and it does so by pausing reads when the queue grows too large. On Linux the socket layer uses poll(), which only reports the conditions you asked about. On Windows, macOS and BSD the code uses select(), which also reports “exceptional conditions”, and the handler for that event performed a read regardless of whether reads were paused. TCP urgent data sets exactly that condition. A paused peer could therefore bypass the backpressure mechanism and queue unbounded data. The advisory’s own summary is unusually blunt: a malicious peer “can trivially crash any Windows, macOS or BSD node it is connected to.” Linux is not affected.

The second one is also medium severity, slower, and more interesting. Peers that stop reading get paused, but transaction announcements keep being appended to their send queue, because the queue is normally drained or the peer is disconnected after missing a nonced ping within twenty minutes. That disconnect does not apply to peers that do not advertise BIP 31 support. A peer can simply pretend to be old, read slowly, and grow the queue without limit at up to 2 MB per hour inbound and 5 MB per hour outbound. Nodes running with -blocksonly are “much less affected”, because transaction announcements are the bulk of what piles up. This one was found by Loupe on 15 September, and independently re-found by developer L0rinc on 21 September.

Low severity covers the third: a bookkeeping failure that turns into a shutdown. Undo data, the record of which coins a block spent, is stored in rev*.dat files that were capped only by a 32-bit position counter. A miner can build valid blocks whose undo data is far larger than the blocks themselves and push a single undo file past 4 GiB, at which point the position wraps, newer undo data overwrites older, and the file is truncated. If a reorg later disconnects an affected block, the node cannot read its undo data and shuts down; a restart does not help, only a -reindex with fixed software. On Windows and 32-bit systems the file-positioning calls cap at 2 GiB, so the node fails to write instead and dies on every restart, needing roughly half the data and no reorg at all. The advisory calls exploitation impractical on 64-bit systems and notes that 32-bit systems and nodes storing blocks on FAT32 remain affected even after upgrading. Storing file positions as 64-bit integers fixed it, with 64-bit positioning calls on Windows and the on-disk format unchanged.

No CVE identifiers appear in the three advisories, and the report from Marty Bent’s team states none had been assigned as of disclosure. That is a deliberate consequence of the new policy, and it is the first place where the fast lane collides with the world outside it. Enterprise vulnerability management runs on CVE identifiers: scanners key on them, ticketing systems sort on them, auditors ask for them. A fix that ships with a release note and an advisory but no identifier is louder to developers and quieter to the compliance machinery that decides when a bank’s infrastructure gets patched.

The scanner found one of these forty-one days before the patch

Here the public narrative and the primary record diverge, and the divergence is the most useful thing in the whole disclosure.

The stories that ran on 29 October describe a five-day turnaround from model finding to patched release. For the TCP bug, that is exactly what the timeline says. For the pre-BIP 31 bug, the same scanner, the same validation path and the same reporter sat on a known, reportable issue from 15 September until Antoine Poinsot opened a mitigation on 26 October. Forty-one days. The bug was not secret because nobody could find it. It was unfixed because the fix was scheduled alongside a release train, and the release train was scheduled for the end of October.

Two bugs from the same scanner, 41 days apart

That gap is not a scandal; a memory-exhaustion bug that needs a deliberately malformed peer over weeks is not the same emergency as a one-packet crash. But it does show which constraint the new policy actually removed. The policy removed the embargo, the deliberate wait between a fix and the telling. It did not remove the coupling between a fix and a release, because a backport still has to be built, tested and shipped for four maintained branches at once. Five days was fast because the release was already near. Move the same discovery to three weeks after a major release and the arithmetic changes.

So read the five-day number as a lower bound on what is achievable and not as a description of the steady state. The steady state is: discovery is now cheap and continuous, triage is human, and shipping is periodic. Only the first of those three got a policy change this month.

The fleet

Versions are public. Nodes announce their user agent, and the snapshot of reachable nodes taken on the morning of 29 October at 07:26 UTC listed 18,209 addresses. Of those, 1,926 reported a Bitcoin Knots build, a separate implementation with its own release cadence. Those are counted separately because this snapshot cannot establish their patch status, which leaves 16,283 Core-identified nodes.

Of those 16,283, 568 ran a patched release: 201 on 32.1, 267 on 31.2, 17 on 29.5, 11 on 30.4, and the rest on patch-level builds that report a recognised version string. That is 3.5 per cent. Another 10,750 nodes, 66.0 per cent, ran a branch without the fix: 8,080 on 31.1.0, 1,226 on 31.0.0, 510 on 30.2.0, 384 on 30.0.0, 87 on 32.0.0, a tag that the project never fully announced. And 4,965 nodes, 30.5 per cent, ran 29.4.0 or older, which is now end-of-life and will never receive these backports.

Bitcoin Core version distribution, own count of 16,283 nodes

What matters is not 3.5 per cent against zero. It is 3.5 per cent against the 66.0 per cent that could patch today with a download and a restart, and against the 30.5 per cent that cannot patch at all without a version jump. A backport strategy aimed at “every maintained version” is a strategy aimed at two thirds of the network at best, and the third that is out of maintenance is the third that has been out the longest, which is usually the third that is hardest to reach.

There is a version of this argument that overstates the danger, and it deserves the space. Bitnodes reports user agents, not operating systems, and the worst bug is a non-Linux bug. The reachable-node sample is biased: listening nodes on datacentre addresses over-represent Linux, while desktop wallets and small home nodes on Windows and macOS under-represent themselves because they sit behind NAT and never accept inbound connections. Most of the 8,080 nodes on 31.1.0 are almost certainly Linux machines following an upgrade cadence measured in quarters, and for them the TCP bug is a non-event. A crashed node is also not a stolen wallet: none of the three bugs moves funds. The realistic harm is a node that stops validating and relaying, which matters if that node anchors payments or a Lightning channel’s view of the chain, and matters not at all if it is a hobby node that gets restarted on a Saturday.

Grant all of that and one part of the measurement still stands. The pre-BIP 31 bug affects Linux, and the undo-file bug leaves 32-bit systems and FAT32 volumes permanently exposed even after upgrading. The comfortable reading, “Linux is fine”, only covers the loudest of the three. The quiet two are the ones that will still be in the field in a year.

The loss ledger and the wage

The reason to take the scanner question seriously is that 2026 already has a bill attached to it. A tally compiled for Bitcoin Magazine by Lightning.news, drawing on a list of protocols hacked for more than $50,000, puts net crypto losses after freezes and returns at roughly $2.35 billion across 230 protocols this year, with about $768 million of it in September alone. The concentration is the point: the largest single loss, Bitget’s drain of roughly $387.5 million on 24 September, came from hot and warm wallets and was attributed by Chainalysis, Elliptic and TRM Labs to North Korean actors who injected withdrawal commands through third-party security products without touching private keys. The second largest, Blockstream’s Liquid network in early September, was an Elements bug that minted about 4,000 unbacked L-BTC and pegged them out for roughly 4,000 bitcoin, near $320 million at the time; the self-described white hats returned 3,400 BTC and kept about 600. No federation keys were compromised. Samson Mow has described the episode as part of an “avalanche of AI-assisted attacks”. That is his characterisation, not an established finding, and it should be read as one.

Hardware wallets, for all the noise around them this year, are a smaller line item in that ledger. Galaxy Research puts the Coinkite RNG losses at roughly 1,596 to 1,789 BTC, on the order of $100 to $130 million. The pattern that holds is that value concentrates where the number of humans who must be persuaded is smallest: one exchange’s hot wallet, one bridge’s single verifier, one sidechain’s software bug. An LLM scanner does not change that geometry. It lowers the price of finding the door.

The gate is the new embargo

The same week produced the mirror image of this problem, and almost nobody connected the two. Google DeepMind released Gemini 4 Carbon, a frontier model positioned on cybersecurity, reporting 88.2 per cent on SEC-bench Pro for vulnerability finding, 54.8 per cent on ExploitGym for exploitation and 71.0 per cent on CWE-bench for patching. It went to first place on the rebuilt Artificial Analysis Intelligence Index v5 with a score of 59.

It was not released to the public. Carbon went first to vetted defenders through Google’s Fairwind Program, with wider developer access promised “as soon as possible”.

Read that against the Bitcoin Core decision. In October the Bitcoin Core project concluded that keeping a fix secret from people who can rediscover it with a prompt is worse than publishing it, because secrecy only delays the defence. Google reached the same conclusion from the other side and drew the opposite inference: if a model makes rediscovery cheap, restrict the model. Both answer the same question, who gets the capability first, and both buy the same commodity. Bitcoin Core bought five days. Google bought whatever a gated release buys, which is the time until an equivalent capability exists outside the gate.

That interval is measurable, and it is not generous. On the same index where Carbon scores 59, the strongest open-weight model listed, Kimi K3.1 Pro, fell from 55 to 46 in the v5 rebuild, and DeepSeek V4.1 Flash and GLM-5.3 both sit at 32. One observer quoted in the same roundup puts the US–China frontier gap at about 3.3 months. Three months of gate, three months of open-weight catch-up: roughly the length of the embargo Bitcoin Core just abolished, arrived at from a completely different direction.

Artificial Analysis Intelligence Index v5, as reported this week

Gating a model is a disclosure policy wearing different clothes. It assumes capability is the scarce input, that the gate holds, and that defenders use the head start better than attackers use the leak. The Bitcoin Core experience says the first assumption is wrong in an important way: capability is not scarce any more, and the scarce things are validation, shipping and installation. Google’s gate cannot supply any of the three.

Why this week’s numbers can be checked at all

There is a reason this argument can be made with numbers instead of adjectives, and it is not that the security world is better run than the AI world. It is that security claims have a falsifier. A memory bug either crashes the node or it does not; a version string either appears in a peer’s handshake or it does not. The advisory published on 28 October can be wrong about severity, but it cannot be wrong about the mechanism. Someone can rebuild the exploit in an afternoon and settle the question.

Debate about measurement in AI has no such floor, and this week showed the strain. The v5 index that put Carbon first runs 60 per cent on private test sets, weights four pillars at 25 per cent each (knowledge work, coding, science, general) and produces a single number that decides who leads a trillion-dollar market. Nathan Lambert’s summary of the trade-off is the most honest sentence written about it: “Hill-climbing is easy, knowing what to hill-climb is hard.” A benchmark that reduces to one number is useful precisely because it is a lossy compression of everything that cannot be reduced to one number.

The two fields also share a denominator that dwarfs both. GitHub’s Octoverse numbers, announced this week, put merged pull requests at 220 million per month, commits at 7.38 billion per month and new repositories at 30.3 million per month, each roughly tripled in a year. That is the surface an LLM scanner now reads. Project Loupe found a remote crash in the most-reviewed open-source codebase in existence because someone pointed a model at a codebase that no human team would ever read line by line. There are now orders of magnitude more code than there are reviewers, and the scanners are the only thing arriving at the ratio.

Which is why the failure mode of the next year is unlikely to be a bug nobody found. It will be a bug everybody found, fixed in five days, and still running on half the network because nobody upgraded.

What is actually testable from here

Three things, and each has an address.

First, the version distribution. The claim embedded in the new policy is that fast disclosure is safe because operators keep up. That claim is falsifiable in thirty days by re-reading the same snapshot: if the 31.1.0 cohort of 8,080 nodes is still there in mid-November, the policy outran the people it was designed to protect, and the trade it made, no embargo in exchange for a shorter exposure window, did not deliver the shorter exposure window.

Second, the CVE question. If the next easily-discoverable advisory also ships without an identifier, watch whether institutional operators respond at the same speed. The absence of a CVE is a silent filter: it does not stop a developer, it stops a scanner.

Third, whether the gate holds. If a model matching Carbon’s cyber scores appears in open weights before Google widens access, then the Fairwind Program bought less time than the old embargo did, and the argument that capability must be rationed loses its main empirical support. If instead the gate lasts a year, the opposite conclusion follows, and the case for keeping exploit-capable models out of general circulation gets stronger than most open-source advocates would like.

The macro backdrop did not change any of this, which is itself the point. The Federal Reserve left the target range at 3.75 to 4 per cent on 28 October by a 10–2 vote, with Governor Lisa Cook and Cleveland Fed President Beth Hammack dissenting in favour of a quarter-point increase. Bitcoin Magazine notes that it is the first time since 1992 that a governor and a regional president have dissented together on the same side. The statement dropped its forward-looking language about when a hike might restore 2 per cent and replaced it with a promise that “the accumulation of more information will help the Committee determine the policy stance.” Bitcoin traded near $81,478 at the time of writing, about a third below its October 2025 record near $126,000, and spot ETFs took in $110 million on 26 October and $176 million on 27 October.

Money was moving into the asset on the same days that the software securing it was being fixed and not installed. Both of those are rational at the level of a single actor: the buyer is pricing a five-year horizon, the node operator is pricing a weekend. The aggregate is the problem. A monetary network that markets itself on verification cannot outsource verification to a model that reads faster than its operators install.

The patch is not the upgrade. Everything the new disclosure policy got right concerned the patch.

Sources

Write a comment