Mastering Bitcoin Skill

Core Insight

Bitcoin is not “digital money” — it is a decentralized trust network. The protocol establishes trust through cryptographic proof rather than institutional authority. Understanding this reframes everything: the blockchain is not a database but a consensus mechanism; mining is not computation for its own sake but a Sybil-resistance mechanism.

---

Keys and Addresses

Key Generation Chain

Random 256-bit number
    → Private key (k)
    → secp256k1 ECDSA: K = k × G (elliptic curve point multiplication)
    → Public key K (compressed: 33 bytes, uncompressed: 65 bytes)
    → SHA256 → RIPEMD160 (= "hash160")
    → Add version byte (0x00 for mainnet)
    → Double SHA256 → first 4 bytes = checksum
    → Append checksum to hash160
    → Base58Check encode
    → Bitcoin address (starts with 1)

One-way: you can go from private key to address, never backwards.

Key Security Properties

• Private key → Public key: ECDH/ECDSA, computationally infeasible to reverse (discrete log problem)
• Public key → Address: hash functions, preimage resistant
• Address reuse: technically possible but privacy-destroying; address = single use by convention

HD Wallets (BIP32/BIP44)

From a single 128-256 bit seed:

• Master key derived via HMAC-SHA512 of seed
• Child keys: derived deterministically — CKD(parent_key, index) → child_key
• Extended public key (xpub): can derive all public keys without ever seeing the private key
• Purpose/account/change/index path structure: m/44'/0'/0'/0/0

Why HD wallets matter: backup one seed → recover all keys. Watch-only wallets possible (xpub only).

BIP38: Encrypted Private Keys

passphrase + private_key → encrypted_private_key (starts with 6P) — useful for paper wallets with passphrase protection.

Multisig (P2SH)

M-of-N: requires M signatures from a set of N public keys. Address starts with 3.

• 2-of-3: two-person authorization, one key as backup
• Use cases: corporate treasury, escrow, cold storage with recovery

---

Transactions

UTXO Model (Unspent Transaction Output)

Bitcoin has no “accounts” or “balances”. Instead:

• The ledger tracks UTXOs — outputs from previous transactions that haven’t been spent
• Every transaction consumes UTXOs as inputs and creates new UTXOs as outputs
• Your “balance” = sum of all UTXOs where you own the locking script

Transaction:
  Inputs:  [ref to UTXO₁, unlocking_script₁]  [ref to UTXO₂, unlocking_script₂]
  Outputs: [value₁, locking_script₁]  [value₂ (change), locking_script₂]
  Fee:     sum(inputs) - sum(outputs)  [implicit — goes to miner]

Transaction Script (Bitcoin Script)

• Stack-based, intentionally Turing-incomplete (no loops) — prevents infinite loops, predictable execution
• Stateless: verification depends only on the script and the unlock data, not external state

Standard transaction types:

Type	Locking Script	Unlocking Script
P2PKH	OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	<sig> <pubKey>
P2PK	<pubKey> OP_CHECKSIG	<sig>
Multisig	OP_2 <pk1> <pk2> <pk3> OP_3 OP_CHECKMULTISIG	OP_0 <sig1> <sig2>
P2SH	OP_HASH160 <scriptHash> OP_EQUAL	<serializedScript> <data...>
OP_RETURN	OP_RETURN <data>	unspendable — data embedding

P2SH benefit: the complex script is hashed; the sender sends to a simple hash. Only the receiver needs to publish the full script at spend time.

Transaction Fees

fee = sum(inputs) - sum(outputs) — miners select transactions by fee per byte (satoshis/byte).

• No fee specified in a field — it’s implicit
• Higher fee = faster confirmation during congestion
• Minimum fee threshold set by nodes (varies)

---

The Bitcoin Network

Node Types

• Full node: downloads all blocks, validates all rules, maintains UTXO set
• SPV node (Simplified Payment Verification): headers only, asks full nodes for transactions using Bloom filters for privacy
• Mining node: full node + mining capability
• Light client: wallet, relies on full nodes for validation

