Chapter 12: The Future of Bitcoin

In Satoshi’s Words

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.”

— Satoshi Nakamoto, BitcoinTalk, June 17, 2010

And four months later:

“It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit”

— Satoshi Nakamoto, BitcoinTalk, October 4, 2010

These two statements are not contradictory. They represent the central tension that defines Bitcoin development in 2025 and beyond: the core design is permanent, but the protocol must evolve within that design. The monetary policy is immutable. The consensus mechanism is settled. The UTXO model is foundational. But the scripting system, the transaction relay logic, the privacy tooling, the Layer 2 infrastructure — these are all active construction sites.

This chapter is about what’s being built and debated right now. Not speculation. Not roadmaps from 2018 that never shipped. The actual state of Bitcoin protocol development as of early 2026.

Part I: The Next Soft Fork — CTV, CSFS, and OP_CAT

The last consensus-level change to Bitcoin was Taproot, activated in November 2021. As of early 2026, over four years have passed without a soft fork. That is both a sign of Bitcoin’s conservatism and an increasingly uncomfortable gap for developers who need new primitives to build better second layers.

Three proposals dominate the conversation. Two of them are being pushed as a package.

CTV (OP_CHECKTEMPLATEVERIFY, BIP 119)

CTV is the longest-running soft fork campaign in Bitcoin’s post-Taproot era. Proposed by Jeremy Rubin in 2019, it does one thing: it allows an output to commit to the exact template of the transaction that spends it. When you create a CTV-encumbered output, you’re saying: “This coin can only be spent by a transaction that looks exactly like this — these outputs, this locktime, this version.”

Technically, CTV replaces OP_NOP4 with a new opcode that takes a 32-byte hash and verifies that the spending transaction matches it. The commitment covers:

• Transaction version
• Locktime
• Number of inputs and outputs
• The outputs themselves (amounts and scriptPubKeys)
• The input’s position in the spending transaction
• Signature scripts hash (if non-null)
• Sequences hash

What this enables:

• Vaults: Pre-commit your coins to a spending path that requires a time delay before final withdrawal. If someone steals your keys, you have a window to claw back funds.
• Congestion control: A single on-chain transaction can commit to a tree of future transactions, batching payouts without requiring all recipients to be online simultaneously.
• Channel factories: Create many Lightning channels from a single on-chain transaction.
• Payment pools: Multiple users share a single UTXO and can exit independently.

Jeremy Rubin spent years pushing CTV through the community. He ran a CTV-specific mailing list, published extensive documentation, organized review sessions, and at one point in 2022 attempted to push toward activation — which was rejected as premature by other developers. Rubin stepped away from active Bitcoin Core development for a period after the pushback. But CTV never died.

In June 2025, James O’Beirne — the author of OP_VAULT (BIP 345) and a longtime CTV supporter — published a letter to the Bitcoin Development Mailing List advocating for final review and activation of CTV alongside CSFS. O’Beirne had been listed as a co-author of CTV at one point, having championed it for over three years, and his vault proposal explicitly depends on CTV as a building block.

By December 2025, pseudonymous developer /dev/fd0 organized a meeting to discuss activation strategy for BIP 119. The tentative plan: a BIP 9-style soft fork activation with conservative parameters, giving the community one year starting January 9, 2026, to signal support. The approach was deliberately slow — no flag days, no ultimatums, no UASF threats. Just miner signaling with ample time.

CSFS (OP_CHECKSIGFROMSTACK, BIP 348)

CSFS is CTV’s companion opcode. Where CTV constrains what a transaction can look like, CSFS enables verifying a signature against arbitrary data — not just the transaction itself.

Normal OP_CHECKSIG verifies a signature against the hash of the spending transaction. CSFS removes that restriction: you push a message, a signature, and a public key onto the stack, and the opcode verifies the signature against the message. Any message.

This sounds abstract. Its implications are concrete:

• Oracle-verified data: A trusted oracle signs a piece of data (a price feed, a sports score, an election result). A Bitcoin script can verify that signature and conditionally release funds. This is the foundation for on-chain DLCs (Discreet Log Contracts).
• Delegation: Sign a message authorizing someone else to spend your coins under specific conditions, without giving them your private key.
• Vaults with recovery: Combined with CTV, CSFS enables vault constructions where a recovery key can override the pre-committed spending path.

