Proof of Work & Security: Mechanics, Incentives, and Risks

Section IV: Consensus Mechanisms

Army Cyber Institute

April 9, 2026

Proof of Work: Purpose and Agenda

What is Proof of Work? - Converts expensive, verifiable computation into a Sybil‑resistant leader election for block proposals - Produces a publicly checkable ordering of blocks where rewriting requires proportional real‑world cost

In this lesson, we will: - Understand the PoW validity rule and how target/difficulty encode expected work - Model mining as a stochastic race; explain orphans and propagation effects - Analyze core threats: double spends, 51% control, selfish mining, eclipse, timestamp games, pool attacks - Connect security to economics: hash‑rate majority, fees vs subsidy, and security budgets

Overall Slide Concept This opening slide frames Proof of Work as both a consensus mechanism and a security budget. It matters here because the rest of the lesson connects block validation, attack cost, and miner incentives into one system. Emphasize that PoW is about leader election and history protection, not just “mining” as an isolated activity.

Key Points - Proof of Work makes block proposal influence expensive and publicly checkable. - Rewriting history requires proportional real-world cost in hardware and energy. - The lesson focuses on mechanics, threats, and the economics that support security.

Walkthrough None

Sources - [1] - [2]

Block Body Anatomy

Recall: A ledger is a history of transactions. A blockchain chains blocks of transactions together.

The block body contains the actual ledger—a set of transactions that transfer value or state. To protect this ledger:

• All transactions in the block are hashed together into a single Merkle root
• The Merkle root is a cryptographic fingerprint: any change to any transaction changes the root
• The root is embedded in the block header, so the entire ledger is secured by the Proof of Work

Overall Slide Concept This slide reminds students that Proof of Work protects a block header which commits to a block body full of transactions. It matters here because later attack and verification discussions only make sense if students remember what the Merkle root is securing. Emphasize that the body holds the ledger content, while the header carries the compact commitments that miners actually hash.

Key Points - The block body contains the actual transactions or state updates being recorded. - A Merkle root compresses those transactions into one hash commitment. - Changing any transaction changes the Merkle root and therefore the secured header. - Merkle root means a single digest derived from a tree of transaction hashes.

Walkthrough None

Sources - [3] - [4]

The PoW Rule at a Glance

• Common block header components: version, previous block hash, Merkle root, timestamp, difficulty target, and nonce.
  
• Validation rule: the block is valid the puzzle is solved below the difficulty target—easy to check, hard to find. Hashes often used as puzzle.
• Fork choice: nodes follow the longest (or heaviest) valid chain according to the protocol’s rules.
  
• Core idea: computation is costly to produce but cheap to verify, enabling secure, open participation without central authority.

Overall Slide Concept This slide gives the core PoW validation rule before the class dives into the supporting mechanics. It matters here because every later concept—difficulty, forks, confirmations, and attacks—depends on the hash-below-target rule and the chain-selection rule. Emphasize that producing valid work is hard, but verifying it is cheap and objective.

Key Points - A block header is valid only if its hash falls below the current difficulty target. - Nodes choose the longest or heaviest valid chain according to protocol rules. - Costly production and cheap verification make open participation possible.

Walkthrough None

Sources - [1] - [4]

Proof-of-work Puzzles

A PoW puzzle is any computation that is:

• Hard to solve: requires significant computational effort
• Easy to verify: a solution can be checked quickly by anyone

Common PoW puzzle types:

• Hash puzzles: find a nonce such that hash(data || nonce) meets a target (e.g., Bitcoin)
• Memory-hard puzzles: require large amounts of RAM, resistant to specialized hardware (e.g., Scrypt, Argon2)
• Proof-of-space puzzles: require storage of pre-computed data (e.g., Chia, Filecoin)
• Proof-of-useful-work: solve real scientific or computational problems with practical value

For this discussion, we focus on hash-based puzzles. The same principles apply to other puzzle types.

Overall Slide Concept This slide broadens the idea of PoW beyond Bitcoin’s specific hash puzzle to show the underlying design pattern. It matters here because students should see that the consensus role comes from asymmetry between solving and verifying, not from SHA-256 alone. Emphasize that the course will focus on hash-based puzzles while recognizing other resource-binding approaches.

