Blockstream

How does Bitcoin work?

TL;DR: Bitcoin is a peer-to-peer monetary system where thousands of independent computers enforce the same rules to agree on who owns what, without any central authority. Transactions are signed with private keys, broadcast to the network, and bundled into blocks by miners who expend energy (proof-of-work) to secure the chain. A fixed supply schedule, difficulty adjustment, and decentralized consensus make the system both predictable and resistant to manipulation.

Bitcoin is a decentralized payment network and monetary system that uses cryptographic signatures to prove ownership, proof-of-work mining to order transactions into blocks, and a distributed network of nodes to enforce consensus rules without requiring trust in any single party. Every participant can independently verify every transaction and every block, making Bitcoin the first monetary system where "don't trust, verify" is a technical reality, not just a slogan.

The Big Picture

Every traditional payment system relies on a central authority to maintain the ledger. When you send money through a bank, the bank updates its internal database: your balance goes down, the recipient's balance goes up. You trust the bank to do this honestly, to not reverse transactions arbitrarily, and to not create money out of thin air. That trust is the single point of failure.

Bitcoin eliminates that single point of failure by distributing the ledger across thousands of independent computers (called nodes) around the world. Each node stores a complete copy of every transaction ever made. Each node independently validates every new transaction against the same set of rules. No single entity controls the ledger, and no single entity can change the rules.

The result is a system where:

  • Ownership is proven cryptographically. Your private key proves you control your bitcoin. No bank or institution needs to vouch for you.
  • Transactions become practically irreversible. Once confirmed in a block and buried under additional blocks, a transaction cannot be undone without redoing enormous amounts of computational work.
  • Supply is fixed and auditable. Every node enforces the 21 million bitcoin cap. Anyone can verify the total supply at any time.
  • The rules apply equally to everyone. Whether you're moving 0.001 bitcoin or 10,000 bitcoin, the network applies the same validation rules.

Understanding Bitcoin means understanding how these properties emerge from the interaction of several interlocking systems: transactions, the UTXO model, blocks, mining, nodes, and consensus rules. Each piece depends on the others. None works alone.

Transactions: From Send to Confirmed

A Bitcoin transaction is a signed data structure that transfers ownership of bitcoin from one set of addresses to another. Every bitcoin transfer, from a two-dollar coffee purchase to a billion-dollar institutional settlement, follows the same process.

Step 1: Constructing the Transaction

A transaction has three core components:

  • Inputs: References to bitcoin you previously received. Each input points to the specific output of a prior transaction that sent you bitcoin. These are your "source of funds".
  • Outputs: The destinations. Each output specifies a Bitcoin address and an amount. A transaction can have multiple outputs (for example, one to the recipient and one back to yourself as change).
  • Amounts: The sum of inputs must be greater than or equal to the sum of outputs. All values are denominated in satoshis, where one bitcoin equals 100,000,000 satoshis (the COIN constant in Bitcoin Core's src/consensus/amount.h). The difference between inputs and outputs becomes the transaction fee, which goes to the miner who includes the transaction in a block.

Your wallet software handles this construction automatically. It selects which inputs to spend, calculates the appropriate fee, creates a change output if needed, and formats the transaction according to the Bitcoin protocol.

Step 2: Signing With Your Private Key

Before a transaction can be broadcast, you must prove that you control the bitcoin being spent. This is done through a digital signature created with your private key.

The private key is a 256-bit number. From it, your wallet derives a public key (using elliptic curve multiplication, a one-way mathematical function). From the public key, it derives your Bitcoin address. Anyone can send bitcoin to your address, but only the holder of the corresponding private key can spend it.

When you sign a transaction, your wallet uses your private key to produce a signature that anyone can verify against your public key. This proves two things: that you hold the private key, and that the transaction data has not been tampered with since signing. The private key itself is never revealed. That signature comes from one of two schemes: ECDSA (used by legacy and SegWit outputs) and Schnorr (BIP 340, activated with Taproot in November 2021 and used by Taproot outputs).

This is why securing your private key is the single most important responsibility in Bitcoin. Whoever controls the private key controls the bitcoin, with no exceptions and no customer support to call. A hardware wallet like the Jade Plus stores your private keys on a dedicated signing device that keeps them isolated from internet-connected computers, and can operate fully air-gapped via QR code signing.

Step 3: Broadcasting to the Network

Your wallet sends the signed transaction to one or more Bitcoin nodes it's connected to. Those nodes validate the transaction (checking the signature, confirming the inputs haven't already been spent, verifying the amounts balance) and, if valid, relay it to their peers. Within seconds, the transaction propagates across the global network.

