Unit4 - Subjective Questions

A Bitcoin block consists of two main parts: the Block Header and the Transaction Data.

1. Block Header (80 bytes)

The header contains metadata about the block and is hashed to produce the Proof of Work. It includes:

• Version: Indicates which set of block validation rules to follow.
• Previous Block Hash: A reference to the hash of the parent block, linking the blocks into a chain.
• Merkle Root: A hash representing all transactions in the block (ensures integrity).
• Timestamp: Current time as seconds since 1970-01-01 T00:00 UTC.
• Difficulty Target (nBits): A compact representation of the target threshold the block hash must be less than.
• Nonce: A 32-bit field that miners adjust to generate a hash below the target.

2. Transaction Data

• Contains a list of all transactions included in the block.
• The first transaction is always the Coinbase Transaction, which creates new bitcoins for the miner.

The Block Header is crucial because the Proof of Work algorithm is applied only to the header, not the entire transaction list, making mining efficient while the Merkle Root ensures no transaction can be altered without changing the header.

The UTXO (Unspent Transaction Output) model is the fundamental way Bitcoin tracks user balances. Unlike a traditional bank account model (which updates a single balance figure), Bitcoin uses discrete chunks of bitcoin associated with a specific owner.

Key Concepts:

1. Inputs and Outputs: Every transaction consumes existing UTXOs (inputs) and creates new UTXOs (outputs).
2. Indivisibility: UTXOs cannot be partially spent. If a user has a UTXO worth 10 BTC and wants to send 2 BTC, they must spend the entire 10 BTC as an input. The transaction will create two new outputs:
   • 2 BTC to the recipient.
   • 8 BTC (minus transaction fees) back to the sender as 'change'.
3. Verification: Full nodes track the set of all existing UTXOs (the UTXO set) to prevent double-spending. If an input attempts to reference an output that is not in the UTXO set (because it was already spent), the transaction is rejected.

Formula for Balance:

Double Spending is the risk that a digital currency holder could spend the same unit of currency more than once. This is possible in digital systems because digital data can be easily copied.

How Bitcoin Solves It:

1. Decentralized Ledger: Every full node maintains a complete history of transactions. If a user tries to send the same UTXO to two different people, the network sees that the input has already been spent.
2. Timestamping (Ordering): To prevent a race condition where two conflicting transactions are broadcast simultaneously, transactions are grouped into blocks.
3. Proof of Work (PoW):
   • Miners compete to solve a cryptographic puzzle to add a block.
   • Once a block is added, it is computationally expensive to rewrite that history.
   • Longest Chain Rule: If two valid blocks are mined at the same time (a fork), nodes follow the chain with the most accumulated work. Eventually, one chain becomes longer, and the conflicting transaction in the shorter chain is discarded.

By requiring massive energy expenditure to rewrite the ledger, Bitcoin makes double-spending economically infeasible for confirmed transactions.

Proof of Work (PoW) in Bitcoin is a consensus mechanism used to secure the network and validate blocks. It involves miners solving a computational puzzle.

The Algorithm

Bitcoin uses SHA-256. Miners must find a value called a Nonce such that:

• The Target is a 256-bit number.
• The lower the target, the harder it is to find a hash that satisfies the condition.
• Since hash functions act randomly, miners must use brute force, trying billions of nonce values per second.

Difficulty Adjustment

To ensure blocks are generated approximately every 10 minutes, the network adjusts the difficulty every 2016 blocks (roughly 2 weeks).

If blocks were mined too fast, difficulty increases (target decreases). If too slow, difficulty decreases.

Scalability is one of the most significant challenges for Bitcoin, limiting its ability to process a high volume of transactions compared to centralized payment networks (like Visa).

Key Scalability Issues:

1. Block Size Limit:
   • Bitcoin blocks were originally limited to 1 MB (legacy).
   • This limits the number of transactions per block.
2. Block Frequency:
   • A block is mined only every 10 minutes on average.
3. Throughput:
   • Resulting throughput is roughly 3-7 transactions per second (TPS).
4. Network Latency:
   • Propagating large blocks through a decentralized P2P network takes time, increasing the risk of 'stale blocks' (orphans) if the block size is increased too much without optimization.
