The Embargo Was Priced in Expertise

Bitcoin Core shortened its embargo for bugs a prompt can find. The same repricing shows up in PHP, in an Ethereum fork cancelled four days out, and in a difficulty chart that kept climbing while the miners left.
The Embargo Was Priced in Expertise

The Embargo Was Priced in Expertise

At 18:07 UTC on Thursday, 22 October, a message of roughly three hundred words arrived on the bitcoin development mailing list under the subject line “Bitcoin Core security policy update.” It contained no CVE number, no patch, no disclosure of any particular vulnerability. It changed the price of a secret.

Antoine Poinsot wrote that the project “recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered,” and put the cause plainly: “This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.”

Then he named the tradeoff that every security policy hides behind procedure. “Any security policy is going to make a tradeoff between two goals that are in tension: transparency and giving users sufficient time to upgrade.” Bitcoin Core, he wrote, had chosen the second goal, because of “the nature of our project, coupled with a slow upgrade culture.” The price of that choice was structural: security fixes “can’t be backported, and only become available with users along with the next major release.” For the class of bug that a prompt can find, he concluded, “this is the wrong tradeoff.”

The new rule is almost banal in its mechanics. During triage a bug may be flagged as easy to discover; for those, a fix is backported to every maintained release, a release is cut as soon as possible, and some details go out in a security advisory at the same moment. Everything else keeps its old clock. Low-severity bugs are disclosed two weeks after the major release carrying the fix; medium and high two weeks after the last affected release reaches end of life, typically a year later; critical bugs never enter the written policy at all and are handled case by case, as Marty Bent summarised on 23 October. Bent’s date is a day off — the mailing-list message is timestamped 22 October, 18:07 UTC — and the discrepancy is worth flagging, because the entire argument is about timing.

What moved is not the software. It is one input to a decision that has always been economic and has never been written down as such.

Two horizontal timelines: under the old policy an operator waited a mean of 186 days to install a fix while the public learned what the fix was at 379 days, whereas a bug classed as easily discoverable is patched and its advisory published on the same day

An embargo is a wager on the cost of looking

Strip away the procedure and a disclosure embargo is a bet between two prices. On one side sits the cost of rediscovering the flaw, which falls on whoever wants to exploit it. On the other sits the cost of delay, which falls on every operator still running the flaw. While rediscovery is expensive, keeping the secret buys defenders time they cannot buy for themselves. Once rediscovery is cheap, the same silence charges the delay to the people it was meant to protect.

Bitcoin Core’s old policy was a deliberate bet on the first price being high. The reasoning was sound when it was written: to turn a known-but-secret fix into an exploit, an attacker had to find the commit, understand what it patched and reconstruct the attack from cryptographic and systems knowledge. That barrier is not a wall, it is a wage. It sets how many hours an adversary must pay for, and therefore how many adversaries can afford the work at all.

The second price is measurable, and the project has never had to quote it. From the release tags themselves — a plain query against the public repository, run on the morning of 23 October — the interval between consecutive major releases is 192 days from 28.0 to 29.0, 181 from 29.0 to 30.0, 189 from 30.0 to 31.0, and 184 from 31.0 to the 32.0 tag cut on 21 October. The mean is 186.5 days. That is the number that used to define the delay: a fix that could not be backported waited for the next major train, on average roughly half a cycle and at worst a full one, before an operator could install it.

Then the disclosure clock began, and it was slower still. Two weeks after the major release for a low-severity bug is tolerable. Two weeks after end of life for medium and high is not a week or a month — it is about a year after the fix existed, according to the tier structure Bent describes. During that year the fix was published in source form, which means a diff was public, which means the only thing standing between the diff and an exploit was the wage again.

Two prices, one policy. The policy assumed the wage was high. The past year has been an experiment on the wage.

Two teams, one engine

The clearest evidence this year did not come from a policy document. It came from PHP.

Researchers disclosed two memory-corruption flaws in the PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619, in PHP’s internal handling of out-of-memory conditions and fatal errors — not in a CMS plugin, not in an application’s authentication layer. The published demonstrations described pre-authentication remote code execution against WordPress, Drupal and Joomla, and memory disclosure against PHP applications generally. The coordinated response ran for about two months across the ecosystem, and one of the two discovery teams was a researcher with a model in the loop: Ryan Austin of the security firm Calif, working inside OpenAI’s “Patch the Planet” programme, used GPT-5.6 Sol in August 2026. Wiz, recently acquired into Google Cloud, independently found the same vulnerabilities using Gemini 4 Argon, GPT-5.6 Sol and its own Atlas tooling, as Latent Space’s AI news summary recorded on 22 October.

