ellipticc
Overview
How Bitcoin Works: A Complete (Technical) Guide

How Bitcoin Works: A Complete (Technical) Guide

Ilias Abousalim Ilias Abousalim
December 3, 2025
26 min read
Cryptocurrency

How Bitcoin Works: A Complete (Technical) Guide

Bitcoin is the first successful decentralized digital currency. Launched in 2009 by Satoshi Nakamoto, it’s a peer-to-peer system that replaces a central authority with a distributed, global consensus: a public ledger called the blockchain.

This page explains how Bitcoin works in detail, from cryptographic foundations through transactions and consensus, to the technical stack you’ll find running a node. At the end we highlight the emerging quantum-computing threat and practical mitigations.

TL;DR - How Bitcoin Works (One Paragraph)

Bitcoin maintains a global ledger of transactions. Users hold private keys that let them spend UTXOs (unspent transaction outputs). Transactions are broadcast to the network, pooled in the mempool, and miners (Proof-of-Work) select transactions, pack them into a block, and solve a hash puzzle (SHA-256 double-hash) to add the block to the chain. The longest valid chain of blocks becomes the authoritative history; wallets track UTXOs to determine balances.

Tip

This guide covers the most important pieces: addresses and keys, transactions and scripts, blocks and mining, the P2P network, wallets, and the risk quantum computers pose to existing cryptography.

Key Cryptography & Primitives

Bitcoin uses a combination of hashing, public-key cryptography, and simple scripting to provide secure transfers:

  • A hash function: double SHA-256 (SHA256(SHA256(x))) is used for block header hashing (PoW) and single SHA-256 + RIPEMD-160 for legacy address encodings (P2PKH); SegWit/Taproot use witness programs and Bech32/Bech32m encodings.
  • An elliptic-curve signature scheme: the curve used is secp256k1 (Koblitz curve), and Bitcoin historically used ECDSA for transaction signatures. Taproot (BIP-340/341/342) introduced Schnorr signatures (BIP-340) and a new script/commitment model (BIP-341, BIP-342), but the curve is still secp256k1.

Important technical details:

  • Private key: a 256-bit secret scalar in the finite field defined by secp256k1; the canonical private key values are in the range 1..n-1 where n is the secp256k1 group order.
  • Public key: the curve point (x,y) computed by scalar multiplication G * priv (G = generator). Taproot uses x-only public keys (BIP-340) for a smaller witness commitment.
  • ECDSA signatures are (r, s) pairs, typically encoded in strict DER format for transaction inputs. Bitcoin Core enforces canonical signature forms and proper encoding for standardness; implementations also prefer low-S normalization (ensuring s <= n/2) to reduce malleability.
  • Schnorr signatures (BIP-340) are a single 64-byte signature using deterministic nonce generation; they enable simpler multisignature and better aggregation semantics.
  • libsecp256k1 is the optimized C library used by Bitcoin Core for all secp256k1 operations (key generation, signing, verification) and includes constant-time arithmetic and hardened implementations to avoid side channels.

Address & protocol standards referenced: BIP-32/BIP-39/BIP-44 (HD wallets), BIP-141 (SegWit), BIP-173/BIP-350 (Bech32/Bech32m), and BIP-340/341/342 (Schnorr/Taproot).

References:

UTXO Model and Transactions

Bitcoin uses a UTXO (Unspent Transaction Output) model rather than an account model. Each transaction consumes one or more UTXOs (inputs) and creates new UTXOs (outputs). A node verifies that inputs exist, are unspent, and the sum of inputs >= sum of outputs (extra becomes fees).

Transaction structure (simplified):

  • Version, inputs, outputs, locktime
  • Each input contains a reference to the previous output, a scriptSig (or witness for SegWit), and a sequence
  • Each output contains a value (satoshis) and a scriptPubKey (locking script)

Scripts: Bitcoin’s script language is intentionally limited and stack-based. Common scripts include P2PKH, P2SH, P2WPKH, and Taproot (Schnorr + complex scripting). A node runs the unlocking script from the input against the locking script in the output to confirm a transaction is valid.

Real bitcoin-cli examples (requires a running bitcoind with RPC enabled):

Terminal window
# Get a new address
bitcoin-cli getnewaddress


# Show raw transaction (hex) details
bitcoin-cli getrawtransaction <txid> 1


# Broadcast a raw transaction (hex)
bitcoin-cli sendrawtransaction <rawhex>


# Show wallet balance
bitcoin-cli getwalletinfo

Blocks, Mining, and Consensus (Proof-of-Work)

A block contains a set of transactions and a header. The header includes:

  • version
  • prevBlockHash
  • merkleRoot (hash of transactions)
  • timestamp
  • difficulty target (bits)
  • nonce

Mining: Miners vary the nonce (and extraNonce space in coinbase) to find a header whose double SHA-256 value is below the target. When found, miners broadcast the new block; nodes validate it by re-checking all fields and scripts. If valid, nodes add it to their best chain.