Key Points - A PoW puzzle must be expensive to solve but fast for others to verify. - Hash puzzles, memory-hard puzzles, and proof-of-space all bind influence to scarce resources differently. - The security logic is similar even when the resource being consumed changes.

Walkthrough None

Sources - [1] - [4]

Block Header Anatomy: What Gets Hashed

• Previous block hash: links each block to its predecessor, forming the blockchain.
  
• Merkle root: commits to all transactions in the block through a single hash summary.
  
• Difficulty target: defines computational difficulty to solve puzzle for the given block.
• Nonce: example of a field miners vary to explore new hashes
• Precision matters: the hash output depends exactly on the header’s byte order and encoding—any difference changes the result.

Overall Slide Concept This slide explains exactly what miners hash when searching for a valid block. It matters here because security and interoperability depend on all nodes hashing the same bytes in the same order. Emphasize that tiny encoding differences change the result completely, so serialization details are security-relevant.

Key Points - The header includes fields such as the previous block hash, Merkle root, target, timestamp, and nonce. - Miners vary nonce-like fields to search the hash space for a valid result. - Byte order and encoding matter because hashing is deterministic on exact bytes. - Nonce means an adjustable number used to try new candidate hashes.

Walkthrough None

Sources - [5] - [6]

Difficulty, Hash Rate, and Expected Work

• Each hash is an independent trial: the chance of success is roughly \(p ≈ \frac{target}{2^{b}}\), where \(b\) represents the number of bits in the hash digest.
• Expected work: on average, a miner must try about \(\frac{1}{p}\) hashes before finding a valid block.
  
• Network hash rate (H): with H total hashes per second, the expected block time is (1/p) ÷ H.
  
• Difficulty tuning: often, the protocol adjusts the target so blocks arrive at a consistent average interval (e.g., ~10 minutes in Bitcoin).

Overall Slide Concept This slide connects target values, hash rate, and expected block-finding time into one probabilistic picture. It matters here because students need an intuitive model for why more total hash power shortens expected search time at a fixed target. Emphasize that mining is a race of many independent trials rather than a deterministic schedule.

Key Points - Difficulty and target determine how rare a valid hash is. - Hash rate measures how many attempts miners can make per unit time. - More aggregate hash rate means the network reaches valid blocks faster unless difficulty adjusts.

Walkthrough None

Sources - [1] - [2]

Difficulty Adjustment: Control-Loop Intuition

• Feedback mechanism: when implemented, the protocol measures how long the last set of blocks took compared to the target interval.
• Adaptive response: if blocks arrive too quickly, the target is lowered (making mining harder); if too slowly, the target is raised (making it easier).
• Stability controls: built-in bounds and damping prevent sharp swings, smoothing out sudden hash-rate changes.
• Goal: maintain a stable average block interval over time—not perfect precision, but long-term equilibrium under noisy conditions.

Overall Slide Concept This slide introduces difficulty adjustment as a control loop that keeps average block timing near a desired target. It matters here because PoW security and usability both depend on preventing block times from drifting wildly as hash rate changes. Emphasize that the network is constantly balancing responsiveness against stability.

Key Points - Difficulty retargeting keeps the expected block interval near the protocol goal. - Rising hash rate without adjustment would make blocks arrive too quickly. - Falling hash rate without adjustment would slow the system and reduce usability. - Control loop means a mechanism that observes output and adjusts inputs to stay near a target.

Walkthrough None

Sources - [1] - [4]

Difficulty Adjustment in Action

Three scenarios showing how the protocol responds to actual block times:

Too Fast ⚡

Block 1
Time: 6 min
Target: 10¹⁹

Block 2
Time: 5 min
Target: 10¹⁹

↓ Adjust

New Target
10¹⁸ (harder)

Just Right ✓

Block 1
Time: 10 min
Target: 10¹⁹

Block 2
Time: 10 min
Target: 10¹⁹

→ No Change

Target Stays
10¹⁹ (stable)

Too Slow 🐢

Block 1
Time: 15 min
Target: 10¹⁹