CTV + CSFS Together

The combination is more powerful than either opcode alone. Together, they enable:

The political dynamics are worth understanding. CTV has had both passionate supporters and vocal detractors. The detractors fall into two camps: those who think CTV is too limited (they want something more general, like OP_CAT or CCV), and those who think any new opcode is a mistake and Bitcoin should ossify. The June 2025 letter acknowledged both positions and argued that CTV + CSFS hit a pragmatic sweet spot: powerful enough to enable vaults and better L2s, constrained enough to be analyzable and safe.

OP_CAT (BIP 347)

OP_CAT is the wildcard. It does one thing: concatenate two stack elements. Pop two items, push back their concatenation. Maximum result size: 520 bytes. That’s it.

It’s also, arguably, the most powerful proposed opcode change in Bitcoin’s history.

OP_CAT was originally in Bitcoin. Satoshi included it in the initial Script implementation. He removed it in September 2010 as a precaution — large concatenations could create memory-exhaustion attacks. BIP 347, authored by Ethan Heilman and Armin Sabouri in October 2023, proposes re-enabling it within Tapscript only (as a redefinition of OP_SUCCESS126), with the 520-byte limit preventing the original attack vector.

What OP_CAT enables:

The power comes from combining concatenation with OP_CHECKSIG. By constructing a transaction hash piece-by-piece on the stack using CAT, then verifying a signature against it, you can achieve transaction introspection — the script can inspect and constrain arbitrary fields of the spending transaction.

This unlocks:

• Recursive covenants: Outputs that constrain not just the next spend, but the spend after that, and the spend after that — indefinitely. This is something CTV explicitly cannot do.
• STARK verification on Bitcoin: Concatenation enables Merkle proof verification on the stack, which enables verifying zero-knowledge proofs, which enables verifying arbitrary computation.
• Vaults: Different construction than CTV vaults, but achievable.
• On-chain verification of off-chain state: Any system that can produce a Merkle proof can have that proof checked in Bitcoin Script.

The controversy:

OP_CAT’s power is precisely the objection. Recursive covenants could enable things that some Bitcoiners believe Bitcoin “shouldn’t” do:

• Token protocols that are enforced at the consensus level (not just by convention, like Ordinals)
• MEV-like behavior where transaction ordering becomes extractable value
• Complex smart contract interactions that could make Bitcoin Script harder to reason about

The counter-argument: OP_CAT was already in Bitcoin. Satoshi included it. The 520-byte limit constrains the practical attack surface. And the alternative — not enabling these capabilities — forces developers onto less elegant paths (like BitVM’s massive on-chain footprint for dispute resolution).

As of early 2026, OP_CAT is active on Bitcoin’s default signet via Bitcoin Inquisition (the signet fork used for testing proposed consensus changes). Real testing is happening. Bitcoin Inquisition 27.0 began enforcing OP_CAT on signet in 2024, and Inquisition 29.2 (February 2026) continues active testing.

The relationship between CTV and OP_CAT is politically charged. Some developers see them as complementary — activate CTV now for immediate use cases, activate OP_CAT later after more study. Others see them as competitors — if you’re going to do a soft fork, pick the more powerful primitive. Still others want neither, or want a different opcode entirely (like OP_CCV, a more general covenant verification opcode that needs more scrutiny).

Part II: Covenants — The General Concept

All three opcodes above are different approaches to the same idea: covenants. A covenant is a restriction on how a UTXO can be spent in the future. Today, Bitcoin Script can restrict who can spend a coin (via signatures and timelocks). Covenants add the ability to restrict where the coin goes and how it gets there.

Why Covenants Matter

Without covenants, every spending condition in Bitcoin is “checked and forgotten.” Once you satisfy the script (provide a valid signature, wait for a timelock), you can send the coins anywhere. There’s no way for an output to say “these coins must go to address X” or “these coins must be split into exactly three outputs.”