The careful reading matters here, and the same summary supplies it: these are researcher-reported exploit results, and they should not be expanded into a claim that every PHP deployment carried an identical, immediately exploitable path. “Seventy percent of the web” is a headline about the installed base of an interpreter, not a measurement of exploitable hosts.

But the coordination problem is the interesting part. Two unconnected teams, working with commercial models, converged on the same interpreter-level defect within weeks of each other. When independent rediscovery becomes routine, the value of a secret does not decay gradually. It collapses at the moment the second team arrives, and no one holding the secret can see the second team coming. An embargo is only as strong as its least observable leak, and a language model with a good prompt is a leak that leaves no trace in the repository.

There is a counterweight, and it is the part most commentary skips. Discovery got cheap for defenders as well. A preprint on the same day, Self-Evolving Static Analysis via LLM Pseudo-Labeling, describes an agent that starts with no detection rules for a language and evolves a set of readable queries, receiving feedback only from a second model acting as critic — no access to ground-truth labels at any point. It reached a mean F1 of 0.742 across eight independent runs on the OWASP Benchmark for Python, above the default configurations of five widely used tools, and comparable to the strongest of those tools once that tool was tuned with the ground truth the agent never saw. In a pilot on real Python projects, rules induced from code written before a vulnerability existed detected 10 of 19 subsequent CVEs, nine of them with rules written for the same repository.

So this is not a story about attackers gaining a permanent edge. It is a story about a specific asymmetry dissolving: the one between the person who knows where to look and the person who could look if it were cheap. Once both sides can look, secrecy stops being a subsidy to defenders and becomes a delay levied on them. That is exactly what Poinsot wrote, in fewer words, to a mailing list at 18:07 on a Thursday.

The check that cancelled a fork

Five days before that message, the same repricing ran in the other direction, and the bill landed on a release schedule.

Ethereum developers called off the Glamsterdam upgrade’s activation on the Hoodi testnet four days before it was due to go live, as Unchained reported on 22 October. The trigger was an analysis published on 13 October by the security firm ChainSecurity covering EIP-8037 and EIP-8038, two proposals that change how the network charges gas for creating and accessing state. Their warning was not about a bug in anyone’s contract. It was about contracts nobody would edit: “Even with unchanged contract code, a failure path that previously reverted can now complete,” and continuing down that path “can turn a retryable operation into a permanent failure.”

Read that sentence twice, because it is the general case. The code did not change. The ground under it changed. A failed call that used to revert now completes, which means every contract that assumed a revert — every retry loop, every fallback, every accounting path written against the old gas semantics — inherits a behaviour it never agreed to. Besu developers merged a pull request titled “Unschedule Amsterdam on Hoodi” on 22 October, and as the report notes, merging code does not update nodes already running the old build.

Two lessons sit in that sequence, and they pull opposite ways. The good one: a security check that would have been too expensive to run two years ago now runs early enough to stop a fork four days before launch. The bad one: the check found something, and the cost of finding it landed on everyone downstream, at the worst possible moment, with no time to spare. Cheap discovery does not only devalue secrets. It also devalues schedules. A world in which looking is free is a world in which every deadline is provisional, and the teams that plan releases as fixed dates will keep discovering, late, that their dates were never theirs.

That is the honest cost of the Bitcoin Core change too, and Poinsot names it in the same message: fixes now get backported and released “as soon as possible,” which is a promise about someone’s weekend.

The one input a model cannot discount

If the cost of looking collapses everywhere, the interesting question becomes what stays expensive. The answer this month was joules.

Bitcoin’s seven-day average hashrate crossed back above one zettahash per second on 22 October, a seven-month high last seen on 3 March, according to BlocksBridge Consulting’s Miner Weekly as reported by Bent. Mining difficulty rose 5.92 percent on 16 October, and BlocksBridge projects another 5.16 percent at the next adjustment — roughly 11.4 percent across two consecutive epochs. Both numbers moved up while the publicly traded miners were leaving.

