Bitcoin Learning Graph

Canonical URL: https://brenorb.com/btc-graph/
Library URL: https://brenorb.com/btc-graph/library/
Sitemap URL: https://brenorb.com/btc-graph/sitemap.xml

Summary:
Bitcoin Learning Graph is a public static website for structured Bitcoin self-study. It combines an interactive prerequisite graph with crawlable HTML concept pages, a text-first library index, and curated external resources.

Audience:
Bitcoin learners, developers, educators, writers, and researchers who want a concise map of prerequisite relationships between concepts.

Keywords:
bitcoin learning graph, bitcoin education, bitcoin curriculum, bitcoin prerequisite map, lightning network learning, bitcoin protocol concepts, bitcoin self-study, bitcoin glossary

Site sections:
- Home: https://brenorb.com/btc-graph/
- Library: https://brenorb.com/btc-graph/library/
- Node info pages: https://brenorb.com/btc-graph/nodes/%3Cnode-id%3E/info/

Topics by category:

Economics (32 concepts)
- Barter Limitations: Why direct barter fails at scale and drives monetary emergence.
- Bitcoin Supply and Demand: Bitcoin supply is programmatically constrained by its issuance schedule, so long-run supply expansion is not discretionary. When demand for holding or transacting in bitcoin rises against that static schedule, price tends to increase.
- Bretton Woods and 1971: The 1971 suspension of dollar-gold convertibility marked the transition to the modern fiat era. This event is central to debates about monetary discretion, inflation, and hard-money alternatives.
- Cantillon Effects: New money enters economies through specific channels, changing relative prices unevenly. Distribution effects depend on who receives new liquidity first.
- Central Bank Basics: Central banks manage base money, lender-of-last-resort functions, and policy rates within modern fiat systems. Understanding their role is required for comparing Bitcoin to state monetary institutions.
- Cost of Production: How energy and hardware costs constrain issuance economics.
- Double-Entry Bookkeeping: Double-entry bookkeeping tracks every economic event as balanced debits and credits across accounts. It provides the accounting lens needed to compare legacy ledgers with Bitcoin's UTXO accounting model.
- Fee Market: How users bid for blockspace and why confirmation priority follows fee rates under congestion.
- Fee Pressure Cycles: Recurring phases of low and high blockspace demand that impact confirmation expectations and wallet behavior.
- Hayek and Spontaneous Order: Hayek's spontaneous-order view explains how institutions like money, law, and language emerge from repeated coordination rather than central design. Bitcoin is often analyzed through this lens as an emergent monetary institution.
- Hayek's Money Competition: Hayek's money competition thesis argues that currencies should compete rather than be monopolized by the state. It frames Bitcoin as a market alternative in monetary selection.
- History of Money: From commodity monies to credit money and modern fiat regimes. This history frames why monetary institutions and trust models evolve over time.
- Hyperinflation History: Hyperinflation episodes show how confidence collapse, fiscal dominance, and monetary over-expansion can destroy currency function. Historical case studies clarify why monetary credibility is fragile.
- Inflation: How monetary expansion changes purchasing power and incentives.
- Long-Term Security Budget: How subsidy decline and fee revenue together influence miner incentives and chain security.
- Lost Coins and Effective Supply: How permanently inaccessible coins affect circulating supply, liquidity, and long-term scarcity.
- Miner Revenue Composition: How subsidy and fees combine to form miner revenue and how that mix evolves across halvings.
- Monetary Backing (Lastro): Monetary backing describes what, if anything, anchors confidence in a currency's purchasing power. Bitcoin's framing emphasizes verifiable scarcity and settlement finality rather than redeemability claims.
- Monetary Inflation vs Price Inflation: Monetary inflation tracks supply expansion of money, while price inflation describes observed changes in goods and services prices. Distinguishing them clarifies policy narratives and Bitcoin thesis claims.
- Monetary Premium: How market participants price liquidity and store-of-value properties.
- Monetization Process: How an asset moves from collectible demand toward broader use as savings and settlement money. Monetization is path-dependent and shaped by social coordination.
- Need for Inflation?: Mainstream policy frameworks argue for low positive inflation targets to reduce deflation risk and support wage and debt adjustment. Competing schools argue these benefits are overstated and can hide distributional costs.
- Neutral Money vs Political Money: Neutral money minimizes discretionary favoritism, while political money embeds policy preferences and selective intervention. This contrast helps explain why credible neutrality matters for global settlement assets.
- On-Chain Cost Allocation: Frameworks for allocating shared transaction costs across recipients, channels, and operational workflows.
- Properties of Money: Durability, portability, divisibility, recognizability, and scarcity.
- Savings vs Investment: Savings prioritizes preserving purchasing power with minimal dependence on counterparties, while investment takes additional risk for expected yield. Bitcoin is best understood as savings technology first, with investment-like behavior as a secondary market expression.
- Scarcity and Sound Money: Why scarce assets can accumulate monetary premium.
- Schelling Points: Schelling points are focal outcomes people coordinate on without explicit communication. In Bitcoin, social convergence on rules and symbols often follows this game-theoretic pattern.
- Time Preference: How short-term vs long-term thinking affects savings behavior.
- Token Basics: A token is a digitally represented unit with rules defined by a protocol or issuer. In Bitcoin education, this topic clarifies differences between native bitcoin units and tokenized or custodial claims.
- Transaction Batching Economics: Cost and UTXO-set tradeoffs of batching payments versus issuing many independent transactions.
- Volatility Psychology and Risk Sizing: Market volatility amplifies behavioral biases such as panic selling and leverage chasing. Risk sizing discipline matters more than prediction accuracy for long-term survival.

