Bitcoin — Digital Gold, Censorship-Resistant Money, and the Lightning Network

From Satoshi's nine-page whitepaper to a $1 trillion network: how Byzantine fault tolerance, SHA-256, and economic incentives combine to create the first credibly scarce digital asset. Covers the UTXO model, Bitcoin Script, Nakamoto consensus, the halving schedule, and Lightning's multi-hop HTLCs.

1. Overview

Bitcoin is a peer-to-peer electronic cash system that allows online payments to be sent directly from one party to another without going through a financial institution. That single sentence — from Satoshi Nakamoto's October 2008 whitepaper — contains a 50-year-old unsolved computer science problem: how do you prevent double-spending without a trusted third party?

The answer Satoshi provided was not any single new idea, but a synthesis of:

• Hashcash proof of work (Adam Back, 1997) — make it computationally expensive to produce a valid block
• Linked timestamping (Haber & Stornetta, 1991) — chain blocks together so history is immutable
• Merkle trees (Ralph Merkle, 1979) — commit to all transactions in a block with a single 32-byte root
• Byzantine fault-tolerant consensus — honest participants follow the chain with the most accumulated work
• Economic incentives — reward honest mining with newly created coins; make cheating more expensive than cooperation

The precursors to Bitcoin

Each precursor solved part of the problem. Bitcoin was the first to combine all the pieces with a viable incentive structure that made the network self-sustaining.

Programmable scarcity: the 21 million cap

The total supply of bitcoin is hard-capped at 20,999,999.9769 BTC — effectively 21 million. This cap is enforced by the consensus rules that every full node verifies independently. No authority can inflate the supply. This is categorically different from any fiat currency or previous digital cash system.

2. The UTXO model

Bitcoin does not track account balances. Instead it tracks Unspent Transaction Outputs (UTXOs). Your "balance" is the sum of all UTXOs that you can unlock with your private key.

How UTXOs are created and spent

A transaction consumes one or more UTXOs (inputs) and creates one or more new UTXOs (outputs). The sum of input values must exceed or equal the sum of output values; the difference is the miner fee. Once a UTXO is spent it is removed from the UTXO set forever.

Interactive UTXO spending diagram

UTXO vs. account model

3. Bitcoin Script

Bitcoin's transaction validation language is a minimal, stack-based scripting system inspired by Forth. It is deliberately not Turing-complete: there are no loops and no unbounded recursion. Every script terminates in a bounded number of steps, making it trivially analyzable and preventing denial-of-service via infinite loops.

How the stack machine works

Execution proceeds left to right. Data items are pushed onto the stack. Opcodes pop items off the stack, perform an operation, and push the result. When execution finishes, if the top of the stack is non-zero (truthy), the script passes and the UTXO is validly spent.

P2PKH: Pay to Public Key Hash

The most common output type, used in >70% of all Bitcoin transactions. The locking script (scriptPubKey) is:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

To spend, Alice provides the unlocking script (scriptSig):

<sig> <pubKey>

Step-by-step execution:

P2SH, SegWit, and Taproot

Taproot is the most significant upgrade since SegWit. It combines three improvements:

• Schnorr signatures — linear in key count (enables non-interactive key aggregation via MuSig2; multisig looks identical to single-sig on-chain)
• MAST (Merkelised Abstract Syntax Trees) — a tree of spending conditions where only the executed path is revealed on-chain, saving space and preserving privacy
• Tapscript — updated scripting semantics enabling more complex conditions without revealing unused branches

In Taproot, key-path spending uses a tweaked public key that commits to the entire MAST root. If both parties cooperate (as in a Lightning channel close), only a single Schnorr signature appears on-chain — indistinguishable from a simple payment.

Common opcodes

# Script: <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

stack = []
script = [sig, pubKey, OP_DUP, OP_HASH160, pubKeyHash, OP_EQUALVERIFY, OP_CHECKSIG]

