Bitcoin Basics is the first category in Mempool Surf Club Learn, but it is not only a glossary of beginner terms. It establishes the conceptual and practical boundaries readers need before moving into the Bitcoin Network, Building on Bitcoin, Bitcoin Development, or the Bitcoin Ecosystem.
Those boundaries matter because familiar words are often used as though they describe the same thing. A wallet is not an address. A private key is not a seed phrase. A seed phrase is not always a complete recovery plan. A custodial account is not the same arrangement as direct key control. A transaction can be signed without being broadcast, broadcast without being confirmed, and confirmed without becoming absolutely final. Privacy can improve at one layer while information still leaks through another.
The purpose of this hub is to give readers the concepts and practical habits needed to understand, hold, and use bitcoin with confidence. Confidence here does not mean certainty, risk-free use, or financial gain. It means identifying which system layer is involved, which claims come from the protocol, which choices belong to software or services, and which responsibilities remain with the user.
A systems map, not a list of definitions
Bitcoin combines a peer-to-peer network with a digitally scarce native asset, bitcoin. The network records transactions, applies consensus rules, and allows independently operated software to verify valid history. The asset is accounted for through transaction outputs rather than one central account database.
That high-level description becomes useful only when its parts remain distinct.
Wallet software manages keys, constructs transactions, and helps users interact with Bitcoin. It does not contain bitcoin as coin files. A wallet calculates a useful balance by identifying transaction outputs connected to the keys, scripts, or watch-only information it manages.
Custody asks who controls the keys or authorization needed to move bitcoin. In self-custody, the user or a user-defined arrangement directly controls that authorization. In a custodial account, a service controls the relevant keys and records a customer claim. Neither arrangement is automatically correct for every person. Each places trust, support, recovery, privacy, and failure risk in different locations.
Transactions spend existing unspent transaction outputs, or UTXOs, and create new outputs. A wallet may hide that structure behind a send screen, but the output model explains input selection, change, fees, balances, privacy links, and later spending.
Security and privacy overlap, but they are not the same goal. Security includes reducing unauthorized spending, permanent loss, operational failure, and recovery failure. Privacy concerns how transaction activity, ownership relationships, and identity can be observed or connected. A device, node, network route, wallet feature, or collaborative transaction may reduce a specific exposure without guaranteeing complete security or anonymity.
This category builds a map of those relationships one guide at a time.
Foundations
Foundations begins with the broadest question: What is Bitcoin?
The first guide distinguishes Bitcoin the network from bitcoin the asset and introduces nodes, miners, wallets, transactions, proof of work, UTXOs, confirmations, and issuance. The second asks why this combination of open participation, verifiable rules, digital scarcity, and key-based ownership may matter while preserving the system's costs, limits, and tradeoffs.
The history sequence places Bitcoin inside decades of work on digital cash, cryptography, timestamping, and proof of work. It separates protocol milestones from market events, company failures, and cultural stories. The Satoshi guide narrows the historical record further. It explains the documented work of Bitcoin's pseudonymous creator without treating an unverified identity theory as fact or turning authorship into permanent control.
These guides create the starting point for everything that follows. Bitcoin has no central issuer, but services around it may still be centralized. Public rules can be inspected, but that does not make software flawless. Scarcity describes an issuance constraint, not a promise about demand, market price, or purchasing power. Open participation reduces certain permission boundaries, but it does not remove technology, legal, access, or operational constraints.
Using Bitcoin
Using Bitcoin moves from the system into the tools and actions most readers encounter first.
A Bitcoin wallet manages keys and transaction workflows. It may generate receiving information, identify relevant UTXOs, calculate a balance, select inputs, create outputs, estimate fees, coordinate signatures, and track confirmation state. Those functions can live in one application or be divided among a coordinator, signer, node, server, backup, and several people.
Self-custody is one possible custody arrangement. It can reduce dependence on a custodian, while shifting backup, recovery, device, continuity, and transaction-verification responsibilities to the user or the arrangement they design. Custody should not be treated as a binary moral judgment. The useful question is where spending authority sits, which dependencies remain, and what happens if a device, service, location, or participant becomes unavailable.
The sending and receiving guide follows an on-chain payment from receiving information through review, input selection, signing, broadcast, node acceptance, miner selection, block inclusion, and later confirmation depth. Each stage answers a different question. A readable QR code does not prove that a destination is correct. A valid signature authorizes transaction data but does not broadcast it. A node may accept a transaction into its local mempool without creating a confirmation. A fee estimate forecasts competition for block space rather than reserving a place in the next block.
The transaction and fee guide then opens the data structure beneath the interface. It explains why UTXOs are spent as complete units, why change is a new output, why the on-chain fee is the difference between input and output value, and why fee rate relates to transaction weight rather than the amount being transferred.
Security
Security begins with recovery material because many serious mistakes come from collapsing several controls into one concept.
A seed phrase is a human-readable backup representation used by many wallets to derive keys under a wallet standard. It is not an address, a device PIN, an application password, or one private key. Recovery can also depend on a passphrase, derivation paths, script types, descriptors, account information, multisignature policy, other signers, or wallet-specific records.
Private and public keys occupy another layer. A private key is secret cryptographic material used to authorize spending. A related public key can support signature verification without revealing the private key under Bitcoin's cryptographic assumptions. Addresses are destination representations used by wallets to construct locking scripts. Keys do not hold bitcoin, and an address is not a wallet.
The security guide turns those components into a maintainable system. It asks readers to consider theft, loss, software origin, devices, backups, transaction review, recovery, physical access, inheritance, and the people involved. More complexity is not automatically more security. A plan that cannot be understood, maintained, or recovered can become its own failure mode.
The privacy guide maps information across the public blockchain, wallet queries, network connections, services, merchants, devices, payment communication, and later spending. Bitcoin is pseudonymous, not automatically anonymous. Fresh addresses, personal nodes, Tor, coin control, CoinJoin, PayJoin, or Lightning may change specific information flows, but no single tool removes every possible link.
Essentials
Essentials connects everyday use to four ideas that readers will meet throughout the rest of Learn.
UTXOs explain Bitcoin's output-based accounting model. A transaction spends specific earlier outputs and creates new ones. Wallet balances are calculated views over those outputs, not protocol-level account balances. Input selection affects transaction weight, fees, change, privacy, and future wallet structure.
Confirmations explain settlement depth. A transaction receives its first confirmation when it is included in a valid block on a node's active chain. Additional blocks increase depth and usually reduce practical reorganization risk. They do not create absolute finality, prove legal identity, settle a commercial dispute, or provide one universal safe count for every payment.
The halving guide explains Bitcoin's consensus-enforced issuance schedule. The block subsidy began at 50 BTC and is reduced by half every 210,000 blocks under current mainnet rules. The halving reduces the permitted subsidy for future blocks. It does not cut existing balances, guarantee miner behavior, or operate as a price mechanism.
The final guide brings the category together through safe everyday practices. It treats safety as an ongoing process: understand the custody model, obtain software through expected sources, know what each control protects, maintain recovery information, verify payment details, review fees and confirmations, manage privacy deliberately, and revisit the setup when people, devices, software, value, or circumstances change.
How the four subcategories connect
The four subcategories are ordered, but they are not isolated.
Foundations explains what the system is and why its design choices matter. Using Bitcoin shows how wallets, custody, transactions, and fees turn those ideas into action. Security examines the keys, recovery information, devices, people, and information flows that make those actions dependable or risky. Essentials reveals the output, confirmation, issuance, and maintenance concepts that connect everyday use to the wider network.
Each guide adds one part of a larger systems map. A wallet guide becomes clearer after Bitcoin and UTXOs are distinguished. A custody decision becomes clearer after keys and recovery are separated. Confirmation policy becomes clearer after transaction broadcast and block inclusion are separated. Privacy becomes clearer after UTXO selection, change, services, and later spending are visible.
Readers do not need to memorize every detail on the first pass. The goal is to know where a question belongs and which boundaries should remain intact.
How to use this hub
There are three planned ways to enter the category.
First, follow the complete sixteen-guide category in canonical order. This is the most complete route. It starts with the system and its history, moves into wallets and transactions, develops security and privacy boundaries, and finishes with UTXOs, confirmations, issuance, and maintainable everyday practice.
Second, enter one of the four subcategories based on the current need. Foundations supports readers asking what Bitcoin is or how it developed. Using Bitcoin supports wallet, custody, payment, and fee questions. Security supports recovery, keys, threat modeling, and privacy questions. Essentials supports readers who need a clearer model of outputs, confirmations, the halving, or practical maintenance.
Third, use MSC-PATH-START | Start With Bitcoin as the curated starting route. A learning path can select a teaching order across destinations, while the hub preserves the permanent canonical category order. MSC-PATH-SAFE | Use Bitcoin Safely and MSC-PATH-NETWORK | Understand the Network are planned related paths for readers with narrower goals.
The category prepares readers for MSC-HUB-NETWORK | The Bitcoin Network without duplicating it. Bitcoin Basics introduces transactions, UTXOs, confirmations, nodes, miners, and consensus only as needed for safe understanding and use. The Network category goes deeper into mining, node operation, mempools, blocks, proof of work, chain selection, consensus, and upgrades.
All anchors, cards, and related destinations are planned intent only. They must remain inactive until implementation confirms real published destinations and URLs.