Four Bugs, a Quantum Clock, and Bitcoin’s BIP-54 Fork Test

Bitcoin spent the first week of October 2026 doing what it does best: almost nothing. The price drifted around $86,000, up roughly 4% on the month after a stronger-than-expected open (Fortune clocked it at $86,682 on October 2), extending the Uptober recovery that carried it off the summer lows. Blocks kept arriving every ten minutes or so, just as they have since 2009. Underneath that calm sits a question the network has been unable to answer for almost five years: can Bitcoin still change its own rules?

The last time it did was November 14, 2021, when Taproot activated at block 709,632 (CoinDesk). Since then, every attempt to add or fix anything at the consensus layer has stalled. In August 2026, a contested proposal to restrict arbitrary data, BIP-110, entered mandatory signaling with 2.53% miner support against a 55% threshold, split off a minority chain that mined two blocks, and died. Now the next item in the queue is about to be tested, and it is the least controversial change anyone has put forward in years.

BIP-54, the Consensus Cleanup, adds no features, enables no new app, and carries no ideology. It fixes four old bugs. And it is already stuck, because one large mining pool has said it will not help activate it. The reason this boring, feature-free fork matters far beyond its four fixes is simple: it is a live test of whether Bitcoin’s upgrade machinery still works at all, and the clock running in the background is not BIP-54’s. It is a quantum clock.

What BIP-54 actually is