Extension Systems (47 concepts)
- Ark Protocol: Ark is an off-chain coordination design for batched transfers with periodic settlement anchors. It combines contract structure with liquidity and timing assumptions.
- Bitchat: Bitchat refers to Bitcoin-adjacent peer messaging experiments that emphasize local relay, mesh-style propagation, and censorship resistance. It is useful as a social-layer coordination complement to monetary protocols.
- Bitcoin Layers: How the base layer, payment channels, and higher-layer protocols compose a layered system.
- Bitcoin-Backed Ecash Systems: Bitcoin-backed ecash mints use blind signatures to trade trust assumptions for fast, private transfers with low on-chain overhead. Understanding mint trust models is critical before treating balances as final.
- BitVM: BitVM enables optimistic computation protocols anchored to Bitcoin settlement. It trades covenant requirements for interactive proofs and operational complexity.
- BOLT12 Offers: Next-generation Lightning request format for reusable, richer, and more private payment intents.
- Cashu: Cashu is a Bitcoin-backed ecash protocol and wallet ecosystem built around blind-signature mints. It improves privacy and transaction speed while preserving explicit mint trust tradeoffs.
- Channel Backups: Static channel backups and operational recovery steps.
- Channel Factories: Channel factories let multiple users share one on-chain UTXO to open and rebalance many off-chain channels. They trade coordination complexity for better on-chain footprint and liquidity efficiency.
- Channel Reserve and Dust Limits: Channel-level reserve and dust constraints that preserve safety margins and spendability under fee pressure.
- Coinpools: Coinpools are shared-ownership constructions that compress many balances into coordinated UTXO sets. They combine covenant-like constraints with cooperative state updates.
- Coinswaps: Coinswaps exchange control of UTXOs between parties without creating obvious on-chain links. They aim to improve privacy beyond straightforward CoinJoin heuristics.
- Congestion-Control Trees: Congestion-control trees pre-structure exits so many users can settle efficiently during fee spikes. They prioritize predictable emergency paths over flexible ad hoc spending.
- Discreet Log Contracts (DLCs): DLCs settle oracle-based outcomes using signature-based cryptographic tricks instead of on-chain scripting branches. They provide private, efficient contract settlement with clear oracle assumptions.
- Dual-Funded Channels: Dual funding allows both channel peers to contribute inputs during channel opening. It improves liquidity symmetry and reduces one-sided capital requirements.
- Eltoo Channel Updates: Eltoo is a Lightning update design that simplifies penalty logic with replaceable state updates. It depends on ANYPREVOUT-style signature semantics.
- Fedi: Fedi packages federated Bitcoin-backed ecash into a user-facing app with community and recovery workflows. It inherits ecash mint trust assumptions while making shared custody models easier to use.
- HTLC Timeout Settlement Paths: On-chain and off-chain settlement behavior when HTLCs approach timeout boundaries.
- HTLCs: Conditional forwarding using hashlocks and timelocks.
- Invoices and Payment Requests: BOLT11 request format and payment execution flow.
- Lightning Anchor Outputs: Commitment format that improves fee-bumping flexibility for channel closure transactions.
- Lightning Channel Fee Policies: Base fee and proportional fee policy setting for balancing routing attractiveness against channel risk.
- Lightning Channel Jamming: A denial-of-service pattern where HTLC slots or liquidity are intentionally exhausted on routing paths.
- Lightning Channel Splicing: Updating channel capacity without fully closing channels by combining on-chain and off-chain state changes.
- Lightning Commitment Transactions: Pre-signed updateable channel states that enforce current balances during unilateral close.
- Lightning Force Closures: Unilateral channel close path, penalty windows, and watchtower-dependent safety assumptions.
- Lightning Gossip Protocol: How channel and node announcements propagate network topology and routing policy updates.
- Lightning Multi-Path Payments: Splitting payments across routes to improve reliability and liquidity utilization.
- Lightning Onion Routing: Packet format and forwarding privacy model for multi-hop Lightning payments.
- Lightning Probing Attacks: Techniques used to infer channel balances or endpoint behavior through crafted routing attempts.
- Lightning Route Blinding: A privacy technique where receivers hide destination topology by providing blinded route hints.
- Lightning Routing: Path finding, forwarding, and reliability constraints.
- Lightning Trampoline Routing: A routing mode where lightweight wallets delegate part of pathfinding to trampoline nodes.
- Liquidity Management: Inbound/outbound capacity and channel balance operations.
- LNURL: LNURL is a family of Lightning interaction conventions layered on top of URLs and metadata endpoints. It improves UX but introduces interoperability and trust-surface tradeoffs.
- Nostr: Nostr is an open protocol for relayed social communication using public-key identities. It is relevant to Bitcoin culture because it extends censorship-resistant coordination beyond payments.
- Payment Channels: Off-chain bilateral channels secured by on-chain contracts.
- Payment Pools: Payment pools coordinate shared UTXOs and internal balance updates to reduce on-chain footprint. They rely on covenant-like constraints to keep exits and rebalances safe.
- Point Time-Locked Contracts (PTLCs): PTLCs replace hashlocks with point-based conditions to improve privacy and composability. They pair naturally with adaptor signatures and next-generation Lightning updates.
- Revocation and Penalty Keys: Lightning mechanism that punishes publication of outdated commitment states using revocation secrets.
- Sidechains: Sidechains move specific execution or policy experiments off the main chain while maintaining some Bitcoin anchoring. The security model depends heavily on peg design and federation or miner assumptions.
- Spacechains: Spacechains anchor external consensus data to Bitcoin while preserving independent execution environments. They use Bitcoin finality as a settlement root without full smart-contract expressiveness.
- Statechains: Statechains transfer control of pre-funded outputs between participants with minimal on-chain activity. Their trust and liveness assumptions differ from Lightning and covenant trees.
- Submarine Swaps: Submarine swaps atomically bridge on-chain and Lightning balances using hashlock and timelock constructions. They enable non-custodial liquidity transitions across layers.
- The Great Script Restoration: The Great Script Restoration revisits disabled Script capabilities for modern Bitcoin use. Its scope includes carefully re-evaluating opcodes such as OP_CAT.
- Transaction Templating: Transaction templating pre-commits spending structures so future spends follow known shapes. It is a core pattern behind many covenant-driven scaling constructions.
- Watchtowers: Penalty transaction protection in offline scenarios.