Step 4: The Mempool

Before being included in a block, the transaction sits in the mempool (memory pool), a holding area that each node maintains for unconfirmed transactions. The transaction remains in the mempool until a miner picks it up and includes it in a block. More on the mempool below.

Step 5: Inclusion in a Block

A miner selects transactions from their mempool (typically prioritizing those with higher fees per byte of data), bundles them into a candidate block, and begins the proof-of-work process. Once the miner finds a block header hash that falls below the network's target, the block is broadcast to the network.

Step 6: Confirmation

When the network accepts the block containing your transaction, the transaction is considered confirmed with one confirmation. Each subsequent block added on top adds another confirmation. Most wallets and services consider a transaction final after six confirmations (roughly 60 minutes), though even one confirmation provides strong assurance for typical transactions.

Under the Hood: How Nodes Validate Transactions

When a node receives a transaction, it does not simply check that the math adds up. It executes a scripting system embedded in every transaction. Each input contains a scriptSig (or witness data, post-SegWit) that provides proof of authorization. Each referenced output contains a scriptPubKey that defines the conditions for spending. The node runs the scriptSig against the scriptPubKey in a stack-based virtual machine. If execution succeeds (the stack evaluates to true), the spend is authorized. If it fails, the transaction is rejected.

For a standard Pay-to-Public-Key-Hash (P2PKH) transaction, the scriptPubKey says: "Provide a public key that hashes to this address, and a valid signature from that key." The scriptSig provides exactly that. For more advanced transaction types (multisig, time-locks, hash-locks), the scripts encode more complex spending conditions, all evaluated by the same stack-based virtual machine.

This script-based model is what makes Bitcoin programmable at the base layer without requiring a general-purpose virtual machine. Every node on the network executes the same scripts and arrives at the same result, with no ambiguity. The scripting language is intentionally limited (no loops, no unbounded computation) to ensure that validation is fast and predictable.

The UTXO Model

Most people think of money in terms of account balances. Your bank account says $5,000. Ethereum works this way too: each address has a balance, and a transaction subtracts from one balance and adds to another.

Bitcoin does not track account balances. It tracks Unspent Transaction Outputs, or UTXOs.

What Is a UTXO?

Every time you receive bitcoin, the transaction creates an output assigned to your address. That output sits on the blockchain, unspent, until you use it as an input in a future transaction. Each unspent output is a UTXO.

Think of UTXOs like physical bills. If you have a $20 bill and a $10 bill, you don't have "a balance of $30." You have two discrete items worth $20 and $10. If you want to pay someone $25, you hand over both bills ($30 total) and receive $5 in change. The original $20 and $10 bills are destroyed (spent), and two new items are created: a $25 payment and a $5 change bill.

Bitcoin works the same way. If you have a 0.5 BTC UTXO and a 0.3 BTC UTXO, and you want to send someone 0.6 bitcoin, your wallet consumes both UTXOs as inputs (0.8 BTC total) and creates two new outputs: 0.6 BTC to the recipient and roughly 0.2 BTC back to yourself as change (minus the transaction fee).

Why UTXOs Instead of Account Balances?

The UTXO model provides several advantages over an account-based model:

  • Parallel validation. Each UTXO is independent. Nodes can validate transactions spending different UTXOs simultaneously without worrying about ordering conflicts. In an account model, transactions from the same account must be processed sequentially to prevent double-counting.
  • Privacy. Because each transaction can create new outputs at new addresses, tracing the flow of funds is more complex than in an account model where all activity links to a single address. Wallet software typically generates a new address for each transaction.
  • Simple double-spend detection. A UTXO either exists (unspent) or it doesn't (spent). There's no ambiguous state. If a transaction tries to spend a UTXO that's already been consumed, every node rejects it immediately.
  • Auditability. The entire UTXO set represents the current state of Bitcoin ownership. Nodes maintain this set and can verify it against the blockchain at any time.

