Section III: Bitcoin Upgrades and Scaling
Bitcoin's technical architecture provides a robust foundation, but no system is perfect from inception. The question becomes: how does a decentralized network evolve without central authority? This section explores Bitcoin's governance model, the mechanisms for upgrading the protocol, and the major improvements that have been deployed over its history.
Bitcoin Core
The Bitcoin protocol is the set of rules that define how Bitcoin works: what makes a block valid, how transactions are structured, how much new bitcoin is created, and so on. It can be thought of as the "specification" for Bitcoin.
Bitcoin Core is software that implements these rules. It's the most widely used Bitcoin node software, originally written by Satoshi Nakamoto and now maintained by a global community of developers. When running a Bitcoin node, one is most likely running Bitcoin Core.
Here's where it gets interesting: Bitcoin has no formal written specification separate from the code. Instead, Bitcoin Core's consensus code has become the de facto reference that defines the rules. Other node implementations exist, like btcd or libbitcoin, but they maintain compatibility by matching Core's behavior. This means Core holds significant influence not because it controls Bitcoin, but because the economic majority has chosen to run it.
Consensus Rules vs. Policy Rules
Understanding Bitcoin requires distinguishing between two types of rules that nodes enforce. Consensus rules are the fundamental laws that define what makes a block or transaction valid on the blockchain itself. These rules are enforced by all full nodes when validating blocks, and any violation results in permanent rejection. Examples include blocks not exceeding 4,000,000 weight units, outputs not exceeding inputs plus the coinbase reward, and signatures being cryptographically valid. Breaking a consensus rule means a transaction or block is invalid and will never be accepted into the blockchain, regardless of miner support.
Policy rules, also called mempool policy or relay policy, represent a different layer entirely. These are optional standards that individual nodes use to decide which unconfirmed transactions they'll accept into their mempool and relay to peers. Working on top of Bitcoin's mandatory consensus rules, these additional local preferences help nodes filter spam, prioritize valuable transactions, and manage resources. Examples include minimum relay fee rates, transaction size limits for relay that are far below the block limit, and standardness restrictions on which types of scripts nodes will relay, favoring common patterns even though more exotic consensus-valid scripts exist.
The distinction between these rule types creates an important dynamic. A transaction can violate standard policy yet remain perfectly valid under consensus rules. When a transaction uses a non-standard script, for instance, most nodes won't relay it and it won't appear in most mempools. However, if a miner receives it directly, perhaps because the user contacted them, the miner can include it in a block. Once included, all nodes will accept that block as valid because policy rules don't govern what belongs in blocks, only what gets relayed beforehand. This has happened with various non-standard transactions throughout Bitcoin's history.
This separation serves several important functions. Nodes can reject uneconomical transactions before they waste network bandwidth or blockchain space without requiring network-wide coordination. Different node operators can choose stricter or looser policies based on their needs, hardware capabilities, or philosophies. Policy can be adjusted through Bitcoin Core releases without the coordination challenges of consensus changes, allowing new transaction types to be made consensus-valid while policy rules gradually adopt them over time.
How Changes Happen
Changes to Bitcoin are proposed through BIPs (Bitcoin Improvement Proposals). Policy changes happen regularly through Bitcoin Core releases and don't require extensive coordination. Node operators can upgrade at their convenience, and the network continues functioning even with mixed policy versions. Recent releases have focused primarily on mempool policy improvements, adjusting things like fee rate minimums and transaction relay rules.
Consensus changes are far rarer and more significant because they modify the fundamental protocol rules about what makes blocks and transactions valid. These require careful coordination since the entire network needs to agree on the rules. When consensus rules do change, it happens through specific upgrade mechanisms explored below.
Bitcoin Core's careful development process, extensive testing, and broad adoption make it the standard reference implementation. Major upgrades like SegWit and Taproot were implemented in Core and activated by the network, demonstrating how protocol evolution works through this widely-adopted software. However, ultimate control rests with users and businesses who decide which software to run and which rules to follow.
Understanding Fork Types
How can a decentralized network be upgraded when no one's in charge? Bitcoin has two main upgrade mechanisms that allow the protocol to evolve while maintaining consensus.
Hard Forks
Hard forks are incompatible upgrades that loosen or change consensus rules. Think of it like changing from left-hand to right-hand driving: if a driver doesn't switch, they simply can't operate safely on the new roads. Everyone has to upgrade or they'll keep driving on the old side, which becomes a separate road network. Bitcoin avoids this because coordinating such a complete transition is risky and can permanently split the network. Hard forks are extremely rare in Bitcoin due to coordination challenges and the risk of permanent network splits.
A notable example is Bitcoin Cash (BCH), created in 2017 by changing rules (notably much larger blocks). In practice, that approach fractured liquidity and community mindshare. Over time, BCH has retained only a small fraction of Bitcoin's adoption, hashpower, and market value. Most users, developers, miners, and exchanges coordinated on the original smaller-block BTC chain as the main “Bitcoin,” largely because it kept it cheaper and easier for ordinary people to run full nodes and verify the chain themselves. Critically, though, deciding what's the "real Bitcoin" isn't something the code can decree since there is no central authority. It's a messy blend of social consensus (what users, exchanges, wallets, and merchants run), economic gravity (where liquidity settles), and security assumptions (what most full nodes enforce). Markets have decidedly treated BTC as the Schelling point, but that outcome is ultimately social, not ordained.
Soft Forks
Soft forks are backward compatible protocol upgrades that tighten consensus rules without breaking the network. Think of it like adding a new traffic rule that existing drivers automatically comply with: upgraded nodes enforce stricter rules (like "no right turn on red at this intersection"), while non-upgraded nodes still see all traffic as valid and the network continues functioning normally. Non upgraded Bitcoin nodes still see new blocks as valid but don't enforce the stricter rules themselves, allowing the network to upgrade without splitting into incompatible versions. They require majority support to avoid chain splits, with examples including SegWit and Taproot.
Activation Mechanisms
Deciding to implement a soft fork is one thing, but actually activating it across the network requires careful coordination. The network needs a way to measure readiness and ensure enough participants have upgraded before the new rules take effect. This is where activation mechanisms come in. Different methods have been developed to balance miner coordination, economic node participation, and the risk of chain splits.
Miner Activated Soft Forks (MASF) rely on hash power signaling; miners indicate readiness by including version bits in block headers. BIP9 was the standard MASF framework, requiring a high threshold (typically 95%) of blocks to signal support during defined time windows. Once the threshold is reached, the soft fork locks in and activates after a grace period. This was used for upgrades like SegWit (eventually) and most historical soft forks.
User Activated Soft Forks (UASF) represent an alternative where economic nodes coordinate a "flag day" to start enforcing tighter rules, potentially regardless of miner signaling. If enough economic nodes and service providers participate, miners face a simple incentive: follow the new rules to get paid, or mine a chain most users won't accept.
Speedy Trial is a short miner signaling trial with a 90% threshold over 2,016 block windows. If it locks in, activation occurs later at a preset block height; if it times out, no activation occurs and other mechanisms can be considered. This method was successfully used for Taproot activation in 2021.
The Challenge of Change
Despite backward compatibility, getting any soft fork into Bitcoin is intentionally difficult. Many developers prioritize protocol ossification, the idea that Bitcoin should become increasingly resistant to change as it matures. This conservative approach recognizes a counter-intuitive strength: Bitcoin's power comes partly from what it doesn't do. By changing rarely, Bitcoin becomes predictable. Users can trust that the monetary policy won't be altered. The fewer changes made, the lower the risk of introducing bugs or unintended consequences that could compromise a multi-trillion-dollar asset.
There's also an economic feedback loop at play: as Bitcoin's market cap grows and more economic activity depends on it, the threshold for "this upgrade is worth the risk" rises accordingly. A $100 billion asset might tolerate experimentation; a $2 trillion asset demands extreme conservatism. This isn't a bug, it's a feature that naturally protects the base layer as its importance increases.
This philosophy means proposals undergo years of review, testing, and community debate.
Bitcoin's Major Upgrades
Segregated Witness (SegWit, 2017)
The SegWit activation saga represents one of the most important case studies in Bitcoin's governance, demonstrating how protocol upgrades work (and sometimes don't work) in a truly decentralized system.
SegWit was a landmark upgrade that solved multiple critical issues. Before SegWit, Bitcoin had a critical bug: third parties could alter a transaction's signature and change its ID (TXID) before confirmation, without affecting the transaction's validity. This transaction malleability made it risky to build dependent transactions or second layer protocols like Lightning.
SegWit moved signature data to a separate "witness" structure, making transaction IDs immutable once created. It also introduced block weight (a new measurement system with a 4,000,000 weight unit maximum instead of a simple 1MB limit). This effectively increased block capacity while incentivizing adoption of more efficient SegWit addresses. The weight system counts witness data as one quarter for weight calculation (commonly described as a "75% discount"), creating a backwards compatible blocksize increase.
To understand the political dynamics, it's helpful to think of pre SegWit Bitcoin as "Bitcoin 1.0" (a system with a hard 1MB blocksize limit and transaction malleability issues). SegWit represented "Bitcoin 1.1" (mostly backwards compatible with Bitcoin 1.0, but fixing protocol bugs and enabling second layer networks while providing a one time capacity increase).
The original activation mechanism was a MASF using BIP9 with a 95% threshold: during any 2,016 block difficulty adjustment period within the window from November 15, 2016 to November 15, 2017, if 95% or more of mined blocks signaled support, the upgrade would lock in. After a grace period, SegWit would activate and the network would accept the new transaction types.
To understand what happened next, some context is needed. Bitcoin had been debating how to scale for years. Some factions wanted to increase the block size limit dramatically through a hard fork (which eventually led to the creation of Bitcoin Cash), while others preferred SegWit's approach of fixing transaction malleability and enabling second-layer solutions like Lightning Network. This disagreement became known as the "blocksize wars."
Some large miners opposed SegWit because they preferred simply increasing block sizes. Even though SegWit had widespread support from developers, businesses, and node operators, these miners could block activation by refusing to signal. The BIP9 mechanism had assumed that signaling meant "my software is technically ready," but these miners were treating it as a political vote. This created an unprecedented governance crisis where a coordinated group of miners could indefinitely veto a beneficial upgrade, even though the upgrade didn't require their technical participation to function.
BIP 148 represented a proposed solution to this governance deadlock. BIP 148 changed consensus rules for participating nodes by rejecting any non-signaling blocks after August 1st, 2017. If enough economic nodes (exchanges, services, businesses) ran BIP 148, miners faced a stark choice: signal SegWit support and get paid in bitcoin that the broader economy would accept, or mine a chain that major economic actors would ignore.
The threat of BIP 148 created powerful economic incentives that ultimately resolved the impasse. BIP 91 locked in on July 21, 2017 and activated two days later, enforcing that miners signal bit 1 and enabling BIP 141 to reach its threshold. With BIP 148's flag day planned for August 1st, the pressure was on. SegWit (BIP 141) locked in on August 9, 2017 and activated on August 24, 2017 at block 481,824. BIP 91 served as an intermediate solution that allowed miners to signal SegWit support before the UASF deadline, and SegWit successfully activated via the original BIP9 mechanism.
The SegWit activation demonstrates several crucial principles about Bitcoin governance. Economic nodes ultimately enforce protocol rules when sufficiently coordinated, reinforcing the power dynamics between miners and users. Soft forks can be enforced by users when there's sufficient economic coordination, even against miner resistance. Credible threats matter more than actual deployment, as BIP 148 succeeded largely because the threat was believable rather than because a majority of nodes actually ran it. Finally, Bitcoin's governance proved antifragile: the system found a way to route around the blockade and activate beneficial upgrades despite coordinated resistance.
Taproot (2021)
The Taproot upgrade significantly improved programmability and confidentiality. Unlike SegWit's contentious activation, Taproot enjoyed broad consensus across miners, developers, and economic nodes. However, even with this agreement, the upgrade still required several years of active community discussion, careful review, and coordination to ensure the changes were thoroughly vetted and safely deployed.
Taproot used the Speedy Trial activation mechanism with a 90% miner signaling threshold. The signaling period began in May 2021, and the threshold was quickly met, with the upgrade locking in during June 2021. After a predetermined grace period to allow remaining nodes to upgrade, Taproot activated in November 2021 at block 709,632. The smooth activation demonstrated that when there's genuine consensus, Bitcoin can upgrade efficiently while still maintaining its cautious, deliberate approach to protocol changes.
The technical improvements were substantial. Schnorr Signatures enable key and signature aggregation, allowing complex multi-party transactions to appear as single signatures on-chain. Merkleized Abstract Syntax Trees (MAST) structure complex spending conditions efficiently, where only the condition that's met needs to be revealed.
Together, these features provide major benefits: complex transactions become indistinguishable from simple payments for key path spends, delivering significant privacy and scalability improvements. When script path spends are used, only the revealed branch is disclosed, maintaining privacy for unused conditions.