Bitcoin

Bitcoin.

Bitcoin is a decentralized digital payment system and its native monetary unit, bitcoin (BTC). A network of independently operated computers checks transactions against shared rules and records them in a public blockchain. Users can send bitcoin without asking a central payment operator to approve each transfer, although wallets, exchanges, and payment services may introduce intermediaries of their own.

Bitcoin was proposed under the name Satoshi Nakamoto in 2008, and its network began operating in January 2009. The creator's real-world identity remains unknown. For the launch, major protocol changes, exchange failures, and adoption milestones, see Bitcoin history. This article describes how the system works; Bitcoin FAQ (Frequently Asked Questions) answers practical questions about payments, wallets, mining, and risks.

The white paper, explained

Satoshi Nakamoto's nine-page 2008 paper, Bitcoin: A Peer-to-Peer Electronic Cash System, proposes online payments without appointing a bank or another central operator to keep the authoritative ledger. It is the design proposal that led to Bitcoin, not a complete manual for today's wallets. Its argument starts with a problem: how can a recipient know that digital funds have not also been paid to someone else?

From a bank's ledger to a shared record

Suppose Alice wants to pay Bob for a pair of socks. Barter would require each to want what the other offers at the same time. Money makes the exchange easier. With a conventional online payment, Alice and Bob normally rely on banks or payment providers to update their records, decide which payment is valid, and handle disputes. Such services can be useful, including when a payment must be reversed, but their availability, charges, privacy rules, and settlement times depend on the providers. The white paper asks how willing parties could transfer value online without making one provider the final judge of the ledger. Bitcoin answers that narrower question; it does not remove all costs, intermediaries, legal obligations, or the need to trust a seller. The paper expects hard-to-reverse payments to reduce one kind of seller fraud, while suggesting escrow to address some buyer risks. Any escrow or payment service has its own rules and trust assumptions; Bitcoin itself does not decide a buyer–seller dispute.

Why a signature is not enough

A digital signature shows that the holder of a spending key authorized a payment. It cannot tell the recipient whether that holder signed a conflicting payment. A bank can resolve the conflict by keeping the only accepted ledger. The paper instead proposes announcing transactions publicly and agreeing on one ordered history. In today's network, a transaction spends earlier unspent outputs and creates new ones; validating nodes check both the authorization and whether those outputs have already been spent.

How blocks establish an order

Transactions are grouped into blocks. Each block includes a fingerprint of the previous block, so changing an older entry would also alter the links that follow it. A miner searches for a block-header hash below a difficulty target. This proof of work is costly to find and easy to check. When two valid blocks appear close together, nodes may briefly follow different tips. They converge as one valid branch accumulates more work. The paper calls this the longest chain; the operational comparison is cumulative work, rather than a simple count of blocks.

What participants do

The network relays transactions; miners assemble candidate blocks; and other nodes check a found block before accepting it. A node rejects an invalid transaction even if its miner spent electricity producing the block. Participants can disconnect and later catch up with the accepted chain. This requires no central clock or named coordinator, but it does depend on the paper's assumptions about honest validation and mining power. Seeing a balance in a wallet service is a different level of assurance from independently checking a block.

Why miners are rewarded

A valid block can claim newly issued bitcoin through its coinbase transaction and collect the fees left by included payments. These rewards give miners a reason to spend resources producing blocks. The paper envisages fees replacing new issuance over time; it does not prove that a particular future fee market will fund a particular level of security. A block reward also gives no authority to override the rules enforced by other nodes.

Checking with less data

A Merkle tree reduces a block's many transactions to a compact fingerprint in its header. A short branch of hashes can prove that a particular transaction is included in that block. The paper also describes discarding old spent data to save space. Its simplified payment verification checks headers and inclusion proofs without validating every transaction. This uses fewer resources but relies more on other nodes and is weaker if an attacker controls the view presented to the user. A full node validates independently; a pruned full node can discard old block files after checking them.

Amounts and privacy

