Glossary
Bitcoin words, explained twice
Each term has a plain explanation anyone can follow, and a precise one for when you want the details. Links lead to the models where you can see it working.
45 terms
A
- Address
-
PlainAn address is a way to write down a spending rule so someone else can pay you.
TechnicalA human encoding (Base58Check, bech32, bech32m) of a scriptPubKey template. Addresses are a wallet convention; the chain only stores scripts.
Reference: BIP173, BIP350
Builds on: Script and spending conditions
See it in: Anatomy of a Wallet
B
- Bitcoin's history
-
PlainBitcoin began with a short paper in 2008 and a first block in January 2009, and has grown through many improvements since.
TechnicalWhitepaper (31 Oct 2008), genesis block (3 Jan 2009), soft forks such as P2SH, SegWit and Taproot, and four halvings to date.
See it in: The Bitcoin Time Machine
- Block
-
PlainA block is a page of the shared record holding a batch of payments.
TechnicalAn 80-byte header plus a transaction list whose first transaction is the coinbase. Limited to 4,000,000 weight units.
Builds on: Transaction
See it in: The Chain of Blocks
- Block header
-
PlainThe block's label: it names the previous page and seals the contents with a fingerprint.
Technicalversion, prev block hash, merkle root, time, nBits (compact target), nonce: 80 bytes, hashed with SHA-256d.
Builds on: Block, Hash function
See it in: The Chain of Blocks, The Mining Machine
- Block subsidy and halving
-
PlainMiners get newly made bitcoin for each block, and that amount halves about every four years.
TechnicalSubsidy = 50 BTC >> ⌊height / 210,000⌋ (in satoshis, with integer shifts), reaching zero after 33 halvings; total supply just under 21 M BTC.
See it in: The Bitcoin Halving Clock
C
- Chain reorganization
-
PlainSometimes nodes switch to a competing version of the latest pages because it took more work to build.
TechnicalWhen a valid branch with more cumulative work appears, nodes disconnect blocks back to the fork point and connect the new branch.
Builds on: Most accumulated work
See it in: The Bitcoin Security Arena
- Change output
-
PlainIf the piece you spend is bigger than the price, you pay yourself the difference back.
TechnicalA wallet-created output returning inputs − payment − fee to the sender. It is an ordinary output; consensus does not know it is change.
Builds on: UTXO, Transaction
See it in: The Life of a Transaction, The UTXO Machine
- Channel capacity and liquidity
-
PlainA channel's size is fixed when it opens; what each side can send is only its own share of it.
TechnicalCapacity is the funding output amount. Outbound liquidity is the local balance above the channel reserve; inbound liquidity is what the other side can send, its balance above its own reserve. A payment larger than the sender's outbound liquidity fails.
Reference: BOLT #2
Builds on: Lightning payment channels
See it in: The Lightning Channel Machine, The Lightning Routing Machine
- Child pays for parent
-
PlainA new payment can pay extra to pull its stuck parent along with it.
TechnicalMiners evaluate ancestor packages: a high-fee child raises the effective package fee rate of its low-fee parent.
See it in: The Blockspace Market
- Commitment transaction
-
PlainA signed but unpublished transaction that says how the channel's money would be split if it closed now.
TechnicalEach side holds a commitment transaction spending the 2-of-2 funding output to the current balances; every payment replaces the pair with a new state, and old states are revoked.
Reference: BOLT #3
Builds on: Lightning payment channels, Digital signature
See it in: The Lightning Security Machine, The Lightning Channel Machine
- Confirmation
-
PlainEach new page on top makes your payment harder to undo.
TechnicalDepth of the including block in the active chain. Reversal probability falls roughly exponentially with depth for an attacker below 50% hash rate.
Builds on: Block, Most accumulated work
See it in: The Life of a Transaction, The Chain of Blocks
D
- Difficulty adjustment
-
PlainEvery two weeks or so, the puzzle gets harder or easier so blocks keep coming about every ten minutes.
TechnicalEvery 2016 blocks the target is scaled by actual timespan (measured over the period's 2015 block intervals) / expected timespan (1,209,600 s), clamped to a factor of 4 either way, and capped at the proof-of-work limit (consensus).
Builds on: Proof of work
See it in: The Difficulty Engine
- Digital signature
-
PlainA signature proves the owner of the secret approved this exact message, without showing the secret.
TechnicalECDSA (legacy and SegWit v0 outputs) or BIP340 Schnorr signatures (Taproot, SegWit v1) over a sighash that commits to the transaction fields selected by the sighash type.
Reference: BIP340, BIP143, BIP341
Builds on: Public and private keys, Hash function
See it in: The Life of a Transaction, Anatomy of a Wallet, The Digital Signature Machine
- Double SHA-256 (SHA-256d)
-
PlainBitcoin often hashes data twice in a row: the fingerprint of the fingerprint.
TechnicalSHA-256d(x) = SHA-256(SHA-256(x)); used for block header hashes (proof of work), transaction ids and the Base58Check checksum. Explorers and Bitcoin Core display txids and block hashes with the bytes reversed. Hashing is not encryption: there is no key and no way to decrypt.
Reference: FIPS 180-4
Builds on: Hash function
See it in: The SHA-256 Hashing Machine
- Double-spend attack
-
PlainTrying to take back a payment by secretly building a competing history without it, one that took more work to build.
TechnicalAn attacker mines a private branch that conflicts with a payment and publishes it once it has more work, reorganizing the payment away (whitepaper §11).
Builds on: Chain reorganization, Confirmation
See it in: The Bitcoin Security Arena
F
- Fee rate
-
PlainThe fee rate is the price per unit of space, like the price per kilo at a market.
Technicalfee / vsize in sat/vB. Miners maximising revenue under the weight limit prefer higher (package) fee rates, not higher absolute fees.
Builds on: Transaction fee, Weight and virtual size
See it in: The Life of a Transaction, The Blockspace Market
- Full node
-
PlainA node is a computer that checks every rule for itself instead of trusting anyone.
TechnicalSoftware that independently validates blocks and transactions against consensus rules and applies its own relay policy.
Builds on: Transaction
See it in: The Global Bitcoin Network
H
- Hardware signing device
-
PlainA small device that keeps your secret locked inside and shows you what you are approving.
TechnicalKeys stay inside a signing boundary; the host proposes a PSBT, the device displays and signs. Security architectures vary by device.
Reference: BIP174
Builds on: Wallet, Digital signature
See it in: Anatomy of a Signing Device
- Hash function
-
PlainA hash is a fingerprint for data: change one letter and the fingerprint changes completely.
TechnicalBitcoin uses SHA-256, usually applied twice (SHA-256d), for block and transaction ids, and HASH160 (RIPEMD-160 ∘ SHA-256) for P2PKH, P2SH and P2WPKH key and script hashes (P2WSH uses a single SHA-256).
Reference: FIPS 180-4
See it in: The SHA-256 Hashing Machine, The Mining Machine
- Hashed time-locked contract (HTLC)
-
PlainA conditional payment: it can be claimed with a secret before a deadline, and otherwise returns to the sender.
TechnicalAn output payable to the recipient with the preimage of a payment hash, or back to the offerer after a time lock (CLTV). Every hop of a Lightning route uses the same payment hash, so once the receiver reveals the preimage each hop can claim its incoming HTLC; a hop that fails to claim it before its time lock expires can lose the amount it forwarded.
Reference: BOLT #2, BOLT #3
Builds on: Commitment transaction, Hash function
See it in: The Lightning Routing Machine
- Hierarchical deterministic keys
-
PlainOne seed grows a whole tree of keys, so one backup covers them all.
TechnicalBIP32 derives child keys from a parent extended key with HMAC-SHA512; hardened vs non-hardened paths; standard paths from BIP44/84/86.
Reference: BIP32, BIP44, BIP84, BIP86
Builds on: Recovery phrase, Public and private keys
See it in: The Recovery Phrase Machine
L
- Lightning payment channels
-
PlainTwo people lock bitcoin in a shared box and pass balance back and forth within seconds, settling on the chain later.
Technical2-of-2 funding outputs with revocable commitment transactions; payments route across channels via HTLCs.
Builds on: Multisignature, Transaction
See it in: The Lightning Channel Machine
- Lightning routing
-
PlainPaying someone through a chain of channels, with each person in between passing the payment on for a small fee.
TechnicalSource-based routing over the public channel graph: the sender picks a route using capacities and fee policies but not the private liquidity split, computes hop amounts backwards (base + proportional fees), and retries other routes when a hop fails.
Reference: BOLT #4, BOLT #7
Builds on: Channel capacity and liquidity, Hashed time-locked contract (HTLC)
See it in: The Lightning Routing Machine
M
- Mempool
-
PlainThe waiting room where valid payments sit until a miner picks them up.
TechnicalEach node's own set of unconfirmed transactions it accepted under its policy. Mempools differ between nodes.
Builds on: Full node, Transaction
See it in: The Life of a Transaction, The Blockspace Market
- Merkle tree
-
PlainFingerprints of fingerprints, folded down to one that seals every payment in the block.
TechnicalA binary SHA-256d tree over txids (a level with an odd number of hashes duplicates its last one); its root is committed in the header. Enables compact inclusion proofs.
Builds on: Hash function, Block
See it in: The Chain of Blocks
- Mining
-
PlainMining is the race to find the winning guess that lets you add the next page.
TechnicalBuilding a block template, then searching nonce, timestamp and extranonce space for a header hash at or below the target. The winner claims subsidy + fees.
Builds on: Proof of work, Mempool
See it in: The Mining Machine
- Monetary policy
-
PlainThe rules for how new money is created: decided by people in most systems; in Bitcoin, set by rules every node enforces, which could change only with broad agreement.
TechnicalDiscretionary central-bank and banking-system money creation versus Bitcoin's consensus-enforced subsidy schedule.
Builds on: Block subsidy and halving
See it in: The Monetary Systems Machine
- Money supply versus prices
-
PlainMore money does not always mean higher prices right away; prices also depend on how much people make and want to hold.
TechnicalMoney supply growth and consumer price inflation are distinct measures; their relation depends on output, velocity and money demand.
Builds on: Monetary policy
See it in: The Monetary Systems Machine
- Most accumulated work
-
PlainNodes follow the chain that took the most total effort to build, not simply the longest one.
TechnicalThe active chain is the valid chain with the greatest cumulative work, Σ 2^256 / (target + 1). Length and work differ when difficulty differs.
Builds on: Proof of work, Difficulty adjustment
See it in: The Chain of Blocks
- Multisignature
-
PlainA vault that needs, say, two keys out of three before it opens.
TechnicalA script policy requiring m-of-n signatures: OP_CHECKMULTISIG in legacy and SegWit v0 scripts, OP_CHECKSIGADD in Taproot scripts (BIP342). Key-aggregation and threshold schemes such as MuSig2 (n-of-n) or the emerging FROST instead produce one signature that looks like a single-key spend.
Builds on: Script and spending conditions, Digital signature
See it in: The Multisignature Vault
O
- Output descriptors
-
PlainA written recipe of which keys and rules make up a wallet, needed to rebuild a shared vault.
TechnicalA language describing output script templates and key origins (e.g. wsh(sortedmulti(2,…))). Multisig recovery needs the descriptor, not just the seeds.
Reference: BIP380, BIP383
Builds on: Script and spending conditions, Hierarchical deterministic keys
See it in: The Multisignature Vault
P
- Peer-to-peer network
-
PlainNodes pass new transactions and blocks to their neighbours, like a rumour spreading through a town.
TechnicalGossip-based relay over the Bitcoin P2P protocol (inv/getdata, compact blocks BIP152). There is no central server or global mempool.
Builds on: Full node
See it in: The Global Bitcoin Network
- Proof of work
-
PlainMiners guess numbers over and over until one makes a fingerprint small enough; it is hard to find and easy to check.
TechnicalA header is valid only if SHA-256d(header), read as a 256-bit little-endian integer, is ≤ the target encoded in nBits.
Builds on: Block header
See it in: The Mining Machine
- Public and private keys
-
PlainA private key is a secret only you know; the public key is a lock anyone can see that only your secret fits.
Technicalsecp256k1 elliptic-curve key pairs: the public key P = k·G is easy to compute from the private scalar k, and infeasible to invert.
See it in: Anatomy of a Wallet, The Digital Signature Machine
R
- Recovery phrase
-
PlainA list of words that can rebuild every key in your wallet; whoever has it has your bitcoin.
TechnicalBIP39: entropy + SHA-256 checksum bits encoded as 12–24 words; PBKDF2-HMAC-SHA512 (2048 rounds, salt "mnemonic" + passphrase) yields the 512-bit seed.
Reference: BIP39
Builds on: Hash function, Wallet
See it in: The Recovery Phrase Machine
- Replace-by-fee
-
PlainMost nodes let you swap a waiting payment for a new version that pays a higher fee.
TechnicalA policy rule (BIP125 and its successors in Bitcoin Core) letting a conflicting transaction replace mempool entries if it pays more in absolute fee and fee rate. Since Bitcoin Core 28.0 any unconfirmed transaction can be replaced this way by default (full RBF); the replacement must also pay for its own relay at the incremental relay fee.
Reference: BIP125
See it in: The Blockspace Market
- Revocation and penalty
-
PlainOld channel agreements are cancelled by handing over a secret; anyone who tries to use a cancelled one loses everything they had in the channel to the other side.
TechnicalLN-penalty: updating a channel revokes the previous commitment by revealing its per-commitment secret. If a revoked commitment is broadcast, the counterparty can spend the broadcaster's delayed to_local output with the revocation key before to_self_delay expires.
Reference: BOLT #2, BOLT #3
Builds on: Commitment transaction
See it in: The Lightning Security Machine
S
- Satoshi
-
PlainA satoshi is the smallest piece of a bitcoin; one bitcoin is 100 million of them.
TechnicalThe base unit of account: 1 BTC = 100,000,000 sat. All consensus amounts are integer satoshis (int64); each must lie between 0 and MAX_MONEY (21,000,000 BTC), a sanity bound. The actual supply is set by the subsidy schedule (just under 21 million BTC).
- Script and spending conditions
-
PlainEvery piece of bitcoin carries a small rule that says what proof is needed to spend it.
TechnicalscriptPubKey defines the condition; scriptSig/witness satisfies it. Standard templates: P2PKH, P2SH, P2WPKH, P2WSH, P2TR.
Builds on: UTXO, Digital signature
See it in: Anatomy of a Wallet
T
- Transaction
-
PlainA transaction takes some pieces of bitcoin and makes new pieces for the people being paid.
TechnicalA signed data structure of inputs (outpoints + unlocking data) and outputs (amount + scriptPubKey); valid only if inputs exist, are unspent and scripts succeed.
Builds on: UTXO, Digital signature
See it in: The Life of a Transaction
- Transaction fee
-
PlainThe fee is the small amount left over that goes to whoever adds your payment to the record.
TechnicalImplicit: sum(inputs) − sum(outputs). Consensus requires it to be ≥ 0; the miner of the including block may claim it in the coinbase.
Builds on: Transaction
See it in: The Life of a Transaction, The UTXO Machine
U
- UTXO
-
PlainYour bitcoin is a set of separate pieces, like notes in a wallet; each piece is spent whole.
TechnicalAn unspent transaction output: an amount plus a locking script (scriptPubKey). Inputs reference outputs by outpoint (txid:vout) and must spend them entirely.
Builds on: Satoshi
See it in: The UTXO Machine
W
- Wallet
-
PlainA wallet does not hold coins; it holds the secrets that let you spend them.
TechnicalSoftware managing keys, scripts/descriptors, UTXO tracking, coin selection, fee estimation and signing. The coins are entries on the chain.
Builds on: Public and private keys, UTXO
See it in: Anatomy of a Wallet
- Watchtower
-
PlainA helper that watches the blockchain while you are offline and can punish someone who publishes an old channel state on your behalf.
TechnicalA third party holding (typically encrypted) justice-transaction data for revoked states; it can only act if it is online, detects the breach and confirms its transaction before the delay runs out. Optional, with its own trust and availability assumptions.
Builds on: Revocation and penalty
See it in: The Lightning Security Machine
- Weight and virtual size
-
PlainBigger transactions take more room in a block, so they pay more for the same speed.
TechnicalWeight = 3 × base size + total size (BIP141); vsize = ⌈weight / 4⌉ vbytes. Blocks are limited to 4,000,000 weight units (consensus).
Reference: BIP141
Builds on: Transaction
See it in: The Life of a Transaction, The UTXO Machine, The Blockspace Market
No term matches. Try a shorter word.