Blockchain and Bitcoin - Overview and Big Picture

Blockchain and Bitcoin in Plain Terms

A good way to see Bitcoin is as a specific application built on top of a more general idea called a blockchain.

A blockchain is a special kind of database or ledger that is:

Public or at least widely replicated
Append only, which means old records are very hard to change
Maintained collectively by many independent computers rather than a single central owner
Secured by cryptography instead of trust in any one institution

Bitcoin is the first large scale system that used this idea to implement a kind of electronic cash. The Bitcoin network is one concrete blockchain plus a set of rules that define how digital coins are created, moved, and validated.

From this starting point many other systems have evolved, such as alternative cryptocurrencies, smart contract platforms, and stablecoins.

To understand how all of this works, it helps to start with the structure of a block.

Inside a Block: Header, Body, and Merkle Tree

A blockchain is literally a chain of blocks. Each block is like one page in a global ledger. Each new block records a batch of transactions and links back to the previous page.

A block has two main parts:

The block header
The block body, which is the list of transactions

1 The block header

The block header is a compact summary that contains several critical fields. In Bitcoin it includes at least:

prev_block_hash
A hash of the previous block. This is like writing the fingerprint of the last page at the top of the new page. It is what forms the chain.
merkle_root
A single hash that summarizes all transactions in the block, computed using a structure called a Merkle tree.
timestamp
An approximate time when the miner created the block.
difficulty_target
Encodes how hard it currently is to find a valid block. The network adjusts this to keep block production at roughly one every ten minutes.
nonce
A number that miners keep changing while trying to find a valid block hash. The nonce is the main variable miners play with during proof of work.

All of that is combined and fed into a hash function, for example:

block_hash = SHA256(SHA256(block_header))

This produces a 256 bit output that acts as the identifier and fingerprint of the block.

2 The block body and the Merkle tree

The body of the block contains the transactions. Each transaction describes how some previously unspent outputs are being spent and who receives new outputs.

To summarize many transactions using one hash, Bitcoin uses a Merkle tree:

Each transaction is hashed individually.
For example h1 = H(tx1), h2 = H(tx2) and so on.
Hashes are paired together and concatenated, then hashed again.
For example h12 = H(h1 || h2), h34 = H(h3 || h4).
The process repeats level by level until there is only one hash left.
That final hash is the merkle_root.

The Merkle root lets nodes efficiently prove that a specific transaction is included in a block by presenting only a small path of hashes instead of all transactions. This compresses information and saves bandwidth.

Hash Functions and Why Blocks Are Hard to Tamper With

The security of the blockchain relies heavily on cryptographic hash functions. A hash function (such as SHA 256) takes any input and produces a fixed size output, usually represented as a long hexadecimal string.

Three key properties matter most here.

One way property
Given x, it is easy to compute H(x). Given only y = H(x), it is essentially impossible in practice to find any x that hashes to y except by brute forcing random inputs.
Collision resistance
It is extremely hard to find two different inputs x1 and x2 with x1 ≠ x2 such that H(x1) = H(x2). Mathematically collisions must exist because the input space is huge and the output space is finite. The security requirement is that no one can find such a pair with any realistic amount of computing power.
Avalanche effect
If you change the input by even one bit, the output hash changes completely in an unpredictable way.

Because of these properties, if someone edits even a single byte in an old block, that block’s hash changes. Since each block header includes the hash of the previous block, that change would propagate: every later block would also need to change. To make those changes valid the attacker would have to redo the proof of work for that entire part of the chain, which is extremely expensive.

How Proof of Work and the Chain Structure Protect History

Bitcoin uses proof of work to make block creation costly and to decide which version of history the network accepts.

1 The mining puzzle

Miners construct a candidate block, which includes:

The hash of the previous block
The Merkle root of all included transactions
The current difficulty target
A nonce and some other header data

They then run a loop:

Serialize the block header.
Compute hash = SHA256(SHA256(block_header)).
Check whether this hash interpreted as a number is less than the difficulty target.
If not, change the nonce or slightly modify the block (for example adjust the coinbase transaction) and try again.

There is no shortcut that is known. The only feasible strategy is to try many nonces and keep hashing until a valid hash appears. This is why it is called proof of work. The hash itself is proof that the miner spent real computing work.

