Bitcoin glossary

Every term you'll meet in the Bitcoin world — defined plainly, with sources where they matter.

A

address noun §

A short string encoding the conditions under which a UTXO can be spent — usually “the holder of the private key for this public key.” Addresses are not accounts. They’re one-time-use destination strings that anyone can generate without contacting the network.

Bitcoin has several address formats in active use: P2PKH (legacy, starts with 1), P2SH (starts with 3, often wraps SegWit or multisig), native SegWit / bech32 (starts with bc1q, cheaper fees), and Taproot / P2TR (starts with bc1p, supports advanced scripts and Schnorr signatures).

Privacy best practice: never reuse an address. Modern wallets generate a fresh address for every receive. Reuse links your transactions together publicly on chain, defeating the pseudonymity property. The protocol allows reuse; that doesn’t mean you should.

See also: Address Validator · Address lookup

ASIC abbreviation §

A purpose-built chip that does exactly one thing: compute SHA-256 as fast and as efficiently as silicon allows. Bitcoin mining has been ASIC-dominated since 2013, when the Avalon and ASICMiner devices made GPUs and FPGAs economically obsolete overnight. A modern Antminer S21 Pro pushes ~234 TH/s at ~15 J/TH — five orders of magnitude better than the CPU mining of 2009.

The ASIC ecosystem is heavily concentrated (Bitmain, MicroBT, Canaan), which draws hand-wringing about supply-chain risk. The counter-argument: making a custom chip that beats incumbents is just an engineering problem with public specs, and as long as the incentive exists, capital chases it.

ASICs are also why Bitcoin’s energy use is not wasted: the chips and electricity are sunk into securing the largest digital settlement system ever built, with no general-purpose alternative use.

See also: Mining profitability · Mining stats

B

BIP abbreviation §

A Bitcoin Improvement Proposal — the document format and process for proposing changes to Bitcoin. Modeled on Python’s PEPs and Ethereum’s later EIPs, BIPs come in three flavours: Standards Track (consensus or peer-protocol changes that all nodes need to agree on), Informational (notes, conventions), and Process (changes to the BIP process itself).

A BIP author writes a draft, opens a PR to github.com/bitcoin/bips, and discusses on the bitcoin-dev mailing list. Reaching Final status takes years and requires both rough consensus among reviewers and deployment by users. Most BIPs that affect consensus also need a soft-fork to actually activate.

Famous BIPs you’ll meet daily: BIP-32 (HD wallets), BIP-39 (seed phrases), BIP-141 (SegWit), BIP-340/341/342 (Taproot). The full index is the canonical map of Bitcoin’s structural choices.

Related: bip32, bip39, bip44, bip84, soft fork, consensus

See also: Hardware wallet setup

BIP-39 abbreviation /bip thirty-nine/ §

Bitcoin Improvement Proposal 39, by Marek Palatinus and others (2013). It specifies how to convert a list of human-readable English words into the binary seed used by an HD wallet. The full text lives in the BIPs repository.

The pipeline: take 128 to 256 bits of randomness, append a small SHA-256 checksum, split the result into 11-bit chunks, and look each chunk up in the 2,048-word English wordlist. Optional translations exist for Japanese, Spanish, French, Chinese, Italian, Korean, Czech, and Portuguese.

The seed itself is then derived by PBKDF2(mnemonic + "mnemonic" + passphrase, HMAC-SHA512, 2048 rounds). The optional passphrase, sometimes called the “25th word,” produces a different seed for each different passphrase value. Same 24 words plus passphrase A and passphrase B yield two distinct wallets, each with no on-chain link to the other.

See also: Address Validator

BIP-84 abbreviation /bip eighty-four/ §

The derivation path standard for native SegWit (P2WPKH, bc1q...) addresses, specified in BIP-84. Uses the same five-level path as BIP-44 but with purpose 84' instead of 44': m/84'/0'/0'/0/0 is the first receive address of the first Bitcoin account on a native SegWit wallet.

Native SegWit lowers transaction fees because witness data is discounted to a quarter of its raw weight. A typical P2WPKH spend is about 30% cheaper than the equivalent legacy P2PKH spend, more if you’re consolidating many inputs.

For a few years (2018–2022) most modern wallets defaulted to BIP-84. New wallets are increasingly defaulting to BIP-86 (Taproot) for the further fee savings and privacy benefits, but BIP-84 remains the universally supported native SegWit standard — when you import a 24-word seed and the wallet generates bc1q addresses, that’s BIP-84 doing the work.

See also: Address Validator

Bitcoin noun /bit-koyn/ §

A peer-to-peer digital cash system, introduced by Satoshi Nakamoto in the 2008 whitepaper and launched on January 3, 2009. Bitcoin is two things at once: a fixed-supply monetary asset (capped at 21 million coins, minted on a predictable schedule) and the open network of nodes that enforces those rules without any central operator.

Capital-B “Bitcoin” usually refers to the protocol and network. Lower-case “bitcoin” or the ticker BTC refers to the unit of account. The smallest unit is the satoshi: 1 BTC = 100,000,000 sats.