History & Governance (23 concepts)
- BIPs Process: How proposals become standards and deployment conventions.
- Bitcoin and Anarchism: Bitcoin governance is not a voting democracy; validity is enforced by voluntary rule-following nodes rather than ballots. This aligns with anarchist and cypherpunk ideas about non-coercive coordination.
- Bitcoin as Social Technology: Bitcoin works through social consensus around rule enforcement, not just code execution. Like contracts, the social layer determines legitimacy when disputes or edge cases appear.
- Bitcoin Immaculate Conception: Bitcoin's birth context is unusual: early digital currencies had little market value, Satoshi's identity was unknown, anyone with commodity hardware could mine, and faucet distribution made coins widely available. This origin story matters for understanding Bitcoin's perceived fairness and decentralization culture.
- Bitcoin Narrative Cycles: Public narratives around Bitcoin shift across boom-bust phases, regulation headlines, and technology milestones. Learning to separate narrative heat from structural signal improves judgment.
- Bitcoin Whitepaper: Original system design framing for decentralized digital cash and double-spend resistance.
- Block Size War: Governance conflict over scaling strategy and how social consensus resolved protocol direction.
- Cypherpunk Movement: Origins of privacy-preserving digital cash ideas.
- Cypherpunk Roots and Bitcoin Origin: Bitcoin emerged from cypherpunk ideas about privacy, digital cash, and open-source coordination. This topic connects pre-Bitcoin experiments to the 2008-2009 launch context.
- Double-Spend Problem: Why digital scarcity is hard and what constraints must be solved.
- Early Bitcoin History: From launch to early adoption cycles and network maturation.
- Genesis Block: Bitcoin’s launch context and embedded design signals.
- GPU-to-ASIC Transition: Historical shift from hobbyist GPU mining to specialized ASIC hardware and its decentralization consequences.
- Monetary Contact Shocks: When previously separate civilizations begin trading, a local money can lose scarcity if outsiders replicate it at lower cost. This helps explain monetary inflation episodes tied to technology and trade contact.
- Nodes vs Miners: Different responsibilities and power boundaries in the network.
- Pre-Bitcoin Digital Cash Attempts: Before Bitcoin, multiple designs tried to create digital money, including DigiCash, Hashcash, b-money, and bit gold. Studying these attempts clarifies what Bitcoin solved and what tradeoffs remained unresolved.
- Rai Stones: Rai stones from Yap are a classic case of socially recognized monetary ownership where transfer can occur without physically moving the asset. They illustrate that money depends on shared ledgers and social consensus.
- RBF Policy Evolution: Historical development of replace-by-fee relay policy and its role in modern fee-bumping workflows.
- SegWit Activation: The activation path, signaling dynamics, and coordination history behind SegWit deployment.
- Soft Forks vs Hard Forks: Compatibility tradeoffs in protocol upgrades.
- Taproot Activation History: Timeline and mechanism of Taproot deployment, from signaling design to mainnet lock-in and activation.
- User-Activated Soft Fork (UASF): How node operators coordinated policy to enforce soft-fork activation during the SegWit era.
- Version Bits Signaling: Miner signaling mechanism for coordinated soft-fork deployment using block version fields.

