Learning Objectives:

  • Master Bitcoin’s peer-to-peer network architecture

  • Understand network messages and protocols

  • Analyze network security and attack vectors

3.5.1: P2P Network Architecture

Network Design Principles:

Bitcoin’s P2P network is designed to be:

  • Decentralized: No central servers

  • Resilient: Works even with many nodes offline

  • Censorship-Resistant: Cannot be shut down

  • Permissionless: Anyone can join

  • Efficient: Minimizes bandwidth usage

 
Network Topology:

┌─────────────────────────────────────────────────────────────────────┐
│                    Bitcoin P2P Network                             │
│                                                                   │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                     Node Discovery                          │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │  DNS Seeds  │  │  Hardcoded  │  │  ADDR       │      │   │
│  │  │             │  │  Nodes      │  │  Messages   │      │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                    │
│  ┌───────────────────────────▼─────────────────────────────────┐   │
│  │                     Node Connections                        │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │  Outbound   │  │  Inbound    │  │  Connections│      │   │
│  │  │  Connections│  │  Connections│  │  (8-12)     │      │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                    │
│  ┌───────────────────────────▼─────────────────────────────────┐   │
│  │                     Message Types                          │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │  Version    │  │  Block/Tx   │  │  Ping/Pong  │      │   │
│  │  │  Handshake  │  │  Propagation│  │  Keep-alive │      │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

3.5.2: Peer Discovery

Discovery Methods:

text
1. DNS Seeds:
   - Hardcoded DNS hostnames
   - Return random active node IPs
   - Example: seed.bitcoin.sipa.be
   - Resilient: Multiple seeds

2. Hardcoded Nodes:
   - Built-in list of known nodes
   - Fallback if DNS fails
   - Updated with releases

3. ADDR Messages:
   - Peers share addresses
   - Build peer list
   - Verify connectivity

4. Tor/Onion Nodes:
   - Hidden services
   - Enhanced privacy
   - Additional discovery

3.5.3: Network Messages

Message Format:

text
Bitcoin Message Structure:

Magic Bytes (4 bytes): 0x0B110907 (mainnet)
Command (12 bytes): Message type (e.g., "version", "tx")
Length (4 bytes): Payload length (in bytes)
Checksum (4 bytes): First 4 bytes of SHA-256(SHA-256(payload))
Payload (variable): Message data

Common Message Types:

 
 
Message Purpose Direction Frequency
version Node handshake Bidirectional Once
verack Acknowledge version Bidirectional Once
addr Share peer addresses Bidirectional Periodic
inv Announce inventory Bidirectional Often
getdata Request data Bidirectional Often
tx Send transaction Bidirectional Often
block Send block Bidirectional Occasionally
ping/pong Check connectivity Bidirectional Periodic
mempool Request transactions One-way Occasionally

3.5.4: Transaction Propagation

Propagation Process:

 
Transaction Propagation:

1. User sends transaction to node
2. Node validates transaction
3. Node adds to mempool
4. Node broadcasts to peers
5. Peers validate and forward
6. Transaction propagates globally

Propagation Time:
- 1-2 seconds for global propagation
- Uses INV/GETDATA pattern
- Efficient via compact blocks

INV/GETDATA Pattern:

 
Inventory Announcement:

INV Message:
- Type: TX (transaction) or BLOCK
- Hash: 32-byte hash

GETDATA Request:
- Request specific inventory
- Node responds with requested data
- Efficient: Only download needed data

Benefits:
- Reduces bandwidth
- Allows selective download
- Prevents spam

3.5.5: Compact Blocks (BIP-152)

Compact Block Protocol:

 
Compact Blocks:

Goal: Reduce bandwidth for block propagation

Method:
1. Sender sends short transaction IDs
2. Receiver reconstructs from mempool
3. Only missing transactions are requested
4. ~80% bandwidth reduction

Process:
1. Block found: Send Compact Block
2. Receiver checks mempool
3. Missing transactions requested
4. Block reconstructed

Benefits:
- Faster propagation
- Lower bandwidth
- Better network efficiency

 

1. Network Attacks and Mitigations

 
 
Attack Description Mitigation
Eclipse Attack Isolate target node Many outbound connections
Sybil Attack Fake identities Proof-of-work, cost
Eavesdropping Intercept communications Encryption (optional)
DDOS Overwhelm nodes Rate limiting, filtering
Timejacking Manipulate time Network-adjusted time

Lesson 3.6: Bitcoin Security and Cryptography

Learning Objectives:

  • Master Bitcoin’s security model

  • Understand cryptographic primitives used

  • Analyze attack vectors and defenses

