<p>Since Bitcoin Core 28.0, block files are XORed with a randomly generated XOR key. This only applies to fresh data directories, which is probably why you're only running into this on testnet. If you want to read the data yourself, you will need to apply the XOR operation again using the key stored in <code>xor.dat</code>.</p>
<p>See the discussion in <a href="https://github.com/bitcoin/bitcoin/pull/28052" rel="nofollow noreferrer">PR #28052</a> for more details.</p>

CC BY-SA 4.0
2024-11-07T14:29:56.733Z
2024-11-07T14:29:56.733Z
Vojtěch Strnad
<p>For the Bitcoin mainnet, I can easily fetch one block by following steps:</p>
<ol>
<li><p>Open the LevelDB database at <code>&lt;bitcoind-dir&gt;/data/blocks/index</code></p>
</li>
<li><p>Get by key: <code>629986b32020caeb48a421956936dd88dc8d7825441bbc96fec10e98b800000000</code>(hex)</p>
<p>Just as an example. This is block #12345 with block hash <code>00000000b8980ec1fe96bc1b4425788ddc88dd36699521a448ebca2020b38699</code>. Transform it into the internal representation in bitcoin-core and prepend ASCII 'b' to it.</p>
</li>
<li><p>Follow <a href="https://bitcoin.stackexchange.com/a/67569/159523">this</a> answer and parse the value.</p>
</li>
</ol>
<p>I'm able to get:</p>
<pre><code>8eed3c -- client_version (259900)
df39 -- block_height (12345)
1d -- block_status (29)
01 -- tx_number (1)
00 -- blk_file (0)
80afc145 -- blk_start (2892101)
9fd565 -- rev_start (not care about this)

01000000 -- block_version
df9c748f06fcb1e7a4152e76b974e8a5c51c235afb6044388260877600000000 -- prev_blockhash
5731362967a95ffbce2027abf78111e87e804aa8ad6b5b483bb96e827ac91dfd -- merkle_root
5cdff449 -- time
ffff001d -- bits
1f35c72e -- nonce
</code></pre>
<p>Open <code>&lt;bitcoind-dir&gt;/blocks/blocks/blk00000.dat</code> and go to offset <code>2892101</code>, there's <code>01000000 df9c748f06fcb1...</code>, which is the correct block header and is the same as one decoded above.</p>
<p>File dump:</p>
<pre><code>002C2140   D9 D8 00 00  00 01 00 00  00 DF 9C 74  8F 06 FC B1  ...........t....
002C2150   E7 A4 15 2E  76 B9 74 E8  A5 C5 1C 23  5A FB 60 44  ....v.t....#Z.`D
....
</code></pre>
<p>But it's just broken for testnet3 and testnet4. For example, use the exactly same approach above, also with block #12345, I got:</p>
<pre><code>8eed3c -- client_version
df39 -- block_height (12345)
801d -- block_status
01 -- tx_number
00 -- blk_file (0)
9cf0ff70 -- blk_start (62668912)
83f19804 -- rev_start

00600720 -- version
39905ba030a61e45209006737dc9dc4cfbe2f077919b01cbc7a20a0000000000 -- prev_blockhash
8cf89e0e3a833718dc0b05da4ad7b5faeff63507ed5d02b66a0b2ce7bb82f12d -- merkle_root
734c3e66 -- time
f0ff0f1b -- bits
924847df -- nonce
</code></pre>
<p>Consult file <code>blocks/testnet4/blocks/blk00000.dat</code> at position 9cf0ff70, it says</p>
<pre><code>03BC4070   73 73 15 A8  83 AE 8E 19  A5 F9 1D E0  A6 0D FC 9E  ss..............
03BC4080   BE 3C 81 74  E4 F3 57 14  B7 31 3A D0  C4 4C EF E2  .&lt;.t..W..1:..L..
03BC4090   9D 14 53 14  0A A1 8E 19  65 4C 3D 5A  43 8D 38 AE  ..S.....eL=ZC.8.
03BC40A0   50 A5 8A B8  83 B4 E8 17  02 B6 C3 32  E9 AB 20 C8  P..........2.. .
03BC40B0   8F 0C 90 9F  F8 19 FC 50  5C 4D 38 E8  CE 90 E8 E9  .......P\M8.....
03BC40C0   9A 43 26 4D  DA 73 83 18  64 4C 3D 85  82 AF 8F 19  .C&amp;M.s..dL=.....
03BC40D0   65 4C 3D 85  82 AE 8E 19  65 4C 3D 85  82 AE 8E 19  eL=.....eL=.....
03BC40E0   65 4C 3D 85  82 AE 8E 19  65 4C 3D 85  82 AE 8E E6  eL=.....eL=.....
</code></pre>
<p>Obviously it's not a block data.</p>
<p>I tried searching the testnet4 genesis block signature <code>03/May/2024 0000000...</code> in the <code>testnet4/blocks</code> folder, with no result either.</p>
<pre class="lang-none prettyprint-override"><code>❯ rg --binary -uuu '03/May/2024 0000'
</code></pre>
<p>Is there some obfuscation or something applied for the testnet blk* file data? Or I missed something? Thanks!</p>
<p>My Bitcoin Core version: v28.99.0-0ca1d1bf69ca</p>