Block 2
Time: 18 min
Target: 10¹⁹

↑ Adjust

New Target
10²⁰ (easier)

Overall Slide Concept This slide gives students a concrete example of the retargeting loop reacting to changing conditions. It matters here because the intuition is easier to trust when students see the feedback process in action rather than only hearing the concept. Emphasize that the system is trying to steer back toward a target interval, not maximize speed.

Key Points - Difficulty should rise after blocks come too quickly and fall after they come too slowly. - Retargeting reacts to history, so it can overshoot or lag when conditions change sharply. - Stable timing is the design goal, not maximum raw throughput.

Walkthrough None

Sources - [7] - [8]

Visualizing the Target Rule

The lower the target, the smaller the fraction of hashes that meet it. This makes valid blocks rarer to find but equally cheap to verify.

• Each hash trial is independent; “work” anchors security in real resource cost.
• Lower target → smaller success window → rarer valid blocks.
  
• Honest miners’ collective hash rate determines block interval.
  
• Verification is constant-time: one hash + comparison.

Overall Slide Concept This slide gives a visual intuition for the target threshold rather than relying only on formulas. It matters here because students often understand mining better once they can picture valid hashes as a tiny region inside a much larger search space. Emphasize that smaller targets mean fewer acceptable outputs and therefore harder work.

Key Points - The target defines which hash outputs count as valid. - Lower target means valid outputs are rarer and mining is harder. - Difficulty is just another way of expressing how restrictive the target is.

Walkthrough None

Sources - [1] - [9]

Retargeting: Technical Implementation

Once the protocol decides to adjust, how does it happen in practice?

Overall Slide Concept This slide moves from intuition to the actual retargeting procedure used by the protocol. It matters here because implementation details determine whether the control loop behaves safely under adversarial or unusual conditions. Emphasize that target adjustment is a protocol rule, not an administrator decision.

Key Points - Retargeting compares observed block-production time to the protocol’s expected time window. - The updated target is computed from historical timing data according to the protocol rule. - Parameter choices constrain how abruptly difficulty can move after a shock.

Walkthrough None

Sources - [1] - [9]

Parameter Choices and Tradeoffs

• Block interval: shorter intervals reduce transaction latency but raise the risk of forks and stale blocks unless network propagation improves proportionally.
  
• Block size: larger blocks increase throughput and efficiency per block but also lengthen propagation and validation times across the network.
  
• Network engineering: relay policies, compact block protocols, and efficient peer selection help mitigate these propagation bottlenecks.
  
• Holistic security: parameters can’t be tuned in isolation—robustness emerges from the interaction of protocol design, network performance, and miner economics.

Overall Slide Concept This slide highlights that PoW parameters are design choices with trade-offs, not universal truths. It matters here because block interval, target responsiveness, and block size shape both performance and security. Emphasize that improving one axis often weakens another.

Key Points - Faster blocks can improve user-perceived responsiveness but increase fork risk. - Conservative parameters may improve stability at the cost of latency or throughput. - Security, decentralization, and performance are linked through parameter choices.

Walkthrough None

Sources - [1] - [9]

Block Propagation and Stale/Orphan Blocks

• Simultaneous discovery: in a decentralized network, two honeest miners can find valid blocks at nearly the same time.
  
• Propagation delays → temporary forks: latency means different peers track different heads of the chain until temporary forks are resolved.
  
• Resolution: all nodes follow the longest/heaviest valid chain; losing blocks become stale (a.k.a. “orphans” in older usage).
• Economic impact: stale blocks are valid but excluded from the canonical chain. Specific chain implementations must determine impact of stale blocks on miner revenue and incentives.
  
• Design trade-off: for a given network speed, shorter block intervals raise the stale rate because the difficulty is lower.

Overall Slide Concept This slide explains why even honest miners sometimes produce short-lived forks. It matters here because stale and orphan blocks are a normal consequence of distributed discovery plus propagation delay, not always an attack. Emphasize that network speed affects security by influencing how much honest work gets wasted.

Key Points - Near-simultaneous block discovery can create temporary competing branches. - Slow propagation increases the chance that honest work becomes stale or orphaned. - Higher stale rates weaken effective security because more honest work is wasted.