The difficulty target is set so that on average the combined network finds a suitable hash for a block around every ten minutes.

2 Longest chain as the accepted history

Every full node follows a simple consensus rule:

Among all valid chains, the node treats the chain with the greatest cumulative proof of work as the canonical history.

Cumulative proof of work is often approximated by chain length, although in detail it depends on difficulty as well.

When two miners find different blocks at approximately the same time, a temporary fork appears. Some nodes see one block first, others see the other. Later miners will build on whichever block they have. Over time one branch will grow faster and become longer. The network converges on that chain, and the shorter branch becomes abandoned. This process is automatic and does not require any central coordinator.

Because rewriting history requires building an alternative chain with more total work than the honest chain, an attacker would need to control more computing power than the rest of the network combined, and even then the cost grows with the depth of the history they want to rewrite.

Keys, Addresses, and Ownership of Coins

Bitcoin does not use the traditional concept of an account with a single balance field. Instead it uses unspent transaction outputs, usually called UTXOs.

1 Private keys, public keys, and addresses

Ownership is based on public key cryptography.

A private key is a 256 bit random number. There are roughly 2^256 possible private keys, which is astronomically large.
A public key is derived from the private key using elliptic curve cryptography. In Bitcoin the curve is called secp256k1. The relationship can be thought of as:

K = k * G

Here k is the private key, G is a fixed base point on the elliptic curve, and K is the public key. Computing K from k is easy. Computing k from K is believed to be practically impossible because it is equivalent to solving the discrete logarithm problem on that curve.
A Bitcoin address is a shorter representation created by hashing the public key and encoding it. That address is what users typically share for receiving payments.

As long as the private key is kept secret, no one else can generate valid signatures for that address. This is what enforces ownership.

2 UTXO model and spending

Each transaction creates outputs. Each output assigns a certain amount of bitcoin to a locking script that usually refers to a public key or address. Outputs that have not yet been spent are called UTXOs.

When you want to spend coins, your wallet:

Selects enough of your UTXOs to cover the desired payment amount plus transaction fee.
Constructs a new transaction that references those UTXOs as inputs.
Creates new outputs. Typically one goes to the recipient and one goes back to you as change.
Hashes the transaction data to obtain a message digest.
Uses the corresponding private key to sign this digest, producing a digital signature.
Attaches the signature and public key information to the transaction.

Any node can then verify that:

The UTXOs referenced exist and have not already been spent
The signature is valid for the message and the public key
The public key matches the locking condition on the UTXO
The total value of inputs is at least as large as outputs plus fees

This combination of signatures, UTXO bookkeeping, and validation ensures that coins cannot be spent twice and cannot be spent by anyone who does not have the proper private key.

3 other ref

https://shiluqi.blogspot.com/2025/11/blockchain-and-bitcoin-records-coins.html

Digital Signature Verification and a Full Transaction Example

1 Why digital signatures are needed

In Bitcoin the system needs to solve three problems at the same time:

Who is allowed to spend a given set of coins
Whether a spend instruction really came from that owner
Whether the transaction data stayed unchanged while traveling through the network

Digital signatures are the tool used to solve these three issues. A signature allows you to:

Use your private key to sign some data, similar to writing a handwritten signature
Let anyone use your public key to verify that the signature was created by the matching private key
Detect any modification of the signed data, because a changed message will no longer match the original signature

Signatures provide authorization and tamper resistance.

2 What signing and verification do at a high level

Bitcoin uses the elliptic curve digital signature algorithm, ECDSA. You do not need the full math, only the structure.

Key pair generation
- Pick a very large random integer k as the private key
- Compute K = k * G on the elliptic curve to get the public key
Signing: Sign(k, message)
When your wallet creates a transaction it effectively does the following.
- Hash the important parts of the transaction data
  m = H(tx_data)
- Use the private key k together with a fresh random value inside the signing algorithm to produce a signature sig
- The signature is a compact piece of data that only verifies correctly with the right K and the original m
Verification: Verify(K, message, sig)
When a node receives your transaction it:
- Recomputes the hash m = H(tx_data)
- Uses the public key K and the signature sig inside the verification algorithm
- The math checks whether there exists some private key k such that K = k * G and that could have produced sig for this m
- If that is not possible, verification fails and the transaction is rejected

