Bitcoin Security Layers:

┌─────────────────────────────────────────────────────────────────────┐
│                     Layer 1: Cryptographic Security                │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │  • Hash Functions (SHA-256, RIPEMD-160)                   │   │
│  │  • Public-Key Cryptography (ECDSA, secp256k1)             │   │
│  │  • Digital Signatures (Transaction signing)               │   │
│  │  • Merkle Trees (Transaction integrity)                   │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                   │
│                     Layer 2: Consensus Security                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │  • Proof-of-Work (Mining)                                 │   │
│  │  • Difficulty Adjustment                                  │   │
│  │  • Longest Chain Rule                                     │   │
│  │  • Block Validation                                      │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                   │
│                     Layer 3: Economic Security                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │  • Block Rewards                                          │   │
│  │  • Transaction Fees                                       │   │
│  │  • Mining Profitability                                   │   │
│  │  • Cost of Attacks                                       │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                   │
│                     Layer 4: Network Security                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │  • P2P Network Architecture                               │   │
│  │  • Node Validation                                       │   │
│  │  • Propagation Mechanisms                                │   │
│  │  • Sybil Resistance                                      │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

Security Properties:

1. Integrity:
   - Transactions cannot be modified after confirmation
   - Block chain is immutable
   - Merkle roots verify transaction sets

2. Authenticity:
   - Only key holder can spend bitcoins
   - Digital signatures prove ownership
   - Non-repudiation of transactions

3. Availability:
   - Network operates 24/7/365
   - No single point of failure
   - Censorship-resistant

4. Finality:
   - Confirmed transactions are irreversible
   - More confirmations = stronger finality
   - Economic finality via mining

5. Permissionless:
   - Anyone can participate
   - No central authority
   - Open to all

SHA-256 Algorithm Deep Dive:

SHA-256 Parameters:
- Message Digest Size: 256 bits (32 bytes)
- Block Size: 512 bits (64 bytes)
- Word Size: 32 bits
- Number of Rounds: 64

SHA-256 Operation:

1. Message Padding:
   - Append '1' bit to message
   - Append '0' bits until length ≡ 448 mod 512
   - Append 64-bit representation of original message length

2. Initialize Hash Values (8 × 32-bit):
   h0 = 0x6a09e667
   h1 = 0xbb67ae85
   h2 = 0x3c6ef372
   h3 = 0xa54ff53a
   h4 = 0x510e527f
   h5 = 0x9b05688c
   h6 = 0x1f83d9ab
   h7 = 0x5be0cd19

3. Compression Function (64 rounds):
   For each 512-bit chunk:
     a. Create message schedule (64 × 32-bit words)
     b. Initialize working variables (a-h)
     c. Perform 64 rounds of compression
     d. Add to hash values

4. Message Schedule Expansion:
   For t = 0 to 15:
     W[t] = M[t]
   For t = 16 to 63:
     W[t] = σ1(W[t-2]) + W[t-7] + σ0(W[t-15]) + W[t-16]

   Where:
   σ0(x) = ROTR⁷(x) ⊕ ROTR¹⁸(x) ⊕ SHR³(x)
   σ1(x) = ROTR¹⁷(x) ⊕ ROTR¹⁹(x) ⊕ SHR¹⁰(x)

5. Compression Round:
   For each round (0-63):
     T1 = h + Σ1(e) + Ch(e,f,g) + K[t] + W[t]
     T2 = Σ0(a) + Maj(a,b,c)
     h = g
     g = f
     f = e
     e = d + T1
     d = c
     c = b
     b = a
     a = T1 + T2

   Where:
   Ch(x,y,z) = (x ∧ y) ⊕ (¬x ∧ z)
   Maj(x,y,z) = (x ∧ y) ⊕ (x ∧ z) ⊕ (y ∧ z)
   Σ0(x) = ROTR²(x) ⊕ ROTR¹³(x) ⊕ ROTR²²(x)
   Σ1(x) = ROTR⁶(x) ⊕ ROTR¹¹(x) ⊕ ROTR²⁵(x)

