Cryptocurrency Core Concepts Flashcards

In Bitcoin's UTXO model, when a transaction consumes inputs totaling 1.5 BTC to pay 1.2 BTC to a recipient, what happens to the remaining 0.3 BTC minus the miner fee?

Answer: It must be explicitly included as a change output addressed by the sender

In the UTXO model, UTXOs must be consumed in their entirety. Any unspent value that isn't sent to the recipient or paid as a miner fee must be explicitly directed to a change address (typically controlled by the sender) as a new UTXO output. Failing to include a change output means the surplus goes entirely to miners as an implicit fee — a costly mistake.

Which of the following best describes a 'selfish mining' attack and its primary economic incentive?

Answer: A miner withholds a discovered block to gain a head start on the next block, forcing honest miners to waste work on a soon-to-be-orphaned chain

Selfish mining (proposed by Eyal and Sirer) involves a miner secretly withholding a valid block and continuing to mine on top of it. When honest miners are about to catch up, the selfish miner releases their private chain. This wastes honest miners' computational effort on an about-to-be-orphaned branch, allowing the selfish miner to earn a disproportionate share of block rewards relative to their actual hash power — even below 50% hashrate.

What is the key cryptographic distinction between Schnorr signatures (used in Bitcoin's Taproot) and ECDSA signatures that makes Schnorr preferable for multi-party signing?

Answer: Schnorr signatures are linearly aggregatable, allowing multiple signers' public keys and signatures to be combined into a single indistinguishable key-signature pair

Schnorr signatures satisfy a linearity property: n signers can each contribute a partial signature, and these can be aggregated into a single valid signature under an aggregated public key. This enables MuSig and similar schemes where a k-of-n multisig looks identical on-chain to a single-sig transaction, improving privacy and reducing transaction size. ECDSA lacks this linearity property, making native aggregation impossible.

In Ethereum's proof-of-stake consensus, what is the primary purpose of the 'inactivity leak' mechanism?

Answer: To gradually drain the balances of offline validators so the active set can recover a supermajority (>2/3) and resume finality

If Ethereum fails to finalize blocks (e.g., >1/3 of stake goes offline), the inactivity leak slowly reduces the balances of non-participating validators. This shrinks their share of total stake until the remaining active validators again hold >2/3 of the stake, restoring the quorum needed for finality. It is a liveness recovery mechanism, not a punishment for malicious behavior.

A developer deploys an ERC-20 token contract that contains the following function: `function transfer(address to, uint256 amount) public returns (bool) { balances[to] += amount; balances[msg.sender] -= amount; return true; }`. What critical vulnerability is present?

Answer: There is no check that `balances[msg.sender] >= amount`, enabling an integer underflow that mints unlimited tokens on underflow wrap-around in older Solidity versions

In Solidity versions prior to 0.8.0, arithmetic operations could silently overflow or underflow. Without an explicit check (`require(balances[msg.sender] >= amount)`), subtracting more than available balance would cause an underflow, wrapping `balances[msg.sender]` to an astronomically large number — effectively minting unlimited tokens. Solidity ≥0.8.0 added checked arithmetic by default, but auditors must still recognize this pattern in legacy code.

When comparing Layer 2 rollup architectures, what is the defining security difference between 'optimistic rollups' and 'ZK rollups' in their approach to transaction finality on Layer 1?

Answer: Optimistic rollups assume transactions are valid and rely on a fraud-proof challenge window (typically 7 days) for dispute; ZK rollups post cryptographic validity proofs so finality is achieved as soon as the proof is verified on L1

Optimistic rollups post transaction batches to L1 without immediate proof of validity, assuming correctness ('optimistically'). A challenge window (usually ~7 days) allows any watcher to submit a fraud proof if they detect an invalid state transition. ZK rollups generate a cryptographic validity proof (SNARK or STARK) for every batch; once that proof is verified on-chain, the state transition is final with mathematical certainty — no waiting period required. This is the fundamental security and latency trade-off between the two architectures.