Unit 4 - Practice Quiz

The Bitcoin protocol is designed to target an average block creation time of 10 minutes. This is maintained by an algorithm that adjusts the mining difficulty every 2016 blocks.

The Genesis Block is the first block of a blockchain. In Bitcoin, it was mined by Satoshi Nakamoto and is hardcoded into the software.

Satoshi Nakamoto is the name used by the presumed pseudonymous person or persons who developed Bitcoin, authored the Bitcoin white paper, and created its original reference implementation.

This linking mechanism creates an immutable chain. The hash of the previous block's header is included in the current block's header, ensuring that any change to a past block would invalidate all subsequent blocks.

Double-spending is a potential flaw where the same single digital token can be spent multiple times. Bitcoin solves this with its public ledger and a consensus mechanism like Proof of Work.

If an attacker controls the majority of the network's mining hash rate, they can potentially reverse their own transactions and prevent other transactions from being confirmed, enabling double-spending.

The mining difficulty is adjusted every 2016 blocks (roughly two weeks) to account for changes in the total network hash rate, ensuring the average time to find a new block remains close to the 10-minute target.

PoW makes it computationally expensive to add new blocks, which secures the blockchain from tampering and allows decentralized nodes to agree on a single, valid chain of transactions.

Mining is the term for the process where network participants (miners) use specialized hardware to solve the cryptographic puzzle, validate transactions, and add new blocks to the blockchain.

Bitcoin's Proof of Work algorithm uses the SHA-256 (Secure Hash Algorithm 256-bit) hashing function. Miners repeatedly hash the block header until the result is below a certain target value.

The miner who successfully solves the PoW puzzle and adds a valid block to the chain is rewarded with a block reward (newly minted bitcoins) and all the transaction fees from the transactions included in that block.

In PoS, validators are chosen to create new blocks based on the number of coins they hold and have locked up as collateral. The more coins staked, the higher the chance of being selected.

PoS does not require intensive computational work to secure the network. This drastically reduces the electricity consumption compared to PoW, making it a much more environmentally friendly consensus mechanism.

While 'mining' is the term associated with PoW, 'forging' or 'minting' are commonly used to describe the block creation process in a PoS system.

DPoS is a variation of PoS where users stake their coins to vote for a limited number of 'delegates' or 'witnesses'. These elected delegates are then responsible for producing and validating blocks.

PBFT and similar algorithms are designed for systems with a known, limited number of validators. They provide high transaction throughput and fast finality, making them ideal for trusted, permissioned environments.

In PoA, validators do not stake coins but instead stake their real-world reputation. Blocks are created by pre-approved participants (authorities) who are trusted entities, making the system highly efficient but centralized.

Bitcoin has a simple, stack-based scripting language officially known as Script. It is used to define the conditions that must be met to spend transaction outputs.

By purposely omitting features like complex loops, the language ensures that scripts will always terminate and have predictable execution costs. This greatly enhances network security by limiting the attack surface for malicious scripts.

The Bitcoin Script allows for the creation of complex spending conditions beyond a simple signature check. A multisig transaction's script specifies that multiple private keys must provide signatures before the funds can be moved.

The UTXO model is not like a bank account balance where a value is debited. UTXOs are indivisible and are fully consumed in a transaction. The transaction creates new UTXOs from the inputs: one for the recipient (1 BTC) and one for the change back to the sender (3 - 1 - 0.001 = 1.999 BTC). The fee is implicitly claimed by the miner and does not become a new UTXO.

The Merkle root is a single hash representing all transactions in a block. An SPV or "light" client can confirm a transaction is included by downloading only the block headers and the "Merkle path" (a small number of intermediate hashes) for that specific transaction. This is far more efficient than downloading every transaction in the entire block.

The target time for 2016 blocks is 2016 blocks 10 minutes/block = 20160 minutes, which is exactly 14 days. If the blocks were found in 7 days, the network was running twice as fast as intended. To bring the block time back to the 10-minute target, the difficulty must be doubled (increased by 100%). The formula is `New Difficulty = Old Difficulty (Expected Time / Actual Time), which isOld Difficulty (14 days / 7 days) = Old Difficulty 2`.