A transaction can have several inputs and outputs, letting a wallet combine smaller amounts or return change after spending a larger output. A payment is not one indivisible coin moving between account balances. The record is public. The paper proposes fresh keys to make transactions harder to link to a person, while noting that combined inputs can reveal connections. Information held by a service can also connect an address with a person. The design offers limited privacy, not guaranteed anonymity.

Why confirmations reduce risk

A dishonest sender might privately build a competing chain that removes a payment after the recipient delivers goods. The paper models this race: if honest participants control more mining power under its assumptions, the attacker's chance of catching up falls as more blocks are added after the payment. This does not make a payment mathematically irreversible or prescribe one safe confirmation count for everyone. A recipient weighs the amount, the kind of goods, and reversal risk. Even a powerful miner cannot make independently validating nodes accept a rule-breaking payment.

Together, signatures, a public transaction history, independently checked rules, and costly block production let participants agree on an order without one ledger operator. The paper sketches incentives and a later transition toward fee-supported mining, but it does not specify the exact 21-million-BTC limit or the later subsidy-halving schedule; those belong to the implemented rules explained below. The following sections explain how the design works in the network today; Bitcoin history covers the launch and later changes.

Transactions and validation

For an ordinary on-chain payment, Alice's wallet selects spendable outputs, creates new outputs for Bob and any change, and signs as the spending conditions require. It then sends the transaction to peers or a service, which may relay it further. Nodes check the rules they enforce before keeping or relaying it; a miner may choose it for a block; and validating nodes check that block. Bob can see a pending transaction before block inclusion, but should distinguish that notification from a confirmation. This sequence describes an on-chain transfer; a custodial account transfer or Lightning payment follows a different path.

Bitcoin accounts are not rows in a central bank database. The network tracks unspent transaction outputs (UTXOs): portions of earlier transactions that have not yet been spent. A wallet creates a transaction that spends earlier, unspent transaction outputs and assigns value to new outputs. The owner authorizes the spend with the required digital signature or other unlocking conditions. Network nodes independently check the transaction, including whether the inputs are available and whether the transaction follows the applicable consensus rules. For example, if a wallet controls one output worth more than the payment, it can spend that output and create both a recipient output and a change output controlled by the sender. The difference between total input and output values is the transaction fee; change is not the fee. An address is a way to describe spending conditions for an output, not an account whose balance is updated in place. Miners choose valid transactions for candidate blocks; a miner's inclusion of a transaction does not exempt it from node validation.

Bitcoin can require more than a single signature to spend an output. A transaction output contains a spending condition, and the next transaction must satisfy it. Some conditions can require more than one key or a specified block height or time before spending; these support arrangements such as shared custody and some payment channels. They do not give Bitcoin an unrestricted general-purpose program running inside every payment. For an ordinary recipient, the important distinction is that the network checks the spending condition, while a buyer–seller agreement or escrow service supplies any separate commercial protection.

Nodes relay transactions before they enter a block. A node may hold an accepted unconfirmed transaction in its memory pool, but memory-pool contents and relay policies differ between nodes. A transaction visible to one service has therefore not necessarily reached every miner, and an unconfirmed payment is not final. Blocks refer to earlier blocks and contain proof of work. Each block added after a transaction increases the work needed to replace its place in the accepted chain. Confirmations therefore reduce, but do not remove, reversal risk. Blocks are targeted to arrive about every ten minutes on average; the interval for a particular block varies. Recipients set their own confirmation policy according to the value and circumstances of a payment.

A competing block can temporarily replace a recently seen block. If the network later adopts a chain with more cumulative work, affected transactions may return to the memory pool or disappear if they conflict with transactions in the adopted chain. A confirmation count is the number of blocks from the transaction's block through the current chain tip; the deeper the transaction, the more work an attacker would need to reverse it. The appropriate wait depends on the recipient's exposure and tolerance for loss.

