Bitcoin's next upgrades: quantum defense, silent payments, and the covenant wars
The most important thing to understand about Bitcoin protocol development is that “merged into the repo” is not the same as “happening soon.” This distinction matters a lot right now.
On February 11, 2026, BIP 360 (a formal proposal for quantum-resistant Bitcoin addresses) was merged into the official Bitcoin BIPs repository. That’s a real milestone. It means quantum defense is officially part of Bitcoin’s formal upgrade conversation for the first time. What it doesn’t mean: your Bitcoin is about to become quantum-safe. Not this year. Probably not this decade.
Let me explain what’s actually going on.
How Bitcoin changes (and why it takes so long)
Bitcoin’s last soft fork, Taproot, activated in November 2021. Nearly five years ago. Ethereum has upgraded dozens of times since. That’s not a bug in Bitcoin; it’s a design choice.
BIP stands for Bitcoin Improvement Proposal, the formal system for documenting proposed changes. Anyone can write one. Being merged into the BIPs repository means the proposal has been reviewed for format and completeness. It does not mean it’s endorsed, scheduled, or likely to be activated. Most BIPs never are.
The path from idea to activation runs roughly like this: an idea gets discussed on Delving Bitcoin or the bitcoin-dev mailing list; a BIP gets written and merged when the format passes review; community debate continues, often for years; Bitcoin Core developers consider implementation; miners signal readiness; the soft fork activates, or doesn’t.
The 2015-2017 “block size wars,” which ended in the Bitcoin Cash chain split, left a deep scar on this process. The community’s tolerance for contentious changes is extremely low. “Rough consensus” in Bitcoin means something close to near-unanimity. You can see why things move slowly, and why that slowness is a feature, not a bug.
BIP 360: quantum resistance, officially on the table
With that context established: the BIP 360 merge is still significant.
The proposal introduces a new address type called Pay-to-Merkle-Root (P2MR), with addresses starting with “bc1z” (versus Taproot’s “bc1p”). The technical purpose is to remove the key-path spend present in current Taproot addresses, forcing all transactions through a script path that relies on hash functions rather than elliptic curve cryptography. Hash functions are far more resistant to quantum attacks.
The quantum threat is specific. Shor’s algorithm, run on a sufficiently powerful quantum computer, can break the mathematical problem protecting Bitcoin private keys. The current thinking is that breaking a 256-bit elliptic curve key would require around 10^8 operations on a cryptographically relevant quantum computer. We don’t have one yet, but timelines are shortening. The US NSA’s CNSA 2.0 framework calls for quantum-safe systems by 2030. NIST plans to phase out elliptic curve cryptography from federal systems by the mid-2030s. Google’s “Willow” quantum chip launched in December 2025; Microsoft is working on “Majorana 1.”
Hunter Beast, the lead author of BIP 360 and a protocol engineer at MARA, described the scope:
“Ultimately, the introduction of BIP 360 and P2MR is a first step in a larger set of quantum-resistance proposals that will be necessary to quantum-harden Bitcoin.”
Isabel Foxen Duke, who joined as co-author specifically to make the BIP accessible to non-developers, explained the team’s communication approach:
“Given the sensitivity of the subject matter, we aimed to ensure the BIP was written in a manner that was clear and understandable to the general public.”
That clarity matters because quantum computing generates two opposite failure modes in public discussion (dismissal and panic) when the reality is more measured. The threat is real on a long enough timeline. BIP 360 is a reasonable first step. Nothing activates on Bitcoin mainnet without years more debate.
BIP 360 creates the P2MR address structure but doesn’t yet specify which post-quantum signature scheme Bitcoin would actually use. NIST has standardized candidates (ML-DSA/CRYSTALS-Dilithium and SLH-DSA/SPHINCS+) but choosing one is separate, future work. The shell is here; the cryptographic engine comes later.
Certain address types are most at risk if Q Day arrives. Early Bitcoin addresses (Pay-to-Public-Key format, used in Satoshi’s era) expose the public key directly, with roughly 1 million BTC in this format. Taproot key-path spends. Reused addresses. A companion proposal called BIP 361 is in development to address how legacy holdings would migrate.
The covenant wars: Bitcoin’s bigger internal debate
While BIP 360 is the freshest news, the longer-running fight in Bitcoin development circles is over “covenants,” and this one goes to the heart of what Bitcoin is for.
Currently, Bitcoin Script can verify who is authorized to spend a coin but not where the funds must go next. A covenant changes that: it embeds rules about how a coin can be spent in the future, following the money through multiple transactions.
The analogy: current Bitcoin is like handing someone cash. Once it’s theirs, they spend it however they want. Covenants are like a trust with conditions attached. You can inherit this, but only under certain rules.
What covenants would unlock is significant: Bitcoin vaults with time-delayed withdrawals (an anti-theft mechanism where stolen coins could be clawed back within a window), trustless bridges between Bitcoin L1 and Lightning or other L2 networks, more efficient Lightning channels, and DeFi-like features on Bitcoin without trusting a counterparty.
Two proposals lead the debate: OP_CAT (BIP 347) and OP_CTV, also called CheckTemplateVerify (BIP 119).
OP_CAT re-enables an opcode Satoshi disabled in 2010 due to memory concerns. It concatenates data, boring in isolation but powerful when combined with other opcodes. It enables complex, potentially recursive covenants, where spending conditions can propagate indefinitely. That power is exactly why critics are wary: attack surfaces, complexity, possible non-fungibility of UTXOs.
OP_CTV is more conservative: a template-based covenant that commits to the exact structure of the next transaction but doesn’t enable recursion. You constrain where funds go once; you can’t make that constraint follow the money forever. Developers who prefer minimal changes lean toward OP_CTV. Developers who want Bitcoin to compete with Ethereum-style programmability tend to favor OP_CAT.
One interesting footnote: Ethan Heilman co-authored both BIP 360 (quantum defense) and BIP 347 (OP_CAT). The same cryptographer is working to protect Bitcoin from external threats and to expand its capabilities from within. I don’t know what to make of that, but it’s worth noting.
Galaxy Research predicted in 2025 that “Bitcoin Core developers will reach consensus on adding either OP_CAT or OP_CTV in 2025.” That didn’t happen. No consensus was reached. As of February 2026, the debate continues on Delving Bitcoin and the mailing list, with no activation mechanism in sight. If you’re waiting on covenants to unlock Bitcoin vaults, plan for years, not months.
Silent payments: the privacy win that’s already here
While the covenant debate grinds on, one privacy improvement doesn’t require a consensus change at all, and it’s already working in production.
Silent payments (BIP 352) are “stealth addresses” that let you receive Bitcoin without exposing your current address and without creating on-chain linkability between payments. The sender performs an Elliptic Curve Diffie-Hellman calculation using their input keys and your static “silent payment address.” You detect incoming payments by scanning the blockchain.
No protocol fork required. Cake Wallet and BitBox already support it.
Active development in February 2026 is focused on BIP 376, which extends silent payments to work with PSBTs, the standard format for hardware wallets and multi-party signing setups. As of February 18, BIP 376’s GitHub PR was updated that morning.
One caveat worth knowing: Bitcoin Optech Newsletter #392 (February 13, 2026) reported a theoretical DoS attack against silent payment recipients. An adversary can construct a transaction with up to 23,255 taproot outputs all targeting the same entity, forcing the recipient’s scanning wallet to spend minutes on cryptographic computations rather than seconds. Researcher Sebastian Falbesoner has proposed limiting recipients per transaction group (K_max = 1,000) as a mitigation. Existing wallets shouldn’t be affected at a high enough threshold.
The DoS discovery is a sign of healthy development, not alarm. The researchers found it early, before anyone could exploit it, and a fix is already in discussion.
Other things moving in the protocol
A few developments worth tracking alongside the headline items.
FROST threshold signatures (BIP 445) are in active development. FROST enables k-of-n signing where multiple parties produce a single Schnorr signature indistinguishable from a single-party signature on-chain. Significant for corporate treasury setups and potentially for trustless L2 bridges.
Hornet UTXO is a performance breakthrough from Toby Sharp, covered in Optech #391. Bitcoin Core v30 takes roughly 167 minutes to re-validate the full chain on a 32-core machine. Hornet brings that to 15 minutes, an 11x speedup. Not merged yet, but the benchmark is real and the code exists.
Bithoven is a new high-level language for Bitcoin Script using C-family syntax (if, else, verify, return), making complex spending conditions more accessible to developers. Still early, but an interesting layer on top of existing capabilities.
Bitcoin Core 30.2 is the current stable release, as of January 13, 2026.
How to follow Bitcoin development if you’re not a developer
The real action happens in a few places.
Bitcoin Optech Newsletter is the single best resource for non-developers. Published every Friday, it summarizes everything that matters across Delving Bitcoin, GitHub, and the mailing list. If you read nothing else, read this.
Delving Bitcoin is the primary technical forum where most substantive developer discussion happens. Not beginner-friendly, but searchable.
github.com/bitcoin/bips is where BIPs live. You can watch PRs and commits in real time.
bip360.org is the BIP 360 project page, with explanations written specifically for non-technical readers.
Bitcoin’s conservatism is a feature
2026 is shaping up to be one of the most active periods for Bitcoin protocol development since Taproot. BIP 360, the covenant debate, silent payments, FROST, Hornet: genuine forward motion across multiple fronts simultaneously.
None of it moves fast. Bitcoin’s deliberate slowness reflects how much is at stake in changing a monetary network that secures trillions of dollars. The block size wars produced Bitcoin Cash. Nobody wants another chain split. That caution has a real cost (slower development, more frustration for builders) but it also has a real value: the changes that do get made have survived years of adversarial review.
The quantum threat is real on a long enough timeline. The covenant debate will resolve eventually. Silent payments are already available to anyone who wants them.
What Bitcoin development looks like is: ideas discussed for years on forums, formalized in BIPs, debated further, slowly merged into Core, eventually activated. It’s not exciting in the moment. It works over time.
Sources
- Bitcoin Magazine: “Bitcoin Advances Toward Quantum Resistance With BIP 360” (Feb 13, 2026) — Hunter Beast and Isabel Foxen Duke quotes
- BIP 360 specification (GitHub) — P2MR technical detail, verified Feb 18, 2026
- bip360.org — project overview and timeline estimates
- Cryptopolitan: “Quantum attack resistance BIP-360 added into the official Bitcoin repository” (Feb 13, 2026)
- Galaxy Research: “Bitcoin’s Next Major Upgrade? An Assessment of OP_CAT & OP_CTV” — covenant explainer and governance context
- Bitcoin Optech Newsletter #391 (Feb 6, 2026) — Hornet UTXO, Bithoven
- Bitcoin Optech Newsletter #392 (Feb 13, 2026) — silent payments DoS attack vector, BLISK
- Hiro.so: “What Are Bitcoin Silent Payments?” — wallet support (Cake Wallet, BitBox)
- bitcoin/bips repository (GitHub) — live BIP status and PR history