Bitcoin and Cryptocurrency Systems

Introduction and Context

Bitcoin is a decentralized electronic cash system introduced in 2008 and implemented in 2009 under the pseudonym Satoshi Nakamoto. Its central design problem is the double-spending problem: digital information can be copied, so how can a scarce digital asset be transferred without relying on a central clearing institution? Bitcoin addresses this problem by combining digital signatures, a replicated transaction ledger, proof-of-work consensus, economic incentives, and a monetary issuance schedule.

Bitcoin is not merely a digital currency. It is a distributed computing and governance system in which participants agree on the ordering and validity of transactions. The system’s design trades high decentralization and censorship resistance for relatively limited transaction throughput, variable fees, energy consumption, and slower settlement than conventional payment networks.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain Bitcoin’s transaction, block, and UTXO models.
2. Describe Bitcoin addresses, keys, wallets, and transaction scripts.
3. Explain mining, proof-of-work, difficulty adjustment, and monetary issuance.
4. Analyze double spending, selfish behavior, and 51% attacks.
5. Evaluate Bitcoin’s incentive structure, energy use, and design trade-offs.
6. Explain the purpose and operation of the Lightning Network.
7. Apply these concepts to practical payment and security scenarios.

1. The Bitcoin Ledger: Transactions and UTXOs

Bitcoin does not maintain account balances in the conventional banking sense. Instead, it records unspent transaction outputs, or UTXOs. A UTXO is a spendable output created by a previous transaction and not yet consumed by a later transaction.

A transaction generally contains references to previous outputs, called inputs, and creates new outputs. Each output specifies an amount of bitcoin and a locking condition, usually expressed through Script. The party spending the output supplies an unlocking witness that satisfies that condition.

The conservation rule for a normal transaction is:

Here, the sums are measured in satoshis, the smallest standard bitcoin unit, where 1 bitcoin = 100,000,000 satoshis. The equality applies to ordinary transactions whose inputs refer to existing UTXOs. A coinbase transaction is a special exception because it creates new units as permitted by consensus rules.

For example, suppose Alice spends two UTXOs worth 0.40 BTC and 0.25 BTC. She creates an output of 0.60 BTC for Bob and a change output of 0.049 BTC for herself. The fee is:

The change output is essential because UTXOs are consumed completely. Wallet software normally returns the unspent remainder to a newly generated address controlled by the sender.

Transaction validation

A full node checks, among other conditions, that:

• every referenced input exists and is unspent;
• the unlocking data satisfies the previous output’s locking script;
• no input is used twice within the transaction;
• the sum of outputs does not exceed the sum of inputs;
• scripts and transaction structure follow consensus rules;
• the transaction is not otherwise invalid under policy or consensus requirements.

A transaction may be valid but not yet included in a block. Such transactions are commonly held in a node’s mempool. Mempool policies, including fee-rate preferences, are not identical to consensus rules: a node may decline to relay a valid low-fee transaction without making it invalid for the entire network.

2. Keys, Addresses, and Wallets

Bitcoin ownership is more precisely described as control over the private keys needed to authorize spending. A private key is a secret scalar selected from a very large numerical space. Its corresponding public key is derived through elliptic-curve cryptography, specifically the secp256k1 curve used by Bitcoin.

A digital signature demonstrates knowledge of a private key without revealing it. In simplified form, a transaction authorization has three properties:

1. Authenticity: it was authorized by the holder of the relevant private key.
2. Integrity: changing signed transaction data invalidates the signature.
3. Non-repudiation in the technical sense: the key holder cannot plausibly claim that the signature was generated without the key, although legal interpretations vary.

An address is an encoding of a spending condition, not an account number containing funds. Modern address formats include SegWit and Taproot forms. Reusing addresses is discouraged because it reduces privacy and may expose relationships among payments.

A wallet generally performs key generation, key storage, address derivation, transaction construction, fee selection, and signing. It does not store coins in the same way that a physical wallet stores cash. The blockchain records UTXOs; the wallet stores the credentials and metadata needed to spend them.

Wallet categories include:

A recovery seed is highly sensitive. Anyone who obtains it may control the associated funds. Best practice includes using reputable wallet software, verifying transaction destinations on a trusted display, maintaining geographically separated backups, and planning inheritance or organizational recovery procedures.

3. Bitcoin Script and Transaction Conditions

Bitcoin Script is a deliberately limited, stack-based programming language. It is not designed as a general-purpose language. Its restrictions reduce computational complexity and help nodes determine transaction validity consistently.