The idea is old. In 2019, developer Matt Corallo proposed a Great Consensus Cleanup: a bundle of narrow fixes for known weaknesses in Bitcoin’s consensus rules, deliberately stripped of anything that would add capability or spark an ideological fight. It went quiet for years. In late 2023, Bitcoin Core contributor Antoine Poinsot, who signs his work as darosior, picked it back up and spent two years turning it into a formal specification. The proposal received its BIP number, 54, in April 2025, and the text reached its final form in 2026, when Poinsot opened a Bitcoin Core pull request implementing it without any mainnet activation logic (bitcoin/bitcoin #35793).

That last detail is the whole philosophy. Poinsot wrote the code that enforces the new rules but left out the switch that would turn them on, so the network can review, test, and argue before anyone commits to a date. Announcing the pull request, he described the effort as one that had, since work resumed in late 2023, “slowly matured into a robust proposal” covering several long-standing quirks in Bitcoin’s consensus protocol (via X). He has been equally clear that none of the bugs it fixes is an immediate, existential threat, and that there is no rush, a framing meant to lower the temperature rather than raise it.

The specification is feature-complete and already running where developers test things that are not yet on mainnet: Bitcoin Inquisition, a patched version of Core used on the signet test network, enforces BIP-54’s rules today (bip54.org). The point of a cleanup is to be uncontroversial by construction, which is exactly why it makes such a clean experiment. What follows is a tour of the four weaknesses it closes, because the details explain both why engineers think the fork is overdue and why a single mining pool can still say no.

Bug one: the timewarp attack

Bitcoin retargets its mining difficulty every 2,016 blocks, roughly every two weeks, by comparing the timestamps of the first and last block in the window. The timewarp attack abuses the fact that those timestamps are only loosely policed. A miner, or a coordinated group, controlling a majority of hashrate can set the final block of a period far into the future and the first block of the next period far into the past, making each window look longer than it really was. Difficulty then ratchets downward, period after period, until blocks can be produced far faster than the intended ten-minute average.

The consequences are not subtle. Analyses of the attack describe a scenario where the attacker eventually mints several blocks per second and drains the remaining block subsidy in a matter of weeks, while every protocol that relies on Bitcoin’s clock, Lightning channels, timelocked vaults, and anything using nLockTime, loses its sense of time (bip54.org). It requires majority hashrate, which is why it has never been executed, but a latent rule that holds only because nobody has chosen to break it is exactly the kind of thing a cleanup is meant to remove. The danger is structural, not hypothetical: the code permits it.

BIP-54’s fix is small. It imposes timestamp limits on the first and last block of each difficulty period so the clock cannot be dragged around. The same rule also neutralizes a subtler cousin documented more recently, the Murch-Zawy attack, named for Bitcoin researchers Mark “Murch” Erhardt and the difficulty-adjustment analyst known as Zawy (Bitcoin.com). Ordinary mining is untouched; only the manipulative edge cases become invalid. Nobody mining honestly today would notice the change at all.

Bug two: poison blocks

Before SegWit arrived in 2017, Bitcoin’s scripting system had no clean limit on how much work a single transaction could force a validating node to do. A legacy transaction can be crafted so that checking its signatures involves a punishing amount of computation, and because that cost grows quadratically with size, an attacker can assemble a block that takes a normal computer hours to verify. Such a block is sometimes called a poison block: valid by the rules, but slow enough to knock nodes offline, open them to eclipse attacks, and quietly push the network toward whoever owns the fastest hardware.

That last effect is the one that worries decentralization-minded developers most. A validation bottleneck does not just inconvenience a hobbyist running a node on a cheap mini-PC; it hands a structural advantage to large, well-provisioned operations that can chew through a poison block while everyone else falls behind. Over time, pressure like that is how a peer-to-peer network quietly concentrates.

BIP-54 caps the number of legacy, pre-SegWit signature operations a transaction may contain at 2,500. Supporters estimate the limit could cut the worst-case verification burden by roughly 40 times in some scenarios (Bitcoin.com), which matters most for the people running Bitcoin on modest machines, the very decentralization the network depends on for its censorship resistance. The transactions that would hit the new cap are exotic and essentially never appear in normal use, so the practical cost to honest users is close to zero.

Bug three: the 64-byte transaction trap

This one is a geometry problem. Bitcoin stores the transactions in a block as a Merkle tree, a structure built by hashing pairs of 32-byte values together. An internal node of that tree is therefore exactly 64 bytes: two 32-byte hashes side by side. It turns out a real Bitcoin transaction can also be made exactly 64 bytes long. That coincidence lets an attacker construct a proof that an internal tree node is actually a transaction, or the reverse, and feed a fake inclusion proof to a client that only checks Merkle paths rather than downloading full blocks.

The victims here are Simplified Payment Verification (SPV) wallets and any system that trusts SPV-style proofs, a category that quietly includes some cross-chain bridges and light-client designs. Estimates put the work needed to forge such a proof at around 70 bits (bip54.org), uncomfortably within reach for a well-resourced attacker, and the failure mode is a wallet or bridge accepting a payment that was never actually confirmed. That is precisely the class of silent, verification-layer assumption that tends to break cross-chain security long before anyone audits it, as HOGE Wire has documented elsewhere. BIP-54 closes the hole by making 64-byte transactions invalid outright; they have been nonstandard and effectively unused for years, so nothing legitimate is lost.

Bug four: the duplicate-coinbase ghost

Bitcoin identifies every transaction by its hash. In the earliest days, two different coinbase transactions, the special transaction that pays a miner the block reward, could end up with identical hashes if their contents matched, and the second one would overwrite the first in the ledger’s accounting of spendable coins. This is not theoretical: in 2010, duplicate coinbase transactions in blocks 91,722 and 91,880, and again in 91,812 and 91,842, permanently destroyed roughly 100 BTC (bip54.org). Those coins are simply gone.

A 2012 rule, BIP-34, mostly closed this by requiring the block height inside each coinbase, and a companion rule, BIP-30, forces nodes to check for duplicates. But that check is expensive, and the original guarantee lapses in the distant future, with the problem able to recur near block 2,000,000, around the year 2046. BIP-54 makes the fix permanent and cheap by requiring every coinbase to commit to its block height in a way that guarantees uniqueness, which also lets future nodes retire the costly duplicate scan entirely. It is housekeeping, but it is the kind of housekeeping that prevents a very bad day decades from now, and the sort of thing a healthy protocol should be able to merge without drama.

The four fixes, side by side

Stripped of the cryptography, the Consensus Cleanup is a short list of latent risks and the narrow rules that retire them. None of the fixes changes anything a normal user or honest miner does; each one removes a sharp edge that has been sitting in the protocol for more than a decade.

The ghost of BIP-110

To understand why a harmless cleanup is in trouble, rewind to August. BIP-110, a temporary soft fork drafted in Luke Dashjr’s orbit and shipped in the Bitcoin Knots client, tried to push restrictions on arbitrary data back into consensus rules. The targets were the Ordinals inscriptions, BRC-20 tokens, and oversized payloads that Taproot’s cheaper witness space made practical, and the aim was to put the limits somewhere no single software release could quietly undo them. It used a mandatory-signaling, user-activated design: during a set window, enforcing nodes would reject any block that did not signal support.

The window opened at block 961,632 on August 8, 2026, and the proposal collapsed on contact. Miner support had peaked at 2.53% in the final voluntary period, a fraction of the 55% needed. When enforcement began, the BIP-110 chain mined exactly two blocks and then stalled; roughly 0.15% of total hashrate ever landed on it, and the main chain never so much as reorganized (Simple Mining). Bitcoin had proven, again, that it can refuse a change decisively. What it did not prove is that it can accept one.

That is the hangover BIP-54 has to work through. As Bitcoin.com put it, BIP-110 “demonstrated how quickly a disputed upgrade can become a broader argument about who should decide Bitcoin’s future” (Bitcoin.com). Every activation conversation now carries the memory of a chain split, even for a proposal nobody is ideologically against. The HOGE Wire breakdown of the 2026 self-custody shakeout made a related point from the user side: Taproot keeps enabling things at the edges while the base layer itself refuses to move.

The miner standoff: F2Pool says no

The specific obstacle has a name. On August 10, 2026, Wang Chun, co-founder of the long-running mining pool F2Pool, said the pool would not signal for BIP-54 before the change had already won a formal majority, though it would update its mining nodes if the proposal cleared the standard bar later (GNcrypto). His objection was not to any individual fix. It was to the package: bundling four separate changes into one soft fork, he argued, resembled stuffing unrelated measures into a single bill, forcing node operators to accept all of it or none.

That position is defensible on its own terms, and it is also a demonstration of leverage. Under a miner-signaling activation, a high threshold means a single large pool can withhold the votes needed to reach it, turning a process designed as a readiness poll into something closer to a veto. Pool market share, not individual-miner sentiment, is where that power lives, which is why control of hashrate routing matters as much to governance as it does to the economics of a mining day. F2Pool has been candid rather than obstructionist; Wang Chun said plainly that the pool would comply with a properly reached majority. But candor does not change the arithmetic.

F2Pool is not alone in its caution. The same reluctance that has left OP_CTV covenants parked at essentially 0% signaling (Spark), despite a live activation client whose window runs to March 2027, hangs over the cleanup too. Miners are not refusing BIP-54 because they dislike bug fixes. They are refusing to move first on anything, because moving first is where the risk and the blame live.

Who actually decides: pools, nodes, and the activation question

Bitcoin has never had a tidy answer to how rules change, only a set of imperfect mechanisms. The most common is BIP-9, in which miners flip a bit in the blocks they produce to signal readiness; cross a threshold within a window and the rule locks in. It is clean when miners agree and useless when they do not, because the threshold doubles as a veto. The alternative is a user-activated soft fork, BIP-8 and its relatives, where economic nodes enforce the new rule on a flag day regardless of miner signaling, daring miners to produce blocks the rest of the network will reject.

After August, nobody wants to reach for the user-activated hammer casually. BIP-110 was a user-activated attempt, and it produced a chain split, however brief and however lopsided. Yet pure miner signaling hands the outcome to pool operators like F2Pool. There is a technical wrinkle that complicates the pools’ grip, though. Protocols like Stratum V2 and the DATUM standard let individual miners build their own block templates instead of accepting whatever their pool hands them, which means they can set the signaling bit themselves. An ASIC simply computes hashes for whatever template it is pointed at; as the post-mortems of August stressed, a pool’s policy is not the same as its miners’ hardware (Simple Mining). In theory, template autonomy could route around a reluctant pool. In practice, almost nobody uses it yet, so the pools’ signaling monopoly holds.

It is worth saying plainly that no outside authority can settle this. Even as US spot Bitcoin ETFs now hold hundreds of thousands of coins and sit under the SEC’s disclosure regime, neither the SEC nor any regulator has a vote in whether a soft fork activates. There is no committee to lobby, no filing to make, no agency that can break the tie. Consensus rules are changed by the people who run the software, or they are not changed at all.

The 2017 shadow, and why boring is not the same as safe

Everyone involved is reading from a script written in 2017. That year’s fight over SegWit and block size ended with a user-activated soft fork, BIP-148, that effectively forced miners’ hands, a scaling-war schism that produced Bitcoin Cash, and a lasting trauma about who controls the protocol. The lesson most developers took away was that contentious activations are dangerous. The lesson some miners took away was that signaling can be weaponized against them. Both lessons now sit on top of a proposal that is not contentious at all.

This is the uncomfortable core of the BIP-54 story. If a feature-free package of security fixes, authored by a respected contributor who openly says there is no rush, cannot find an activation path, then the bottleneck was never the specific change. It is the process itself. Bitcoin’s conservatism is usually described as a feature, and for a settlement network holding well over a trillion dollars, caution is rational. But there is a difference between declining to add risky features and being unable to repair known defects. A network that can only agree to do nothing has, in effect, chosen ossification by default rather than by decision, and it has chosen it right as the one deadline Bitcoin cannot negotiate with starts to come into view.

The clock that does not negotiate: quantum

Here is why a cleanup fork is really a referendum on something much larger. A sufficiently powerful quantum computer running Shor’s algorithm could derive a private key from a public key that has been exposed on-chain. Taproot, by design, reveals the full public key in a standard key-path spend, and across reused addresses and the early pay-to-public-key era, researchers estimate that roughly 6.9 million BTC, close to a third of all coins that will ever exist, already sit in addresses a capable quantum machine could eventually drain (AMINA Bank).

The timeline keeps shortening. In research published on March 31, 2026, Google Quantum AI concluded that breaking the signatures might need fewer than 500,000 physical qubits, a roughly twentyfold cut from a 2019 estimate, with a concrete attack model needing on the order of 1,200 to 1,450 high-quality logical qubits and able to forge a competing transaction in about nine minutes (CoinDesk). Google’s own milestone for useful quantum systems sits around 2029. None of this means coins get stolen next year, and serious researchers are careful to stress the uncertainty. But it does put a horizon on a question Bitcoin has been able to ignore for its entire history.

Bitcoin’s answer in progress is BIP-360, Pay to Quantum Resistant Hash, authored by Hunter Beast and merged into the BIP repository on February 11, 2026 (Cointelegraph). It defines a new address type that builds on Taproot’s structure but removes the exposed-key spend, swapping in post-quantum signatures approved by standards bodies. A companion idea, BIP-361, goes further and would freeze provably vulnerable coins rather than let an attacker sweep them. Both are proposals, not activated rules, and both would require the single largest key migration in Bitcoin’s history, every exposed holder moving to new addresses within whatever window the network has. That migration cannot happen until Bitcoin can agree to activate a soft fork. Which is the test BIP-54 is running right now, on the easiest possible case.

Put the two stories next to each other and the stakes come into focus. One is a bundle of bug fixes almost no one opposes, stalled for lack of a yes. The other is a defensive migration that is vastly harder, politically and technically, against an adversary with a schedule. If the network struggles with the former, the latter is not a 2026 planning item so much as a hope.

The queue behind Taproot

BIP-54 is not alone in the waiting room. Nearly five years after Taproot, the list of finished or nearly finished consensus proposals that cannot find an activation path has quietly become the longest in Bitcoin’s history. The following snapshot captures where each sits in October 2026.

What a yes would take

There are only a few realistic ways out of the stall, and each has a cost. The gentlest is patience: keep the specification stable, let more operators run it on signet, and wait for miner sentiment to drift toward a routine BIP-9 vote. That is essentially Poinsot’s stated posture, that the bugs are real but not urgent, so there is room to build consensus slowly rather than force it. The risk is that patience and paralysis look identical from the outside, and that four years of quiet have already shown how long drift can last.

A second path answers Wang Chun directly: unbundle. Splitting the cleanup into separate, single-purpose forks would let the least controversial fixes, the 64-byte ban and the coinbase rule, advance on their own, at the cost of running the fragile activation gauntlet several times instead of once. A third path is the user-activated route, where economic nodes set a flag day and enforce the rules regardless of pool signaling. It worked in 2017, but BIP-110 just showed the downside, and few want to point that weapon at a fix this minor.

The fourth path is the one Bitcoin has taken by default since 2021: nothing. An indefinite stall is not neutral. Every year the cleanup waits, the latent bugs stay latent, the quantum horizon moves closer, and the muscle memory for coordinating any change at all keeps atrophying. The decision not to decide is itself a decision, and for now it is the one winning.

What it means if you hold, run a node, or build on Bitcoin

For holders, there is nothing to do today. None of BIP-54’s four bugs is being exploited, and the quantum threat is a horizon risk, not a this-quarter risk. The honest long-term takeaway is that at some point, protecting coins from a quantum attack will mean moving them to a new address type, the same move-your-own-coins discipline that defined the self-custody debates of 2026. Address reuse, already poor practice, becomes a specific liability in that future, because every spend from a reused address leaves its public key sitting in the open.

For node operators, BIP-54 is cheap. Its rules are forward-compatible, miners can already start setting the coinbase commitments the cleanup expects, and running a client that enforces the fixes costs nothing but a software update. For builders, the lesson of the past five years is the operative one: the base layer is effectively frozen, so the interesting work keeps migrating to layers that do not need a soft fork to ship, from Lightning and statechain designs to the covenant-emulating rollups trying to inherit Bitcoin’s security without waiting for its consensus. Each of those relies on exactly the primitives, Schnorr signatures, Tapscript, and MAST, that Taproot delivered in 2021, which is the quiet irony of the whole situation.

That is the paradox Taproot leaves behind. It was a genuine upgrade, and it may also be the high-water mark of base-layer change for a long time. BIP-54 will not settle the quantum question; it is far too small for that. But it will answer a smaller one that comes first: faced with a fix almost nobody opposes, can Bitcoin still say yes? The network spent early October doing nothing, as usual. For once, the nothing is the story.

Frequently Asked Questions

What is BIP-54, the Bitcoin Consensus Cleanup?

BIP-54 is a proposed Bitcoin soft fork that fixes four long-standing consensus bugs without adding any new features: the timewarp difficulty attack, hard-to-validate poison blocks, a 64-byte transaction flaw that can fool light wallets, and duplicate coinbase transactions. It was revived by Bitcoin Core contributor Antoine Poinsot and reached its final specification in 2026.

Why is BIP-54 stalled if it is uncontroversial?

Activation still requires miner support. On August 10, 2026, F2Pool co-founder Wang Chun said the pool would not signal for BIP-54 before it reached a formal majority, objecting to bundling four changes into one fork. Under a high signaling threshold, a single large pool can effectively block activation, and the failed BIP-110 fork in August made everyone wary of forcing the issue.

How does BIP-54 relate to Bitcoin’s quantum computing risk?

BIP-54 does not fix the quantum problem; the quantum fix is a separate proposal, BIP-360. But BIP-54 is a test of whether Bitcoin can still activate any soft fork. If the network cannot agree on a harmless cleanup, the far larger and more contentious quantum migration becomes much harder, and researchers estimate roughly 6.9 million BTC sit in quantum-exposed addresses.

Was BIP-54 the fork that caused a chain split in 2026?

No. The August 2026 chain split came from BIP-110, a contested proposal to restrict arbitrary data. It drew only 2.53% miner support, mined two blocks on a minority chain, and stalled. BIP-54 is a different, feature-free proposal, and no activation attempt or split has occurred for it.

When will BIP-54 activate on Bitcoin?

There is no activation date. As of October 2026, BIP-54 is specification-complete and running on test networks, but no activation parameters or signaling window have been set, and the activation mechanism, miner signaling versus a user-activated flag day, is still being debated. Any timeline depends on resolving the miner standoff.

By Marcus Okafor, HOGE Wire senior Bitcoin correspondent.