The UTXO Set

The complete collection of all unspent outputs at any given moment is called the UTXO set. As of early 2026, the UTXO set contains on the order of 170 to 180 million entries. Every full node maintains this set in memory for fast transaction validation. When a new transaction arrives, the node checks: do the referenced inputs exist in the UTXO set? If yes, the transaction is potentially valid. If no, it's rejected.

Blocks and the Blockchain

Individual transactions are not written directly to the permanent ledger. They are grouped into blocks, and blocks are chained together in sequence to form the blockchain.

What a Block Contains

Every Bitcoin block has two parts: a header and a body.

The block header (80 bytes) contains:

FieldDescription
VersionThe block format version, signaling which protocol rules apply.
Previous block hashA double-SHA-256 hash of the previous block's header. This is the link that chains blocks together.
Merkle rootA single hash that summarizes every transaction in the block. Built by hashing pairs of transactions together repeatedly until one hash remains. If any transaction in the block were changed, the Merkle root would change, invalidating the block.
TimestampWhen the miner began working on the block (approximate, with a two-hour tolerance window).
Difficulty targetThe threshold that the block hash must fall below for the block to be valid.
NonceA 32-bit number miners vary while searching for a valid hash. It is one of several fields miners adjust during proof-of-work (along with the coinbase extra nonce and timestamp).

The block body contains the transactions themselves. A block can hold a maximum of 4 million weight units (4 MWU), defined as MAX_BLOCK_WEIGHT in Bitcoin Core's src/consensus/consensus.h. This typically produces blocks of roughly 1.5 to 2 MB of serialized data and fits a few thousand transactions, often in the range of 2,000 to 4,500 depending on their complexity.

How Blocks Chain Together

Each block header includes the hash of the previous block's header. This creates a chain where every block is linked to the one before it, all the way back to the genesis block (block #0, mined by Satoshi Nakamoto on January 3, 2009).

This chaining is what makes the blockchain tamper-evident. If someone altered a transaction in block 500,000, the Merkle root of that block would change, which would change the block's hash, which would break the "previous block hash" reference in block 500,001. To maintain a consistent chain, the attacker would need to redo the proof-of-work for block 500,000 and every subsequent block, racing against the entire network's hashrate. The deeper a block is buried, the more computationally infeasible this becomes.

Mining and Proof-of-Work

Mining is the process by which new blocks are created and added to the blockchain. It serves two functions: ordering transactions into a tamper-evident sequence, and issuing new bitcoin according to a predetermined schedule.

The Mining Process

A miner assembles a candidate block by:

  1. Selecting transactions from their mempool (typically the ones paying the highest fees per unit of block weight).
  2. Creating a special transaction called the coinbase transaction that awards the block reward (newly created bitcoin + all transaction fees in the block) to the miner's address.
  3. Computing the Merkle root of all selected transactions.
  4. Filling in the block header with the previous block's hash, the Merkle root, the current timestamp, and the difficulty target.

The miner then begins hashing the block header using double-SHA-256 (applying SHA-256 twice). The goal: find a nonce value that, when included in the header, produces a hash below the current difficulty target. There is no shortcut. The only known method is brute-force trial and error: try a nonce, hash the header, check if the result is below the target, and if not, increment the nonce and try again.

Modern mining hardware (ASICs, Application-Specific Integrated Circuits) can perform hundreds of trillions of hashes per second. Even so, the network-wide average time to find a valid block is approximately ten minutes, defined by nPowTargetSpacing (600 seconds) in Bitcoin Core's src/kernel/chainparams.cpp, because the difficulty target is calibrated to match the total hashrate.

Why Proof-of-Work Matters

Proof-of-work is what gives Bitcoin its security guarantees. To rewrite the blockchain, an attacker would need to outpace the combined computational power of every honest miner on the network. As of Q1 2026, the Bitcoin network's total hashrate exceeds 800 exahashes per second (per mempool.space / Coin Metrics). Assembling even a fraction of that power would require billions of dollars in hardware and energy, with no guarantee of success.

Proof-of-work also solves the "who gets to decide" problem in a decentralized system. Anyone can attempt to mine a block. No permission is needed. The miner who finds a valid hash first earns the right to propose the next block. Other miners verify the block and, if valid, build on top of it. This converts energy expenditure into a fair, permissionless selection mechanism.