A traditional pay-to-public-key-hash condition can be described conceptually as:

1. provide a public-key hash and signature;
2. hash the supplied public key;
3. compare the result with the committed hash;
4. verify the signature against the transaction.

Other important constructions include:

• Pay-to-Script-Hash (P2SH): payment is made to a hash of a redeem script.
• Pay-to-Witness-Public-Key-Hash (P2WPKH): a SegWit form that separates witness data from the transaction’s older serialization area.
• Multisignature: requires a specified number of signatures from a set of keys.
• Taproot and Tapscript: support more flexible conditions while improving privacy and efficiency in appropriate cases.

Bitcoin Script uses conditional execution, but consensus validation also imposes limits on operations, sizes, and resource use. Script design illustrates a core engineering principle: expressive power must be balanced against verification cost and attack surface.

4. Blocks, Nodes, and Consensus

A block contains a block header, a set of transactions, and a cryptographic commitment to those transactions. The header includes the previous block hash, a Merkle-root commitment to transactions, a timestamp, a difficulty-related target representation, and a nonce.

A Merkle tree allows a node to verify that a transaction belongs to a block using a compact authentication path. If a transaction changes, the Merkle root changes, which changes the block header hash.

Full nodes independently verify blocks and transactions. They do not simply trust miners. A node rejects a block that violates consensus rules, even if the block was produced by a powerful miner. When multiple valid chains exist, nodes normally select the valid chain with the greatest accumulated proof-of-work, often described informally as the longest chain.

The phrase “longest chain” can be misleading because the relevant criterion is cumulative work, not necessarily the number of blocks. A chain containing blocks mined at different difficulty levels is evaluated by the total proof-of-work represented.

5. Mining and Proof of Work

Mining is the process by which specialized hardware repeatedly varies a block header field, commonly a nonce and extra nonce, seeking a hash below the network target. If H is the block-header hash and T is the target, a block satisfies the proof-of-work condition when:

The hash function behaves, for practical analysis, like a random function. If a single hash attempt has probability p of success, the expected number of attempts is:

This is an expectation, not a guarantee. Mining outcomes are probabilistic: a miner may find a valid block quickly or may experience a long sequence of failures.

A miner’s expected revenue depends on block subsidies, transaction fees, the probability of finding blocks, operating costs, and payment arrangements with a mining pool. If a miner controls fraction q of the network’s effective hash rate, its long-run expected share of block production is approximately q, assuming stable conditions and no unusual strategic behavior.

Mining pools reduce variance by coordinating miners. A pool gives miners work and pays them according to contributed shares, which demonstrate effort even when they do not satisfy the network target. Pool concentration creates governance and censorship concerns, although pool operators and the underlying hash-power owners are not always the same entity.

Difficulty adjustment

Bitcoin adjusts its target approximately every 2,016 blocks to keep the long-run block interval near ten minutes. The ideal period is therefore:

A simplified adjustment relation is:

In the actual protocol, the measured time is bounded by protocol limits to prevent extreme changes in a single adjustment period. If blocks arrive faster than intended, the target decreases, making mining harder. If they arrive more slowly, the target increases, making mining easier, subject to the relevant bounds.

The expected block interval is influenced by total hash rate, target, and the hash function’s output space. Difficulty adjustment does not make every individual block arrive every ten minutes; it regulates the average over adjustment periods.

6. Monetary Issuance and Supply

Bitcoin’s monetary policy is encoded in consensus rules. New bitcoin enters circulation through the block subsidy in coinbase transactions. The subsidy began at 50 BTC per block and halves approximately every 210,000 blocks. The sequence is therefore 50 BTC, 25 BTC, 12.5 BTC, 6.25 BTC, and so on, subject to the protocol’s integer-satoshi representation.

Ignoring rounding details and assuming the initial subsidy and halving schedule, the total subsidy is a geometric series:

Since the infinite geometric sum with first term 1 and ratio 1/2 equals 2, the idealized total is approximately 21,000,000 BTC. Actual implementation uses integer satoshis and finite subsidy periods, so the precise total is determined by consensus code and rounding.

The subsidy gradually declines, increasing the relative importance of transaction fees in miner revenue. This creates an unresolved long-run economic question: whether fee revenue will be sufficient to maintain adequate security as subsidy income approaches zero. The answer depends on bitcoin demand, transaction volume, fee levels, market prices, and the amount of hash power miners are willing to supply.

