Bitcoin — On-Chain Fundamentals

The base layer. Everything else builds on Bitcoin's UTXO model and proof-of-work security.

The UTXO Model#

Bitcoin doesn't track "accounts." It tracks Unspent Transaction Outputs (UTXOs).

┌─────────────────────────────────────┐
│  Transaction 1: Bob pays Alice 1 BTC │
│  Output: 1 BTC → Alice's address     │  ← UTXO for Alice
│  Confirmed in block #800,000         │
└─────────────────────────────────────┘
           │
           ▼
┌─────────────────────────────────────┐
│  Transaction 2: Alice spends 0.3 BTC │
│  Input:  1 BTC UTXO from TX1        │  ← Consumes Alice's UTXO
│  Output: 0.3 BTC → Carol            │
│  Output: 0.6999 BTC → Alice (change) │  ← New UTXO for Alice
│  Fee: 0.0001 BTC                     │
└─────────────────────────────────────┘

UTXO Properties#

• Atomic: each output is all-or-nothing
• Discrete: fixed denominations, not account balances
• Linked: inputs reference specific outputs
• Immutable: once confirmed, the chain can't be altered

Transactions#

Structure#

Field        Description
-----------------------
version       Transaction format version
inputs[]      List of UTXOs being spent
outputs[]     List of new UTXO destinations
locktime      Earliest block/time for confirmation

Script Types#

Type	Example	Use Case
P2PKH	Pay to Public Key Hash	Legacy (base58 addresses)
P2SH	Pay to Script Hash	Multi-sig, SegWit-compat
P2WPKH	Pay to Witness Public Key Hash	Native SegWit (bc1...)
P2WSH	Pay to Witness Script Hash	Complex scripts
P2TR	Pay to Taproot	Schnorr, privacy, efficiency

Address Formats#

Prefix	Type	Script
1...	P2PKH	Legacy
3...	P2SH	Nested SegWit
bc1q...	P2WPKH / P2WSH	Native SegWit
bc1p...	P2TR	Taproot

Keys#

ECDSA (Original)#

• Curve: secp256k1
• Uses: Legacy signing, non-Taproot addresses

Schnorr (BIP-340, Taproot)#

• Curve: secp256k1
• Uses: Taproot addresses, Nostr identity
• Advantages: Linear aggregation (multi-sig = single key), batch verification, privacy

Derivation Paths (BIP-32/39/44/84/86)#

m / purpose' / coin_type' / account' / change / address_index

m / 84' / 0' / 0' / 0 / 0    ← Native SegWit
m / 86' / 0' / 0' / 0 / 0    ← Taproot

Block Structure#

Block
├─ Header (80 bytes)
│  ├─ Version
│  ├─ Previous block hash
│  ├─ Merkle root
│  ├─ Timestamp
│  ├─ Difficulty target (bits)
│  └─ Nonce
└─ Transaction list
   ├─ Coinbase tx (miner reward)
   └─ Regular transactions

Block Time: ~10 minutes#

Block Size: ~4MB (up to, with SegWit)#

Block Reward: 3.125 BTC (since April 2024), halving every ~4 years#

Supply#

Total supply: 21,000,000 BTC
Current supply: ~19,500,000 BTC (~93%)
Next halving: ~March 2028 (3.125 → 1.5625 BTC)

Mempool#

The mempool is the waiting room of unconfirmed transactions:

• Each node maintains its own mempool
• Miners select transactions by fee rate (sat/vB)
• Full mempool → low-fee transactions purged
• Replace-by-fee (RBF): bump fee to accelerate

Confirmations and Finality#

1 confirmation:  ~10 minutes  — Low-value final
3 confirmations: ~30 minutes  — Typical threshold
6 confirmations: ~1 hour      — "Standard" finality
100 confirmations: ~16.7 hours — Exchange-grade

Consensus Rules (Simplified)#

1. Total supply ≤ 21M BTC
2. Valid signature for each input
3. No double-spends of UTXOs
4. Valid proof-of-work (hash ≤ target)
5. Block size within limits
6. Halving schedule

Why This Matters for Lightning & Cashu#

• Lightning channels are UTXOs (2-of-2 multisig transactions)
• Channel opens/closes are on-chain Bitcoin transactions
• Cashu mints back tokens with on-chain BTC
• All value ultimately settles on Bitcoin
• Proof-of-work provides the trust anchor for the entire stack

Resources#

• Bitcoin Whitepaper — Satoshi Nakamoto, 2008
• Mastering Bitcoin — Andreas Antonopoulos
• BIPs — Bitcoin Improvement Proposals