Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // bitcoin

Mining & Consensus

Proof-of-work, difficulty adjustment, and mining incentives for builders.

intermediate5 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Explain proof-of-work and difficulty adjustment
  • Distinguish consensus rules from miner preference
  • Connect mining incentives to confirmation UX builders ship

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • bookMastering Bitcoin

    Ch. 12: Mining

Reflection prompts

  1. Explain Mining & Consensus to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Mining & Consensus?
  3. Which BIP, book chapter, or Core doc is authoritative here, and what did you verify?

Lab // Regtest PoW loop

Complete Steps 2–3. On regtest, mine blocks with generatetoaddress, compare getblockchaininfo before/after (height, difficulty), and write one sentence on how this differs from mainnet competition.

evidence required

  • ·Before/after getblockchaininfo (or getblock) showing height change
  • ·generatetoaddress command output
  • ·One sentence contrasting regtest mining with mainnet PoW competition
  • ·Link to Mastering Bitcoin Ch. 12 section you used
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Mining is the competitive process of finding a proof-of-work that makes a block header valid under current difficulty. Consensus rules define what blocks and transactions are valid; miners choose among valid templates.

Complete Step 1 // Required reading in the study plan above, then continue here. This closes Protocol Depth. Soft-fork activation was the previous lesson — here focus on PoW and enforcement.

Step 2 — Core idea: PoW, difficulty, who enforces

You may never run an ASIC, but every confirmation UX, reorg assumption, and fee-market discussion depends on mining incentives and consensus enforcement by full nodes.

Analogy: Difficulty is a treadmill that speeds up or slows down so bags of work arrive roughly every 10 minutes. Blocks too fast → treadmill speeds up; too slow → it eases.

Loading diagram…

Miners search for a header hash below the target; winners earn rewards.

Approximately every 2016 blocks, difficulty adjusts based on recent timestamps to keep average block time near 10 minutes.

Miners propose blocks; full nodes verify. Economic users running nodes ultimately decide which rules their software accepts. Soft forks (previous lesson) tighten those rules over time — libraries and descriptors must track whether they assume post-fork features (SegWit, Taproot).

Nodes enforce rules

Hashrate does not rewrite consensus by itself. Invalid blocks are rejected by validating peers even if a miner produced them.

Done when: You can separate “miner preference among valid templates” from “consensus validity.”

Step 3 — Try it: mine on regtest (lab)

bitcoin-cli -regtest getblockchaininfo
ADDR=$(bitcoin-cli -regtest getnewaddress)
bitcoin-cli -regtest generatetoaddress 1 "$ADDR"
bitcoin-cli -regtest getblockchaininfo

Note height (and difficulty if present). One sentence: how generatetoaddress differs from competing for mainnet PoW.

Common mistakes

  • Believing miners can arbitrarily change supply rules without node acceptance
  • Ignoring that empty blocks / fee market dynamics affect confirmation times
  • Testing only generatetoaddress on regtest and assuming mainnet propagation matches

Done when: Lab evidence (before/after chain info + generate output + contrast sentence + source) is complete. Complete the chapter quiz when prompted.

Next lesson

Bitcoin Libraries (Development) — keys, addresses, and transaction construction in code.

further reading

  • bipBIP-9 Version bits
  • articleBitcoin Optech: Soft fork activation

review // club

Chapter review picks

Practice on real Bitcoin OSS changes tied to this chapter. Read the diff, use the checklist, and optionally paste your review comment URL in your lab notes.

  • Bitcoin Core soft-fork related PRs

    Review a Core PR touching soft-fork activation or consensus rules and note rollout implications.

    pr review
    rolloutversion bitstests
    55 min·advancedopen on GitHub
  • BIP-152 compact block relay

    Read BIP-152 and explain how compact blocks reduce relay bandwidth during block propagation.

    spec review
    bandwidthmempool reconstruction
    45 min·advancedopen on GitHub
  • BIP-157/158 light client filters

    Compare BIP-157 client filters with naive address-query light clients for privacy tradeoffs.

    spec review
    client privacyfilter false positives
    50 min·advancedopen on GitHub
review checklist
  1. Does the change solve the stated problem?
  2. Are edge cases and rollout behavior covered?
  3. Are tests or test vectors included?
  4. Is the diff minimal and clearly explained?

More repos and GFIs on /discover and /issues.

build // next

Apply this chapter in a project

You have the concepts — ship something small to prove it. These Pull projects connect directly to what you just studied.

  • project // compact-block-lab

    ./spec./submit
  • project // p2p-message-sniffer

    ./spec./submit

discussion

Discussion

prevSoft Forks & ActivationnextBitcoin Libraries

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.