This limitation makes it impossible to build certain things natively:

OP_VAULT (BIP 345)

James O’Beirne’s OP_VAULT proposal is the most targeted covenant design. Rather than adding a general-purpose opcode, it adds two opcodes (OP_VAULT and OP_VAULT_RECOVER) specifically designed for vault use cases.

A vault built with OP_VAULT works like this:

1. You deposit coins into a vault output
2. To spend, you first trigger an unvaulting process, specifying the destination
3. A time delay begins (e.g., 24 hours)
4. During the delay, you can send the coins to a recovery address (the “clawback”)
5. After the delay, the coins go to the specified destination

This is arguably the single most important self-custody improvement possible for Bitcoin. Hardware wallet compromises, $5 wrench attacks, social engineering — all of these become survivable if you have a 24-hour clawback window.

OP_VAULT requires CTV to function. If CTV activates, OP_VAULT can be built on top of it. This is one of the strongest practical arguments for CTV.

The Philosophical Debate

Should Bitcoin outputs have “memory”? Should the protocol care where coins go after they leave your control?

The ossification camp says no. Bitcoin’s simplicity is its strength. Every new opcode is a new attack surface. Every covenant is a potential for unintended emergent behavior. Bitcoin works. Don’t break it.

The pragmatic camp says Bitcoin’s current Script system is crippled in specific, known ways that prevent building critical infrastructure — particularly vaults and better Layer 2 systems. The question isn’t whether to change Bitcoin, but whether to make careful, conservative changes that unlock specific, well-understood capabilities.

Both camps invoke Satoshi. Both have a point.

Part III: Privacy and Quantum Resistance

Silent Payments (BIP 352)

Silent Payments are the most significant Bitcoin privacy improvement that doesn’t require a soft fork.

The problem: To receive Bitcoin privately, you need a fresh address for every payment. This requires interaction — the receiver must generate and communicate a new address to each sender. For donation pages, tip jars, or any scenario where a static address is published, this is impossible. The result: address reuse, which destroys privacy by linking all payments to the same entity.

The solution: Silent Payments use ECDH (Elliptic Curve Diffie-Hellman) to let senders derive a unique, one-time address from the recipient’s static public key. The sender combines their input keys with the recipient’s scan key to produce a shared secret, then uses that secret to tweak the recipient’s spend key into a unique output address.

The recipient’s published address (starting with sp1...) never appears on-chain. Each payment creates a unique Taproot output that only the recipient can identify by scanning the blockchain and performing the reverse ECDH calculation.

How it works, step by step:

1. Alice publishes her Silent Payment address: a pair of public keys (scan key + spend key)
2. Bob wants to pay Alice. He takes the sum of his input private keys and Alice’s scan key, performs ECDH
3. The shared secret is used to derive a tweak
4. Bob creates an output to Alice’s spend key + tweak. This is a standard-looking Taproot output
5. Alice scans the blockchain. For each transaction, she takes the sum of the sender’s input public keys, performs ECDH with her scan private key, and checks if any output matches
6. If a match is found, Alice can spend it using her spend private key + the derived tweak

The cost: Scanning. Unlike BIP 32 wallets that check the UTXO set for known scriptPubKeys, Silent Payment wallets must scan every transaction and perform ECDH. This is computationally more expensive, though optimizations exist (light client support, Nostr-based notifications).

Deployment status (early 2026):

• BIP 352 merged into the BIPs repository
• Cake Wallet: shipping with Silent Payment support (send and receive)
• Silentium: dedicated Silent Payment wallet
• Nunchuk: added Silent Payment support in early 2026
• Bitcoin Core: PSBT support for Silent Payments under active development (BIP 375 merged for sending)
• Draft BIP for Silent Payment output descriptors published
• Electrum server implementation for testing available

Silent Payments are a wallet-level upgrade. No soft fork needed. No miner signaling. No activation drama. Just better wallet software. This is the category of improvement that can ship without anyone’s permission.

BIP 360: Quantum Resistance (P2QRH / P2MR)

Quantum computers cannot break Bitcoin today. But “today” is the wrong timeframe for a protocol designed to last centuries.