Intuition: Mining is a brute-force search where miners repeatedly change a small value (nonce) and re-hash the block header until the resulting hash is lower than the encoded target. Think of this as guessing a long numeric combination where only a small fraction of guesses succeed. The network difficulty adjusts so the whole network finds a block roughly every 10 minutes.

How it works (technical):

  • Block header fields that matter: version, prev_block_hash, merkle_root, timestamp, nBits (compact target), nonce.
  • Proof-of-Work function: compute hash = SHA256(SHA256(block_header)) and compare hash <= target (all as 256-bit integers), where target is derived from nBits.
  • Changing the nonce or coinbase (extraNonce) changes the coinbase transaction and therefore the merkle root and header hash; miners commonly vary nonce, extranonce (in the coinbase script), timestamp, or transaction ordering to expand the search space beyond the 4-byte nonce alone.

Difficulty and nBits summary:

  • nBits is a compact representation of the 256-bit target. The network difficulty is computed as the ratio of the fixed difficulty-1 target (the genesis target 0x1d00ffff) to the current target. If the target decreases (lower target), mining difficulty increases to maintain ~10-minute blocks.

Practical commands & regtest example (reproducible)

Use a regtest node to experiment without real-world difficulty - you can mine instantly.

Terminal window
# Create a wallet and address
bitcoin-cli -regtest createwallet "mining" true
mine_addr=$(bitcoin-cli -regtest -rpcwallet=mining getnewaddress)


# Mine a single block to the address (instant in regtest)
bitcoin-cli -regtest -rpcwallet=mining generatetoaddress 1 "$mine_addr"


# Inspect the block header and block details
blockhash=$(bitcoin-cli -regtest getbestblockhash)
bitcoin-cli -regtest getblock "$blockhash" 2


# Get the coinbase tx and decode coinbase (ASCII) - useful for viewing extraNonce or messages
txid=$(bitcoin-cli -regtest getblock "$blockhash" 2 | jq -r '.tx[0]')
coinbase_hex=$(bitcoin-cli -regtest getrawtransaction "$txid" 1 | jq -r '.vin[0].coinbase')
echo "$coinbase_hex" | xxd -r -p

Compute header double-sha256 and compare with target (advanced):

Terminal window
# Get the raw block header (compact serialization) and compare to the target shown in the block
header_hex=$(bitcoin-cli -regtest getblockheader "$(bitcoin-cli -regtest getbestblockhash)" 0)


# Convert nBits (compact) to full target (example small script or library; shown here in Python for clarity)
python - <<'PY'
import json
import subprocess
import hashlib


def nbits_to_target(nbits_val):
  # nbits_val is the compact representation returned from RPC (string like '1d00ffff' or a decimal int)
  # The compact format encodes exponent (highest byte) and mantissa (lowest 3 bytes).
  # Reference: nCompact = exponent<<24 | mantissa
  if isinstance(nbits_val, str):
    if nbits_val.startswith('0x'):
      ncompact = int(nbits_val, 16)
    else:
      # try hex first then decimal
      try:
        ncompact = int(nbits_val, 16)
      except ValueError:
        ncompact = int(nbits_val)
  else:
    ncompact = int(nbits_val)


  exponent = (ncompact >> 24) & 0xff
  mantissa = ncompact & 0x007fffff
  # If exponent <= 3 we shift right, otherwise shift left.
  if exponent <= 3:
    target = mantissa >> (8 * (3 - exponent))
  else:
    target = mantissa << (8 * (exponent - 3))
  return target


blockhash = subprocess.check_output(['bitcoin-cli','-regtest','getbestblockhash']).strip().decode()
header_hex = subprocess.check_output(['bitcoin-cli','-regtest','getblockheader', blockhash, '0']).strip().decode()
header_json = json.loads(subprocess.check_output(['bitcoin-cli','-regtest','getblockheader', blockhash, '1']))
nbits_hex = header_json.get('bits')
target = nbits_to_target(nbits_hex)


# Compute the double-sha256 of the header
header_bytes = bytes.fromhex(header_hex)
header_hash_raw = hashlib.sha256(hashlib.sha256(header_bytes).digest()).digest()
header_hash_int = int.from_bytes(header_hash_raw[::-1], 'big')


print('nbits', nbits_hex)
print('target', hex(target))
print('header hash (int)', header_hash_int)
print('header hash (hex)', header_hash_raw[::-1].hex())
PY

Toy script: demonstrate nonce changing and header hash differences (Linux/basics):

Terminal window
# create a simple loop to increment nonce in a header hex and show the double hash
# NOTE: this requires you prepare a header hex and update the nonce bytes manually; careful when crafting headers
for nonce in {0..5}; do
  # replace last 4 bytes in header with fixed nonce
  H="<header-hex-with-last-4-bytes-zeroed>"
  newH="${H%????}$(printf '%08x' $nonce)"
  echo -n "$newH" | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -sha256 -hex