5. Storage Costs:
   • As the blockchain grows (hundreds of GBs), running a full node becomes expensive, leading to centralization risks where fewer people verify the ledger.

Solutions: Technologies like Segregated Witness (SegWit) and Layer 2 solutions (Lightning Network) were introduced to address these limitations.

A Merkle Tree is a binary hash tree used in Bitcoin to summarize all transactions in a block efficiently.

Structure and Role

1. Hashing Transactions: Every transaction in a block is hashed (TxIDs).
2. Pairing: These hashes are paired and concatenated, then hashed again.
3. Root: This process repeats recursively until a single hash remains, called the Merkle Root.
4. Block Header: Only the Merkle Root is stored in the Block Header.

Benefits

• Integrity: Changing a single bit in any transaction changes its hash, which changes the parent hash, cascading up to change the Merkle Root. This invalidates the block.
• Lightweight Client (SPV) Verification: A node does not need to download the entire block to verify one transaction exists. It only needs the Merkle Path (hashes of partners at each level up to the root).

Complexity

For a block containing transactions:

• The height of the tree is .
• To verify a transaction, an SPV client needs only hashes.
• Complexity:
• This is significantly more efficient than required if a simple list hash were used.

The Nothing at Stake Problem is a theoretical security flaw specific to Proof of Stake (PoS) systems.

The Problem

In Proof of Work, mining on two competing chains (forks) simultaneously is costly because miners must split their physical computing power (hash rate). They naturally converge on one chain to avoid wasting electricity.

In Proof of Stake, validating a block requires negligible computational power. If the chain forks:

• It costs a validator effectively nothing to sign/vote on both forks.
• Validators are incentivized to vote on all forks to ensure they collect transaction fees regardless of which chain eventually wins.
• This prevents consensus from resolving quickly and makes the network vulnerable to double-spend attacks.

Mitigation Strategies