Bitcoin’s defining feature is verifiability. You don’t trust me, the developers, or any exchange — you run a node, replay every block from genesis, and confirm the rules for yourself. That property is the entire point.

block noun §

A batched container of Bitcoin transactions plus an 80-byte header. Blocks are mined roughly every 10 minutes on average, capped at about 4 million weight units (~1.5–2 MB in practice depending on transaction mix).

Every block has exactly one coinbase transaction (the one that pays the miner) followed by zero or more user transactions the miner chose to include from their mempool. The header contains six fields: version, previous block hash, merkle root, timestamp, difficulty target, and nonce.

The 10-minute target is enforced by difficulty adjustment every 2,016 blocks, but real intervals are memoryless — sometimes two blocks arrive within a minute, sometimes 40 minutes pass. That irregularity isn’t a bug; it’s the statistical signature of an honest Poisson-like process.

See also: Bitcoin blocks · Block lookup

block reward noun §

The total amount a miner earns for finding a block: the block subsidy (brand-new bitcoin minted by the protocol) plus all the transaction fees in the block. The miner receives this through the special first transaction in each block, called the coinbase transaction.

Today subsidy still dominates fees most of the time, but every halving shifts the balance further toward fee revenue. By the late 2030s, fees become the structural majority. By 2140, the subsidy is exactly zero and miners are paid entirely by users bidding for blockspace.

This is the security budget problem stated honestly: total miner revenue must stay high enough to make 51% attacks unprofitable. Whether fees alone will cover that is one of Bitcoin’s great open questions.

Related: coinbase tx, subsidy, fee, halving

C

change output noun §

When you spend a UTXO worth more than the amount you’re sending, the “leftover” goes back to you in a new UTXO called the change output. Bitcoin transactions don’t have partial spends — you consume an entire UTXO and create new ones. Change is just one of those new outputs, addressed back to your own wallet.

A naive wallet would send change to the same address you spent from. Don’t do that — it links the addresses publicly. Modern wallets generate change addresses on the change branch of the BIP-32 derivation path (m/.../1/n rather than m/.../0/n), keeping receive and change addresses in separate streams.

Privacy attackers analyze transactions trying to guess which output is the payment and which is the change. The “round-number heuristic” — a 0.05 BTC output and a 0.0317 BTC output, the round one is probably the payment — is one of the most common attacks. Sending round-number changes (coinjoin amounts) and using the same address type for payment and change helps muddy the analysis.

See also: Address Validator

channel noun §

A 2-of-2 multisig funded by two parties on the Bitcoin base layer that lets them pay each other off-chain. Each off-chain update is a fully-signed transaction the receiver could broadcast at any moment to claim their current balance — but they don’t, because the next update will pay them slightly more.

Channel capacity is the total funding (sender’s local balance + receiver’s remote balance). Outbound liquidity is what you can send; inbound is what you can receive. Mismatches cause “I can’t receive any more” errors that kneecap small Lightning users until they understand channel rebalancing.

Closing a channel writes the final balance to the chain. Cooperative close is cheap and instant; force-close fees include time-locks and a CSV delay so the counterparty has time to dispute a stale state. That delay is when watchtowers earn their keep.

coinbase transaction noun §

The first transaction in every block, paying the miner. Unlike all other transactions, the coinbase has no real input — it points to a special “null” prior transaction and creates new bitcoin out of thin air, up to the current subsidy plus the sum of fees in the block.

The output(s) of a coinbase transaction can pay anywhere — usually a mining pool, which then redistributes proportionally to its hashpower contributors via off-chain payouts. The pool’s coinbase address is what explorers display as the “miner” of a given block.

Coinbase outputs have a special rule: they can’t be spent until 100 blocks have been built on top of them. This coinbase maturity protects against short reorganizations from accidentally letting double-spends survive. The 100-block buffer (~16 hours) is overkill for any normal reorg and deliberately conservative.

Don’t confuse this with Coinbase the exchange. The terms are unrelated — coinbase transaction is from the original whitepaper and predates the company by years.

Related: block, block reward, subsidy, halving, fee

See also: Bitcoin blocks

cold storage noun §

Storing private keys on a device that has never been, and ideally will never be, connected to the internet. The strict version means an air-gapped hardware wallet, signing transactions via QR codes or microSD card transfer to a separate online machine.

Cold storage isn’t binary — it’s a spectrum. A Ledger plugged into your laptop daily is “cold-ish.” A Coldcard that talks only via SD card to a networked computer is “colder.” A multisig where keys live on three different devices in three different physical locations and have never been online is “deeply cold.” Each step trades convenience for security.

For amounts you cannot afford to lose, cold is the right answer. The mental model: assume every internet-facing device you own is compromised. Your cold storage should still survive that assumption. The whole point of self-custody is that your security doesn’t depend on any single device or person staying honest.

See also: Self-custody basics

consensus noun §