<bitcoind><testnet><leveldb>
Unable to parse blocks from blk*.dat for testnet (3 and 4)
bczhc
# Unable to parse blocks from blk*.dat for testnet (3 and 4)

(Asked by: username_0 on 2024-11-07)

For the Bitcoin mainnet, I can easily fetch one block by following steps:

1. Open the LevelDB database at `<bitcoind-dir>/data/blocks/index`
2. Get by key: `629986b32020caeb48a421956936dd88dc8d7825441bbc96fec10e98b800000000`(hex)

   Just as an example. This is block #12345 with block hash `00000000b8980ec1fe96bc1b4425788ddc88dd36699521a448ebca2020b38699`. Transform it into the internal representation in bitcoin-core and prepend ASCII 'b' to it.
3. Follow [this](https://bitcoin.stackexchange.com/a/67569/159523) answer and parse the value.

I'm able to get:

```
8eed3c -- client_version (259900)
df39 -- block_height (12345)
1d -- block_status (29)
01 -- tx_number (1)
00 -- blk_file (0)
80afc145 -- blk_start (2892101)
9fd565 -- rev_start (not care about this)

01000000 -- block_version
df9c748f06fcb1e7a4152e76b974e8a5c51c235afb6044388260877600000000 -- prev_blockhash
5731362967a95ffbce2027abf78111e87e804aa8ad6b5b483bb96e827ac91dfd -- merkle_root
5cdff449 -- time
ffff001d -- bits
1f35c72e -- nonce

```

Open `<bitcoind-dir>/blocks/blocks/blk00000.dat` and go to offset `2892101`, there's `01000000 df9c748f06fcb1...`, which is the correct block header and is the same as one decoded above.

File dump:

```
002C2140   D9 D8 00 00  00 01 00 00  00 DF 9C 74  8F 06 FC B1  ...........t....
002C2150   E7 A4 15 2E  76 B9 74 E8  A5 C5 1C 23  5A FB 60 44  ....v.t....#Z.`D
....

```

But it's just broken for testnet3 and testnet4. For example, use the exactly same approach above, also with block #12345, I got:

```
8eed3c -- client_version
df39 -- block_height (12345)
801d -- block_status
01 -- tx_number
00 -- blk_file (0)
9cf0ff70 -- blk_start (62668912)
83f19804 -- rev_start

00600720 -- version
39905ba030a61e45209006737dc9dc4cfbe2f077919b01cbc7a20a0000000000 -- prev_blockhash
8cf89e0e3a833718dc0b05da4ad7b5faeff63507ed5d02b66a0b2ce7bb82f12d -- merkle_root
734c3e66 -- time
f0ff0f1b -- bits
924847df -- nonce

```

Consult file `blocks/testnet4/blocks/blk00000.dat` at position 9cf0ff70, it says

```
03BC4070   73 73 15 A8  83 AE 8E 19  A5 F9 1D E0  A6 0D FC 9E  ss..............
03BC4080   BE 3C 81 74  E4 F3 57 14  B7 31 3A D0  C4 4C EF E2  .<.t..W..1:..L..
03BC4090   9D 14 53 14  0A A1 8E 19  65 4C 3D 5A  43 8D 38 AE  ..S.....eL=ZC.8.
03BC40A0   50 A5 8A B8  83 B4 E8 17  02 B6 C3 32  E9 AB 20 C8  P..........2.. .
03BC40B0   8F 0C 90 9F  F8 19 FC 50  5C 4D 38 E8  CE 90 E8 E9  .......P\M8.....
03BC40C0   9A 43 26 4D  DA 73 83 18  64 4C 3D 85  82 AF 8F 19  .C&M.s..dL=.....
03BC40D0   65 4C 3D 85  82 AE 8E 19  65 4C 3D 85  82 AE 8E 19  eL=.....eL=.....
03BC40E0   65 4C 3D 85  82 AE 8E 19  65 4C 3D 85  82 AE 8E E6  eL=.....eL=.....

```

Obviously it's not a block data.

I tried searching the testnet4 genesis block signature `03/May/2024 0000000...` in the `testnet4/blocks` folder, with no result either.

```none
❯ rg --binary -uuu '03/May/2024 0000'

```

Is there some obfuscation or something applied for the testnet blk\* file data? Or I missed something? Thanks!

My Bitcoin Core version: v28.99.0-0ca1d1bf69ca

**Tags:** bitcoind, testnet, leveldb


---

## 1 answers

### Answer by username_1 on 2024-11-07. Score: 2 | Accepted answer

Since Bitcoin Core 28.0, block files are XORed with a randomly generated XOR key. This only applies to fresh data directories, which is probably why you're only running into this on testnet. If you want to read the data yourself, you will need to apply the XOR operation again using the key stored in `xor.dat`.

See the discussion in [PR #28052](https://github.com/bitcoin/bitcoin/pull/28052) for more details.


---

