Start with a familiar question: what happens when someone pays in bitcoin? These eight lessons follow the payment from the wallet to a confirmed block. Technical terms are explained when they first appear. You can read in order or choose a topic from the contents.
Lesson01
Bitcoin, BTC and wallets: three different things
Bitcoin is a network of computers that follows shared rules to record transfers without a central account administrator. Its participants exchange transactions directly with one another. The public transaction history is grouped into blocks linked together: the blockchain. BTC is the network’s native monetary unit. One bitcoin equals 100 million satoshis, so a payment can use a small fraction of a bitcoin.
A wallet is software or a device that manages the information needed to receive payments and authorize spending. The bitcoin themselves are recorded as unspent outputs in the network’s transaction history; they are not files stored inside your phone. The private keys are secret information used to authorize spending. An address provides payment instructions that you can share with a sender; it is not a private key.
With self-custody, you control the keys and are responsible for protecting and recovering them. With a custodial account, a provider controls the keys on your behalf. These arrangements involve different risks. Bitcoin’s limited issuance does not guarantee a stable price, purchasing power or investment return.
Lesson02
How a payment moves from a wallet to a block
Bitcoin does not update a single account balance when you pay. A transaction spends earlier unspent transaction outputs, usually shortened to UTXOs, and creates new outputs. A wallet adds up the outputs it can spend to display a balance. When it selects an output for payment, that output is spent in full; any change can be assigned to a new output controlled by the sender.
For example, an input worth 10,000 satoshis can fund a payment of 6,000 satoshis and a change output of 3,800 satoshis. The remaining 200 satoshis are the transaction fee. These amounts explain the accounting; they are not a quote for today’s fees. Fees generally depend on transaction size and demand for block space, rather than a fixed percentage of the amount sent.
The wallet creates the transaction and supplies the authorization required to spend its inputs. It broadcasts the transaction to the network. Nodes check it and may keep it in a local mempool, their collection of transactions awaiting confirmation. A miner can include it in a block. Once that block is accepted under a node’s rules and becomes part of its active chain, the transaction has its first confirmation. Additional blocks add confirmations.
Lesson03
SHA-256 and digital signatures: different jobs
SHA-256 is a cryptographic hash function. It takes input bytes, such as the bytes representing a message, and produces a 256-bit result called a hash or digest. It is commonly displayed as 64 hexadecimal characters. The same input always gives the same result. Changing even one bit usually produces a very different hash, with no useful shortcut for predicting it.
A hash is not encryption. There is no decryption key that turns a SHA-256 digest back into the original message. Hashing helps link data and detect changes; it does not hide Bitcoin’s public transaction history or make users anonymous. In the experiment below, you can change a sample message and compare the results yourself.
Digital signatures solve a different problem: they provide authorization to spend under the transaction’s rules without revealing the private key. Other participants can check the signature using the corresponding public key and the signed data. Bitcoin uses ECDSA signatures and, for Taproot, BIP340 Schnorr signatures over the secp256k1 elliptic curve. Hash functions and signatures work together, but they are not interchangeable.
Lesson04
Mining: searching for a hash below a target
A miner prepares a candidate block containing transactions and a first transaction called the coinbase. The coinbase can allocate the permitted new-block subsidy and transaction fees. The miner then constructs the block’s 80-byte header. It includes a reference to the previous block, a value called the Merkle root, which links the header to the block’s transaction identifiers, and fields such as the timestamp, target encoding and nonce.
Mining repeatedly applies SHA-256 twice to the header. For a valid proof of work, the resulting number must be less than or equal to the required target, a threshold set by the consensus rules. A smaller target makes success less likely for each attempt. This is trial and error: miners are not solving a useful hidden equation, and one failed attempt does not make the next more likely to succeed.
The nonce is a 32-bit field that miners can change to try different headers. They can also change other permitted data. For example, changing extra-nonce data in the coinbase changes its transaction identifier, the Merkle root and the header. Once a qualifying hash is found, the block still has to pass all other validation rules. Mining pools coordinate participants and share proceeds under their own arrangements; they do not guarantee rewards or profitability.
Lesson05
How full nodes check blocks and confirmations
A full node is software that independently checks Bitcoin’s consensus rules. When it receives a block, it checks more than the proof-of-work hash: transactions must satisfy their spending conditions, inputs cannot spend unavailable outputs, and the coinbase cannot claim more than the permitted subsidy and fees. An invalid block is rejected even if producing it used substantial computing power.
Two valid blocks can occasionally compete for the same position. Among histories that satisfy its rules, a node follows the chain with the most accumulated proof of work. This is often called the longest chain, but the important measure is total work, not simply the number of blocks or the number of computers supporting a version of history.
A confirmation means that a transaction is included in a block in that chain; each following block adds another confirmation. Replacing that part of the history becomes harder as more work accumulates, but reorganizations remain possible. The number of confirmations appropriate for a payment depends on its value and the recipient’s risk tolerance. The protocol targets an average of about ten minutes between blocks; it does not promise that the next block will arrive within ten minutes.
Lesson06
Who develops Bitcoin, and who decides the rules?
Bitcoin is not a company with a chief executive who can order everyone to change the system. Different participants have different roles. Developers propose, write, test and review software. Miners choose candidate blocks to work on. Node operators choose the software and rules they enforce. Users choose wallets and services and decide which payments they will accept.
A Bitcoin Improvement Proposal, or BIP, documents a proposed idea or standard. Publication is not activation: a proposal, a software release and a rule that is actually enforced are different stages. Changes can require technical review, implementation and coordination among participants. People can also disagree and choose not to adopt a change.
It helps to distinguish consensus rules from a node’s local policies. Consensus determines whether a block is valid under that node’s rules. Local policies affect matters such as which unconfirmed transactions it relays or keeps in its mempool. A local policy change is not automatically a change to what Bitcoin blocks may contain. Well-known educators, contributors and companies can influence discussion, but none speaks for every Bitcoin user.
Lesson07
Real uses: payments, donations and local projects
Bitcoin can transfer value between people who choose to use it, without requiring a central operator to approve a transaction that meets the network’s rules. A payment can remain on the blockchain, or a service can use another system, such as Lightning, with its own operating requirements. Access to the network and access to a convenient local-currency service are different things.
There are practical examples. BTCPay Server provides open-source tools that merchants can use to accept bitcoin, including Lightning when configured. OpenSats accepts bitcoin donations to support open-source work. Bitcoin Beach describes a local payment and education initiative in El Salvador. These examples illustrate possible uses; they do not establish universal adoption or imply that a particular service suits every reader.
Before using a payment service, check who controls the keys, the fees, how the recipient receives value and what happens if the provider is unavailable. Volatility, local-currency conversion, privacy and applicable rules also matter. Sending bitcoin across a border does not automatically provide cash withdrawal at the destination. Learning how a system works should come before deciding whether to use it.
Lesson08
Why Bitcoin uses payment channels and other networks
Bitcoin’s base layer records transactions in blocks with limited capacity. More demand for that capacity can raise fees and waiting times. Increasing the number of everyday payments is therefore not just a question of putting more individual transactions into each block. Other designs can handle some activity outside the main chain and use it for specific settlement or enforcement steps.
Lightning uses payment channels to update balances without recording every update in a Bitcoin block. Sidechains such as Liquid and Rootstock have their own blocks and mechanisms for representing bitcoin. Fedimint provides custody shared among guardians. Ark-style systems and BitVM-based designs explore other mechanisms at different stages of development. Calling something a layer 2 does not mean that it has the same guarantees as another system.
Compare each design using five questions: who controls the keys, what asset the user holds, where transactions become final under the system’s rules, what liquidity is needed, and how the user can exit if a provider fails. A faster screen update is not necessarily a Bitcoin main-chain confirmation. The next section explains a selected set of models and their limitations; it is not a list of every Bitcoin-related project.
Five terms you will meet in these lessons
Nonce
A 32-bit number in the block header that miners change to try new hashes. When its possible values are exhausted, other permitted data can be changed too.
Coinbase
The first transaction in a block. It can allocate the permitted block subsidy and transaction fees. This protocol term is unrelated to the company named Coinbase.
Merkle root
A 32-byte value that commits the header to an ordered list of transaction identifiers (txids). Changing a committed identifier changes this value. Bitcoin separately commits to witness data, additional spending data such as signatures; changing only those data need not change a transaction’s txid.
Target
The largest permitted proof-of-work hash integer. A smaller target makes finding a qualifying hash harder.
Peg
A mechanism connecting an asset represented on one network to funds held on another. The people, software or hardware that operate that connection are part of its security assumptions.
SHA-256
Try it: hashing and a simplified proof of work
Change a sample message and compare its SHA-256 digest. Then try nonce values in a demonstration header. This runs only in your browser; it mines no bitcoin and sends no transaction.
Use sample text, never wallet secrets. Your input is neither sent to the server nor stored. Leaving this page clears it from the tool.
Double SHA-256 result, shown in Bitcoin’s usual byte order
—
Attempts
0
Last nonce tested
—
The example uses an 80-byte header, an artificial easy target and a message digest in place of a real transaction Merkle root. It has no valid block body and does not follow mainnet difficulty. Real nodes would not accept it as a Bitcoin block. The last tested nonce, not a count of guaranteed successes, is shown.
These explanations simplify the presentation, not the rules. Examples use illustrative amounts rather than current fees. Each lesson links to protocol documentation or a primary source so you can explore the details.
Sources checked:
Learn first. Then interpret the data.
Connect the explanations to observed fees, blocks, treasury disclosures and market data. A chart is more useful when you know what its numbers measure.