6. Add to Hash Values:
   h0 = h0 + a
   h1 = h1 + b
   ...
   h7 = h7 + h

7. Output:
   Concatenate h0 through h7 (256-bit hash)

Security Strength:
- Pre-image: 2²⁵⁶ operations
- Collision: 2¹²⁸ operations (birthday attack)
- Quantum: 2¹²⁸ operations (Grover's algorithm)

Double SHA-256:
Hash = SHA-256(SHA-256(data))

Why Double Hash?
1. Length Extension Attack Protection:
   - Single hash vulnerable to length extension
   - Double hash prevents this attack

2. Historical Reasons:
   - Bitcoin originally used single SHA-256
   - Changed to double for security

3. Consistency:
   - Merkle tree uses double hash
   - Block headers use double hash

4. Security:
   - Additional protection
   - No downside (minimal overhead)

Example - Block Header Hash:
Block_Header_Hash = SHA-256(SHA-256(Version || Prev_Hash || Merkle_Root || Timestamp || Difficulty || Nonce))

RIPEMD-160 Overview:
- Output Size: 160 bits (20 bytes)
- Developed by RACE Integrity Primitives Evaluation
- Used in Bitcoin address generation

RIPEMD-160 vs SHA-256:
- RIPEMD-160: 160-bit output
- SHA-256: 256-bit output
- Combined for address generation

Address Generation Flow:
Public Key (33/65 bytes)
     │
     ▼
SHA-256 (32 bytes)
     │
     ▼
RIPEMD-160 (20 bytes) → Public Key Hash
     │
     ▼
Add Version Byte (0x00 for Mainnet)
     │
     ▼
Double SHA-256 Checksum (4 bytes)
     │
     ▼
Base58Check Encoding
     │
     ▼
Bitcoin Address (34 characters)

Why RIPEMD-160?
- Shorter addresses (20 vs 32 bytes)
- User-friendly (shorter strings)
- Combined with SHA-256 for security
- Bitcoin addresses are 20 bytes + checksum

ECDSA Mathematics:

Domain Parameters (secp256k1):
- Prime p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
- Curve y² = x³ + 7 (mod p)
- Generator G = (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,
                  0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8)
- Order n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
- Cofactor h = 1

Key Generation:
1. Choose random private key d ∈ [1, n-1]
2. Compute public key Q = d × G (elliptic curve point multiplication)

Signing Process (Transaction):
1. Hash the transaction: z = SHA-256(SHA-256(tx_data))
2. Choose random nonce k ∈ [1, n-1]
3. Compute R = k × G
4. Compute r = R.x mod n
5. Compute s = k⁻¹ × (z + r × d) mod n
6. Signature = (r, s)

Verification Process:
1. Check 1 ≤ r ≤ n-1 and 1 ≤ s ≤ n-1
2. Compute z = hash(transaction)
3. Compute u₁ = z × s⁻¹ mod n
4. Compute u₂ = r × s⁻¹ mod n
5. Compute point = u₁ × G + u₂ × Q
6. Verify point.x == r (mod n)

Signature Security:
- k must be unique for each signature
- k must be truly random
- Reusing k reveals private key

k-Reuse Vulnerability:
If k is reused for two signatures:
s₁ = k⁻¹ × (z₁ + r × d) mod n
s₂ = k⁻¹ × (z₂ + r × d) mod n

Subtract: (s₁ - s₂) × k = z₁ - z₂
k = (z₁ - z₂) / (s₁ - s₂)
d = (s₁ × k - z₁) / r

Private key exposed!

Schnorr Signatures:

Benefits over ECDSA:
1. Simpler: No inverse needed in signing
2. Faster: More efficient verification
3. Linear: Supports signature aggregation
4. Provable: Security proof
5. Non-malleable: Fixed signature format

Schnorr Signing:
1. Choose random nonce k ∈ [1, n-1]
2. Compute R = k × G
3. Compute e = SHA-256(R || pubkey || message)
4. Compute s = k + e × d (mod n)
5. Signature = (R, s)

Schnorr Verification:
1. Compute e = SHA-256(R || pubkey || message)
2. Check: s × G == R + e × Q
3. If equal, signature is valid

Schnorr vs ECDSA Comparison:

| Feature | ECDSA | Schnorr |
|---------|-------|---------|
| **Signing** | s = k⁻¹(z + rd) | s = k + ed |
| **Verification** | Multiple steps | Single equation |
| **Aggregation** | Not possible | Yes (linear) |
| **Batch Verification** | Not possible | Yes (linear) |
| **Security Proof** | Heuristic | Provable |
| **Malleability** | Yes | No (non-malleable) |
| **Patent** | Free | Free |
| **Signature Size** | 64-72 bytes | 64 bytes |

Schnorr Key Aggregation:
- Multiple signers can create one signature
- Reduces block space
- More privacy (hides number of signers)

MuSig (Multi-Signature):
1. Individual public keys: Q₁, Q₂, ..., Qₙ
2. Aggregated key: Q_agg = Σ Qᵢ
3. Individual nonces: R₁, R₂, ..., Rₙ
4. Aggregated nonce: R_agg = Σ Rᵢ
5. Individual signatures: sᵢ = kᵢ + e × dᵢ
6. Aggregated signature: s_agg = Σ sᵢ
7. Final signature: (R_agg, s_agg)

Merkle Tree Construction:

Example with 4 Transactions:

Level 2 (Root):  Merkle Root = H(H₁₂ || H₃₄)
                      ┌──────┴──────┐
Level 1:          H₁₂ = H(H₁ || H₂)  H₃₄ = H(H₃ || H₄)
                   ┌──┴──┐          ┌──┴──┐
Level 0:         H₁      H₂        H₃      H₄
                 │        │         │        │
Transactions:   Tx₁      Tx₂       Tx₃      Tx₄

Hash Functions:
H₁ = SHA-256(SHA-256(Tx₁))
H₂ = SHA-256(SHA-256(Tx₂))
H₃ = SHA-256(SHA-256(Tx₃))
H₄ = SHA-256(SHA-256(Tx₄))
H₁₂ = SHA-256(SHA-256(H₁ || H₂))
H₃₄ = SHA-256(SHA-256(H₃ || H₄))
Merkle Root = SHA-256(SHA-256(H₁₂ || H₃₄))

Merkle Proof for Tx₃:
1. Provide Tx₃
2. Provide H₄ (sibling)
3. Provide H₁₂ (sibling at higher level)
4. Verifier computes:
   H₃ = Hash(Tx₃)
   H₃₄ = Hash(H₃ || H₄)
   Merkle Root' = Hash(H₁₂ || H₃₄)
5. Compare Merkle Root' with published Merkle Root

Proof Size = log₂(N) hashes
Where N = number of transactions

For 1,000,000 transactions:
Proof Size = log₂(1,000,000) ≈ 20 hashes
= 20 × 32 bytes = 640 bytes

UTXO Security Properties:

1. Immutable History:
   - Each UTXO has a creation transaction
   - Can trace back to genesis
   - No account balances to modify

2. Deterministic State:
   - UTXO set = all unspent outputs
   - State is clearly defined
   - No hidden balances

3. Atomic Operations:
   - Transaction either succeeds or fails
   - All inputs consumed or none
   - No partial updates

4. Double-Spend Protection:
   - UTXO can only be spent once
   - Network rejects second spend
   - Mining confirms first spend

UTXO Lifecycle Security:

Creation:
1. Transaction creates output(s)
2. Output added to UTXO set
3. Only valid if transaction is valid

Consumption:
1. Input references UTXO
2. Must provide correct signature
3. UTXO removed from set

Spent UTXO Security:
- Cannot be spent again
- Removed from UTXO set
- Immutable record of spend

Unspent UTXO Security:
- Protected by private key
- Cannot be accessed without signature
- Can be spent anytime

51% Attack:

Requirements:
1. Hash Power: >50% of network hash rate
2. Hardware: ASIC miners (billions of dollars)
3. Electricity: Megawatts of power
4. Time: Hours to days
5. Cost: Millions of dollars per day

Attack Success Probability:
- 51% hash power: ~100% (theoretical)
- 50.1% hash power: ~50% (probabilistic)
- 50% hash power: ~50% (random)

What Attack Can Do:
✓ Double-spend coins (limited)
✓ Censor transactions
✓ Mine empty blocks
✓ Orphan blocks from honest miners
✗ Reverse other people's transactions
✗ Create new coins (not allowed)
✗ Steal coins (without private keys)
✗ Change consensus rules

Attack Economics:
Cost = Hash_Power × Electricity + Hardware_Amortization
Current (2024):
- Hash Power: 500 EH/s
- Cost: ~$25M/day
- Duration: Days to weeks
- Total Cost: ~$100M+

Defense Mechanisms:
1. Economic Disincentive (costly)
2. Increasing Confirmations (6+ blocks)
3. Detection (network monitoring)
4. Community Response (hard fork)
5. Difficulty Adjustment (resilience)

Double-Spend Attacks:

1. Race Attack:
   - Broadcast two conflicting transactions
   - One to merchant, one to self
   - Merchant accepts unconfirmed transaction
   - Attack succeeds if self-spend confirms first
   Defense: Wait for confirmations

2. Finney Attack:
   - Miner pre-mines block with self-spend
   - Sends transaction to merchant
   - Merchant accepts (0-conf)
   - Miner releases pre-mined block with self-spend
   Defense: Wait for confirmations

3. Vector76 Attack:
   - Combination of race and Finney
   - One block advantage
   - More sophisticated
   Defense: Wait for confirmations (6+)

4. 51% Attack:
   - Majority hash power
   - Build private chain
   - Orphan public chain
   Defense: Economic cost, monitoring

Prevention Summary:
- 0 confirmations: Vulnerable (small amounts)
- 1 confirmation: Some risk (medium amounts)
- 6 confirmations: Safe (large amounts)
- 12+ confirmations: Very safe (institutional)

Quantum Computing Threats:

1. Shor's Algorithm:
   - Factors integers exponentially faster
   - Breaks ECDSA (secp256k1)
   - Threat Level: Critical (10-20 years)

2. Grover's Algorithm:
   - Searches quadratically faster
   - Weakens hash functions (SHA-256)
   - Threat Level: Moderate (can adapt)

3. Impact Timeline:
   2024-2028: Research phase
   2028-2032: Early quantum computers
   2032-2035: Cryptographically relevant
   2035+: All classical crypto compromised

Specific Threats to Bitcoin:

| Component | Current Crypto | Quantum Threat | Mitigation |
|-----------|----------------|----------------|------------|
| **Signatures** | ECDSA (secp256k1) | Broken by Shor | Post-quantum signatures |
| **Public Keys** | ECC (256-bit) | Broken by Shor | Larger keys, post-quantum |
| **Addresses** | RIPEMD-160 (160-bit) | Weakened (80-bit) | Larger hash sizes |
| **Block Hashes** | SHA-256 (256-bit) | Weakened (128-bit) | SHA-512 |
| **Transaction IDs** | SHA-256 | Weakened | SHA-512 |
| **Merkle Trees** | SHA-256 | Weakened | SHA-512 |

Migration Options:

1. Signature Scheme Upgrade:
   - Replace ECDSA with post-quantum
   - Options: Dilithium, Falcon, SPHINCS+
   - NIST standards (2024-2025)

2. Address Format Update:
   - New address types for post-quantum
   - Backward compatibility
   - Gradual migration

3. Hybrid Approach:
   - ECDSA + Post-quantum
   - Both must be valid
   - Gradual transition

4. Hard Fork (Likely):
   - New consensus rules
   - Post-quantum signatures
   - Legacy support (optional)

Timeline:
- 2024-2026: Research and planning
- 2026-2028: Testnet experiments
- 2028-2030: Soft fork (hybrid)
- 2030-2032: Hard fork (post-quantum)
- 2032+: Quantum-safe Bitcoin

Quantum-Resistant Address Types:
1. P2QH (Pay to Quantum Hash)
2. P2QS (Pay to Quantum Signature)
3. Hybrid (Classical + Quantum)
4. Larger hash addresses

User Security Checklist:

1. Private Key Management:
   ☐ Use hardware wallets for storage
   ☐ Never share private keys
   ☐ Use strong passwords
   ☐ Enable 2-factor authentication (if available)
   ☐ Keep software updated

2. Seed Phrase Security:
   ☐ Store offline (no digital copies)
   ☐ Multiple physical copies
   ☐ Different secure locations
   ☐ Fire/water protection
   ☐ Never share with anyone

3. Transaction Security:
   ☐ Verify addresses carefully
   ☐ Check amounts before sending
   ☐ Use trusted wallets
   ☐ Keep small amounts in hot wallets
   ☐ Use multiple wallets (different purposes)

4. Network Security:
   ☐ Use trusted connections
   ☐ VPN for privacy
   ☐ Update wallet software
   ☐ Verify SSL/TLS certificates
   ☐ Use hardware wallets on secure computers

5. Recovery Planning:
   ☐ Test recovery process
   ☐ Document recovery steps
   ☐ Share with trusted contacts
   ☐ Consider inheritance
   ☐ Update regularly

Red Flags:
✗ Websites asking for seed phrases
✗ Unsolicited wallet support
✗ Messages claiming to be from miners
✗ Too-good-to-be-true offers
✗ Requests to "validate" wallet

Business Security Checklist:

1. Custody:
   ☐ Multi-signature wallets (3-of-5)
   ☐ Hardware security modules (HSM)
   ☐ Geographic key distribution
   ☐ Regular key rotation
   ☐ Internal controls

2. Operations:
   ☐ Secure infrastructure
   ☐ Regular security audits
   ☐ Incident response plan
   ☐ Employee training
   ☐ Insurance coverage

3. Compliance:
   ☐ KYC/AML procedures
   ☐ Transaction monitoring
   ☐ Regulatory reporting
   ☐ Audit trail
   ☐ Data protection

4. Risk Management:
   ☐ Key management policies
   ☐ Disaster recovery
   ☐ Business continuity
   ☐ Third-party risk
   ☐ Regular testing

5. Technology:
   ☐ Secure wallet software
   ☐ Hardware security
   ☐ Network security
   ☐ Encryption
   ☐ Backup systems

Key Lessons:

1. Exchange Security:
   - Regular security audits
   - Cold storage for majority of funds
   - Multi-signature for operations
   - Insurance coverage
   - User education

2. Personal Security:
   - Never store on exchanges
   - Use hardware wallets
   - Secure seed phrases
   - Regular backups
   - Stay informed

3. Protocol Security:
   - Regular upgrades (Taproot)
   - Post-quantum readiness
   - Security research
   - Community vigilance
   - Network monitoring

4. Industry Security:
   - Sharing threat intelligence
   - Collaborative defense
   - Regulatory compliance
   - Best practices
   - Continuous improvement

Address Security:

P2PKH (Legacy):
- 160-bit hash (RIPEMD-160)
- Security: 2⁸⁰ (quantum) vs 2¹⁶⁰ (classical)
- Vulnerability: Exposed public key when spending

P2SH (Script Hash):
- 160-bit hash
- Security: 2⁸⁰ (quantum) vs 2¹⁶⁰ (classical)
- Used for multi-signature

SegWit (P2WPKH):
- 160-bit hash
- Security: 2⁸⁰ (quantum) vs 2¹⁶⁰ (classical)
- No address reuse recommended

Taproot (P2TR):
- 256-bit public key
- Security: 2¹²⁸ (quantum) vs 2²⁵⁶ (classical)
- Most secure address type