done

Mining probability example (real-world intuition):

  • If a miner has a fraction f of the total network hashrate, their probability to find the next block is f.
  • Example: your miner has 100 TH/s (1e14 H/s) and network is 200 EH/s (2e20 H/s). Your chance = 1e14/2e20 = 5e-7 per block - with ~144 blocks/day, expected ~0.000072 blocks/day, or ~1 block every 38 years solo. Pools make this steadier.

Mining pools and shares:

  • Pools distribute work; miners submit “shares” that meet a lower difficulty target as proof of contributing work and receive payouts proportionally.
  • Example share difficulty: share target 1/2^32 allows miners to submit many low-difficulty results that pools tally for rewards.

Why it secures Bitcoin:

  • To alter past transactions an attacker would need to redo all PoW for all blocks after the target block; this is computationally expensive.
  • If one party controls >50% hash power, they can occasionally perform re-orgs, but it’s cost-prohibitive in a healthy network.

Mining RPCs & diagnostics (useful commands):

Terminal window
bitcoin-cli getmininginfo
bitcoin-cli getnetworkhashps
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'

Limitations and trade-offs:

  • Energy consumption and ASIC centralization are real world concerns.
  • Solo mining is impractical at large scale; pool payouts are common.

This section gives both intuition and practical steps to experiment with regtest. If you want, I’ll expand the Python snippet to decode nBits precisely and show a full example comparison using a real block header from mainnet (or regtest) with the computed target.

Terminal window
# Get block info by height or hash
bitcoin-cli getblock <blockhash>
bitcoin-cli getblockhash <height>


# Mining RPC (only with a mining node configured):
bitcoin-cli getmininginfo

Merkle Trees & Block Structure

Bitcoin uses a Merkle tree of transactions so you can verify a transaction is included in a block using only the transaction, a Merkle path, and the block header (helpful for light clients / SPV).

  • block.header contains the Merkle root
  • The proof of inclusion is a compact path from transaction to root.

P2P Network & Nodes

Bitcoin nodes communicate with TCP (port 8333 for mainnet) in a gossip protocol. Nodes advertise new transactions (inv), request data, and relay blocks.

  • A node maintains a peer list, mempool (unconfirmed transactions), and the UTXO set.
  • Full nodes verify all rules and keep the entire chain history (or pruned). Light clients (SPV) rely on block headers and Merkle proof.

Common node commands:

Terminal window
# Show node info and peers
bitcoin-cli getnetworkinfo
bitcoin-cli getpeerinfo

Wallets and Key Management

Wallets use BIP-32/39/44 to derive addresses from a seed (mnemonic). HD wallets let you restore your entire wallet from a single mnemonic.

  • BIP39: mnemonic seed
  • BIP32: hierarchical deterministic (HD) key derivation
  • BIP44: standard paths for multiple coin types

Wallet security: never expose your private keys, use hardware wallets for large holdings, and avoid address reuse.

Terminal window
# Create a new HD wallet on Bitcoin Core (v24+, with descriptors)
bitcoin-cli createwallet "mywallet" true
bitcoin-cli -rpcwallet="mywallet" getnewaddress

  • PSBT & Hardware Wallets (recommended for custody):

    • PSBT (Partially Signed Bitcoin Transaction) is a standard (BIP-174) that lets you create a transaction, export it as a PSBT, sign parts of it in a hardware wallet, and then finalize & broadcast the signed transaction - this is central to secure offline signing workflows.
    • Flow (high-level, wallet and hardware):
    Terminal window
    # Create a PSBT using your wallet (it will pick inputs and estimate fees)
    psbt=$(bitcoin-cli walletcreatefundedpsbt '[]' '[{"<address>":0.001}]' 0 '{"replaceable":true}' true | jq -r '.psbt')
    

    # If your wallet can't sign or you want to sign with hardware, export and sign with your device
    # After hardware signature, use walletprocesspsbt to import/merge signatures
    signed=$(bitcoin-cli walletprocesspsbt "$psbt" | jq -r '.psbt')
    

    # Finalize the PSBT and broadcast
    hex=$(bitcoin-cli finalizepsbt "$signed" | jq -r '.hex')
    bitcoin-cli sendrawtransaction "$hex"
    • Advantages: hold private keys in hardware while constructing transactions on a connected host, allowing offline signing for high-value transfers.

Address Types & Construction (P2PKH / P2SH / P2WPKH / P2TR)

Tip (Learn Bitcoin)

For a comprehensive, approachable Bitcoin guide, visit Learn Me A Bitcoin.