The set of rules every Bitcoin full node enforces about what counts as a valid block and a valid transaction. The 21M cap, the halving schedule, the script rules, the signature checks — all consensus. Two nodes running the same consensus rules will always agree on whether any given block is valid; that agreement, replicated across thousands of independent nodes, is what makes Bitcoin a single coherent ledger.

Consensus changes are how Bitcoin evolves, and they’re hard on purpose. Tightening consensus is a soft-fork; loosening or contradicting it is a hard-fork. The bar for consensus changes is very high — typically years of review, multiple independent implementations, and broad deployment before activation.

The phrase “Bitcoin’s consensus” sometimes also means the rough social agreement among developers, businesses, and users about which proposals are reasonable. That informal layer is messier — call it Bitcoin politics — and it gates which changes ever make it to consensus-rule status.

Related: soft fork, hard fork, uasf, full node, bip

D

DCA abbreviation §

Buying a fixed dollar amount of an asset on a fixed schedule, regardless of price. Instead of trying to time entries, you spread purchases over time so your average cost trends toward the asset’s average price across that window. Bad weeks buy more units; good weeks buy fewer.

For a long-trending asset, DCA underperforms a perfect-timing lump-sum but beats every realistic timing strategy because nobody has perfect timing. The bigger value is psychological: it’s a system you can follow when you’re panicking, doubting, or distracted, and the historical Bitcoin DCA results have been outstanding from any 4+ year window.

DCA is the most boring strategy in Bitcoin and the only one I unironically recommend to friends without conviction. Run the calculator on your own start date — it’s an interesting reality check.

Related: stack sats, hodl, market cap

See also: DCA calculator · Stacking plan

derivation path noun §

A string like m/84'/0'/0'/0/5 that specifies how to navigate from the master seed of an HD wallet to a particular keypair. The slashes are tree levels, the apostrophe means hardened derivation, and the numbers are child indices.

Every receive and change address in your wallet has a unique derivation path. The wallet starts from the master node m, applies BIP-32 child derivation at each level, and ends up at a specific private key. Same seed, same path, same key — anywhere, on any compatible wallet.

The first three levels — purpose'/coin_type'/account' — are universally hardened by convention. The last two — change/index — are unhardened so that an extended public key (xpub) at the account level can derive every receive and change address in watch-only mode. That’s how block explorers or budgeting tools can show your balance without ever seeing private keys.

Related: bip32, bip44, bip84, hd wallet, descriptor

See also: Hardware wallet setup

descriptor noun §

A precise, machine-readable string that describes the entire spending policy of a wallet — which keys, in which combination, with which script template. Introduced in Bitcoin Core to replace the brittle, ambiguous “import a key, hope it works” model.