for op in script:
    if op == OP_DUP:
        stack.append(stack[-1])            # duplicate top
    elif op == OP_HASH160:
        top = stack.pop()
        stack.append(ripemd160(sha256(top)))
    elif op == OP_EQUALVERIFY:
        a, b = stack.pop(), stack.pop()
        if a != b:
            raise ScriptError("EQUALVERIFY failed")  # abort, UTXO not spent
    elif op == OP_CHECKSIG:
        pub = stack.pop()
        sig = stack.pop()
        tx_hash = compute_sighash(current_tx, input_index)
        valid = ecdsa_verify(sig, tx_hash, pub)
        stack.append(1 if valid else 0)
    else:
        stack.append(op)   # push data item

assert stack[-1] != 0, "Script failed"
# UTXO is validly spent

4. Nakamoto Consensus

Nakamoto consensus is the mechanism by which the Bitcoin network agrees on a single canonical chain history without a trusted coordinator. It combines proof-of-work, the longest-chain rule, and economic incentives to achieve probabilistic finality.

Proof of Work: SHA-256 double hash

To produce a valid block, a miner must find a nonce such that the double-SHA-256 hash of the 80-byte block header is numerically less than a target value:

The difficulty target is a 256-bit number. A smaller target means fewer valid hashes exist, so on average more hashes must be tried. The current difficulty requires the hash to start with approximately 76 leading zero bits — corresponding to roughly 10²³ hashes per valid block.

Difficulty adjustment

Every 2016 blocks (~2 weeks at 10 min/block), every node independently adjusts the target:

If blocks came faster than 10 minutes, the target decreases (harder). If slower, the target increases (easier). This self-regulating mechanism keeps block time near 10 minutes regardless of how much hash rate joins or leaves the network.

The longest-chain rule

When two miners find valid blocks simultaneously, a fork occurs. Nodes follow whichever chain has the most accumulated proof-of-work (not longest by block count, but heaviest by total difficulty). Miners build on the heaviest chain because building on a lighter chain is statistically certain to waste revenue.

Probabilistic finality: why 6 confirmations?

After a block containing your transaction is mined, each subsequent block (confirmation) makes reversing the transaction exponentially harder. Satoshi's original paper provided the exact analysis: an attacker with fraction q of total hash rate and honest miners with fraction p = 1 - q has probability:

where λ = z(q/p). For an attacker with 10% of hash rate:

Six confirmations provides <0.15% chance of reversal for an attacker with 10% of hash rate — considered safe for most payments. Exchanges handling large amounts typically require 3–6 confirmations; high-value transactions (Bitcoin ETF custodians) may require 12–30.

Selfish mining

In the selfish mining attack (Eyal & Sirer, 2013), a mining pool withholds valid blocks to gain a disproportionate share of rewards. A pool with just 25–33% of hash rate can earn more than its fair share by strategically releasing blocks. This attack is mitigated by propagation speed and the fact that large pools are publicly identifiable — the community can coordinate a fork to punish them.

Mining pools

Solo mining is impractical for most participants — at current difficulty, a single ASIC miner would expect to find a block every 20,000 years. Pools aggregate hash rate, find blocks more frequently, and distribute rewards proportionally. Major pools (Foundry USA, AntPool, ViaBTC) each control 15–25% of hash rate. A cartel of the top 3 pools approaching 51% is a recurring concern for decentralization maximalists.

5. Mining economics

Block subsidy and the halving schedule

Every Bitcoin block awards the miner a subsidy — newly created BTC. This subsidy halves every 210,000 blocks (~4 years):

The geometric series sums to exactly 21 × 10⁶ BTC: Σ (50 × 210,000 / 2ⁿ) for n=0,1,2,... = 50 × 210,000 × 2 = 20,999,999.97…

The fee market

As the block subsidy approaches zero, miner revenue must come entirely from transaction fees. This is not a bug — it is the designed long-term security model. The theory: as Bitcoin becomes more valuable, the total economic activity it processes grows, and fees per block should be sufficient to incentivize mining. Critics note this assumes perpetually growing on-chain demand, which is uncertain.