SPV and Bloom Filters

SPV nodes can’t validate transactions independently; they verify a transaction is in a block by checking the Merkle proof. Bloom filters let them ask “does this block contain transactions involving my addresses?” without revealing exact addresses to the full node.

Network Discovery

Nodes use DNS seeds or hardcoded seed nodes, then exchange addr messages to discover peers. Connections maintained via ping/pong keepalives.

---

The Blockchain

Block Structure

Block:
  Header (80 bytes):
    Version (4 bytes)
    Previous Block Hash (32 bytes)  ← chain link
    Merkle Root (32 bytes)          ← commits to all transactions
    Timestamp (4 bytes)
    Difficulty Target (4 bytes)
    Nonce (4 bytes)
  Transaction count
  Transactions[]

Merkle Trees

All transactions in a block are hashed pairwise up a binary tree to produce the Merkle Root in the header.

Why Merkle trees matter:

• Tamper detection: changing any transaction changes the root
• Merkle proof: prove a transaction is in a block with O(log n) hashes, not the entire block
• SPV clients use this for lightweight verification

Blockchain Forks

When two miners find valid blocks nearly simultaneously:

1. Network temporarily splits
2. Both branches are valid; nodes work on whichever they saw first
3. When one branch gets a subsequent block, it becomes longer
4. Nodes switch to the longer chain; shorter chain’s block becomes an orphan
5. Resolution is automatic, ~10 minutes

---

Mining and Consensus

Proof of Work

Find a nonce such that: SHA256(SHA256(block_header)) < target

• Hash output must have N leading zero bits
• Target adjusted every 2016 blocks (~2 weeks) to maintain ~10 minute block time
• Expected work: 2^N hash operations to find a valid nonce

Why it works: producing a valid block is expensive (CPU/electricity); verifying it is instant (one hash). Attacks require majority of hash rate.

Difficulty Adjustment

new_target = old_target × (actual_time / 2016 blocks × 10 min)

Capped at 4× change per adjustment period to prevent oscillation.

Mining Incentive Structure

• Block subsidy: new bitcoin created each block (started at 50 BTC, halves every 210,000 blocks)
• Transaction fees: collected from all transactions in the block
• As subsidy approaches 0 (~2140), fees must sustain security

Coinbase Transaction

First transaction in every block, special:

• No inputs (creates new bitcoin)
• Contains coinbase data (arbitrary data, up to 100 bytes)
• Satoshi embedded “Chancellor on brink of second bailout for banks” in genesis block

51% Attack

If an attacker controls >50% of hash rate:

• Can create a longer chain starting from any past block
• Can double-spend: broadcast a transaction, wait for confirmation, then mine a secret longer chain that excludes it
• Cannot: create invalid transactions, steal from others’ addresses, change consensus rules (node software rejection)

Mining Pools

Miners pool hash power; shares submitted for partial work; reward split by contributed work. Reduces variance for individual miners; doesn’t change security properties as long as no single pool > 50%.

---

Bitcoin Security Principles

Security Model

Bitcoin security is based on cryptographic proof (not trust in institutions). The root of trust is:

1. Cryptographic keys you generate and control
2. Consensus rules enforced by your full node

Key Storage Hierarchy

Hot (online):
  Software wallet → small amounts, convenience

Cold (offline):
  Hardware wallet → significant amounts, daily use
  Paper wallet → long-term storage, infrequent access

Risk Management for Custody

• Diversify: don’t hold all bitcoin in one wallet type
• Multisig: add authorization requirements (2-of-3 hardware keys)
• Survivability: ensure heirs can recover — document key locations, use Shamir Secret Sharing
• Physical security: protect seed phrases from fire, theft, loss

Development Security Rules

1. Never generate keys on an internet-connected device for significant value
2. Test on testnet first; mainnet transactions are irreversible
3. Validate all inputs; verify amounts before signing
4. Use established libraries; don’t implement cryptography yourself