Book: Bitcoin for the Befuddled
Author: Conrad Barski and Chris Wilmer
Difficulty: Intermediate
The Big Idea
Bitcoin literacy means separating authorization, transaction validity, settlement confidence, custody, and market value. A valid signature does not establish a fair price. A growing blockchain does not make a wallet recoverable. Understanding those boundaries is more useful than memorizing enthusiastic claims about the technology.
Use the book alongside this independent workbook. Read each assigned chapter first, then complete the original calculations, evidence checks, and practice questions below. The workbook covers all ten numbered chapters, the separate altcoin comic, and both programming appendices; it does not reproduce the book’s stories, illustrations, or code.
The supplied title page verifies the authors. The publisher lists a November 2014 release, while the supplied copyright page says 2015. No additional edition is assumed. Reading references use chapter titles, not page numbers: EPUB pagination varies by reader and font size. Beginner readers can follow the conceptual route; the cryptography and programming modules take more effort.
Contents and Reading Map
- Quick study guide
- Read older instructions critically
- Seven-session study plan
- 1. What Is Bitcoin?
- 2. Bitcoin Basics
- 3. Storing Your Bitcoins
- 4. Buying Bitcoins
- 5. Lost at Sea
- 6. Why Bitcoin Is a Big Deal
- 7. The Cryptography Behind Bitcoin
- 8. Bitcoin Mining
- 8½. The Strange World of Altcoins
- 9. Different Types of Bitcoin Wallets
- 10. Bitcoin 2030
- Appendix A: Hello Money!
- Appendix B: BitcoinJ
- Original offline programming lab
- Four reusable worksheets
- Capstone and scoring rubric
- Verification references
Quick Study Guide
| Concept | Useful mental model | Common mistake |
|---|---|---|
| Bitcoin versus bitcoin | Bitcoin names the system; bitcoin/BTC denotes its monetary unit. | Treating network usefulness as a valuation model. |
| Satoshi | 1 BTC = 100,000,000 satoshis. | Using floating-point money calculations without checking rounding. |
| Private key / public key / address | A secret authorizes; a public key helps verification; an address encodes a payment destination associated with spending conditions. | Calling all three interchangeable. |
| Wallet | Manages keys, scripts, transaction construction and/or a view of funds. | Assuming coins are files stored inside the app. |
| UTXO | An unspent transaction output that can be consumed in a later transaction. | Assuming the protocol is just a bank-account balance ledger. |
| Transaction fee | Inputs minus outputs; estimated fees depend on transaction size and chosen fee rate. | Charging a fixed percentage of the amount sent. |
| Proof of work | Costly block production plus independently enforced validity rules. | Thinking hash power permits arbitrary theft or inflation. |
| Confirmation | Inclusion and subsequent depth in the selected valid chain. | Treating a broadcast notice as final settlement. |
| Self-custody | You control signing authority and must solve recovery. | Assuming removing a custodian removes every risk. |
| Market value | An uncertain outcome of demand, supply, liquidity and expectations. | Dividing a large market by coin supply and calling it a forecast. |
Core arithmetic: fee = input sats − output sats; change = inputs − payment − fee. Mining operating margin = revenue − electricity − pool charges − other operating costs. A valuation scenario is assumed monetary value ÷ assumed coin count; both inputs need justification.
Read Older Instructions Critically
The conceptual chapters remain useful reading, but historical screenshots and code are not current operating instructions. These are our corrections and present-day qualifications, not silent rewrites of the authors’ rules.
| Book-era topic | How to use it in this workbook |
|---|---|
| “Instant,” cheap, private payments | Separate broadcast, inclusion and confirmation depth. Fees vary, and public transaction history can expose relationships; pseudonymity is not anonymity. |
| Addresses beginning with 1 and classic ECDSA | These illustrate older formats. Modern Bitcoin also has other address/script types, including Taproot using Schnorr signatures. |
| Paper wallets, brainwallets and online generators | Study the threat models; do not generate or fund wallets from old examples. Never use a printed key, guessed phrase, or copied seed. |
| Wallet and exchange walkthroughs | Treat names, buttons and authentication screenshots as historical. No provider is endorsed or checked here for suitability. |
| Longest-chain shorthand | Choose among valid chains by cumulative proof of work, not peer count or simply the largest block count. |
| Subsidy sequence | The printed 6.725 BTC value is a typo: 12.5 halves to 6.25. Subsidy and fees are distinct; issuance follows block-height rules. |
| Mining economics and future prices | Old hardware figures and adoption scenarios are not current quotations, return evidence, or forecasts. |
| Programming dependencies and credentials | Do not run the old main-network examples. Use the original offline lab below to study event handling without exposing a wallet. |
Seven-Session Study Plan
Use one session per sitting or spread it across several days. Completion demonstrates understanding, not investment readiness or profitability. Allow roughly 45–90 minutes per conceptual session, plus your reading time; the technical sessions may take longer.
| Session | Read in the book | Produce before moving on |
|---|---|---|
| 1 – Foundations | Chapters 1–2 | A five-part system explanation and a correct transaction/change calculation. |
| 2 – Custody | Chapters 3 and 9 | A fictional recovery plan separating signing, validation and information leakage. |
| 3 – Exchange and consensus | Chapters 4–5 | An all-in cost comparison and an explanation of why signatures do not prevent double spending alone. |
| 4 – Claims and scenarios | Chapter 6, altcoin comic and Chapter 10 | A claim ledger with falsifiable assumptions and two contrasting adoption scenarios. |
| 5 – Cryptography | Chapter 7 | A hash/signature comparison and an explanation of what toy math cannot secure. |
| 6 – Mining | Chapter 8 | A cost model with a downside sensitivity check. |
| 7 – Developer thinking | Appendices A–B | Offline lab observations, four completed worksheets and the capstone. |
1. What Is Bitcoin?
Read: Chapter 1: What Is Bitcoin?. Learning objective: Explain the difference between the network, its monetary unit and the institutions around it.
Start by asking what problem a shared ledger solves. A digital message can be copied freely; a payment system must decide whether a spend is authorized and whether the same funds have already been spent. Bitcoin combines transaction rules, signatures, peer-to-peer communication and proof of work to coordinate that decision.
Decentralization changes where trust is placed. A person may still depend on wallet software, an internet provider, hardware, an exchange or a data server. List each dependency rather than assuming “no central issuer” means “no intermediaries anywhere.”
Original worked example: One payment, several claims
| Step | Calculation or observation | Meaning |
|---|---|---|
| Authorization | A fictional sender signs a transaction. | The required spending condition may be satisfied. |
| Delivery | The recipient sees an unconfirmed transaction. | The network has seen a proposal; it is not a confirmation. |
| Custody | The recipient uses a hosted balance. | A provider still controls withdrawal access. |
Keep this: Evaluate the specific layer before accepting a broad claim.
The opening emphasizes digital scarcity and independence from central issuers.
Scarcity does not guarantee demand, stable purchasing power, anonymity or legal immunity.
Practice and check your reasoning
List two risks that remain even if the protocol works correctly.
Show explained answer
Loss of recovery information and theft through a compromised signing environment are two examples. A third is a market-price decline: protocol correctness does not stabilize purchasing power.
Does a public ledger make every user’s legal identity public?
Show explained answer
Not automatically. The ledger exposes transaction relationships; identity can be linked through exchanges, reuse and other data. It is neither an identity directory nor a guarantee of anonymity.
Explain Bitcoin without making a price prediction.
Show explained answer
Describe a peer-to-peer monetary system in which participants validate spending rules and coordinate transaction history using proof of work. No claim about future demand is needed.
2. Bitcoin Basics
Read: Chapter 2: Bitcoin Basics. Learning objective: Calculate units, fees and change, and distinguish validation from confirmation.
A transaction spends earlier outputs and creates new ones. An input identifies an earlier output; the spending data must meet its conditions. Any remainder needs an explicit change output, otherwise the difference contributes to the fee.
Wallets present convenient balances, but the protocol’s transaction structure matters when checking fees and privacy. Miners propose blocks, while full nodes independently reject blocks that violate consensus rules. More work does not make an invalid transaction valid.
Original worked example: UTXO arithmetic in satoshis
| Step | Calculation or observation | Meaning |
|---|---|---|
| Inputs | 90,000 + 70,000 = 160,000 sats | Both fictional outputs are consumed. |
| Outputs | Payment 120,000; change 37,500 | Total outputs = 157,500 sats. |
| Fee | 160,000 − 157,500 = 2,500 sats | At a fictional 250 vbytes, this is 10 sat/vB. |
Keep this: Track all outputs, including change, before calculating the fee.
The chapter introduces a roughly ten-minute block interval and mining rewards.
Ten minutes is an average, not an appointment. Reward includes subsidy plus fees; confirmation depth is probabilistic security, not a clock-based warranty.
Practice and check your reasoning
Convert 0.0032 BTC to satoshis.
Show explained answer
0.0032 × 100,000,000 = 320,000 sats. Retaining integer satoshis avoids representing fractional money with binary floating-point arithmetic.
An input is 200,000 sats, a payment is 150,000 and the intended fee is 3,000. What is the change?
Show explained answer
47,000 sats: 200,000 − 150,000 − 3,000. A wallet must explicitly construct that output if it is to return the remainder.
Can an invalid block win by having more work?
Show explained answer
A correctly validating node rejects it first. Cumulative work selects among valid competing chains; it does not override signature, issuance or other consensus rules.
3. Storing Your Bitcoins Safely, Securely, and Conveniently
Read: Chapter 3: Storing Your Bitcoins Safely, Securely, and Conveniently. Learning objective: Build a threat model that separates accidents, theft and usability.
Custody design starts with failure scenarios: a device breaks, a backup is destroyed, a malicious app substitutes a destination, or a custodian freezes withdrawals. A control is useful when you can name which failure it addresses and which failures remain.
Hot and cold describe exposure and signing arrangements, not a promise that funds are invulnerable. Hardware signing can reduce exposure of secrets to a general-purpose computer, but requires trustworthy transaction verification, backups and recovery procedures. Never put a real seed, private key or backup photograph into these worksheets.
Original worked example: Recovery without secrets
| Step | Calculation or observation | Meaning |
|---|---|---|
| Accident | A fictional signing device is destroyed. | An independent recovery path is necessary. |
| Theft | Someone finds one backup location. | A second copy alone does not prevent theft from the first. |
| Usability | The owner cannot interpret the recovery notes. | Documentation must identify formats and procedures without casually exposing secrets. |
Keep this: A backup plan must address both availability and unauthorized access.
The chapter compares paper storage, secret sharing, multisignature and brainwallets.
These are different mechanisms. Secret sharing reconstructs a secret; multisignature requires multiple authorizations. Self-chosen brainwallet phrases and historical web generators are not safe practice exercises.
Practice and check your reasoning
Why is emailing yourself a seed a poor recovery plan?
Show explained answer
It creates additional copies in mail accounts, servers, backups and potentially compromised devices. Convenience increases the set of places from which an attacker could recover signing authority.
Is a 2-of-3 signing arrangement the same as splitting one key into three fragments?
Show explained answer
No. A 2-of-3 authorization policy requires signatures from two keys. A threshold sharing scheme reconstructs a secret from shares; its use and failure modes differ.
What belongs in a public workbook recovery plan?
Show explained answer
A fictional inventory of device roles, backup format, required configuration, responsibilities and review procedures. Actual secrets, sensitive locations and access credentials do not belong in it.
4. Buying Bitcoins
Read: Chapter 4: Buying Bitcoins. Learning objective: Compare total costs and counterparty risks without treating the chapter as an instruction to buy.
The educational value here is market plumbing: quotes, spreads, order types, authentication, transfer timing and counterparty exposure. The book’s provider interfaces are historical, so study the questions they raise rather than following screenshots.
A market order prioritizes execution subject to available liquidity; it does not fix the final price. A limit order sets a price constraint, but can execute immediately against existing orders and may be charged as a taker. Exchange rules and fees must be checked at the time of any real decision.
Original worked example: All-in hypothetical acquisition cost
| Step | Calculation or observation | Meaning |
|---|---|---|
| Venue A | 10,000 quote + 80 trading fee + 20 withdrawal = 10,100 | Compare the same fictional quantity delivered to the same endpoint. |
| Venue B | 10,030 quote + 20 trading fee + 90 withdrawal = 10,140 | The apparently smaller trading fee is not the smallest total cost. |
| Other risks | Withdrawal delay, account restrictions and custody exposure | These are not captured by a single price figure. |
Keep this: Compare equivalent outcomes, not advertising headlines.
The reading discusses authentication and price differences between venues.
Two-factor authentication is a control, not insurance. A quoted arbitrage spread can disappear after fees, slippage, delays and transfer restrictions.
Practice and check your reasoning
A limit buy is priced above an available sell quote. Must it wait in the order book?
Show explained answer
No. It may match immediately at an acceptable price. “Limit” describes a constraint, not guaranteed maker status.
A venue is 0.7% cheaper but costs 1% more to complete the same transfer. Is the apparent spread a profit?
Show explained answer
No. Even before price movement and counterparty risk, the extra cost exceeds the quote advantage by 0.3 percentage points.
What can an escrow service fail to solve?
Show explained answer
It cannot automatically establish an asset’s legitimacy, eliminate collusion or make every payment method irreversible. Its release conditions, control and dispute process matter.
5. Lost at Sea: A Cryptographic Adventure
Read: Chapter 5: Lost at Sea: A Cryptographic Adventure. Learning objective: Use the comic as a model of coordination, then identify its limits.
Read the comic in the book rather than replacing it with a retelling. Focus on three problems: recognizing an authorized message, detecting conflicting spends and selecting a shared history when messages arrive in different orders.
A signature addresses authorization. It does not by itself tell two isolated recipients which of two conflicting signed transactions should prevail. Proof of work and validation rules supply additional coordination. Counting identities alone is weak when one actor can cheaply manufacture many apparent participants.
Original worked example: Two recipients, one output
| Step | Calculation or observation | Meaning |
|---|---|---|
| Proposal A | One fictional output is signed toward recipient A. | A signature may be valid. |
| Proposal B | The same output is also signed toward recipient B. | Another signature may also verify. |
| Shared history | Only one spend can survive in a valid selected history. | Valid signatures alone do not settle the conflict. |
Keep this: Authorization and uniqueness are separate checks.
The comic uses physical messengers and puzzle solving to illustrate network coordination.
These are teaching analogies. A signed statement is not necessarily a Bitcoin transaction, and a puzzle story is not the complete consensus protocol.
Practice and check your reasoning
Why does “100 peers agree” not prove that 100 independent people agree?
Show explained answer
A single actor may operate many peers. This is the identity-multiplication problem often called a Sybil attack; peer counts are not proof of independent economic weight.
Does a valid signature prove someone’s legal identity?
Show explained answer
It demonstrates satisfaction of a cryptographic verification condition. Linking a key to a particular legal person requires separate evidence.
What should be added to the comic model when evaluating real Bitcoin?
Show explained answer
Explicit transaction and block validity rules, cumulative work, network delays and reorganizations. An analogy helps intuition but cannot replace those checks.
6. Why Bitcoin Is a Big Deal
Read: Chapter 6: Why Bitcoin Is a Big Deal. Learning objective: Separate technical usefulness, adoption arguments and valuation assumptions.
The historical discussion contrasts systems that rely on a central operator with Bitcoin’s different coordination model. Evaluate each claimed advantage by asking what is measured, over what period, and compared with which alternative.
A network effect can encourage adoption without guaranteeing permanent dominance. An issuance limit does not determine demand. Claims about portability, durability or scarcity need a distinction between protocol properties, user experience and purchasing power. Avoid treating a successful technical design as proof of a good investment at any price.
Original worked example: A valuation scenario, not a target
| Step | Calculation or observation | Meaning |
|---|---|---|
| Assumption | A hypothetical market is worth $800 billion. | The boundary and measurement of that market need evidence. |
| Capture | Assume 0.5% is represented: $4 billion. | Adoption is assumed, not observed. |
| Division | $4 billion ÷ 20 million assumed coins = $200 per coin | Changing the capture assumption changes the answer; this is not a forecast. |
Keep this: A precise quotient can rest on uncertain premises.
The reading develops large potential-market arguments.
Check the arithmetic as well as the economic model. For example, $1.2 trillion × 1% ÷ 21 million is approximately $571, not a five- or six-figure valuation.
Practice and check your reasoning
If the capture assumption doubles while the denominator stays fixed, what happens to the scenario price?
Show explained answer
It doubles algebraically. This says nothing about whether doubled adoption is plausible or whether the model captures actual price formation.
Does a fixed issuance rule imply stable purchasing power?
Show explained answer
No. Demand, liquidity and expectations can change even with a predictable issuance schedule.
Turn “network effects guarantee success” into a research question.
Show explained answer
Ask which measurable adoption advantages persist, what switching costs users face and what observations would show those advantages weakening. A guarantee becomes a falsifiable hypothesis.
7. The Cryptography Behind Bitcoin
Read: Chapter 7: The Cryptography Behind Bitcoin. Learning objective: Distinguish hashing, signatures and encryption; recognize where toy math stops.
A hash provides a compact fingerprint of data. A signature allows verification of authorization under a public-key scheme. Encryption protects confidentiality. Bitcoin transaction data is not made confidential merely because cryptography is involved.
The chapter’s arithmetic examples help explain one-way operations and elliptic-curve ideas. They are not implementations to secure funds. Bitcoin’s classic ECDSA relies on elliptic-curve discrete-logarithm assumptions, not RSA integer factoring; modern Taproot also uses Schnorr signatures. Do not implement signing from these examples.
Original worked example: A file check with a missing trust anchor
| Step | Calculation or observation | Meaning |
|---|---|---|
| Download | A fictional file and its hash arrive from the same compromised server. | They can agree even if both are malicious. |
| Verification | A trusted independent reference supplies the expected digest. | Matching now tests the intended file identity under that trust assumption. |
| Boundary | The expected file could still contain a software flaw. | A matching hash is not a malware audit. |
Keep this: A fingerprint is useful only in relation to a trusted expectation.
The technical section uses small-number examples and simplified pseudocode.
Correct the printed factorization: 98 = 2 × 7 × 7. The curve equation uses x cubed, not x squared. A scalar-multiplication loop that starts at A and adds A k times yields (k+1)A, not kA.
Practice and check your reasoning
Is “signing means encrypting with the private key” a reliable general definition?
Show explained answer
No. Signature schemes have their own algorithms and security requirements; the phrase is misleading outside limited textbook analogies and does not define ECDSA or Schnorr.
Can an attacker test guessed passwords against a leaked password hash?
Show explained answer
Yes, depending on the system. Hashing does not make weak guesses disappear; salts and suitable password-derivation functions help address different parts of that threat.
Why must a toy curve never hold real value?
Show explained answer
Tiny parameter spaces are easy to exhaust, and classroom code lacks production validation and side-channel protections. Correct-looking arithmetic is not evidence of a secure signing implementation.
8. Bitcoin Mining
Read: Chapter 8: Bitcoin Mining. Learning objective: Explain target-based proof of work and model mining costs without promises.
Mining repeatedly tests candidate block headers for a hash meeting the network target. A lower target makes success less likely per trial. Difficulty compares a reference target with the current target; reversing that ratio reverses its meaning.
A pool changes payout variability and introduces pool terms and counterparty exposure. It does not turn an uneconomic setup into an economic one. Full nodes still enforce validity. A majority of hash power can threaten ordering and settlement, but cannot simply authorize spending another person’s outputs without satisfying their spending conditions.
Original worked example: Fictional daily mining cash flow
| Step | Calculation or observation | Meaning |
|---|---|---|
| Electricity | 3 kW × 24 hours × $0.08/kWh = $5.76 | Assumes continuous operation and a flat tariff. |
| Operating margin | $7.50 revenue − $0.15 pool charge − $5.76 = $1.59 | Excludes hardware, cooling, repairs and depreciation. |
| Downside | Revenue falls 20% to $6.00; 2% pool charge is $0.12; margin = $0.12 | A modest input change nearly removes the operating margin. |
Keep this: A positive operating margin is not the same as a profitable investment.
The chapter describes rewards, difficulty adjustment and equipment economics.
Treat historical performance and equipment quotations as historical. Pool shares are accounting evidence of work submitted, not each a network block or guaranteed profit.
Practice and check your reasoning
If the current target halves, what happens to reference-target/current-target difficulty?
Show explained answer
It doubles. A hash has a smaller acceptable range, so expected work rises.
Can a miner claim any subsidy amount if enough peers relay the block?
Show explained answer
No. Validating nodes enforce the permitted issuance and fee limits. Relaying an invalid block does not make its coinbase valid.
Why is $1.59 per day not a payback calculation?
Show explained answer
It omits purchase cost and several expenses, and assumes revenue, uptime and electricity remain constant. Payback needs time-dependent net cash flows and uncertainty, not one-day division alone.
8½. The Strange World of Altcoins
Read: The Strange World of Altcoins comic, between Chapters 8 and 9. Learning objective: Compare a protocol’s rules with its adoption and economic security.
Read the standalone comic as a prompt to examine imitation and competition. Copying source code can reproduce some technical rules, but it does not copy users, infrastructure, liquidity, maintenance or a history of credible operation.
A rule limiting the supply of one asset does not limit the number of competing assets. Conversely, the existence of competitors does not by itself demonstrate that users will switch. The comic’s numerical predictions about future markets should be treated as the authors’ speculation.
Original worked example: Two fictional networks
| Step | Calculation or observation | Meaning |
|---|---|---|
| Rules | Both advertise the same issuance cap. | This checks one design feature. |
| Operations | One has sparse independent validation and fragile maintenance. | The headline rule is not the entire security model. |
| Market | One quoted trade implies a large fully diluted valuation. | A quotation does not establish deep executable liquidity. |
Keep this: Compare incentives, control and actual use before comparing slogans.
The comic makes playful claims about the number and future size of competing coins.
Those claims are not verified market statistics or recommendations. The lesson is to define comparable evidence, not to repeat a prediction as fact.
Practice and check your reasoning
Why can code be copied more easily than network effects?
Show explained answer
Code is an information artifact; users, integrations, liquidity and operational trust require separate adoption and coordination.
Does low nominal coin price mean an asset is cheap?
Show explained answer
No. Unit counts and issuance differ. Price per token alone does not measure total valuation, dilution or economic quality.
Name three comparison fields beyond issuance.
Show explained answer
Who can change rules, how consensus is secured, and whether liquidity is concentrated are useful fields. State evidence and uncertainty for each rather than assigning a promotional score.
9. Understanding Different Types of Bitcoin Wallets
Read: Chapter 9: Understanding Different Types of Bitcoin Wallets. Learning objective: Classify wallets along separate signing, validation and recovery dimensions.
A wallet can be noncustodial without running a full validating node. A watch-only wallet can observe relevant activity without holding spending keys. A pruned full node can validate while retaining less historical block data; permanent archival storage and validation are not identical properties.
Deterministic wallets derive key families from initial secret material and associated rules. BIP32 extended keys include a chain code; they are not just ordinary public keys or simple “add one” sequences. An extended public key can expose substantial transaction relationships even though it is not ordinarily a spending secret.
Original worked example: Separate three decisions
| Step | Calculation or observation | Meaning |
|---|---|---|
| Signing | A fictional hardware device holds signing keys. | This answers where authorization occurs. |
| Validation | A separate full node checks the chain. | This answers which rules are independently verified. |
| Recovery | Documented compatible backup and configuration are available. | This answers how access survives device loss. |
Keep this: Do not collapse a wallet review into a single hot/cold label.
The book compares full-wallet and lightweight verification and introduces deterministic derivation.
An inclusion proof is not full consensus validation. Recovery compatibility may depend on seed format, passphrase, script type and derivation information; word count alone is insufficient.
Practice and check your reasoning
Can a watch-only wallet spend merely because it displays the balance?
Show explained answer
No. Observation does not provide the required signing authority. It may still reveal sensitive financial information.
Why is an extended public key more sensitive than a single receiving address?
Show explained answer
It may reveal or derive a family of public keys and addresses, enabling broader activity linkage. Treat it as privacy-sensitive rather than casually publishing it.
Does a wallet’s noncustodial label prove it validates all blocks itself?
Show explained answer
No. Custody concerns signing control; validation concerns how transaction and chain rules are checked. Inspect both architectures separately.
10. Bitcoin 2030
Read: Chapter 10: Bitcoin 2030. Learning objective: Read future narratives as conditional scenarios and separate recordkeeping from enforcement.
The future chapter is an exercise in imagining adoption and applications. Treat its named events and laws as elements of a scenario, not as verified history. In particular, the Digital Real Estate Reform Act described in the future narrative is fictional.
A token or timestamp can record a statement without proving that the statement is true, that a physical asset exists or that a court recognizes a transfer. Off-chain systems also differ: a custodian’s internal ledger is not automatically equivalent to a payment channel with on-chain enforcement mechanisms.
Original worked example: Scaling a hypothetical workload
| Step | Calculation or observation | Meaning |
|---|---|---|
| Volume | 2 billion hypothetical payments per day | A scenario input, not measured adoption. |
| Throughput | 2,000,000,000 ÷ 86,400 ≈ 23,148 payments/second | An average; peaks would be higher. |
| Architecture | Ask which events are on-chain and who can exit or censor. | Throughput alone does not describe custody or settlement guarantees. |
Keep this: Name both the scaling mechanism and its trust assumptions.
The reading projects future adoption, prices and applications.
Predicted dates and vivid stories are not evidence. Separate user count, transaction frequency, valuation and technical capacity into independently testable assumptions.
Practice and check your reasoning
Does a blockchain record prove legal ownership of a house?
Show explained answer
Not by itself. Identity, authority, factual accuracy and applicable legal recognition are external requirements. A tamper-evident record cannot supply missing truth.
Why is average throughput inadequate for capacity planning?
Show explained answer
Traffic varies. Peak demand, latency, failures, transaction size and settlement design matter; an average can conceal congestion.
What would weaken an optimistic adoption scenario?
Show explained answer
Evidence of declining use, persistent usability barriers, weak security incentives or migration to alternatives could weaken particular assumptions. Specify the measurement before observing the outcome.
Appendix A: Hello Money!
Read: Appendix A: Hello Money! A Simple JavaScript Program. Learning objective: Recognize payment-state and polling errors without connecting to a wallet.
The appendix contrasts merchant-service integration, node RPC and direct peer networking. Each moves trust and operational responsibilities. Do not install its old dependencies or expose an authenticated node endpoint simply to follow a historical tutorial.
A rising balance is not a reliable receipt identifier. A spend can lower the balance, an unrelated deposit can raise it, and a reorganization can change confirmation state. Receipt accounting should track identifiable outputs and explicit states, not compare a balance with an old high-water mark.
Original worked example: Why the balance alarm misses events
| Step | Calculation or observation | Meaning |
|---|---|---|
| Start | Balance is 100 fictional units. | The monitor stores 100. |
| Spend | Balance falls to 20; the monitor updates only on increases. | Its stored comparison remains 100. |
| New receipt | Balance rises to 60. | A real increase of 40 is missed because 60 is below the stale high-water mark. |
Keep this: Use stable receipt identities and state transitions rather than balance increases alone.
The appendix shows a short periodic callback and Bitcoin-node connection.
In JavaScript, setInterval(mainLoop(), 5000) calls the function immediately; setInterval(mainLoop, 5000) passes it for later calls. That syntax fix alone does not solve accounting, authentication or confirmation handling.
Practice and check your reasoning
Why does an unchanged total balance not prove there were no transactions?
Show explained answer
Incoming and outgoing amounts can offset. Balance is an aggregate, not a complete event log.
Why should a receipt’s amount be immutable under the same output identity?
Show explained answer
Changing it silently could corrupt accounting or conceal inconsistent input. A robust handler rejects the conflict and investigates rather than overwriting it.
What does the offline lab intentionally omit?
Show explained answer
It does not connect to Bitcoin, verify signatures or blocks, discover recipients, select a safe confirmation threshold or custody funds. It tests a narrow bookkeeping model only.
Appendix B: Bitcoin Programming with BitcoinJ
Read: Appendix B: Bitcoin Programming with BitcoinJ. Learning objective: Audit persistence, callbacks and settlement assumptions in historical code.
Treat the old Java API and dependency versions as a code-reading exercise. Logging private keys, holding essential state only in memory and busy-waiting indefinitely are patterns to question, not copy into a modern application.
Broadcast completion, peer acceptance, transaction inclusion and later confirmation depth are different events. An application needs durable state, restart behavior, error handling and reorganization handling. A library callback is evidence of a specific event, not proof of irreversible settlement.
Original worked example: Restart and replay
| Step | Calculation or observation | Meaning |
|---|---|---|
| Before restart | The app credits a fictional output, but stores its identity only in memory. | The business ledger and receipt state can diverge. |
| After restart | The provider repeats the same receipt callback. | The app can double-credit if it treats every callback as new. |
| Control | Persist identity and accounting changes atomically; reconcile after restart. | The requirement is broader than a single duplicate check. |
Keep this: Event delivery and business accounting must be coordinated.
The appendix demonstrates wallet creation, peer connections and payment callbacks.
Its old classes and main-network assumptions are historical. This workbook does not validate that code against current BitcoinJ or recommend running it with funds.
Practice and check your reasoning
Does a successful broadcast callback mean two confirmations?
Show explained answer
No. It reports broadcast-related progress under that library’s semantics, not inclusion plus depth. Read the actual event contract.
What is dangerous about printing private keys during debugging?
Show explained answer
Logs are copied, indexed, retained and shared. A debug statement can expose permanent signing authority to systems outside the wallet’s intended trust boundary.
Which failure should a restart test include?
Show explained answer
A crash between receipt detection and durable ledger update, followed by replay. The system must neither lose the credit nor apply it twice; transaction boundaries and reconciliation require explicit design.
Original Offline Lab: Receipt State, Duplicates and Reversals
This original JavaScript exercise uses invented output labels and integer satoshis. It models a receipt ledger, not the Bitcoin protocol. No packages, account, wallet, network access or secrets are needed. Save the code as receipt-lab.cjs and run it with Node.js, or simply trace the fixture table by hand.
Our experimental rule credits an output at two confirmations and removes that credit if its reported state falls below two or is marked removed. Two is chosen only to demonstrate transitions; it is not a universal settlement recommendation. The event source is assumed to report the current authoritative state. Real software also needs authentication, ordering, durable atomic updates and reconciliation; an old event arriving late could otherwise undo a newer one.
| Fixture event | Credit change, sats | Why |
|---|---|---|
| A first seen at 0 confirmations | 0 | Below the experimental threshold. |
| A reaches 2 | +25,000 | Crosses the threshold. |
| Duplicate A event | 0 | Same state must not credit twice. |
| A falls to 0 | −25,000 | Previously applied credit is reversed. |
| A reaches 3 | +25,000 | Qualifies again after the reversal. |
| B reaches 2 | +7,000 | A separate fictional output. |
| B marked removed | −7,000 | Removal overrides reported confirmation count. |
Open complete offline JavaScript lab
Select and copy the code manually. It contains only fictional fixtures.
"use strict";
const assert = require("node:assert/strict");
const receipts = new Map();
let creditedSats = 0;
const threshold = 2; // Teaching choice, not a settlement policy.
function apply(event) {
const { output, amountSats, confirmations, removed = false } = event;
assert.equal(typeof output, "string");
assert.ok(output.length > 0);
assert.ok(Number.isSafeInteger(amountSats) && amountSats > 0);
assert.ok(Number.isSafeInteger(confirmations) && confirmations >= 0);
assert.equal(typeof removed, "boolean");
const prior = receipts.get(output);
if (prior) assert.equal(prior.amountSats, amountSats);
const wasCredited = prior ? prior.credited : false;
const isCredited = !removed && confirmations >= threshold;
const delta = (Number(isCredited) - Number(wasCredited)) * amountSats;
const nextTotal = creditedSats + delta;
assert.ok(Number.isSafeInteger(nextTotal) && nextTotal >= 0);
receipts.set(output, { amountSats, credited: isCredited });
creditedSats = nextTotal;
return delta;
}
const events = [
{ output: "fictional-A:0", amountSats: 25000, confirmations: 0 },
{ output: "fictional-A:0", amountSats: 25000, confirmations: 2 },
{ output: "fictional-A:0", amountSats: 25000, confirmations: 2 },
{ output: "fictional-A:0", amountSats: 25000, confirmations: 0 },
{ output: "fictional-A:0", amountSats: 25000, confirmations: 3 },
{ output: "fictional-B:1", amountSats: 7000, confirmations: 2 },
{ output: "fictional-B:1", amountSats: 7000, confirmations: 2, removed: true }
];
const deltas = events.map(apply);
assert.deepEqual(deltas, [0, 25000, 0, -25000, 25000, 7000, -7000]);
assert.equal(creditedSats, 25000);
assert.throws(() => apply({ output: "fictional-A:0", amountSats: 9, confirmations: 2 }));
assert.throws(() => apply({ output: "fictional-C:0", amountSats: 0.5, confirmations: 2 }));
console.log(JSON.stringify({ deltas, creditedSats }, null, 2));
Validation status: The complete fixture sequence and assertions were executed locally with Node.js. Expected deltas are 0, +25,000, 0, −25,000, +25,000, +7,000, −7,000; final credited total is 25,000 sats. Conflicting amounts and fractional satoshi inputs are rejected. This verifies the displayed toy behavior only, not production readiness or Bitcoin consensus.
Practice and check your reasoning
Remove the final event by hand. What total should remain?
Show explained answer
32,000 sats. A contributes 25,000 and B contributes 7,000 until B’s removal reverses that second credit.
What happens if an old zero-confirmation snapshot arrives after a newer three-confirmation snapshot?
Show explained answer
This deliberately small handler trusts arrival order and would reverse the credit. Production ingestion needs authoritative ordering or reconciliation; idempotency alone does not solve stale events.
Why There Is No Pine Script Indicator
This book teaches monetary systems, cryptography, custody and software behavior rather than a defined chart setup. OHLCV cannot verify signatures, recover keys, validate consensus or audit a custodian. Adding a price-chart indicator would imply a connection the source does not provide. The relevant executable exercise is therefore the offline bookkeeping lab above. No Pine trading system or order-execution code is included.
Four Reusable Worksheets
Copy these field names into your notes and complete them using fictional cases. Keep real secrets and sensitive operational details out of shared documents. The sample entries show the expected depth; they are not instructions to buy or transfer funds.
Worksheet 1 – Transaction observation
| Field | What to record | Fictional sample |
|---|---|---|
| Question | Define exactly what you are checking. | Does the proposed transaction preserve value with the intended fee? |
| Inputs | List output identities and integer amounts. | A:0 = 90,000 sats; B:1 = 70,000 sats. |
| Outputs | Separate payment and change. | 120,000 payment; 37,500 change. |
| Fee and rate | Show calculation and size assumption. | 2,500 sats; 250 assumed vB; 10 sat/vB. |
| Observed state | Distinguish mempool, inclusion and depth. | Seen unconfirmed; no settlement claim. |
| Unknowns | State what the worksheet cannot verify. | No actual transaction, signature or block was supplied. |
| Review | Check arithmetic and intended recipient independently. | 160,000 − 157,500 = 2,500; destination still requires verification. |
Worksheet 2 – Custody and recovery review
| Field | Prompt | Fictional sample |
|---|---|---|
| Asset and authority | Who can authorize spending? | A fictional owner controls one signing device. |
| Threat | Choose one event at a time. | Device destroyed in an accident. |
| Control | What addresses that failure? | A separately maintained compatible recovery path. |
| Residual risk | What does the control not solve? | A thief with sufficient recovery material can still authorize. |
| Dependencies | List nonsecret configuration requirements. | Wallet format and script/derivation documentation. |
| Recovery rehearsal | Describe a safe no-funds demonstration. | Trace the documented procedure with invented labels only. |
| Review trigger | When should the plan be revisited? | A change in device, software, responsible people or backup arrangement. |
Worksheet 3 – Research claim and evidence ledger
| Field | Prompt | Fictional sample |
|---|---|---|
| Claim | Use one testable sentence. | Venue A is cheaper for an equivalent delivered amount. |
| Source and date | Identify provenance, not just a screenshot. | Two fictional written quotes for the same time window. |
| Definition | Define comparable outcomes. | Same quantity, currency, withdrawal destination and timing. |
| Calculation | Include all named costs. | 10,100 versus 10,140 total cost. |
| Contrary evidence | What would change the conclusion? | Withdrawal surcharge or inability to deliver on schedule. |
| Uncertainty | Name missing information. | No actual provider terms or execution records checked. |
| Decision boundary | State what follows and what does not. | A wins this invented cost comparison; no real provider recommendation follows. |
Worksheet 4 – Software event and learning review
| Field | Prompt | Fictional sample |
|---|---|---|
| Invariant | What must always remain true? | One qualifying receipt contributes its amount once. |
| Identity | Which stable field identifies the item? | Fictional transaction label plus output index. |
| Normal path | List expected state transitions. | 0 confirmations → 2 → duplicate 2. |
| Failure path | Include reversals and restarts. | 2 → 0; removal; replay after process restart. |
| Expected result | Write the answer before running anything. | Duplicate delta 0; reversal delta −25,000. |
| Observed result | Record actual output and differences. | Local lab matches fixture deltas; no network behavior tested. |
| Next improvement | Name an unresolved boundary. | Persistent atomic ledger updates and stale-event handling. |
| Teach-back | Explain the error you now recognize. | Balance movement is not receipt identity. |
Capstone: Audit a Fictional Bitcoin Payment Project
A fictional community group wants to accept Bitcoin payments. Its proposal says: “Payments are instantly final; a hardware wallet makes backups unnecessary; a callback means paid; we will estimate future revenue from a fixed coin supply.” Your task is to replace those assertions with a defensible educational design, without setting up accounts or moving money.
- System map: Identify the payer, signer, wallet interface, validation source, event source, accounting ledger and recovery responsibilities.
- Transaction check: Use 240,000 input sats, a 175,000 payment and a 4,000 fee. Show the change and distinguish authorization from settlement state.
- Custody review: Model device loss and one theft scenario. Name controls and residual risks; include no real secrets.
- Receipt tests: Define duplicate, reversal, restart and stale-event cases. Explain the offline lab’s limits.
- Evidence review: Correct each promotional assertion. Add a valuation scenario with explicit assumptions and one adverse alternative.
- Teach-back: Write 150–250 words explaining what the project can verify, what it still trusts and what requires specialist review.
Open capstone answer outline
The change is 61,000 sats: 240,000 − 175,000 − 4,000. Signature validity concerns authorization; inclusion and confirmation depth concern the selected chain. A broadcaster or payment callback alone does not establish the chosen settlement state.
A sound map separates signing from validation and payment-event ingestion from durable accounting. The custody review needs an independent recovery path and recognizes that hardware does not protect every backup or every approval decision. Duplicate handling must survive restarts; reversal handling must adjust previously applied credit. Stale events need ordering or reconciliation rather than blind arrival-order processing.
Future revenue requires assumptions about actual customers, payment frequency, pricing and costs; a supply cap cannot provide those. A hypothetical valuation calculation may be included as sensitivity analysis, with a lower-adoption alternative and no price target. The summary should identify remaining trust in software, devices, data sources and operational procedures.
| Scoring area | 0–2 points | Full-credit requirement |
|---|---|---|
| System boundaries | 0 absent; 1 partial; 2 clear | Signing, validation, custody and accounting are distinct. |
| Arithmetic | 0 incorrect; 1 unexplained; 2 correct | 61,000-sat change and complete fee arithmetic. |
| Threat model | 0 slogans; 1 one-sided; 2 balanced | Accident and theft controls plus residual risks. |
| Event handling | 0 callback=paid; 1 partial; 2 robust | Duplicate, reversal, restart and stale-event cases addressed. |
| Evidence quality | 0 promises; 1 caveats; 2 testable | Claims corrected and scenario assumptions exposed. |
Completion standard: Aim for at least 8/10 with no zero in arithmetic or threat modeling. Revisit the relevant chapter for every missed point. This is a learning rubric, not a certification of software security, custody readiness or investment suitability.
Verification References and Research Boundaries
The workbook’s reading assignments refer to the supplied EPUB. These primary sources support specific clarifications; they are not blanket endorsements of products. Technical and security references were checked for this draft on October 27, 2026.
- No Starch Press: book listing – title, authors, release listing and ISBN.
- Bitcoin Developer Guide: transactions – outputs, change and transaction-fee structure; avoid treating its historical policy examples as current quotes.
- Bitcoin Developer Reference: block chain – block validity, target and coinbase constraints.
- BIP32: hierarchical deterministic wallets – extended keys, chain codes and derivation.
- BIP341: Taproot – modern script and signature context, referring to BIP340 Schnorr signatures.
- Electrum FAQ – wallet seeds and lightweight verification architecture; not a recommendation to reuse book-era setup instructions.
- Trezor: scams and phishing – recovery-material exposure and impersonation risks; product-specific recovery procedures vary.
What was and was not tested: Workbook arithmetic, internal links, saved content and the offline JavaScript assertions were checked. No exchange account, Bitcoin node, signing device, production wallet or BitcoinJ deployment was tested. No live prices, profitability records or current provider fee schedules are supplied.
Final Takeaway
Use the book to understand the questions, and use this workbook to make the distinctions precise. You should be able to explain a spend, audit a fee, map custody dependencies, evaluate a mining assumption and spot a payment-state error without relying on a prediction about Bitcoin’s price.
Risk Disclosure
This material is educational and is not personalized financial, legal, tax or cybersecurity advice. Bitcoin and other cryptoassets can lose substantial value. Custody mistakes, compromised software, scams and operational failures can cause irreversible loss. The exercises use fictional data and do not require buying assets, revealing secrets or transmitting funds.
This independent companion is not affiliated with or endorsed by the authors or publisher. Read the original book alongside it; the workbook’s examples, critiques, exercises and code are original educational additions.