🔀 Upgrade Mechanisms

Soft Fork (Bitcoin’s Approach)

Definition: Backward-compatible protocol change. Old nodes continue functioning; new rules are stricter subset of old rules.

Mechanism:

• New rules add constraints (never remove them)
• Transactions valid under new rules are also valid under old rules (but not vice versa)
• Old nodes see new transactions as “anyone-can-spend” or otherwise valid
• Network splits avoided—majority hash rate enforcement sufficient

Examples: SegWit (BIP141), Taproot (BIP340/341/342), P2SH (BIP16)

Hard Fork (Ethereum’s Frequent Approach)

Definition: Non-backward-compatible protocol change. Requires all nodes to upgrade or split into separate chains.

Mechanism:

• Changes consensus rules fundamentally
• Transactions valid under new rules may be invalid under old rules
• Creates permanent network split if not unanimous
• Requires coordinated flag-day upgrade

Examples: Bitcoin Cash fork (2017), Ethereum’s The Merge (2022), block size wars

🔧 How SegWit Works

Core Innovation: Separate transaction data into two parts:

1. Transaction data (base): Inputs, outputs, amounts, locktime
2. Witness data (segregated): Signatures and scripts proving spending authority

Transaction ID Calculation:

// Pre-SegWit (vulnerable)
txid = SHA256(SHA256(entire_transaction_including_signatures))

// Post-SegWit (fixed)
txid = SHA256(SHA256(base_transaction_ONLY))  // Excludes witness data
wtxid = SHA256(SHA256(base_transaction + witness_data))  // Separate commitment

Result:

• Txid cannot be changed by modifying signatures (signatures excluded from txid)
• Witness data separately committed in block (witness root in coinbase)
• Old nodes see SegWit transactions as “anyone-can-spend” (appear valid, don’t verify witness)
• New nodes enforce witness rules (verify signatures normally)

🔑 ECDSA vs. Schnorr

Why Replace ECDSA?

• ECDSA chosen in 2009 because it was patent-free (Schnorr patent expired only in 2008)
• ECDSA has signature malleability issues (required SegWit fix)
• Schnorr offers superior mathematical properties

Schnorr Advantages:

1. Linearity (Key Aggregation)

Property: Signatures and keys can be mathematically combined

// Multiple keys → Single aggregate key
PubKey_Combined = PubKey_A + PubKey_B + PubKey_C

// Multiple signatures → Single aggregate signature
Signature_Combined = Signature_A + Signature_B + Signature_C

// Verification
verify(PubKey_Combined, Message, Signature_Combined) → True

Impact: Multi-sig (2-of-3, 3-of-5, etc.) looks identical to single-sig on-chain. Same size, same privacy.

2. Smaller Signatures

• ECDSA signature: (r, s) = 64 bytes + 8-9 bytes DER encoding = 72-73 bytes
• Schnorr signature: (R, s) = 64 bytes (no DER encoding needed)
• Savings: ~10% smaller signatures, compounds with batch verification

3. Provable Security

• Schnorr has formal security proof (secure under discrete logarithm assumption)
• ECDSA security not formally proven (still believed secure, just less elegant proof)
• Schnorr’s simplicity reduces implementation complexity → fewer bugs

4. Batch Verification

• Can verify multiple Schnorr signatures simultaneously faster than verifying individually
• Speedup: ~2x faster for batch verification vs individual verification
• Benefit: Nodes validate blocks faster, improving network sync time

🌲 Complex Scripts Without Revealing Complexity

Pre-Taproot Problem:

• Complex scripts (multi-sig with fallbacks, timelocks, etc.) expose ALL conditions on-chain when spending
• Example: “Alice + Bob, OR Alice after 1 year, OR 2-of-3 arbitrators”
• Entire script visible → privacy leak + wasted block space

MAST Solution:

1. Merkle Tree of Scripts:
   • Each spending condition is a leaf in Merkle tree
   • Root hash committed in output
2. Selective Revelation:
   • When spending, reveal ONLY the branch you’re using
   • Provide Merkle proof that it’s part of original tree
   • Other branches remain hidden
3. Privacy + Efficiency:
   • Unused scripts never touch blockchain
   • Complex multi-condition scripts same size as simple scripts
   • No way to tell how many alternative spending paths exist

Example:

// Spending conditions
Leaf A: Alice + Bob (normal operation)
Leaf B: Alice after 1 year (recovery if Bob disappears)
Leaf C: 2-of-3 arbitrators (dispute resolution)

// Merkle tree
       Root
      /    \
    Hash   Leaf C
   /    \
Leaf A  Leaf B

// When Alice + Bob spend (normal case)
Reveal: Leaf A + Merkle proof (Hash, Leaf C hashes)
Hidden: Leaf B, Leaf C scripts (privacy preserved!)

🎭 The Privacy Principle

Privacy Problem (Pre-Taproot):

• Single-sig transactions look different from multi-sig
• Lightning channels identifiable by transaction patterns
• Complex scripts expose all conditions on-chain
• Chain analysis can identify: wallet types, use cases, participant counts

Taproot Solution:

• Key-path spending: All cooperative transactions look identical
• No distinguishing features: Single pubkey, single signature
• Indistinguishable transactions:
  • 2-of-2 multi-sig = single-sig payment
  • Lightning channel = normal payment
  • 3-of-5 threshold signature = simple transfer
  • Complex escrow with timelocks = basic transaction
• Anonymity set grows: All Taproot transactions share same appearance → harder to deanonymize

🚀 Near-Term Possibilities

1. Cross-Input Signature Aggregation

Concept: Aggregate signatures across multiple inputs in single transaction

Benefit: Further reduce transaction size (~30% smaller for multi-input transactions)

Status: Requires new BIP, research ongoing

2. SIGHASH_ANYPREVOUT (APO)

Concept: Signature flag allowing signature to be valid for any input (eltoo for Lightning)

Benefit: Enables better Lightning channel designs, reduces complexity

Status: BIP118 proposed, awaiting consensus

3. Covenants (OP_CTV / OP_CAT)

Concept: Script opcodes enabling spending conditions on outputs (not just inputs)

Benefit: Vaults, better Lightning, congestion control, DeFi primitives

Status: Multiple competing proposals (OP_CHECKTEMPLATEVERIFY, OP_CAT restoration), contentious debate

4. Post-Quantum Signatures

Concept: Integrate post-quantum cryptography (CRYSTALS-Dilithium, FALCON)

Benefit: Protection against quantum computers

Status: Research phase, 10-20 year timeline before urgency