Mining (19 concepts)
- 51% Attack Model: Majority hashrate threat model: what an attacker can and cannot do under Nakamoto consensus.
- ASICBoost: ASICBoost is a proof-of-work optimization that can reduce hashing cost under specific block-construction strategies. Its deployment affects miner incentives, transparency, and template policy debates.
- ASICs: ASICs are application-specific chips built for Bitcoin's SHA-256 Proof of Work. They dramatically increase hashing efficiency versus general-purpose hardware, reshaping mining economics and decentralization tradeoffs.
- Block Propagation Latency: How network propagation speed affects stale risk, template quality, and mining profitability.
- Block Template Transaction Selection: How miners and pools choose mempool transactions for candidate blocks under fee and policy constraints.
- Empty-Block Mining Strategy: Why miners occasionally produce low-fee or empty blocks and how this impacts network fee dynamics.
- Environmental Co-Benefits: Bitcoin mining can use renewable energy well, can be a good demand response load, can recycle heat, can reduce methane emissions, and can use lost energy that would otherwise be wasted.
- Fee Sniping: Miner strategy of re-mining recent blocks to capture high-fee transactions, with reorg and incentive tradeoffs.
- GetBlockTemplate Workflow: How miners request candidate block templates and construct valid block submissions.
- Grid Balancing and Demand Response: Flexible mining loads can curtail or ramp based on grid conditions and price signals. This introduces potential value in balancing intermittent generation and constrained transmission.
- Mining Economics: Revenue, opex, capex, and fee dependence over time.
- Mining Energy Accounting: Energy analysis depends on boundaries and assumptions, especially the difference between marginal and average accounting. Good analysis distinguishes physical grid effects from narrative shortcuts.
- Mining Environmental Debate: Environmental claims about Bitcoin mining depend heavily on system boundaries, attribution methods, and counterfactual assumptions. A strong view should engage both best critiques and strongest rebuttals.
- Mining Hardware: ASIC design constraints and practical deployment considerations.
- Mining Template Construction: How miners and pools build candidate blocks from mempool transactions under policy, size, and fee constraints.
- Pool vs Solo Mining: Variance, payout models, and operational tradeoffs.
- Stale Blocks: Why valid blocks can become stale due to propagation races and how relay improvements reduce this risk.
- Stratum: Mining communication protocol concepts and architecture.
- Stratum V2: Mining protocol upgrades for efficiency, security, and improved job negotiation.