Bitcoin supports several address types. They differ by what script or witness program they lock funds to and by how the address is encoded for humans.

  • P2PKH (Legacy / 1… addresses):

    • Construction: pubkey -> SHA256 -> RIPEMD-160 (pubKeyHash) -> add version byte (0x00) -> checksum -> Base58Check
    • Example: Genesis address 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF is a P2PKH address constructed from the uncompressed public key present in the genesis coinbase output.
    • To fetch script details for an address managed by your node:
    Terminal window
    bitcoin-cli -rpcwallet=mywallet getaddressinfo 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

  • P2SH (Script hash / 3… addresses):

    • Construction: redeemScript -> SHA256 -> RIPEMD-160 -> add version (0x05) -> checksum -> Base58Check
    • Example: 3M219KR5vEneNb47ewrPfWyb5jQ2DjxRP6 is a canonical P2SH-formatted address. These addresses are commonly used for multisig and other script-based outputs.
    • You can create a P2SH (multisig) address with Bitcoin Core:
    Terminal window
    bitcoin-cli createmultisig 2 "[\"02...pubkey1\",\"03...pubkey2\"]"

  • P2WPKH/P2WSH (SegWit / bech32 bc1q…):

    • Construction: witness program version 0 + hashed pubkey or script (20-byte or 32-byte witness program), encoded with bech32/segwit.
    • Example address (BIP-173 test vector): bc1qazcm763858nkj2dj986etajv6wquslv8uxwczt (P2WPKH). This is encoded with Bech32.
    • To generate a native SegWit address from Bitcoin Core (descriptor wallets):
    Terminal window
    bitcoin-cli -regtest getnewaddress "" bech32
    bitcoin-cli -regtest -rpcwallet=demo-wallet getaddressinfo <segwit-address>

  • P2TR (Taproot / bech32m bc1p…):

    • Construction: an x-only public key or Taproot script tree hashed as a 32-byte witness program; encoded with Bech32m (BIP-350).
    • Example: a real Taproot address will have bc1p8jkwplu835wtjfuzzj3pwkzydyf98qlvvufyudutvqdlpns04h4qqqhnea on mainnet. Example (programmatically generated): bc1p... (addresses differ per key).
    • To generate a Taproot address with Bitcoin Core (v22+ supports descriptors):
    Terminal window
    bitcoin-cli -regtest getnewaddress "" bech32m
    bitcoin-cli -regtest -rpcwallet=demo-wallet getaddressinfo <taproot-address>

Why types matter:

  • Privacy: SegWit and Taproot expose less data on-chain than older P2PKH outputs.
  • Fees: newer address types often have smaller virtual size (vbytes), so lower fees.
  • Compatibility: some services or older clients may not support modern addresses.

Monetary Policy & Halving

Bitcoin’s monetary policy is fixed in code: new coins are created by the block subsidy and halved approximately every 210,000 blocks (about every 4 years). The subsidy schedule is deterministic and asymptotically approaches zero, which caps total supply at 21,000,000 BTC.

  • The original block subsidy was 50 BTC per block; every 210,000 blocks the subsidy halves: 50 → 25 → 12.5 → 6.25 → 3.125 (current after 2024 halving).
  • Check current block height and compute subsidy (simple demo):
Terminal window
height=$(bitcoin-cli getblockcount)
halvings=$((height / 210000))
initial_sat=5000000000  # 50 BTC in satoshis
subsidy_sat=$((initial_sat >> halvings))
echo "Height: $height, Halvings: $halvings, Subsidy: $(awk "BEGIN {printf \"%.8f\", $subsidy_sat/100000000}") BTC"

Coinbase Maturity

Coinbase (block reward) outputs must mature for 100 confirmations before they are spendable. This rule protects the network against premature spending of rewards that could be invalidated if the block becomes orphaned during a reorg.

Example (regtest): mine 101 blocks to mature the coinbases so they are spendable:

Terminal window
addr=$(bitcoin-cli -regtest getnewaddress)
bitcoin-cli -regtest generatetoaddress 101 "$addr"

Reorgs, Orphan Blocks & 51% Attacks

Because mining is distributed, competing blocks occasionally lead to short forks. A reorganization (reorg) occurs when a node receives a longer valid fork than its current chain; that branch becomes the canonical chain. Orphan (stale) blocks are valid blocks that were not included in the final chain.

  • A 51% attack (controlling majority hash power) would let an attacker produce a longer chain, allowing targeted reorgs and double-spends, but this is extremely expensive on mainnet.
  • Detecting forks and tips:
Terminal window
bitcoin-cli getchaintips   # shows known chain tips
bitcoin-cli getbestblockhash

Merchant guidance: require confirmations appropriate to transaction value - commonly 6 confirmations for large sums.

Transaction Fees & Mempool

Fees incentivize miners to include your transaction in a block. Fee markets prioritize transactions with higher sat/vbyte. bitcoin-cli provides mempool analytics and fee estimation.

Terminal window
bitcoin-cli estimatesmartfee 6  # estimate fee rate for confirmation in ~6 blocks
bitcoin-cli getmempoolinfo

Confirmations & Double-Spend