The Difficulty Adjustment

Block intervals drift whenever mining power changes. If more miners join, blocks are found faster; if miners leave, blocks slow down. Either scenario creates problems: too-fast blocks waste bandwidth and increase orphan rates (blocks that are mined but then discarded) (blocks that are mined but then discarded) (blocks that are mined but then discarded) (blocks that are mined but then discarded) (blocks that are mined but then discarded); too-slow blocks delay transaction confirmation.

Bitcoin solves this with the difficulty adjustment, one of its most elegant mechanisms.

How It Works

Every 2,016 blocks (approximately two weeks), every node on the network recalculates the difficulty target. The 2,016-block interval is derived from nPowTargetTimespan (1,209,600 seconds, or exactly two weeks) divided by nPowTargetSpacing (600 seconds), both defined in Bitcoin Core's src/kernel/chainparams.cpp. The calculation is simple: compare how long the last 2,016 blocks actually took versus the expected time of 20,160 minutes (2,016 blocks x 10 minutes each).

  • If blocks came too fast (the 2,016 blocks took less than two weeks), difficulty increases, making the target hash harder to find.
  • If blocks came too slow (the 2,016 blocks took more than two weeks), difficulty decreases, making the target easier to find.

The adjustment is capped at a factor of four in either direction per period, preventing sudden, destabilizing swings.

Why It Matters

The difficulty adjustment is what keeps Bitcoin's issuance schedule on track regardless of how much or how little mining power is deployed. Whether ten miners or ten million miners are running, blocks arrive roughly every ten minutes. This makes the supply schedule predictable decades into the future, something no other monetary system can claim.

The difficulty adjustment also creates a self-regulating economic feedback loop. When the bitcoin price rises, mining becomes more profitable, attracting more hashrate. More hashrate triggers a difficulty increase, raising costs for miners. When the price falls, unprofitable miners shut off, hashrate drops, difficulty decreases, and the remaining miners become more profitable. The system continuously rebalances.

Nodes: The Enforcers of the Rules

Miners produce blocks, but nodes decide whether those blocks are valid: miners propose, nodes dispose. A miner who produces an invalid block (one that violates consensus rules) will have that block rejected by every honest node on the network. The miner wastes their energy and earns nothing.

What a Node Does

A Bitcoin full node performs three primary functions:

  1. Validates transactions. When a node receives a new transaction, it checks: Are the signatures valid? Do the referenced UTXOs exist and are they unspent? Do the input amounts cover the output amounts? Does the transaction conform to the script rules? If any check fails, the transaction is rejected and not relayed.
  2. Validates blocks. When a node receives a new block, it verifies every transaction in the block, confirms the proof-of-work meets the difficulty target, checks the block header references the correct previous block, and ensures the block reward does not exceed the allowed amount. A single invalid transaction or incorrect field causes the entire block to be rejected.
  3. Stores the blockchain. Full nodes maintain the complete transaction history from the genesis block to the present. This allows any node to independently verify the entire chain and reconstruct the current UTXO set from scratch.

Full Nodes vs. Lightweight Nodes

A full node downloads and validates every block and every transaction. It trusts nothing and verifies everything. Running a full node requires roughly 600+ GB of disk space (as of 2026) and a persistent internet connection, though the hardware requirements are modest: any modern computer with sufficient storage can run one.

A lightweight node (also called an SPV client, for Simplified Payment Verification) does not download the full blockchain. It downloads only block headers and requests proof that specific transactions are included in blocks. This requires far less storage and bandwidth but relies on full nodes for validation. Lightweight nodes trust that the blocks they receive are valid because full nodes accepted them.

PropertyFull NodeSPV/Lightweight Node
Data storedComplete blockchain (every block and every transaction since genesis)Block headers only (~80 bytes per block), plus Merkle proofs for relevant transactions
Storage requirement600+ GB (as of 2026)Under 1 GB
Trust modelTrustless: independently verifies every rule and every transactionTrust-minimized: relies on full nodes to validate blocks; assumes the heaviest chain is valid
Validation approachExecutes all consensus rules, scripts, and signature checks for every transactionVerifies block headers and Merkle inclusion proofs; does not validate individual transactions

Why Running a Node Matters

