<p>the BLK files are not an API. You shouldn't directly read those files.
What you should do is requesting the headers/block via the JSON RPC interface (or the REST interface).</p>

<p>You can get the genesis block hash via:</p>

<pre><code>bitcoin-cli getblockhash 0
</code></pre>

<p>Then you can get a block (without transactions):</p>

<pre><code>bitcoin-cli getblock &lt;hash&gt;
</code></pre>

<p>Then get the next block by looking at the <code>nextblockhash</code> item in the block JSON response, etc.</p>

<p>Also, consider using the REST interface. There you can get binary responses which are much faster (no JSON encoding/decoding overhead).</p>

CC BY-SA 3.0
2017-04-11T07:10:04.980Z
To answer the question more directly: if you read the blk files directly, you would find the chain's blocks out of order, potentially with gaps in between, including forked off blocks, and the format may change in future versions.
Pieter Wuille
CC BY-SA 3.0
2017-04-11T13:57:41.120Z
@PieterWuille many thanks for the clarification.
Bobo
CC BY-SA 3.0
2017-04-12T02:56:15.177Z
@PieterWuille you'r wrong. While reading blk files with some math you can find order of blockchain exclude of any gaps or forks. Perhaps.
Denis Leonov
CC BY-SA 3.0
2017-04-12T06:23:23.093Z
I wrote that code in Core. Yes, you can scan for all blocks and afterwards figure out the longest chain, and filter out garbage. But that's not what the question was about. On disk, the blocks are out of order.
Pieter Wuille
CC BY-SA 3.0
2017-04-10T19:29:10.197Z
2017-04-10T19:29:10.197Z
Jonas Schnelli
<p>I am trying to understand the structure of the underlying block chain stored in the core implementation (or rather just the BLK files used by a fullnode). My question is ; does the block chain store the complete tree structure , i.e all the forks which were encountered? Or does it purge the entries once a fork is resolved.</p>

<p>If i were to read the blk files sequentially , can i assume that every single block read is correctly ordered and no forks are present?</p>

<p>Thanks!</p>

<bitcoind><bitcoin-core><bitcoin-core-development>
Bitcoind block chain structure
Bobo
# Bitcoind block chain structure

(Asked by: username_0 on 2017-04-10)

I am trying to understand the structure of the underlying block chain stored in the core implementation (or rather just the BLK files used by a fullnode). My question is ; does the block chain store the complete tree structure , i.e all the forks which were encountered? Or does it purge the entries once a fork is resolved.

If i were to read the blk files sequentially , can i assume that every single block read is correctly ordered and no forks are present?

Thanks!

**Tags:** bitcoind, bitcoin-core, bitcoin-core-development


---

## 1 answers

### Answer by username_1 on 2017-04-10. Score: 3 | Accepted answer

the BLK files are not an API. You shouldn't directly read those files.
What you should do is requesting the headers/block via the JSON RPC interface (or the REST interface).
You can get the genesis block hash via:
bitcoin-cli getblockhash 0

Then you can get a block (without transactions):
bitcoin-cli getblock 

Then get the next block by looking at the nextblockhash item in the block JSON response, etc.
Also, consider using the REST interface. There you can get binary responses which are much faster (no JSON encoding/decoding overhead).

> **Comments:**
> **username_2**: To answer the question more directly: if you read the blk files directly, you would find the chain's blocks out of order, potentially with gaps in between, including forked off blocks, and the format may change in future versions.  
> **username_0**: @PieterWuille many thanks for the clarification.  
> **username_3**: @PieterWuille you'r wrong. While reading blk files with some math you can find order of blockchain exclude of any gaps or forks. Perhaps.  
> **username_2**: I wrote that code in Core. Yes, you can scan for all blocks and afterwards figure out the longest chain, and filter out garbage. But that's not what the question was about. On disk, the blocks are out of order.  

---