Network, Relay & Client Sync (44 concepts)
- AddrMan Bucketing: Peer address manager bucket strategy used to diversify outbound candidate selection and reduce eclipse risk.
- AddrV2 (BIP 155): Extended peer address relay format that supports newer network address types while preserving compatibility.
- ASMAP Peer Diversity: Using AS-level bucketing to reduce eclipse-risk concentration from peers within the same autonomous systems.
- AssumeUTXO: Fast-start strategy using UTXO snapshots with deferred full validation for faster node usability.
- Assumevalid: A sync optimization that can skip historical script verification until chain trust is established during IBD.
- Bitcoin Core RPC: Programmatic interaction with node functionality.
- Bitcoin P2P Message Flow: Version handshake, inventory relay, and message sequencing in node-to-node communication.
- Child Pays for Parent (CPFP): Fee-bumping strategy where a child transaction incentivizes confirmation of a low-fee parent.
- Cluster Mempool: Cluster mempool tracks package relationships to improve policy decisions and package relay behavior. It aims to make ancestor/descendant handling more predictable under load.
- Compact Block Filters: Client-side block filtering protocol for light clients without full bloom-filter leakage patterns.
- Compact Block Relay: Bandwidth-efficient block propagation using short transaction identifiers.
- Compact Blocks vs Compact Filters: Operational differences between block propagation optimization and lightweight-client block filtering protocols.
- Distributed Systems: Replication, fault tolerance, and coordination in decentralized networks.
- DNS Seeds: Bootstrap mechanism that gives new nodes initial peers before ongoing address gossip takes over.
- Dust Policy: Policy thresholds for economically unspendable outputs and their impact on transaction construction.
- Electrum Server: Serving wallet queries from your own verified node stack.
- Erlay Transaction Relay: Erlay reduces transaction relay bandwidth while preserving propagation robustness. It changes gossip behavior to scale peer connectivity more efficiently.
- Fee Estimation RPC: How wallet and node software estimate feerates from mempool and historical confirmation data.
- Headers-First Synchronization: How nodes download and validate block headers before fetching full blocks during initial sync.
- Initial Block Download: How a new node bootstraps chainstate safely and reaches current tip.
- Mempool: How unconfirmed transactions propagate, queue, and get filtered by local node policy.
- Mempool Policy: Standardness, relay policy, and transaction propagation behavior.
- Mesh Networks: Mesh networks route data through many local peers without depending on one central ISP path. They are studied as resilience infrastructure for Bitcoin communication under outage or censorship pressure.
- Node Hardware Sizing: CPU, RAM, disk, and network requirements by workload.
- Package Relay: Policy and relay of related transaction packages, commonly parent-child sets, for fee-bumping and package validation.
- Peer Discovery and Addrman: How nodes discover, score, and rotate peers using address relay and addrman persistence.
- Peer Eviction Protection: Inbound and outbound peer eviction logic designed to retain high-value peers and resist DoS/eclipsing behavior.
- Peer-to-Peer Network Topology: How Bitcoin nodes discover peers, relay data, and maintain decentralized communication.
- Pruned vs Archival Nodes: Storage and functionality tradeoffs in node configuration.
- Replace-by-Fee (RBF): Policy mechanism to replace unconfirmed transactions with higher-fee versions.
- Run a Full Node: Install, sync, and maintain independently verifying infrastructure.
- Signet Operations: Using signet for deterministic, low-value testing of wallet and node workflows.
- Standardness Policy: Node relay and mempool policy rules that constrain which valid transactions are considered standard.
- testmempoolaccept RPC: RPC workflow to pre-check transaction acceptance against local mempool and policy rules.
- Testnet and Regtest: Controlled experimentation environments for protocol and wallet behavior.
- Tor for Node Connectivity: Improving network privacy and resilience by routing node traffic over Tor.
- Transaction Bloom Filtering (BIP37): Legacy lightweight-client filtering using bloom filters and why modern wallets moved to compact filters.
- Transaction Index (txindex): Global transaction indexing mode for historical transaction lookups at the cost of extra disk and sync overhead.
- Transaction Relay (inv/getdata): How peers announce and request transactions using inv/getdata before full tx relay.
- Utreexo: Utreexo compresses UTXO commitments using accumulator proofs to reduce full-node state costs. It shifts part of the burden to proof generation and verification pipelines.
- UTXO Set Management: Operational handling of UTXO set growth, disk constraints, and validation performance tradeoffs.
- V2 P2P Transport (BIP324): V2 transport encrypts peer-to-peer traffic and improves handshake behavior. It reduces passive metadata leakage and hardens network communications.
- Verify Node Sync: Validation checkpoints and trust-minimized sync checks.
- WTXID Relay (BIP 339): Peer-to-peer relay mode that uses witness transaction IDs to improve transaction tracking consistency.

