Bitcoin

In brief

Bitcoin is a peer-to-peer electronic cash system proposed in 2008 by the pseudonymous Satoshi Nakamoto and brought online in 2009. The whitepaper’s goal is online payments without a financial institution as a trusted third party, using digital signatures plus a proof-of-work chain to order transactions and resist double-spending. Coins are tracked as unspent transaction outputs, not as account balances. Miners assemble transactions into blocks, targeting one block about every ten minutes; the block subsidy started at 50 bitcoin and halves every 210,000 blocks, so issuance approaches a little under 21 million. Full nodes enforce the rules. Settlement is probabilistic: more confirmations make a reversal harder, not metaphysically impossible. Bitcoin is a specialized monetary network with a limited scripting language. It is not a general-purpose application platform, and other blockchains do not all work the same way.

Historical motivation and the 2008 paper

On 31 October 2008, Satoshi Nakamoto wrote to the Cryptography Mailing List: “I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party,” and pointed to a paper titled Bitcoin: A Peer-to-Peer Electronic Cash System.

The paper’s abstract states the aim directly. A purely peer-to-peer version of electronic cash would allow online payments from one party to another without a financial institution. Digital signatures solve ownership, but not double-spending, if a mint must still approve every spend. The proposed fix is a peer-to-peer timestamp network that hashes transactions into an ongoing chain of proof-of-work.

The introduction describes internet commerce as relying on financial institutions to process payments, mediate disputes and reverse charges. That model, Nakamoto argues, raises costs, blocks very small payments, and prevents truly non-reversible transfers. The alternative is cryptographic proof instead of institutional trust.

The author’s identity is unknown. This article does not speculate about it.

2009 launch

The first Bitcoin block — the genesis block, numbered 0 in modern software — carries timestamp nTime = 1231006505, which is 3 January 2009. Its coinbase includes the text “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” The Bitcoin Wiki treats that headline as evidence the block was created on or after that date, and as a comment on the banking crisis then in the news. The 50-bitcoin subsidy in that block is unspendable because of how the genesis transaction is handled in the reference software.

The next block arrived days later. Bitcoin’s blockchain has continued from that genesis block, with nodes independently validating its accumulated history.

What Bitcoin set out to do — and what it does not

Bitcoin’s original objective is electronic cash: transfer of a native asset (later called BTC) between keys, without a central operator, with public verification and costly reversal of recent history.

It does not try to be a general-purpose computer. Bitcoin Script is a limited, non-Turing-complete language for spending conditions, not a general application platform. Those limits are choices. Bitcoin can do payments, simple scripts such as multisignature spends, and later upgrades such as SegWit and Taproot. It does not host arbitrary smart-contract applications of the kind later platforms built around a virtual machine.

Other blockchains reuse some of these ideas and discard others. Proof-of-work, a 10-minute block time, UTXOs and a 21 million issuance cap are Bitcoin properties, not universal blockchain properties.

How value moves: transactions and UTXOs

The whitepaper defines an electronic coin as a chain of digital signatures. An owner spends by signing a hash of the previous transaction and the next owner’s public key. In today’s language, bitcoin lives in unspent transaction outputs (UTXOs). The 2008 paper does not use that acronym; it describes the same structure in the section on combining and splitting value. Transactions have inputs that consume earlier outputs and new outputs that create spendable amounts, typically a payment and optional change.

A node accepts a spend only if each referenced output is present and unspent in its UTXO set, the input data satisfies that output's spending conditions, and the input amounts cover the outputs. The difference, if any, is a transaction fee.

Authorization is a script check, not a property of an address string. Each output carries spending conditions (a pubkey script). A later input provides data that must satisfy those conditions. In the classic pay-to-public-key-hash (P2PKH) case, the spender reveals a public key that hashes to the expected value and a signature that verifies against that public key. The address is only a convenient encoding of that hash for receiving; it is not itself a cryptographic object that verifies a signature. Newer output types — P2SH, SegWit and Taproot among them — use different scripts and witness data. Multisignature and other scripted outputs can require more than one key.

Blocks, mining and proof of work

Nodes collect valid transactions into a block. A block contains a header (previous block hash, Merkle root of the transactions, timestamp, nonce and compactly encoded proof-of-work target) and the transaction list. The first transaction is the coinbase, which pays the miner the block subsidy plus fees.

Mining is the search through nonce values and other changeable block data for a block hash that meets the current target. The whitepaper describes proof-of-work in the style of Adam Back’s Hashcash: find a hash with enough leading zero bits. Once found, changing the block means redoing that work, and changing an old block means redoing every block after it.

The whitepaper’s network loop is:

1. New transactions are broadcast.
2. Each node collects them into a block.
3. Each node works on a difficult proof-of-work.
4. A successful node broadcasts the block.
5. Other nodes accept it if all transactions are valid and unspent.
6. They express acceptance by mining on top of it.

