Bitcoin entered BIP-110’s final ordinary 2,016-block window on July 25 with miner support at 0.89%. The proposal requires 1,109 blocks, or 55%, for ordinary lock-in, and its mandatory version-bit phase can begin in August if support stays below that threshold.
Jameson Lopp has framed Consensus Cleanup, covenants, and quantum preparation as Bitcoin’s next agenda. He also occupies two sides of that transition: Lopp opposes BIP-110 and co-authored BIP-361, a draft plan for post-quantum migration.
BIP-110 gives those debates a live governance reference because developers, miners, node operators, exchanges, custodians and holders each supply a different form of consent. The next proposals attach that coordination test to block validation, theft-resistant custody and the ownership status of vulnerable coins.
Known bugs enter the upgrade queue
Consensus Cleanup combines four protocol repairs in BIP-54. Antoine Poinsot and Matt Corallo completed the specification in May, and Bitcoin Inquisition has run the rules on its experimental signet since February.
The package covers the timewarp attack, extreme block-validation costs, a Merkle-tree ambiguity involving 64-byte transactions, and future duplicate-transaction checks.
The timewarp flaw gives majority hash power a route to drive mining difficulty toward its minimum within 38 days, pulling subsidy forward through faster block production and altering miner incentives.
A separate weakness is that specially crafted blocks can take several minutes on high-end hardware and hours on weaker machines.
BIP-54 caps signature operations per transaction, cutting the worst-case validation burden by a factor of 40. It also invalidates a 64-byte transaction form that miners have treated as nonstandard since 2019 and that Bitcoin last recorded on-chain in 2016.
Because those repairs tighten consensus validity, review centers on edge cases across the specification, reference code, test vectors, and months of signet use. An extended delay would leave four documented weaknesses in the protocol and increase the likelihood that a future attack would compress the review schedule.
Consensus Cleanup gives Bitcoin a maintenance test with defined faults and measurable remedies, allowing approval to demonstrate that the network can process defensive protocol work through ordinary review.
Prolonged delay would convert known weaknesses into accumulated technical debt.
| BIP-54 repair | Risk addressed | Practical impact | Forward-looking question |
|---|---|---|---|
| Timewarp fix | Majority hash power can push difficulty toward minimum | Could accelerate block production and pull subsidy forward | Can Bitcoin close known incentive bugs before they become exploitable? |
| Validation-cost limits | Crafted blocks can take minutes or hours to validate | Weakens low-resource nodes and increases propagation risk | Does the network prioritize worst-case resilience before attack pressure rises? |
| 64-byte transaction rule | Merkle-tree ambiguity from special transaction format | Removes a class of historical consensus ambiguity | Is preventive cleanup easier before the edge case becomes weaponized? |
| Duplicate-transaction cleanup | Future BIP-0030-style validation concerns | Reduces legacy exception handling | Can Bitcoin simplify consensus without triggering coordination backlash? |
Covenants move into active testing
Bitcoin Inquisition activated BIP-446’s OP_TEMPLATEHASH on July 27 at signet block 314,928. The opcode lets a Tapscript commit to the exact transaction that can spend an output, giving wallets and second-layer systems a covenant primitive.
A vault uses that primitive via a first transaction that announces an attempted withdrawal and creates a delay during which the owner can redirect funds to a safer address or block the thief’s payout.
Current constructions can use presigned transactions and destroyed signing keys, an operational model that becomes fragile across large balances and long storage periods.
BIP-448 proposes a three-opcode Tapscript package that combines OP_TEMPLATEHASH with OP_CHECKSIGFROMSTACK and OP_INTERNALKEY.
Gregory Sanders, Antoine Poinsot and Steven Roose connect the package to rebindable transactions, simpler payment channels, multiparty Lightning designs, statechains and Ark variants.
Reviewers can compare a standalone TEMPLATEHASH activation, with its smaller review surface and earlier vault tooling, against BIP-448’s broader payment-system support and lower chance of another soft fork.
A longer testing period keeps current consensus rules in place and extends reliance on custodians or fragile presigned constructions.
For holders, covenant policy determines how much control a wallet can encode before funds leave an address.
Vault delays, recovery paths, and restricted-spending templates could strengthen self-custody and keep control outside exchanges, ETFs, or professional custodians.
| Proposal | Core change | Main use case | Trade-off |
|---|---|---|---|
| BIP-446 / OP_TEMPLATEHASH | Lets Tapscript commit to the spending transaction | Vaults, recovery paths, restricted spending | Smaller review surface, but narrower capability |
| BIP-448 package | Combines OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK, and OP_INTERNALKEY | Payment channels, multiparty Lightning, statechains, Ark variants | Broader utility, but larger consensus-review burden |
| No covenant activation | Keeps current consensus rules | Presigned vaults, custodial controls, existing wallet models | Avoids soft-fork risk, but leaves self-custody tools weaker |
Quantum migration sets the ownership deadline
BIP-361 places the largest coordination task on a five-year clock. The draft would stop creation of new quantum-vulnerable outputs around three years from activation, then nodes would tighten verification for legacy ECDSA and Schnorr spending paths around year five.
Phase B would require a quantum-safe rescue protocol for legacy spends, although the draft does not yet specify a single rescue design.
That timetable would require exchanges, custodians, wallet providers, and individual holders to move funds into a post-quantum output type. Owners who do not migrate by Phase B would need to meet the new rescue conditions.
By placing ownership guarantees inside the security design, BIP-361 aims to block a quantum operator from sweeping exposed coins through legacy spend paths. Owners who miss the window could face added recovery friction, and any rescue mechanism would require rules for proof design, privacy, fraud controls, and dormant funds.
| Phase | Approximate timing | What changes | Who must act |
|---|---|---|---|
| Activation | Year 0 | Quantum migration clock starts | Developers, node operators, wallet providers, exchanges, custodians |
| Phase A | Around year 3 | New quantum-vulnerable outputs would stop being created | Wallets, exchanges, payment processors, custodians |
| Phase B | Around year 5 | Legacy ECDSA/Schnorr verification would be tightened with quantum-safe rescue rules | All holders with vulnerable outputs |
In the bull case, the BIP-110 process produces clearer standards for network readiness. BIP-54 receives concentrated review, covenant proposals gain comparative signet data, and quantum planning receives a multi-year implementation runway.
Wallets gain stronger theft controls, nodes gain tighter validation bounds, and custodians gain time to inventory vulnerable outputs.
In the bear case, the spam dispute turns each soft fork into a factional contest. Consensus Cleanup stays on signet, covenant work fragments across competing opcode packages, and post-quantum policy waits for a nearer cryptographic threat.
Bitcoin then carries known bugs, weaker self-custody tools, and a compressed migration schedule into the same governance process.
BIP-110’s August window will create a single record of Bitcoin governance, and Consensus Cleanup, covenants, and BIP-361 will extend that record into maintenance, custody, and cryptographic survival.
Bitcoin’s path now depends on identifying which protocol proposals protect its core functions and building consent before emergency conditions set the timetable.