Confirmations are the number of blocks that include (or follow) the block that contains a transaction. Each new block makes a transaction harder to reverse because an attacker must remake more proof-of-work to outpace the chain.

  • The common industry heuristic is 6 confirmations for high-value transfers - this makes a successful reorg increasingly expensive and improbable. For lower-value or time-critical cases, merchants sometimes accept 0-conf with mitigations.
  • Check confirmations via RPC:
Terminal window
bitcoin-cli getrawtransaction <txid> 1 | jq -r '.confirmations'
# or if you control the wallet
bitcoin-cli gettransaction <txid> | jq -r '.confirmations'

Double-spend risk:

  • A double-spend is a conflicting transaction that spends the same inputs differently. This might succeed without confirmations (0-conf) if a merchant accepts an unconfirmed payment.
  • To protect against double-spend: wait for confirmations, prefer more confirmations for higher value, and use services (blockchain watchers, mempool observers) that detect conflicting transactions.

RBF & CPFP (Replace-By-Fee and Child-Pays-For-Parent)

Two ways to influence network fee and transaction priority after a transaction is broadcast:

  • RBF (Replace-By-Fee): the sender can mark a transaction as replaceable (BIP-125), allowing them to broadcast a new transaction with a higher fee that replaces the previous one. If you created a transaction with RBF enabled, bumping the fee via the wallet is easy.
Terminal window
# Check if a mempool entry is replaceable (bip125 flag)
bitcoin-cli getmempoolentry <txid> | jq -r '."bip125-replaceable"'


# If you used wallet-created transactions, bump fee using the wallet
bitcoin-cli bumpfee <txid>
  • CPFP (Child-Pays-For-Parent): if you cannot replace the parent (it’s not RBF) but control an output funded by it, create a child transaction that spends the unconfirmed output and attach a very high fee to the child - miners will include the parent + child pair if the combined fee-per-vbyte makes it attractive.
Terminal window
# Example high-level steps for a CPFP child:
# 1. Identify the unconfirmed parent's UTXO
bitcoin-cli listunspent 0 9999999 '[{"address":"<your_address>"}]'


# 2. Create a child tx that spends that UTXO with a large fee
createrawtx=$(bitcoin-cli createrawtransaction '[{"txid":"<parentid>","vout":0}]' '{"<recipient>":0.0009}')
funded=$(bitcoin-cli fundrawtransaction "$createrawtx")
signed=$(bitcoin-cli signrawtransactionwithwallet "$funded")
bitcoin-cli sendrawtransaction "$signed"

Notes:

  • CPFP requires you to control child inputs or collaborate with the recipient.
  • RBF is cleaner if you can create your transactions as replaceable to begin with.

Bitcoin Core & the Technical Stack

Bitcoin Core is the reference implementation written in C++ (with libsecp256k1 for elliptic curve operations and many performance-focused implementations). The common components are:

  • bitcoind (full node daemon) and bitcoin-cli (RPC client)
  • libsecp256k1: optimized secp256k1 implementation used by Bitcoin Core
  • Bitcoin Core source: consensus rules, P2P, wallet management
  • electrum (Python) and other light wallet servers and clients

The stack is mature; nodes usually run Bitcoin Core and miners run specialized mining software that talks to pools or directly to nodes.

Technical notes: secp256k1, ECDSA, Schnorr

  • secp256k1 is the specific Koblitz elliptic curve used by Bitcoin (curve equation: y^2 = x^3 + 7 over the finite field F_p, with p = 2^256 - 2^32 - 977). The group order n and generator G are defined by the SEC standard and used by Bitcoin clients.
  • ECDSA basics (high-level): to sign a message digest z with private key d, pick an ephemeral nonce k, compute R = k*G, let r = R.x mod n, compute s = k^-1 * (z + r * d) mod n, then signature = (r, s). Signatures are typically serialized in strict DER and Bitcoin Core enforces canonical encoding for standard transactions.
  • Schnorr (BIP-340) uses deterministic nonce generation and a different signature equation; it produces a single 64-byte signature that enables cleaner aggregation and multisignature schemes compared to ECDSA.
  • libsecp256k1 is the optimized implementation used by Bitcoin Core for secp256k1 arithmetic, key management, and safe signing/verification; it prioritizes constant-time arithmetic to mitigate side channels.

References:

Scaling: Layer 2 and SegWit

  • SegWit (BIP141) moved signatures to a separate witness structure and fixed transaction malleability.
  • Lightning Network: A Layer 2 payment protocol built on top of Bitcoin using state channels to enable fast, low-fee payments. Lightning uses HTLCs and multi-hop routing.

Some Common Commands (Bitcoin Core RPC)

Terminal window
# Blockchain status
bitcoin-cli getblockchaininfo


# Wallet status
bitcoin-cli getwalletinfo


# Get transaction details
bitcoin-cli getrawtransaction <txid> 1


