bitcoincryptographyblockchain

Life of a Bitcoin Transaction

From the moment you press “Send” to the final confirmation on the blockchain, every step visualized

01Key Generation

Everything starts with randomness. Your wallet generates a private key, a random 256-bit number, then derives a public key using elliptic curve multiplication (secp256k1). The Bitcoin address is a hash of that public key.

Derivation chain

256-bit random→Private Key (k)→k × G = Public Key→HASH160 → Address

Private key = secret (never shared)
Public key = derived via ECDSA on secp256k1
Address = RIPEMD160(SHA256(pubkey)) + Base58/Bech32

02Building the Transaction

Bitcoin doesn't track “balances.” Instead, it uses UTXOs (unspent transaction outputs). To send BTC, your wallet selects UTXOs that total at least the amount you want to send, and constructs a new transaction.

Transaction structure

Inputs (what you're spending):
  Reference to previous tx output (txid:vout)
  Unlocking script (scriptSig / witness)

Outputs (where coins go):
  Output 0: 0.05 BTC to recipient address
  Output 1: 0.0489 BTC to your change address

Implicit fee = inputs minus outputs = 0.0011 BTC

03Digital Signature

Your wallet signs each input with the corresponding private key using ECDSA (or Schnorr for Taproot). This proves you own the coins being spent without revealing your private key.

Signing process

Transaction data+Private key→ECDSA Sign→(r, s) signature

Anyone can verify using the public key:
ECDSA_Verify(pubkey, txhash, sig) → pass or fail

The signature is placed in the scriptSig (legacy) or witness (SegWit) field of each input.

04Broadcast to the Network

Your wallet sends the signed transaction to a connected Bitcoin node. That node validates it and relays it to its peers. Within seconds, the transaction floods across thousands of nodes worldwide via gossip protocol.

Node validation checks

Syntactically valid (correct format)
Inputs reference existing, unspent UTXOs
Signatures are valid for each input
Input value is greater than or equal to output value (positive fee)
Not a double spend of already seen tx
Scripts evaluate to TRUE
Transaction size within limits

05The Mempool

Each node keeps a “waiting room” of unconfirmed transactions called the mempool (memory pool). Your transaction sits here, competing with thousands of others. Miners pick from this pool to build the next block.

Mempool prioritization

Miners rank transactions by fee rate (sat/vB):

50 sat/vB30 sat/vB10 sat/vB3 sat/vB

Higher fee rate means picked sooner
If mempool is full, lowest fee txs get evicted

06Mining & Proof of Work

A miner selects transactions from the mempool (prioritizing high fee rates), assembles them into a candidate block, and begins the Proof of Work grind: repeatedly hashing the block header with different nonces until the hash falls below the difficulty target.

Block header fields

version | prev_block_hash | merkle_root
timestamp | difficulty_bits | nonce

The mining loop:

Pick nonce→SHA256(SHA256(header))→hash < target?

If no, try another nonce (trillions of attempts)
If yes, block found! Broadcast immediately.

07Merkle Tree Construction

Before mining, the miner hashes all selected transactions into a Merkle tree. The root of this tree (the Merkle Root) goes into the block header. This commits to every transaction in the block with a single 32-byte hash.

This is the structure that enables SPV (light client) proofs. The root locks in all transactions; a logarithmic proof can verify any single one.

08Block Propagation

The winning miner broadcasts the new block to the network. Each node independently validates the block, checking the PoW, all transaction signatures, UTXO references, the Merkle root, and the link to the previous block. Valid blocks are appended to the chain.

Block validation

Proof of Work: hash < difficulty target
Previous block hash matches chain tip
Merkle root matches transaction list
Every transaction passes full validation
Block size within consensus limits
Coinbase reward is at most subsidy + total fees
Timestamp within acceptable range

09Confirmations

Once your transaction is in a block, it has 1 confirmation. Each subsequent block mined on top adds another confirmation. The deeper it's buried, the harder it is to reverse because an attacker would need to redo the Proof of Work for every block on top.

Confirmation security

1 confirmation means the tx is in a block (~10 min avg)
3 confirmations is safe for moderate amounts
6 confirmations is the Bitcoin gold standard (~1 hour)

Reversing 6 blocks requires an attacker to outpace the entire honest network's hash power for ~1 hour, which is astronomically expensive.

10UTXO Set Updated

Every full node updates its UTXO set: the inputs your transaction spent are removed (now spent), and the new outputs are added (now available for future spending). The cycle is complete and your recipient can now spend their new UTXO.

UTXO lifecycle

Old UTXO (spent)→Your Transaction→New UTXO

The recipient's wallet sees the new UTXO and updates their displayed balance.

The transaction is now final.

At a Glance

Cryptography

ECDSA / Schnorr + SHA-256

Block Time

~10 minutes avg

Tx Commitment

Merkle Root in header

Consensus

Proof of Work (SHA-256²)

Safe at

6 confirmations (~1 hr)

Model

UTXO-based (not accounts)