Reference

Glossary

Every term used across the eight modules, plus the wider Bitcoin vocabulary — 790 entries, each defined in one teaching sentence. Plus 76 long-form guides and deep-dives below.

Beginner Guides

Bitcoin from Scratch

19 long-form guides covering blockchain, mining, wallets, keys, transactions, and the parts of the network — each in the same retro-terminal layout used throughout the source material.

Technical Deep-Dives

Protocol Internals

57 reference pages covering serialization, cryptography, address formats, and consensus minutiae. Topics with an interactive section let you type and watch the page recompute.

51% Attack
Adaptor Signatures
Addresslive
AssumeUTXO
Base58live
Bech32live
BIP85
Bitcoin Script — Interactivelive
Bits (Difficulty Target)
blk.dat Files
Block Hashlive
Block Height
Block Serializationlive
Block Time
Block Validation
Block Version
Byte Order
Bytes
Chain Reorganization
Checkpoints
Checksum
Compact Sizelive
Derivation Pathslive
Double Spendlive
ECDSAlive
Elliptic Curvelive
Entropy & RNGlive
Extended Keyslive
Genesis Blocklive
Hard Fork
Hash Functionlive
HASH160 (Key Hash)
HD Walletslive
Hexadecimallive
HMAC-SHA512
Key Tweakinglive
Little Endianlive
Longest Chain
Merkle Proofs
Merkle Rootlive
Mnemonic Seedlive
MuSig2live
Nonce
Orphan / Stale Blocks
Output Descriptorslive
Pay to Anchor (P2A)
Previous Block Hash
Private Key
Public Key
RIPEMD-160
Schnorr Signatureslive
Signaturelive
Silent Paymentslive
Soft Fork
Transaction Serialization — Interactivelive
UTXO Setlive
WIF Private Keylive

From the modules

Module References

The 28 terms that appear hyperlinked across the eight modules, each tagged with the module it belongs to. Hover any underlined term in a lesson to jump back here.

Stack: A stack is a data structure where the last item pushed is the first item removed (LIFO). In Bitcoin Script, the stack is the only place data lives — there are no variables, registers, or heap. Every opcode either pushes something onto the stack or pops something off it.
LIFO: LIFO stands for Last In, First Out. The most recently pushed item is always the first one removed. This is the opposite of a queue (FIFO). Bitcoin Script enforces LIFO because every opcode that reads data pops from the top — it can never reach deeper without explicit manipulation opcodes like OP_OVER or OP_ROT.
Opcode: An opcode (operation code) is one instruction in a Bitcoin Script program. Each opcode is encoded as a single byte in the raw script. The Script interpreter executes opcodes one at a time, left to right, maintaining the stack as it goes. There are roughly 80 active opcodes in Bitcoin Script.
Push: Pushing means adding a new item to the top of the stack. Push opcodes like OP_1 through OP_16 encode small integers directly. For arbitrary data, the script includes a PUSHDATA opcode followed by the raw bytes. After a push, the stack is one item taller.
Pop: Popping removes the top item from the stack and returns it to the opcode that requested it. Most opcodes that perform operations pop their inputs — for example, OP_ADD pops two items and pushes the result. After a pop, the stack is one item shorter.
OP_DUP: OP_DUP copies the top item and pushes the copy. The original remains in place. This is used in P2PKH to keep a copy of the public key for OP_CHECKSIG after OP_HASH160 has consumed one copy for hashing.
Script: Bitcoin Script is the programming language embedded in every Bitcoin transaction. A locking script (scriptPubKey) specifies the conditions for spending an output. An unlocking script (scriptSig) provides the data that satisfies those conditions. Nodes execute the combined script to validate each transaction.
CScriptNum: CScriptNum is the integer encoding used by Bitcoin Script for all numeric operations. Zero is encoded as the empty byte array (not 0x00). Integers use little-endian byte order with the sign bit in the high bit of the last byte. The maximum size for arithmetic opcodes is 4 bytes (±2,147,483,647). This encoding is distinct from standard two's complement.
OP_ADD: OP_ADD pops the top two items from the stack, decodes them as CScriptNum integers, adds them, and pushes the encoded result. Both inputs and the output must fit within 4 bytes. This is the fundamental arithmetic opcode — subtraction, multiplication, and others follow the same pattern.
Minimal push: The minimal push rule (enforced by the MINIMALDATA flag) requires that scripts use the shortest possible encoding when pushing data. For example, the number 1 must be pushed as OP_1, not as a PUSHDATA byte followed by 0x01. This rule closes a transaction malleability vector and is enforced on mainnet.
Boolean: In Bitcoin Script, boolean truthiness is determined by the raw byte array. An item is falsy only if it is the empty array [] (zero) or [0x80] (negative zero). Any other byte sequence — including 0x01, 0xFF, multi-byte values — is truthy. Comparison opcodes like OP_EQUAL push the canonical true (0x01) or false ([]) rather than arbitrary non-zero values.
OP_EQUAL: OP_EQUAL performs a byte-for-byte comparison of the top two stack items and pushes 1 if they are identical, 0 otherwise. It does not interpret the items as numbers — a 32-byte hash and a 32-byte hash are compared as raw bytes. For numeric equality, use OP_NUMEQUAL instead.
OP_VERIFY: OP_VERIFY pops the top item and fails the entire script execution if that item is falsy (empty array or negative zero). Nothing is pushed. It acts as an assertion opcode: "this must be true or the transaction is invalid." Many opcodes have VERIFY variants (OP_EQUALVERIFY, OP_CHECKSIGVERIFY) that combine the base opcode with an implicit OP_VERIFY.
Branching: Branching in Bitcoin Script is the ability to execute different opcodes depending on a runtime value. OP_IF begins a conditional block; OP_ELSE provides the alternative path; OP_ENDIF closes the block. Unlike traditional programs, Bitcoin Script has no loops — branches can only select between two linear paths, never repeat.
conditionStack: The condition stack is an internal state maintained by the Script interpreter to handle nested OP_IF blocks. When an OP_IF is entered, the interpreter pushes a boolean indicating whether that branch is active. All non-flow opcodes check the entire condition stack before executing — if any level is inactive, the opcode is skipped. This is how nested conditions work without any jump instructions.
OP_IF: OP_IF pops the top stack item. If it's truthy, the opcodes between OP_IF and OP_ELSE (or OP_ENDIF if there's no OP_ELSE) are executed. If falsy, they are skipped. The condition value is consumed — it doesn't remain on the stack. OP_NOTIF is the inverse: its block runs when the condition is falsy.
Hash function: A cryptographic hash function takes any input and produces a fixed-size output (the digest or hash). It is deterministic, fast to compute, and practically impossible to reverse (preimage resistance) or to find two inputs with the same output (collision resistance). Bitcoin Script has five built-in hash functions: OP_SHA1, OP_SHA256, OP_HASH256, OP_RIPEMD160, and OP_HASH160.
SHA-256: SHA-256 (Secure Hash Algorithm 256-bit) produces a 32-byte digest and is the workhorse of Bitcoin's cryptography. It's used for transaction IDs (double-SHA256), mining (double-SHA256 of block headers), and HASH160 (SHA256 then RIPEMD-160). OP_SHA256 applies it once; OP_HASH256 applies it twice (SHA256(SHA256(x))).
RIPEMD-160: RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest 160-bit) produces a 20-byte digest. In Bitcoin it is always applied after SHA-256 rather than alone. The combination RIPEMD160(SHA256(x)) is called HASH160 and produces the 20-byte public key hash that appears in P2PKH and P2SH addresses.
HASH160: HASH160 is the two-step hash used throughout Bitcoin address generation: first SHA-256, then RIPEMD-160, yielding a 20-byte result. It is used in P2PKH (to hash the public key into an address) and in P2SH (to hash the redeem script). The 20-byte output is what gets Base58Check-encoded into the address you share with senders.
Preimage: A preimage is the input value that was hashed to produce a given digest. In a hash commitment script, a locking script embeds a hash H and the spender must reveal the preimage P such that hash(P) = H. This is the mechanism behind Hash Time-Locked Contracts (HTLCs) in the Lightning Network — the recipient proves knowledge of a payment preimage to claim funds.
ECDSA: ECDSA (Elliptic Curve Digital Signature Algorithm) is the signature scheme Bitcoin uses to prove ownership of private keys. A private key signs a message (the transaction hash) to produce a signature. Anyone with the corresponding public key can verify the signature without learning the private key. Bitcoin uses the secp256k1 curve. Taproot transactions use Schnorr signatures instead.
DER encoding: DER (Distinguished Encoding Rules) is the ASN.1-based binary format used to serialize ECDSA signatures in Bitcoin. A DER-encoded signature begins with 0x30 and encodes the two integers r and s. The SIGHASH type byte is appended after the DER encoding. Legacy Bitcoin transactions require DER-encoded signatures; Taproot (Schnorr) uses a compact 64-byte format instead.
OP_CHECKSIG: OP_CHECKSIG pops a public key (top) and a signature (second) from the stack, verifies the ECDSA signature against the serialized spending transaction, and pushes 1 (valid) or 0 (invalid). In production this requires the full transaction context. In the Stack simulator, a fixed test-vector pair is used to demonstrate the mechanics without real transaction data.
scriptSig: scriptSig (also called the input script or unlocking script) is the data a spender includes in a transaction input to satisfy the conditions of the output being spent. For P2PKH, the scriptSig contains a signature and a public key. Nodes prepend the scriptSig to the scriptPubKey and execute the combined program to determine if the spend is valid.
scriptPubKey: scriptPubKey (also called the output script or locking script) is the program embedded in a Bitcoin transaction output that defines the conditions for spending. For P2PKH it is: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Only someone who can provide a matching scriptSig — proving they know the corresponding private key — can spend the output.
P2PKH: P2PKH (Pay-to-Public-Key-Hash) is the script template behind every Bitcoin address starting with '1'. The scriptPubKey locks funds to the HASH160 of a public key. To spend, the owner provides their signature and public key; the script verifies the public key hashes to the expected value and the signature is valid. P2PKH improves on P2PK by hiding the public key until spend time.
OP_CHECKMULTISIG: OP_CHECKMULTISIG validates that at least M out of N provided signatures are valid for the corresponding public keys. It reads N public keys, M signatures, and the dummy element from the stack, then checks each signature against each key in order. A historical off-by-one bug requires an extra element (conventionally OP_0) to be on the stack before the signatures — it is silently consumed. BIP 147 mandated this dummy must be an empty array.

Category

20 terms

Bitcoin Basics

The vocabulary you meet on day one — what Bitcoin is and the pieces that make it move.