ASIC arms race

Bitcoin mining is dominated by Application-Specific Integrated Circuits (ASICs) custom-designed for SHA-256 double-hashing. Modern ASICs (Bitmain S21 XP: ~270 TH/s, 14.2 J/TH) are 10,000,000x more energy-efficient than the CPU mining of 2009. The arms race has priced out individual hobbyist miners and concentrated hardware production in a small number of foundries (primarily TSMC and Samsung, building chips for Bitmain and MicroBT).

Geographic distribution

Post the 2021 Chinese mining ban, the geographic distribution shifted dramatically. Current estimates (Cambridge CBECI, 2025):

6. The Lightning Network

On-chain Bitcoin throughput is approximately 7 transactions per second — insufficient for global retail payments. The Lightning Network is a Layer 2 payment channel network that enables near-instant, low-fee microtransactions without trusting a custodian.

Payment channels

A payment channel between Alice and Bob is created by locking BTC in a 2-of-2 multisig funding transaction on-chain. Once open, the two parties exchange signed commitment transactions off-chain, each of which represents the current balance split. Sending a payment = exchanging a new commitment transaction. Only the final state needs to be broadcast to close the channel.

Multi-hop routing with HTLCs

If Alice wants to pay Dave 0.001 BTC but doesn't have a direct channel, she can route through Charlie (who has channels to both). The routing uses Hashed Time Locked Contracts:

1. Dave generates a random secret R and sends Alice the hash H = SHA256(R)
2. Alice creates an HTLC with Charlie: "You get 0.001 BTC if you reveal a preimage of H within 40 blocks, else I get my money back"
3. Charlie creates an HTLC with Dave: "You get 0.001 BTC if you reveal a preimage of H within 20 blocks"
4. Dave reveals R to Charlie to claim payment; Charlie then reveals R to Alice to claim her HTLC
5. Atomicity: either all hops complete (Dave reveals R in time) or all revert (timeouts expire)

Onion routing for privacy

Lightning uses a Sphinx-based onion routing protocol. The sender wraps the route in layers of encryption — each hop only knows the previous and next node, not the full path. This prevents routing nodes from learning that Alice is paying Dave.

Real-world adoption

Lightning limitations

• Channel management — users must monitor channels for fraudulent closure attempts (or pay a watchtower service)
• Liquidity — outbound and inbound capacity must be balanced; routing large payments requires well-capitalized nodes
• Routing failures — payments can fail if no path has sufficient liquidity; BOLT 12 and trampoline routing help
• Capital lockup — funds in channels are locked and earn no yield; opportunity cost relative to DeFi
• Not UTXO-private by default — channel opens are on-chain and link UTXOs; improving with Taproot channel types

# Opening a channel
def open_channel(alice_key, bob_key, alice_amount, bob_amount):
    funding_tx = create_transaction(
        inputs=[alice_utxos + bob_utxos],
        outputs=[
            # 2-of-2 multisig output
            P2WSH(MultiSig(2, [alice_key, bob_key]),
                  value=alice_amount + bob_amount)
        ]
    )
    # Both sign and broadcast
    alice_sig = sign(funding_tx, alice_key)
    bob_sig   = sign(funding_tx, bob_key)
    broadcast(funding_tx)  # on-chain; ~1 confirmation needed

    # Initial commitment transactions (never broadcast unless closing)
    alice_commitment = create_commitment_tx(
        input=funding_tx.output[0],
        outputs=[
            CSV_delayed_to(alice_key, value=alice_amount),  # Alice's balance
            P2PKH(bob_key, value=bob_amount),               # Bob's balance
        ]
    )
    return Channel(funding_tx, alice_commitment)

