Reviewed and updated: October 19, 2026.
Bitcoin's architecture becomes easier to understand when the roles are separated. Wallets help users construct and authorize transactions. Full nodes independently validate rules. Miners assemble candidate blocks and perform proof of work. One operator may run several of these components, but the responsibilities are different.
Bitcoin tracks spendable outputs
The developer guide describes transactions as spending previous outputs and creating new ones. An unspent transaction output, or UTXO, has an amount and spending conditions. A wallet's displayed balance commonly summarizes outputs it can spend. The UTXO set is state: calling Bitcoin stateless confuses its scripting design with the network's accounting.
A complete input, payment, change and fee example
Suppose a wallet spends two outputs worth 0.006 BTC and 0.004 BTC. Their total is 0.010 BTC. It creates a 0.007 BTC payment and a 0.0029 BTC change output. The difference is the transaction fee:
0.006 + 0.004 − 0.007 − 0.0029 = 0.0001 BTC, or 10,000 satoshis.
The previous outputs are consumed as inputs; the change is a new output, not a partly edited old coin. These invented amounts demonstrate accounting and are not a suggested fee. Real fee selection depends on the transaction and network conditions.
Who checks what?
| Component | Main responsibility | What it does not establish alone |
|---|---|---|
| Wallet | Track relevant outputs, construct transactions and manage signing | That every displayed payment has been confirmed |
| Full node | Validate transactions and blocks against its consensus rules | The real-world identity or purpose behind an address |
| Miner | Build candidate blocks and search for acceptable proof of work | Permission to make invalid transactions valid |
| Block explorer | Present indexed network information | Independent validation by the person viewing its website |
Bitcoin Core's validation explanation emphasizes that nodes check blocks rather than trusting the miner that supplied them. Proof of work is necessary for an accepted Bitcoin block, but it does not replace transaction checks. A block that violates the node's rules is not made acceptable merely by spending more computing power on it.
Full validation does not require permanent archival storage
Bitcoin Core's historical pruning documentation explains how validated raw block files can be discarded while retaining the data needed for ongoing validation. A pruned full node and an archival full node therefore differ in retained history, not simply in whether they validate the rules.
A lightweight or SPV design uses a different verification model, commonly relying on headers and inclusion evidence rather than executing every transaction rule itself. Do not assume every mobile wallet is SPV: some rely on a server, some connect to a user's node, and implementations vary.
Signatures authorize; consensus orders history
Bitcoin uses spending conditions that can involve signatures. ECDSA is relevant to established output types, while BIP 340 specifies Schnorr signatures used with Taproot. Saying all Bitcoin signatures use only ECDSA leaves out this distinction.
When valid competing histories exist, proof-of-work chain selection considers accumulated work, not just a simplistic count of blocks. More confirmations can reduce reversal risk under the relevant assumptions; they do not prove a physical delivery occurred or protect a lost private key.
How to inspect a payment
Check the transaction's network, inputs, destination output, change, fee and confirmation status. Separate a wallet's local status from what a validating node or correctly identified explorer reports. This makes the architecture practical: it tells you which component can answer a question and which claims still require evidence outside Bitcoin.
Sources and scope
- Bitcoin developer guide: transaction inputs and outputs
- Bitcoin Core: validation responsibilities
- Bitcoin Core 0.11.0: introduction of block-file pruning (historical)
- BIP 340: Schnorr signatures
- Bitcoin developer guide: block-chain consensus
Continue reading: Proof-of-work probability and chain selection · Inscription storage and retrieval · Wallet custody and recovery
Editorial update: Corrected the stateless, all-nodes-archive and ECDSA-only descriptions; separated node and miner roles; added a balanced UTXO transaction and a payment-inspection workflow.