Activation date: November 14, 2021 (Block 709,632)
Upgrade method: Soft fork (Speedy Trial)
Core technologies: Schnorr Signatures + MAST + Tapscript
Primary goals: Privacy + Efficiency + Smart Contract Enhancement

Traditional ECDSA vs. New Schnorr:

ECDSA (Traditional):
- Signature length: 71-73 bytes
- Multisig complexity: Requires multiple signatures
- Poor privacy: Easy to identify multisig transactions

Schnorr (Taproot):
- Signature length: 64 bytes (fixed)
- Signature aggregation: Multiple signatures -> One signature
- Enhanced privacy: Multisig looks like single-sig

Problem: Complex scripts expose all conditions
Solution: Only reveal the execution path actually used

Traditional P2SH script:
IF
  Alice's signature AND Bob's signature    # Condition 1
ELSE
  Timelock AND Charlie's signature         # Condition 2
ENDIF

MAST script:
Default: Alice single-sig (most common use)
Fallback: Merkle tree root (containing other complex conditions)
-> Only the condition actually used is revealed on-chain

Traditional multisig (ECDSA):
Transaction = {
  Inputs: [Signature1, Signature2, Signature3],
  Outputs: [...]
}

Schnorr multisig (aggregated):
Transaction = {
  Inputs: [AggregatedSignature],  <- 3 signatures merged into 1
  Outputs: [...]
}

1. Choose random number k
2. Compute R = k * G (G is the generator point)
3. Compute e = hash(R || P || m) (P is the public key, m is the message)
4. Compute s = k + e * x (x is the private key)
5. Signature = (R, s)

1. Compute e = hash(R || P || m)
2. Verify: s * G = R + e * P

2-of-3 multisig comparison:

ECDSA:
- 2 signatures: 2 x 71 bytes = 142 bytes
- 2 public keys: 2 x 33 bytes = 66 bytes
- Total: 208 bytes

Schnorr:
- 1 aggregated signature: 64 bytes
- 1 aggregated public key: 33 bytes
- Total: 97 bytes

Savings: (208 - 97) / 208 ~ 53%

Traditional multisig transaction characteristics:
- Obvious multisig address format
- Multiple signatures reveal number of participants
- Easy to identify corporate wallets

Taproot multisig transactions:
- Looks like an ordinary single-sig transaction
- Cannot determine from the transaction itself whether it's multisig
- Protects business privacy

Traditional P2SH multisig script:
IF
  Alice's signature AND Bob's signature    # Condition 1: Daily use
ELSE
  Timelock AND Charlie's signature         # Condition 2: Emergency
ELSE
  Inheritance conditions                    # Condition 3: Estate inheritance
ENDIF

Problems:
- All conditions are exposed on-chain
- Poor privacy
- High fees (storing all conditions)

MAST structure:
Default path: Alice single-sig (most common)
Fallback paths: Merkle tree root (containing other conditions)

Actual usage:
Daily transfer: Only reveals Alice's signature
Emergency: Reveals timelock + Charlie's signature + path proof
Inheritance: Reveals inheritance conditions + path proof

Assume 4 conditions: A, B, C, D

Level 2: Hash(A+B), Hash(C+D)
Level 1: Hash(Hash(A+B) + Hash(C+D)) = Merkle Root

Address = Hash(Internal Public Key + Merkle Root)

When using condition A:
Need to provide: A + Path Proof (proving A is in the tree)
Path proof: Hash(B), Hash(Hash(C+D))

Verification:
1. Compute Hash(A+B)
2. Compute Hash(Hash(A+B) + Hash(Hash(C+D)))
3. Verify it equals the Merkle Root

Information exposed by traditional methods:
- All possible execution conditions
- Number of participants
- Business logic structure

Information hidden by MAST:
- Only the condition actually used is revealed
- Other conditions remain private
- Cannot infer the complete logic

Privacy comparison:

Traditional multisig (2-of-3):
Address: 3AnNyxwq... (P2SH)
-> Clearly identifiable as multisig
-> Script exposes all conditions

Taproot multisig:
Address: bc1p5d7rj... (P2TR)
-> Looks like ordinary single-sig
-> Only known to be complex when spent

Benefits:
- Transaction privacy greatly increased
- On-chain analysis more difficult
- User privacy protected

Traditional enterprise multisig:
- Address format reveals multisig characteristics
- Transaction patterns easily identified
- Business activities are transparent

Taproot enterprise multisig:
- Looks like a personal wallet
- Cannot determine enterprise nature from address
- Protects business privacy

Traditional inheritance script:
"My single-sig OR (Timelock AND Heir's signature)"
-> Exposes the inheritance logic

Taproot inheritance:
Default: My single-sig (daily use)
Fallback: Inheritance conditions (hidden)
-> Daily use only reveals single-sig