Transaction malleability occurs when a third party alters the signature of a transaction without invalidating it, which changes the transaction ID (txid). SegWit solves this by moving the signature (witness) data out of the part of the transaction that is hashed to calculate the txid. Since the txid no longer depends on the witness data, the txid cannot be changed by manipulating the signature.

The "nothing-at-stake" problem arises because creating a block in PoS has a very low marginal cost. If a fork occurs, a rational validator has an economic incentive to build on both chains to maximize their chances of earning rewards. In PoW, a miner must dedicate their computational resources and associated energy cost to only one chain, making it economically irrational to support multiple forks simultaneously.

Unlocking a P2SH output is a two-step validation process. First, the spender provides the full redeem script, which the network hashes to ensure it matches the script hash in the output's scriptPubKey. Second, the spender provides the necessary signatures or other data required by the redeem script itself. The network then executes this redeem script with the provided data to finally validate the transaction.

In DPoS, coin holders vote for a limited number of "delegates" or "witnesses" who are responsible for producing blocks. Because the number of block producers is small and known (e.g., 21), consensus can be reached very quickly. This significantly increases transaction throughput. The main trade-off is that power is concentrated in the hands of these few elected entities, making the system less decentralized than Bitcoin's PoW.

A 51% attack gives the attacker control over the ordering of transactions and the ability to mine a new, longer version of the blockchain. They could broadcast a transaction (e.g., paying an exchange), let it confirm, and then use their majority hash power to mine a new chain that excludes that transaction. This new, longer chain would become the accepted one, effectively reversing their own payment. They cannot, however, change consensus rules (like the coin supply limit) or forge signatures to steal funds from others.

The "puzzle-friendly" property is crucial for PoW. It means there's no shortcut to solving the mining puzzle (finding a hash below the target). The only way a miner can find a valid hash is by repeatedly trying different nonces (inputs) until they get lucky. This makes the mining process a fair competition based purely on computational power.

A Turing complete language allows for complex computations, including loops of indeterminate length. If Bitcoin's Script were Turing complete, a malicious actor could create a transaction with a script that runs forever. When nodes tried to validate this transaction, their systems would get stuck, effectively launching a denial-of-service (DoS) attack. By intentionally limiting the language (e.g., no complex loops), every script is guaranteed to terminate in a predictable amount of time, making validation secure.

Slashing is a punitive measure designed to enforce honest behavior from validators. If a validator is caught performing a malicious act, such as attesting to two different blocks at the same height (double-signing), the protocol automatically destroys a portion of their staked coins. This creates a significant financial penalty, making attacks costly and irrational.

The Lightning Network is a Layer 2 solution. It allows users to open payment channels with each other. Transactions within these channels happen off-chain, are nearly instant, and have very low fees. Only the opening and closing transactions of a channel need to be recorded on the main Bitcoin blockchain, which vastly reduces the load on the network and allows for a high volume of small payments.

The Bitcoin protocol includes a "halving" event approximately every four years, which cuts the new bitcoin subsidy in half. Over time, this subsidy will trend towards zero. For the network to remain secure, miners must continue to be incentivized to expend energy. Transaction fees, paid by users for block inclusion, are intended to take over as the main source of revenue for miners, ensuring the security budget of the network remains substantial.

PBFT algorithms are designed for systems where the participants (validators) are known and their total number is fixed. The consensus process involves multiple rounds of voting, which is efficient with a small number of validators but does not scale to the large, dynamic, and anonymous set of participants in a public network like Bitcoin. Its major advantage in a permissioned setting is fast performance and deterministic finality (transactions are irreversible once confirmed).

nLockTime is a field that specifies the earliest time a transaction can be legally mined. If the value is less than 500 million, it's interpreted as a block height; otherwise, it's a Unix timestamp. This feature enables use cases like time-locked payments or creating payment channels where transactions are only valid after a certain period, forming a crucial component for more complex protocols like the Lightning Network.

The validation process executes the scriptSig (pushing the signature and public key to the stack) followed by the scriptPubKey (which contains opcodes). The final opcode, OP_CHECKSIG, consumes the public key and signature, compares them, and pushes a single TRUE (represented as 1) or FALSE (0) value back. For the transaction to be valid, the script must complete with a single non-zero value left on top of the stack.