A simple example: wpkh([d34db33f/84'/0'/0']xpub.../0/*) describes a native SegWit single-sig wallet rooted at a specific derivation path. A multisig descriptor wraps a multi(...) or sortedmulti(...) policy with the participants’ xpubs and a threshold.

Descriptors solve a real interoperability headache. Before them, every wallet had its own quirks for how it handled BIP-32 paths, address types, and multisig key ordering. Two wallets thinking they were importing the same multisig would disagree on addresses. Descriptors make the whole spec explicit — same descriptor, same wallet, on any compatible software.

See also: Hardware wallet setup

difficulty noun §

A network-wide parameter that sets how rare a valid block hash must be. The target is a 256-bit number; a header is valid if its hash is below the target. Difficulty is just the inverse, normalized to the easiest-ever target from the genesis era — so a difficulty of 100T means it’s 100 trillion times harder than mining the first block.

Bitcoin auto-adjusts difficulty every 2016 blocks (≈2 weeks) to keep the average block interval at 10 minutes regardless of how much hashrate has joined or left. If miners produced the last 2016 blocks faster than 2 weeks, difficulty rises; slower, it falls. The clamp is ±300% per retarget.

This negative feedback loop is what makes Bitcoin’s issuance schedule unforgeable. You can throw any amount of energy at the network — block time stays the same, supply still halves on schedule.

Related: proof of work, hashrate, retarget, block

See also: Difficulty stats · Halving stats

double SHA-256 noun §

SHA256(SHA256(input)) — apply the SHA-256 hash function twice, feeding the output of the first round into the second. Bitcoin uses this composition almost everywhere a hash appears: block headers, transaction IDs, merkle tree internal nodes.

The motivation, as best anyone can tell from the early Bitcointalk archives, was defense in depth against length-extension attacks against the Merkle– Damgård construction that SHA-256 is built on. With double-hashing, even if SHA-256 had subtle weaknesses, the second pass forces an attacker to control the digest output of the first pass, which is much harder.

Mining is the most visible consumer of double SHA-256. Every hash attempt is two SHA-256 invocations chained back-to-back. Modern ASICs implement the pair as a single highly-optimized hardware pipeline. The “5 × 10^20 hashes per second” headline number actually represents 10^21 SHA-256 operations.

Related: sha 256, hash, proof of work, block

See also: Bitcoin blocks

E

ECDSA abbreviation /ee-see-dee-ess-ay/ §

The signature algorithm Bitcoin used exclusively from launch in 2009 until the Taproot soft fork in 2021. ECDSA over the secp256k1 curve produces roughly 71-byte signatures and is widely deployed across the internet (TLS, SSH, smart cards).

ECDSA is fine — battle-tested, well-understood, no known practical breaks on secp256k1 — but it has rough edges: signatures are malleable (the same signature can be tweaked to a valid alternate form, which created historical headaches before SegWit fixed the txid commitment), and they don’t aggregate cleanly. Multisig requires N separate signatures, all sitting in the witness.

Schnorr signatures, enabled by Taproot, address both pain points and are slightly shorter. New Bitcoin wallets sign with Schnorr by default for P2TR outputs, while ECDSA remains valid for legacy and SegWit v0 spends indefinitely — backward compatibility is forever in Bitcoin.

Related: signature, public key, schnorr, taproot

See also: Self-custody basics

F

fee noun §

The difference between the sum of a transaction’s input values and the sum of its output values. Whatever’s left goes to whichever miner includes the transaction in a block. There’s no fee field in the transaction — fees are implicit, computed from the value gap.

Fees are paid in satoshis and quoted in sat per virtual byte (sat/vB). A 200-vbyte transaction at 50 sat/vB pays a 10,000-sat fee. Wallets estimate the going rate from current mempool conditions, usually offering “fast / medium / slow” tiers corresponding to next-block, ~3-block, and ~6-block confirmation expectations.

Fees are the long-term security model. As the block subsidy halves every four years and trends toward zero around 2140, fees become the primary incentive for miners to keep hashing. A healthy fee market — non-zero, volatile, demand-driven — is what eventually sustains the network without new issuance.

Related: sat per vbyte, mempool, rbf, cpfp, virtual byte

G

gossip noun §

The peer-to-peer messaging pattern Bitcoin uses to spread information without central servers. Every node forwards new transactions and blocks to its peers, who forward to theirs, until the entire reachable network has seen them.

Bitcoin uses a flood-fill gossip variant. To prevent loops and waste, nodes first announce a transaction by ID (inv message); peers reply asking for the full body (getdata) only if they don’t have it yet. This way each transaction hits each link in the network roughly once.

The Lightning Network uses a different gossip layer for channel and node announcements, separate from the main chain gossip. Both share a key property: there’s no privileged broadcast point. Take down half the nodes on the planet and the other half keeps gossiping.

Related: node, peer, propagation, mempool

H

halving noun §

Every 210,000 blocks (≈4 years) Bitcoin’s block subsidy is cut in half. We’ve had four halvings: 50 BTC → 25 (Nov 2012), 12.5 (Jul 2016), 6.25 (May 2020), 3.125 (Apr 2024). The next halving in 2028 takes it to 1.5625 BTC. By the year 2140 the subsidy rounds to zero and the cap of 21,000,000 BTC is hit.

This pre-programmed disinflation is why Bitcoin is the first asset humans have ever owned with a known, enforced supply schedule — no central banker can pivot, no chairman can ease, no committee can override. The schedule is checked by every node every block.

Halvings have historically led the largest price runs in Bitcoin’s life (2013, 2017, 2021, 2024) but the timing is correlation, not causation — the issuance change is small at this point compared to total existing supply. Don’t trust narratives, verify the math.

Related: block reward, subsidy, satoshi

See also: Hardware wallet setup

HODL verb §

Originally a typo for “hold” in a famous 2013 BitcoinTalk forum post titled “I AM HODLING,” HODL has become Bitcoin culture’s shorthand for long-term conviction holding through volatility. Sometimes retroactively backronymed as “Hold On for Dear Life,” but the typo is the canon.

The HODL ethos: don’t trade. Don’t try to time tops and bottoms. Buy what you can afford to lose, take it off exchanges into your own custody, and ignore the price for years. The historical track record of this strategy versus active trading is uncomfortably one-sided in HODL’s favour.

The cultural counterpart is the HODLer’s contempt for “have-funs-staying-poor” trading-meta noise. Whether that’s wisdom or just confirmation-bias depends on whether the next decade plays out like the last four. We’re betting it will.

Related: stack sats, dca, btc, sat

See also: Self-custody basics

HTLC abbreviation §

The atomic primitive that lets a multi-hop Lightning payment either succeed all the way or fail back to the sender — never get stuck in the middle.

The mechanism: the recipient picks a random secret R and shares hash(R) with the sender. The sender constructs a payment that is “redeemable by the holder of R if claimed within N blocks, otherwise refunded to me”. Each forwarder along the route locks up the same hash with a slightly shorter timeout. When the recipient reveals R to the last forwarder, every hop unwinds, each claiming their amount with the same secret. If anything fails, the time-lock branch refunds.

HTLCs are the reason Lightning works as a network and not just as a chain of trustful relationships. Recent protocol work (PTLCs via Schnorr/MuSig2) upgrades them to leak less metadata and route more efficiently.

I

input noun §

A reference to an existing UTXO that a transaction is consuming, plus the witness data (signature) that authorizes the spend. Every non-coinbase transaction has at least one input.

The structure: a 32-byte transaction ID pointing to the prior output, a 4-byte output index, and the unlocking script or witness. The witness proves you satisfy the spending conditions of the referenced UTXO — usually “you hold the private key for this public key.”

Input count drives transaction size, which drives fees. Consolidating ten small UTXOs into one big one in a single transaction is much cheaper during low-fee periods than carrying them around forever, paying the overhead on every future spend. UTXO management is a real ongoing chore for wallets — it’s worth thinking about, especially before high-fee periods like halvings or NFT-driven mempool spikes.

Related: output, utxo, signature, transaction

L

legacy address noun §

The original Bitcoin address format, encoding OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG. Starts with 1 in Base58Check encoding. Sometimes called P2PKH (pay-to-public-key-hash). Used since the first Bitcoin block in 2009.

Legacy addresses are still fully supported and probably will be forever — Bitcoin doesn’t break old outputs. But they’re the most expensive format to spend because they don’t get the SegWit witness discount. A typical P2PKH spend pays roughly 30% more in fees than the equivalent native SegWit spend.

If you find a wallet with 1... addresses, it works fine. If you’re setting up a new wallet today, choose native SegWit (bc1q...) or Taproot (bc1p...) instead. The same 24-word seed can derive all three formats in parallel — switching is a configuration change, not a wallet change.

Related: p2sh, segwit, native segwit, address

See also: Address Validator

Lightning Network noun §

A peer-to-peer payment network that settles to Bitcoin’s base layer through multi-signature channels. Two parties open a channel by funding a 2-of-2 multisig output on-chain; they then exchange off-chain signed updates that shift the channel balance. Closing the channel publishes the latest update on-chain. In between, transfers are nearly instant and almost free.

Routing extends this to a network: a multi-hop payment crosses several channels, and each hop earns a tiny fee in exchange for forwarding. As long as a path with enough liquidity exists from sender to recipient, the payment goes through.

Lightning is what makes Bitcoin practical for everyday spending without turning the base layer into a transaction supercomputer. It’s also where real Bitcoin commerce lives — strikingly more so in El Salvador, the Philippines, and pockets of Africa than in the West.

Related: channel, htlc, routing, watchtower, bolt 11

M

market cap noun §

Circulating supply × current price. For Bitcoin, that’s about 19.85M coins times whatever the spot price is, in whatever currency. Market cap is the most cited Bitcoin number after price itself, but it has serious limitations: it assumes you could sell every bitcoin in existence at the current spot price, which is obviously false at any reasonable size.

A better lens is realized cap — the value of all coins priced at the time they last moved. Realized cap is more like “cost basis of the network” and moves much more sluggishly than market cap. Spread between them is a useful sentiment proxy.

For comparing Bitcoin to other monetary assets (gold’s $15T, US M2’s $20T, global real estate’s $300T), market cap is the wrong number — but it’s the only one journalists ever quote. Use it with that caveat in mind.

Related: realized cap, btc, satoshi

See also: Bitcoin blocks

mining pool noun §

A coordinator that aggregates hashrate from many miners and distributes the block reward proportionally to each contributor’s share of submitted work. Solo mining is now a multi-decade-variance lottery; pools convert that volatility into a steady wage by paying out shares before any individual miner ever finds a block.

The trade-off is centralization. While miners point hashpower wherever they want and can leave anytime, the pool operator picks transactions, builds templates, and is the entity governments would lean on to censor. Stratum V2 and protocols like BetterHash try to give individual miners back the power to choose which transactions go in their share’s template.

Healthy distribution: no single pool above ~30%, top three under 60%. Watch the mining stats page — concentration risk is real.

multisig noun /mul-tee-sig/ §

A spending policy that requires M signatures out of N possible keys to authorize a transaction. A 2-of-3 multisig has three keys and needs any two to spend. A 3-of-5 has five keys and needs three. The redundancy protects against single-key compromise and single-key loss.

Common multisig setups for individuals: 2-of-3 with one key on a Coldcard, one on a Trezor, one on a third device geographically separated. Lose any one, you can still spend with the other two and rotate the lost key. Even if an attacker compromises one device, your funds stay safe.

Pre-Taproot multisig spends were larger and more expensive on chain than single-sig because every signature was published. Post-Taproot, MuSig2 lets N parties combine into a single Schnorr signature, indistinguishable on chain from a single-key spend — cheaper, more private, and easier to build coordinator software for. The downside: tooling for multisig is still rougher than single-sig. Plan for the recovery scenario, not just the happy path.

See also: Hardware wallet setup

N

native SegWit noun §

A SegWit address used directly, without the legacy P2SH wrapper. Native SegWit addresses use the bech32 encoding, start with bc1q on mainnet (tb1q on testnet), and lock to a public key hash via the v0 witness program.

Bech32 is more compact, has stronger error detection (the BCH code catches up to four typos), and renders cleanly in QR codes (all-lowercase, fewer modules). The character set deliberately excludes 1, b, i, o to reduce confusion.

Native SegWit captures the full SegWit fee discount. A typical P2WPKH single-input single-output transaction is about 110 vbytes — versus ~140 vbytes for P2SH-P2WPKH and ~225 vbytes for legacy P2PKH. For new wallets in 2026, native SegWit (BIP-84) or Taproot (BIP-86) are the right defaults. Legacy and P2SH formats are accepted indefinitely but should not be generated for new receives.

Related: segwit, p2sh, taproot, bip84, address

See also: Address Validator

node noun §

A computer running Bitcoin software that participates in the network — receiving blocks, validating them, and gossiping them onward. Nodes come in flavours: full nodes validate every block back to genesis; pruned nodes do the same but throw away historical block data; light (SPV) clients trust headers and ask others for the rest.

Running your own node is the only way to not trust a third party about your balance, the chain tip, or the rules. Every fee estimate, every “your tx confirmed” notification you read from someone else is hearsay until your node agrees.

Nodes are also Bitcoin’s actual governance: a soft-fork only takes effect if node operators run code that recognises it. Miners propose; nodes dispose. That’s why “run a node” is the most consequential way for an ordinary person to have skin in the protocol.

O

output noun §

The destination half of a transaction. Each output specifies an amount in satoshis and a locking script that defines who can spend it next — typically “the holder of this public key” via P2PKH, P2WPKH, or P2TR.

When a transaction confirms, its outputs become new UTXOs in the global set. They sit there, spendable, until someone references them as an input in a future transaction. At that point they’re consumed and disappear from the UTXO set, replaced by whatever new outputs that future transaction created.

Outputs come in two practical varieties for an everyday user: the payment output (the amount you’re sending to the recipient) and the change output (the leftover sent back to a fresh address you control). Wallets handle this automatically; you just enter “send X to Y” and the wallet figures out which UTXOs to consume and how much change to return.

Related: input, utxo, change output, address

P

P2SH abbreviation /pee-two-ess-aitch/ §

A scripting model defined in BIP-16 (2012). Instead of locking a UTXO to a specific public key, you lock it to the hash of a script. To spend, you reveal the script (called the redeem script) and provide whatever it expects.

P2SH addresses start with 3 in Base58Check encoding. The receiver doesn’t need to know what’s behind the hash — they just send to the address. The spender reveals the script when they spend. This decoupling enabled the first wave of multisig addresses without requiring every receiver wallet to understand multisig templates.

P2SH was also the wrapper format for early SegWit adoption (P2SH-P2WPKH and P2SH-P2WSH, addresses still starting with 3). That kept old wallets compatible while the SegWit upgrade rolled out. New wallets generally prefer pure native SegWit bc1q or Taproot bc1p, which are cheaper and more privacy-preserving.

See also: Address Validator

P2TR abbreviation /pee-two-tee-arr/ §

The output type for Taproot addresses. P2TR addresses use bech32m encoding (a small modification to bech32 that fixes a length-extension edge case) and start with bc1p on mainnet, tb1p on testnet.

A P2TR output commits directly to a 32-byte tweaked public key — no intervening hash. The owner can either provide a Schnorr signature against that key (the key path spend, indistinguishable from any other Taproot spend) or reveal a script and prove inclusion in a Merkle tree of alternative scripts (the script path spend, used for fallback policies or complex contracts).

P2TR fees are roughly comparable to P2WPKH for single-key spends, slightly better for multisig because of Schnorr aggregation. The privacy benefit shows up when you have non-trivial spending policies — a 2-of-3 multisig key-path spend looks identical to a single-key spend on chain. Same script-tree, same wallet, indistinguishable transaction.

Related: taproot, schnorr, native segwit, address

See also: Address Validator

peer noun §

Another Bitcoin node that yours is connected to. By default Bitcoin Core maintains 8 outbound connections (peers it dialed) and accepts up to 117 inbound (peers that dialed it). Some are full nodes, some are wallets, some are SPV light clients — your node treats them roughly the same at the network level.

Peer selection is privacy-relevant. The set of IPs your node has connected to over time is what an observer would correlate to deanonymise you, which is why Tor-only and i2p-only setups are popular for privacy-conscious node runners. Bitcoin Core 0.21+ also has Tor v3 native and can do hybrid mode (Tor outbound, clearnet inbound).

If your node has zero peers, you’re not on the Bitcoin network — you’re just running software. The peer count badge in our node stats is a healthy sanity check.

Related: node, gossip, propagation

See also: Hardware wallet setup

R

RBF abbreviation /are-bee-eff/ §

A mechanism, specified in BIP-125, for bumping the fee on an unconfirmed transaction by broadcasting a replacement that pays more. The replacement must spend at least one of the same inputs and pay a strictly higher fee, and the original transaction must have signaled RBF eligibility.

RBF is the gentle remedy for “stuck” transactions. You sent at 5 sat/vB, the mempool spiked, and now you’re waiting for hours. With RBF you broadcast a new version at 30 sat/vB; miners pick that one up; the old version evaporates from the mempool; you’re confirmed in the next block.

Default RBF signaling has been wallet-by-wallet for years. As of Bitcoin Core 24.0+, full RBF (allowing replacement of any unconfirmed transaction, not just opt-in ones) has been gaining traction at the relay-policy level. The merchant-acceptance debate around “zero-conf” continues, but the prevailing engineering view is: don’t trust unconfirmed transactions for high-value payments, period. Lightning is the right tool for instant.

Related: cpfp, fee, mempool, sat per vbyte

S

sat noun §

The smallest indivisible unit of Bitcoin: one hundred millionth of a BTC (1 sat = 0.00000001 BTC, or 1 / 10^8). Named after Bitcoin’s pseudonymous creator Satoshi Nakamoto. At a $100k BTC price, 1 sat ≈ $0.001.

Sats are the unit Bitcoin actually transacts in. The protocol thinks in sats, not in BTC — when a transaction says it’s transferring 50,000, it’s transferring 50,000 sats. Wallets just convert to BTC for display. As Bitcoin appreciates, displaying balances in sats becomes more user-friendly: “you have 1,250,000 sats” beats “you have 0.0125 BTC.”

A small but growing wallet movement (Phoenix, Mutiny, Wallet of Satoshi) shows sats by default. Wholehog “denominate everything in sats” is the most plausible near-term step toward hyperbitcoinization.

Related: btc, satoshi, stack sats

See also: Address Validator

SHA-256 abbreviation /ess-aitch-ay two-fifty-six/ §

The cryptographic hash function used everywhere in Bitcoin: in mining proof-of-work, in transaction IDs, in merkle trees, in address derivation. Defined by NIST in FIPS 180-4, SHA-256 takes any input and produces a 256-bit (32-byte) digest.

Three properties matter for Bitcoin: it’s deterministic (same input always gives same output), one-way (you can’t run it backward to find the input), and collision-resistant (no one has ever found two inputs that produce the same output, despite massive search efforts).

In mining, the entire global hashrate is essentially a giant SHA-256 brute force. Around 2026, the network performs roughly 5 × 10^20 SHA-256 hashes per second — five hundred exahashes — looking for a header that hashes below the current difficulty target. Bitcoin actually uses double SHA-256 in most places, hashing the output of one SHA-256 as the input to a second.

See also: Bitcoin blocks

signature noun §

A short cryptographic proof — generated using a private key — that authorizes a specific transaction. Anyone holding the corresponding public key can verify the signature, but no one can forge it without the private key.

Bitcoin signatures don’t sign “I authorize this transaction” abstractly. They sign a specific message derived from the transaction itself, called the sighash. The default sighash flag (SIGHASH_ALL) commits to every input and output, so altering any field invalidates the signature. Other flags exist for niche use cases like collaborative transaction building.

Pre-Taproot, Bitcoin used ECDSA signatures over secp256k1. After the 2021 Taproot soft fork, Schnorr signatures are also valid — they’re shorter, support aggregation, and have cleaner security proofs. New wallets default to Schnorr where possible.

See also: Self-custody basics

stack sats verb §

The practice of accumulating bitcoin in small, regular amounts — denominated in sats rather than BTC — over long horizons. The mantra: “stack sats, then stack more sats.” The terminology nudges people away from thinking about Bitcoin as one indivisible token and toward thinking about owning, e.g., 500,000 sats (currently around $300).

Sat-stacking is HODL’s working-class wing. Where HODL says “hold what you have,” sat-stacking says “and keep buying more, on a schedule, every paycheck, automatic if possible.” It’s dollar-cost-averaging dressed in orange.

Tools that automate it include river.com and Strike for Americans, relai.app for Europeans, and small recurring buys on any exchange that offers them. Then move them off-exchange to your own keys. See the DCA calculator for what historical stacking would look like.

Related: hodl, dca, sat, satoshi

See also: DCA calculator · Stacking plan

submarine swap noun §

A trustless atomic swap between Lightning and on-chain Bitcoin. Pay an on-chain transaction with a hash lock; the recipient is forced to either reveal the same hash to claim Lightning sats from you (completing the swap) or eat a refund. No counterparty risk during the swap.

Submarine swaps power services like Boltz and Loop, which let you “refill” inbound or outbound Lightning liquidity by trading on-chain BTC for off-chain LN balance, and vice versa. Useful when your channels are unbalanced and you want to keep using the same node without closing and reopening.

Phoenix and Wallet of Satoshi use submarine swaps under the hood to make on-chain ↔ Lightning feel like one wallet. The user sees “send Bitcoin” and gets either an LN payment or an on-chain tx automatically — the swap fee is the cost of that magic.

Related: lightning network, channel, htlc

T

Taproot noun /tap-root/ §

A 2021 soft fork that introduced Schnorr signatures, the P2TR address format, and the ability to commit to entire spending policies in a single public key. Specified across BIP-340, BIP-341, BIP-342. Activated November 14, 2021 at block 709,632.

The killer feature is privacy through indistinguishability. Before Taproot, a multisig spend, a Lightning channel close, and a complex DLC each looked distinct on chain. With Taproot, all of them can collapse to a single Schnorr signature against a single key — visually indistinguishable from a plain payment.

Adoption has been slower than SegWit was. Wallet support arrived in 2022, but defaults moved gradually. By 2026, most modern wallets generate Taproot addresses (bc1p...) by default for new receives. The chain is gradually shifting Taproot-heavy as users transact and consolidate, but SegWit v0 and legacy addresses will remain valid forever.

Related: p2tr, schnorr, segwit, multisig

See also: Address Validator

transaction noun §

A signed instruction that consumes one or more existing UTXOs and creates new ones. A Bitcoin transaction has zero “balance” semantics — it just says: “the person who can unlock these old UTXOs is authorizing the creation of these new ones.”

The structure is straightforward: a list of inputs (each pointing to a previous transaction’s output and including a signature that unlocks it), a list of outputs (each containing an amount in sats and a locking script that says who can spend it next), plus a few protocol fields like nLockTime and version.

Once broadcast, a transaction sits in the mempool until a miner includes it in a block. After that block, the new outputs are spendable. Most receivers wait six confirmations for high-value transfers, though one is enough for small everyday payments.

Related: input, output, utxo, fee, signature

U

UASF abbreviation §

A soft-fork that’s activated by users (node operators) rather than miners. The mechanism: starting on a particular flag day, all participating nodes simply reject any block that doesn’t enforce the new rule. Miners who keep producing old-rule blocks have their revenue burned by the wider network rejecting them.

The famous example is BIP-148 in 2017, which forced SegWit’s activation when miners had been stalling on signaling for over a year. The threat alone was enough — by August 1, 2017, miners capitulated and SegWit locked in via the existing BIP-9 path.

UASF is the most concrete demonstration that nodes — not miners — decide what Bitcoin is. Run your own node and you literally vote on every block. The phrase “Bitcoin is what nodes say it is” stops being a slogan and starts being how the protocol works.

Related: soft fork, consensus, bip

See also: Self-custody basics

UTXO abbreviation /you-tex-oh/ §

A discrete chunk of Bitcoin you can spend, identified by the previous transaction’s ID and an output index. Bitcoin’s ledger is just a set of UTXOs at any given moment — there are no “balances” in the protocol, only sets of outputs that your wallet can unlock.

When you send Bitcoin, you consume (spend) one or more UTXOs and create new ones — one to the recipient, and usually one back to yourself as “change.” Wallets aggregate your UTXOs into a displayed balance, but under the hood every transaction is UTXO surgery.

The UTXO model is one of Bitcoin’s most underrated design choices. It makes parallel validation easy, it sidesteps account-replay attacks entirely, and it lets you reason about coin history at the granularity of individual outputs. The trade-off is that wallets must do coin selection and users have to think about UTXO consolidation when fees are cheap.

Related: coinbase tx, change output, dust, input, output

V

virtual byte noun /vee-byte/ §

The post-SegWit fee-accounting unit, defined as weight ÷ 4. A virtual byte equals one byte of non-witness data or four bytes of witness data. The 4× discount on witness data is what makes native SegWit and Taproot cheaper to spend than legacy P2PKH.

Block capacity is bounded at 4 million weight units (1 million vbytes). Average blocks contain around 600,000–800,000 vbytes of transactions — fewer when the mempool is quiet, more during congestion when miners pack blocks tightly.

Wallet fee displays use vbytes throughout. When mempool.space shows “30 sat/vB,” it means 30 sats per virtual byte. A 140-vbyte SegWit transaction at that rate costs 4,200 sats. The “virtual” prefix acknowledges this isn’t a literal byte count — it’s a weighted measure designed to incentivize SegWit adoption while keeping the block-weight limit honest.

Related: weight unit, sat per vbyte, segwit, fee

W

watch-only adjective §

A wallet that holds the extended public key (xpub) for an HD wallet but no private keys. It can derive receive addresses, scan the chain for your balance, and build unsigned transactions. It cannot spend.

Watch-only wallets are how you check your hardware wallet’s balance from a phone or laptop without exposing the seed. Sparrow, Nunchuk, Specter, and many others support importing an xpub and treating it as read-only. You see your funds the same way an explorer would, but the spending keys never touch the watching device.

The privacy caveat: an xpub leaks all addresses, past and future, of that account. Anyone with your xpub can construct a complete history of every transaction ever associated with it. Treat xpubs as semi-sensitive: don’t post them publicly, don’t share with services that don’t need them, and prefer per-account xpubs (BIP-44 layer 3) rather than the master xpub for the entire wallet.

See also: Bitcoin blocks