Data size comparison:

Traditional 2-of-3 multisig:
- Script size: ~105 bytes
- Signature data: ~144 bytes (2 signatures)
- Total overhead: ~249 bytes

Taproot multisig (aggregated signatures):
- Script size: 32 bytes (only public key hash)
- Signature data: 64 bytes (aggregated single signature)
- Total overhead: ~96 bytes

Savings: (249 - 96) / 249 ~ 61% space!

Fee calculation comparison:

Traditional multisig transaction:
Fee = 249 bytes x Fee rate

Taproot multisig transaction:
Fee = 96 bytes x Fee rate

Savings: ~61% in fees

Schnorr signature verification:
- Faster than ECDSA
- Supports batch verification
- Reduces computational overhead

Smaller transaction sizes:
- Faster propagation
- Lower network load
- Higher throughput

New opcodes introduced by Taproot:
- OP_CHECKSIGADD: Supports Schnorr signature verification
- OP_TAPBRANCH: Supports script paths
- OP_TAPLEAF: Supports leaf node operations

Traditional script limitations:
- Fixed script structure
- Limited combination methods
- Poor privacy

Tapscript advantages:
- More flexible script combinations
- Better privacy protection
- More efficient execution

Lightning Network channels:
- Use Taproot for improved privacy
- Channel closings look like ordinary transfers
- Reduced on-chain footprint

DeFi contracts:
- Complex DeFi logic appears simplified on-chain
- Protects user privacy
- Reduces fees

Timelocks:
- More flexible time conditions
- Better privacy protection
- Lower fees

json
// Taproot transaction example
{
  "vin": [
    {
      "txid": "abc123...",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "witness": [
        "signature_64_bytes"  // <- Concise Schnorr signature
      ]
    }
  ],
  "vout": [
    {
      "value": 0.01000000,
      "scriptPubKey": {
        "asm": "OP_1 5d7rjc4k3m8n9p0q1r2s3t4u5v6w7x8y9z",
        "type": "witness_v1_taproot",       // <- Taproot type
        "address": "bc1p5d7rjc4k3m8n..."   // <- Starts with bc1p
      }
    }
  ]
}

python
import requests
import json

def bitcoin_rpc(method, params=[]):
    url = "http://localhost:8332"
    headers = {'content-type': 'application/json'}

    payload = {
        "method": method,
        "params": params,
        "jsonrpc": "2.0",
        "id": 0,
    }

    response = requests.post(url, data=json.dumps(payload), headers=headers, auth=('user', 'password'))
    return response.json()

def create_taproot_address():
    # Generate a new Taproot address
    result = bitcoin_rpc("getnewaddress", ["", "bech32m"])

    print(f"Taproot Address: {result['result']}")
    return result['result']

# Execute Taproot address creation
taproot_address = create_taproot_address()

python
def create_taproot_multisig(pubkeys, required_signatures):
    """Create a Taproot multisig wallet"""

    # Create multisig address
    result = bitcoin_rpc("createmultisig", [required_signatures, pubkeys, "bech32m"])

    print(f"Taproot Multisig Address: {result['result']['address']}")
    return result['result']

def sign_taproot_transaction(raw_tx, private_keys):
    """Sign a Taproot transaction"""

    # Use Schnorr signature
    signed_tx = bitcoin_rpc("signrawtransaction", [raw_tx, [], private_keys])

    return signed_tx['result']['hex']

# Usage example
pubkeys = ["pubkey1", "pubkey2", "pubkey3"]
multisig_info = create_taproot_multisig(pubkeys, 2)

python
def create_mast_script(internal_key, merkle_root):
    """Create a MAST script"""

    # Build Taproot address
    taproot_address = bitcoin_rpc("createtaproot", [internal_key, merkle_root])

    return taproot_address['result']['address']

def spend_mast_script(script_path, path_proof):
    """Spend a MAST script"""

    # Provide script path and proof
    witness = [script_path] + path_proof

    return witness

Compatibility features:
- Soft fork upgrade
- Old nodes can validate Taproot transactions
- Gradual adoption
- No network split

Security analysis:
- Mathematically provably secure
- More secure than ECDSA
- Years of academic research
- Already validated in other projects

Privacy improvement mechanism:
- Only reveals the condition actually used
- Other conditions remain hidden
- Cannot infer complete logic
- Protects business privacy

Address format:
- Prefix: bc1p
- Length: 62 characters
- Encoding: Bech32m
- Note: Case-sensitive

Migration strategy:
1. Use Taproot for new addresses
2. Gradually transfer funds
3. Update wallet software
4. Enjoy new features

Ordinals applications:
- Uses Taproot for data storage
- Better privacy
- Lower fees
- Larger data capacity