Running your own full node means you verify every rule yourself. You don't trust your wallet provider, your exchange, or your internet service provider to tell you the truth about the state of the Bitcoin network. You see it directly. This is the technical foundation of self-sovereignty in Bitcoin: if you can't verify it yourself, you're trusting someone else.

Full nodes also form the enforcement layer of the network's consensus rules. If a majority of miners colluded to change Bitcoin's rules (for example, increasing the supply cap beyond 21 million), full node operators could simply reject those blocks. Miners don't define the rules. Nodes do.

Blockstream Satellite, a satellite broadcast service Blockstream previously operated (transferred to an independent mining entity in April 2025), broadcasted the entire Bitcoin blockchain from space, allowing anyone to run a full node without a traditional internet connection. This removed one of the last infrastructure dependencies for node operation: even if local internet access was censored or unavailable, the blockchain data remained accessible via satellite receiver.

Consensus: How the Network Agrees

With thousands of independent nodes and hundreds of thousands of miners, how does the Bitcoin network agree on a single version of the truth? Through Nakamoto Consensus, the mechanism described in the original Bitcoin whitepaper.

Nakamoto Consensus

The rule is straightforward: every node follows the valid chain with the most accumulated proof-of-work. "Valid" means every block in the chain follows all consensus rules. "Most accumulated proof-of-work" means the chain representing the most total computational effort (commonly but somewhat imprecisely called "the longest chain").

The rule needs no vote, and nodes take part without registering or proving an identity. Each node independently evaluates every chain it sees and follows the one with the most work. Because producing proof-of-work is expensive and verifying it is cheap, an attacker cannot fake accumulated work. The only way to build a chain with more work than the honest chain is to control more hashrate than the rest of the network combined.

How Forks Are Resolved

Occasionally, two miners find a valid block at nearly the same time. Some nodes see Block A first; others see Block B first. The network temporarily has two competing chain tips. This is a fork.

The fork resolves itself naturally. Miners continue working on whichever block they received first. Eventually, one side finds the next block before the other. That chain now has more accumulated work, and all nodes switch to it. The transactions in the orphaned block return to the mempool and are typically included in a subsequent block.

These forks are rare (lasting more than one block is extremely uncommon) and resolve without any coordination. The protocol handles it automatically.

The Mempool

The mempool is the holding area for unconfirmed transactions. Every node maintains its own version of the mempool, and the contents vary slightly from node to node depending on which transactions they've received and their individual relay policies.

How the Mempool Works

When a transaction is broadcast and validated by a node, it enters that node's mempool. It remains there until one of three things happens:

  1. A miner includes it in a block (the transaction is confirmed and removed from the mempool).
  2. A conflicting transaction that spends the same inputs gets confirmed first (the original transaction becomes invalid and is purged).
  3. It expires. Nodes typically drop transactions that have been in the mempool for more than two weeks without confirmation, though this varies by node configuration.

The Fee Market

Bitcoin blocks have a limited capacity of 4 million weight units. When more transactions are waiting in the mempool than a single block can fit, miners must choose which transactions to include. The selection criterion is economic: miners maximize their revenue by selecting the transactions paying the highest fees per unit of block weight (measured in satoshis per virtual byte, or sat/vB).

This creates a fee market. During periods of high demand, the mempool grows, and users compete by offering higher fees for faster confirmation. During low-demand periods, the mempool clears, and even minimum-fee transactions confirm quickly. The fee market is Bitcoin's mechanism for allocating scarce block space without a central authority setting prices.

You can follow a transaction's entire journey using a block explorer. Paste any transaction ID into Blockstream Explorer to see its inputs, outputs, fees, and confirmation status.

Block Rewards and the Halving

Every block's coinbase transaction creates new bitcoin. This is the only way new bitcoin enters circulation, and the amount follows a rigid, predetermined schedule coded into the protocol. Newly mined bitcoin cannot be spent until 100 additional blocks have been built on top of the block that created them, a maturity rule defined by COINBASE_MATURITY in Bitcoin Core's src/consensus/consensus.h. This prevents miners from spending coins on a chain tip that might be orphaned.

The Issuance Schedule

When Bitcoin launched in 2009, the block reward was 50 bitcoin per block. Every 210,000 blocks (approximately four years), the reward is cut in half. This interval is controlled by nSubsidyHalvingInterval in Bitcoin Core's src/kernel/chainparams.cpp. This event is called the halving.

