<p>To add on to eponymous's answer, to disable this, comment out this section of code:</p>

<p><a href="https://github.com/bitcoin/bitcoin/blob/50fae68d416b4b8ec4ca192923dfd5ae9ea42773/src/dbwrapper.cpp#L129-L139" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/50fae68d416b4b8ec4ca192923dfd5ae9ea42773/src/dbwrapper.cpp#L129-L139</a></p>

<pre><code>if (!key_exists &amp;&amp; obfuscate &amp;&amp; IsEmpty()) {
    // Initialize non-degenerate obfuscation if it won't upset
    // existing, non-obfuscated data.
    std::vector&lt;unsigned char&gt; new_key = CreateObfuscateKey();

    // Write `new_key` so we don't obfuscate the key with itself
    Write(OBFUSCATE_KEY_KEY, new_key);
    obfuscate_key = new_key;

    LogPrintf("Wrote new obfuscate key for %s: %s\n", path.string(), HexStr(obfuscate_key));
}
</code></pre>

<p>Then recompile, then delete your existing chainstate. (This change only causes it to stop generating an obfuscation key, it does not un-obfuscate the data.)</p>

CC BY-SA 3.0
2017-11-15T02:28:39.287Z
2017-11-15T02:28:39.287Z
Nick ODell
<p>There’s no way of easily disabling obfuscation, but you could build a version that sets the keys to zero, resulting in no change when the XOR is used. Generally it has no impact on anything, so it’s left enabled even on non-windows systems where it’s generally not useful. </p>

CC BY-SA 3.0
2017-11-15T03:26:56.223Z
That's what I was guessing. I'm trying to optimize my python's chainstate parser. It not a big of a deal when parsing a single output, but if you have to parse the whole chainstate it makes a difference in terms of running time. Seeing @NickODell answer seems to me that a config parameter that deals with this could have been easily set though.
sr_gi
CC BY-SA 3.0
2017-11-15T03:59:02.290Z
There’s probably going to be UTXO address indexes in the core client as an option at some point which might be of use to you as well.
Claris
CC BY-SA 3.0
2017-11-15T00:24:35.093Z
2017-11-15T00:24:35.093Z
Claris
<p>I'm wondering if there is a flag that allows running <code>bitcoind</code> without using an <code>obfuscation key</code> for the <code>chainstate</code>. I haven't been able to find it.</p>

<bitcoind><leveldb>
Non-obfuscated chainstate data
sr_gi
# Non-obfuscated chainstate data

(Asked by: username_0 on 2017-11-14)

I'm wondering if there is a flag that allows running `bitcoind` without using an `obfuscation key` for the `chainstate`. I haven't been able to find it.

**Tags:** bitcoind, leveldb


---

## 2 answers

### Answer by username_1 on 2017-11-15. Score: 2 | Accepted answer

To add on to eponymous's answer, to disable this, comment out this section of code:

<https://github.com/bitcoin/bitcoin/blob/50fae68d416b4b8ec4ca192923dfd5ae9ea42773/src/dbwrapper.cpp#L129-L139>

```
if (!key_exists && obfuscate && IsEmpty()) {
    // Initialize non-degenerate obfuscation if it won't upset
    // existing, non-obfuscated data.
    std::vector<unsigned char> new_key = CreateObfuscateKey();

    // Write `new_key` so we don't obfuscate the key with itself
    Write(OBFUSCATE_KEY_KEY, new_key);
    obfuscate_key = new_key;

    LogPrintf("Wrote new obfuscate key for %s: %s\n", path.string(), HexStr(obfuscate_key));
}

```

Then recompile, then delete your existing chainstate. (This change only causes it to stop generating an obfuscation key, it does not un-obfuscate the data.)


---

### Answer by username_2 on 2017-11-15. Score: 3

There’s no way of easily disabling obfuscation, but you could build a version that sets the keys to zero, resulting in no change when the XOR is used. Generally it has no impact on anything, so it’s left enabled even on non-windows systems where it’s generally not useful.

> **Comments:**
> **username_0**: That's what I was guessing. I'm trying to optimize my python's chainstate parser. It not a big of a deal when parsing a single output, but if you have to parse the whole chainstate it makes a difference in terms of running time. Seeing @username_1 answer seems to me that a config parameter that deals with this could have been easily set though.  
> **username_2**: There’s probably going to be UTXO address indexes in the core client as an option at some point which might be of use to you as well.  

---