BIP 360, authored by Hunter Beast (MARA senior protocol engineer) and Ethan Heilman (co-author of OP_CAT), with Isabel Foxen Duke joining as co-author, introduces Pay-to-Quantum-Resistant-Hash (P2QRH), now rebranded as Pay-to-Merkle-Root (P2MR).

The threat model:

Bitcoin’s security relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures, both based on the secp256k1 curve. Shor’s algorithm, running on a sufficiently powerful quantum computer, could derive private keys from public keys. Two attack scenarios:

1. Long-exposure attack: Public keys that are permanently visible on-chain (P2PK outputs, reused addresses, Taproot key-path outputs) can be targeted at leisure. As of 2025, over 6 million BTC sit in quantum-exposed addresses.
2. Short-exposure attack: A quantum computer fast enough to derive a private key while a transaction is in the mempool (between broadcast and confirmation). This is much harder but not impossible in the distant future.

How P2MR works:

P2MR operates like Taproot but removes the key-path spend entirely. Instead of committing to a public key (which becomes quantum-vulnerable when revealed), P2MR commits only to the Merkle root of the script tree. Every spend goes through the script path. This eliminates long-exposure vulnerability — no public key is ever revealed until the moment of spending.

The proposal is designed as a foundation. Future BIPs can layer in post-quantum signature algorithms — candidates include:

• ML-DSA (Dilithium): Lattice-based, NIST-standardized
• SLH-DSA (SPHINCS+): Hash-based, very conservative security assumptions, large signatures
• SQIsign: Isogeny-based, compact signatures but newer and less studied

Current status:

• BIP 360 merged to the BIP repository in 2025
• Active discussion on Delving Bitcoin
• Not yet implemented in Bitcoin Core
• No activation timeline — this is preparatory work

The pragmatic view: We don’t know when quantum computers will threaten secp256k1. IBM, Google, Microsoft, PsiQuantum, and others are investing billions. The US government has mandated phasing out ECDSA cryptography by 2035. Whether the timeline is 5 years or 50, having the BIP written, reviewed, and ready to implement is prudent engineering. Bitcoin’s upgrade process is slow by design — you don’t want to start designing quantum resistance after a quantum computer can steal coins.

Part IV: Protocol Infrastructure

Cluster Mempool (Bitcoin Core 28–30+)