# Get address information (requires wallet)
bitcoin-cli -rpcwallet=mywallet getaddressinfo <address>


# Estimate fees
bitcoin-cli estimatesmartfee 6

These commands assume you have a running bitcoind with RPC configured. Check ~/.bitcoin/bitcoin.conf for RPC settings.

Privacy & Practical Considerations

Bitcoin’s privacy is limited by on-chain transparency: all transactions and UTXOs are public. Techniques such as CoinJoin, mixers, and off-chain payments (Lightning) improve privacy, but they’re not perfect.

Use a new address for each receive where possible, avoid sharing public keys (spending reveals a public key), and prefer latest wallets that default to SegWit/Taproot for improved privacy and lower fees.

Quantum Computing: Why Bitcoin Is Vulnerable

Bitcoin’s security relies on elliptic-curve cryptography (ECDSA/Schnorr) on secp256k1 and the collision-resistance/preimage-resistance of hash functions. Quantum algorithms are a real and distinct threat for different reasons:

  • Shor’s algorithm (Peter Shor, 1994) efficiently solves the discrete logarithm and integer factorization problems, which would allow recovery of private keys from public keys for schemes like ECDSA and Schnorr once sufficiently powerful, fault-tolerant quantum hardware exists. This is the most serious long-term threat to private-key security.
  • Grover’s algorithm (Lov Grover, 1996) gives a quadratic speed-up for unstructured search problems, which reduces the effective security level of symmetric primitives such as SHA-256 (e.g., 256-bit preimage complexity → 2^128 under an ideal Grover run). While serious, this is less immediately catastrophic than Shor’s impact on public-key cryptography because it requires substantially more resources to beat classical PoW adjustments.

Practical implications for Bitcoin:

  1. Address reuse & public key exposure
  • If you reuse addresses or reveal a public key on-chain (standard P2PK or after spending), the public key is visible and an adversary with sufficient quantum capability could use Shor’s algorithm to derive the private key. Avoid reuse and prefer address types that minimize public key exposure (e.g., P2WPKH, P2TR where public key exposure occurs only on spend).
  1. Harvest-now, break-later
  • Adversaries can store public on-chain data today and wait for post-quantum capability to extract keys later (a “store-now, break-later” attack). For long-term confidentiality, this matters.
  1. PoW vs Quantum
  • Grover’s algorithm lowers symmetric key security (square-root speedup). Doubling SHA-256 length is impractical; Bitcoin’s PoW difficulty is dynamic, but PoW’s protective value depends on available classical hashing power vs any quantum attacker’s advantage.
  1. Taproot / Schnorr vulnerability
  • Taproot uses Schnorr signatures (BIP-340), still based on ECC and therefore vulnerable to Shor’s algorithm like ECDSA.

References:

Mitigation Strategies & The Road Forward

  • Avoid address reuse and ensure best wallet hygiene
  • Use post-quantum signature schemes in a hybrid approach (combine classical ECDSA with a PQ scheme): hybrid multisignature or hybrid single-signature scheme would require protocol upgrades, and careful design to maintain compatibility.
  • Use hardware wallets and policy-based vaults to reduce exposure surfaces.
  • Plan for a protocol migration: a hard- or soft-fork to change signature schemes is possible but complex; the community will need to coordinate.
  • You can adopt an immediate mitigation: create new addresses (safe) and spend from older addresses now to move funds to PQ-hardened addresses once a solution is available.

Note: Replacing every wallet/address and coordinating a migration for a global currency is a non-trivial political and technical challenge.

Issues Beyond Quantum Computing

Bitcoin’s limitations that are not QC-related but important to understand:

  • Energy use & environmental impact of PoW
  • Mining centralization and ASIC dominance
  • Layer 1 scalability and throughput (for most users the answer is Layer 2)
  • Privacy concerns with on-chain transparency
  • Regulatory tension between censorship resistance and legal frameworks

Genesis Block - The First Block on the Chain

The genesis block (block 0) is the first block and is hard-coded into Bitcoin Core. It is notable for the embedded coinbase text that Satoshi included as a little political commentary in January 2009.

Common ways to inspect the genesis block (requires a running bitcoind):

Terminal window
# Get the genesis block hash
blockhash=$(bitcoin-cli getblockhash 0)


# Get decoded block data (replace <hash> with the value returned above)
bitcoin-cli getblock "$blockhash" 2


# Extract the coinbase txid and coinbase payload (hex) and decode to ASCII
txid=$(bitcoin-cli getblock "$blockhash" 2 | jq -r '.tx[0]')
coinbase_hex=$(bitcoin-cli getrawtransaction "$txid" 1 | jq -r '.vin[0].coinbase')
echo "$coinbase_hex" | xxd -r -p

The canonical genesis block hash is:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

The coinbase message embedded by Satoshi in the genesis block is the newspaper headline:

“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”