Walkthrough None

Sources - [7] - [8]

Implementation Notes

• Byte-exact hashing: serialization, field order, and endianness must follow the specification precisely—header hashing is bit-for-bit deterministic.
  
• Nonce space limits: once the standard nonce field is exhausted, miners must vary additional inputs such as the coinbase or timestamp to continue searching.
  
• Timing sensitivity: clock skew and timestamp windows affect both block validity and the difficulty-retarget calculation.
  
• Reproducible testing: validate implementations with known test vectors and small, deterministic toy chains before scaling up.

Overall Slide Concept This slide gathers practical implementation details that developers and operators need to treat seriously even when the math looks straightforward. It matters here because serialization, field handling, and edge cases are common sources of consensus bugs. Emphasize that implementations fail on details, not only on high-level ideas.

Key Points - Exact byte layout and field handling must match the protocol specification. - Small implementation mismatches can cause invalid blocks or consensus divergence. - Safe engineering requires careful testing around edge cases and boundary values.

Walkthrough None

Sources - [3] - [4]

Hardware Evolution and Centralization Pressures

• Hardware race: mining evolved from general-purpose CPUs → GPUs → FPGAs → purpose-built ASICs. Each step brought massive efficiency gains but higher capital barriers.
  
• Economies of scale: cheap electricity, cooling infrastructure, and manufacturing access concentrate mining power geographically and institutionally.
  
• Design countermeasures: memory-hard or bandwidth-bound algorithms can slow specialization but rarely prevent it entirely.
  
• Security perspective: centralization raises the question—who controls enough hash power to pose a credible threat to consensus?

Overall Slide Concept This slide explains how hardware specialization changes the decentralization landscape of PoW over time. It matters here because the security budget is not only about total hash rate, but also about who can realistically access efficient mining hardware. Emphasize that improvements in efficiency can come with increased concentration of power.

Key Points - Mining hardware has evolved from general-purpose CPUs to increasingly specialized devices. - Specialized hardware can raise efficiency while also increasing entry barriers. - Centralization pressure grows when only a small set of actors can compete economically.

Walkthrough None

Sources - [10] - [11]

Mining Pools, Variance, and Payouts

• Solo mining: each miner works independently — rewards arrive rarely but in large chunks.
  • High variance: payouts are unpredictable; luck dominates short-term outcomes even if long-term averages are fair.
    
• Mining pools: aggregate hash power and share rewards, reducing variance and providing steadier income.
  • Trade-offs: pools create coordination benefits but also new risks—operator control, censorship, and block withholding.
    
• Miner Goal: often seeks to find balance between stable payouts and decentralized control.

Overall Slide Concept This slide introduces mining pools as a variance-reduction response to the lottery-like nature of mining rewards. It matters here because pools reshape incentives and concentrate coordination power even when underlying mining hardware remains distributed. Emphasize that pools solve a payout problem while creating a governance and attack-surface problem.

Key Points - Individual mining rewards are highly variable, so miners join pools to smooth income. - Pools aggregate hash power and share rewards according to a payout rule. - Concentrated pool influence can raise censorship and coordination risks.

Walkthrough None

Sources - [1] - [10]

Pool Payout Model: Pay-Per-Share (PPS)

• Concept: miners are paid a fixed amount for every valid share submitted, regardless of when blocks are actually found.
  • A share is awarded when a miner in a pool solves the puzzle with a set difficulty that is easier than, but close to the target difficulty.
• Effect: eliminates payout variance for miners—steady, predictable income.
• Operator risk: the pool absorbs variance; must maintain reserves to pay miners even during unlucky streaks.
• Analogy: like a salaried job—consistent pay, but someone else manages the uncertainty.

Payout Timeline: PPS (Consistent)

Each share → immediate fixed payout (pool absorbs block luck)

Overall Slide Concept This slide explains the PPS pool payout model as an insurance-like contract for miners. It matters here because payout rules change who bears risk and therefore how pools attract participants. Emphasize that PPS offers predictable income to miners while shifting variance risk onto the pool operator.