# Cooperative close
def close_channel_cooperative(channel, alice_key, bob_key):
    closing_tx = create_transaction(
        input=channel.funding_tx.output[0],
        outputs=[
            P2WPKH(alice_key, final_alice_balance),
            P2WPKH(bob_key,   final_bob_balance),
        ]
    )
    # Both sign — single Schnorr signature with Taproot (indistinguishable from simple payment)
    sig = schnorr_sign_aggregated([alice_key, bob_key], closing_tx)
    broadcast(closing_tx)  # on-chain settlement

7. Bitcoin as money

Store of value vs medium of exchange

Gresham's Law states: bad money drives out good money. When two currencies circulate, people spend the inflationary one and hoard the deflationary one. In practice, Bitcoin holders spend fiat and save BTC — making Bitcoin function as a store of value rather than a unit of account or medium of exchange at current adoption levels.

The maximalist argument: this is the correct evolution. Gold similarly was first adopted as a store of value before becoming a medium of exchange in coinage. Lightning Network is the medium-of-exchange layer when/if the broader population holds BTC.

Stock-to-Flow model (and its critics)

The S2F model (PlanB, 2019) models Bitcoin's price as a function of its stock-to-flow ratio — the existing supply divided by annual new supply. Gold's S2F ≈ 60; after the 2024 halving, Bitcoin's S2F ≈ 120. The model predicted exponential price growth post-halving and achieved viral adoption among retail investors.

Bitcoin vs gold

Institutional adoption

• MicroStrategy — holds >500,000 BTC (~2.5% of total supply) on its balance sheet; pioneered the "Bitcoin treasury" corporate strategy
• US Spot Bitcoin ETFs — approved January 2024; BlackRock IBIT reached $50B AUM in record time; ETFs collectively hold >1M BTC
• Nation-state adoption — El Salvador (legal tender 2021); Central African Republic (2022); US Strategic Bitcoin Reserve executive order (2025)
• Pension/endowment funds — State of Wisconsin Investment Board, Abu Dhabi sovereign wealth fund disclosed BTC ETF positions

8. Network and nodes

Full node responsibilities

A Bitcoin full node downloads and validates every block and transaction since genesis. It independently enforces all consensus rules:

• Block size ≤ 4MB (weight units)
• Block subsidy matches the halving schedule
• No double-spend (UTXO set check)
• All scripts execute to true
• Timestamps within ±2 hours of median of last 11 blocks
• Proof-of-work target met

There are ~15,000–20,000 publicly reachable full nodes and likely 50,000–100,000 private nodes. They enforce consensus rules by refusing to relay or build on invalid blocks — even blocks produced by miners. This is the key insight behind the phrase "nodes > miners": miners can produce blocks, but nodes decide which rules count.

SPV clients

Simplified Payment Verification (SPV) clients (most mobile wallets) only download block headers (~80 bytes each; ~60 MB for the full chain). They verify payment inclusion via Merkle proofs from full nodes. SPV clients trust the longest chain of headers — they cannot independently verify every rule, but they can verify that their transaction is included in a block with valid proof-of-work.

Mempool and fee market dynamics

Unconfirmed transactions wait in each node's mempool (memory pool). Miners select transactions that maximize fee revenue per weight unit (satoshis/vByte). When block space is congested, fee rates spike. Users can accelerate stuck transactions using Replace-by-Fee (RBF) — rebroadcasting the transaction with a higher fee, signalled by setting sequence number < 0xFFFFFFFD. Child-Pays-for-Parent (CPFP) is an alternative: a recipient creates a child transaction with high fees to incentivize mining the stuck parent.

P2P gossip protocol

Bitcoin uses a custom peer-to-peer protocol over TCP. Nodes connect to 8 outbound peers by default. New transactions and blocks are announced with inv (inventory) messages and fetched with getdata. Block propagation uses compact blocks (BIP 152) — nodes send only the short transaction IDs for transactions they assume the peer already has in its mempool, reducing block propagation from ~1MB to ~10KB and cutting propagation latency from ~3s to ~0.3s.