Learn Crypto

Quick Basics

Start here for the essentials. Then scroll for in‑depth modules, pro topics, and the full glossary.

1) Money & Digital Scarcity

Money is a coordination tool. It wins by offering store of value, medium of exchange, and unit of account. Useful money is portable, divisible, durable, scarce, and easy to verify. Scarcity and verifiability historically required physical constraints (e.g., gold) or institutional control (fiat). Blockchains introduce a third path: digital scarcity enforced by cryptography and consensus.

Why blockchain?

• Double‑spend prevention: an append‑only ledger where nodes converge on one history.
• Credible issuance: rules baked into consensus (total supply, emission).
• Self‑verification: anyone can run a node and independently verify.

Related: monetary neutrality, censorship‑resistance, and permissionless access are emergent properties of public verification + wide node/miner distribution.

2) Cryptography Essentials

Hashes, Merkle trees, signatures

• Hash function: one‑way mapping with collision and preimage resistance. Tiny input changes → unpredictable output.
• Merkle tree: hash commitments enable efficient proof a tx is included in a block.
• Public/private keys: private key signs; public key verifies. Wallet seeds deterministically derive many keys.

Keys are capability: whoever holds the private key controls funds. Do not share a seed or type it on random sites. Keep offline backups.

See also: BIP‑39 seed phrase, BIP‑32 HD wallets, bech32 address.

Deterministic wallets & seeds

• One seed → many addresses (hierarchical derivation). Back up the seed once; you can restore all derived keys.
• Entropy quality matters: use reputable wallets; avoid rolling your own RNG.
• Passphrase (optional) changes the wallet; losing it = funds unrecoverable even with the seed.

3) UTXO vs Account Models

UTXO: you own a set of unspent outputs (“bills”). A spend selects inputs and creates new outputs (payment + change). Account: you have a balance and a nonce; transactions mutate balances.

• UTXO pros: parallelism, precise control, simple validation; cons: address reuse privacy issues, change handling.
• Account pros: simple UX, smart‑contract suitability; cons: global state, nonce handling, different privacy trade‑offs.

Practical UTXO hygiene

• Prefer fresh receive addresses; avoid address reuse to limit linkage.
• Consolidate small UTXOs during low‑fee periods; avoid creating dust.
• Label change addresses in advanced wallets to avoid accidental reuse.

4) Proof‑of‑Work Consensus

PoW secures history with verifiable cost. Miners find a block header hash below a target (“difficulty”). Nodes follow the chain with the most accumulated work. Rewriting confirmed history requires expending more work than honest miners—economically prohibitive at scale.

• Difficulty & target: networks retarget so block intervals trend toward a target; short‑term variance is expected.
• Confirmations: each block stacked on your tx makes reversal exponentially costlier. Small payments: 1–2 conf; medium: 3–6; large: policy‑based.
• Reorgs: shallow (1 block) can occur; deep reorgs are rare as hashrate and node diversity rise.

Intuition for difficulty

Lower target = fewer acceptable hashes = harder puzzle. If blocks arrive too fast over an adjustment window, difficulty increases; too slow → decreases. Variance persists; averages converge over time.

5) Blocks, Mempools & Fees

A block packages validated transactions with a header linking to the previous block. Pending txs collect in node mempools; miners select from mempools—often by feerate—so fees rise with congestion and fall when quiet.

• Anatomy: height, timestamp, prev_hash, hash, difficulty, nonce, tx list, reward/coinbase.
• Fee dynamics: backlog → higher fees for priority; low demand → cheaper confirmation.

See: mempool, difficulty adjustment, coinbase transaction.

Practical fee tips

• Batch payments when possible; avoid peak times; use replace‑by‑fee if supported.
• Estimate by recent blocks’ feerates rather than mempool size alone.

6) Transactions & Practical Safety

• Inputs/outputs: unlock conditions; change addresses; multi‑sig and timelocks exist.
• Risk by value: 0‑conf often unsafe; 1–2 conf small; 3–6 conf typical; large transfers use stricter policies.

See: confirmation depth and how it affects finality.

7) Security & Self‑Custody

• Threat models: malware, phishing, SIM‑swap, clipboard hijack, address poisoning.
• Wallet classes: hot, cold, hardware; passphrase; air‑gap workflows; restore testing.
• Backups: write seed on paper/steel; store separately; practice a restore; plan inheritance.

Hardening checklist

• Dedicated device/profile for finance; keep OS and wallet updated.
• Record the seed offline; consider steel backup; never cloud notes.
• Use hardware wallet for significant value; verify receive addresses on‑device.