The key ideas are:

The private key is used to sign, which proves that the owner approved the message
The public key is used to verify, so everyone can check
Any change to the transaction data changes its hash and makes the old signature invalid

3 A full example from private key to block inclusion

The following example ties these ideas together.

Generating a private key and address

The wallet generates a random private key k
It computes the public key K = k * G
It hashes the public key to derive an address addr
The wallet stores k securely and presents addr to you as your receiving identifier

You can think of the private key as the key to your safe, the public key as a mathematical verifier for that key, and the address as the bank account number that others can use to pay you.

Receiving a payment

A friend sends 0.5 BTC to your address addr
That transaction is eventually mined into a block
Nodes update their UTXO set
- They add a UTXO that says “0.5 BTC locked to the script corresponding to your public key hash”
Your wallet sees that this new UTXO can be unlocked with your keys and shows a balance of 0.5 BTC

From the system perspective there is no explicit balance field for you. The ledger simply has a UTXO worth 0.5 BTC, and whoever can provide the correct signature is allowed to spend it.

You send a payment, creating and signing a transaction

Suppose you want to pay someone 0.1 BTC and are willing to pay 0.0001 BTC as a fee.

Select a UTXO
- The wallet selects your 0.5 BTC UTXO as the input
Construct the transaction
- Input: that 0.5 BTC UTXO
- Output 1: 0.1 BTC to the recipient’s address
- Output 2: 0.3999 BTC as change back to a fresh address of yours
- The remaining 0.0001 BTC is the miner fee
Create the message to be signed
- The wallet builds the transaction structure and computes a hash m = H(tx_data)
Sign using your private key
- It computes sig = Sign(k, m)
- It inserts sig and the relevant public key into the unlocking script for the input
Broadcast
- The wallet sends the fully signed transaction to a Bitcoin node

How nodes verify and accept this transaction

When a node receives your transaction it:

Checks the basic format of the transaction
Confirms that the referenced UTXO exists and is unspent
Checks that the values add up
- Total input = 0.5
- Total outputs = 0.1 + 0.3999
- Fee = 0.0001
Verifies the digital signature
- Extracts your public key K from the input script
- Recomputes m = H(tx_data)
- Calls Verify(K, m, sig)
- If verification passes, it knows that
  - Someone with the matching private key approved the transaction
  - The transaction data has not been modified after signing
If all checks pass, the node puts the transaction into its mempool where miners can see it

Miners include it in a block and your signature becomes part of history

A miner selects transactions from its mempool, sorted by fee rate
The miner builds a candidate block that includes your transaction, computes the Merkle tree and block header
The miner performs proof of work by repeatedly hashing the header until it finds a valid hash below the target
When it finds a valid block it broadcasts it to the network
Other nodes verify the block and each transaction inside, including your signature
Once accepted, nodes update the UTXO set
- Your old UTXO is marked as spent
- The recipient’s output and your change output become new UTXOs

From that moment onward your signature and your transaction are part of the blockchain history. Every new block built on top of that block increases the confirmation count of your payment.

Full Transaction Flow: From Click to Block

The complete lifecycle of a typical Bitcoin transaction can be summarized as follows.

1 Creation in the wallet

You click “Send” in your wallet and provide the recipient address and amount.
The wallet scans your local data or connected node to find your available UTXOs.
It chooses enough UTXOs to cover the amount plus a suitable fee.
It constructs a raw transaction with inputs and outputs.
It signs the transaction with your private key.
It runs basic sanity checks on the transaction and then sends it to a node, either your own full node or a remote service.

2 Validation and mempool

The receiving node:

Parses the transaction and checks its structure.
Verifies all signatures.
Confirms that each referenced UTXO exists and is unspent in its current UTXO set.
Checks for double spends and that the sum of inputs covers outputs plus fee.
If all validation passes, the node adds the transaction to its mempool, which is a pool of valid but unconfirmed transactions.
The node then relays the transaction to its peers, which repeat the same process. The transaction spreads across the network.

3 Miners select transactions

A miner’s node maintains its own mempool as well. When constructing a block, the miner:

Updates its mempool with newly received transactions.
Sorts transactions by fee rate, which is fee per unit of data size.
Selects a set of transactions to fit into the block under size and weight limits.
Creates a special transaction called the coinbase transaction that collects the block subsidy and the total fees of included transactions.
Builds the Merkle tree of all transaction hashes and computes the Merkle root.
Fills the block header fields including previous block hash, Merkle root, timestamp, difficulty target, and nonce.

4 Proof of work mining loop

The miner then enters the mining loop:

Serializes the block header.
Computes hash = SHA256(SHA256(header)).
Checks whether the hash is below the difficulty target.
If not, increments the nonce or tweaks some minor field and tries again.

This can happen trillions of times before a valid hash appears.

When a miner finally finds a hash below the target, it has discovered a valid new block.

5 Block broadcast and acceptance

The winning miner broadcasts the block to its peers. Each full node that receives the block:

Verifies the header:
- The previous block hash matches the node’s current chain tip
- The block hash meets the current difficulty target
- The timestamp and version are within acceptable bounds
Verifies every transaction in the block:
- Checks all signatures
- Ensures that no transaction double spends any UTXO
- Confirms that the coinbase reward (subsidy plus fees) does not exceed the allowed limit
- Ensures inputs and outputs are consistent

If the block is valid and extends the current best chain, the node:

Adds the block to its local chain
Updates the UTXO set by removing spent outputs and adding new outputs

At this moment your transaction is considered confirmed once.

6 Further confirmations

Subsequent blocks are mined on top of this block. Each new block that builds on it increases the confirmation count for your transaction.

In practice many users and services treat six confirmations as very safe against reorganization attacks, especially for high value transfers.

Node Types, Storage Requirements, and Practicality

A common question is whether every participant must store the entire blockchain and whether that is realistic.

The answer is that not every computer does so. There are different kinds of nodes.

1 Full nodes

Full nodes keep a complete or logically complete copy of the blockchain and independently verify every block and transaction according to the protocol rules. They do not trust others to tell them which blocks are valid.

Running a full node has some storage cost. Bitcoin’s blockchain size is in the range of hundreds of gigabytes rather than petabytes, which modern consumer hardware can handle.

There are also pruning modes for full nodes. In a pruned node configuration, the node verifies all blocks but only keeps recent data and the minimal information required to maintain the current UTXO set. Older block data can be deleted from disk after it has been fully validated. This reduces storage requirements significantly.

2 Light nodes and custodial wallets

Most users do not run full nodes. Instead they often use:

Lightweight wallets (also known as SPV wallets) that do not download all blocks. They rely on other full nodes to provide proofs that a transaction is included in some block.
Custodial services such as exchanges. In this case the service runs full nodes and handles blockchain interaction, while the user trusts the service to keep accurate balances.

These approaches reduce the storage and bandwidth burden on normal users, while full nodes and specialized operators bear the cost of storing and validating the entire chain.

3 Why run a full node

Even though running a full node is not required for everyone, it has important benefits for those who do.

Independent verification
A full node user does not rely on any third party to decide which transactions and blocks are valid. The node checks every rule itself. This reduces the risk of being tricked by a dishonest or censored service that provides a filtered view of the blockchain.
Better privacy
Light wallets usually need to ask some server which transactions relate to a set of addresses. That server can infer which addresses belong to the user and analyze their history. A wallet that connects only to a user’s own full node does not need to reveal its addresses to anyone else.
Reliability
With a personal full node, the wallet has a direct connection to the network. It does not depend on any single provider staying online or honest. This can help in environments where connectivity is restricted or where certain services may be blocked.
Public good and network health
Every full node that independently validates and propagates blocks contributes to decentralization. It becomes harder for a single government, company, or attacker to control the network. This indirectly protects the value of everyone’s bitcoins, including the node operator’s own holdings.

It is important to note that full nodes do not receive direct block rewards. Mining and node operation are separate roles. Miners earn block subsidies and fees. Nodes that only validate and relay do not receive protocol level payments, though they may be run by businesses that earn money in other ways.

Mining Rewards, Halving, and the Future Fee Economy

Bitcoin controls its money supply using a predictable halving schedule.