Protocol & Consensus (48 concepts)
- Adaptor Signatures: Adaptor signatures embed encrypted conditions into signature flows. They are foundational for DLC settlement and PTLC-style constructions.
- Addresses and Outputs: Address formats, script templates, and spendability.
- Bitcoin Covenants: Covenants constrain how coins can be spent in future transactions. They enable advanced contract constructions such as vaults, payment pools, and congestion-control trees.
- Bitcoin Script: Locking and unlocking conditions for UTXO spending.
- Block Height: Height indexing of blocks and coinbase commitments used for chain ordering and validation assumptions.
- Block Structure: Header fields, merkle root, and block composition.
- Block Weight and Virtual Bytes: How weight units and vbytes price block space after SegWit.
- Byzantine Generals Problem: Consensus under adversarial communication assumptions.
- CHECKLOCKTIMEVERIFY (BIP 65): Script opcode that enforces an absolute locktime for spending conditions in Bitcoin scripts.
- CHECKSEQUENCEVERIFY (BIP 112): Script opcode that enforces relative locktime conditions using sequence-based spending constraints.
- Coinbase Transaction: Special first transaction in each block that collects subsidy and transaction fees.
- Consensus Rules: Validation rules that define Bitcoin’s canonical state.
- CPFP Carve-Out Policy: CPFP carve-out is a mempool policy exception intended to make Lightning commitment fee-bumping practical. It affects package acceptance limits and descendant accounting.
- Cross-Input Signature Aggregation (CISA): CISA aggregates signatures across multiple inputs to reduce weight and improve coordination efficiency. It introduces new accounting and policy considerations for batch spenders.
- Difficulty Adjustment: Automatic retargeting to stabilize block production.
- Digital Scarcity: Digital scarcity is the ability to make digital units costly to forge and impossible to validly spend twice under shared rules. Bitcoin's breakthrough is combining cryptography, networking, and consensus to enforce that scarcity.
- Direct Introspection Proposals: Direct introspection proposals expose transaction fields to Script for covenant enforcement. They increase expressiveness while raising complexity and review-surface tradeoffs.
- Discrete Log Equivalency (DLEQ): DLEQ proofs show two public keys share the same secret scalar without revealing that scalar. They are building blocks for adaptor signatures, atomic swaps, and scriptless constructions.
- Ephemeral Anchors: Ephemeral anchors adjust fee-bumping flows so temporary anchors improve package relay flexibility. They are tightly coupled to modern mempool package policy.
- Fee Sponsorship: Fee sponsorship lets one party help another transaction confirm without directly modifying the original spend. It is part of a broader package-relay design space for contract reliability.
- Halving Cycle: Programmed issuance reductions and long-term security implications.
- MATT and CCV: MATT and CCV propose composable covenant techniques for generalized contract trees. They aim to express advanced spending programs with structured state transitions.
- Median Time Past: Consensus time reference based on prior blocks, reducing miner timestamp manipulation for locktime behavior.
- OP_CAT: OP_CAT concatenates stack elements and expands Script programmability. It is frequently discussed as a primitive for covenant and introspection-style constructions.
- OP_CHECKSIGADD: OP_CHECKSIGADD accumulates signature checks and supports Schnorr multisignature constructions in Tapscript. It simplifies threshold policies compared with legacy CHECKMULTISIG patterns.
- OP_CHECKSIGFROMSTACK: OP_CHECKSIGFROMSTACK verifies signatures over stack-provided messages instead of transaction fields alone. It is a common building block in advanced covenant proposal discussions.
- OP_CHECKTEMPLATEVERIFY (CTV): CTV restricts spending transactions to a committed template hash. This enables deterministic spending trees and scalable pre-planned transaction structures.
- OP_CODESEPARATOR: OP_CODESEPARATOR changes the script segment committed by signature hashing. Its behavior is subtle and historically important for advanced script correctness.
- OP_RETURN Outputs: Provably unspendable script outputs used for bounded data commitments on-chain.
- Pay-to-Script-Hash (P2SH): Output type where spending conditions are committed as a script hash and revealed at spend time.
- Proof of Work: Mining via Proof of Work solves three core problems at once: consensus on transaction history, network security against sybil and rewrite attacks, and open distribution of new coins through block rewards.
- Reorgs and Finality: Probabilistic finality and chain reorganization behavior.
- Script Timelocks: Timelock primitives used to constrain when funds can be spent in script contracts.
- Segregated Witness (SegWit): Witness data separation that fixed key malleability issues and increased block capacity efficiency.
- SegWit Witness Commitment: How witness data is committed in coinbase transactions to secure segregated witness verification.
- Sequence Locks (BIP 68): Relative locktime semantics encoded in nSequence and enforced through sequence-based transaction finality rules.
- SIGHASH Flags: Signature hash flags define which transaction parts are committed by each signature and shape authorization semantics.
- SIGHASH_ANYPREVOUT: ANYPREVOUT changes signature commitment semantics so updates can bind less history. It is a key enabler for eltoo-style channel update protocols.
- Taproot: Protocol upgrade enabling more private and efficient key/script spending conditions.
- Taproot Annex: The annex is an optional witness element committed by Taproot signatures but ignored by script execution. It provides forward-compatibility space for future soft-fork semantics.
- TLUV Proposal: TLUV is a covenant proposal focused on constrained value and output structure updates. It aims to support richer contract trees without exposing full introspection.
- Transaction Confirmations: How confirmation depth affects settlement confidence for different payment risk profiles.
- Transaction Lifecycle: From creation and propagation to confirmation and settlement.
- Transaction Malleability: How pre-confirmation transaction mutation risk appears and why stable identifiers matter.
- Transaction Pinning: Transaction pinning exploits relay and mempool rules to block fee-bump or replacement strategies. It is a core risk area for contract protocols that rely on timely confirmation.
- TXHASH Proposal: TXHASH introduces transaction field commitments for covenant-like constraints. It explores a finer-grained introspection path for contract design.
- UTXO Model: State model based on spendable outputs instead of account balances.
- What Is a Protocol?: A protocol is a shared rule set that independent participants follow to coordinate behavior without central control. Bitcoin works as a monetary protocol because nodes enforce rules the same way.