Bitcoin payments have no routine chargeback mechanism. A sender should check the recipient, amount, and network before sending. On-chain fees depend primarily on the transaction's size in data and current demand for block space, not simply on the amount transferred. Wallets can estimate fees, but a confirmation time is not guaranteed.

Network nodes and verification

A fully validating node checks incoming blocks and transactions against its own rules and maintains a view of the spendable outputs. It need not trust a block explorer or wallet provider's account of whether a block is valid. Initial synchronization downloads and validates historical data and can take considerable time and storage; a pruned node can discard old block files after validation while retaining the data needed for current validation. A lightweight wallet can use a server or simplified verification method, trading some independence or privacy for lower resource use.

Peers can discover one another through previously known addresses, DNS seeds, and addresses exchanged by peers. Ordinary wallets and nodes making outbound connections generally do not need an open inbound port. Network reachability matters for relaying, but a recipient's device need not be online when another person sends an on-chain payment; the wallet can learn about it when it reconnects.

Mining and supply

Mining is the competition to find a block header whose hash satisfies the network's difficulty target. Miners repeatedly vary candidate block data and hash the header until a result falls below the target. Finding a result is difficult, while checking it is comparatively easy. The difficulty adjusts every 2,016 blocks so that block production tends toward an average of about ten minutes despite changes in participating hash power. The winning miner broadcasts its candidate, but other nodes still reject it if it breaks their rules. A valid block can pay its miner a newly issued subsidy and the fees from transactions it contains. The first transaction, called the coinbase transaction, claims this reward. A miner may make an otherwise valid block without ordinary payments, although including fee-paying transactions can increase its revenue. The subsidy began at 50 BTC per block and halves every 210,000 blocks. The April 2024 halving reduced it to 3.125 BTC. Under the current rules, total issuance approaches a limit just below 21 million BTC; one BTC equals 100 million satoshis. The subsidy is expected to reach zero around 2140, but the calendar date is an estimate because blocks do not arrive at exact ten-minute intervals. Lost keys can make some issued bitcoin inaccessible, so issued supply and spendable supply are different concepts.

A mining pool coordinates work among participants and distributes rewards under its own arrangements. Pool operators can influence which valid transactions their blocks include, so concentration can affect censorship and short-term reversal risk. Even a majority of mining hash power cannot force a node to accept an invalid transaction, create arbitrary coins under existing rules, or spend coins without satisfying their spending conditions. A sufficiently powerful attacker can attempt to reorganize recent blocks or exclude payments while it controls that power; this is distinct from changing the rules enforced by nodes.

Mining consumes electricity and specialized hardware. Its environmental effects depend on the amount and source of energy used and on the measurement method. Mining pools reduce the variance of participants' rewards but introduce coordination and operator risks. A miner or pool cannot make an invalid block acceptable to a node that enforces the rules.

Supply, units, and fees

The commonly used smaller units are a millibitcoin (mBTC, 0.001 BTC), a microbitcoin (μBTC, 0.000001 BTC), and a satoshi (0.00000001 BTC). For example, 0.001 BTC is 100,000 satoshis. These are different ways to display the same amount, not separate currencies. On-chain transaction outputs are denominated in whole satoshis under current consensus rules; naming a smaller unit does not change those rules. Because a bitcoin can be divided into many satoshis, a buyer need not obtain one whole BTC.

Bitcoin amounts can be expressed in BTC or satoshis; 100 million satoshis equal one BTC. Users can acquire fractions of a bitcoin by receiving payment or buying from a counterparty or service. The protocol does not set the purchase price, identify a trustworthy seller, or guarantee that a quoted service will deliver bitcoin. The fixed subsidy schedule does not imply that all issued coins remain accessible: outputs controlled by irretrievably lost keys remain in the public record, while their owners cannot spend them.

The subsidy eventually becomes negligible under current rules; blocks can continue to earn transaction fees. A transaction's fee is the difference between its input and output totals. The fee rate, often expressed per unit of transaction data, matters to miners selecting transactions for limited block space. Demand and wallet behavior affect actual fees and wait times. A sender may pay more for a complex transaction even when transferring a small amount. Future fee revenue and network security are uncertain rather than predetermined by the issuance limit.