Key Points - PPS pays miners a fixed rate per submitted share regardless of when the pool actually finds a block. - This smooths miner revenue but requires the operator to absorb variance risk. - Share means a partial proof used to measure contributed work inside the pool.

Walkthrough None

Sources - [12]

Pool Payout Model: Pay-Per-Last-N-Shares (PPLNS)

• Concept: rewards are distributed among the last N shares once a block is found.
• Effect: payouts fluctuate with block luck—miners who contributed recently share the block reward.
• Miner risk: higher variance but no operator reserve needed; payment depends on actual block discovery.
• Analogy: like a commission system—earnings track collective success in finding blocks.

Payout Timeline: PPLNS (Variable)

Payouts only at block discovery (green) — amount depends on block luck and recent share contributions

Overall Slide Concept This slide explains the PPLNS pool model as a lower-risk alternative for pool operators that gives miners more variance. It matters here because students should see that payout design is an incentive trade-off rather than a neutral bookkeeping choice. Emphasize that the model changes who carries timing risk and how strategic behavior is discouraged.

Key Points - PPLNS rewards are based on the last N shares around actual block discoveries. - Miners bear more variance than under PPS, but the pool operator bears less risk. - The payout window is designed to reduce opportunistic hopping between pools.

Walkthrough None

Sources - [12]

Security Model and Economics

• Core assumption: the majority of total hash power will honestly follow the canonical fork-choice rule.
  
• Attack economics: the cost of rewriting history grows with time and with the share of hash power the attacker must control.
  
• Security budget: defined by the rewards sustaining honest miners—block subsidy plus transaction fees, now and expected in the future.
  
• Economic pressure: if rewards fall or volatility rises, maintaining honest participation becomes harder and attacks can become economically viable.

Overall Slide Concept This slide ties PoW security to miner incentives and the overall budget available to defend the chain. It matters here because attacks become easier when honest mining is underfunded relative to the value being protected. Emphasize that protocol security depends on economics as well as cryptography and networking.

Key Points - The security budget comes from block subsidy, fees, and the value miners expect to earn. - Attack cost depends on whether an adversary can acquire or redirect enough hash power. - Incentive alignment matters because miners respond to revenue and cost, not just protocol ideals.

Walkthrough None

Sources - [1] - [2]

Attacks: Double Spend

• Attack concept: an adversary first broadcasts a payment that gets accepted into a block, then secretly mines an alternate chain excluding that payment (or a second parallel payment).
• Goal: release the longer, conflicting chain later—erasing the original transaction while keeping the goods or funds received.
  
• Network dynamics: factors like propagation speed, block relay efficiency, and miners’ transaction-selection rules influence how vulnerable a payment is to being replaced in practice
• Migitgation: merchant chooses the required number of confirmations based on transaction value, risk tolerance, and current network stability.
  • a higher confirmation depth makes the attack exponentially harder; the deeper the block, the lower the probability of a successful reorg.

Overall Slide Concept This slide explains the classic double-spend attack as a race between honest confirmations and a private conflicting branch. It matters here because probabilistic finality is one of the most important user-facing properties of PoW systems. Emphasize that confirmations lower risk but never make it literally zero.

Key Points - A double-spend tries to replace an accepted payment with a conflicting private history. - Success probability falls as the honest chain builds more confirmations over the transaction. - Merchants choose confirmation depth based on value, risk tolerance, and network conditions.

Walkthrough None

Sources - [1] - [13]

51% (Majority Hash) Attacks

• Scenario: if a single entity controls more than half of total hash power, they can outpace the honest network by privately mining a longer chain.

• Capabilities: control which valid transactions are recorded on the ledger:
  • reorder or remove recent transactions
  • censor new ones
  • perform double-spend attacks

• Limits: cannot forge digital signatures, counterfeit coins, or change consensus rules—protocol validation still applies.

• Defenses: preserve decentralization of hash power, monitor for unusual chain growth or reorgs, and raise required confirmations during network stress.

Overall Slide Concept This slide clarifies what majority hash power does and does not let an attacker do. It matters here because 51% attacks are often invoked vaguely, and students should understand the exact scope of the threat. Emphasize that majority work can reorder recent valid history, but it cannot bypass signature rules or create coins from nothing.