The mempool — the waiting room where unconfirmed transactions sit before being included in blocks — got a fundamental rearchitecture. Cluster Mempool, developed by Suhas Daftuar and Pieter Wuille, was merged into Bitcoin Core on November 25, 2025 (PR #33629), and ships in Bitcoin Core 30.0.

The problem it solves:

Prior to cluster mempool, Bitcoin Core maintained two separate transaction orderings:

1. Ancestor feerate — looking backward from a transaction to its parents, computing the combined feerate of the “ancestor set” (everything you need to confirm to confirm this transaction)
2. Descendant feerate — looking forward to child transactions

These two orderings served different purposes: ancestor feerate for block construction (what should a miner include?), descendant feerate for eviction (what should be dropped when the mempool is full?). The problem: they could disagree. A transaction might be high-priority for inclusion but low-priority for eviction, or vice versa. This created:

• Suboptimal block templates (miners leaving money on the table)
• Inaccurate fee estimation (users overpaying or underpaying)
• Pinning attacks on Layer 2 protocols (attackers exploiting the inconsistency between what gets accepted and what gets mined)

The solution:

Cluster mempool groups related unconfirmed transactions into “clusters” — connected components of parent-child relationships. Each cluster is then subdivided into “chunks” sorted by feerate. All mempool operations — acceptance, eviction, replacement, block building — use the same unified ordering.

This is not a consensus change. It’s a node implementation change. But it has profound effects on Lightning Network reliability (more predictable fee bumping), mining profitability (better block templates), and user experience (more accurate fee estimation).

Part V: Lightning Network Evolution

Lightning is not standing still. Multiple improvements are shipping or in late-stage development.

BOLT 12 / Offers

BOLT 12 introduces “offers” — reusable payment requests that replace the single-use invoices of BOLT 11. An offer is a static string (or QR code) that a payer uses to fetch a fresh invoice from the payee, automatically, without human interaction.

Why this matters: BOLT 11 invoices expire. You can’t put one on a website and leave it. BOLT 12 offers are permanent. A streamer, a merchant, a donation page — any entity that needs to receive Lightning payments — can publish a single offer and receive payments indefinitely. Offers also support:

• Blinded paths: The payee doesn’t reveal their node identity to the payer
• Recurring payments: Subscribe to a service with a single offer
• Refunds: Built-in mechanism for the payee to send money back

Core Lightning shipped full BOLT 12 support in 2024 — the first new BOLT addition since 2017. Adoption is spreading across other implementations. Human-readable Bitcoin addresses (like user@domain.com resolving to a BOLT 12 offer) are gaining traction, improving the payment UX dramatically.

Splicing

Splicing solves one of Lightning’s most persistent UX problems: channel capacity is fixed after creation. If you open a channel with 0.1 BTC and need 0.2 BTC of capacity, you have to close the channel and open a new one — two on-chain transactions, downtime, and fees.

Splicing allows you to:

• Splice in: Add funds to an existing channel without closing it
• Splice out: Remove funds from a channel (sending them on-chain) without closing it

The channel stays live during the splice. The funding transaction is updated on-chain, but the channel never goes offline. Phoenix Wallet (ACINQ) has been the pioneer implementation, and the protocol changes are working their way into the Lightning BOLTs specification.

The deeper implication: with splicing, a Lightning wallet can present a unified balance to the user. No more “on-chain balance” vs. “Lightning balance.” Funds move seamlessly between the two layers as needed, with the user seeing a single number.

Taproot Channels

Taproot channels use P2TR (Pay-to-Taproot) outputs for the channel funding transaction instead of P2WSH. The benefits:

• Privacy: Cooperative closes look like ordinary single-sig Taproot spends — indistinguishable from normal transactions on-chain
• Efficiency: Schnorr signature aggregation reduces the on-chain footprint
• Future-proofing: Taproot’s script tree enables more complex channel constructions

LND and other implementations have been rolling out Taproot channel support. This is incremental but meaningful — every Lightning channel that looks like a normal transaction improves the privacy of both Lightning users and non-Lightning users (by increasing the anonymity set).

LN-Symmetry (formerly eltoo)

LN-Symmetry is a proposed simplification of Lightning channel state management. Current Lightning channels use a “penalty” mechanism: if your counterparty broadcasts an old channel state, you can take all their funds. This works but is complex and requires storing every previous channel state.

LN-Symmetry replaces this with a simpler model: any newer state can override any older state. No penalty required. No need to store old states. The latest state always wins.

The catch: LN-Symmetry requires a new sighash flag, SIGHASH_ANYPREVOUT (APO), which is itself a soft fork proposal. Without APO, LN-Symmetry cannot be deployed. This creates a dependency chain: APO soft fork → LN-Symmetry → simpler Lightning channels.

LSPs (Lightning Service Providers)

LSPs are the practical solution to Lightning’s onboarding problem. Opening a Lightning channel requires an on-chain transaction, understanding of liquidity, and technical knowledge. LSPs abstract this away:

• They open channels to new users (providing inbound liquidity)
• They use Just-in-Time (JIT) channels — creating a channel the moment a payment arrives
• They handle routing, rebalancing, and watchtower duties

The tradeoff: LSPs are typically non-custodial (you keep your keys), but they can see your payment metadata. This is better than custodial Lightning wallets (where someone else holds your keys) but worse than running your own node.

Greenlight managed over 200,000 nodes by end of 2024 (20x growth). Voltage powers enterprise Lightning for BitGo, Unocoin, and Braiins. The LSP ecosystem is maturing rapidly.

Lightning Agent Tools (February 2026)

On February 11, 2026, Lightning Labs released lightning-agent-tools — an open-source toolkit that gives AI agents the ability to send and receive Bitcoin payments over Lightning autonomously. No API keys. No signup. No identity.

The toolkit uses the L402 protocol (built on HTTP’s 402 “Payment Required” status code). A website sends a Lightning invoice to an AI agent; the agent pays it; the agent receives a cryptographic receipt (a macaroon) that grants access to the resource.

Seven composable skills ship with the toolkit:

1. Running a Lightning node
2. Isolating private keys with a remote signer
3. Baking scoped credentials (macaroons with spending limits)
4. Paying for L402-gated APIs
5. Hosting paid endpoints
6. Querying node state via MCP (Model Context Protocol)
7. Orchestrating buyer/seller workflows

This is significant because it identifies a use case that only Lightning can serve. Credit cards require identity. Bank transfers require KYC. PayPal requires an email. Lightning requires none of these. For autonomous software agents that need to pay for API calls, compute, or data — Lightning is the only payment rail that works without human-in-the-loop authentication.

The toolkit works with any agent framework that can execute shell commands, including Claude Code and Codex.

Part VI: BitVM — Computation Without a Soft Fork

BitVM is Robin Linus’s answer to the question: “Can Bitcoin verify arbitrary computation without changing the protocol?”

The answer, published in his October 2023 paper “BitVM: Compute Anything on Bitcoin,” is yes — with caveats.

How BitVM Works

BitVM uses an optimistic verification model (similar to optimistic rollups on Ethereum):

1. A Prover claims to have executed a computation correctly
2. A Verifier can challenge the claim
3. If challenged, the computation is bisected on-chain until a single gate-level operation is identified
4. Bitcoin Script verifies that single operation
5. If the Prover lied, they lose their collateral

The key insight: Bitcoin doesn’t need to execute the computation. It only needs to verify a single step if there’s a dispute. Since any computation can be decomposed into binary gate operations, and Bitcoin Script can verify individual gates, Bitcoin can act as the final arbiter for any computation.

BitVM2 (the optimized version, with a peer-reviewed paper presented at the Science of Blockchain Conference at Berkeley) dramatically reduced the on-chain footprint. Where BitVM required hundreds of on-chain transactions for dispute resolution, BitVM2 reduces this to a handful. On June 3, 2025, the full unhappy path was validated on Bitcoin mainnet — Claim, Challenge, Assert, Disprove — confirming in 42 blocks (about 7 hours) at a total cost of approximately 14.9 million sats (~$16,000 at the time). This path is unlikely in practice, since honest operators avoid losing collateral.

BitVM Bridge

The most immediate application: trustless Bitcoin bridges. The BitVM Bridge allows BTC to move between Bitcoin and other chains without relying on a federation or multisig committee.

How it differs from existing bridges:

With a BitVM Bridge, any single honest verifier can prevent theft by executing a challenge. You don’t need to trust a majority — you only need one honest participant. This is a fundamentally different security model.

Mainnet status: Bitlayer launched its BitVM Bridge mainnet beta in 2025 as the first functional application of the BitVM paradigm. Citrea, the first ZK rollup using BitVM for proof verification, went live on mainnet in early 2026. The BitVM Alliance — including Alpen, Babylon, Bitlayer, BOB, Citrea, Element, Fiamma, GOAT Network, and ZeroSync — coordinates development.

BitVM is funded as open-source software under the ZeroSync nonprofit, with grants from Spiral, StarkWare, OpenSats, Fedi, and community contributions. Robin Linus is now a PhD student at Stanford, focusing on Bitcoin scalability, privacy, and usability.

Part VII: RGB + Tether on Bitcoin

RGB Protocol

RGB is a system for client-side validated smart contracts on Bitcoin and Lightning. Unlike Inscriptions or BRC-20 tokens (which store data on-chain), RGB keeps all state off-chain. The blockchain is used only for commitments — cryptographic anchors that prove the off-chain state existed at a specific point in time.

How RGB works:

1. Contract state is stored by the participants (client-side)
2. State transitions are validated by each participant independently
3. A hash of the state transition is committed to a Bitcoin transaction (using an OP_RETURN or Taproot tweak)
4. The blockchain proves ordering and prevents double-spends
5. Lightning compatibility: RGB state can be transferred over Lightning channels

This is fundamentally different from the Ordinals/Inscriptions approach. RGB doesn’t bloat the blockchain. It doesn’t require full nodes to store or validate token data. It uses Bitcoin as a timestamping and anti-double-spend layer, nothing more.

The LNP/BP Standards Association maintains the RGB specification.

Tether on RGB

On August 28, 2025, Tether announced the launch of USDT on RGB. This is the largest stablecoin (over $167 billion in circulation) running natively on Bitcoin’s actual protocol layer.

Paolo Ardoino (Tether CEO): “Bitcoin deserves a stablecoin that feels truly native — lightweight, private, and scalable.”

Why this matters:

• USDT on RGB is private by default (client-side validation means transaction details aren’t on-chain)
• It works over Lightning (near-instant settlement, negligible fees)
• It doesn’t bloat the blockchain
• Users can hold BTC and USDT in the same wallet

This is distinct from USDT on the Lightning Network via Taproot Assets (announced earlier, using Lightning Labs’ protocol). RGB and Taproot Assets are competing approaches to the same goal: assets on Bitcoin. RGB is the older specification with a more conservative, standards-body-driven development process.

Part VIII: Ark — A New Layer 2

Ark is a Layer 2 protocol designed by Burak Keceli to solve a problem that Lightning has never fully addressed: onboarding.

The Lightning Onboarding Problem

To use Lightning, you need a channel. A channel requires an on-chain transaction. At $50 per on-chain transaction (during fee spikes), onboarding a new Lightning user costs real money. And the channel needs inbound liquidity — someone has to commit BTC on the other side. LSPs solve this partially but add complexity and counterparty awareness.

Ark takes a different approach.

How Ark Works

1. An Ark Service Provider (ASP) periodically creates shared on-chain transactions called “rounds”
2. Users receive virtual UTXOs (VTXOs) — shares in the shared UTXO, backed by a tree of pre-signed off-chain transactions
3. Payments within Ark are transfers of VTXOs: the sender’s VTXO is consumed, the recipient gets a new one
4. Any user can unilaterally exit at any time by broadcasting their branch of the pre-signed transaction tree. No ASP cooperation needed.
5. VTXOs expire (currently ~4 weeks) and must be refreshed by participating in a new round

The user experience is closer to on-chain Bitcoin than Lightning: you have UTXOs (virtual ones), you make payments by consuming and creating them, and you can exit to the chain whenever you want.

Trust Model

Out-of-round transfers are instant but require trusting that the sender and ASP don’t collude to double-spend. In-round transfers are trustless but take a few seconds. Users can designate multiple delegates for VTXO refresh, shifting the liveness requirement to a 1-of-N assumption.

CTV Dependency

Ark currently operates in a trust-minimized mode. With CTV, the protocol becomes more fully trustless — CTV can enforce the structure of the VTXO trees at the consensus level, removing some of the interactive signing requirements. This is another strong argument for CTV activation.

Two implementations are in active development:

• Second (second.tech)
• Arkade (arkadeos.com)

Ark complements Lightning; it doesn’t replace it. Ark users can send and receive Lightning payments through Lightning Gateways, which atomically swap VTXOs for Lightning payments.

Part IX: The Ossification Debate

Is Bitcoin “done”?

This is the deepest philosophical question in Bitcoin development, and there is no consensus answer. Both sides argue from first principles, and both have historically been correct about different things.

The Case for Ossification

1. Stability is the feature: Bitcoin’s value proposition is that it doesn’t change. The rules you agree to today are the rules that exist tomorrow. Every soft fork, no matter how conservative, introduces risk. Taproot introduced Inscriptions — an unintended consequence. CTV could introduce unintended consequences we can’t predict.

2. The Lindy effect: Bitcoin has survived for 17 years with relatively few consensus changes. Each year without a breaking change increases confidence. Stopping changes extends the Lindy clock indefinitely.

3. Attack surface minimization: Every new opcode is new code in the consensus path. New code means new bugs. Consensus bugs in Bitcoin are catastrophic — they can cause chain splits, inflation events, or fund theft.

4. L2 innovation doesn’t require L1 changes: BitVM proves that arbitrary computation is possible without a soft fork. Lightning works today. Build on what exists.

The Case Against Ossification

1. Missing critical features: Bitcoin cannot do vaults today. Self-custody security is stuck at “don’t lose your keys.” Covenants would make self-custody dramatically safer for ordinary users. Denying this upgrade is a policy choice that costs users real money when their keys are compromised.

2. Layer 2 limitations: Lightning requires on-chain transactions for channel opens and closes. Without better L1 primitives (CTV, APO), L2 protocols remain more complex, more interactive, and more expensive than they need to be. The “build on what exists” argument ignores the genuine engineering limitations.

3. Quantum threat: secp256k1 will eventually be broken. The question is when, not if. Having P2MR (BIP 360) reviewed, tested, and ready to deploy is not optional — it’s a survival requirement. Ossification before quantum resistance is reckless.

4. The ossification paradox: If you ossify now, you also ossify the ability to respond to emergencies. A truly ossified Bitcoin cannot be patched. This may be fine in a world without quantum computers and without clever attacks on Script. We don’t live in that world.

Jameson Lopp articulated this well: “I believe that Bitcoin has far greater potential than what we have achieved thus far. I view the Bitcoin blockchain as a cryptographic accumulator for a wide variety of systems that can anchor into it. But we have barely scratched the surface of what is possible.”

The Pragmatic Middle

The actual practice of Bitcoin development already occupies a middle ground: conservative, extremely high consensus bar, with changes only when the benefit clearly outweighs the risk. Taproot took years. CTV has been debated since 2019. No one is shipping fast and breaking things.

Christine Kim (Galaxy Research, BTC Before Light newsletter) captured the reality well in January 2026:

“Based on the recent discourse over these proposals, you might think, ‘Wow, Bitcoin is going to change a ton this year!’ The thing is, it probably won’t. Bitcoin is extremely resistant to change, even in the face of multiple soft fork attempts.”

Development Roadmap (As of Early 2026)

Key Takeaways

1. The next soft fork, whenever it comes, will likely include CTV (BIP 119). It has the broadest developer support, the longest review history, and concrete use cases (vaults, channel factories, congestion control). BIP 9 signaling was proposed to begin January 2026, but activation requires overwhelming consensus — which hasn’t been reached yet.

2. OP_CAT is more powerful but more controversial. It enables recursive covenants, STARK verification, and general computation checks. Whether that power is a feature or a risk is the central debate. Active testing on signet continues.

3. Silent Payments are shipping now without anyone’s permission. BIP 352 is the most important privacy upgrade Bitcoin has received since Taproot, and it’s a wallet-level change. No soft fork drama. Just better software.

4. Cluster Mempool is a quiet revolution. It doesn’t change consensus rules, but it fundamentally improves how nodes handle transactions — better fee estimation, more optimal block building, more predictable RBF and CPFP behavior. It makes Lightning more reliable.

5. BitVM proves that Bitcoin can verify arbitrary computation today. No soft fork required. The tradeoff is on-chain cost for disputes, but the BitVM Bridge provides the first truly trust-minimized Bitcoin bridge (1-of-N honesty assumption).

6. Lightning is maturing into real infrastructure. BOLT 12 offers, splicing, Taproot channels, LSPs, and AI agent tooling are transforming Lightning from a developer toy into a production payments system.

7. Quantum resistance is being prepared, not deployed. BIP 360 (P2MR) lays the groundwork. The timeline for quantum threats is uncertain, but the engineering work must happen before the threat materializes.

8. The ossification debate is healthy. Bitcoin’s resistance to change is a feature, not a bug. But resistance to change is different from inability to change. The protocol must retain the capacity to upgrade when the need is clear and the consensus is overwhelming.

9. Satoshi designed Bitcoin to work without him. He also designed it to evolve. Both quotes at the top of this chapter are true simultaneously. The core design is set in stone. The implementation keeps getting better. That tension is what makes Bitcoin durable.

Previous: Chapter 11 — The Bitcoin Network — How the P2P layer actually works: node types, block propagation, transaction relay, and eclipse attack resistance.

Related: Satoshi’s Words — Every Satoshi quote in this guide, with full context.