Can someone explain how the Bitcoin Blockchain works?



I'm trying to figure out how the blockchain works and how to read it via website. Is there a laymen way of explaining how the block chain works and how to read the blockchain to trace transactions?

What I know so far is: the blockchain is just a public ledger of transactions on the bitcoin network.

Patoshi パトシ

Posted 2013-07-31T17:24:43.420

Reputation: 9 661

1The methods of accessing data will differ between using (web-based API) and Bitcoin-Qt/bitcoind (local API). If you are looking to pull all the blockchain data, you'll exceed access threasholds with – Stephen Gornick – 2013-07-31T23:56:10.753

3There are dozens of writeups about how Bitcoin works and the role of the blockchain. It would be much better if you would read one or two of them, and then ask specific questions about anything you don't understand. – Nate Eldredge – 2013-09-16T20:30:51.970

related What is the Blockchain?

– Murch – 2014-02-23T02:36:18.833



If you are completely new to Bitcoin, you may find my second answer more accessible, which is a less technical description.

As you said, the blockchain is a log of all transactions that were ever verified on the Bitcoin network.

The transactions are collected in blocks, which are found approximately every ten minutes in a random process called mining. As transactions transfer ownership of Bitcoin balances, each of these blocks represents an update of the user's balances on the network.
By following the blockchain from the Genesis Block and applying all transactions that were validated in each block in the correct order, you arrive at the current status quo.

Each block header contains:

Bitcoin Block Data [Illustration by Matthäus Wander (Wikimedia)]

  • Timestamp:
    The time when the block was found.
  • Reference to Parent (Prev_Hash):
    This is a hash of the previous block header which ties each block to its parent, and therefore by induction to all previous blocks. This chain of references is the eponymic concept for the blockchain.
  • Merkle Root (Tx_Root):
    The Merkle Root is a reduced representation of the set of transactions that is confirmed with this block. The transactions themselves are provided independently forming the body of the block. There must be at least one transaction: The Coinbase. The Coinbase is a special transaction that may create new bitcoins and collects the transactions fees. Other transactions are optional.
  • Target:
    The target corresponds to the difficulty of finding a new block. It is updated every 2016 blocks when the difficulty reset occurs.
  • Nonce:
    An arbitrarily picked number to conveniently add entropy to a block header without rebuilding the Merkle tree.
  • The block's own hash:
    All of the above header items (i.e. all except the transaction data) get hashed into the block hash, which for one is proof that the other parts of the header have not been changed, and then is used as a reference by the succeeding block.

As many miners compete to find the next block, often there will be more than one valid next block discovered. This is resolved as soon as one of the two forks progresses to a greater length, at which any client that receives the newest block knows to discard the shorter fork. These discarded blocks are referred to as extinct blocks (sometimes also referred to as orphaned blocks, although their complete ancestry is known).

When a transaction is submitted to the network, it is passed on peer to peer by all clients. Upon discovery miners will put it on their list of transactions that they want to verify and update the Merkle Root.

On you can track a transaction either by requesting the page directly with the transaction hash<transaction-hash>

or by calling one of the involved addresses through<address>

Either way for each transaction you will see a line with a big arrow that shows you which addresses' were used to fund the transaction and what addresses received which portions of the transaction.


Posted 2013-07-31T17:24:43.420

Reputation: 51 063

1As a member of the general public, this answer is next to useless. I do not understand IT but this answer is written as though I already knew this stuff - you need to start from a very simple example: Bill sells Sally some apples for £2.50 .... – None – 2016-01-22T16:24:45.503


@user32260: I hope that you find my second answer more accessible.

– Murch – 2016-01-22T18:41:38.087

The picture you've used also contains something called the "nonce", but your description leaves this out. Is it worth adding this, or is it of little concern to the overall explanation? – Richard Horrocks – 2016-04-20T20:57:18.177

@RichardHorrocks: the nonce is just a random number that adds entropy for finding a valid block. Miners go through millions of them to find a block. – Murch – 2016-04-20T23:32:46.197