3.6.1: Security Model

Security Assumptions:

Bitcoin’s security relies on several key assumptions:

text
Security Assumptions:
1. Hash functions are secure (SHA-256, RIPEMD-160)
2. ECDSA is secure (discrete logarithm problem)
3. Honest majority of hash power (>50%)
4. Miners are rational (profit-seeking)
5. Nodes validate all rules

Security Properties:
1. Integrity: Transactions cannot be changed
2. Authenticity: Only key holder can spend
3. Non-repudiation: Cannot deny transaction
4. Finality: Confirmed transactions are irreversible
5. Censorship Resistance: Cannot block transactions

3.6.2: Cryptographic Security

Hash Function Security:

 
SHA-256 Security:
- Pre-image: 2²⁵⁶ operations (impossible)
- Collision: 2¹²⁸ operations (impossible)
- Quantum: 2¹²⁸ operations (with Grover)

RIPEMD-160 Security:
- Pre-image: 2¹⁶⁰ operations
- Collision: 2⁸⁰ operations (weaker)
- Used only for addresses (not security-critical)

Double SHA-256:
- Bitcoin uses SHA-256 twice
- Prevents length extension attacks
- More secure than single hash

ECDSA Security:

 
ECDSA (secp256k1):
- Key Size: 256 bits
- Security Level: 128 bits
- Quantum Threat: Broken by Shor

Signature Components:
- Private key: Random 256-bit number
- Public key: EC point on secp256k1
- Signature: (r, s) 64 bytes

Security Requirements:
1. Unique k (nonce) per signature
2. Secure random number generation
3. Private key kept secret
4. No side-channel leakage

3.6.3: Attack Vectors

Common Attacks:

 
 
Attack Description Impact Prevention
51% Attack Majority hash power Double-spend Economic cost
Double-Spend Spend same coins twice Financial loss Confirmations
Sybil Attack Fake identities Network disruption Connection limits
Eclipse Attack Isolate node Misleading node Multiple connections
Timejacking Manipulate time Network disruption Time consensus
Selfish Mining Withhold blocks Reduced security Detection
Replay Attack Replay transaction Unauthorized spending Sequence numbers
Malleability Change transaction ID Transaction confusion SegWit

3.6.4: Double-Spend Protection

How Bitcoin Prevents Double-Spending:

text
Double-Spend Prevention:

1. UTXO Model:
   - Each UTXO can only be spent once
   - Network rejects second spend

2. Transaction Validation:
   - Nodes check UTXO existence
   - Verify no previous spend

3. Block Confirmation:
   - Transaction in block
   - Subsequent blocks add security
   - More confirmations = More secure

4. Mempool Tracking:
   - Nodes remember pending transactions
   - Reject double-spend attempts
   - First-seen policy (usually)

5. Race Condition Protection:
   - Miners choose first transaction
   - Network consensus rejects second

3.6.5: Privacy and Anonymity

Privacy Considerations:

t
Bitcoin Privacy:

Transaction Transparency:
- All transactions are public
- Amounts are visible
- Addresses are pseudonymous

Privacy Challenges:
1. Address reuse (links transactions)
2. IP address exposure
3. Transaction graph analysis
4. Exchange KYC/AML

Privacy Solutions:
1. Use new addresses for each transaction
2. Use Tor/I2P for network
3. CoinJoin (mixing transactions)
4. Confidential transactions (not in Bitcoin)
5. Lightning Network (private payments)

1. 51% Attack Detailed Analysis

 
51% Attack Requirements:

1. Hash Power: >50% of network
2. Hardware Cost: ~$15B (2024)
3. Electricity Cost: ~$25M/day
4. Attack Time: Hours to days

Attack Success Metrics:
- Success probability depends on:
  - Hash rate advantage
  - Attack duration
  - Target transaction value

Defense Mechanisms:
1. Economic cost (too expensive)
2. Detection (network monitoring)
3. Hard fork (community response)
4. Increased confirmations

2. Quantum Computing Threats

text
Quantum Threats to Bitcoin:

1. ECDSA Signatures:
   - Shor's algorithm breaks ECDSA
   - Need post-quantum signatures
   - Migration planned (Taproot, etc.)

2. Addresses:
   - Public keys exposed on spend
   - Quantum computers can derive private key
   - Use new addresses for each transaction

3. Hash Functions:
   - Grover's algorithm weakens (2¹²⁸)
   - Still secure for now
   - SHA-512 possible upgrade

4. Timeline:
   - 10-20 years (speculative)
   - Bitcoin can upgrade
   - Post-quantum readiness
PreviousNext