Cryptocurrency Core Concepts Flashcards

In Bitcoin's Script language, what is the primary security purpose of the OP_CHECKLOCKTIMEVERIFY (CLTV) opcode when used in a payment channel closing transaction?

Answer: It prevents a counterparty from broadcasting an outdated channel state by making the output unspendable until a specified block height or Unix timestamp

OP_CHECKLOCKTIMEVERIFY (BIP 65) makes a transaction output unspendable until the blockchain reaches a specified block height or Unix timestamp. In payment channels, this is used in refund transactions so a party can reclaim funds if the channel partner disappears, but the time-lock prevents premature broadcasting that could undermine the channel's cooperative close.

Which cryptographic property allows a Merkle tree structure in a block header to provide a compact proof that a specific transaction is included in a block, without downloading the entire block?

Answer: Second pre-image resistance enabling Simplified Payment Verification (SPV) proofs

Second pre-image resistance is the property that makes SPV (Merkle) proofs secure: given a known transaction hash (leaf), it is computationally infeasible to find a different transaction that hashes to the same value. This allows an SPV client to verify inclusion using only the sibling hashes along the Merkle path (a logarithmic-length proof), trusting that a valid Merkle root commits to that exact transaction.

Under Ethereum's EIP-1559 fee mechanism, what happens to the base fee when consecutive blocks are consistently filled to exactly 50% of the target gas limit?

Answer: The base fee remains unchanged because 50% capacity is the equilibrium target

EIP-1559 sets the target block size at 50% of the maximum gas limit. The base fee adjustment formula only changes the base fee when blocks deviate from this 50% target: above 50% causes the base fee to rise (up to +12.5% per block), and below 50% causes it to fall (up to -12.5% per block). At exactly 50% utilization, the adjustment factor is zero and the base fee remains stable — this is the protocol's designed equilibrium.

In the context of cryptocurrency mining, what distinguishes a 'selfish mining' attack from a standard 51% attack, and why can selfish mining be profitable at hash rates below 50%?

Answer: Selfish mining withholds discovered blocks to gain disproportionate revenue by forcing honest miners to waste work on stale branches, and it can be profitable above roughly 33% hash rate with optimal network connectivity

In a selfish mining attack (Eyal & Sirer, 2014), the attacker withholds a found block and continues mining in secret. When honest miners find the next block, the attacker releases their private chain, causing honest miners' work to become orphaned. The attacker earns a disproportionate share of block rewards relative to their hash rate. Critically, the threshold at which this becomes profitable is approximately 33% of total hash rate (not 50%), and a well-connected attacker with γ=0.5 propagation advantage can profit at even lower thresholds — making it distinct from a simple majority attack.

What is the role of the 'nonce' field in an Ethereum transaction, and what specific vulnerability does it prevent that would otherwise be exploitable even on a different blockchain network?

Answer: It is a per-account sequential counter that prevents transaction replay attacks both on the same chain and — combined with EIP-155 chainId — across different EVM-compatible chains

Ethereum's per-account nonce is a strictly incrementing counter that ensures each transaction can only be included once on a given chain (preventing replay attacks). Before EIP-155, a valid transaction on Ethereum mainnet could be replayed on Ethereum Classic because the signature did not commit to the chain ID. EIP-155 solved cross-chain replay by incorporating the chainId into the transaction signing hash (v = {0,1} + 2*chainId + 35), so a transaction signed for one EVM chain is cryptographically invalid on another.

In a Lightning Network Hash Time-Locked Contract (HTLC), which combination of conditions must be satisfied to allow the payment recipient (Bob) to claim the funds from an intermediate routing node (Carol)?

Answer: Bob must reveal the preimage R such that SHA256(R) equals the payment hash H, and he must do so before the HTLC's absolute timelock expires

An HTLC has two spending paths: (1) the hashlock path — claimable by anyone who presents a preimage R where SHA256(R) = H — and (2) the timelock path — refundable to the sender after the absolute block height expires. For Bob to claim from Carol's HTLC output, he must present the correct preimage R before the timelock expires. No co-signature from Carol is required for the hashlock redemption path; the Script itself validates the preimage. Carol's role is only to forward the payment and later claim from the upstream HTLC using the same preimage Bob revealed.