At the start in 2009, each block paid a subsidy of 50 BTC to the miner. This subsidy halves every 210,000 blocks, which corresponds to about four years at ten minutes per block. The sequence of subsidies is therefore:

50, 25, 12.5, 6.25, 3.125 and so on.

The total supply of bitcoin approaches but never exceeds 21 million coins. As the subsidy halves repeatedly, eventually the block reward in terms of newly created coins becomes extremely small. After roughly 130 years from launch, around the year 2140, the block subsidy will be effectively zero because the smallest unit is one satoshi, and the protocol will not create fractional satoshis.

Miners will then be paid almost entirely through transaction fees.

Even today miners already earn both subsidy and fees. Over time the ratio will shift further toward fees.

In that future era, the incentive model becomes:

Users who want their transactions included must attach fees.
Miners will include transactions based on fee rates, aiming to maximize revenue per block subject to size constraints.
If total fee revenue in a block is high, more miners have incentive to join or remain, raising network hash power and security.
If fees are very low and usage is limited, some miners may shut down because their operating costs exceed their expected fee income. Hash power may decline and the network could become easier to attack.

There is a dynamic market feedback loop. The difficulty adjustment also interacts with this. If many miners leave, blocks slow down until the next difficulty adjustment, which reduces difficulty and lowers cost for the remaining miners.

How secure Bitcoin will be when only fees exist depends on long term adoption and demand. If by then the network is widely used, fees could be sufficient to support a strong mining ecosystem. If demand is weak, hash power and therefore security may be lower. This is an open topic in research and community discussion, but the transition will be gradual and takes place over many decades.

Majority Hash Power and Rewriting History

A classic concern is what happens if some group of miners controls more hash power than the rest of the network combined, particularly in the early days when the total hash power is small.

1 The majority attack scenario

Suppose an attacker controls more than fifty percent of the total hash power. They can attempt the following:

Choose a block in the recent past.
Starting from the block before that, quietly mine their own private chain, where they change the transactions in the chosen block and subsequent blocks. For example they remove a payment they made and insert a different one.
While they work on the private chain, the honest network continues to extend the public chain.
Because the attacker has more hash power, their private chain tends to grow faster.
Once the private chain becomes longer than the public chain, the attacker broadcasts their chain to the network.

2 What honest nodes do

Honest nodes follow the rule of selecting the valid chain with the greatest cumulative proof of work.

When they receive the attacker’s chain, they do not see any explicit error. They:

Verify each block in the attacker’s chain, ensuring all consensus rules are followed.
Notice that at some height the chain diverges from their current view.
Compare cumulative work and see that the new chain has more work than their old chain.
Perform a chain reorganization:
- Roll back to the fork point
- Mark the previous blocks beyond that point as orphaned or stale
- Apply the blocks from the new chain, updating the UTXO set accordingly

This is considered a normal, although usually shallow, event in the protocol. Nodes log that a reorganization occurred, but they do not treat it as a software error.

From the node’s perspective, the history after the fork point is replaced by the attacker’s version. Transactions that were in the old chain but missing from the new one may become unconfirmed again or may be conflict with double spend transactions that now dominate.

3 What an attacker can and cannot do

With majority hash power, the attacker can:

Reverse their own payments by building an alternative history where their original payment never occurred and they spend the same coins differently. This is how a double spend attack works.
Delay or censor other transactions by refusing to include them in the blocks they mine, especially if they dominate most of the mining capacity.

However, even with fifty percent or more hash power, the attacker cannot:

Break consensus rules such as maximum block reward or money supply. Honest nodes will reject any block that violates these rules regardless of hash power.
Spend coins that belong to other people without their signatures. They cannot derive private keys or forge signatures by sheer hash power. That part is protected by cryptography, not by proof of work.

Rewriting deep history is possible in theory but becomes increasingly expensive and more visible. It would require redoing proof of work for many blocks and overcoming the continuing work of honest miners. In addition, if such an attack is detected, exchanges, users, and developers might coordinate a social response such as changing software to ignore the attacker’s chain. That moves beyond pure protocol rules into community governance.

The combination of majority hash power being expensive to acquire and the inability to break fundamental rules limits what such an attack can achieve.

Hash Collisions: Theory, Practice, and Response