Security (51 concepts)
- Address Reuse: How reuse harms financial privacy and graph analysis resistance.
- Adversarial Thinking: Adversarial thinking models how rational and irrational attackers can exploit protocol and implementation edges. It is essential for reviewing Bitcoin changes before deployment.
- AML/KYC and Sanctions Tradeoffs: Compliance controls can reduce some abuse vectors while increasing surveillance and exclusion risks. The tradeoff analysis should separate legal requirements, policy goals, and technical limits.
- Amount Correlation: How amount uniqueness and matching patterns can link inputs, outputs, and user behavior across transactions.
- Blind Signatures: Blind signatures let a signer authorize a token without seeing its final contents, enabling ecash mints to issue privately spendable proofs. They build directly on digital-signature verification.
- Censorship Resistance: Why open participation and distributed validation make transaction censorship costly and fragile.
- Chain Analysis Heuristics: Common heuristics used to cluster addresses and infer ownership from on-chain behavior.
- Change Avoidance Strategies: Wallet spending techniques that minimize change output creation to reduce linkage and future privacy leakage.
- Change Output Detection: How analysts identify probable change outputs and why output structure discipline matters for privacy.
- Coin Control: Manual UTXO selection to optimize privacy and fee outcomes.
- CoinJoin: Collaborative transaction construction to reduce heuristics.
- Commitment Schemes: Commitment schemes let someone bind to a value now and reveal it later. Bitcoin and adjacent cryptographic systems use commitments to anchor later verification without exposing all underlying data upfront.
- Common-Input Ownership Heuristic: Heuristic that clusters addresses by assuming inputs in one transaction are controlled by the same entity.
- Cyclic Groups: Cyclic groups model repeated application of an operation from a generator and are the algebraic setting for many Bitcoin cryptographic constructions. They define why private scalars can map to public points in a structured way.
- Dandelion Transaction Propagation: Dandelion-style relay separates diffusion phases to reduce origin-linkability. It is a network-level privacy strategy with deployment and adversarial-model tradeoffs.
- Diffie-Hellman Key Exchange: Diffie-Hellman lets two parties derive a shared secret over a public channel using group exponentiation. In Bitcoin systems, elliptic-curve variants appear in encrypted transport and protocol design patterns.
- Digital Signatures: Verifiable authorization without revealing private keys.
- Discrete Logarithm Problem: Bitcoin key security depends on the hardness of solving discrete logarithms on elliptic curves. This hardness assumption is the core one-way property behind public keys.
- ECDSA: ECDSA is the legacy Bitcoin signature algorithm used by pre-Taproot outputs and many wallets. Understanding its nonce and inverse terms explains key leak risks and malleability-era constraints.
- Eclipse Attacks: Eclipse attacks isolate a node from honest peers to manipulate its view of the network. Mitigation requires peer diversity, routing hygiene, and robust eviction policy.
- Elliptic Curve Cryptography: Elliptic curve cryptography maps finite-field arithmetic into group operations used for Bitcoin keys and signatures. It is the practical cryptographic system behind secp256k1.
- Exfiltration-Resistant Signing: Exfiltration-resistant signing protocols prevent compromised signers from leaking key material through nonce channels. They are particularly important in multi-device and hardware-assisted setups.
- Fermat's Little Theorem: Fermat's little theorem is used to reason about inverses in prime fields used by Bitcoin cryptography. It helps explain why modular inversion works for non-zero elements.
- Finite Fields: Finite fields define the arithmetic space where Bitcoin elliptic-curve operations occur. Prime-field constraints make key operations deterministic and secure.
- Fungibility: Fungibility means each unit is equally acceptable regardless of its transaction history. Weak fungibility raises censorship and surveillance risk even when base-layer ownership remains valid.
- Hash Functions: One-way functions, preimage resistance, and collision resistance.
- Interactive Proofs: Interactive proofs model verification as a dialogue between a prover and a verifier. They matter because many zero-knowledge protocols start from this challenge-response structure before later non-interactive variants compress the interaction.
- KYC and Privacy Tradeoffs: Identity linkage risks and mitigation strategies.
- Merkle Trees: Efficient integrity proofs for large sets of transactions.
- Modular Arithmetic Basics: Modular arithmetic is clock-style math over a fixed modulus and is the base of Bitcoin signature calculations. It defines addition, subtraction, and multiplication inside finite fields.
- Modular Exponentiation: Fast exponentiation under a modulus is the core operation behind key exchange and signature verification. It turns repeated multiplication into tractable computation on large numbers.
- Modular Inverse: Modular inversion is required in Bitcoin signature equations for both key and nonce terms. Understanding inversion clarifies why bad nonce handling can leak private keys.
- Network Privacy (Tor): Reducing IP-level linkage when interacting with Bitcoin nodes.
- OP_VAULT Proposal: OP_VAULT proposes native covenant support for delayed recovery and theft mitigation flows. It is designed to make vault policies safer and simpler to deploy.
- PayJoin (P2EP): Interactive transaction protocol that breaks common-input ownership heuristics.
- Protocol Neutrality: Protocol neutrality means consensus and relay rules should avoid embedding special treatment for particular users or outcomes. Neutral rule design is a core part of Bitcoin’s credible fairness.
- Pseudonymity (Not Anonymity): Bitcoin is pseudonymous, not anonymous: addresses are public identifiers that can be linked to real identities through behavior, counterparties, and metadata. Privacy requires active operational practices rather than default assumptions.
- Public/Private Keys: Asymmetric cryptography foundations for ownership proofs.
- Reproducible Builds: Reproducible builds let independent parties verify that released binaries match source code. They reduce supply-chain trust assumptions for wallet and node software.
- Responsible Disclosure: Responsible disclosure coordinates vulnerability reporting and patching to reduce exploit windows. In Bitcoin, disclosure timing and communication quality can have ecosystem-wide impact.
- Scalar Multiplication: Scalar multiplication is repeated elliptic-curve point addition and is the operation that derives public keys from private keys. It is efficient forward but infeasible to reverse in practice.
- Schnorr Signatures: Schnorr signatures are Bitcoin's modern signature scheme introduced with Taproot and designed for linearity and simpler multisignature constructions. They improve composability for advanced scripts and protocols.
- Script-Type Fingerprinting: Privacy leakage from distinctive output script and address-type patterns that narrow likely wallet/software identity.
- secp256k1 Curve Parameters: secp256k1 is Bitcoin's elliptic curve and fixed parameter set for key generation and signatures. Its field, generator point, and group order determine valid key and nonce ranges.
- Silent Payments: Silent payments let receivers publish one static address while each payment still lands in a unique on-chain output. This reduces address reuse while keeping receiver-side scanning requirements manageable.
- Trustlessness: Trustlessness in Bitcoin means security comes from verification and incentives rather than trusted operators. You can reduce counterparty risk by validating rules locally.
- UTXO Consolidation Tradeoffs: Balancing fee savings and future spending efficiency against privacy loss when merging UTXOs.
- XPUB Leakage: Privacy and security risks from sharing extended public keys with third-party services.
- Zero-Knowledge Proofs: Zero-knowledge proofs let someone prove a statement is true without revealing the underlying witness. They matter as background for privacy systems, validity proofs, and off-chain verification schemes discussed around Bitcoin.
- zk-SNARKs: zk-SNARKs are succinct non-interactive zero-knowledge proofs that usually optimize for very small proofs and fast verification. They are useful to understand when evaluating privacy systems, proof aggregation, and trusted-setup tradeoffs.
- zk-STARKs: zk-STARKs are transparent zero-knowledge proofs that avoid trusted setup and lean on hash-based commitments. They matter when comparing proof systems for scalability, auditability, and post-quantum assumptions.