Read more: phishing (crypto), address poisoning, dusting attack.

8) Mining 101

• Variance: mining outcomes follow probability; measure performance over weeks, not hours.
• Solo vs pool: solo = high variance; pools smooth payouts but require pool trust.
• Hygiene: thermals, power, stable clocks; avoid throttling; log monitoring.

Back‑of‑the‑envelope EV

Expected blocks/day ≈ (your hashrate ÷ network hashrate) × blocks/day. Expected daily coins ≈ expected blocks × block reward. Real results fluctuate around this mean.

See also: hashrate and difficulty adjustment.

9) Network Attacks & Health

Eclipse, selfish‑mining theory vs practice, timestamp tricks, difficulty edges. Defenses: diverse peers, robust propagation, widely distributed hashrate/nodes.

Pro: Linux, Shell & Ops

A power‑user toolbox to get more from nodes and miners.

• Process & logs: htop, journalctl -u yournode.service, dmesg for thermal/power hints.
• Networking: ss -tulpn, ufw basics, port forwarding and NAT hairpin notes.
• Filesystems: ext4 vs btrfs snapshots; rsync --inplace for fast data syncs.
• Scripting: small bash one‑liners for fee checks, log tailing, and simple alerts.

See also: DevOps & infra glossary.

Pro: Developer Corner

• Data formats: block header fields, endianness footguns, varints.
• Validation: header‑first vs full validation; checkpoints and trade‑offs.
• APIs: JSON endpoints on explorer; rate‑limit etiquette.
• SPV & proofs: headers + Merkle proofs for light clients; DoS budgets and proof sizes.
• Fee estimation: rolling medians vs mempool sampling; outliers & spike handling.
• Storage: UTXO set vs full history; pruning strategies; snapshot integrity.
• Benchmarks: block import throughput, sig‑verify cost, mempool admission latency.
• Script/VM: minimal script vs EVM design; determinism, gas/accounting nuances.
• Network health: stale/orphan diagnostics, eclipse resistance, peer selection.
• Attack economics: short‑range reorg costs, censorship incentives, fees vs subsidy.
• Tooling: tracing blocks, validating proofs, fuzzing tx parsers.

10) Economics & Game Theory

Emission schedules and halvings create a transparent supply path. Miner incentives combine block rewards + fees; finality emerges from the cost to rewrite history relative to expected gains.

Halvings & terminal supply

Fixed‑rule issuance front‑loads rewards to bootstrap security and tapers over time. As rewards decline, fee markets become security co‑funders.

Fee markets and security budgets

• Security budget = block subsidy + fees; the fee share grows over time.
• Healthy fee markets correlate with scarce blockspace and useful demand.
• Variance: fees are spiky; miners smooth with pools and treasury policy.

Attack economics

• Rational attackers weigh hashrate cost vs expected benefit of a reorg/censor.
• Mitigations: deeper confirmation policies for high‑value tx; diverse node/miner ecosystems.

11) Privacy Basics

Address reuse harms privacy; change detection, common input heuristics, and network metadata leak patterns. Good hygiene: fresh receive addresses, note change behavior, and beware linkable spending patterns.

12) Running a Node

A full node independently verifies all rules and transactions. Consider disk (with pruning if needed), memory, bandwidth, and uptime. Node data ≠ wallet seed—separate backup concerns.

Deep Dive: Nodes & Validation

How nodes prove the chain is valid and pick the canonical tip.

Node roles

• Full node: downloads and verifies all blocks/tx against consensus rules.
• Pruned node: discards old block bodies, keeping the UTXO set and recent blocks for validation.
• Archival node: retains full history; useful for explorers and historical queries.
• Light client: verifies headers + Merkle proofs; different trust model.

Validation pipeline (sketch)

• Header checks: target/nBits, PoW, version, prev hash linkage, timestamps (median‑time‑past policies).
• Block body: size limits, coinbase rules, reward/subsidy bounds, duplicate tx protection.
• Transaction rules: syntax, signatures, standardness/policy vs consensus, double‑spend checks against the UTXO set.
• Chain selection: follow the chain with the most accumulated work; handle shallow reorgs gracefully.

Storage & IBD

• UTXO set vs block store; pruning and compaction strategies; snapshot integrity/verification.
• Initial block download: parallel header sync then block fetch; assume‑valid/assume‑UTXO style shortcuts require careful trade‑offs.

Reliability

• Consensus‑critical code paths, test vectors, fuzzing, and defensive parsing.
• Operational tips: persistent storage, power protection, time sync, and safe upgrade windows.

Deep Dive: Networking & Propagation

How transactions and blocks move through the peer‑to‑peer network, and why it matters for security and UX.