A hash collision occurs when two different inputs produce the same hash output. Theoretically collisions must exist for any fixed length hash function because there are more possible inputs than outputs.

Bitcoin relies primarily on SHA 256 and SHA 256 combined with RIPEMD 160 in some contexts such as address generation.

1 Theoretical versus practical collisions

For SHA 256, the output length is 256 bits. There are 2^256 possible output values, which is roughly 1.16 × 10^77. Due to the birthday paradox, on the order of 2^128 random trials would be needed to have around a fifty percent chance of stumbling across a collision by pure luck.

That number of trials is completely infeasible with any realistic amount of computing power in the lifetime of the universe.

Therefore:

In a strict mathematical sense collisions exist.
In practice the probability that anyone will encounter a random collision in the normal operation of Bitcoin is so tiny that it can be ignored.

So under current knowledge, Bitcoin’s design treats natural collisions as a non issue.

2 Deliberate collisions and hash function breaks

The real risk would be if someone discovered a practical method to construct collisions for SHA 256. That is what happened to SHA 1, where researchers were eventually able to generate artificial collisions.

If such a break occurred for SHA 256, an attacker might craft two distinct pieces of data that share a hash. In the context of Bitcoin, this could create subtle attacks where a user sees a benign transaction while miners are tricked into including a different one with the same hash.

Such an event would not affect only Bitcoin. Many systems use SHA 256. A break would be a major news event across the entire cryptographic community.

3 How a blockchain would respond

If a widely used hash function became unsafe, the likely response for a blockchain would be to upgrade to a different function. This would involve:

Designing and implementing new rules that use a stronger hash function, for example SHA 3 or another vetted algorithm.
Releasing new node software that understands the new rules.
Using either a soft fork or hard fork approach to switch over. For example new blocks from a certain height might be required to use the new hash while old blocks remain as historical data.
Providing migration paths for addresses, transactions, and scripts that depend on the old hash.

This process would take coordination but is conceptually straightforward. Cryptographic algorithms are ingredients that can be replaced while the higher level economic design and consensus rules stay similar.

At the level of day to day understanding, it is safe to think of SHA 256 collisions as practically impossible under current knowledge. If that changes, the global cryptography and blockchain communities would react and adapt.

From Bitcoin to the Wider Ecosystem: Other Coins and Stablecoins

Bitcoin introduced the basic idea that you can have a decentralized digital currency secured by mathematics and proof of work rather than a central bank.

From that idea several directions of evolution have emerged.

1 Other cryptocurrencies

Some projects focus on more expressive smart contracts. Ethereum is a prime example. It extends the basic idea of a blockchain to support general purpose computation and stateful smart contracts. This enables decentralized finance applications, games, token systems, and more.

Other projects aim at different tradeoffs such as enhanced privacy, higher transaction throughput, or new consensus mechanisms.

Although their details differ, many still rely on similar ingredients: blocks, hashes, signatures, and some method to reach consensus on a shared transaction history.

2 Stablecoins

One of the most important offshoot concepts is the stablecoin.

Bitcoin is volatile and fluctuates in fiat value. This makes it less convenient for day to day denominated payments. Stablecoins try to create tokens that trade close to a target price, often one unit of a national currency such as the United States dollar.

There are several main designs:

Fiat backed stablecoins
A central issuer holds reserves of fiat currency or equivalent assets. For each unit of fiat deposited, it issues one token on a blockchain. Users treat the token as a representation of that currency. Redeemability at a one to one ratio is key. Examples include widely known dollar stablecoins. The main trust assumption is that the issuer actually has the reserves and manages them honestly.
Crypto collateralized stablecoins
These are somewhat more decentralized. Users lock volatile crypto assets like ether into smart contracts and mint stablecoins against that collateral. The system enforces over collateralization so that price swings in the collateral do not immediately break the peg. Interest rates and liquidation rules manage risk.
Algorithmic stablecoins
These attempt to stabilize price using purely algorithmic expansion and contraction of supply, often through linked token pairs and market incentives. Several such designs have failed dramatically when market conditions stressed the system.

Stablecoins act as a type of on chain cash denominated in familiar units such as dollars. They make it easier to trade and store value within the crypto ecosystem without constantly moving between exchanges and bank accounts.

