Before We Begin: Think About Protocol Governance
Bitcoin has no CEO, no board of directors, no formal governance structure. Yet it evolves and improves. How is this possible?
No one can force nodes to upgrade. So how do new features get adopted across the network?
Both change Bitcoin's rules, but one is backward compatible and one isn't. Why does this matter?
There's no "suggestion box" at Bitcoin HQ. What's the process for suggesting changes?
These were widely desired improvements. Why the slow rollout compared to traditional software?
Bitcoin's answer: Bitcoin Improvement Proposals (BIPs)
The BIP Process: How Bitcoin Evolves
Bitcoin Improvement Proposals (BIPs) are the primary mechanism for proposing changes to Bitcoin's protocol, applications, and processes. They provide a formal, documented way for the community to discuss and evaluate potential improvements.
What is a BIP?
A BIP is a design document that:
- Describes a new feature or change to Bitcoin
- Provides technical specifications
- Explains the rationale and motivation
- Documents discussion and consensus-building
- Serves as permanent documentation if implemented
BIP Types
| Type | Description | Examples |
|---|---|---|
| Standards Track | Changes to the Bitcoin protocol, network, or validation rules | BIP 141 (SegWit), BIP 340-342 (Taproot) |
| Informational | Design issues, guidelines, or information for community | BIP 39 (Mnemonic seeds) |
| Process | Changes to Bitcoin development processes | BIP 2 (BIP process itself) |
BIP Lifecycle
Initial proposal written and submitted to BIPs repository. Open for feedback and discussion.
Proposal is complete and ready for community review. Discussion continues.
BIP has been implemented and activated on the network. No longer changing.
Proposal doesn't gain consensus or is withdrawn by author.
How to Read a BIP
Every BIP follows a standard structure:
BIP: [number]
Title: [descriptive title]
Author: [names and emails]
Status: [Draft/Proposed/Final/etc]
Type: [Standards Track/Informational/Process]
Created: [date]
License: [license type]
Abstract
--------
Brief summary of what the BIP proposes
Motivation
----------
Why is this change needed? What problem does it solve?
Specification
-------------
Detailed technical description of the change
Rationale
---------
Why this approach over alternatives?
Backward Compatibility
----------------------
How does this affect existing systems?
Reference Implementation
------------------------
Link to code implementing this BIPPractice: Read Your First BIP
Go to github.com/bitcoin/bips and read BIP 32: Hierarchical Deterministic Wallets.
As you read, identify:
- What problem does it solve?
- What are the key technical innovations?
- Why is this better than previous approaches?
- Are there any tradeoffs or limitations?
Soft Forks vs Hard Forks
Understanding the difference between soft forks and hard forks is crucial for Bitcoin development. It's not just technical—it's about how changes can (or can't) be deployed in a decentralized network.
Hard Fork: Breaking Change
A hard fork makes previously invalid blocks/transactions valid. Old nodes will reject new blocks, causing a permanent chain split.
| Characteristic | Details |
|---|---|
| Compatibility | NOT backward compatible. Old nodes reject new blocks. |
| Activation | Requires ALL nodes to upgrade or be left on old chain |
| Risk | HIGH - Can split network, create two coins |
| Examples | Increasing block size, changing PoW algorithm |
| Used in Bitcoin? | Extremely rare - last scheduled hard fork was in 2013 |
Example of a hard fork change:
// Increasing block size from 1MB to 2MB
// Old rule: blocks > 1MB are invalid
if (block.size > 1_000_000) {
return false; // INVALID
}
// New rule: blocks up to 2MB are valid
if (block.size > 2_000_000) {
return false; // INVALID
}
// Problem: Old nodes reject new 1.5MB blocks → chain split!Soft Fork: Backward Compatible Change
A soft fork makes previously valid blocks/transactions invalid (stricter rules). Old nodes still accept new blocks, remaining compatible.
| Characteristic | Details |
|---|---|
| Compatibility | Backward compatible. Old nodes accept new blocks. |
| Activation | Only requires majority of miners to upgrade |
| Risk | LOWER - Network stays unified |
| Examples | SegWit, Taproot, P2SH, CLTV, CSV |
| Used in Bitcoin? | Preferred method for protocol upgrades |
Example of a soft fork change:
// Adding new script opcode via soft fork
// Old rule: Any script is potentially valid
// New rule: OP_CHECKSEQUENCEVERIFY must pass new check
// Old nodes see new transactions as "anyone can spend"
// But miners enforce the new rule
// So old nodes still accept blocks with new transactions
// Result: Network stays unified, new feature deployed!⚠️ Why Bitcoin Avoids Hard Forks
Hard forks require coordinating thousands of independent node operators to upgrade simultaneously. This is:
- Nearly impossible in a decentralized system
- Creates risk of permanent chain splits
- Can be exploited for contentious changes
- Reduces nodes' ability to independently validate rules
Bitcoin's principle: Your node, your rules. Soft forks preserve this by making changes opt-in while maintaining network unity.
Case Study: Segregated Witness (SegWit)
Segregated Witness
The Problem:
Bitcoin faced several issues that SegWit addressed:
- Transaction Malleability: Transaction IDs could change before confirmation
- Block Size Limitation: 1MB block limit constraining transaction capacity
- Signature Data Overhead: Signatures took up ~65% of transaction data
- Script Versioning: Hard to deploy new script features
The Solution:
SegWit separated (segregated) the signature data (witness) from transaction data:
// Before SegWit - Signature included in transaction
Transaction {
inputs: [...],
outputs: [...],
signatures: [...] // Part of transaction hash
}
// After SegWit - Signature separated
Transaction {
inputs: [...],
outputs: [...]
}
Witness {
signatures: [...] // Separate, not in transaction hash
}Benefits Achieved:
- Fixed malleability: Txid no longer includes signatures
- Increased capacity: ~1.8MB effective block size
- Lower fees: Witness data gets 75% discount
- Enabled Lightning: Made payment channels practical
- Script versioning: Enabled future upgrades (like Taproot)
Why It's a Soft Fork:
SegWit transactions appear as "anyone can spend" to old nodes. But miners enforcing new rules prevent actual spending without proper signatures. Old nodes still validate blocks, just with reduced security guarantees.
SegWit Activation Timeline
BIP 141 proposed by Pieter Wuille
SegWit merged into Bitcoin Core 0.13.1
Signaling period - miners vote for activation (contentious!)
SegWit activated at block 481,824 (95% miner support achieved)
Gradual adoption - now ~85%+ of transactions use SegWit
Lessons from SegWit
- Consensus building takes time - even for good ideas
- Soft forks are technically backward compatible, but adoption is gradual
- Protocol changes are political as much as technical
- The Bitcoin community values caution over speed
Case Study: Taproot & Schnorr Signatures
Taproot Upgrade
Three BIPs, One Upgrade:
- BIP 340: Schnorr signatures for secp256k1
- BIP 341: Taproot (SegWit v1 output spending rules)
- BIP 342: Tapscript (new scripting language)
Key Innovations:
1. Schnorr Signatures (BIP 340)
Replaced ECDSA with Schnorr signatures, enabling:
- Signature aggregation: Combine multiple signatures into one
- Smaller size: More compact than ECDSA
- Provable security: Stronger mathematical foundation
- Better privacy: Multi-sig looks like single-sig
// Before: 2-of-3 multisig requires 2 separate signatures
scriptPubKey: OP_2 OP_3 OP_CHECKMULTISIG
scriptSig:
// After: Schnorr MuSig - single aggregated signature
scriptPubKey: OP_CHECKSIG
scriptSig:
// Same security, smaller size, better privacy! 2. Taproot (BIP 341)
Allows complex scripts to look like simple payments, improving privacy and efficiency:
- Most outputs look identical on-chain
- Only reveal script conditions when spending via that path
- Can have multiple spending paths (scripts) in one output
- Simple case (key path) is very efficient
// Taproot output can be spent via:
// 1. Key path (most common): Simple signature
// 2. Script path: Reveal one of many possible scripts
// Example: Lightning channel
// Key path: Both parties agree (cooperative close)
// Script path: Timelock recovery (uncooperative close)
// On-chain, both look identical until spent!3. Tapscript (BIP 342)
New version of Bitcoin Script with improvements:
- Signature operations use Schnorr
- OP_CHECKSIGADD for batch verification
- Removed 10,000 op limit
- Future upgradability via OP_SUCCESSx opcodes
Taproot Activation Timeline
Pieter Wuille proposes Schnorr signatures
BIPs 340-342 published
Merged into Bitcoin Core 0.21.0
Speedy Trial activation method - 90% miner signaling threshold achieved
Taproot activated at block 709,632
Growing adoption - wallet/exchange support expanding
Lessons from Taproot
- Taproot learned from SegWit - smoother activation process
- "Speedy Trial" gave miners/community clear timeframe to signal
- Bundling related improvements (Schnorr + Taproot + Tapscript) reduced coordination overhead
- Privacy and efficiency improvements encourage adoption
- Forward compatibility designed in from the start
Soft Fork Activation Mechanisms
How does a soft fork actually activate across the network? Bitcoin has tried several methods:
1. Flag Day Activation
Activate at a specific block height or time, regardless of miner support.
- Pro: Simple, predictable
- Con: No signal of readiness, risk of chain split if controversial
- Used for: Early Bitcoin upgrades (P2SH)
2. IsSuperMajority (ISM)
Activate when 950 of last 1,000 blocks signal readiness (95% threshold).
- Pro: Measures miner readiness
- Con: No timeout, could stall forever
- Used for: BIP 66 (strict DER signatures), BIP 65 (CLTV)
3. BIP 9 (Version Bits)
95% miner signaling within defined time window. Fails if threshold not met by timeout.
- Pro: Multiple forks can be deployed in parallel
- Con: Can fail if miners don't signal (SegWit issue)
- Used for: BIP 68, 112, 113 (CSV)
4. BIP 148 (UASF - User Activated Soft Fork)
Users run nodes that reject blocks not signaling for upgrade (controversial!).
- Pro: Gives users/nodes power, not just miners
- Con: Risk of chain split if miners don't comply
- Used for: Pressured SegWit activation (combined with BIP 91)
5. Speedy Trial
Short signaling period (~3 months), 90% threshold. If successful, activates after 6-month delay.
- Pro: Fast feedback, clear timeline, lower threshold than BIP 9
- Con: Only works for non-controversial changes
- Used for: Taproot (BIP 341)
There's No Perfect Activation Method
Each method balances:
- Speed vs. safety
- Miner signaling vs. user choice
- Predictability vs. flexibility
- Coordination vs. decentralization
The "right" method depends on the specific upgrade and community consensus.
Hands-On Exercise: BIP Analysis
Goal: Learn to analyze and understand BIPs
Tasks:
- Pick one BIP from each category:
- Consensus change (e.g., BIP 65 - CHECKLOCKTIMEVERIFY)
- Wallet standard (e.g., BIP 84 - Native SegWit derivation)
- Process (e.g., BIP 2 - BIP process)
- For each BIP, answer:
- What problem does it solve?
- What is the proposed solution?
- Is it a soft fork, hard fork, or neither?
- What are the tradeoffs?
- Has it been implemented? When?
- Compare SegWit and Taproot activation:
- How long did each take from proposal to activation?
- What activation method was used?
- Were there controversies? How were they resolved?
Bonus Challenge:
- Find a BIP currently in Draft status and read the discussion
- Identify what concerns/questions people have
- Form your own opinion: Would you support this BIP?
Key Takeaways
- BIPs are Bitcoin's formal proposal process for changes and improvements
- Three BIP types: Standards Track, Informational, Process
- Hard forks break backward compatibility; soft forks maintain it
- Bitcoin strongly prefers soft forks to maintain network unity
- SegWit fixed malleability, increased capacity, enabled Lightning
- Taproot brought Schnorr signatures, better privacy, and script efficiency
- Activation mechanisms balance speed, safety, and decentralization
- Protocol changes take years - this is a feature, not a bug
- Consensus building is as important as technical merit
Essential Resources
- Bitcoin BIPs Repository - All Bitcoin Improvement Proposals
- BIPs.dev - Searchable BIP database
- Bitcoin Optech - Weekly newsletter on Bitcoin tech
- Bitcoin Core BIP Support - Which BIPs are implemented
- Bitcoin Wiki: Soft Fork