Cryptocurrency Mining Principles Flashcards

In the context of Bitcoin mining, what is the precise effect of the 'difficulty adjustment' algorithm when the network hash rate drops significantly below the 2-week target window?

Answer: The target hash value increases (becomes less restrictive), making it easier to find a valid block

Bitcoin's difficulty adjustment recalibrates every 2016 blocks (~2 weeks). The 'target' is a 256-bit threshold — a valid proof-of-work requires a block hash numerically below this target. When hash rate drops and blocks are found slower than the 10-minute average, the protocol increases the target value (i.e., raises the ceiling), making the hash condition easier to satisfy and restoring the ~10-minute cadence. Block rewards and mempool rules are entirely separate mechanisms unaffected by difficulty adjustments.

A mining pool uses a 'PPLNS' (Pay Per Last N Shares) payout scheme. A miner joins the pool 30 minutes before the pool finds a block, submitting 500 shares. The pool's sliding window N is set to 10,000 shares and the pool submitted 9,500 shares before the miner joined. How does PPLNS treat this miner's payout relative to a PPS (Pay Per Share) scheme?

Answer: PPLNS pays the miner less because their 500 shares compete against all 10,000 N-window shares, while PPS would credit each share at a fixed rate regardless of timing

Under PPLNS, a miner's reward share is proportional to their contribution within the last N shares window. This miner's 500 shares out of 10,000 total = 5% of the block reward. Under PPS, each accepted share is immediately credited at a fixed rate (expected value per share), so the miner would receive payment for all 500 shares regardless of when the block was found. Late-joining miners are disadvantaged under PPLNS vs. PPS when luck is average or better, because PPLNS dilutes their contribution across the full N window filled partly by pre-joining shares.

Which of the following best explains why ASICs designed for SHA-256 mining (Bitcoin) cannot be repurposed for Monero's RandomX proof-of-work algorithm?

Answer: RandomX is deliberately designed to execute random programs on a general-purpose CPU architecture, making its performance bottleneck DRAM latency and branch prediction — hardware characteristics that ASICs cannot efficiently optimize without resembling a CPU

RandomX was specifically designed to be ASIC-resistant by executing a randomly generated program each epoch using a virtual machine that stresses components ASICs are weak at: large scratchpad memory (256 MB dataset), branch-heavy instruction streams, and floating-point operations. The bottleneck is intentionally placed on DRAM bandwidth and CPU-like pipeline behavior, meaning that an ASIC efficient at RandomX would essentially need to replicate a general-purpose CPU — at which point it loses its cost/performance advantage. This is a deliberate algorithmic design choice, not a legal or power limitation.

During a selfish mining attack, an attacker with 35% of network hash rate withholds a privately mined block. The honest network then mines a block at the same height (a tie). The attacker immediately releases their withheld block. What happens next, and what long-term advantage does this strategy theoretically create?

Answer: A temporary fork exists; the attacker has a head start on the next block because they can begin mining on their block immediately, while honest miners split hash power between both chain tips — giving the attacker a disproportionate share of blocks over time

In a selfish mining attack (Eyal & Sirer, 2014), when the attacker releases a withheld block at the same height as an honest block, honest miners split between the two chain tips. The attacker, already mining on their private tip, gains a statistical lead on the next block. Over repeated rounds, this compounds: with 35% hash rate, selfish mining can yield revenue equivalent to ~45% of blocks (exceeding fair share) by causing honest miners to waste hash rate on blocks that ultimately become orphans. The protocol has no timestamp-based penalty mechanism for this.

In Ethereum's transition from Proof-of-Work to Proof-of-Stake (The Merge, September 2022), what happened to the SHA3/Ethash mining hardware (GPUs) that had been used for ETH mining, and why could they NOT simply switch to validating on the new PoS chain?

Answer: Proof-of-Stake validation requires staking 32 ETH as collateral and runs on standard CPU/network infrastructure — it requires no specialized computation, so GPU mining hardware provides no advantage and cannot 'validate' in the PoW sense

Ethereum's PoS consensus (Gasper/Casper FFG) selects validators based on staked ETH (minimum 32 ETH per validator), not computational power. Validation duties — attesting to blocks, proposing blocks when selected — are cryptographic signing operations that run efficiently on any commodity CPU with reliable internet. There is no hashrate competition; a GPU provides zero advantage over a CPU for PoS validation. Miners' GPUs were either sold, redirected to other PoW chains (e.g., Ethereum Classic, Ravencoin), or repurposed for AI/rendering workloads. No buyback occurred.

A Bitcoin miner observes that the current block template's coinbase transaction can be structured to include an 'extra nonce' field in the scriptSig. Why is manipulating the extra nonce in the coinbase transaction a critical technique for modern ASIC miners, even though the block header already contains a 32-bit nonce field?

Answer: Modern ASICs exhaust the entire 32-bit nonce space (~4.3 billion values) in under a second at current hash rates, so changing the coinbase extra nonce produces a new Merkle root — effectively creating a new block header to restart nonce iteration

The block header nonce is only 32 bits, providing ~4.29 billion values. A modern ASIC farm running at terahashes per second exhausts this entire space in milliseconds. When the nonce space is exhausted without finding a valid hash, miners must change something else in the block header to get a new search space. The Merkle root (a header field) changes when any transaction in the block changes — including the coinbase transaction. By incrementing an 'extra nonce' embedded in the coinbase scriptSig, miners produce a new Merkle root and thus a completely new header to iterate over, effectively giving an unbounded search space. This is fundamental to how Stratum work units are structured.