3 DeFi and beyond

On blockchains that support smart contracts, decentralized finance systems can be built that offer lending, borrowing, trading, derivatives, and other financial services. Non fungible tokens represent unique digital items. Scaling solutions and second layers move many transactions off the main chain while settling final results on it.

Many of these systems still use Bitcoin’s original ideas about cryptographic ownership, hash based data structures, and consensus.

ASCII Flow Diagram of a Bitcoin Payment

For completeness, here is a compact ASCII style flow diagram describing a Bitcoin payment from send to confirmation, corresponding to the detailed explanation earlier.


+---------------------------------------------------------------+
|                  1. WALLET CREATES TRANSACTION                |
+---------------------------------------------------------------+

   [You click "Send" in your wallet]
                       |
                       v
   +----------------------------------------------+
   | 1.1 Select UTXOs (your spendable coins)      |
   |----------------------------------------------|
   | - Wallet scans your local data or full node  |
   |   for your unspent outputs (UTXOs).          |
   | - Chooses enough UTXOs to cover:             |
   |      amount_to_send + fee                    |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 1.2 Build a raw transaction                  |
   |----------------------------------------------|
   | Inputs:  which UTXOs you're spending         |
   | Outputs:                                     |
   |   - recipient address + amount               |
   |   - your change address + change amount      |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 1.3 Sign the transaction                     |
   |----------------------------------------------|
   | - Hash the transaction data (tx digest).     |
   | - Use your private key(s) to create          |
   |   digital signature(s).                      |
   | - Attach signatures + public keys            |
   |   into the transaction.                      |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 1.4 Final checks & broadcast                 |
   |----------------------------------------------|
   | - Wallet checks structure, fee, etc.         |
   | - Sends the signed transaction to            |
   |   a Bitcoin node (your own or a server).     |
   +----------------------------------------------+


+---------------------------------------------------------------+
|            2. NODE VALIDATION & MEMPOOL (UNCONFIRMED)         |
+---------------------------------------------------------------+

   [Your connected node receives the transaction]
                       |
                       v
   +----------------------------------------------+
   | 2.1 Basic transaction validation             |
   |----------------------------------------------|
   | - Check syntax / format.                     |
   | - Verify each signature is valid.            |
   | - Check inputs (UTXOs) exist and are         |
   |   unspent in its current UTXO set.           |
   | - Check no double-spend.                     |
   | - Check amounts make sense:                  |
   |      sum(inputs) >= sum(outputs) + fee       |
   +----------------------------------------------+
                       |
       If invalid -----------------------------X (reject)
                       |
                       v
   +----------------------------------------------+
   | 2.2 Place into mempool                       |
   |----------------------------------------------|
   | - Node stores tx in its mempool              |
   |   (pool of unconfirmed transactions).        |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 2.3 Gossip to other nodes                    |
   |----------------------------------------------|
   | - Node announces the tx to its peers.        |
   | - Other nodes repeat 2.1 -> 2.2 -> 2.3.      |
   | - Soon, many nodes and miners know           |
   |   about your transaction.                    |
   +----------------------------------------------+


+---------------------------------------------------------------+
|          3. MINER PICKS TRANSACTIONS FOR A NEW BLOCK          |
+---------------------------------------------------------------+

   [A miner is trying to create the next block]
                       |
                       v
   +----------------------------------------------+
   | 3.1 Miner updates its mempool view           |
   |----------------------------------------------|
   | - Miner node has its own mempool, filled     |
   |   by the same gossip process.                |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 3.2 Choose which transactions to include     |
   |----------------------------------------------|
   | - Miner sorts mempool by fee rate            |
   |   (fee per byte).                            |
   | - Picks a set of transactions that fit       |
   |   into the maximum block size/weight.        |
   | - If your fee is competitive enough,         |
   |   your tx is selected.                       |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 3.3 Build candidate block                    |
   |----------------------------------------------|
   | - Create a "coinbase" transaction:           |
   |     * mining reward + total fees             |
   | - Collect selected transactions, including   |
   |   (possibly) yours.                          |
   | - Build a Merkle tree of all tx hashes and   |
   |   compute the Merkle root.                   |
   | - Fill the block header with:                |
   |     * version                                |
   |     * previous block hash                    |
   |     * Merkle root                            |
   |     * timestamp                              |
   |     * difficulty target                      |
   |     * nonce (starting guess)                 |
   +----------------------------------------------+