7. Double Spending and Security Threats

A double spend occurs when the same spendable value is used in conflicting transactions. A user might broadcast one transaction to a merchant and attempt to confirm a conflicting transaction elsewhere. Nodes reject conflicting attempts from the same UTXO within a single accepted chain, but temporary conflicts can exist in mempools or competing blocks.

Confirmation risk

A merchant accepting an unconfirmed transaction assumes that the transaction will be included in the economically dominant valid chain. More confirmations generally increase resistance to reversal because an attacker must produce an alternative chain with greater cumulative work. Confirmation count is not an absolute guarantee; security depends on attacker hash rate, transaction value, time, network conditions, and incentives.

The 51% attack

If an entity controls a majority of network hash power, it may be able to reorganize recent blocks and reverse its own payments, censor selected transactions, or prevent other miners from earning on a preferred chain. It cannot normally create coins arbitrarily, spend another user’s funds without the required keys, or alter the fixed consensus rules merely by mining more quickly.

A majority hash-rate attack is costly because the attacker must acquire or control hardware, electricity, and operational capacity. The attack may also reduce confidence in the currency and damage the attacker’s holdings. Nevertheless, an attacker may have motives other than direct profit, such as censorship, extortion, or geopolitical disruption.

Other threats include private-key theft, exchange insolvency, wallet malware, mining-pool manipulation, eclipse attacks, routing attacks, and software bugs. Bitcoin’s cryptography does not protect users who reveal keys or approve malicious transactions.

8. Incentives and Governance

Bitcoin aligns several incentives:

• miners receive subsidy and fees for producing valid blocks;
• nodes obtain validation and relay capabilities by following consensus rules;
• users pay fees to obtain scarce block space;
• developers propose changes, but adoption depends on voluntary use and coordination;
• holders may value predictable issuance and censorship resistance.

These incentives are imperfect. Miners may prefer changes that increase revenue, users may prefer low fees, and node operators may prefer lower resource requirements. Governance is therefore partly technical and partly political. Protocol changes can be activated through different coordination mechanisms, but no mechanism eliminates disagreement.

The distinction between consensus rules and policy rules is professionally important. Consensus rules determine whether a block or transaction is valid. Local policies determine what a node relays, stores, or prioritizes. Confusing the two can lead to incorrect security assessments.

9. Energy Use and Environmental Trade-offs

Proof-of-work converts electricity and hardware expenditure into a costly, externally verifiable ordering mechanism. Energy use is not an accidental side effect; it is part of the security model. A prospective attacker must incur comparable costs to compete with honest miners.

Environmental assessment should distinguish electricity consumption from emissions. A useful identity is:

If electricity is measured in kWh and emissions intensity in kg CO₂e/kWh, the result is kg CO₂e. The calculation requires reliable boundaries: whether it includes only mining machines or also cooling, buildings, manufacturing, and hardware disposal.

Mining can respond to electricity prices, stranded or curtailed energy, regulation, hardware efficiency, and bitcoin price. Claims about environmental impact should therefore specify time period, geographic scope, energy source assumptions, and lifecycle boundaries. The principal trade-off is that proof of work offers open participation and strong settlement assurance but requires substantial real-world resources. Alternative consensus systems may reduce direct electricity use but introduce different assumptions concerning capital concentration, governance, or security.

10. The Lightning Network

The Lightning Network is a protocol for transactions conducted largely off the Bitcoin base chain. It uses payment channels secured by Bitcoin scripts and cryptographic commitments.

Two parties can fund a channel with an on-chain transaction. They then exchange signed commitment transactions that update each party’s balance without publishing every update to the blockchain. A later closing transaction settles the final state on-chain.

The channel mechanism uses a revocation principle: if a participant broadcasts an outdated commitment, the counterparty can claim the channel’s funds under defined conditions, provided it detects the violation within the relevant time window. This creates a strong incentive to use the latest state honestly.

Payments across multiple channels use hashed timelock contracts, or HTLCs. The recipient reveals a secret preimage to claim payment. Intermediate participants can claim their incoming payment using the same secret, while timelocks protect them if the payment fails.

Lightning can improve speed, reduce on-chain fees for repeated payments, and support small transactions. Its limitations include liquidity management, online availability, routing failures, channel-management complexity, watchtower or monitoring requirements, and less straightforward user experience. It complements rather than replaces the base layer.

11. Applied Case: A Small Merchant Accepting Bitcoin

Background