Wallets, custody, and privacy

A wallet manages the information and keys needed to receive and spend bitcoin. It does not hold coins as a file; the outputs are recorded on the shared ledger. A wallet may be software on a phone or computer, a device dedicated to signing, or a combination of an offline signer and a networked watcher. A receiving address can be shared, but a private key or recovery phrase should not be. The wallet's displayed balance depends on what it has learned from the network or its service provider. In self-custody, the user controls the spending keys and must protect usable backups. With a custodial service, the operator controls the keys and the customer relies on that operator's records and withdrawal process. Losing the only usable key or recovery information can make funds permanently inaccessible; disclosing it can let someone else spend them.

Bitcoin transaction history is public. Addresses do not contain a person's name by themselves, but payments can sometimes be linked to people through address reuse, service records, or other information. Bitcoin is therefore pseudonymous, not inherently anonymous. Generating a new receiving address for each payment can reduce one source of linkage, though it does not guarantee privacy. Combining several inputs in one transaction can disclose a relationship between them. CoinJoin is a way for several participants to make one transaction so that an observer has less certainty about which input paid which output; its effectiveness depends on the transaction, participants and other information available to an observer. It does not erase the public record or guarantee anonymity.

Observing payments and the network

A wallet or block explorer can show a transaction identifier, outputs, fee, block inclusion, and confirmations. An explorer is convenient but is another service's view of the public chain; it may log the addresses a visitor looks up. A self-operated validating node provides an independent check of accepted blocks. A missing payment should be investigated by checking the transaction identifier, the intended network and address, broadcast status, wallet synchronization, and whether a block contains the transaction. A balance shown by an exchange or custodian may instead be an entry in that operator's internal records.

Uses and limitations

People use bitcoin for direct payments, savings, and transfers through custodial or self-custody arrangements. A person may acquire it by accepting it as payment or through a seller or service; the service's identity checks, fees, payment methods, and withdrawal conditions vary. A merchant can request an on-chain payment to an address, decide when it has enough confirmations, and account for refunds separately because there is no automatic chargeback. The Bitcoin FAQ (Frequently Asked Questions) addresses common practical choices without endorsing a particular provider. The Lightning Network uses payment channels for a different payment experience; its liquidity, availability, and custody assumptions require separate consideration. Bitcoin's base layer has limited block space, so fees and confirmation delays can rise when demand is high.

Bitcoin has no official market price. Exchange quotes differ by venue, currency, and time, and market prices can change sharply. A fixed issuance schedule does not guarantee purchasing power, a stable exchange rate, or an investment return. Legal and tax treatment varies by jurisdiction and should be checked against current local primary rules rather than inferred from a general encyclopedia article.

Limits and trade-offs

Every fully validating node processes data needed to check the chain, while block space is limited. Raising throughput on the base layer can increase the resources required to validate it. Off-chain arrangements, including payment channels, change the balance of speed, cost, liquidity, and trust. Wallet providers and exchanges can simplify access but introduce their own security, privacy, and availability risks. Bitcoin does not prevent fraud by a seller, protect against a lost key, or guarantee a stable purchasing power.

Governance and development

Bitcoin software is open source. Developers can propose and publish changes, miners can choose transactions and signal preferences, and node operators decide which rule-enforcing software to run. No one participant can compel independently operated nodes to accept a rule change. Disagreements can result in incompatible chains or separate systems, as described in Bitcoin history.

Reading blockchain and market data

A reader can inspect the public record without owning bitcoin: copy a transaction identifier from a wallet into a block explorer, check the network and whether it is still pending, then open its containing block if one is shown. The transaction's inputs point to outputs from earlier transactions; its new outputs may include both the recipient's payment and change returned to the sender. The difference between input and output totals is the fee. An address page is a convenient grouping by that explorer, but a single address is not necessarily one person or one wallet. Explorer annotations and estimates should be treated separately from data actually committed to blocks.