That is the part worth pausing on. Public miners cut their realised hashrate by approximately 23 percent while growing AI and high-performance-computing revenue 52 percent quarter over quarter through the second quarter of 2026. BlocksBridge estimates the displaced capacity at about 1.5 billion dollars of mining hardware, using its own assumed purchase price of 20 dollars per terahash — an assumption the firm itself flags as an order-of-magnitude figure rather than a mark, because ASIC spot pricing has moved. The network’s response to a fifth of its public capacity walking away was to get 45 percent harder than its July low near 726 exahashes per second, per CryptoQuant data cited by Ki Young Ju.

Three arithmetic consequences follow, and they are mine, not the sources’.

First, difficulty times 2^32 divided by 600 gives hashes per second, so one zettahash per second at ten-minute blocks implies a difficulty near 139.7 trillion. That is the scale at which the two published numbers are consistent with each other.

Second, revenue per unit of hash falls with difficulty when the price does not move. After a 5.92 percent and then a 5.16 percent upward adjustment, the same machine with the same electricity bill earns 89.8 percent of what it earned before — a 10.2 percent cut, applied to every operator on the network, in the same fortnight in which a quarter of the public fleet decided the trade was no longer worth making.

Third, and this one requires a stated assumption rather than a measurement: one zettahash per second at 15 joules per terahash is 15 gigawatts of continuous draw; at 20 it is 20; at 25 it is 25. I do not know the fleet’s real average efficiency, and neither does anyone publishing a headline number, so treat the range as a sensitivity check on an order of magnitude rather than a figure. Tens of gigawatts, running without interruption, to maintain a ledger that a laptop can verify. I would rather publish the assumption than defend a headline figure, and the assumption is the only soft number in that sentence.

Diverging bars: difficulty up 11.4 percent over two epochs and network hashrate up 45 percent from its July low, against public miners’ realised hashrate down 23 percent and revenue per hash down 10.2 percent, with AI and HPC revenue up 52 percent quarter over quarter

Why that matters to a policy argument is the shape of the demand on the other side of the fence. Erik Bernhardsson, whose company Modal crossed one billion dollars in annualised run rate and raised 750 million dollars at a 16 billion dollar valuation, describes GPU demand as anything but rectangular: a capacity contract gives a customer a fixed number of chips for a fixed period, and real workloads grow, spike and fall through the day. His business is a duration transformation — pool thousands of customers so the aggregate is smoother than any single one, and carry the risk that the capacity you locked in at today’s price becomes expensive if prices fall. Sandboxes, the product that almost got shut down, are now roughly a third of revenue.

Put the two industries side by side and the migration makes sense as a trade, not a fashion. Mining offers a fixed, verifiable payout per hash and a difficulty that rises whenever anyone else is willing to lose more money than you. Inference offers a spiky, contract-shaped revenue stream with a residual risk on the hardware price. Capital went where the demand curve was less rectangular, and the difficulty chart did not care, because if that reading is right, the machines that stayed are cheaper to run than the ones that left — the secondhand Antminer S21 XPs advertised through hosting facilities in Paraguay and Texas are the visible edge of that.

Measure the joules, not the operator

Which brings the argument full circle, because the newest idea in AI governance is the oldest idea in bitcoin.

A preprint posted on 23 October, Detecting AI Training in Datacentre Power, asks how a regulator can tell whether a monitored computing cluster is training a large model without trusting the operator. The method is not a software attestation and not an audit. It reads facility-level power and tracks the wandering cadence of training iterations with a Viterbi tracker. On simulated datacentre power, with the operator making no attempt to hide, it detects at least 96 percent of training runs against a declared inference workload at a 1 percent false-alarm rate, within 0.04 of the Neyman–Pearson optimum, provided the meter samples at 2 hertz or faster.

The adversarial half is the part that makes it an argument rather than a demo. Of eight strategies an operator might use to hide, only extreme variation of the work per iteration evades the tracker. Its strongest form hides training in up to 73 percent of five-minute observations, but over a day at least 87 percent of such runs are still caught, at a 0.1 percent false-alarm rate per run. That evasion costs no throughput, but in small-scale training the operator needs 93 to 267 percent more compute to reach the same loss. The authors’ conclusion is deliberately modest: a passive meter is enough to make hidden training both detectable and expensive.

Substitute one word and you have the design of proof-of-work. Replace power with hashes, replace the iteration cadence with the nonce, replace the meter with every node on the network. Bitcoin’s answer to “how do I know this was produced honestly” has never been “ask the producer.” It is “the production left a physical trace that is expensive to fake and cheap to check.” The paper is that principle applied to the thing everyone assumed was unmeasurable, and it arrives in the same week that the most conservative security policy in the industry conceded that the cost of looking had fallen through the floor.