EraBlock RangeReward per BlockApproximate Dates
10 - 209,99950 BTC2009 - 2012
2210,000 - 419,99925 BTC2012 - 2016
3420,000 - 629,99912.5 BTC2016 - 2020
4630,000 - 839,9996.25 BTC2020 - 2024
5 (current)840,000 - 1,049,9993.125 BTC2024 - ~2028

This schedule continues, halving approximately every four years, until the reward becomes so small it rounds to zero. The final bitcoin will be mined around the year 2140. At that point, the total supply will have approached 21 million bitcoin. No more can ever be created.

How the 21 Million Cap Works

The 21 million cap is not a configurable parameter that can be adjusted. It is a mathematical consequence of the halving schedule. Sum the total bitcoin produced across all eras:

50 x 210,000 + 25 x 210,000 + 12.5 x 210,000 + ... = 21,000,000

This is a geometric series that converges to exactly 21 million. Every full node enforces this limit by rejecting any block whose coinbase transaction exceeds the allowed reward for that block height. If a miner tried to award themselves extra bitcoin, every node on the network would reject the block. (Due to satoshi-level integer rounding, the actual maximum is approximately 20,999,999.98 BTC; "21 million" is standard shorthand.)

The Long-Term Fee Transition

As block rewards diminish, transaction fees become an increasingly important part of miner revenue. By the time the last bitcoin is mined, miners will be compensated entirely through fees. This transition is already underway: during periods of high network activity, fees have at times rivaled or exceeded the block reward in value. The fee market ensures that miners remain economically incentivized to secure the network even as new issuance approaches zero.

Putting It All Together: Alice Sends Bitcoin to Bob

Here is the complete journey of a single transaction, from wallet to confirmed settlement.

1. Alice opens her wallet. Her wallet software scans the UTXO set and finds the unspent outputs she controls. She has three UTXOs: 0.2 BTC, 0.15 BTC, and 0.05 BTC, totaling 0.4 bitcoin.

2. Alice constructs the transaction. She wants to send Bob 0.3 bitcoin. Her wallet selects the 0.2 BTC and 0.15 BTC UTXOs as inputs (0.35 BTC total) and creates two outputs: 0.3 BTC to Bob's address and 0.0499 BTC back to Alice's change address. The remaining 0.0001 BTC is the transaction fee.

3. Alice signs the transaction. Her wallet uses the private keys corresponding to each input's address to produce digital signatures. The signed transaction proves Alice controls the bitcoin being spent, without revealing her private keys.

4. The transaction is broadcast. Alice's wallet sends the signed transaction to a connected Bitcoin node. That node validates it by checking that the signatures are correct, that the referenced UTXOs exist and are unspent, and that the amounts balance. The checks pass, and the node relays the transaction to its peers. Within seconds, the transaction reaches thousands of nodes worldwide.

5. The transaction enters the mempool. Each node that validates the transaction adds it to their mempool. The transaction is now "unconfirmed" but visible to the network. Alice's wallet may show "pending" or "0 confirmations".

6. A miner includes it in a block. A miner constructing the next block sees Alice's transaction in their mempool. The 0.0001 BTC fee is competitive relative to the transaction's size, so the miner includes it alongside roughly 3,000 other transactions. The miner builds the Merkle tree, fills in the block header, and begins hashing.

7. The miner finds a valid hash. After trillions of attempts, the miner's ASIC finds a nonce that produces a block hash below the current difficulty target. The completed block is broadcast to the network.

8. Nodes validate and accept the block. Every full node that receives the block independently verifies: Does the proof-of-work meet the difficulty target? Does every transaction in the block follow consensus rules? Is the block reward correct? Does the "previous block hash" field match the current chain tip? Everything checks out. Nodes add the block to their chain and remove its transactions from their mempools.

9. Alice's UTXOs are spent; Bob's UTXO is created. The 0.2 BTC and 0.15 BTC UTXOs that Alice spent are removed from the UTXO set. Two new UTXOs are created: 0.3 BTC assigned to Bob's address and 0.0499 BTC assigned to Alice's change address. The UTXO set is updated across every node.