Bitcoin: A peer-to-peer digital cash system where coins are entries in a public ledger that anyone can verify and no one controls.
BTC: The ticker symbol for one bitcoin; one BTC equals 100,000,000 satoshis, the smallest divisible unit.
Satoshi (unit): The smallest unit of bitcoin (1 sat = 0.00000001 BTC); all on-chain amounts are stored as integer satoshis to avoid floating-point errors.
Satoshi Nakamoto: The pseudonymous author of the 2008 Bitcoin whitepaper and the original Bitcoin software; their identity remains unknown.
Blockchain: An append-only chain of blocks where each block commits to the previous one via its hash, making history tamper-evident.
Decentralization: No single party can change the rules or freeze funds, because thousands of independent nodes each validate every transaction themselves.
Peer-to-peer (P2P): A network where every participant talks directly to other participants, with no central server in the middle.
Consensus: The shared agreement among nodes on which transactions are valid and which chain is the canonical history.
Permissionless: Anyone can run a node, mine, or transact without asking for approval; participation is open by default.
Censorship-resistance: Once a transaction has enough confirmations no entity can erase or block it, because miners and nodes are globally distributed.
Trust-minimized: Verifying the chain replaces trusting people; you check the math instead of trusting a bank, exchange, or government.
Open Source: Bitcoin's reference software is published publicly so anyone can audit, fork, or improve it.
Bitcoin Core: The reference implementation of the Bitcoin protocol; running it gives you a full node that validates every rule from genesis.
Bitcoin Network: The global mesh of nodes, miners, and wallets that propagate transactions and blocks to one another.
Block: A batch of transactions plus a header; blocks are mined roughly every ten minutes and chained together to form the blockchain.
Transaction: A signed message that spends one or more existing UTXOs and creates new ones, transferring value on the ledger.
Node: A computer running Bitcoin software that stores the chain and enforces the consensus rules; full nodes validate everything themselves.
Miner: A participant who packages transactions into candidate blocks and burns electricity searching for a valid proof-of-work hash.
Wallet: Software that manages your private keys, builds transactions, and tracks your UTXOs; it never holds coins directly, only the keys to spend them.
Address: A short string that encodes a locking script; senders pay your address and the network resolves it back to the script that locks the output.

Category

79 terms

Keys & Cryptography

Elliptic curves, hashes, and signatures — the math that lets a 32-byte secret control billions of dollars.

Private Key: A random 256-bit number that gives full spending authority over the coins locked to its derived public key.
Public Key: A point on the secp256k1 curve, derived from a private key, that others use to verify signatures you produce.
Key Pair: A private key paired with its mathematically-linked public key; one signs, the other verifies.
Elliptic Curve: A curve defined by y² = x³ + ax + b; "adding" two points produces a third, and that operation is easy forward but practically impossible to reverse.
secp256k1: The specific elliptic curve Bitcoin uses, chosen for its lack of suspicious constants and high-performance arithmetic.
Generator Point (G): A fixed agreed-upon point on secp256k1; multiplying G by your private key gives your public key.
Curve Order (n): The number of distinct points on secp256k1 reachable from G; private keys are integers modulo n.
Field Prime (p): The prime modulus defining secp256k1's coordinate field; all curve arithmetic is done modulo p.
Point Addition: Combining two distinct curve points by drawing a line through them and reflecting the third intersection across the x-axis.
Point Doubling: Adding a point to itself by using the curve's tangent at that point; the basis of fast scalar multiplication.
Point Multiplication: Adding a point to itself k times to produce k·P; the one-way trapdoor underlying ECDSA and Schnorr.
Scalar Multiplication: Same as point multiplication; the scalar is the integer (e.g. private key) and the point is on the curve.
ECDSA: Elliptic Curve Digital Signature Algorithm; legacy Bitcoin's signature scheme, producing a (r,s) pair from a private key and message hash.
Schnorr Signatures: A simpler, linearly-aggregatable signature scheme adopted in Taproot (BIP340); supports multi-signature collapse to a single 64-byte signature.
Digital Signature: Cryptographic proof that the holder of a private key approved a specific message, verifiable by anyone with the public key.
Signature: The byte string produced by signing; in Bitcoin it is appended with a sighash flag indicating what parts of the tx it commits to.
Hash Function: A deterministic function mapping arbitrary input to a fixed-size output; one-way and collision-resistant.
SHA-256: A 256-bit cryptographic hash function used everywhere in Bitcoin — TXIDs, mining, address derivation, Merkle trees.
RIPEMD-160: A 160-bit hash function; composed with SHA-256 it produces HASH160, used to shrink public keys into addresses.
HASH160: RIPEMD160(SHA256(x)); the 20-byte fingerprint embedded in legacy and P2SH addresses.
HASH256: SHA256(SHA256(x)); applied twice for added preimage protection — used for TXIDs and block hashing.
Double-SHA256 (SHA256d): Another name for HASH256; the workhorse digest of Bitcoin's consensus layer.
HMAC: A keyed hash construction: HMAC(k, m) authenticates message m with secret k, used in HD wallet derivation.
HMAC-SHA512: HMAC built on SHA-512; BIP32 uses it to deterministically derive child keys from a parent and chain code.
SHA-512: A 512-bit hash function; used inside HMAC-SHA512 for BIP32 derivation.
SHA-1: A legacy 160-bit hash, broken for collisions; Bitcoin retains OP_SHA1 only for backward compatibility.
Tagged Hash: SHA256(tag || tag || data); domain-separates hashes per use case, critical to Taproot and Schnorr.
Trapdoor Function: A function easy to compute one way and infeasible to reverse without a secret; ECDLP is Bitcoin's trapdoor.
One-way Function: A function whose forward direction is cheap but whose inverse is computationally intractable.
Modular Arithmetic: Arithmetic where numbers wrap around at a modulus; all curve coordinates live in a finite field defined by p.
Modular Inverse: For x in modulus m, the value y such that x·y ≡ 1 (mod m); needed to compute s in ECDSA signing.
Extended Euclidean Algorithm: An efficient way to compute the modular inverse via the GCD recursion.
Finite Field: A finite set with well-defined + and × operations; secp256k1 coordinates live in the finite field of size p.
Prime Modulus: A prime number used as the modulus, guaranteeing every nonzero element has a unique inverse.
Entropy: Unpredictable randomness measured in bits; a Bitcoin private key needs ≥128 bits of true entropy to be secure.
Random Number Generation (RNG): The process of producing unpredictable values; weak RNG has historically caused millions in Bitcoin theft.
Compressed Public Key: 33-byte pubkey: a 1-byte parity prefix (02/03) plus the x-coordinate; the y is recovered from the curve equation.
Uncompressed Public Key: 65-byte pubkey: 0x04 prefix plus full x and y coordinates; obsolete but still valid for legacy scripts.
X-only Public Key: 32-byte pubkey used in Taproot — only the x-coordinate, with the y always taken to have even parity.
DER Signature: Distinguished Encoding Rules format for ECDSA signatures, starting with 0x30 and a length byte.
MuSig2: A two-round Schnorr multisignature protocol producing a single signature indistinguishable from a single-signer one.
Adaptor Signatures: A signature that is only valid once an extra secret t is revealed; enables atomic swaps and PTLCs.
Threshold Signatures: Schemes (FROST, etc.) where any t of n parties can jointly produce a valid signature without ever assembling the full key.
Batch Verification: Verifying many Schnorr signatures together with one combined check, far faster than verifying each individually.
DLEQ Proof: Discrete-log-equality proof: shows that two different group elements share the same secret exponent.
Parity Bit: A single bit indicating whether the y-coordinate of a curve point is even or odd; used in compressed and x-only formats.
Key Tweaking: Adding a scalar derived from extra data (e.g. a Merkle root) to a public key, committing the key to that data.
Merkle Proof: A list of sibling hashes proving a leaf is included in a Merkle root, without revealing the whole tree.
Signature Hash (Sighash): The digest a signature commits to — typically a hash of selected tx fields determined by the sighash flag.
Coordinate (x, y): A point on secp256k1 is a pair (x, y) of integers in the finite field that satisfies the curve equation.
RSA: An older public-key scheme based on integer factoring; not used in Bitcoin because signatures are too large.
Asymmetric Encryption: Encryption where the keys for encrypting and decrypting differ; Bitcoin uses asymmetric crypto for signatures, not for sealing data.
Symmetric Encryption: Encryption with a single shared key for both directions; used in wallet file encryption, not in the protocol itself.
Commitment Scheme: A way to bind to a value now and reveal it later without changing it — hashes are the simplest commitment.
Challenge (Schnorr): The hash e = H(R || P || m) inside a Schnorr signature; ties the signature to the public key and message.
ECDSA Nonce: The per-signature random scalar k; if k repeats or leaks, the private key can be recovered instantly.
Curve Equation (y² = x³ + 7): The defining equation of secp256k1; every public key is a point satisfying it.
Double-and-Add Algorithm: Standard fast method to compute k·P in O(log k) point operations.
ECDLP (Elliptic Curve Discrete Log Problem): Given P and k·P, finding k is intractable; this hardness is Bitcoin's security foundation.
ECDH (Elliptic Curve Diffie-Hellman): A way for two parties to derive a shared secret from their public keys without revealing their private keys.
RFC 6979 (Deterministic ECDSA Nonce): Deriving the nonce k deterministically from the private key and message, eliminating bad-RNG vulnerabilities.
Low-S Rule (BIP66): A consensus rule forcing the s value of an ECDSA signature to be in the lower half of n, removing one form of malleability.
NUMS Point (Nothing-Up-My-Sleeve): A curve point provably without a known discrete log; used as an internal key in Taproot when only the script path matters.
TapLeaf / TapBranch / TapTweak Tags: Domain-separated tagged hashes structuring a Taproot script tree and its final key tweak.
Adaptor Point: The curve point T = t·G associated with adaptor secret t; revealing the adaptor signature exposes t.
Rogue Key Attack: Attack where a malicious co-signer picks their key to cancel another's; MuSig2 prevents it via key aggregation hashes.
Key Aggregation: Combining multiple public keys into a single aggregate key using weighted sums to prevent rogue-key attacks.
Linear Aggregation (naive, broken): Naively summing pubkeys to combine them; broken because attackers can craft cancelling keys.
FROST (Threshold Schnorr): A threshold Schnorr signing protocol allowing any t of n signers to produce a single signature.
Scriptless Scripts: Encoding contract logic entirely inside signatures using adaptor signatures, leaving no script on-chain.
Merkle-Damgård Construction: The iterative hash construction (SHA-256, etc.) that processes message blocks through a compression function.
Preimage Resistance: The property that finding any input that hashes to a target output is infeasible.
PBKDF2 (Key Stretching): A function that repeatedly hashes a password and salt to derive a slow, GPU-resistant key; used in BIP39 seed derivation.
CSPRNG (Cryptographically Secure PRNG): A pseudo-random generator whose output is indistinguishable from true randomness without the seed.
Hash Collision: Two distinct inputs that hash to the same output; finding one is infeasible for SHA-256.
Hash Commitment: Publishing H(x) now commits you to x without revealing it; opening means revealing x later.
Binding Factor (b): In MuSig2, a per-signer scalar mixed into nonce combination to prevent Wagner-style forgery.
Partial Signature (MuSig2): One co-signer's contribution to a MuSig2 signature; sums with the others into a single valid Schnorr signature.
Nonce Commitment (MuSig2 Round 1): The first MuSig2 round, where each signer publishes two nonces (R₁, R₂) before seeing others'.

Category

50 terms

Addresses & Encoding

How raw bytes become human-shareable strings — and the encoding rules that catch typos.