@Murch: So anyone will know your Bitcoin balance, right? – anhldbk – 2016-12-28T01:30:51.323

No, how did you get that impression? – Murch – 2016-12-28T01:32:10.627

@anhldbk: Everybody knows the all spendable balances. However, in general it is not possible to know which balances belong to specific persons or which balances belong to the same person. – Murch – 2016-12-28T10:35:24.647

@Murch: So if I publicly post my bitcoin address on the Internet, so anyone will know my balance, right? – anhldbk – 2016-12-28T15:08:56.507

@anhldbk: If you only use one address, yeah. – Murch – 2017-07-15T04:17:40.640


For user32260: Bill sells Sally some apples for £2.50

Bill is a fruit vendor. Sally wants to buy some apples for £2.50. Sally wishes to use Bitcoin to pay Bill for the apples. Bill presents Sally his payment address, for example as a quickresponse code:

Bill's address

Sally uses a Bitcoin wallet on her smartphone to scan the code. She is presented a screen where she can enter an amount to send to Bill's address. She types '£2.50' and presses send. A moment later Bill's tablet notifies him that there is an incoming payment pending, which is not confirmed yet. About ten minutes later, the payment is finalized when it gets confirmed.

Under the hood

1) The payment order (Transaction):
The software on Sally's smartphone checks whether Sally has a sufficient balance and then creates a payment order, which we'll call a transaction. This transaction is composed of three pieces of information: which "coins" get spend, the payment to the recipient, and a signature.
Sally's wallet is connected to other participants in the network. The wallet passes the transaction to all of them, who in turn forward it to all of their connections. Within a few seconds, every participant in the network has received notification of Sally's payment order. Each and every participant checks whether the referenced "coins" exist, and whether the signature matches the owner's.

2) Confirmation:
So far, Sally's payment is only a promise, because the transaction is still unconfirmed.
To change that, some network participants, which we'll call miners, work on confirming these transactions. The miners grab all the unconfirmed transactions and try to pack them into a set. When this set doesn't fulfill the difficulty requirement, they reshuffle it and try again. Miners all over the planet are performing this work until at some point, somebody finds a set with the right properties: a valid block. Because finding a valid block is such an unlikely event, the announcement of the new block proves that the network has expended work to find it.
Just as with the transactions before, the miner sends the block to all their connections, who in turn forward it. Every participant checks the work (to confirm that the block follows the rules) and when satisfied, applies the included transactions to their own ledger: the transactions get executed and the "coins" that were used by the senders get marked as spent, whereas the recipients gain new "coins" as instructed by the transactions. Sally's transaction (and all the others) is now confirmed. Bill can now spend the "coins" he received from Sally.

3) The Blockchain
Let's take a step back. Before Sally paid Bill, Sally got her bitcoins from Alice. The order of transactions is crucial as transactions can only spend "coins" that have already been created. Sally can't pay Bill if she didn't get the money from Alice first. The transactions have an explicit position in the block that confirms them and each block has a fixed position in the block chain by referencing its direct predecessor. E.g. Block 90 links to Block 89 as its predecessor it, in turn Block 89 builds on Block 88, and so forth, until Block 2 points at the first block, the Genesis Block.

Genesis Block ← 2 ← … ← 88 ← 89 ← 90

The eponymous blockchain has useful properties:

  • Deterministic results: Everyone can start from the Genesis Block and apply each block consecutively to arrive at the same result.
  • Synchronization & Consensus: When you have applied the latest block, the balances in your ledger have the exact same state as in all the other participants' ledgers.
  • Unchangeable History: As each block builds upon its predecessor, each new block buries the history under more work (see graphic below):

enter image description here Illustration: Mark Montgomery/IEEE Spectrum


Posted 2013-07-31T17:24:43.420

Reputation: 51 063

What a brilliant answer. We need more stuff like this. :) – nz_21 – 2021-02-05T00:13:40.643