10. Bob sees one confirmation. Bob's wallet detects the new UTXO assigned to his address and displays the received bitcoin. The transaction has one confirmation. Ten minutes later, another block is built on top, giving it two confirmations. After six confirmations (roughly 60 minutes), the transaction is considered deeply settled. To reverse it, an attacker would need to redo the proof-of-work for six blocks while outpacing the rest of the network. The cost would be astronomical and the probability of success near zero.

The entire process, from Alice pressing "send" to Bob seeing a confirmed payment, takes an average of ten minutes for the first confirmation. No bank approved the transfer, no institution processed it, and no government authorized it. Thousands of independent computers enforced the same rules, and the math checked out.

Frequently Asked Questions

How long does a Bitcoin transaction take?

A transaction typically receives its first confirmation within about ten minutes (the average time between blocks, set by nPowTargetSpacing of 600 seconds). However, this varies. If the mempool is congested and the fee is low, a transaction may wait longer to be included in a block. Most recipients consider a transaction settled after six confirmations (roughly 60 minutes), though for smaller amounts, one or two confirmations are often sufficient. For faster settlements, layer-2 networks like the Lightning Network (near-instant) and the Liquid Network (one-minute blocks) extend Bitcoin's capabilities.

What happens if a transaction is never confirmed?

If a transaction sits in the mempool without being included in a block, it eventually expires (most nodes drop unconfirmed transactions after about two weeks). The bitcoin is never "lost" because the original UTXOs were never actually spent. The funds remain under the sender's control. The sender can also broadcast a replacement transaction with a higher fee to speed up confirmation, using a feature called Replace-By-Fee (RBF).

Can a Bitcoin transaction be reversed?

In practice, no. Once a transaction is confirmed in a block and subsequent blocks are built on top of it, reversing it would require redoing the proof-of-work for every block from that point forward while outpacing the entire network. After six confirmations, this is computationally infeasible for any known entity. This finality is a core property of Bitcoin and one of its key differences from traditional payment systems where chargebacks and reversals are common.

What determines Bitcoin transaction fees?

Transaction fees are determined by supply and demand for block space. Each block has limited capacity of 4 million weight units (MAX_BLOCK_WEIGHT in src/consensus/consensus.h). When more transactions are waiting in the mempool than a single block can fit, users bid higher fees for priority. Fees are measured in satoshis per virtual byte (sat/vB). During low-demand periods, fees can be as low as 1 sat/vB. During high-demand periods, they can spike significantly. Your wallet typically estimates an appropriate fee based on current mempool conditions.

Why does Bitcoin use so much energy?

Bitcoin's energy expenditure is the direct cost of its security model. Proof-of-work mining requires real-world energy to produce blocks, which makes the blockchain expensive to attack. The energy spent mining is not waste; it is the physical anchor that prevents anyone from rewriting transaction history without incurring enormous, real-world costs. The network's energy consumption is proportional to its security. Whether this tradeoff is worth it depends on how you value a monetary system that cannot be censored, debased, or controlled by any single entity.

What happens when all 21 million bitcoin are mined?

The last bitcoin will be mined around the year 2140, after approximately 33 halvings reduce the block subsidy to zero satoshis. After that, no new bitcoin will be created, and miners will be compensated entirely through transaction fees. This transition happens gradually rather than all at once: with each halving (every 210,000 blocks per nSubsidyHalvingInterval, roughly every four years), the block reward shrinks and fees make up a larger share of miner revenue. The total supply converges on 21 million through the geometric series: 210,000 × 50 × (1 + 1/2 + 1/4 + ...) = 21,000,000. The fee market is already operational and has sustained meaningful miner revenue during periods of high network demand.

What is the difference between a full node and a lightweight node?

A full node downloads and independently validates every block and every transaction, trusting nothing and verifying everything. It requires roughly 600 GB of disk space. A lightweight node, also called an SPV (Simplified Payment Verification) client, downloads only block headers and Merkle proofs, requiring under 1 GB, but relies on full nodes to validate blocks. Full nodes form the enforcement layer of Bitcoin's consensus rules, while lightweight nodes trade some trust assumptions for far lower resource use. Running your own full node, paired with a hardware wallet like the Jade Plus, lets you verify every rule yourself rather than trusting a third party.

Share:

Copied!