Key Points - Majority hash power lets an attacker outpace the honest network on competing branches. - Capabilities include censorship, reordering, and practical double-spend attacks. - Protocol validity still limits the attacker: signatures and monetary rules remain enforceable.

Walkthrough None

Sources - [1] - [14]

Censorship and Transaction Selection

• Miner discretion: miners decide which transactions to include in their blocks; policy, regulation, or external pressure can influence these choices.
  
• Economic incentives: fee-based selection maximizes revenue and throughput but can also be leveraged to exclude targeted transactions.
  
• Network factors: relay performance, anonymity, and transaction privacy influence how likely a transaction is to reach miners’ mempools.
  
• Design responses: fee mechanisms, privacy layers, and decentralized relay networks aim to reduce the risk of arbitrary or policy-driven censorship.

Overall Slide Concept This slide explains censorship as a transaction-selection problem rather than only a chain-rewrite problem. It matters here because miners influence user experience long before a transaction is finalized. Emphasize that fee policy, regulation, and network visibility all affect which transactions get mined promptly or at all.

Key Points - Miners exercise discretion over which transactions enter blocks. - Fee incentives often govern selection, but external pressure can also shape inclusion. - Relay quality and privacy tools affect whether a transaction even reaches miners fairly.

Walkthrough None

Sources - [8] - [15]

Selfish Mining: Strategic Withholding

• Concept: a coalition of miners withholds newly found blocks, maintaining a private chain to gain an advantage.
  
• Tactic: by releasing blocks strategically, they can invalidate honest miners’ work and control which branch becomes canonical.
  
• Key insight: even with less than 50% hash power, a well-connected coalition can earn more than its fair share of rewards.
  • Typically considered economically viable at 33% of hash power.
• Consequences: higher orphan (stale) rates, pressure on independent miners to join the selfish group, and increased centralization risk.
  
• Countermeasures: improve block relay efficiency, refine tie-breaking rules, and design incentives that discourage block withholding, bigger networks

Overall Slide Concept This slide introduces selfish mining as an incentive attack that exploits timing and release strategy rather than direct majority control. It matters here because students should see that harmful behavior can emerge below the 51% threshold under the right network conditions. Emphasize that the danger is not only lost blocks, but pressure toward further centralization.

Key Points - Selfish miners withhold blocks to build a private lead and release it strategically. - Under favorable connectivity conditions, sub-majority coalitions can earn more than their fair share. - Higher stale rates and strategic advantage can pressure other miners to join the selfish coalition.

Walkthrough None

Sources - [16] - [7]

Eclipse and Network-Level Attacks

• Concept: an attacker isolates a target node by monopolizing all its network connections, both inbound and outbound.
  
• Effect: the victim sees only attacker-controlled peers, accepting a false view of the blockchain that enables censorship or double-spends.
  
• Defenses: use diverse peer selection, limit connections per network prefix (/16), combine DNS seeds with manual node lists, and apply eviction rules to rotate peers.
  
• Operational hygiene: regular monitoring, trusted bootstraps, and network diversity are as critical as on-chain consensus rules.

The Trusted Bootstrap Paradox: A fully decentralized protocol still requires a bootstrapping step. DNS seeds and hardcoded peer lists are centralized dependencies—if compromised, an attacker can eclipse your node before consensus rules even matter. This is a critical but often overlooked attack surface.

Overall Slide Concept This slide shifts attention from on-chain rules to the network layer that supplies each node’s view of the chain. It matters here because a node that only hears from an attacker can make bad decisions even if consensus rules are locally followed. Emphasize that peer diversity and operational hygiene are part of consensus security.

Key Points - Eclipse attacks isolate a target node by controlling its peer connections. - The victim may accept a distorted view of the chain or experience selective censorship. - Connection diversity, peer rotation, and trusted bootstrap paths reduce the attack surface.

Walkthrough None

Sources - [17] - [15]

Timestamp Manipulation and Time-Warp Attacks

• Concept: miners can slightly adjust block timestamps within allowed protocol limits to influence how the network measures time.
  
