<ol>
<li>I can only think of one way to use a XOR key for obfuscation, which is splitting the data into chunks that have the same length as the key and XOR'ing each chunk with the key. I'd assume that's how it works here as well.</li>
<li>Antivirus software can flag the blocks directory when someone inserts data matching a known virus into a block. XOR'ing randomizes the data, so it will no longer match.</li>
</ol>

CC BY-SA 4.0
2024-12-17T00:17:35.633Z
Hi Vojtěch, thank you for very much your efforts. I apologize for the my unclear questions. I was specifically asking about the new "-blocksxor" option which you also haven't worked with either it sounds like. Thank you again.
jimhash
CC BY-SA 4.0
2024-12-17T00:24:13.240Z
Hi jimhash, I was indeed answering with regards to the -blocksxor option. What exactly in my answer seems wrong?
Vojtěch Strnad
CC BY-SA 4.0
2024-12-17T00:05:02.053Z
2024-12-17T00:05:02.053Z
Vojtěch Strnad
<p>I would please like help understanding the new <strong>-blocksxor</strong> enhancement, mainly from an admin perspective.  I did see the following useful info.<br/>
Output from <em>bitcoind --help</em>:</p>
<pre><code>   -blocksxor
        Whether an XOR-key applies to blocksdir *.dat files. The created XOR-key
        will be zeros for an existing blocksdir or when `-blocksxor=0` is
        set, and random for a freshly initialized blocksdir. (default: 1)
</code></pre>
<p>From v28.0 release notes:</p>
<blockquote>
<p>Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the -blocksxor help for more details. (#28052)</p>
</blockquote>
<p>Comments for this change are at: <a href="https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-2273008031" rel="nofollow noreferrer">Pull Request #28052</a></p>
<p>Reading further, it sounds like this enhancement compensates for some AV softwares wrongly flagging blockchain storage files. It sounds like this was originally reported against chainstate files (<a href="https://github.com/bitcoin/bitcoin/issues/4069" rel="nofollow noreferrer">Issue #4069</a>), whereas this new &quot;-blocksxor&quot; remediation deals with erroneous AV flags to the blocks data files themselves.
For the new enhancement, it sounds like a rolling random XOR obfuscation  blocks directory which is then used to optionally obfuscate file contents.</p>
<p>My questions I'd please like help with are:</p>
<ol>
<li>I didn't see the &quot;rolling&quot; nature of these keys described?  When are the random XOR keys generated, and when do they &quot;roll?&quot; Are new keys created for each block?  Does the new -blocksxor key-file contain multiple obfuscation keys, it must?</li>
<li>Also, how does this help prevent AV softwares from continuing to wrongly flag these data files? Doesn't randomly XOR(ing) persisted data just &quot;kick the can down the road&quot;? Eventually the same problem may happen. Are there AV-integration tests which prove out this XOR(ing) solution?</li>
</ol>

<storage><leveldb><command-line-options><blocks.dat>
How does new -blocksxor switch that obfuscates LevelDB blocks.dat files work?
jimhash
# How does new -blocksxor switch that obfuscates LevelDB blocks.dat files work?

(Asked by: username_0 on 2024-12-16)

I would please like help understanding the new **-blocksxor** enhancement, mainly from an admin perspective. I did see the following useful info.  
Output from *bitcoind --help*:

```
   -blocksxor
        Whether an XOR-key applies to blocksdir *.dat files. The created XOR-key
        will be zeros for an existing blocksdir or when `-blocksxor=0` is
        set, and random for a freshly initialized blocksdir. (default: 1)

```

From v28.0 release notes:

> Block files are now XOR'd by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the -blocksxor help for more details. (#28052)

Comments for this change are at: [Pull Request #28052](https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-2273008031)

Reading further, it sounds like this enhancement compensates for some AV softwares wrongly flagging blockchain storage files. It sounds like this was originally reported against chainstate files ([Issue #4069](https://github.com/bitcoin/bitcoin/issues/4069)), whereas this new "-blocksxor" remediation deals with erroneous AV flags to the blocks data files themselves.
For the new enhancement, it sounds like a rolling random XOR obfuscation blocks directory which is then used to optionally obfuscate file contents.

My questions I'd please like help with are:

1. I didn't see the "rolling" nature of these keys described? When are the random XOR keys generated, and when do they "roll?" Are new keys created for each block? Does the new -blocksxor key-file contain multiple obfuscation keys, it must?
2. Also, how does this help prevent AV softwares from continuing to wrongly flag these data files? Doesn't randomly XOR(ing) persisted data just "kick the can down the road"? Eventually the same problem may happen. Are there AV-integration tests which prove out this XOR(ing) solution?

**Tags:** storage, leveldb, command-line-options, blocks.dat


---

## 1 answers

### Answer by username_1 on 2024-12-17. Score: 3

1. I can only think of one way to use a XOR key for obfuscation, which is splitting the data into chunks that have the same length as the key and XOR'ing each chunk with the key. I'd assume that's how it works here as well.
2. Antivirus software can flag the blocks directory when someone inserts data matching a known virus into a block. XOR'ing randomizes the data, so it will no longer match.

> **Comments:**
> **username_0**: Hi username_1, thank you for very much your efforts. I apologize for the my unclear questions. I was specifically asking about the new "-blocksxor" option which you also haven't worked with either it sounds like. Thank you again.  
> **username_1**: Hi username_0, I was indeed answering with regards to the -blocksxor option. What exactly in my answer seems wrong?  

---