1. Slashing Conditions: Protocols (like Ethereum's Casper) introduce penalties. If a validator is caught signing two conflicting blocks at the same block height, they are 'slashed', meaning they lose a significant portion or all of their staked coins.
2. Penalties: This imposes an economic cost on misbehavior, simulating the physical cost found in PoW.

Bitcoin Script is a Forth-like, stack-based programming language used to process transactions on the Bitcoin network. It instructs the network on how the bitcoins in a UTXO can be spent.

Characteristics

• Stack-Based: It operates using a data stack (LIFO - Last In, First Out). Commands (Opcodes) push data onto the stack or manipulate data already there.
• Stateless: No state is stored between script executions.

Turing Incompleteness

Bitcoin Script is intentionally Turing incomplete, primarily meaning it lacks loops (like while or for) and complex flow control capabilities that allow for infinite recursion.

Reasons for Design

1. Security: Restricting loops eliminates the risk of infinite loops which could crash nodes or freeze the network (Denial of Service attacks).
2. Predictability: The complexity of a script is bounded. Miners can calculate exactly how much resource verification will take.
3. Simplicity: It reduces the attack surface, making it harder to hide malicious logic compared to complex smart contract platforms like Ethereum.

P2PKH is the most common Bitcoin transaction type. It locks bitcoin to the hash of a public key.

ScriptPubKey (Locking Script): OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig (Unlocking Script): <Signature> <PublicKey>

Execution Steps:

1. Combine: The execution begins by running ScriptSig followed by ScriptPubKey.
   • Stack: Empty
2. Push Sig & PubKey: From ScriptSig.
   • Stack: <Signature> <PublicKey>
3. OP_DUP: Duplicates the top item.
   • Stack: <Signature> <PublicKey> <PublicKey>
4. OP_HASH160: Hashes the top item (RIPEMD160(SHA256(PubKey))).
   • Stack: <Signature> <PublicKey> <PubKeyHash_Calculated>
5. Push <PubKeyHash>: From the locking script.
   • Stack: <Signature> <PublicKey> <PubKeyHash_Calculated> <PubKeyHash_Sender>
6. OP_EQUALVERIFY: Checks if the top two items are equal. If yes, pop both. If no, fail.
   • Stack: <Signature> <PublicKey>
7. OP_CHECKSIG: Verifies that the <Signature> matches the <PublicKey> and the transaction data.
   • Stack: TRUE (if valid)

If the final result is TRUE, the transaction is valid and the funds can be spent.

Delegated Proof of Stake (DPoS) is a consensus mechanism that introduces a democratic voting layer to standard Proof of Stake.

How DPoS Works

1. Voting: Token holders do not validate blocks directly. Instead, they use their tokens to vote for 'Delegates' or 'Witnesses'.
2. Validation: Only the top elected delegates (e.g., top 21) are allowed to validate transactions and create blocks.
3. Rotation: The elected group produces blocks in a round-robin fashion.

Difference from Standard PoS

• Efficiency: Because there are fewer validators (e.g., 21 vs thousands in standard PoS/PoW), the network can reach consensus much faster, allowing for higher transaction throughput (TPS).
• Governance: It includes a governance mechanism. If a delegate acts maliciously, voters can withdraw their votes, kicking them out of the validator set effectively immediately.
• Centralization Trade-off: DPoS is often criticized for being more centralized than pure PoS because the network relies on a small number of entities.

Pay to Script Hash (P2SH) allows transactions to be sent to a script hash (an address starting with '3') rather than a public key hash.

Mechanism

Instead of the sender putting a long, complex script into the transaction output (bloating the UTXO set), they essentially send funds to the Hash of a Redeem Script. The recipient must provide the actual Redeem Script (and the signatures to unlock it) only when they want to spend the funds.

Utility in Multi-Signature (Multi-Sig)

Without P2SH, a sender paying into a 2-of-3 Multi-Sig wallet would need to know all 3 public keys and construct a long, complex transaction.

With P2SH:

1. The complexity is shifted from the Sender to the Recipient.
2. The recipient creates a Redeem Script (requiring 2 of 3 signatures).
3. The recipient hashes this script to create a short P2SH address.
4. The sender sends bitcoin to this short address just like a standard payment.
5. This reduces transaction fees for the sender and improves privacy by hiding the spending conditions until the funds are moved.

A 51% Attack occurs when a single miner or a mining pool controls more than 50% of the network's total hashing power (hash rate).

Capabilities of the Attacker:

1. Double Spending: They can spend coins, privately mine a longer chain where that transaction is replaced by a transaction sending the coins back to themselves, and then broadcast the longer chain to reverse the original payment.
2. Censorship: They can prevent specific transactions from gaining confirmations by refusing to include them in blocks.
3. Block Reversal: They can rewrite the recent history of the blockchain.

What they CANNOT do:

• They cannot steal people's existing funds (they don't have private keys).
• They cannot change the rules of the system (e.g., creating more than 21 million BTC) as full nodes would reject invalid blocks regardless of hash power.

Implications

While theoretically possible, a 51% attack on Bitcoin is economically prohibitive due to the massive hardware and electricity cost required to overpower the current network hash rate.

Proof of Burn (PoB) is an alternative consensus mechanism where miners demonstrate their investment in the network by destroying ('burning') cryptocurrency rather than expending energy.

How it Works

1. Burning: Miners send coins to a verifiable 'eater address' (an address with no known private key) from which they can never be spent.
2. Virtual Mining: This act of burning is recorded on the blockchain. The more coins a user burns, the higher their probability of being selected to mine the next block.
3. Decay: Usually, the 'power' gained from burning decays over time to encourage continued investment.

Advantages over PoW

• Energy Efficiency: It does not require massive electricity consumption.
• Long-term Commitment: Burning coins signals a strong long-term belief in the asset's stability, as the investment is destroyed immediately for future rewards.

Forks occur when there is a change in the protocol rules.

Hard Fork

• Definition: A permanent divergence in the blockchain. It occurs when non-upgraded nodes cannot validate blocks created by upgraded nodes.
• Compatibility: Not backward compatible. Old nodes reject the new blocks.
• Result: The chain splits into two separate currencies (e.g., Bitcoin vs. Bitcoin Cash) if not everyone upgrades.
• Rule Change: Usually involves loosening rules (e.g., increasing block size from 1MB to 8MB).

Soft Fork

• Definition: A change to the protocol where only previously valid blocks/transactions are made invalid.
• Compatibility: Backward compatible. Non-upgraded nodes still recognize the new blocks as valid (though they may not understand the new features).
• Result: One single chain is maintained, provided the majority of hashing power upgrades.
• Rule Change: Usually involves tightening rules (e.g., SegWit, which added constraints on how data is stored but looked valid to old nodes).