Address: A user-friendly string that encodes a locking script; you give it to a sender and they pay the script.
Base58: A 58-character alphabet excluding visually-confusable characters (0, O, I, l); used in legacy addresses.
Base58Check: Base58 with a 4-byte SHA256d checksum suffix; a single typo will fail the checksum.
Bech32: BIP173 address format for SegWit v0; uses a lowercase 32-character alphabet and BCH error-correcting checksum.
Bech32m: BIP350 variant fixing a Bech32 mutation issue; used for SegWit v1+ (Taproot).
Checksum: Extra bytes appended to data so a recipient can detect transmission errors with high probability.
WIF (Wallet Import Format): Base58Check encoding of a private key with a version byte and optional compression flag.
Public Key Hash: The 20-byte HASH160 of a public key, embedded in P2PKH and P2WPKH scripts.
Script Hash: The 20-byte HASH160 or 32-byte SHA256 of a redeem script, embedded in P2SH and P2WSH.
Witness Program: The bytes after the witness version in a SegWit scriptPubKey; identifies what the witness must satisfy.
bc1 prefix (P2WPKH): Bech32 mainnet addresses for native SegWit start with "bc1q" for v0 witness programs.
bc1p prefix (P2TR): Bech32m mainnet addresses for Taproot outputs start with "bc1p" (witness version 1).
1-prefix address (P2PKH): Legacy Base58Check addresses starting with "1" — pay to a public key hash.
3-prefix address (P2SH): Base58Check addresses starting with "3" — pay to a script hash; can wrap SegWit for backward compatibility.
Hexadecimal: Base-16 representation where each byte becomes two characters (0–9, a–f); the universal raw-byte format.
Base64: A 64-character encoding used outside Bitcoin (PSBT export, etc.); more compact than hex.
ASCII: A 7-bit character encoding; relevant when scripts treat bytes as text in BIP322 message signing.
Bytes: The atomic unit of all serialized data in Bitcoin — every field is some sequence of bytes.
Byte Order: Whether the most or least significant byte appears first; Bitcoin mostly uses little-endian internally.
Little Endian: Least-significant byte first; Bitcoin's internal serialization for integers, hashes, and TXIDs.
Big Endian: Most-significant byte first; how humans usually display hashes when reading them.
Natural Byte Order: Internal little-endian byte order of TXIDs and block hashes as they appear in raw data.
Reverse Byte Order: The display order obtained by reversing the natural order; what block explorers usually show.
Compact Size: A variable-length integer encoding using 1, 3, 5, or 9 bytes depending on the value; flags by first byte.
VarInt: Synonym for compact size in Bitcoin context.
Silent Payments (BIP 352): Reusable static addresses where every payment derives a unique on-chain output via ECDH, breaking address-reuse linkage.
Stealth Address: General term for any address scheme that generates a fresh on-chain output per payment.
Pay to Anchor (P2A): An OP_RETURN-like anyone-can-spend output enabling fee-bumping packages without polluting the UTXO set.
HRP (Human Readable Part): The prefix of a Bech32 string (e.g. "bc" or "tb") indicating the network.
Separator (Bech32 "1"): The literal character "1" between HRP and data section in every Bech32 address.
Polymod: The polynomial function used to compute Bech32's 6-character checksum.
BCH Code (Bose-Chaudhuri-Hocquenghem): The class of error-correcting codes Bech32 uses, guaranteeing detection of any 4-character error.
Hamming Distance: The number of positions in which two equal-length strings differ; Bech32 maximises this between valid codes.
Version Byte (Base58Check): The first byte before Base58 encoding; distinguishes networks and script types (0x00 = mainnet P2PKH, etc.).
Compression Flag (WIF 0x01): A single 0x01 byte appended to a WIF private key indicating its public key is to be used in compressed form.
Leading "1" Encoding: In Base58, each leading 0x00 byte of the input becomes a leading "1" in the output.
Leading Zeros: High-order zero bytes that affect Base58 length but vanish in plain Base58 without the leading-1 rule.
Octet: A byte — exactly eight bits.
Nibble: Four bits, or one hex character.
LSB / MSB (Least/Most Significant Byte): The byte representing the smallest or largest power of 256 in a multi-byte integer.
Display vs Internal Byte Order: TXIDs are stored little-endian internally but shown big-endian; the two look identical only by accident.
0x Prefix (Hex Literal): The conventional "0x" notation marking a hexadecimal literal in code and docs.
0xFD / 0xFE / 0xFF Prefixes (CompactSize Discriminators): Lead bytes of CompactSize telling the parser whether 2, 4, or 8 more bytes follow.
Magic Number / Magic Bytes (0xF9BEB4D9): The four-byte mainnet network identifier prefixed to every P2P message.
Scan Key (B_scan): In Silent Payments, the public key the recipient publishes that senders use to derive a unique output via ECDH.
Spend Key (B_spend): In Silent Payments, the static key the recipient uses to detect and spend incoming outputs.
Input Hash (BIP352 UTXO Binding): A hash binding a Silent Payment output to specific inputs, preventing wormhole attacks.
Label Mechanism (Silent Payments): A scheme letting one Silent Payment recipient distinguish payments for different purposes using labels.
Human Readable Names / HRN: A human-readable handle (₿alice@example.com) that resolves via DNSSEC to a Bitcoin payment instruction (BIP 353).
DNSSEC (DNS Security Extensions): Cryptographic signatures on DNS responses; BIP 353 relies on it for HRN resolution integrity.

Category

35 terms

HD Wallets

How a single seed phrase deterministically produces a whole tree of keys — and the BIPs that standardised it.