• Exploit: if many miners coordinate over several blocks, they can shift timestamps enough to make the protocol believe blocks are arriving more slowly—temporarily reducing difficulty (a “time-warp”).
  
• Impact: could allow coordinated miners to mine more quickly than intended by the protocol design.
• Mitigations: rules such as median-time-past and narrow timestamp windows limit manipulation but cannot eliminate it completely.
  
• Design trade-off: protocols must balance strict timing enforcement—resisting manipulation—against tolerance for clock drift and honest network delays.

Overall Slide Concept This slide explains how timestamp flexibility can be abused to distort the difficulty control loop. It matters here because it links a seemingly minor header field to large-scale security and timing consequences. Emphasize that control loops can be manipulated if the inputs they trust are weakly constrained.

Key Points - Miner-set timestamps influence how the protocol perceives elapsed time. - Manipulated timestamps can skew retargeting and distort expected work over time. - Time-warp attacks target the control loop rather than directly forging consensus rules.

Walkthrough None

Sources - [1] - [9]

Block Withholding in Poolsv

• Attack pattern: a rogue miner participates in a pool, submitting valid shares but withholding full blocks, reducing the pool’s total rewards.
  

• Motivations: sabotage rival pools, manipulate reputation, or create pressure that drives miners to switch affiliations.
  

• Detection challenge: withholding looks statistically similar to bad luck—detectable only over time and with enough data.
  

• Countermeasures: continuous performance monitoring, reputation systems, and contractual or payout designs that align incentives.
  

• Key insight: mining security depends not only on cryptography, but also on the social and economic structures surrounding it.

• Question: How does this impact PPS vs. PPLNS pools?

Overall Slide Concept This slide distinguishes block withholding from selfish mining by focusing on sabotage inside pooled mining rather than chain-wide reordering. It matters here because pools introduce internal trust problems even when the public protocol is unchanged. Emphasize that reward-sharing arrangements can create new opportunities for hidden abuse.

Key Points - In block withholding, a participant withholds found blocks from the pool while still submitting partial shares. - The attacker harms pool revenue or competitiveness without necessarily trying to reorganize the public chain. - Pools create internal agency problems between operators and participants.

Walkthrough None

Sources - [12] - [18]

Activity: A Mining Race

Let’s simulate proof of work by flipping five coins at once to see if we can achieve the target sequence.

Use this mining activity to race others in your pool to solve the puzzle.

/assets/labs/POW_mining_micro/

Then try the second mode where difficulty updates.

Overall Slide Concept This activity turns mining from an abstract probability story into an interactive race students can reason about. It matters here because forks, stale blocks, and confirmation depth become easier to remember once students act them out. Emphasize that the goal is to observe the protocol’s incentives and timing behavior, not to compute exact formulas.

Key Points - Independent trial races help explain why PoW block discovery is probabilistic. - Near-simultaneous wins create temporary forks that later resolve. - Additional confirmations reduce the practical risk of reversal.

Walkthrough None

Sources - [5] - [6]

Energy, Externalities, and Design Responses

• Economic framing: energy use represents the cost side of the Proof-of-Work security budget—raising the price of attack by anchoring security in physical resources.
  
• Geographic dynamics: access to cheap or surplus electricity shapes miner location, while seasonal or regional grid mixes determine environmental impact.
  
• Design responses: improve hardware and protocol efficiency, adjust block parameters, or integrate alternative consensus layers such as Proof-of-Stake or hybrid finality gadgets.
  
• Holistic evaluation: assess security, decentralization, and sustainability together—each influences the long-term legitimacy of the system.

Overall Slide Concept This slide places energy use inside the course’s security-budget framing instead of treating it only as a political talking point. It matters here because PoW security is intentionally anchored in physical resource expenditure. Emphasize that security, decentralization, and environmental impact have to be evaluated together rather than in isolation.

Key Points - Energy expenditure is the cost side of the PoW security budget. - Geography and power markets influence who can mine profitably and with what externalities. - Designers can respond with efficiency improvements, parameter changes, or alternative consensus layers.

Walkthrough None

Sources - [5] - [6]

Review and Reflection

• Explain the PoW validity rule and why verification is cheap.

• State how difficulty targets the average block interval and why retargeting is needed.