Proof-of-work also assigns weight in a disagreement. The paper calls this “one-CPU-one-vote.” Honest majority hash rate is assumed to grow the heaviest valid chain faster than an attacker.

Consensus, full nodes and the chain

Consensus here means independent programs enforcing the same rules and choosing the same chain tip, not a vote by a company board. Full nodes download and verify blocks and transactions against those rules. They do not have to mine. Lightweight clients can check proof-of-work headers and Merkle proofs, as the whitepaper’s simplified payment verification section describes, at the cost of trusting that honest nodes dominate mining.

Nodes follow the valid chain with the most accumulated proof-of-work. If two blocks appear at once, nodes may temporarily see competing branches; once one has more accumulated work, the other is abandoned. That short reorganization is normal. A deep reorganization is possible in principle if a large share of hash rate works on a competing history; it becomes rapidly more expensive as blocks accumulate.

Published history is expensive to rewrite, not magically unalterable. Bonneau et al. describe Bitcoin’s consensus as a decentralized protocol in which parties add blocks of valid transactions; conflicting views of the chain are resolved by accumulated proof-of-work, not by a trusted operator who could freeze or rewrite spends. That resistance, plus social refusal to change the rules to bail out a particular spend, is what people loosely call immutability.

Issuance, the 21 million cap and halvings

New bitcoin enters circulation as the miner subsidy. The Bitcoin Wiki’s controlled-supply page states the rule: the subsidy decreases geometrically, with a 50% reduction every 210,000 blocks (about four years at the target rate). The first era paid 50 BTC per block. Later eras pay 25, 12.5, 6.25, 3.125, and so on, until the subsidy falls below one satoshi.

The number of bitcoins “will not exceed slightly less than 21 million.” Integer rounding and some historical underpaid coinbases mean the actual ceiling is a little under that round figure. Lost coins are not reissued.

The whitepaper already said that once a predetermined number of coins have entered circulation, the incentive can move to transaction fees alone. Fees are the difference between input and output amounts, collected by the miner of the including block.

Difficulty adjustment

The whitepaper says difficulty is a moving average targeting a constant block rate. The implemented rule, documented on the Bitcoin Wiki, retargets every 2,016 blocks. At one block per 10 minutes, that interval is two weeks. If the previous 2,016 blocks arrived too quickly, difficulty rises; if too slowly, it falls, in proportion to the miss. The target average remains about six blocks per hour.

Individual blocks are not clockwork. Confirmation times follow a random process around that average. The Wiki notes that a given 10-minute window has only about a 63% chance of containing a block.

Confirmations, reorganizations and probabilistic settlement

A transaction in the mempool has zero confirmations. Inclusion in a block is the first confirmation; each block after that adds one. bitcoin.org warns that unconfirmed transactions are not secure and that confirmations make reversal harder rather than instantly impossible. Its table treats six confirmations as a common minimum for high-value transfers, while noting that lightweight wallets and full nodes see risk differently.

The whitepaper’s calculations show an attacker’s chance of catching up from z blocks behind falling exponentially if honest hash rate leads. Six is a convention from those assumptions, not a protocol constant. The Bitcoin Wiki emphasizes that six is arbitrary: overkill against a small attacker, insufficient against a very large one.

This is probabilistic settlement. Bitcoin does not have the economic finality gadget used by some proof-of-stake systems, where reverting a finalized checkpoint would require burning a large fraction of stake. A Bitcoin reorganization is always a question of hash rate, time and what nodes will accept.

SegWit and Taproot

Two later soft forks extended what scripts and addresses can do without replacing the system.

Segregated Witness (BIP-141) moves signatures and scripts into a separate witness structure. That fixes involuntary transaction malleability for transactions whose inputs use SegWit (the txid excludes the witness), enables cleaner off-chain protocols, and defines block weight so witness data is discounted relative to base data. It was assigned in December 2015, deployed through BIP9, and activated on mainnet at block 481,824 on 24 August 2017.

Taproot (BIP-341) adds SegWit version 1 outputs that combine a public key with an optional Merkle tree of scripts. A key-path spend looks like a single Schnorr signature. A script-path spend reveals only the branch that was actually used. BIP-341 states that the mainnet deployment activated at height 709,632. The motivation is privacy, efficiency and flexibility for complex spends, including multisig, without new cryptographic assumptions beyond those already used.

Neither upgrade turned Bitcoin into a general smart-contract chain. Both remain optional output types alongside older ones.

Decentralization is several questions

It is not a single score.

• Validation: anyone can run a full node and reject invalid blocks.
• Block production: anyone may mine, but hash rate has concentrated in pools and specialized hardware.
• Development: changes are proposed as Bitcoin Improvement Proposals and adopted only if implementations and operators run them. There is no CEO.
• Economic: coins, nodes and miners are distributed across many holders, with large holders and large miners still mattering.

A network can be easy to join as a node and still have concentrated mining. Those facts can be true at the same time.