HD Wallet (Hierarchical Deterministic): A wallet that generates an unlimited tree of keys from one master seed via BIP32 derivation.
Mnemonic Seed: A 12–24 word phrase encoding the entropy from which the master seed is derived (BIP39).
Seed Phrase: Synonym for mnemonic seed — the words you write down to back up an HD wallet.
BIP 39: The standard mapping a 12/24-word phrase plus optional passphrase to a 512-bit seed via PBKDF2.
Wordlist (BIP 39): A fixed list of 2048 unambiguous words (English, Japanese, etc.) used to encode entropy.
Master Private Key: The root scalar in a BIP32 tree, derived from HMAC-SHA512("Bitcoin seed", seed).
Master Public Key: The public key corresponding to the master private key; gives view-only access to the whole subtree.
Master Extended Key: The master key bundled with its chain code, version, depth, fingerprint, and child index for serialization.
Extended Private Key: A 64-byte string (key || chain code) plus metadata; can derive any child key, private or public.
Extended Public Key (xpub): An extended public key; can derive child public keys but never private ones.
Chain Code: A 32-byte secret accompanying each key, used as the HMAC input during child derivation.
Child Keys: Keys derived from a parent via HMAC of the parent's key, chain code, and an index.
Hardened Child Keys: Children derived using the parent's private key (index ≥ 2^31); knowing the parent xpub does NOT leak them.
Normal Child Keys: Children derived using only the parent public key (index < 2^31); known parent xpub leaks all of them.
Derivation Path: A slash-separated sequence (m/44'/0'/0'/0/0) describing how to reach a specific key from the master.
BIP 32: The original HD wallet derivation specification.
BIP 44: Multi-account hierarchy: m/44'/coin'/account'/change/index, standard for legacy addresses.
BIP 49: Derivation path for P2SH-wrapped SegWit addresses (m/49').
BIP 84: Derivation path for native SegWit Bech32 addresses (m/84').
BIP 85: Deterministically derive other secrets (mnemonics, WIFs, hex entropy) from a single master seed.
Homomorphic Key Derivation: Property that non-hardened child pubkeys can be derived from a parent pubkey alone; the key-tweak math is linear.
ypub / zpub (SLIP-0132 Extended Key Prefixes): Version-byte variants of xpub indicating the intended script type (P2SH-SegWit, native SegWit).
SLIP-0044 (Coin Type Registry): A registry mapping each cryptocurrency to a coin-type index used in BIP44 paths.
Purpose (BIP 44 First-Level Index): The 44' / 49' / 84' / 86' field selecting which standard's derivation scheme is in use.
Gap Limit (Address Scan Threshold): How many unused consecutive addresses a wallet checks before stopping the scan (default 20).
Fingerprint / Key Fingerprint: The first four bytes of HASH160(pubkey); a short identifier used in PSBTs and descriptors.
Depth (HD Tree Level): How many derivation steps away a key is from the master; master is depth 0.
Master Seed (64-byte BIP39 Output): The 64-byte PBKDF2 output from a mnemonic phrase, fed into BIP32 to derive the master key.
Passphrase (BIP 39 "25th Word"): An optional extra string that, combined with the phrase, yields a totally different seed; gives plausible deniability.
Brain Wallet (Memorized Phrase, deprecated): A wallet whose seed is a memorized passphrase; broken in practice because human-chosen phrases lack entropy.
Key Sweep: Moving funds out of a single private key (e.g. paper wallet) into a fresh HD wallet output.
Range Descriptor (`/*` wildcard): A descriptor with a wildcard index, expanding into many child addresses for scanning.
Child Entropy (BIP 85): Deterministically derived randomness for creating independent child mnemonics from one master.
One-Way Derivation: Hardened derivation is non-invertible: child cannot reveal its parent.
83696968 (BIP 85 Magic Number): The BIP85 path prefix m/83696968' identifying derived-entropy outputs.

Category

75 terms

Transaction

How money moves: inputs, outputs, fees, signatures, sighash flags, and the formats that wrap them.

Transaction (Tx): A signed payload spending one or more UTXOs and creating new ones; every state change in Bitcoin is a tx.
Raw Transaction: The hex-serialized bytes of a transaction, ready to broadcast or analyze.
Transaction ID (TXID): HASH256 of a transaction's pre-witness serialization; used to reference outputs by (txid, vout).
wTXID (Witness TXID): HASH256 of the full transaction including witness data; commits to signatures and used in the witness commitment.
Input: A reference to a previous output being spent, plus the data (scriptSig/witness) authorizing the spend.
Output: An (amount, scriptPubKey) pair created by a transaction; spendable later by a tx whose input references it.
UTXO (Unspent Transaction Output): An output that hasn't been spent yet; your "balance" is the sum of UTXOs you can sign for.
UTXO Set: The complete set of currently-spendable outputs maintained by every full node — Bitcoin's state.
Outpoint: A pair (txid, vout) uniquely identifying one previous output being spent by an input.
VOUT (Output Index): The zero-based index of an output within its transaction.
ScriptSig: The legacy input field containing the data that satisfies the previous output's scriptPubKey.
ScriptPubKey: The locking script attached to an output; defines who can spend it.
Sequence Number: A per-input 32-bit field used originally for tx replacement; now signals RBF and encodes relative locktimes.
Locktime: Transaction-level field forbidding inclusion before a block height or Unix time.
Absolute Locktime: A locktime referring to a specific block height or timestamp.
Relative Locktime: Per-input delay encoded in sequence (BIP68); the input is only spendable N blocks/seconds after its parent confirmed.
Witness: Per-input field introduced by SegWit holding signatures and witness scripts outside the legacy serialization.
Witness Data: The collective signatures and scripts in a transaction's witness section.
Version (transaction v1/v2): The 4-byte first field of a transaction; v2 unlocks BIP68 relative locktimes via sequence.
Marker: The 0x00 byte that signals a SegWit-serialized transaction (followed by the flag byte).
Flag: The 0x01 byte after the marker indicating the presence of witness data.
Transaction Fee: The difference between total input value and total output value; collected by the miner.
Feerate: Fee divided by transaction virtual size; what miners actually sort by when filling blocks.
Satoshis per vByte (sat/vB): The standard fee-rate unit; multiply by tx vsize to get the total fee.
Dust Limit: A relay policy threshold below which outputs are uneconomical (cost more in fees to spend than they're worth).
Change Output: An output sending the leftover input value back to the sender, since UTXOs must be spent whole.
Transaction Malleability: Third-party ability to alter a TXID without invalidating signatures; fixed for legacy by BIP66 and for witness by SegWit.
Transaction Chain: A sequence of unconfirmed transactions where each spends the previous one; CPFP exploits this.
Coinbase Transaction: The first transaction in every block; has one input with no outpoint and creates the block subsidy plus fees.
Legacy Transaction: Pre-SegWit serialization without marker/flag/witness; still valid for spending legacy outputs.
SegWit Transaction: A transaction using SegWit serialization (BIP141); separates witnesses from the TXID.
Virtual Bytes (vBytes): Tx weight divided by 4; the unit used for feerate calculation that gives witness data a discount.
Weight Units: Per-byte cost: 4 WU for non-witness data, 1 WU for witness data; total block weight ≤ 4M WU.
Transaction Weight: Sum of all weight units in a transaction; determines block-space cost.
Transaction Size: Raw byte length of the transaction's serialization; less useful than vsize for fee purposes.
PSBT (Partially Signed Bitcoin Transaction): A standardized container for incomplete transactions, allowing signers and hardware wallets to interoperate.
PSBTv0: The original PSBT format (BIP174); inputs and outputs are listed in fixed positions.
PSBTv2: Updated PSBT (BIP370) allowing inputs and outputs to be added incrementally.
BIP 174: The original PSBT specification.
BIP 370: PSBTv2 specification, enabling input/output addition after creation.
SIGHASH_ALL: Default sighash type; signature commits to every input and every output.
SIGHASH_NONE: Signature commits to inputs only; outputs can be rewritten by anyone with the input access.
SIGHASH_SINGLE: Signature commits to the input's own corresponding output and all inputs; other outputs are free.
SIGHASH_ANYONECANPAY: Modifier letting other inputs be added after signing; useful for fundraisers and CoinJoin.
SIGHASH_DEFAULT: Taproot's 0x00 byte (omitted in serialization) meaning SIGHASH_ALL with the implicit-default flag.
Replace-by-Fee (RBF): A policy allowing a pending tx to be replaced by another with the same inputs and higher fee (BIP125).
Full RBF: A mempool policy accepting RBF replacement regardless of the original's opt-in signal; now the Bitcoin Core default.
CPFP (Child-Pays-for-Parent): Bumping a low-fee tx by spending its output in a child tx with a high fee; miners pick by package rate.
Package Relay (BIP 331): P2P messages letting miners receive parent+child as one unit so CPFP works even at the mempool edge.
v3 Transactions: A topology-restricted policy class (TRUC) with strict descendant rules, enabling reliable fee bumping for L2.
Ephemeral Anchors: Zero-value anyone-can-spend outputs paired with v3 packages to allow CPFP without UTXO bloat.
Transaction Batching: Combining many recipients into one transaction to share input fees.
Input & Output Ordering (BIP 69): Deterministic lexicographic ordering of inputs and outputs to remove a wallet fingerprint.
Spent Output: An output already consumed by a confirmed input.
Unspent Output: An output not yet spent; a UTXO.
Fee Estimation: Predicting the sat/vB needed for inclusion within N blocks by sampling recent mempool and block data.
Sigops (Signature Operations): A consensus-counted measure of script verification cost; blocks cap total sigops.
Payjoin (BIP 77/78): A collaborative two-input transaction breaking the heuristic that all inputs share an owner.
CoinJoin: A multi-party transaction mixing inputs and outputs to obscure ownership links.
Coin Control: Manually selecting which UTXOs to spend, instead of letting the wallet auto-select.
Transaction Pinning: A grief-attack where a low-fee descendant blocks CPFP/RBF of the parent.
ExtraNonce: A field in the coinbase's scriptSig that miners increment when the header nonce range is exhausted.
Witness Version (0, 1): A small integer in the scriptPubKey choosing which SegWit version (0 = SegWit v0, 1 = Taproot).
Sighash Type (Generic Category): The flag byte controlling what parts of the tx a signature commits to.
0-Conf (Zero Confirmation): An unconfirmed transaction; risky to accept because it can still be double-spent or replaced.
Confirmation Depth: How many blocks have built on top of a transaction's block; deeper = harder to reverse.
TRUC (Topologically Restricted Until Confirmation): Policy class enforcing single-child, small-package shape, removing pinning risk for L2 protocols.
Replay Attack: Broadcasting a valid tx from one chain (or context) on another; mitigated by chain-specific sighash data.
Absurd Fees: A policy check rejecting transactions whose fees are wildly disproportionate to their size, usually a wallet bug.
Anti-Fee Sniping: Setting locktime near the tip so miners can't profitably reorder this tx into an older block.
Package Fee Rate: The combined fee divided by combined size of a parent-child package; what miners sort by for CPFP.
Minimum Relay Fee Rate: Mempool floor (default 1 sat/vB) below which transactions are not relayed.
Ancestor Fee Rate Mining: A miner selection algorithm that picks transactions by their full ancestor-set feerate, not just their own.
CPFP Carve Out: A relay exception letting one extra small high-fee child evade mempool descendant limits, enabling reliable bumping.
Coinbase Input (Zero-Hash + 0xFFFFFFFF): A coinbase input's outpoint is 32 zero bytes plus vout 0xFFFFFFFF, since there's no previous output to reference.

Category

124 terms

Script & Authorization

The stack VM that decides whether a UTXO is spendable — opcodes, templates, and modern script trees.

Script: Bitcoin's purpose-built stack language; every locking and unlocking script is a script program.
Stack: The single LIFO data structure all script execution operates on; no variables, no registers.
Locking Script: The scriptPubKey on an output; specifies the spending conditions.
Unlocking Script: The scriptSig/witness in an input; provides the data that satisfies the lock.
Redeem Script: In P2SH, the script whose HASH160 appears in the output; revealed at spend time and then executed.
Witness Script: In P2WSH, the script whose SHA256 is committed in the output; placed at the end of the witness stack.
Script Execution: Sequential stepping through opcodes, mutating the stack until either a valid truthy stack remains or the script fails.
Stack Model: The execution model where every opcode reads from and writes to the same stack — no random access.
P2PK (Pay To Public Key): Original output template locking to a public key directly: <pubkey> OP_CHECKSIG.
P2PKH (Pay To Public Key Hash): Locks to HASH160(pubkey); spender supplies pubkey + sig. Standard "1..." legacy address.
P2MS (Pay To Multisig): Bare multisig template using OP_CHECKMULTISIG; nonstandard at the output level since 2014.
P2SH (Pay To Script Hash): Output commits to HASH160 of a redeem script; spender reveals the script + satisfying data (BIP16).
P2WPKH (Pay To Witness Public Key Hash): Native SegWit v0 version of P2PKH; witness holds sig + pubkey.
P2WSH (Pay To Witness Script Hash): Native SegWit v0 version of P2SH; commits to SHA256 of a witness script.
P2SH-P2WPKH: P2WPKH nested inside a P2SH for backward-compatibility with wallets that don't speak SegWit addresses.
P2SH-P2WSH: P2WSH wrapped in a P2SH; lets old wallets pay to native SegWit script outputs.
P2TR (Pay To Taproot): Witness v1 output committing to a tweaked Schnorr key encoding both a key path and an optional script tree.
OP_RETURN: Marks an output provably unspendable and stores up to 80 bytes of data; used for commitments and metadata.
Tapscript (BIP 342): Modified script language used in Taproot script-path spends; replaces OP_CHECKMULTISIG with OP_CHECKSIGADD, etc.
Miniscript: A typed, analyzable subset of Bitcoin Script that machines can compose, verify, and translate to/from policy.
MAST (Merkelized Abstract Syntax Tree): A Merkle tree of script alternatives; only the chosen branch is revealed at spend time.
Leaf Script: A single script at a leaf of a Taproot script tree; revealed when that branch is taken.
Leaf Hash: tagged_hash("TapLeaf", version || compact_size(script) || script) — the Merkle leaf.
Leaf Version: A byte (default 0xc0) identifying the script's execution rules; allows future Taproot script-language upgrades.
Control Block: The witness element supplying the Merkle path and internal key needed to verify a script-path spend.
Annex: An optional reserved 0x50-prefixed final witness element; designed for future Taproot extensions, currently must be ignored.
Taproot Key Path Spend: Spending a P2TR output by signing with the tweaked output key directly — looks like a single signature.
Taproot Script Path Spend: Spending by revealing one script-tree leaf, its Merkle path, and a satisfying witness.
Script Tree: The Merkle tree of leaf scripts committed to by a Taproot output's tweak.
Taproot Tweak: t = tagged_hash("TapTweak", internal_pubkey || merkle_root); the value added to the internal key.
Internal Public Key: The pre-tweak Schnorr public key whose tweak yields the output key; visible only on script-path spends.
Tweaked Public Key: The output key Q = P + t·G that actually appears on-chain in a P2TR scriptPubKey.
Taproot Output Key: Synonym for tweaked public key — the 32-byte key embedded in the P2TR output.
Covenants: Scripts that restrict where the spending transaction's outputs can go, not just whether it's authorized.
OP_CHECKSIG: Pops pubkey and signature, verifies signature against the tx sighash, pushes 1 or 0.
OP_CHECKMULTISIG: Verifies M of N signatures against N pubkeys; consumes an extra dummy stack item due to a 2010-era bug.
OP_CHECKSIGVERIFY: Like OP_CHECKSIG but fails the script if the signature is invalid (no 0/1 push).
OP_CHECKSIGADD: Tapscript replacement for OP_CHECKMULTISIG: pops sig, n, pubkey; pushes n+1 if sig is valid, else n.
OP_CHECKMULTISIGVERIFY: Legacy variant of OP_CHECKMULTISIG that fails the script on bad sig instead of pushing 0.
OP_DUP: Duplicates the top stack item; central to P2PKH.
OP_HASH160: Pops one item, pushes RIPEMD160(SHA256(item)).
OP_HASH256: Pops one item, pushes SHA256(SHA256(item)).
OP_EQUALVERIFY: OP_EQUAL followed by OP_VERIFY — both must pop equal items or the script fails.
OP_EQUAL: Byte-compares the top two stack items; pushes 1 if identical, 0 if different.
OP_VERIFY: Pops the top; if it's falsy, the entire script fails.
OP_IF: Pops a boolean; executes the following block if truthy, the OP_ELSE block if falsy.
OP_ELSE: Marks the alternative branch of an OP_IF.
OP_ENDIF: Closes an OP_IF / OP_NOTIF / OP_ELSE block.
OP_NOTIF: Like OP_IF but executes the block when the condition is falsy.
OP_DROP: Pops and discards the top item.
OP_SWAP: Swaps the top two items on the stack.
OP_OVER: Copies the second item to the top.
OP_ROT: Rotates the top three items so the third is moved to the top.
OP_ADD: Pops two numbers, pushes their sum (CScriptNum, 4 bytes max).
OP_SUB: Pops two numbers, pushes the second minus the first.
OP_0: Pushes an empty byte array — the canonical false and zero in Script.
OP_1 through OP_16: Single-byte opcodes pushing the integer 1..16 directly.
OP_1NEGATE: Pushes the integer −1 as a single byte (0x81).
OP_PUSHBYTES: Direct-push opcodes 0x01..0x4b; the opcode byte itself encodes the data length.
OP_PUSHDATA1: Push opcode with a 1-byte length prefix; up to 255 bytes of data follow.
OP_PUSHDATA2: Push opcode with a 2-byte little-endian length prefix.
OP_PUSHDATA4: Push opcode with a 4-byte length prefix; rarely used because of script size limits.
OP_CHECKLOCKTIMEVERIFY (CLTV): Compares stack value to tx locktime; fails if locktime is earlier — absolute timelock primitive (BIP65).
OP_CHECKSEQUENCEVERIFY (CSV): Compares stack value to the input's sequence number; encodes relative timelocks (BIP112).
OP_CAT (BIP 347): Concatenates the top two stack items; proposed reactivation enabling new covenant designs.
OP_CHECKTEMPLATEVERIFY / OP_CTV (BIP 119): Proposed covenant opcode committing to the exact shape of the spending transaction.
OP_CODESEPARATOR: Marks a position in the script after which signature hashes ignore preceding bytes; rarely used in practice.
OP_NOP: A no-op opcode; reserved variants (NOP2/NOP3) became CLTV/CSV via soft fork.
OP_SIZE: Pushes the byte length of the top item without removing it.
OP_DEPTH: Pushes the current number of items on the main stack.
OP_TOALTSTACK: Moves the top item from the main stack to the alt stack.
OP_FROMALTSTACK: Moves the top item from the alt stack back to the main stack.
OP_RIPEMD160: Pops one item, pushes RIPEMD-160 of it.
OP_SHA256: Pops one item, pushes SHA-256 of it.
OP_NIP: Removes the second item from the stack, leaving the top untouched.
OP_TUCK: Copies the top item and inserts it below the second item.
OP_PICK: Pops an integer n; copies the n-th item from the top of the stack onto the top.
OP_ROLL: Pops an integer n; moves the n-th item from the top to the top (removing it from its old position).
OP_BOOLAND: Pops two items; pushes 1 if both are truthy, else 0.
OP_BOOLOR: Pops two items; pushes 1 if either is truthy.
OP_NUMEQUAL: Pops two numbers; pushes 1 if they are numerically equal (not byte-equal).
OP_WITHIN: Pops x, min, max; pushes 1 if min ≤ x < max.
Opcode: A single one-byte instruction in Bitcoin Script; ~80 are active today.
Standardness Rules: Mempool policies (stricter than consensus) that nodes use to filter unusual transactions.
Non-standard Script: A script valid under consensus but not relayed by default nodes; still mineable if a miner accepts it.
Script Size Limits: Consensus caps: 10,000-byte script, 1,000-byte push, 201 non-push opcodes (legacy).
CLEANSTACK: Standardness rule requiring exactly one item left on the stack after script execution.
Hash Puzzle: A script that releases funds upon revealing a preimage of a committed hash.
Timelocks: Constraints (CLTV, CSV, nLocktime, sequence) preventing spending before a height or time.
Script Validity: A spend is valid iff combined scriptSig+scriptPubKey (or witness+script) executes to a truthy stack with no exceptions.
Sigops Budget: Per-block sigop limit (80,000); each CHECKSIG costs sigops to bound verification work.
Output Descriptors: A textual language (BIP380) precisely describing scripts and key derivation, e.g. wpkh([fp/84'/0'/0']xpub.../0/*).
Wallet Policies (BIP 388): A human-readable wrapper around descriptors letting hardware signers display policies clearly.
Forth-like Stack Language: Bitcoin Script's ancestry: a postfix language operating on a single stack, similar to the Forth programming language.
Turing Incompleteness: Bitcoin Script lacks unbounded loops or arbitrary recursion, so program halting is decidable — by design.
Turing Completeness: Property of languages that can simulate any computation; deliberately avoided by Bitcoin Script.
Stateless Script Verification: Each script can be validated without knowledge of other transactions — every input carries its own context.
Push (Stack Op): Placing a value on the top of the stack.
Pop (Stack Op): Removing the top value from the stack and returning it to the caller.
OP_TRUE: An alias for OP_1; pushes the single byte 0x01.
OP_FALSE: An alias for OP_0; pushes the empty byte array.
OP_NOT: Pops one item; pushes 1 if it was zero, else 0 (logical negation).
OP_SUCCESSx (Tapscript Reserved): Tapscript opcodes that succeed unconditionally and ignore the rest of the script — reserved for future use.
NOP1–NOP10 (Reserved Opcodes): Reserved opcodes safely ignored on legacy chains; can be soft-forked into real opcodes later.
VERIFY Opcode Family: Opcodes whose plain form pushes 0/1 and whose VERIFY variant aborts the script on failure.
Encumbrance: Any condition placed on spending an output — locktime, signature, hash preimage, etc.
Spending Condition: A clause within a script (one branch of an OP_IF or one MAST leaf) that, if satisfied, lets the output be spent.
Smart Contract: Any non-trivial script encoding multi-party logic; in Bitcoin always constrained by the Script VM.
Anonymity Set: The number of plausible spenders/recipients given on-chain data; large sets imply better privacy.
Provably Unspendable: An output whose script can never evaluate to true (e.g. OP_RETURN); the UTXO set need not track it.
Dummy Stack Element (NULLDUMMY Quirk): The extra item OP_CHECKMULTISIG pops due to a 2010 bug; BIP147 mandated it be the empty byte array.
Mutual Satisfaction Clause: A scripted condition requiring all parties to agree — the cooperative branch in many smart contracts.
Pay to Contract (P2C): Locking funds to a key tweaked by a hash of contract terms; spending reveals the terms or aborts.
Partial Private Key: One signer's share in a threshold or aggregate signing protocol.
Partial Public Key: A co-signer's public component combined with others to form an aggregate key.
Abstract Syntax Tree (AST): Tree representation of a program's structure; Miniscript and MAST treat script as a typed AST.
t-of-k Multisig: A multisig requiring t signatures out of a participating subset k.
m-of-n Multisig: The standard multisig phrasing: m valid signatures needed from a fixed pool of n keys.
Quorum: The minimum number of signers needed; same as the m in an m-of-n.
1 OP_RETURN Bug (Historical): Early bug allowing scripts to push 1 then OP_RETURN to short-circuit failure; long since fixed.
Proof-of-Existence (Digital Notary): Embedding a hash in OP_RETURN to prove a document existed at a given block time.
Descriptor Checksum (BIP380 8-char polynomial): A polynomial checksum appended to descriptors to catch transcription errors.
Leaf Version (0xc0 — default Tapscript leaf): The default leaf version identifying a standard Tapscript leaf in a Taproot script tree.
Key-only Taproot (no script tree committed): A P2TR output that commits to no script tree; the tweak still uses a NUMS or actual root for safety.

Category

39 terms

Block

The 80-byte header and the transaction batch beneath it — what miners actually produce.

Block Header: An 80-byte structure containing version, previous block hash, Merkle root, timestamp, bits, and nonce — the input miners hash.
Block Hash: HASH256 of the 80-byte header; the value miners must drive below the target.
Block Height: Zero-based index of a block from genesis; not part of the header — derived by counting.
Block Reward: Coinbase output value: subsidy + transaction fees.
Block Subsidy: The newly-minted bitcoin in the coinbase, halving every 210,000 blocks.
Block Time (10 minutes): Target average interval between blocks, maintained by the difficulty adjustment.
Block Size: The serialized byte length of a block; SegWit replaced this with weight as the consensus limit.
Block Weight: Weighted byte count: witness data counts 1 WU, everything else 4 WU; capped at 4 million WU.
Block Serialization: Header + transaction count + raw transactions; SegWit-aware nodes use the witness format.
Block Validation: Verifying header PoW, timestamp rules, transaction validity, Merkle root, and consensus limits.
Genesis Block: The first block, hardcoded into every implementation; its coinbase contains the famous Times headline.
Previous Block Hash: The 32-byte hash linking each block to its parent, making history tamper-evident.
Merkle Root: 32-byte root of the binary Merkle tree of TXIDs; commits the header to every included tx.
Merkle Tree: Hash tree letting compact proofs prove that a leaf is in the set without revealing the rest.
Nonce: A 32-bit field miners increment while searching for a valid block hash.
Bits (difficulty encoding): Compact 32-bit encoding of the current target threshold.
Version (block): 4-byte header field; bits used to signal soft-fork readiness via versionbits.
Time (block timestamp): 4-byte Unix timestamp; loose rules (median past, 2-hour future) allow honest miners flexibility.
blk.dat: Bitcoin Core's on-disk block storage files; raw block data in order received.
Block Template: A JSON skeleton sent by a node to a miner via getblocktemplate, ready to be hashed.
getblocktemplate: BIP22/23 RPC giving miners a node-validated block to work on.
Block Space: The scarce resource bidders compete for via fees; bounded by weight per block.
Weight Limit (4,000,000 WU): Consensus cap on a block's weight; effectively ~1.8–4 MB depending on witness ratio.
Unix Timestamp: Seconds since 1970-01-01 UTC; format used in headers and locktimes ≥ 500,000,000.
Median Time Past (MTP): Median of the previous 11 block timestamps; used as the canonical "now" for locktimes.
wTXID Commitment: A coinbase OP_RETURN committing to a Merkle root of all wTXIDs; required since SegWit.
chainstate (Bitcoin Core UTXO DB): A LevelDB index of the UTXO set, kept in chainstate/ on disk.
rev.dat (Undo Files): Files storing reverse data so a block can be undone during reorgs.
Block Index (LevelDB folder): Bitcoin Core's LevelDB tracking each block's file location and metadata.
merkleblock (P2P Message): A P2P message containing a block header plus a partial Merkle tree for SPV proofs.
Undo Data: Per-block info needed to restore the chainstate when disconnecting that block.
Coinbase Maturity (100 blocks): Coinbase outputs cannot be spent until 100 confirmations to absorb reorg risk.
Background Validation (AssumeUTXO): New nodes import a UTXO snapshot and validate prior history in the background.
Time Field (Header Offset 68): Bytes 68–71 of the header hold the timestamp; relevant when manually parsing headers.
2-Hour Rule (Future Block Timestamp): A block's timestamp may not be more than 2 hours ahead of network-adjusted time.
Nonce Space (4.29B Range): 2^32 possible nonce values; at modern hashrates this exhausts in microseconds, hence ExtraNonce.
Nonce k (Signing Scalar): In ECDSA/Schnorr signing, the per-message random scalar; distinct from the block-header nonce.
Witness Root Hash: Merkle root of wTXIDs committed in the coinbase output for SegWit.
Target Bits (Compact Encoding): A 4-byte float-like encoding of the 256-bit target stored in the bits field.

Category

39 terms

Blockchain

Chains of blocks, forks, reorgs, and how the network settles on one history.

Chain Height: The block height of the current tip of the most-work chain.
Longest Chain Rule: Old name for "most-work chain"; the chain with the greatest cumulative proof-of-work wins.
Chain Reorganization: When a competing chain with more work appears, nodes disconnect blocks until they reach a common ancestor and reconnect the new chain.
51% Attack: Controlling >50% of hashrate to rewrite recent history; expensive but not impossible.
Hard Fork: A consensus rule loosening; old nodes reject the new chain. Requires every node to upgrade.
Soft Fork: A consensus rule tightening; old nodes still see the new chain as valid. Backward compatible.
Orphan Block: A block whose parent is unknown to a node; held until the parent arrives.
Stale Block: A valid block at the tip that loses the race to a competing block at the same height.
Double Spend: Attempting to spend the same UTXO twice; rejected by all honest nodes.
AssumeUTXO: Bitcoin Core feature letting nodes start from a hash-pinned UTXO snapshot, validating older blocks in the background.
Checkpoints: Hard-coded block hashes shipped in the client; mostly historical, now superseded by AssumeValid.
Initial Block Download (IBD): The phase a new node spends downloading and validating the chain from genesis.
Fork: Any divergence — software, network, or rules — producing two competing chains or codebases.
Chain Split: When two persistent chains coexist following a contentious fork.
Finality: Probabilistic in Bitcoin: each confirmation makes reversal exponentially harder.
Immutability: The practical inability to change confirmed history without redoing all subsequent proof-of-work.
Distributed Ledger: A ledger replicated across many independent nodes; Bitcoin's blockchain is one.
Block Confirmation: Each additional block built on top of yours counts as one confirmation.
Reorg Depth: How many blocks need to be disconnected during a reorg; deeper reorgs are vanishingly rare.
Assumed Valid: A precomputed hash up to which Bitcoin Core skips signature checks; assumes the developers vetted the chain.
Chainwork (Cumulative PoW): A node's estimate of total work in the chain; determines the heaviest chain.
Heaviest Chain: The chain with the greatest cumulative chainwork — Bitcoin's actual consensus rule.
Common Ancestor (Reorg Divergence Point): The most recent block shared by two competing chains during a reorg.
Pruned Node: A full node that discards old block data after validating, keeping only recent blocks + the UTXO set.
chainparams.cpp (Network Parameters): The Bitcoin Core file containing magic bytes, genesis block, port, and consensus parameters per network.
dbcache (UTXO Cache Size): Bitcoin Core option setting how much UTXO data is kept in RAM; affects IBD speed.
LevelDB (Embedded KV Store): Google's on-disk key-value store; Bitcoin Core uses it for the UTXO and block indexes.
UTXO Snapshot: A serialized UTXO set at a specific height; used by AssumeUTXO to bootstrap nodes.
Nakamoto Consensus: Bitcoin's consensus rule: nodes follow the chain with the most cumulative proof-of-work.
Rule Loosening (Hard Fork Direction): Changing rules so previously-invalid blocks become valid; old nodes will reject.
Rule Tightening (Soft Fork Direction): Changing rules so previously-valid blocks become invalid; old nodes still accept the smaller set.
Chain Linking (Hash-Pointer Mechanism): Each block stores its parent's hash, cryptographically linking history.
Timestamp Proof: Inclusion in a Bitcoin block proves data existed by the time the block was mined.
Topological Order: Transactions must follow dependency order within a block — no input can reference an output later in the same block before that output exists.
Independent Transaction Verification: Each tx is validated against the UTXO set alone, without external state.
Independent Block Verification: Each block validates against consensus rules without trusting other nodes' opinions.
Forward Compatibility: Old nodes can keep running while new rules are added via soft fork.
Forward Incompatibility: A hard fork requires every node to upgrade or be left behind on the minority chain.
Best Blockchain: A node's currently-favoured chain — the one with the most chainwork it has fully validated.

Category

6 terms

Forks (Extended)

Less common but important kinds of forks beyond hard/soft.

Software Fork (Alternative Client): A different codebase implementing the same consensus rules; useful for client diversity.
Mining Fork (Miner-Driven Divergence): A temporary divergence caused by two miners finding blocks at the same height.
Network Fork (Node Partition): A split caused by network partitioning; resolves when connectivity returns.
Contentious Hard Fork: A hard fork without economic consensus, creating two persistent chains and assets.
Spontaneous Fork (Propagation Race): Routine, short-lived fork happening when two valid blocks race to propagate.
Buried Deployment (BIP 90): Once a soft fork is deep enough in the chain, its activation logic is removed in favour of an unconditional rule.

Category

41 terms

Mining

The energy-secured lottery: ASICs, difficulty, halvings, and the economics of block production.

Mining: Repeatedly hashing block headers until you find one whose hash is below the target.
Proof of Work: A scheme where producing a valid block requires demonstrably expending energy.
Hashrate: Number of header hashes attempted per second across the network — currently exahashes per second.
Hash Power: Same as hashrate; a measure of mining capacity.
Difficulty: A scaled inverse of the target; the difficulty-1 target corresponds to the highest threshold ever used.
Difficulty Adjustment: Every 2016 blocks, the target is rescaled so the next epoch averages 10-minute blocks.
Retarget Period (2016 blocks): The block interval over which difficulty is recalculated, ≈ two weeks.
Target: A 256-bit number the block hash must be below for the block to be valid.
Nonce Exhaustion: When all 2^32 header nonces have been tried; miners then bump ExtraNonce in the coinbase.
Halving: Every 210,000 blocks the subsidy halves, driving Bitcoin's asymptotic 21M supply.
21 Million Cap: The asymptotic upper bound on the total supply, set by the halving schedule.
Supply Schedule: Predetermined issuance over time; each halving cuts the per-block subsidy in half.
Issuance: New bitcoin coming into existence via coinbase outputs; ends when subsidies round to zero.
Memory Pool (Mempool): A node's set of validated unconfirmed transactions waiting for inclusion in a block.
Candidate Block: A block-template assembled by a miner but not yet found a valid PoW.
Transaction Selection: Choosing which mempool txs to include in a candidate block, usually by feerate.
Mining Pool: A group of miners sharing rewards proportional to contributed work to smooth income.
Pool Share: A low-difficulty hash submitted to a pool as evidence of work.
PPLNS (Pay Per Last N Shares): Pool payout scheme paying members based on their shares within the last N submitted.
PPS (Pay Per Share): Pool payout scheme paying a fixed amount per accepted share; pool takes variance risk.
Stratum Protocol: The standard pool-to-miner protocol over TCP for distributing work and accepting shares.
Stratum V2: Encrypted, miner-empowering Stratum revision allowing miners to compose their own block templates.
DATUM Protocol: A Stratum-like protocol enabling individual miners to construct templates against a local node.
Selfish Mining: Hash-power-strategy where a miner withholds blocks to gain a relative-revenue advantage.
Merged Mining: Mining two chains simultaneously by committing the auxiliary chain's work in Bitcoin's coinbase.
Mining Hardware (ASIC): Application-specific chip optimized for SHA-256d; GPUs and FPGAs are obsolete for Bitcoin.
Mining Difficulty: Synonym for difficulty.
Fee Revenue: Total tx fees a miner collects in a block; share of total reward grows as subsidy shrinks.
Hashrate Security (Attack Cost): Cost a 51% attacker would incur to outpace honest miners.
Retargeting Bias (0.05% Off-by-One): Difficulty retargets use 2015-block interval, not 2016 — a tiny systematic bias.
Target Timespan (1,209,600s): Two weeks in seconds; the ideal time for 2016 blocks.
Subsidy Halving Interval (210,000): Blocks per halving epoch; ≈ four years.
Hash Lottery: Each hash attempt is an independent Bernoulli trial against the target; mining is sampling.
P2Pool (Decentralized Pool): A peer-to-peer mining pool eliminating the central pool operator.
Share Chain: The auxiliary chain inside P2Pool tracking miner shares for reward distribution.
Solo Mining: Mining without a pool; income is high-variance but unmediated.
Managed Pool: A traditional pool with a central operator distributing work and rewards.
Mining Reward (Subsidy + Fees): Total a miner earns per block: the coinbase subsidy plus collected fees.
Coinbase Reward Maturity: The 100-block delay before coinbase outputs become spendable.
Currency Issuance Rate: BTC minted per unit time; depends on subsidy and block discovery rate.
Moore's Law (Hardware Density): Historical trend of doubling transistor density; relevant for ASIC efficiency gains.

Category

34 terms

Networking

How nodes find peers, exchange transactions and blocks, and stay in sync.

Full Node: A node that downloads and verifies every block and transaction against consensus rules.
Light Node (SPV Node): A node that downloads only headers and uses Merkle proofs to verify specific transactions.
SPV (Simplified Payment Verification): Verifying inclusion of a tx by checking its Merkle proof against a downloaded header chain.
Bloom Filter: A probabilistic filter an SPV node sends so full nodes only forward potentially-relevant transactions.
Peer: Another node your node has an open connection to.
Peer Discovery: Finding new peers via DNS seeds, hard-coded seeds, or peer-exchange messages.
DNS Seed: A DNS hostname returning A-records of well-known node IPs; bootstrap mechanism.
Magic Bytes: The 4-byte network identifier prefixing each P2P message frame.
P2P Messages: The set of message types (version, ping, inv, getdata, tx, block, etc.) defined by the Bitcoin protocol.
inv Message: Inventory announcement: "I know about these txids/block hashes."
getdata Message: Request for specific items previously inv'd.
tx Message: A serialized transaction sent in response to getdata.
block Message: A full serialized block.
headers Message: A list of block headers without transaction bodies.
addr Message: Gossip-style sharing of peer addresses for discovery.
addrv2 Message: BIP155 variant supporting Tor v3, I2P, and CJDNS addresses.
version Handshake: Initial peer exchange of version + verack messages establishing protocol capabilities.
Transaction Propagation: How a tx is gossiped through inv/getdata cascades across the network.
Block Propagation: Spreading a newly mined block to peers; Compact Blocks dramatically reduces bandwidth.
Compact Blocks (BIP 152): Sending only short-IDs of txs in a block, since peers usually already have the full tx.
Erlay (BIP 330): Set-reconciliation-based mempool sync that reduces bandwidth from O(n²) gossip.
Dandelion++ (BIP 156): Two-phase tx propagation hiding the origin IP by stem-then-fluff broadcast.
Tor: Onion-routing overlay network; running a node over Tor hides its IP from peers.
I2P: Garlic-routing peer-to-peer overlay; an alternative anonymity network.
Mempool Policy: Per-node rules for accepting or evicting unconfirmed transactions, distinct from consensus.
Mempool Eviction: Removing low-feerate transactions when the mempool reaches its size cap.
Transaction Relay: Forwarding received valid transactions to peers, subject to policy filters.
Network Synchronization: The process of bringing a new node's view of the chain and mempool up to date with the network.
Feeler Connection: Brief outbound connection to test a peer's liveness before committing to it long-term.
Inbound / Outbound Peers: Peers that initiated the connection to you vs. peers you reached out to; outbound is harder to eclipse.
Propagation Delay (Orphan Cause): Time taken to spread a new block; longer delays create more stale blocks.
RDRAND (Hardware RNG Instruction): Intel CPU instruction returning random bytes; Bitcoin Core mixes it with other entropy sources.
Cluster Mempool: Bitcoin Core 31.0 mempool design grouping transactions by ancestry into clusters, improving fee-driven selection.
Chunk (Mempool): A feerate-sorted subdivision of a mempool cluster; the unit miners pick from.

Category

16 terms

Security Attacks

Threat models and named attacks every Bitcoin practitioner should recognise.

Eclipse Attack: Isolating a node by monopolizing its peer connections to feed it a fake chain or censor its data.
Sybil Attack: Filling the peer network with attacker-controlled identities to skew gossip or peer selection.
Fee Sniping: Mining attempting to rewrite recent blocks to capture their fees; mitigated by anti-fee-sniping locktimes.
Time-Warp Attack: Manipulating timestamps within difficulty rules to bring difficulty down on a minority chain.
Address Reuse: Spending from or receiving repeatedly on the same address; leaks privacy and risks key compromise.
Selfish Mining Attack: Withholding blocks to gain disproportionate relative reward; profitable above ~33% hashrate.
Double Spend Attack: Broadcasting two conflicting txs hoping a service accepts one as confirmed before the other reorgs it.
Dust Attack: Sending tiny amounts to many addresses hoping to trace them when consolidated.
BGP Hijacking: Reannouncing IP routes at the internet-routing level to intercept Bitcoin traffic.
Race Attack: Broadcasting one tx to the victim and a conflicting one to the network simultaneously, hoping miners pick the latter.
Finney Attack: A premined block containing a double-spending tx is held until the victim accepts the conflicting unconfirmed tx.
Pinning Attack: Stalling fee-bumping by submitting a low-fee descendant that blocks RBF/CPFP via mempool policy limits.
Long-range Attack: An attack relying on rewriting history from far back; mitigated by checkpoints and chainwork.
Wormhole Attack: In Silent Payments or PTLCs, a routing-layer attack stealing fees by short-cutting the path.
Chain Analysis: Heuristic clustering of on-chain activity to deanonymize users; CoinJoin and other techniques resist it.
Takeover Attack (Hashrate Acquisition): Buying or renting enough hashpower to attempt a 51% reorg.

Category

18 terms

Wallet Security & Practices

Operational habits and architectures that keep keys safe.

Root of Trust (Security Architecture): The single point you must trust because everything else derives from it — usually a hardware signer.
Cold Storage (Offline Keys): Keys stored on devices never connected to the internet, dramatically reducing remote attack surface.
Hot Wallet (Online, Vulnerable): A wallet whose keys exist on an internet-connected device; convenient but exposed.
Hardware Signing Device: A purpose-built device that holds keys, signs txs internally, and returns signed transactions only.
Tamper-Proof Hardware (Secure Element): Specialized chips designed to resist physical extraction; used in hardware wallets.
Concentric Circles of Trust: Layered architecture: small hot funds in convenient wallets, large reserves in cold storage.
Pocket Change Strategy: Keeping only spending-money in a hot wallet, like cash in a pocket vs. savings in a vault.
Estate Planning (Bitcoin Inheritance): Designs (multisig with timelocks, dead-man switches) that pass funds to heirs without exposing them prematurely.
Wallet Recovery Codes: Additional backup material — passphrase shares, recovery seeds — beyond the primary mnemonic.
Keyboard Monitoring (Keylogger): Malware logging keystrokes; a major reason never to type a seed phrase on an online machine.
Mass Compromise (Centralized Failure): Single-point failures (exchange hacks) draining many users at once.
Trojan Infection: Software masquerading as legitimate but stealing keys when run.
Identity Theft: Impersonating you to drain accounts, often paired with SIM-swap attacks.
Eavesdropping: Passive interception of traffic; encryption and Tor mitigate it.
Risk Diversification: Spreading funds across wallets, devices, and locations to limit any single failure.
Encrypted Wallet File: A wallet file protected by a passphrase such that extracting keys requires the password.
Paper Wallet Backup: Seed phrase printed on paper; cheap and offline but susceptible to fire, water, and decay.
Metal Backup (Stamped/Engraved): Seed phrase stamped or engraved on metal; resists fire, water, and corrosion.

Category

10 terms

Protocol Economics

The fee market, block-space scarcity, and the post-subsidy security budget.

Fee Market: The auction for block space where higher-fee transactions get included sooner.
Block Space Market: Synonym for fee market — the constrained resource users bid for.
Block Reward Curve: The deterministic decay of subsidy plus the rising share of fees, forming long-term miner revenue.
Subsidy Decay: The geometric decline in coinbase subsidy across halvings.
Transaction Fee Revenue: Miner income from fees; increases in share as subsidy declines.
Sat/vByte: Satoshis per virtual byte — the canonical feerate unit.
Replace-by-Fee Market: The implicit fee-bidding war when an unconfirmed tx is replaced upward to chase confirmation.
Mempool Congestion: When demand for block space exceeds supply and feerates rise.
Fee Bumping: Increasing the effective feerate of a pending tx (via RBF or CPFP) to speed confirmation.
Economic Node: A node operated by an economic actor (exchange, custodian) that meaningfully enforces consensus.

Category

48 terms

Lightning Network

Off-chain payment channels and routed micropayments built on top of Bitcoin.

Lightning Network: A network of payment channels enabling instant, cheap Bitcoin payments off-chain.
Payment Channel: A 2-of-2 multisig output funded by both parties; balance is rewritten off-chain via signed commitment txs.
Channel Open Transaction: The funding transaction creating the channel's on-chain anchor UTXO.
Channel Close Transaction: Any on-chain transaction spending the channel UTXO, ending the channel.
Cooperative Close: Both parties sign a fresh tx splitting the current balance; lowest-fee close path.
Force Close: One party broadcasts the latest commitment tx unilaterally; pays higher fees and triggers timelocks.
Commitment Transaction: A pre-signed off-chain tx representing the current channel balance; spendable but penalized if old.
Revocation Key: A key that, when leaked to the counterparty during a state update, lets them punish a force-close of the old state.
HTLC (Hash Time Locked Contract): An in-channel conditional payment unlocked by revealing a hash preimage before a timeout.
PTLC (Point Time Locked Contract): HTLC's Schnorr/adaptor-signature successor; no on-chain payment hash, better privacy.
Preimage: The secret r such that H(r) equals the published payment hash; revealing r claims the HTLC.
Payment Hash: The hash committed to in an HTLC; the receiver reveals its preimage to settle.
Invoice: A signed payment request encoding amount, hash, and routing hints; the customer's bill.
BOLT11 Invoice: Legacy Bech32-encoded Lightning invoice (rough equivalent of a URL).
BOLT12 / Offers: A signed long-lived offer format supporting reusable payment requests and refunds.
BOLT Specifications: The "Basis of Lightning Technology" specs — the protocol bible.
Onion Routing (Lightning): Source routing where each hop only sees the previous and next hop, not the full path.
Sphinx Packet: The fixed-size onion packet format used to route Lightning HTLCs.
Routing: Finding a path of channels with sufficient balance from sender to recipient.
Pathfinding: Algorithmic search over the gossip graph for routes optimizing fees and reliability.
Liquidity: Funds available in a channel to send (outbound) or receive (inbound).
Inbound Liquidity: Capacity on the remote side of a channel — what limits how much you can receive.
Outbound Liquidity: Capacity on your side of a channel — what limits how much you can send.
Watchtower: A third-party service watching the chain for old channel states and broadcasting penalties on your behalf.
Penalty Transaction: The tx a wronged party broadcasts using the revocation key to claim all funds when a counterparty cheats.
Justice Transaction: Another name for the penalty transaction.
Channel Capacity: Total bitcoin locked in a channel; the upper bound on any single payment through it.
Splicing: Resizing a channel in-place by spending the funding UTXO into a new larger or smaller one.
Submarine Swap: Atomic swap between on-chain BTC and a Lightning payment using HTLCs.
Atomic Swap: A trade between two parties on different chains/layers that either fully completes for both or fully reverts.
Channel Factory: A multi-party construction where many channels share a single on-chain funding UTXO.
LSP (Lightning Service Provider): A commercial node providing channels, liquidity, and routing services to end users.
LNURL: A simple URL-based protocol layering features (login, pay-to-domain) on top of LN invoices.
Anchor Output: Small CPFP-able output added to commitments so either party can bump fees at force-close time.
Gossip Protocol (Lightning): How nodes share channel announcements and updates across the LN graph.
Spillman-Style Payment Channel (Unidirectional): Early one-way channel design predating LN; sender to receiver only.
Asymmetric Revocable Commitments: LN's scheme where each party holds a different commitment tx, each revocable by the other.
Free American Call Option Problem: Pre-LN issue where one party could selectively cash out at the most favourable old state; solved by revocation.
HTLC Forwarding: Intermediate-node operation of locking an outgoing HTLC contingent on receiving the incoming one's preimage.
Native Forwarding: Forwarding an HTLC without intermediate currency conversion.
Translated Forwarding: Forwarding where the hop translates between asset types or currencies.
Channel Announcements: Gossip messages declaring a public channel's existence with both nodes signing.
Channel State Advancement: Updating channel balances by signing new commitment txs and exchanging revocation secrets.
Refund Transaction: In some channel constructions, a pre-signed tx allowing the funder to recover funds if the channel never opens fully.
BOLT Repository: The GitHub repo at github.com/lightning/bolts containing the BOLT specs.
Funding Transaction: On-chain tx creating the channel's 2-of-2 UTXO; same as Channel Open Transaction.
Settlement Transaction: A finalized on-chain payout of the channel's current balance, especially at cooperative close.
Unilateral Channel Closure: Synonym for force close — one party closing without the other's cooperation.

Category

24 terms

Layer 2 & Overlays

Higher-layer protocols using Bitcoin for settlement or commitments.

Layer 2: Any protocol settling onto Bitcoin while operating mostly off-chain (LN, Ark, sidechains).
Ark Protocol: A shared-UTXO protocol providing instant payments with periodic on-chain settlement and unilateral exits.
Virtual UTXO (vUTXO): An Ark balance that behaves like a UTXO but lives off-chain inside a shared output.
Fedimint: A federated Chaumian e-cash mint backed by a multisig holding bitcoin.
Chaumian eCash: David Chaum's blind-signature based digital cash, providing strong sender privacy.
Sidechain: A separate blockchain pegged to Bitcoin, often with a federated or burn-and-mint peg.
State Channel: A general off-chain protocol updating state between parties using on-chain settlement as backstop.
BitVM: A scheme letting two parties verify arbitrary computation by responding to challenges on Bitcoin.
RGB Protocol: A client-side-validated asset protocol using Bitcoin only as a commitment medium.
Ordinals: A numbering scheme assigning identities to individual satoshis; used to track ordinal-based assets.
Inscriptions: Arbitrary data inscribed onto a satoshi via a witness, viewable by ordinal-aware indexers.
Runes Protocol: A simpler UTXO-based fungible-token protocol using OP_RETURN commitments.
BRC-20: A speculative meme-token standard built on Ordinals inscriptions; not a Bitcoin protocol per se.
Client-side Validation: A pattern where the network only commits to data and clients validate semantics themselves.
DLC (Discreet Log Contract): A 2-of-2 contract whose outcome is determined by an oracle signature over a specific event.
Taproot Assets: Lightning-Labs protocol issuing assets via Taproot commitments and routing them over LN.
Drivechain: A proposed sidechain peg model where miners vote on withdrawal aggregation.
Merged Mining Sidechain: A sidechain whose blocks are produced by Bitcoin miners simultaneously hashing for both.
Unilateral Exit: The ability to leave an L2 system back to the base chain without permission from other parties.
VTXOs (Virtual Transaction Outputs): Ark's term for virtual UTXOs participants own off-chain.
Single-Use Seals (RGB Primitive): A construction binding ownership to a Bitcoin UTXO so spending it transfers the asset.
EPOBC (Enhanced Padded-Order-Based Coloring): A legacy colored-coin protocol; mostly historical.
Lighthouse (Assurance Contracts): A crowdfunding protocol where pledges are valid only if a target is met.
Colored Coins (Legacy): Early protocols tagging satoshis to represent off-chain assets; mostly obsolete.

Category

88 terms

Upgrades & BIPs

The proposal process and the major upgrades that shaped Bitcoin.

Segregated Witness (SegWit, BIP 141): The 2017 upgrade separating witness data, fixing tx malleability, and introducing weight units.
Taproot (BIP 341): The 2021 upgrade introducing key-aggregable Schnorr signatures and Merkleized script trees.
Tapscript (BIP 342): Script-language updates accompanying Taproot — new opcodes, removed limits.
Schnorr (BIP 340): The Schnorr signature spec adopted by Taproot.
BIP Process: The community workflow for proposing, discussing, and tracking changes to Bitcoin.
Soft Fork Activation: The mechanism (versionbits, MASF, UASF, Speedy Trial) by which soft forks turn on.
MASF (Miner-Activated Soft Fork): Activation triggered by miner signaling in block versions.
UASF (User-Activated Soft Fork): Activation enforced by economic nodes regardless of miner signaling.
Speedy Trial: A short activation window used for Taproot: miners signal within three months or activation aborts.
Versionbits (BIP 9): The signaling mechanism reserving block-version bits for pending soft forks.
CISA (Cross-Input Signature Aggregation): Future Schnorr feature aggregating signatures across all inputs into one.
OP_CAT (BIP 347): Proposal to re-enable string concatenation in Script, enabling new covenant designs.
OP_CTV (BIP 119): Proposed covenant opcode committing to the exact spending tx shape.
OP_VAULT (BIP 345): Proposed vault primitive enabling timelocked recovery flows on-chain.
SIGHASH_ANYPREVOUT (BIP 118): Proposed sighash flag enabling signatures that don't commit to a specific previous output.
Package Relay (BIP 331): P2P primitive for relaying parent-child packages so CPFP fee bumps survive mempool eviction.
Erlay (BIP 330): Bandwidth-efficient mempool reconciliation; reduces redundant tx gossip.
Compact Blocks (BIP 152): Bandwidth-efficient block relay using short transaction IDs.
Silent Payments (BIP 352): Reusable static-address scheme deriving fresh outputs per payment via ECDH.
OP_CHECKSIGFROMSTACK: A proposed opcode verifying a signature against a message taken from the stack, enabling arbitrary delegation.
LNHANCE: A proposal bundling OP_CTV, OP_CSFS, and OP_PAIRCOMMIT to advance Lightning use-cases.
Great Script Restoration: A proposal restoring legacy opcodes (OP_CAT, OP_MUL, etc.) inside Tapscript.
OP_INTERNALKEY: A proposed opcode pushing the internal key of the current Taproot output onto the stack.
Covenant Proposal: Any of the active covenant proposals (CTV, CCV, VAULT, etc.) shaping Bitcoin's next decade.
BIP 388 (Wallet Policies): A standard for human-readable wallet policies built on top of output descriptors.
BIP 47 (Reusable Payment Codes): Early reusable static-address scheme using notification transactions and Diffie-Hellman.
BIP 144 (SegWit Transaction Serialization): Spec for the marker/flag/witness-bearing transaction serialization.
BIP 158 (Compact Block Filters): Golomb-coded filters letting light clients fetch only relevant blocks without bloom filters.
BIP 173 (Bech32 Spec): The native SegWit v0 address encoding.
BIP 327 (MuSig2 Spec): Standard for the MuSig2 multi-signature protocol.
BIP 350 (Bech32m Spec): The Bech32 variant fixing the witness-version mutation issue; used for v1+.
BIP 380–386 (Output Descriptors Family): The family of specs defining output descriptors and their semantics.
BIP 1 (BIP Purpose & Guidelines): The meta-spec describing what BIPs are and how to author them.
BIP 11 (Multisig Outputs): The original bare-multisig spec.
BIP 13 (P2SH Address Format): The "3..." Base58Check P2SH address encoding.
BIP 14 (User Agent / Subversion String): The free-form user-agent string in the version message.
BIP 16 (P2SH Evaluation Rules): The 2012 soft fork defining P2SH semantics.
BIP 21 (Bitcoin Payment URI): The bitcoin: URI scheme for payment requests.
BIP 22 (Getblocktemplate RPC): The miner RPC for fetching node-validated block templates.
BIP 23 (Getblocktemplate Extensions): Extensions to getblocktemplate including coinbase customization.
BIP 30 (Duplicate Tx Prevention): Rule preventing two transactions with the same TXID in the UTXO set.
BIP 31 (Pong Message): Adding a pong response to ping for liveness checks.
BIP 34 (Coinbase Height, Block v2): Required block height in the coinbase scriptSig; first soft fork via version bits.
BIP 35 (Mempool Protocol Message): P2P message letting peers request another's mempool.
BIP 37 (Bloom Filter for Light Clients): Bloom-filter-based filtering for SPV; now deprecated in favour of BIP158.
BIP 42 (Subsidy Schedule Bug Fix): Fix preventing infinite subsidy growth from integer overflow far in the future.
BIP 43 (HD Wallet Purpose Field): Introduced the purpose' field for derivation paths.
BIP 61 (Reject Message): P2P reject message; deprecated due to leaking node policy.
BIP 65 (CHECKLOCKTIMEVERIFY): The 2015 soft fork enabling absolute timelocks via OP_CLTV.
BIP 66 (Strict DER Signatures): The 2015 soft fork enforcing canonical DER signature encoding.
BIP 68 (Sequence Locks): Reinterpreting the input sequence field as relative timelocks (with BIP112).
BIP 70 / 71 / 72 (Payment Protocol): A merchant-side payment-request protocol; mostly deprecated due to centralization concerns.
BIP 86 (HD Derivation for Taproot): Standard derivation paths for single-key Taproot addresses (m/86').
BIP 90 (Buried Deployments): Hard-coding old soft-fork activations into the client to remove versionbits checks.
BIP 111 (NODE_BLOOM Service Bit): Service bit advertising that a node supports BIP37 bloom filtering.
BIP 112 (CHECKSEQUENCEVERIFY): The 2016 soft fork enabling relative timelocks via OP_CSV.
BIP 113 (Median Time Past Locktime): Replacing block timestamp with MTP for locktime evaluation.
BIP 114 (Early MAST Proposal): An early Merkleized AST proposal predating Taproot.
BIP 116 (MERKLEBRANCHVERIFY): An early proposal for Merkle inclusion checks in script.
BIP 125 (RBF Signaling): The opt-in Replace-by-Fee signaling spec via sequence numbers.
BIP 130 (Direct Headers Announcement): Letting peers announce new blocks as headers rather than inv messages.
BIP 133 (Fee Filter Message): P2P message advertising a peer's minimum-feerate filter.
BIP 143 (Witness Tx Sig Verification): The SegWit sighash algorithm fixing quadratic-hashing complexity.
BIP 145 (Getblocktemplate for SegWit): Extending getblocktemplate to expose witness-related fields.
BIP 147 (NULLDUMMY Soft Fork): Mandating the dummy element of OP_CHECKMULTISIG be empty.
BIP 155 (Addrv2 / Sendaddrv2): Expanded peer-address message supporting Tor v3, I2P, and CJDNS.
BIP 157 (Compact Block Filter Service): P2P service exposing BIP158 filters to light clients.
BIP 159 (NODE_NETWORK_LIMITED Service Bit): Service bit advertising a pruned node's limited block availability.
BIP 176 (Bits Denomination Unit): Standardizing "bit" = 100 satoshis as a display unit.
BIP 320 (Versionbits for Mining Nonce Space): Reusing low version bits as extra nonce space for ASIC firmware efficiency.
BIP 325 (Signet Test Network): The signed test network where blocks are signed by a designated authority.
BIP 339 (Tx Relay by wTXID): Relaying transactions by wTXID to avoid wasted bandwidth on witness-malleated duplicates.
BIP 371 (Taproot Fields for PSBT): PSBT fields carrying Taproot-specific metadata (internal key, leaf scripts).
BIP 3 (Updated BIP Process): 2025 update to the BIP authoring process with a four-status taxonomy.
BIP 322 (Generic Signed Message Format): Signing arbitrary messages by constructing a virtual transaction for any script.
BIP 324 (V2 P2P Encrypted Transport): Encrypted P2P transport using ChaCha20-Poly1305 with elligator-squared key exchange.
BIP 326 (Anti-fee-sniping for Taproot): Recommended use of nLocktime to discourage one-block reorgs targeting your fees.
BIP 328 (MuSig2 Aggregate Key HD Derivation): Standard for deriving MuSig2 aggregate keys hierarchically.
BIP 329 (Wallet Labels Export Format): JSON-Lines interchange format for wallet labels and notes.
BIP 353 (DNS Payment Instructions): Resolving human-readable names (₿user@example.com) to payment instructions via DNSSEC.
BIP 360 (Pay to Quantum Resistant Hash — P2QRH / QuBit): Draft post-quantum address type committing to PQ-safe pubkey hashes.
BIP 361 (Post-Quantum Migration & Legacy Signature Sunset): Draft migration roadmap deprecating ECDSA/Schnorr in favour of PQ signatures.
BIP 373 (MuSig2 PSBT Fields): PSBT extensions carrying MuSig2 nonces and partial signatures.
BIP 374 (DLEQ Proofs for Multi-signer Silent Payments): Discrete-log-equality proofs allowing multi-signer Silent Payment sends.
BIP 375 (Sending Silent Payments with PSBTs): PSBT extensions for constructing Silent Payment transactions.
BIP 376 (Spending Silent Payment Outputs with PSBTs): PSBT extensions for spending detected Silent Payment outputs.
BIP 390 (musig() Descriptor Key Expression): New descriptor key-expression for MuSig2 aggregate keys.
BIP 443 (OP_CHECKCONTRACTVERIFY / CCV): A general covenant opcode enabling arbitrary commitments to spending tx structure.

Category

7 terms

Wallets & Developer Tools

Software and test networks engineers use day-to-day.

Hardware Wallet: A dedicated device that stores keys offline and signs transactions internally.
Watch-only Wallet: A wallet holding extended public keys but no private keys; can monitor balances and build PSBTs only.
Multisig Wallet: A wallet requiring m-of-n signatures to spend; spreads risk across keys and devices.
Testnet / Testnet4: Public test networks with worthless coins; testnet4 is the current iteration.
Signet: A test network whose blocks are signed by a designated authority; predictable for development.
Regtest: A local-only regression-test network where blocks are mined on demand.
Bitcoin RPC API: JSON-RPC interface to a Bitcoin Core node for wallet, mining, and chain commands.

Category

9 terms

Post-Quantum Bitcoin

How Bitcoin plans to survive cryptographically-relevant quantum computers.

Post-Quantum Cryptography (PQC): Cryptography believed to resist attacks by future quantum computers.
Quantum Computing Threat: A sufficiently large quantum computer running Shor's algorithm could break ECDSA and Schnorr.
Shor's Algorithm: Polynomial-time quantum algorithm for factoring and discrete logs; breaks Bitcoin's signatures if scaled.
Lattice-based Cryptography: PQ schemes built on hardness of lattice problems (LWE, SIS); fast verification, moderate sig sizes.
Hash-based Signatures (PQC): Signature schemes (SLH-DSA, XMSS) whose security depends only on hash function strength.
FALCON: NIST-selected PQ lattice signature scheme; ~666-byte signatures.
CRYSTALS-Dilithium / ML-DSA: NIST's primary PQ digital signature standard; ~2,420-byte signatures.
SPHINCS+ / SLH-DSA: NIST's hash-based PQ signature standard; large but with minimal algebraic assumptions.
XMSS: Stateful hash-based signature scheme defined in RFC 8391.

Sources: learnmeabitcoin.com, Mastering Bitcoin 3rd ed. (Antonopoulos & Harding), and the BIP repository.

790 terms across 19 categories. ← Back to course