Bitcoin Scaling Always Trades Security

Changing Bitcoin's core consensus rules (e.g., block size) directly trades decentralization for throughput.

• Fork Risk: Proposals like Bitcoin Cash create permanent chain splits.
• Centralization Pressure: Larger blocks increase hardware requirements, pushing out smaller node operators.
• Security Stasis: The ~1MB block limit is a political ceiling, not a technical one.

Delegates security to a known, permissioned validator set (e.g., Liquid Network, Rootstock).

• Speed Gain: Enables ~1s block times and 1000+ TPS.
• Trust Assumption: Users must trust the federation, a significant reduction from Bitcoin's ~15,000 full nodes.
• Capital Efficiency: Enables fast, cheap transfers and DeFi, but with custodial risk.

Batches transactions off-chain, posting proofs or fraud challenges to Bitcoin. This is the current frontier.

• ZK Rollups (e.g., Botanix, Citrea): Use validity proofs for cryptographic security, but face Bitcoin's limited scripting.
• Optimistic Rollups: Rely on a 1-2 week fraud challenge period, creating long withdrawal delays.
• Security Inheritance: Both models are only as secure as their economic bond and ability to force settlement on L1.

The security of a Bitcoin L2 is only as strong as its bridge. Users must trust a multi-sig federation or watchtower, creating a centralized point of failure and censorship.

• Custodial Risk: Bridges like those for Stacks or Liquid rely on a ~10-15 member multi-sig, a high-value target.
• Data Availability: Fraud proofs require data to be posted to L1. If unavailable, funds can be stolen.
• Capital Efficiency: Locking BTC in a bridge removes it from the base layer's security, creating $2B+ honeypots.

Sidechains like Liquid Network or Rootstock run entirely separate consensus (e.g., PoA, merged mining). This abandons Bitcoin's Proof-of-Work security for speed.

• Validator Centralization: A small, known set of entities (Liquid: 15, RSK: ~4 mining pools) control the chain.
• Sovereignty Risk: The sidechain can hard fork or change rules independently, breaking the "peg".
• Weak Crypto-Economics: Security is not backed by BTC's $1T+ hashpower, but by the reputation of a few entities.

A proposed soft fork, Drivechains would allow miners to act as custodians for sidechain pegs. This replaces federation risk with miner cartel risk.

• Miner Extractable Value (MEV) on Steroids: Miners could vote to steal sidechain funds, a direct financial incentive to collude.
• Governance Paralysis: Requires a soft fork, facing immense political hurdles and ideological opposition.
• Slow Withdrawals: User exits rely on a ~3-month challenge period, destroying capital efficiency for security.

Models like RGB or BitVM push computation off-chain. Security collapses if a single participant withholds state data.

• Peer Dependency: You must find at least one honest peer to challenge fraud. If all go offline, you lose.
• User Complexity: Requires running a full node and managing state channels, a non-starter for mass adoption.
• Limited Throughput: Scalability is gated by the frequency of on-chain settlement transactions, creating congestion during peaks.

Bitcoin's base layer is the immutable security bedrock, but its throughput is capped at ~7 TPS with ~10-minute finality. Scaling here is a direct trade-off.

• Security Model: Nakamoto Consensus secured by ~500 EH/s of global hash power.
• Scalability Ceiling: Fixed 4 MB block weight and 1 MB block size limit create a hard throughput cap.
• Trade-off: Any L1 change (e.g., bigger blocks) risks altering the economic equilibrium and decentralization.

Solutions like the Lightning Network and sidechains (Liquid Network, Stacks) move computation off-chain, inheriting security assumptions.

• Lightning: Trust-minimized via HTLCs and penalty transactions, but requires liquidity management and watchtowers.
• Sidechains: Federated models (Liquid) or merged mining (Stacks) introduce new validator sets, creating a sovereign security budget.
• Trade-off: You exchange base-layer censor-resistance for ~1M+ TPS potential and sub-second finality.

Paradigms like BitVM and drivechains attempt to bring Ethereum-style rollups to Bitcoin, using fraud proofs or a federated peg.

• BitVM: Enables optimistic rollups via a Turing-complete off-chain VM, with disputes settled on-chain. No live execution on L1.
• Drivechains: A soft-fork proposal allowing sidechains to be secured by Bitcoin miners, but introduces new governance complexity.
• Trade-off: Maximizes L1 security reuse but adds significant protocol complexity and is not yet production-ready.

Building a separate chain with Bitcoin as a reserve asset (e.g., Babylon, Nomic) uses Bitcoin for staking or timestamping, not execution.

• Security Source: Bitcoin provides cryptoeconomic security via staking derivatives or proof-of-stake backstopping.
• Execution Layer: A separate, high-performance blockchain (often Cosmos SDK) handles transactions.
• Trade-off: You get a full-stack chain but its security is decoupled from Bitcoin's hash power, relying on inter-protocol incentives.

Scaling requires cheap, abundant data posting. Bitcoin's ~4 MB/block is a major constraint compared to Ethereum's ~1.8 MB/blob per slot.

• Inscriptions/Ordinals: Demonstrated that block space is the ultimate scarce resource, driving fees over $50/tx.
• Solutions: Proposals like Bitcoin-native DA layers or leveraging external systems (Celestia, EigenDA) create a modular dependency.
• Trade-off: Using external DA reduces data lineage guarantees and introduces additional trust layers.

Architects must explicitly choose which property to optimize and which to compromise on. There is no free lunch.

• Optimize for Security: Use Lightning for payments; accept capital inefficiency and routing complexity.
• Optimize for Scalability: Use a sidechain; accept a federated or weaker consensus model.
• Optimize for Sovereignty: Build an appchain; accept bootstrapping a new security budget from scratch.
• The Map: Your choice defines your threat model, user experience, and ultimate ceiling.