Bitcoin and Blockchaii Bitcoin and Blockchain Creation of Coins Genesis Block © First Block: Created on January 3, 2009, by Satoshi Nakamoto © Block Reward: Initial 50 BTC * Embedded Message: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" * Technical Peculiarity: Genesis block's coins cannot be spent Mining-Based Issuance * Coinbase Transaction: Special first transaction in each block * Block Reward Structure: © Initial 50 BTC per block ‘* Halving every 210,000 blocks (approximately 4 years) © Current reward (2024): 3.125 BTC per block * Final supply cap: 21 million BTC (expected around 2140) Coin Maturity ‘+ Maturity Period: Newly mined coins require 100 block confirmations before spending ‘* Purpose: Prevents chain reorganization spending issues * Exception: Block rewards cannot be spent in the same block they're created Bitcoin Decimal Structure © Smallest Unit: 1 Satoshi = 0.00000001 BTC © Total Divisibility: 100 million Satoshis per Bitcoin * Future Adaptability: Layer-2 solutions can enable further subdivision if needed Payments and Double Spending Double Spending Problem * Definition: Spending the same digital currency more than once ‘* Fundamental Challenge: Digital information is easily duplicated © Pre-Bitcoin Solutions: Relied on central authorities to verify transactionsBitcoin's Solution * Distributed Ledger: Every transaction publicly recorded * Timestamping: Transactions ordered chronologically * Block Confirmation: Transactions become increasingly secure with each additional block ‘+ Network Consensus: Nodes agree on transaction history ‘© Computational Proof: PoW makes altering history prohibitively expensive Double Spend Attack Vectors 1. Race Attack: * Sending same coins to two recipients simultaneously * First recipient accepts zero-confirmation transaction © Attacker attempts to confirm transaction to different recipient © Mitigation: Wait for confirmations 2. Finney Attack: ‘* Miner pre-mines block with transaction returning coins to self ‘Spends same coins in real-world transaction * Releases pre-mined block, invalidating real-world transaction * Mitigation: Multiple confirmation requirements 3.51% Attack: * Controlling majority of network hashrate * Ability to reorganize blockchain and double-spend © Extremely costly for established networks * Mitigation: Increasing confirmation requirements for large transactions Payment Verification Methods. * Full Verification: Complete blockchain validation (full nodes) © Sim ied Payment Verification (SPV): Verifies transactions using block headers and Merkle proofs * Payment Processors: Third-party services verifying transactions Bitcoin Scripts Script Overview * Definition: Stack-based, non-Turing complete scripting language ‘* Purpose: Defines conditions for spending Bitcoin * Components: Two scripts per transaction:© scriptSig (unlocking script): Provided by spender © scriptPubKey (locking script): Created by recipient Script Execution 1. Concatenation: scriptSig + scriptPubKey 2, Stack Manipulation: Commands push/pop data to/from stack 3. Evaluation: Script executes left to right 4, Validation: Transaction valid if stack contains TRUE (non-zero) value after execution Common Script Types 1. Pay-to-Public-Key-Hash (P2PKH). ‘* Most common traditional format * Locks funds to hash of public key ‘* Requires signature and public key to spend Format: (OP_DUP OP_HASHI60 OP_EQUALVERIFY OP_CHECKSIG) 2, Pay-to-Script-Hash (P2SH): * Locks funds to hash of script * Enables complex spending conditions * Redeem script revealed only when spending * Lower fees for complex conditions © Format: (OP_HASHI60 OP_EQUAL Requires M-of-N signatures © Format: (* ‘ N OP_CHECKMULTISIG 4, SegWit Formats: © P2WPKH: Native SegWit (bech32 addresses) ‘© P2WSH: SegWit script hash © P2SH-P2WPKH: Nested SegWit (backward compatible) 5, Taproot Formats (since 2021): © P2TR: Pay-to-Taproot * Enables key aggregation and script-path spending * Improved privacy and efficiency Script Operations‘© Flow Control: IF, ELSE, ENDIF ‘© Stack Operations: DUP, SWAP, TUCK, DROP * Bitwise Operations: AND, OR, XOR * Arithmetic: ADD, SUB, MUL, DIV * Crypto Operations: HASH160, SHA256, CHECKSIG * Time Locks: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY Script Limitations * Non-Turing Complete: No loops * Limited State Access: Can't access blockchain data * Size Restrictions: 10,000 bytes maximum script size ‘Stack Size Limit: 1,000 stack elements * Opcode Limitations: Some opcodes disabled for security Bitcoin P2P Network Network Architecture * Decentralized: No central servers or controlling nodes © Peer Discovery: Methods to find network participants ‘+ Node Types: * Full Nodes: Store complete blockchain * Lightweight Nodes: Store headers, rely on full nodes ‘* Mining Nodes: Create new blocks * Listening Nodes: Accept incoming connections * Economic Nodes: Participate in Bitcoin economy Peer Discovery Mechanisms 1. DNS Seeds: ‘* Hardcoded DNS names resolving to active nodes * Maintained by trusted Bitcoin contributors * First connection point for new nodes 2. Address Propagation: ‘* Nodes share known addresses via messages * Gossip protocol for peer discovery * Each node maintains address database3. Manual Configuration: : Ceenmee) parameters * For specific connection requirements 4, Hardcoded Seeds: * Fallback connection points in source code © Used if DNS seeds unavailable Network Connections * Connection Limit: Default 8 outbound, 125 total connections * Connection Types: * Outbound: Initiated by the node * Inbound: Received from other nodes ‘* Manual: User-specified connections © Feeler: Temporary connections to test addresses © Block-relay-only: For block propagation without transaction relay Network Messages © handshake: for connection establishment Network Topology © Unstructured Overlay: Random connections between peers Small World Network: Most nodes reachable within few hops ‘* Non-Uniform Distribution: Some nodes have more connections * Unreachable Nodes: NAT/firewalled nodes make outbound connections only Network Privacy Considerations * IP Address Exposure: Connections reveal IP addresses * Transaction Origin Identification: First-relay analysis © Privacy Enhancements: * Tor network integration * Dandelion++ transaction relay© Compact block filters (BIP 157/158) Transactions in Bitcoin Network Transaction Lifecycle 1. Creation Phase: © Wallet Creation: User constructs transaction * UTXO Selection: Choose inputs to spend © Output Definition: Specify recipient(s) and amounts * Fee Calculation: Determine network fee * Signing: Apply ECDSA signatures to inputs 2, Propagation Phase: © Initial Broadcast: Transaction sent to connected peers * Validation by Peers: Each node verifies transaction ‘* Mempool Inclusion: Valid transactions stored in memory pools * Further Propagation: Transaction relayed to other peers * Reach: Eventually propagates to most network nodes 3, Mining Phase: * Transaction Selection: Miners prioritize by fee rate * Block Inclusion: Transaction added to candidate block * Mining Process: PoW computation to find valid block © Block Discovery: Valid block containing transaction found 4. Confirmation Phase: * Block Propagation: New block broadcast to network Validation by Nodes: Nodes verify block validity Blockchain Addition: Block added to blockchain Additional Confirmations: Subsequent blocks increase security Finality: Transaction considered final after ~6 confirmations Transaction Structure 1. Transaction Components: * Version: Protocol version (currently 1 or 2) © Input Counter: Number of inputs ‘© Inputs: References to previous outputs being spent © Output Counter: Number of outputs© Outputs: Destinations and amounts * Locktime: Earliest time/block transaction can be mined ‘* Witness Data (SegWit): Segregated signature data 2. Input Structure: * Transaction ID: Reference to previous transaction © Output Index: Which output from referenced transaction © ScriptSig: Unlocking script (signatures, etc.) © Sequence: Enables time locks and RBF 3. Output Structure: * Value: Amount in satoshis © ScriptPubKey: Locking script defining spending conditions 4. Transaction ID Calculation: © Double SHA-256 hash of serialized transaction * For SegWit: excludes witness data (txid vs. wtxid) Transaction Types 1. Standard Transaction Types: * P2PKH: Pay to Public Key Hash (legacy) ‘© P2SH: Pay to Script Hash (multi-sig, complex scripts) © P2WPKH: Pay to Witness Public Key Hash (native SegWit) © P2WSH: Pay to Witness Script Hash (SegWit script) * P2TR: Pay to Taproot (key/script paths) Transaction Types: * Coinbase Transaction: First in block, creates new coins ‘© CPFP: Child Pays For Parent fee acceleration © RBF: Replace By Fee transaction replacement * Coinjoin: Privacy-enhancing transaction combining inputs/outputs Transaction Fee Market 1, Fee Determination: ‘© Supply: Block space (limited to ~1-4MB) ‘© Demand: Pending transactions * Fee Rate: Expressed in sat/vB (satoshis per virtual byte) 2. Fee Estimation Methods:Historical Analysis: Recent confirmation times Mempool Monitoring: Current pending transaction fees Priority Bands: Grouping by fee rate * Dynamic Adjustments: Based on mempool size changes 3. Fee Optimization Strategies: * Transaction Batching: Combining multiple payments ‘+ UTXO Management: Consolidation during low-fee periods Timing: Sending during low-demand periods RBF: Fee bumping if needed Layer-2 Solutions: Lightning Network for low-fee transactions Block Mining ing Process Overview 1. Block Template Creation: + Coinbase Transaction: Special first transa n creating reward * Transaction Selection: Choosing from mempool based on fees * Block Header Construction: Version, previous block hash, etc. * Target Calculation: Based on current difficulty 2. Mining Loop: * Merkle Root Calculation: Hash tree of all transactions ‘* Timestamp Update: Current time (within protocol limits) ‘© Nonce Iteration: Trying different values * Extra Nonce: Modifying coinbase when nonce space exhausted 3. Proof of Work: * Hash Calculation: Double SHA-256 of block header * Target Comparison: Check if hash is below target * Difficulty: Inverse relationship with target ‘© Successful Mining: Finding hash below target 4, Block Completion: * Final Assembly: Complete block with valid proof of work * Self-Validation: Verify block meets all protocol rules * Network Submission: Broadcast to connected peers Mining Hardware Evolution1. CPU Mining Era (2009-2010): * Regular Computers: Mining on standard processors © Hash Rate: ~10-100 MH/s per device * Efficiency: Low power efficiency 2. GPU Mining Era (2010-2013) * Graphics Cards: Parallel processing advantage ‘© Hash Rate: ~100-1,000 MH/s per device jency: Better than CPUs, still inefficient 3. FPGA Mining Era (2011-2013): * Field Programmable Gate Arrays: Custom circuits ‘Hash Rate: ~1-10 GH/s per device © Efficiency: Significant improvement over GPUs 4, ASIC Mining Era (2013-Present) * Application Specific Integrated Circuits: Purpose-built hardware ‘* Hash Rate: TH/s to PH/s per device © Efficiency: Orders of magnitude better than previous technologies * Generation Evolution: Multiple ASIC generations with improving efficiency Mining Economics 1. Revenue Components: * Block Subsidy: New bitcoins created (3.125 BTC as of 2024) © Transaction Fees: Sum of fees from included transactions + Exchange Rate: Bitcoin price influences fiat value 2. Cost Components: ‘* Equipment: ASIC miners, cooling systems, etc. * Electricity: Primary ongoing operational cost © Facility: Data center, ventilation, etc. * Maintenance: Repairs, replacements * Staff: Technical personnel * Network: Internet connectivity 3. Profitability Factors: * Efficiency: Joules per terahash (J/TH) * Electricity Cost: Price per kilowatt-hour © Difficulty: Adjusts every 2016 blocks* Bitcoin Price: Market value of rewards * Equipment Depreciation: Hardware becomes obsolete Block Propagation and Block Relay Standard Block Propagation (Pre-2016) 1. Announcement Protocol: * inv message: Inventory announcement of new block hash * getdata request: Recipient requests full block * block message: Sender transmits complete block © Verification: Recipient validates entire block * Further Propagation: Recipient announces to its peers 2. Propagation Challenges: * Latency: Large blocks take time to transmit Redundancy: Same transactions sent multiple times Bandwidth Consumption: Full block transmission to each peer Propagation Time: Network-wide distribution delay Orphan Risk: Increases with propagation delay ‘Compact Block Relay (BIP 152, 2016) 1. Compact Block Mechanism: * Announcement: Block header and transaction short IDs * Mempool Matching: Recipient reconstructs block using transactions already in mempool ‘* Missing Transaction Request: Only unknown transactions requested * Completion: Full block reconstructed with minimal data transfer 2. Operational Modes: ‘* Low Bandwidth Mode: Request-response for missing transactions * High Bandwidth Mode: Missing transactions sent immediately 3. Advantages: * Bandwidth Reduction: ~90% less data transmitted * Faster Propagation: Reduced network latency * Lower Orphan Rate: Faster block propagation reduces orphans * Network Efficiency: Better utilization of bandwidth Advances in Block Propagat1. Fibre Network (Fast Internet Bitcoin Relay Engine): * Purpose-Built Network: Optimized connections between miners * UDP Transport: Faster than TCP for global transmission * Forward Error Correction: Reduces retransmission needs * Block Templates: Pre-propagation of likely block templates 2. Erlay Protocol: * Set Reconciliation: Efficiently identify differences between transaction sets + Bandwidth Reduction: ~40% less bandwidth for transaction relay * Connection Scaling: Enables more connections between nodes 3, Block Propagation Strategies: ‘* Outbound Priority: Critical blocks sent to outbound peers first * Header-First Propagation: Headers propagate before full blocks * Block-Relay-Only Connections: Dedicated to block propagation * Diffusion Spreading: Randomized propagation timing for privacy Block Propagation Metrics 1. Propagation Time: ‘* 50% Propagation: Time to reach half of network * 90% Propagation: Time to reach vast majority * Historical Trend: Improved from ~10s to ~1s for 90% propagation 2. Orphan Rate: * Definition: Percentage of valid blocks not in main chain * Historical Reduction: From ~1-2% to <0.1% * Correlation: Directly related to propagation speed 3, Bandwidth Impact: © Pre-Optimization: ~1MB per peer per block * Post-Opti ition: ~20KB per peer per block * Network Capacity: Enables larger blocks with same propagation time Working with Consensus in Bitcoin Distributed Consensus in Open Environments Consensus Challenges in Decentralized Systems * Core Issue: Reaching agreement among distributed parties that may include malicious actors* Bitcoin's Context: Nodes must agree on transaction history without trusted third party * Theoretical Background: Lamport, Shostak, and Pease’s 1982 paper * Traditional Solution Limitation: Required 2/3+ honest nodes with known identities 2. Specific Challenges in Open Networks: * Sybil Attacks: Creating multiple fake identities * Unknown Participants: Open participation without identity verification * Dynamic Membership: Nodes join and leave unpredictably * Variable Latency: Network delays affect information propagation * Scale: Potentially thousands of nodes worldwide 3. Double-Spending in Digital Currency. * Problem Definition: Same digital token spent multiple times * Previous Solutions: Central authority validation * Bitcoin's Innovation: Solving without central authority 4, Eventual Consistency: * Temporary Disagreements: Nodes may temporarily have different views © Convergence Property: Views eventually align given sufficient time + Probabilistic Finality: Transactions become increasingly secure over time Pre-Bitcoin Consensus Approaches 1. Traditional Distributed Consensus: * Paxos: Leader-based agreement protocol *. PBFT: Byzantine Fault Tolerance with 3f+1 nodes * Limitations: Required known participant set 2. Previous Digital Cash Attempts: © DigiCash (David Chaum): Central server for double-spend prevention + B-money (Wei Dai): Proposed broadcast of transactions * Bit Gold (Nick Szabo): Proposed proof of work concept 3. Critical Limitations: ‘* Closed Membership: Limited to known participants * Central Points: Reliance on specific entities * Byzantine Agreement: Required 2/3+ honest participants Bitcoin's Consensus Innovation 1. Nakamoto Consensus:Proof-of-Work: Resource commitment for participation Longest Chain Rule: Objectively verifiable selection criteria Economic Incentives: Aligns honest behavior with self-interest Probabilistic Finality: Security increases with confirmations 2. Key Breakthrough Components: Consensus in a Combining Technology: Cryptography, P2P networks, and incentives Resource-Based Participation: Computing power determines influence Self Adjusting Difficulty: Maintains consistent block time Block Chain Structure: Immutable transaction history coin Network Bitcoin Consensus Rules 1. Block Validity Rules: Structure Format: Correct data structure and fields Block re: Must not exceed maximum size limit Block Header: Valid proof of work, timestamp, ete. First Transaction: Must be valid coinbase transaction Alll Transactions: Must follow transaction validity rules 2. Transaction Validity Rules: Syntax: Correct data structure and size Inputs: Must reference existing, unspent outputs Input Value: Must be fully spent (no partial spends) Output Value: Must not create more bitcoins than input value (minus fees) Scripts: All scripts must execute successfully Coinbase Maturity: Coinbase outputs require 100 confirmations before spending 3. Chain Selection Rules: Genesis Block: All valid chains start from the same genesis block Accumulated Work: Chain with most cumulative proof of work is authoritative Block Difficulty: Must meet network difficulty requirements Chain Val lation: Every block and transaction must follow all rules Consensus Rule Enforcement 1, Full Nodes: Complete Validation: Verify every block and transaction* Independent Verification: No trust in other nodes Full Blockchain Storage: Maintain entire transaction history * Role: Primary consensus rule enforcers 2. Mining Nodes: © Block Creation: According to consensus rules * Transaction Selection: Valid transactions from mempool * Rule Adherence: Must follow rules or blocks rejected by network * Economic Incentive: Block rewards only valid if rules followed 3, Lightweight Nodes (SPV): Limited Validation: Verify block headers and specific transactions lation Trust Requirement: Rely on full nodes for some ve Block Headers: Download and verify PoW chain Merkle Proofs: Verify specific transactions without full blocks ‘Soft and Hard Forks 1. Soft Fork: © Defi jon: Backward-compatible tightening of rules * Activation: When majority of hash power enforces new rules Non-Upgraded Nodes: Continue to follow chain, but may accept invalid blocks Examples: P2SH, SegWit, Taproot Activation Methods: BIP9 (version bits), BIP148 (UASF), BIP91 2. Hard Fork: * Defi jon: Rule changes incompatible with previous rules © Chain Split Risk: Can result in persistent blockchain split * Non-Upgraded Nodes: Reject blocks following new rules + Examples: Block size increase, fundamental protocol changes * Contentious History: Bitcoin Cash fork (2017) 3, Consensus Change Process: * Bitcoin Improvement Proposals (BIPs): Technical specifications © Community Discussion: Mailing lists, forums, conferences * Implementation: Code change in multiple clients * Testnet Deployment: Testing before mainnet * Activation Mechanism: Coordinated upgrade methodBlockchain Reorganizations 1. Chain Reorganization Process: * Alternative Chain Discovery: Node receives blocks forming chain with more work * Validation: Verify all blocks in alternative chain * Reorganization: Switch to new chain, reverse transactions from old chain + Reprocessing: Apply transactions from new chain it: Practical limits on reorg depth (default max 100 blocks) ‘* Transaction Reversal: Confirmed transactions may become unconfirmed * Double-Spend Risk: Previously confirmed transactions could be replaced Confirmation Security: More confirmations reduce reorg risk * Economic Finality: Cost of attack increases with depth 3. Notable Reorg Events: * March 2013: 24-block reorg due to database bug * July 2015: 6-block reorg during mining pools upgrade + Recent History: Rare beyond 1-2 blocks in Bitcoin Proof of Work (PoW) - Basic Introduction Core Concept of Proof of Work 1. Fundamental Principle: ‘* Resource Commitment: Demonstrating computational work * Asymmetric Verification: Difficult to produce, easy to verify * Non-interactive: No back-and-forth communication required * Probabilistic Solution: Based on random attempts 2. Historical Context © Pre-Bitcoin Uses: Anti-spam measures, denial of service protection * Conceptual Origins: "Pricing via Processing” (Dwork & Naor, 1992) * Hashcash: Adam Back's email anti-spam system (1997) * B-money & Bit Gold: Wei Dai and Nick Szabo's digital currency proposals 3, Key Properties: * Adjustable Difficulty: Calibrated to target specific work amount © Statistical Predictability: Effort correlates to success probability * Independence: Each attempt has same probability of success* Unforgeability: No shortcuts to finding valid proof Generic PoW Construction 1, Basic Components: * Challenge: Data that needs proof of work * Difficulty Target: Threshold that solution must meet. * Nonce: Variable modified to find solution * Verification Function: Typically a cryptographic hash function 2. Process Flow: * Input Formation: Combine challenge data with nonce * Function Application: Apply one-way function (typically hash) ‘© Output Evaluation: Check if result meets difficulty criteria © Iteration: If criteria not met, modify nonce and repeat 3, Mathematical Probability: * Uniform Distribution: Hash outputs evenly distributed © Success Probability: 1/(2n) where n is difficulty bits * Expected Attempts: 2“n attempts needed on average * Statistical Variance: Actual attempts may vary significantly Applications of PoW 1. Anti-Spam Systems ‘© Email: Require small proof of work for sending * Website Registration: Prevent automated signups © API Rate Li ing: Resource-based request limitation 2. Denial of Service Protection: * Connection Limiting: Require PoW for opening connections * Request Prioritization: Higher PoW gets priority service 3. Consensus Mechanisms: © Sybil Attack Resistance: Cost to creating multiple identities * Block Production: Competition for block creation rights * Chain Selection: Measure of chain validity (accumulated work) HashCash PoW HashCash Fundamentals1. Original Purpose: Email Anti-Spam: Requiring computational work to send email © Developer: Adam Back (1997) * Goal: Economic disincentive for mass emailers 2. Technical Design: * Header Format: Version, bits, date, resource, ext, rand, counter * Resource String: Email address or domain being protected * Challenge: Find counter value creating hash with leading zeros * Verification: Check hash has required number of leading zeros 3, HashCash Algorithm: ‘+ Input Formation: Concatenate header fields Hash Function: SHA-1 in original implementation * Target Pattern: Hash with specified number of leading zero bits * Solution Search: Increment counter until matching hash found HashCash in Bitcoin 1. Adaptation for Bitcoin: * Function Change: SHA-256d (double SHA-256) instead of SHA-1 * Resource Field: Block header data instead of email address * Difficulty Adjustment: Dynamic target based on network hashrate * Counter Implementation: Nonce field + extraNonce in coinbase 2. Key Differences: ‘© Purpose: Consensus mechanism vs. anti-spam * Difficulty: Much higher in Bitcoin (adjustable) © Reward Structure: Block rewards incentivize participation ‘* Continuous Operation: Ongoing mining process vs. one-time stamp 3, Implementation Details: * Binary Target: Compact representation in block header © Target Calculation: From difficulty or bits field * Search Space: 32-bit nonce + variable extraNonce © Verification: Compare block hash against target HashCash Properties 1. Security Properties© Pre-image Resistance: Cannot derive input from hash © Second Pre-image Resistance: Cannot find alternate input with same hash * Collision Resistance: Difficult to find any two inputs with same hash 2. Operational Characteristics * CPU-Bound: Performance limited by processing speed * Parallelizable: Can distribute work across multiple processors * Memory-Efficient: Minimal memory requirements * Fixed Cost: Same verification cost regardless of creation cost Bitcoin POW Bitcoin PoW Implementation 1. Block Header Structure © Version: Protocol version number * Previous Block Hash: Link to parent block ‘* Merkle Root: Hash of all transactions © Timestamp: Current time (within protocol limits) © Difficulty Target: Compact form of target threshold * Nonce: 32-bit field varied to find solution 2. Mining Process: * Header Preparation: Assemble all fields except nonce ‘* Hash Calculation: Double SHA-256 of block header * Target Comparison: Check if hash is below target © Nonce Exhau: in: If 32-bit nonce space exhausted, modify extraNonce in coinbase * Solution Found: Valid block when hash below target 3. Difficulty Adjustment: * Retargeting Period: Every 2016 blocks (approximately 2 weeks) © Target Block Time: 10 minutes per block * Adjustment Formula: © Constraints: Maximum adjustment factor of 4x up or down * Difficulty: Inverse relationship with target Mathematical Properties1. Target Representation: * Compact Format: 3 bytes mantissa, 1 byte exponent © Full Target: 256-bit number compared against hash * Difficulty Calculation: © Maximum Target: 0x00000000FFFF0000000000000000000000000000000000000000000000000000 2. Probability Analysis: ‘+ Success Probability: target / 2256 per hash attempt © Expected Hashes: 2256 / target on average * Network Hash Rate: Total hashes per second across all miners * Block Finding Time: Poisson distribution with 10-minute mean, 3, Bitcoin PoW Security Model: * Economic Security: Attack cost exceeds potential benefit * Accumulated Werk: Rewriting history requires reproducing all work + Hash Rate Distribution: Security correlated with decentralization * Thermodynamic Security: Energy expenditure backs security Bitcoin PoW Evolution 1. Mining Hardware Progression: © CPU Era: General-purpose processors (2009-2010) ‘GPU Era: Graphics processing units (2010-2013) * FPGA Era: Field-programmable gate arrays (2011-2013) * ASIC Era: Application-specific integrated circuits (2013-present) * Efficiency Trends: From ~1000 J/TH to ~30,J/TH 2, Protocol Adaptations: * Difficulty Algorithm: Minor adjustments to calculation * Block Header Format: Remained stable ‘+ Timestamp Rules: Allowed variance constraints * AsicBoost: Exploitation and neutralization of optimization technique 3. Environmental Considerations: * Energy Consumption: Estimated 100-150 TWh annually © Geographic Distribution