P2P basics

• Gossip model, inbound/outbound peers, addr relay, peer eviction and DoS budgets.
• Announcements (inv), requests (getdata), and responses; headers‑first sync.

Propagation techniques

• Compact blocks and header‑based reconciliation reduce bandwidth and time‑to‑relay.
• Transaction relay policy: minimum feerate, orphan/pool limits, replace‑by‑fee signaling, package relay concepts.

Performance & health

• Latency and bandwidth directly affect stale/orphan rates; diverse peers and good connectivity improve outcomes.
• Monitoring: observe stale rate, mempool shape, and peer churn to assess network conditions.

Privacy notes

• Transaction origin leaks via patterns; staggered broadcast and Tor can help, with trade‑offs.

Practical Guides

Self‑Custody in 15 Minutes

1. Install a reputable wallet; generate a new wallet; record the seed on paper/steel—never digital photos.
2. Optionally add a passphrase; verify you understand that losing it loses funds even with the seed.
3. Test restore on a second device (preferably offline); ensure addresses match.
4. Store two backups separately; label and protect from fire/water.

Fee & Confirmation Sanity

• Backlog high → consider waiting or paying higher fee for priority.
• Small payments: 1–2 conf; medium: 3–6; large: increase per policy and risk appetite.

Speeding Up or Fixing a Stuck Tx

• RBF (Replace‑By‑Fee): if your wallet supports it, resend the same tx with a higher fee. The higher‑fee version replaces the older one.
• CPFP (Child‑Pays‑For‑Parent): send a new tx that spends change from the stuck tx with a high fee. Miners include both to earn the combined feerate.
• When to use: RBF if possible; CPFP when RBF isn’t available but you control an output from the stuck tx.

Multisig & Inheritance Basics

• Multisig: require m‑of‑n signatures (e.g., 2‑of‑3). Store devices/seeds separately; document the policy.
• Inheritance: write a plain‑language instruction letter: where the wallet is, what a seed is, how to restore, who can help. Add legal executor details if applicable.
• Test: practice a restore on a spare device. Assume future‑you has forgotten everything—make it followable.

Glossary (selected)

Term UTXO: Unspent Transaction Output. A coin you control that can be spent as an input to a new transaction.

Term Confirmation: One block added after the block containing your transaction; deeper = safer.

Term Nonce: Value miners vary to search for a valid block hash under the target.

Term Mempool: A node’s pool of unconfirmed transactions awaiting inclusion in a block.

Term Reorg: A short rollback when another competing chain tip overtakes the current tip.

Full glossary will expand as we iterate; we’ll cross‑link terms in the text. Prefer the comprehensive version here: Open full glossary →

FAQ (Beginner)

Why do block times vary? Mining is probabilistic; difficulty retargets keep long‑term averages near the target.

Why are confirmations recommended? They raise the cost to reverse a transaction; policies scale with value and risk tolerance.

My transaction is stuck—what do I do? If your wallet supports RBF, resend with a higher fee. Otherwise try CPFP by spending your change with a high fee.

Is it OK to reuse addresses? Avoid it. Reuse harms privacy and can leak your balance relationships.

What’s a seed passphrase? An optional extra word/phrase that changes the wallet. Lose it and funds are unrecoverable even with the seed.

FAQ (Intermediate)

What is RBF vs CPFP? RBF replaces a prior tx with a higher-fee version; CPFP spends an output of the stuck tx with a high fee so miners include both.

How do fees get estimated? Wallets sample recent blocks and mempool feerates; estimates are probabilistic and react to short‑term spikes.

What’s UTXO consolidation? Combine small UTXOs during low-fee periods to reduce future transaction size and fees.

What’s the mempool? A node’s queue of unconfirmed tx; bigger mempool → higher fees, slower confirmations.

Pruned vs archival node? Pruned keeps validation data for the tip; archival keeps full history. Both validate; archival serves historical data.

FAQ (Advanced)

Why do reorgs happen? Competing blocks at the tip resolve when one chain gains more work. Shallow reorgs are normal; deep ones are rare.

How does difficulty adjustment stabilize issuance? By retargeting the acceptable hash threshold to offset hashrate changes, keeping the long‑run average interval near the target.

What drives healthy fee markets? Scarce blockspace + useful demand. Fees co‑fund security as subsidies decline; demand is spiky and miner policies adapt.

Can SPV be safe? With header chains + Merkle proofs and robust anti‑DoS policies; trust model differs from full verification.

What improves propagation? Compact blocks, efficient peer graphs, bandwidth, and diverse relay paths reduce stale rates.