In Bitcoin's PoW consensus, a transaction is never 100% final in a mathematical sense. The security of a transaction is based on the amount of cumulative work built on top of the block containing it. An attacker wanting to reverse a transaction would have to re-mine that block and all subsequent blocks faster than the rest of the network. The cost to do this grows with each new block added. Therefore, the likelihood of a reversal becomes vanishingly small as more blocks (confirmations) are added, leading to "probabilistic finality".

In selfish mining, a miner with a secret chain can get a head start. If the public chain finds a competing block, the selfish miner can release their longer private chain, which causes the honest miner's block to be orphaned and the selfish miner to win the reward. By strategically releasing their privately mined blocks, they can cause honest miners to waste effort on a chain that will ultimately be abandoned, thus increasing the selfish miner's relative share of total block rewards.

In Bitcoin's PoW, finding a valid block means finding a hash that is numerically less than the current target value. A lower target value is harder to find and thus represents a higher difficulty. Requiring more leading zeros in the hash's hexadecimal representation corresponds to a much smaller numerical target. Therefore, an increase in difficulty means the target becomes smaller, which is commonly described as requiring more leading zeros.

While the blockchain's confirmation ultimately prevents double-spending, the network's first line of defense is the mempool policy of individual nodes and miners. When a node receives a transaction spending a specific UTXO, it adds it to its memory pool. If it then receives a second, conflicting transaction spending the same UTXO, it will identify it as a double-spend attempt and reject it. Whichever of the two transactions gets mined into a block first becomes canonical, invalidating the other permanently.

This script uses OP_IF/OP_ELSE/OP_ENDIF to create two distinct spending paths. To trigger the OP_IF branch, the spender must push a non-zero value (e.g., OP_1) onto the stack. The script then executes the 2-of-3 OP_CHECKMULTISIG. To trigger the OP_ELSE branch, the spender pushes a zero value (OP_0). This path first checks if the spending transaction's nLockTime is greater than or equal to the specified timestamp using OP_CHECKLOCKTIMEVERIFY. If it is, OP_DROP removes the timestamp from the stack, and the script proceeds to require a single signature from key D via OP_CHECKSIG.

Block discovery follows a Poisson process. The average time for the entire network to find a block is 10 minutes, so the network-wide rate is 0.1 blocks/minute. The pool's rate is blocks/minute. The probability of an event occurring at least once in an interval is given by . For a 60-minute period, the calculation is: . This is approximately 59.4%.

While using new addresses for receiving payments and for change is a crucial privacy practice, its effectiveness is limited when a user needs to construct a transaction that requires consolidating multiple UTXOs. When a transaction has multiple inputs, chain analysis tools operate on the strong assumption that all those input addresses are controlled by the same wallet or entity. This allows them to link previously separate addresses and activity clusters together, effectively merging the user's pseudonymous identities. Techniques like CoinJoin are specifically designed to break this heuristic.

The txid is the double-SHA256 hash of the entire transaction data, including the signature script. The ECDSA signature scheme has properties that allow for multiple valid encodings of the same signature. The most famous example is that if (r, s) is a valid signature, so is (r, -s mod N), where N is the order of the curve. A third party could take a transaction from the mempool, change the signature encoding, and produce a transaction with a new txid that was still valid and spent the same inputs to the same outputs. The main problem this caused was for unconfirmed chained transactions. If a child transaction was created to spend an output from the parent, it would reference the parent's original txid. If the parent was malleated before confirmation, its txid would change, invalidating the child transaction.

Modern PoS protocols solve the Nothing-at-Stake problem by creating a significant economic disincentive for equivocating (voting on multiple forks). This is achieved through slashing. If a validator signs two different blocks at the same block height or makes contradictory attestations, another user can submit proof of this malicious behavior to the chain. The protocol then automatically punishes the offending validator by 'slashing' a portion of their staked capital, which is permanently destroyed. This makes it economically irrational to vote on multiple chains, as the potential loss from slashing far outweighs any potential reward from being on the 'winning' fork.