A block explorer can help a reader follow a payment from its transaction identifier to the block that includes it. The transaction view shows inputs spent from earlier outputs, new outputs for recipients and often change, and the difference paid as a fee. The block view shows its height, previous-block reference, header hash, proof-of-work target and transaction list. The nonce is one header field miners can vary; a displayed hash proves only that the header meets the target, while a validating node also checks the block's transactions and rules. An explorer's label for a miner or address owner may be an inference rather than a fact encoded in the blockchain.

An unconfirmed transaction shown in an explorer is in that service's view of the memory pool, not in the agreed chain. Different nodes can see different pending transactions. Network charts likewise need definitions: transaction counts do not count people, addresses are not unique users, and a pool's reported hash rate is an estimate. For a price chart, check the quoted currency, exchange, time, trading volume and whether the chart uses an average; there is no protocol-defined BTC price. Historical market events belong with the dated chronology in Bitcoin history.

Acquiring and holding bitcoin

A person can receive bitcoin for goods or services, buy from a seller or exchange, trade directly with another person, or use a cash-to-bitcoin kiosk where one operates. Each route has different counterparty and custody risks. An exchange account commonly records a claim against its operator until the customer withdraws; a person-to-person trade requires particular care about payment finality and delivery; a kiosk may quote a wide spread as well as a stated fee. Availability and legal requirements depend on the place and provider. Before using any route, compare the total price and fees, payment and identity requirements, withdrawal limits, and whether the provider permits a transfer to a wallet whose keys the buyer controls. A price quote or an account balance at a provider is not the same as an on-chain payment to that wallet.

For a self-custody purchase, learn the wallet's backup and recovery procedure first, verify the receiving address and network, and check a small transfer before relying on a larger one. Protect the recovery phrase offline and never give it to a seller or support agent. Custody can reduce the work of managing keys but creates dependence on the custodian's solvency, security and withdrawal policy. When selling or spending, also check the counterparty, total conversion cost, confirmation policy and any refund arrangement. The Bitcoin FAQ (Frequently Asked Questions) covers these choices as questions; none of these steps makes a seller or investment safe by itself.

Market history and later developments

Bitcoin's market price has gone through sharp rises and falls, so a dated high or low cannot describe its current value. In the 2020–2024 price history reported by a US-listed bitcoin trust, the reference-market price reached a high above $67,000 in 2021, a low below $16,000 in 2022, and a high above $100,000 in 2024. These figures describe that filing's chosen market, dates and method, not a single worldwide Bitcoin price. A reader comparing periods should use one identified source consistently and separate observed prices from stories about what caused them. Protocol supply is only one influence: access to trading venues, liquidity, demand, expectations and wider events also matter. The launch of a financial product that tracks bitcoin can change how some people obtain price exposure without giving its share owners direct control of the bitcoin keys. In January 2024, the US Securities and Exchange Commission approved exchange listings for spot bitcoin exchange-traded products; that decision was about the listed products, not an endorsement of bitcoin or a change to Bitcoin's rules.

The system also changed after the 2008 paper. Segregated Witness (SegWit) moved signature-related data into a separately committed witness structure and changed transaction capacity accounting. Taproot introduced additional rules for spending certain outputs, including a key-path option and script-path commitments. These are protocol changes with particular compatibility and privacy properties, not promises that all payments become private or cheap. Payment channels such as the Lightning Network use the base chain for opening and closing arrangements while moving individual payments off-chain. Bitcoin history places these developments in time.

In this article, Bitcoin generally names the network and protocol; bitcoin names its unit. Both uses appear in compound names and titles, so context matters more than typography alone.

Further reading: the original white paper, the Bitcoin Developer Guide on transactions, and Bitcoin.org's getting-started guide.

See also

• Bitcoin history — development and historical events
• Bitcoin FAQ (Frequently Asked Questions) — practical answers
• Lightning Network — payment channels