Consider an illustrative case in which a software freelancer receives international payments. Bank transfers are slow and costly, while a custodial exchange creates counterparty dependence. The freelancer considers accepting on-chain bitcoin and Lightning payments.

Problem

The freelancer must manage price volatility, private keys, invoice generation, settlement risk, accounting, tax records, and the possibility of receiving a payment that is later disputed or incorrectly recorded.

Analysis

For large invoices, the freelancer chooses an on-chain transaction and waits for an appropriate number of confirmations based on transaction value and risk tolerance. For small recurring invoices, a Lightning invoice offers rapid settlement and avoids publishing every payment on-chain. The freelancer keeps only operational liquidity in a hot wallet and stores longer-term holdings in a hardware wallet with a documented backup procedure.

The freelancer also records the bitcoin value at the time of receipt, monitors fee rates, verifies invoices through trusted software, and maintains a conversion policy to reduce exchange-rate exposure. A multisignature arrangement may be appropriate if the business has multiple owners or requires separation of duties.

Outcome

The hybrid approach reduces dependence on a single intermediary and improves payment flexibility, but it does not eliminate operational costs. The business remains responsible for custody, compliance, accounting, security, liquidity, and customer support.

Learning points

The case demonstrates that Bitcoin is a system of trade-offs rather than a universal replacement for payment infrastructure. Technical capability must be matched with governance, controls, and an appropriate risk model.

12. Design Trade-offs and Professional Practice

Bitcoin’s principal design choices can be summarized as follows:

Professionals working with Bitcoin should separate protocol facts from market predictions, distinguish custody from ownership claims, document assumptions in security assessments, and avoid treating transaction confirmation as an absolute guarantee. Organizations should establish key-management policies, incident-response procedures, segregation of duties, vendor due diligence, and legal and tax review.

Contemporary development includes Taproot-based applications, improved wallet standards, hardware security, payment-channel research, mining diversification, and regulatory experimentation. These developments do not remove fundamental trade-offs; they change how those trade-offs are managed.

Chapter Summary

Bitcoin solves decentralized digital scarcity by combining cryptographic authorization, UTXO-based transactions, Script, replicated validation, proof-of-work, and economic incentives. Transactions consume previously unspent outputs and create new outputs, with fees equal to inputs minus outputs for ordinary transactions. Wallets manage keys and transaction construction rather than storing coins directly.

Mining selects blocks through a probabilistic hash search. Difficulty adjusts approximately every 2,016 blocks to target a ten-minute average block interval. New supply is issued through block subsidies that halve approximately every 210,000 blocks, while fees are expected to become increasingly important to miner security. Double spending is controlled through transaction validation and accumulated proof of work, although confirmation risk and majority-hash attacks remain important considerations.

Bitcoin’s strengths include independent verification, predictable issuance, and resistance to unilateral censorship. Its costs include energy use, limited base-layer throughput, fee variability, custody risk, privacy challenges, and governance difficulty. The Lightning Network extends Bitcoin through off-chain channels, offering faster payments while introducing liquidity and availability requirements. Effective professional use requires both technical understanding and disciplined operational, legal, financial, and ethical controls.

Key Terms

UTXO: An unspent transaction output that can be used as an input in a future transaction.

Satoshi: The smallest standard bitcoin unit, equal to 0.00000001 BTC.

Transaction fee: The difference between total transaction inputs and outputs.

Coinbase transaction: The special first transaction in a block that claims subsidy and fees.

Digital signature: Cryptographic evidence authorizing a transaction with a private key.

Private key: Secret data used to create valid digital signatures.

Public key: A value derived from a private key and used in cryptographic verification.

Address: An encoded representation of a Bitcoin spending condition.

Wallet: Software or hardware that manages keys, addresses, and transaction signing.

Script: Bitcoin’s stack-based language for expressing spending conditions.

Block: A data structure containing transactions and a proof-of-work header.

Merkle root: A compact cryptographic commitment to all transactions in a block.

Mining: The process of searching for a valid proof-of-work block.

Hash rate: The number of hash attempts performed per unit of time.

Difficulty adjustment: Protocol recalibration intended to maintain the target average block interval.

Block subsidy: Newly issued bitcoin awarded through a valid coinbase transaction.

Double spending: Attempting to use the same value in conflicting transactions.

51% attack: A majority-hash-power attack that may enable censorship or reversal of the attacker’s own recent payments.

Lightning Network: A payment-channel network enabling many transactions away from the base chain.