SegWit introduced new output types. For P2WSH (the SegWit equivalent of P2SH), the scriptPubKey is a version byte (OP_0) followed by the 32-byte SHA256 hash of the redeem script. This is different from legacy P2SH which uses OP_HASH160 and a 20-byte hash. To spend this output, the transaction's scriptSig must be empty. The spending logic is provided entirely in the witness field, which must contain the signatures required by the script (in this case, two signatures) and, finally, the full redeem script itself. The node verifies by first hashing the provided redeem script to ensure it matches the 32-byte hash in the scriptPubKey, and then executing the redeem script with the provided signatures.

This is a core distinction. In Bitcoin, a transaction is never 100% final. With each new block added on top (a 'confirmation'), the probability of a reorganization deep enough to reverse the transaction decreases exponentially, approaching (but never reaching) zero. This is probabilistic finality. In PBFT, consensus is reached through a multi-stage voting process among a known set of validators. Once a supermajority (2/3 + 1) of validators agree on a block, it is considered final, and the protocol guarantees it will not be reverted unless more than 1/3 of the validators are Byzantine (malicious or faulty). This is absolute or deterministic finality within the model's assumptions.

The difficulty is fixed for the 2016-block period. A 40% decrease means the new hashrate is 60% (or 0.6) of the old hashrate. Since block time is inversely proportional to hashrate, the new average block time will be the old time divided by the new hashrate factor. New Time = (Old Time) / (New Hashrate Multiplier) = 10 minutes / 0.6 = 16.67 minutes. The difficulty will only adjust downwards to correct this after this slow 2016-block period has completed.

When a party broadcasts a commitment transaction (especially a revoked, old one), the output paying back to themselves is not immediately spendable. It is locked by a script containing a relative timelock (e.g., OP_CHECKSEQUENCEVERIFY). This to_self_delay (e.g., 144 blocks) means that even if they broadcast an old state to cheat, they cannot access their own part of the funds until that delay has passed. Crucially, this output also has a second spending path: it can be spent immediately by the other party if they possess the revocation key for that specific state. This delay period is therefore the 'justice window' where the honest party (or their watchtower) can detect the fraud and sweep all the funds in the channel as a penalty.

The Merkle root in the block header commits to the set of transaction hashes (txids). If an attacker finds a collision where two different transactions T1 and T2 result in the same txid, they can build a Merkle tree that is valid for both. They could get the user to agree to a payment in T1. The attacker would then mine a block containing T2 but with the same Merkle root. The block header's hash and proof-of-work would be valid. They could then privately show the user evidence of the block containing T1 (which has a valid Merkle proof against the block header) while broadcasting the block containing T2 to the rest of the network, effectively stealing the funds. While computationally infeasible today, this demonstrates the critical importance of collision resistance in the hash function used for Merkle trees.

A long-range attack involves an attacker using old private keys (from a time when they controlled a large amount of stake) to create a long, alternative history from a point deep in the past. Because creating PoS blocks is cheap, they can generate this chain quickly. This attack is not effective against existing online nodes, as they have already accepted the legitimate chain and won't re-organize past a certain point. However, a brand new node syncing from genesis has no prior knowledge of the 'correct' chain. It might see the attacker's long, valid-looking (but fake) chain and accept it as the truth. This is why modern PoS protocols rely on social consensus and weak subjectivity checkpoints to provide new nodes with a trusted recent state to sync from, mitigating this attack.

A P2TR output's address commits to a tweaked public key, where the tweak is derived from an internal public key and the Merkle root of the possible spending scripts. For a cooperative 'key-path' spend, only a signature is needed. However, for a non-cooperative 'script-path' spend, the spender must prove that their desired spending condition was one of the ones originally committed to. To do this, they provide in the witness: 1) The inputs for the script they are using (e.g., signatures, preimages). 2) The full body of that script. 3) The Merkle proof, which consists of the sibling hashes needed to re-calculate the Merkle root. The verifying node uses the provided script and Merkle proof to recalculate the root, checks that it matches the commitment in the UTXO, and then executes the script.