What this leaves an operator holding

The practical consequence of Poinsot’s change is smaller than the argument and sharper than the coverage. Minor releases are no longer housekeeping. Under the old policy, a point release mostly meant fixes you could install at your convenience; under the new one, a point release may carry an advisory published at the same time, which means the interval between “the fix exists” and “everyone knows what the fix was” is now approximately zero for one class of bug.

That converts version discipline into a security control with a deadline attached, and the deadline is not negotiable by the operator. It also makes the release feed a security feed. For scale: the project’s public release feed carries 68 published releases since November 2016, eight of them in 2026 up to 10 July, and the 32.0 tag — signed and dated 13:27 UTC on 21 October — does not yet appear in that feed as a release entry. The tag is there, the announcement is not. A node operator who watches release announcements rather than tags will always be a little behind, and this year “a little behind” acquired a price.

Four bars of the days between consecutive Bitcoin Core major releases: 192, 181, 189 and 184, with a mean line at 186.5 days

For my own part, I checked the node I run while writing this. It reports itself as /Satoshi:31.1.0/ with ten outbound connections, while the 32.0 tag exists upstream. That is exactly the position the new policy is aimed at: maintained, functional, and one major release behind the fixes that will now be published with their own advisory attached.

The morning’s prices, from my own quote feed at 09:31 CEST on 23 October, put bitcoin at 81,693.51 dollars, up 377.31 on the session; Brent at 114.47, gold at 4,027.40, the dollar index at 101.803, and the S&P 500 at 7,663.43, down 93.74 points. The Block reported the same selloff reaching Asia overnight, with the Kospi down 2.3 percent and the Nikkei 1.6 percent, and bitcoin sliding below 81,500 dollars. None of that changes the policy argument. It changes the audience, because a falling price is when operators postpone upgrades.

The steel man, and the number nobody has

The objection to the new tier is not that it is wrong. It is that it is unmeasured, and Poinsot’s own message contains the reason.

If the classification is made at triage, by the developer who knows the bug, then the policy’s safety depends on a judgement call made by the party with the least incentive to over-share and the most information about how findable the bug really is. That is a reasonable place to put the decision, and also an unauditable one. The label “easily discoverable” is a prediction about an adversary’s cost, made by someone who cannot see the adversary.

Worse, the advisory publishes a map to a population that upgrades slowly — the phrase is Poinsot’s, and it is the load-bearing admission. Under the old policy the population was slow but ignorant. Under the new one it is slow and informed, and the informed include everyone who reads a security advisory for a living. So the policy is correct if the marginal attacker who reads the advisory is slower than the median operator who patches. If the reverse holds, the faster clock has moved exposure from the patient to the careless without shortening it.

Nobody measures either number. Bitcoin Core does not publish a version-share estimate, and a sample of ten peers from one node is an anecdote. That gap is the honest state of the art: the policy has been corrected on the strength of one price — the cost of rediscovery — while the other price, the time operators actually take, remains a guess inside the same document that corrects the first.

The test is falsifiable and near. If a vulnerability in the easily-discoverable tier is exploited in the wild between its advisory and the wide installation of the release, the policy will be revised, because the project’s culture treats published process as a promise. Watch the next few patch cycles. If the releases ship fast and nothing gets burned in the gap, the bet was right. If something does, we will have learned what the second price was, the expensive way.

The residue

The through-line this week is not that machines got better at finding bugs. It is that a decade of security practice rested on a price that nobody had written down, and the price moved faster than the policy did. Bitcoin Core responded by shortening the embargo for exactly the class of bug where the wage had collapsed. Ethereum responded by cancelling a fork four days out, because a check that had become affordable had become unavoidable and then found something real. The miners responded by selling machines to anyone with cheaper electricity, and the difficulty went up anyway, because joules are the one input that no model has learned to fake.

Everything else in this business is now cheap to produce: a paragraph, a chart, a plausible research note, a diff that looks like a fix, a vulnerability report that looks like a favour. What remains expensive is the part that leaves a physical trace — a hash, a watt, a signed release, a diff someone actually read. The useful question for the next year is not which model is smarter. It is which of your inputs can still be checked by a stranger with a meter. Bitcoin Core just told you, in writing, which of its own secrets no longer pass that test.

Sources

Write a comment