+---------------------------------------------------------------+
|                4. PROOF-OF-WORK (MINING LOOP)                 |
+---------------------------------------------------------------+

   [Miner now tries to find a valid hash]
                       |
                       v
   +------------------------------------------------------+
   | 4.1 Repeated hashing with different nonces           |
   |------------------------------------------------------|
   | LOOP:                                                |
   |   - Serialize the block header.                      |
   |   - Compute hash = SHA256(SHA256(block_header)).     |
   |   - Check if hash < target difficulty.               |
   |   - If NOT:                                          |
   |        * change nonce (or tweak coinbase / tx set)   |
   |        * repeat.                                     |
   +------------------------------------------------------+
                       |
       If no valid hash yet ------------------> (keep looping)
                       |
                       v
   +----------------------------------------------+
   | 4.2 Found a valid block                      |
   |----------------------------------------------|
   | - One nonce finally produces a hash below    |
   |   the target.                                |
   | - This miner has discovered a new block.     |
   +----------------------------------------------+


+---------------------------------------------------------------+
|          5. NEW BLOCK BROADCAST & NETWORK VALIDATION          |
+---------------------------------------------------------------+

   [Miner broadcasts the new block to the network]
                       |
                       v
   +----------------------------------------------+
   | 5.1 Other nodes receive the block            |
   |----------------------------------------------|
   | - Peers get the block from the winning       |
   |   miner (and from each other).               |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 5.2 Full block validation                    |
   |----------------------------------------------|
   | Nodes check, in order:                       |
   | - Block header:                              |
   |   * previous block hash matches their tip    |
   |   * hash meets difficulty target             |
   |   * timestamp & version are acceptable       |
   | - All transactions in the block:             |
   |   * signatures valid                         |
   |   * no double-spends                         |
   |   * coinbase reward within allowed limit     |
   |   * total inputs >= total outputs + fees     |
   +----------------------------------------------+
                       |
       If invalid -----------------------------X (reject block)
                       |
                       v
   +----------------------------------------------+
   | 5.3 Extend the chain                         |
   |----------------------------------------------|
   | - If valid and built on the chain tip,       |
   |   node accepts this as the new best block.   |
   | - Updates its UTXO set:                      |
   |     * removes spent UTXOs                    |
   |     * adds new outputs (including yours)     |
   | - Your transaction is now "confirmed"        |
   |   (1 block confirmation).                    |
   +----------------------------------------------+


+---------------------------------------------------------------+
|                 6. MORE CONFIRMATIONS (DEEPER)                |
+---------------------------------------------------------------+

   [Other miners now build on top of this block]
                       |
                       v
   +----------------------------------------------+
   | 6.1 Subsequent blocks get mined              |
   |----------------------------------------------|
   | - New blocks A, B, C... are mined that all   |
   |   reference this block (directly or via tip) |
   | - Each new block adds one more confirmation. |
   +----------------------------------------------+
                       |
                       v
   +----------------------------------------------+
   | 6.2 Final user perception                    |
   |----------------------------------------------|
   | - Wallet / exchange shows something like:    |
   |     * "1 confirmation" → just entered chain  |
   |     * "6 confirmations" → considered very    |
   |       safe against reorg / double spend.     |
   | - At this point, your payment is effectively |
   |   treated as permanent history.              |
   +----------------------------------------------+

Closing Summary

Putting everything together, Bitcoin is a system where:

Ownership of coins is enforced by public key cryptography.
Transactions are grouped into blocks whose headers link together with hashes to form a chain.
Miners expend real computing work to solve a puzzle, establishing proof of work that makes the chain hard to rewrite.
Nodes independently verify all rules and follow the valid chain with the most work.
Incentives are provided first by block subsidies and later more by transaction fees.
Attacks require either breaking the cryptography or controlling a majority of hash power at significant cost.
The broader crypto ecosystem extends these ideas into stablecoins, smart contracts, and decentralized finance.

November 15, 2025

1. Blockchain and Bitcoin - Overview and Big Picture