The core of selfish mining profitability is not about earning more from a single block, but about increasing the miner's long-term share of total rewards beyond their share of hashrate (). When the selfish miner has a secret chain and the public chain finds a block, the selfish miner broadcasts their competing block. The network is now split. The selfish miner mines on their chain, while honest miners are split or mine on the public chain. If the selfish miner finds the next block, their chain is now longer and the honest block gets orphaned. This means the honest miners' work was wasted. By successfully orphaning blocks from the honest network, the selfish miner reduces the competition's revenue, thereby increasing their own proportional revenue above their direct hashrate contribution.

If a miner could spend their block reward immediately, and then a chain reorganization occurred that orphaned their block, the original coinbase transaction would become invalid. Consequently, any transaction that spent those coins would also become invalid, as would any transactions that spent those, and so on. This could cause a cascade of transaction invalidations across the network, creating chaos and economic loss. By requiring a 100-block wait, the rule ensures that a block is very deeply buried in the chain and thus extremely unlikely to ever be orphaned before its reward becomes spendable, preserving the stability of the ledger.

The core trade-off of DPoS is sacrificing decentralization for performance. By having a small, fixed set of known block producers (e.g., 21), the system becomes highly efficient. However, this creates a de facto oligopoly. These producers can communicate off-chain and collude. They might agree to vote for each other to stay in power, blacklist transactions from certain users (censorship), or alter the protocol for their own benefit. This introduces a level of trust in a small group that is antithetical to the goals of maximum decentralization seen in systems like Bitcoin.

A Bitcoin transaction has a certain base size (for version, locktime, etc.) and then a size per input and per output. If an exchange processed 100 withdrawals as 100 separate transactions, they would pay the base size cost 100 times. By batching, they create a single transaction with potentially many inputs and 100 outputs. This transaction only has the base size cost once. While the total size is large, the average size per withdrawal is significantly smaller than it would be otherwise. This leads to a dramatic reduction in total transaction fees paid to miners, making it a highly efficient practice. While it has privacy implications (linking all outputs to the exchange), its main driver is economic efficiency.

The probability of a single hash being valid is the ratio of the number of successful outcomes to the total number of possible outcomes. The number of successful outcomes is (from 0 to T-1), and the total number of outcomes is (or M+1). So, . The expected number of trials for one success is the reciprocal of the probability, . The official Bitcoin 'difficulty' metric is a relative measure defined as the ratio of the easiest possible target (, also called the difficulty_1_target) to the current target (). So, Difficulty = . The expected number of hashes is not just but is directly related to this difficulty metric, which scales this expectation. Option C is the most precise definition used in practice.

This is a hash puzzle with a size constraint. Let's trace the stack with the spender's input <data>: 1. The <data> is pushed to the stack. 2. OP_SIZE pushes the size of <data> (in bytes) onto the stack. 3. <32> is pushed. Stack is [<data>, size_of_data, 32]. 4. OP_EQUALVERIFY checks if size_of_data equals 32. If not, the script fails. If it does, both values are consumed. Stack is [<data>]. 5. OP_SHA256 hashes the top item, replacing it with its hash. Stack is [hash(data)]. 6. <expected_hash> is pushed. 7. OP_EQUAL compares the two hashes. The script succeeds only if they match. This is a common pattern for revealing a pre-image to a hash (like in HTLCs), but with the added constraint that the pre-image must be exactly 32 bytes.

This question tests a nuanced interaction between two fields. The nLockTime field sets an absolute time-lock for a transaction. However, this lock is only enabled if at least one of the transaction's inputs has an nSequence number less than the maximum value of 0xFFFFFFFF. If all inputs have their nSequence number set to 0xFFFFFFFF, the nLockTime logic is completely disabled for that transaction. Therefore, despite the future nLockTime value, the transaction is considered final and can be included in a block immediately.

A major challenge in PoS is preventing attacks on the next block producer. If the selection algorithm is publicly predictable, an attacker knows exactly which node to target with a DDoS attack to stall the network. A VRF solves this by being non-predictable. Each validator can privately use their secret key and a public seed to compute a random output. Only they know if their output 'wins' the slot. No one else can predict the winner in advance. When the winner produces the block, they publish a proof along with it. Anyone can then use the validator's public key to verify the proof, confirming they were chosen legitimately. This provides verifiability without predictability.