Wallets (29 concepts)
- Address Types: Legacy, SegWit, and modern output encoding differences.
- Air-Gapped Signing: Signing workflow that keeps private keys on an offline device while moving unsigned and signed payloads between systems.
- Backups and Recovery: Recovery drills, inheritance planning, and backup hygiene.
- BIP32 Hierarchical Deterministic Keys: Tree-based key derivation model enabling deterministic wallet structures and account separation.
- BIP39 Mnemonics: Mnemonic seed format and entropy/checksum model used by many wallet backups.
- BIP44 Derivation Paths: Account hierarchy convention for interoperable deterministic wallet path structures.
- Bitcoin Inheritance Planning: Designing survivable custody workflows that balance privacy, security, and recoverability.
- BSMS for Multisig Coordination: Bitcoin Secure Multisig Setup standards for interoperable multisig setup, descriptors, and recovery metadata.
- Codex32 Backups: Codex32 is a checksummed seed-sharing format designed for human-verifiable backup workflows. It focuses on robustness against transcription and partial-share handling mistakes.
- Custody vs Self-Custody Legal Framing: Legal obligations and risk shift depending on whether funds are held by an intermediary or controlled directly by the user. Understanding this split is essential for consumer protection and compliance posture.
- Descriptor Wallet Imports: Importing and managing descriptor-based wallet script sets, ranges, and checksums for deterministic tracking.
- fundrawtransaction RPC: RPC for coin selection and fee funding of partially constructed transactions.
- Hardware Wallets: Isolated signing environments and practical security tradeoffs.
- HD Wallets: Deterministic key derivation for scalable wallet management.
- HWI + PSBT Signing Flow: Separation between host construction and hardware-device signing through PSBT-based workflows.
- Miniscript: Safer script composition and policy analysis.
- Multisig Wallets: Threshold signing policies for resilience and governance.
- MuSig2 Descriptor Workflows: How MuSig2 key-aggregation workflows integrate with descriptor-based wallet and signing policies.
- Output Descriptors: Descriptor expressions that describe script templates, key origins, and wallet scanning behavior.
- PSBT v2: The v2 evolution of PSBT that improves transaction construction semantics and interoperability.
- PSBT Workflow: Partially signed transaction flow for safer collaborative signing.
- scantxoutset RPC: RPC-based scanning of chainstate UTXOs for descriptor matches without full wallet import.
- Seed Passphrase (BIP39): Optional passphrase extension for mnemonic seeds and its recovery risk tradeoffs.
- Seed Phrases: Mnemonic backups and key restoration model.
- Seed XOR Shards: Splitting seed entropy into XOR-combined shards for backup distribution, with operational and recovery pitfalls.
- Self-Custody Principles: Operational responsibility model and threat minimization.
- UTXO and Output Labeling: Maintaining labels for transaction outputs and counterparties to improve spending decisions, accounting, and privacy hygiene.
- Wallet Development: Building safer wallet UX around signing and policy constraints.
- Watch-Only Wallets: Wallet setups that monitor balances and addresses without holding spending keys.