1What do you mean by requirements in the phrase "When their set doesn't fit the requirements, they reshuffle it and try again. " ? – anhldbk – 2016-12-28T01:34:04.333

@anhldbk: Miners hash their block drafts and see whether the block hash fulfills the difficulty requirement. If the hash doesn't fulfill the difficulty, it's not a valid block. – Murch – 2016-12-28T09:57:59.373

1I especially like how you summarized step 2. Very concise hashing-out of the process. – Darren – 2017-07-14T15:25:48.170

1@anhldbk: I've updated my answer to explicitly state the requirement.— Thanks Darren. :) – Murch – 2017-07-14T17:55:19.577

@Murch "Each and every participant checks whether the listed "coins" exist, and whether the signatory is the owner." So everybody must know how much money you have? – tomak – 2017-10-21T13:16:45.307

2@tomak: Everyone knows about all coins that exist, but other users don't know whom they belong to. When you spend, you prove that you have the right to spend, but still don't reveal your identity. You also do not reveal control of any "coins" that were not involved in this particular transaction (unless you're reusing addresses, or someone was able to identify a connection with the help of chain analysis). – Murch – 2017-10-23T23:45:53.473

in step 1 what happens when any of the checks fail? In step 2, is there any advantage for a miner to take only the minimum required transactions and combine them into a set/block? – RKA – 2017-11-27T16:30:16.863

1@RaviKumar: 1. If the checks fails, either the money didn't exist or the sender didn't authenticate themselves properly as the owner. The transaction is invalid. Nodes don't forward invalid transactions to their peers, and miners don't include invalid transactions in blocks. 2. If a miner hasn't verified the last block yet, they would run the risk of including a transaction that was already confirmed or is no longer valid if they found a new block right away, that's why miners may mine "empty blocks" very briefly after a block was discovered. Otherwise they earn more fees by including more tx. – Murch – 2017-11-27T16:34:31.187

I did not quite understand the “empty blocks” you mentioned and still few more questions :) Let us say miner m1 just completed verification of the previous block. Now, m1 forms new block and adds transaction tx1, tx2, tx3 to it and start working on finding the right solution. Meanwhile, miner m2 also has completed verification of the previous block, forms a new block and adds tx3 and tx4 to it. And if it so happens that m2 finds a solution first, then m2’s block is the valid next block. Am I right? – RKA – 2017-11-27T17:20:10.400



  • See for "empty blocks". 2) Usually, whenever someone finds a valid block, it becomes the new chaintip. The only natural exception to this is when two miners publish a block at exactly the same time. See e.g.
  • – Murch – 2017-11-27T21:32:34.523

    i am thinking about how the performance keeps up. If today the chain tip is 1million blocks away from the genesis-block and 2 years later the chain tip is 4 quadrillion blocks away from the genesis-block, how will a verification all the way to the genesis block work on a fast, high volume, high velocity transaction ecosystem where number of users/transactions are growing exponentially? Wouldn't it start to become exponentially slow? Will it still be 10 minutes of confirmation time till then? – Rakib – 2018-05-08T23:44:49.637

    Also, if a transaction is initially sent o all peers, and they send to all their peers, and they send to all their peers until EVERYONE in the network has a copy of the transaction as you described in step 1. Does that mean EVERY bitcoin blockchain user has to keep info about EVERY SINGLE ONE of the MILLIONS of transactions happening over the network? How does it account for everyone's data storage limits of storing so much information in every single node? – Rakib – 2018-05-08T23:47:29.763

    1@SyedRakibAlHasan: The block interval automatically corrects back to 10 minutes, in a bit over nine years, we only have 521822 blocks, and we'll have about 1100 per week going forward. You only have to keep track of every transaction if you're running an archival full node. Pruning nodes keep only a subset of the data, and thin clients only learn about transactions relevant to them in the first place. However, it seems to me that you should perhaps ask new question rather. ;) – Murch – 2018-05-08T23:48:11.513

    @SyedRakibAlHasan: Related

    – Murch – 2018-05-08T23:49:59.547