Privacy Challenges:
Bitcoin is pseudonymous, not anonymous.

1. Public Ledger: Every transaction is visible. If a real-world identity is linked to a Public Address (e.g., via a KYC exchange), their entire financial history can be traced.
2. Address Reuse: Reusing addresses makes clustering user activity easier for chain analysis firms.

CoinJoin Solution

CoinJoin is a privacy strategy that combines multiple payments from different spenders into a single transaction.

• Mechanism: Several users agree to create a transaction with multiple inputs (from User A, User B, User C) and multiple outputs (to Recipient A, Recipient B, Recipient C).
• Result: Looking at the blockchain, it becomes difficult to determine exactly which input corresponds to which output. It breaks the link between the sender and the receiver history.
• Implementation: Wallets like Wasabi or Samurai implement CoinJoin (e.g., Whirlpool) to mix UTXOs.

The Lightning Network is a Layer 2 scaling solution built on top of Bitcoin.

Mechanism

It uses Payment Channels. Two parties open a channel by creating a multi-sig transaction on the main blockchain (funding transaction). They can then transact back and forth instantly off-chain thousands of times without broadcasting to the main network.

• Updating Balance: They exchange signed transactions that update their local balance sheet but don't broadcast them.
• Settlement: Only when they decide to close the channel is the final balance broadcast to the Bitcoin blockchain.

Solving Scalability

1. Throughput: Enables millions of transactions per second (TPS) as they are limited only by internet speed, not block size.
2. Cost: Fees are negligible because miners are not validating every micro-transaction.
3. Speed: Instant settlement (no 10-minute wait).

It reduces the load on the main blockchain by taking small, frequent transactions off-chain.

Mining Pools are groups of cooperating miners who agree to share block rewards in proportion to their contributed mining hash power.

Role

• Variance Reduction: A solo miner might take years to solve a block and get a reward. By pooling resources, the group finds blocks frequently.
• Reward Distribution: The pool operator distributes the 6.25 BTC (plus fees) reward to participants based on the 'shares' (partial proofs of work) they submitted.

Centralization Concerns

• Hash Rate Concentration: If a few large pools control >51% of the network hash rate, they could theoretically collude to launch a 51% attack.
• Transaction Censorship: Pool operators decide which transactions go into a block. If 2 or 3 operators control the majority of the network, they could be pressured by governments to censor specific addresses.
• Protocol Governance: Large pools have significant sway in voting for or against protocol upgrades (Soft Forks).

1. Creation: The user's wallet creates a transaction by gathering UTXOs (inputs), specifying the destination (outputs), and signing the inputs with private keys.
2. Broadcasting: The wallet sends the signed transaction to neighboring nodes in the P2P network.
3. Validation (Mempool): Nodes verify the transaction (signatures, UTXO availability). If valid, they add it to their Mempool (Memory Pool) and propagate it to other nodes.
4. Mining: A miner selects transactions from their Mempool (usually prioritizing high fees) and constructs a candidate block.
5. Proof of Work: The miner attempts to solve the hash puzzle for the candidate block.
6. Block Propagation: Once a miner finds the nonce, they broadcast the block to the network.
7. Verification: Other nodes verify the block's PoW and transactions. If valid, they append it to their blockchain.
8. Confirmation: The transaction is now confirmed (1 confirmation). As subsequent blocks are mined on top of it, the confirmation count increases, making the transaction immutable.

Bitcoin uses Probabilistic Finality, unlike some other consensus models (like PBFT) that offer absolute finality.

Explanation

• Immediate Reversibility: When a block is just mined, there is a small chance that another miner mined a competing block at the same time (a temporary fork).
• Confirmation Depth: As more blocks are added on top of the block containing a transaction, the probability of the chain being reorganized (removing that block) drops exponentially.
• Standard Practice: A transaction is generally considered 'secure' after 6 confirmations (approx. 1 hour).

Limitation

This probabilistic nature makes Bitcoin unsuitable for applications requiring instant, absolute settlement (e.g., point-of-sale retail) without using Layer 2 solutions, as there is always a theoretical (though statistically vanishing) chance of a deep chain reorganization.