This is visible as ASCII embedded in the coinbase for the genesis coinbase transaction, and it’s often cited as a succinct statement of motivation behind the first Bitcoin block.

Full raw block data (including coinbase hex) can be inspected on the Bitcoin Wiki: https://en.bitcoin.it/wiki/Genesis_block

Raw hex (full genesis block dump)

Below is the raw genesis block hex (xxd-style dump) - the full byte content of the Genesis block as widely published:

00000000   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000010   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000020   00 00 00 00 3B A3 ED FD  7A 7B 12 B2 7A C7 2C 3E   ....;£íýz{.²zÇ,>
00000030   67 76 8F 61 7F C8 1B C3  88 8A 51 32 3A 9F B8 AA   gv.a.È.ÈŠQ2:Ÿ¸ª
00000040   4B 1E 5E 4A 29 AB 5F 49  FF FF 00 1D 1D AC 2B 7C   K.^J)«_Iÿÿ...¬+|
00000050   01 01 00 00 00 01 00 00  00 00 00 00 00 00 00 00   ................
00000060   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000070   00 00 00 00 00 00 FF FF  FF FF 4D 04 FF FF 00 1D   ......ÿÿÿÿM.ÿÿ..
00000080   01 04 45 54 68 65 20 54  69 6D 65 73 20 30 33 2F   ..EThe Times 03/
00000090   4A 61 6E 2F 32 30 30 39  20 43 68 61 6E 63 65 6C   Jan/2009 Chancel
000000A0   6C 6F 72 20 6F 6E 20 62  72 69 6E 6B 20 6F 66 20   lor on brink of
000000B0   73 65 63 6F 6E 64 20 62  61 69 6C 6F 75 74 20 66   second bailout f
000000C0   6F 72 20 62 61 6E 6B 73  FF FF FF FF 01 00 F2 05   or banksÿÿÿÿ..ò.
000000D0   2A 01 00 00 00 43 41 04  67 8A FD B0 FE 55 48 27   *....CA.gŠý°þUH'
000000E0   19 67 F1 A6 71 30 B7 10  5C D6 A8 28 E0 39 09 A6   .gñ¦q0·.\Ö¨(à9.¦
000000F0   79 62 E0 EA 1F 61 DE B6  49 F6 BC 3F 4C EF 38 C4   ybàê.aÞ¶Iö¼?Lï8Ä
00000100   F3 55 04 E5 1E C1 12 DE  5C 38 4D F7 BA 0B 8D 57   óU.å.Á.Þ\8M÷º..W
00000110   8A 4C 70 2B 6B F1 1D 5F  AC 00 00 00 00            ŠLp+kñ._¬....

A Real-World Example: Bitcoin Pizza Day (May 22, 2010)

The first documented purchase of a good with bitcoin is one of the better-known early stories in Bitcoin history. On May 22, 2010, programmer Laszlo Hanyecz (username laszlo) paid 10,000 BTC for two Papa John’s pizzas - an event now celebrated by the community as “Bitcoin Pizza Day”.

Why this is instructive:

  • It’s a concrete example of a Bitcoin transaction moving real value for a real-world good; it illustrates early usage, low liquidity at the time, and the dramatic changes in implied fiat value over time.
  • You can inspect historical transactions with bitcoin-cli (if you run a full node) or any block explorer. Example:
Terminal window
# Fetch raw transaction by txid (mainnet) and decode
bitcoin-cli getrawtransaction <txid> 1


# Decode a raw transaction hex
bitcoin-cli decoderawtransaction <rawhex>

NOTE: When you fetch historical transactions by txid you might need to use a public block explorer. If you want me to add the confirmed txid (and a decoded getrawtransaction from a block explorer) I can fetch and include it - or we can add a short interactive bitcoin-cli regtest example (below) that shows the full flow on a test net to avoid referencing a single historical txid.

Raw Transaction Lifecycle - A Regtest bitcoin-cli Example

For reproducible examples, use regtest where block creation is instant and private to you. These commands assume Bitcoin Core v0.21+ with wallet support.

Linux / Bash (regtest) commands:

Note: these examples assume jq and xxd are installed for parsing and hex decoding.

Terminal window
# Start bitcoind in regtest (background)
bitcoind -regtest -daemon


# Create a wallet for demo purposes
bitcoin-cli -regtest createwallet "demo-wallet"


# Generate an address and mine 101 blocks to mature coinbase outputs
addr=$(bitcoin-cli -regtest getnewaddress)
bitcoin-cli -regtest generatetoaddress 101 "$addr"


# Confirm wallet balance
bitcoin-cli -regtest -rpcwallet=demo-wallet getbalance


# Send 1 BTC to a fresh address (creates a spendable UTXO)
recipient=$(bitcoin-cli -regtest -rpcwallet=demo-wallet getnewaddress)
bitcoin-cli -regtest -rpcwallet=demo-wallet sendtoaddress "$recipient" 1.0


# Pick a UTXO from listunspent (use jq to extract txid/vout)
utxo_json=$(bitcoin-cli -regtest -rpcwallet=demo-wallet listunspent | jq -r '.[0]')
txid=$(echo "$utxo_json" | jq -r '.txid')
vout=$(echo "$utxo_json" | jq -r '.vout')


# Create a raw transaction using that UTXO; subtract a fee (0.001) for example
raw=$(bitcoin-cli -regtest createrawtransaction "[{\"txid\":\"$txid\",\"vout\":$vout}]" "{\"$recipient\":0.999}")


# Sign the transaction with the wallet
signed_json=$(bitcoin-cli -regtest signrawtransactionwithwallet "$raw")
signed_hex=$(echo "$signed_json" | jq -r '.hex')


# Broadcast the signed transaction
send_txid=$(bitcoin-cli -regtest sendrawtransaction "$signed_hex")


# Fetch and decode the broadcasted transaction (full JSON)
bitcoin-cli -regtest getrawtransaction "$send_txid" 1 | jq .


# Decode transaction hex (human-readable fields)
bitcoin-cli -regtest decoderawtransaction "$signed_hex" | jq .

This regtest flow demonstrates the entire lifecycle: fund a wallet, create a raw transaction using an unspent UTXO, sign it, and broadcast. You can inspect the result using getrawtransaction and decoderawtransaction to verify every field.

Burn Addresses & Vanity Addresses

Burn addresses

  • A burn address is an address to which BTC is sent intentionally to make it effectively unspendable (no private key exists for the address). A common example is 1BitcoinEaterAddressDontSendf59kuE frequently used to irretrievably remove coins.
  • Burn outputs can also be created using OP_RETURN outputs (data-carrying outputs) in a transaction, though OP_RETURN does not consume UTXO’s vout spendable value unless explicitly spent.
  • Example send to burn address (regtest/mainnet):
Terminal window
bitcoin-cli sendtoaddress 1BitcoinEaterAddressDontSendf59kuE 0.001

Vanity addresses

  • Vanity addresses are addresses that contain human-readable characters in their prefix (e.g., 1JohnD0e...), generated by repeatedly deriving keys until the resulting address matches a pattern. Tools like vanitygen are commonly used.
  • Security caveats for vanity addresses:
    • Never use third-party services to generate a private key unless you fully trust the tool - leaking keys to a remote generation service is extremely risky.
    • Vanity address generation for long prefixes is compute-expensive and may require GPUs or large cloud instances.

Use cases:

  • Burn addresses: publish tokens in immutable way or prove provenance of an event (some projects have used burns in protocol migrations).
  • Vanity addresses: brand presence or novelty; earnings in real-world usage risk leaving funds unspendable if private keys are lost.

Quotes & Primary Sources

From Satoshi Nakamoto’s whitepaper (2008):

“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.” - Satoshi Nakamoto, Bitcoin whitepaper (2008)

Authoritative references and sources used in this guide:

Final Thoughts: Is Bitcoin Safe? For Now - But Not Forever

Bitcoin’s architecture and ecosystem are robust and battle-tested. For short to medium timelines (today → next several years), existing operational best practices (address hygiene, hardware wallets, not reusing addresses, secure backups) remain effective. The long-term challenge is quantum computing: it changes the shape of trust and forces a protocol evolution.

If you hold long-term Bitcoin balances, consider a migration plan and pay attention to post-quantum cryptography developments. Hardware wallets and custodial providers may implement hybrid or PQ-safe schemes when the time is right.

Before You Store Bitcoin Long-Term (Checklist)

Use this short checklist when moving funds into long-term custody. These are practical hygiene items that reduce risk and help prepare for cryptographic or operational changes:

  • Use a hardware wallet: keep private keys offline via a verified hardware wallet and create a PSBT for offline signing.
  • Use strong seed backup: store the BIP-39 seed securely, preferably in multiple geographically-separate locations; consider using a metal backup for long-term durability.
  • Use multisig or threshold schemes for high-value holdings: splitting custody reduces single-point-of-failure risk.
  • Avoid address reuse and prefer SegWit / Taproot addresses for better privacy and lower fees.
  • Plan a migration path for quantum-safe upgrades: monitor NIST PQ announcements and maintain a migration checklist (e.g., move funds to new addresses signed with PQ-schemes when available).
  • Consider custody diversification: split holdings across trusted custodians and your own hardware wallet(s).
  • Practice the recovery process: perform a dry-run restoration from backup seed in a non-production environment.
  • Monitor the network and mempool: use a full node or services to detect suspicious reorgs or large-scale double-spend attempts.

Start Protecting Data from Quantum Threats

Important (Post-Quantum Protection)

Protect your files with Ellipticc Drive - 5 GB free.

Share:
ellipticc.
ellipticc.
ellipticc.
ellipticc.
ellipticc.
ellipticc.