HTLC: A hashed timelock contract used to coordinate conditional cross-channel payments.

Review Questions

Short Answer Questions

1. What is a UTXO, and how does it differ from an account balance?
2. Why does a normal Bitcoin transaction need a change output?
3. What is the purpose of the difficulty adjustment?
4. What can and cannot a 51% attacker normally do?
5. What problem does the Lightning Network address?

Long Answer Questions

1. Explain the complete lifecycle of a Bitcoin transaction from wallet creation to block confirmation.
2. Describe proof-of-work mining, including the role of the target, nonce, hash rate, and difficulty adjustment.
3. Analyze Bitcoin’s monetary issuance schedule and discuss the transition from subsidy-based to fee-based security.
4. Compare custodial, non-custodial, hardware, and multisignature wallets in terms of control and risk.
5. Evaluate proof of work using security, decentralization, energy, and governance criteria.

Analytical / Application Questions

1. A transaction consumes inputs of 0.75 BTC and 0.18 BTC and creates outputs of 0.80 BTC and 0.125 BTC. Calculate the transaction fee and explain the likely role of the smaller output.
2. A merchant receives a high-value payment from a customer but sees only an unconfirmed transaction. What technical and business factors should determine whether the merchant releases the goods?
3. Design a custody and payment architecture for a small international business using both on-chain Bitcoin and Lightning. Justify your choices concerning keys, liquidity, confirmations, fees, volatility, and recovery.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a Bitcoin UTXO?

A. A user account balance maintained by a central bank

B. An unspent transaction output that can be consumed by a later transaction

C. A mining pool’s record of contributed hash attempts

D. A private key encrypted by a wallet

Correct Answer: B. An unspent transaction output that can be consumed by a later transaction

Question 2

A transaction has inputs totaling 0.90 BTC and outputs totaling 0.875 BTC. What is its fee?

A. 0.0025 BTC

B. 0.025 BTC

C. 0.875 BTC

D. 1.775 BTC

Correct Answer: B. 0.025 BTC

Question 3

What condition must a mined block satisfy in simplified proof-of-work notation?

A. H(header) ≥ target

B. H(header) = 0 for every hash attempt

C. H(header) ≤ target

D. The block must contain exactly one transaction

Correct Answer: C. H(header) ≤ target

Question 4

Why does Bitcoin adjust difficulty approximately every 2,016 blocks?

A. To maintain an average block interval near ten minutes

B. To guarantee that every block takes exactly ten minutes

C. To increase the block subsidy automatically

D. To eliminate transaction fees

Correct Answer: A. To maintain an average block interval near ten minutes

Question 5

Which action is generally within the capability of a majority-hash-power attacker?

A. Stealing coins directly from arbitrary private keys

B. Changing every user’s wallet password

C. Reversing the attacker’s own recent payment by reorganizing blocks

D. Creating unlimited bitcoin without violating consensus rules

Correct Answer: C. Reversing the attacker’s own recent payment by reorganizing blocks

Question 6

What is the main function of a Bitcoin wallet?

A. To store physical bitcoin coins

B. To manage keys and construct or sign transactions

C. To guarantee profitable mining

D. To replace all full nodes

Correct Answer: B. To manage keys and construct or sign transactions

Question 7

Which statement about Bitcoin’s block subsidy is correct?

A. It increases whenever fees decrease

B. It is awarded only to custodial exchanges

C. It halves approximately every 210,000 blocks

D. It is set independently by each miner

Correct Answer: C. It halves approximately every 210,000 blocks

Question 8

What is a principal benefit of the Lightning Network?

A. It removes the need for cryptographic signatures

B. It enables many payments without recording every update on the base chain

C. It guarantees that bitcoin prices cannot change

D. It makes private keys unnecessary

Correct Answer: B. It enables many payments without recording every update on the base chain

Question 9

If electricity consumption is measured in kWh and emissions intensity in kg CO₂e/kWh, their product measures:

A. Hash rate

B. Block difficulty

C. Operational emissions in kg CO₂e

D. Transaction throughput in BTC

Correct Answer: C. Operational emissions in kg CO₂e

Question 10

Why are confirmation counts relevant to merchants?

A. More confirmations generally increase the work an attacker must replace to reverse a payment

B. Confirmations convert bitcoin into fiat automatically

C. A confirmation proves that a private key can never be lost

D. Confirmations eliminate all exchange-rate risk

Correct Answer: A. More confirmations generally increase the work an attacker must replace to reverse a payment