• Describe why confirmations lower double‑spend risk but never reach zero.

• Name two attack classes and one mitigation for each.

Overall Slide Concept This closing slide consolidates the lesson into the main explanations and assumptions students should be able to state back clearly. It matters here because PoW only makes sense when students can connect the validity rule, retargeting, probabilistic finality, and the attack surface in one mental model. Emphasize explanation and justification rather than rote recall.

Key Points - Students should explain why PoW verification is cheap even though finding a valid block is expensive. - They should connect difficulty retargeting to stable average block intervals. - They should relate confirmations and attacks back to assumptions about hash power, timing, and incentives.

Walkthrough None

Sources - [5] - [6]

References

[1]

S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System.” Satoshi Nakamoto Institute, Oct. 31, 2008. Accessed: Sep. 12, 2025. [Online]. Available: https://cdn.nakamotoinstitute.org/docs/bitcoin.pdf

[2]

S. Bano et al., “Consensus in the Age of Blockchains.” 2017. Available: https://arxiv.org/abs/1711.03936

[3]

A. M. Antonopoulos, Mastering Bitcoin: Programming the open blockchain, Second edition. Sebastopol, CA: O’Reilly, 2017.

[4]

Bitcoin.org Developers, “Block Chain (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/block_chain.html

[5]

J. Katz and Y. Lindell, Introduction to Modern Cryptography, 3rd ed. Chapman and Hall/CRC, 2020. doi: 10.1201/9781351133036.

[6]

A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, “Handbook of Applied Cryptography.” CRC Press, Aug. 07, 2011. Accessed: Oct. 23, 2025. [Online]. Available: https://cacr.uwaterloo.ca/hac/

[7]

C. Decker and R. Wattenhofer, “Information propagation in the Bitcoin network,” in IEEE P2P 2013 Proceedings, 2013, pp. 1–10. doi: 10.1109/P2P.2013.6688704.

[8]

Bitcoin.org Developers, “P2P Network (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/p2p_network.html

[9]

Bitcoin.org Developers, “Mining (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/mining.html

[10]

J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies,” in 2015 IEEE Symposium on Security and Privacy, 2015, pp. 104–121. doi: 10.1109/SP.2015.14.

[11]

I. Neumueller, “Bitcoin electricity consumption: An improved assessment - News & insight.” Accessed: Oct. 28, 2025. [Online]. Available: https://www.jbs.cam.ac.uk/2023/bitcoin-electricity-consumption/

[12]

M. Rosenfeld, “Analysis of bitcoin pooled mining reward systems,” CoRR, Dec. 2011, Accessed: Mar. 28, 2026. [Online]. Available: https://arxiv.org/abs/1112.4980

[13]

J. Garay, A. Kiayias, and N. Leonardos, “The Bitcoin Backbone Protocol: Analysis and Applications.” Accessed: Oct. 21, 2025. [Online]. Available: https://eprint.iacr.org/2014/765

[14]

Bloomberg News, “Zcash Mining Pool Concentration Shows 51% Attack Risks.” 2023. Available: https://www.bloomberg.com/news/newsletters/2023-09-26/zcash-blockchain-viabtc-mining-pool-concentration-shows-51-attack-risks

[15]

M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking Bitcoin: Routing Attacks on Cryptocurrencies,” in 2017 IEEE Symposium on Security and Privacy (SP), May 2017, pp. 375–392. doi: 10.1109/SP.2017.29.

[16]

I. Eyal and E. G. Sirer, “Majority is Not Enough: Bitcoin Mining is Vulnerable,” in Financial Cryptography and Data Security, in LNCS, vol. 8437. 2014, pp. 436–454. doi: 10.1007/978-3-662-45472-5_28.

[17]

E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network.” Accessed: Oct. 21, 2025. [Online]. Available: https://eprint.iacr.org/2015/263

[18]

M. Ren, H. Guo, and Z. Wang, “Mitigation of block withholding attack based on zero-determinant strategy,” PeerJ Computer Science, 2022, Accessed: Mar. 28, 2026. [Online]. Available: https://pubmed.ncbi.nlm.nih.gov/36092016/