<p>I have written a tool that accesses the chainstate LevelDB database to get a list of UTXOs.</p>

<p><a href="https://github.com/in3rsha/bitcoin-utxo-dump/blob/master/utxodump.go" rel="nofollow noreferrer">https://github.com/in3rsha/bitcoin-utxo-dump/blob/master/utxodump.go</a></p>

<p>The tool would originally corrupt the database every time I accessed it, forcing me to run <code>bitcoind -reindex-chainstate</code> to fix it. I was able to get around this by adding a <em>no compression</em> option when accessing the database, which seemed to fix the problem.</p>

<p>However, using this tool will still <em>occasionally</em> corrupt the database, but not always, and I am not sure why.</p>

<p>I'm not looking for a review of the code, but I was wondering if there might be <strong>any common reasons why the chainstate database might become corrupted after another program has accessed it (whilst <code>bitcoind</code> <em>isn't</em> running)?</strong></p>

CC BY-SA 4.0
2020-01-08T17:25:19.727Z
The no-compression part I can explain: Bitcoin Core links in a modified variant of LevelDB without compression support (reducing dependencies, and it's not useful in our use case). If you open the DB with a tool that has compression enabled, Bitcoin Core won't be able to read it anymore.
Pieter Wuille
CC BY-SA 4.0
2020-01-08T17:43:29.650Z
I used to have the same problem when writing my utxo analysis tool in Python and fixed it by disabling compression. Never had an issue with it afterwards. It may sound dumb (I haven't checked the code), but have you made sure that you properly close the db every time? It could also be the case that the go library for leveldb has a bug that the Python does not, but that seems less likely.
sr_gi
CC BY-SA 4.0
2020-01-09T14:12:34.117Z
Me not closing the database correctly sounds like the most likely cause. Thank you both.
inersha
<leveldb>
What can cause the chainstate database to become corrupted?
inersha
# What can cause the chainstate database to become corrupted?

(Asked by: username_0 on 2020-01-08)

I have written a tool that accesses the chainstate LevelDB database to get a list of UTXOs.

<https://github.com/in3rsha/bitcoin-utxo-dump/blob/master/utxodump.go>

The tool would originally corrupt the database every time I accessed it, forcing me to run `bitcoind -reindex-chainstate` to fix it. I was able to get around this by adding a *no compression* option when accessing the database, which seemed to fix the problem.

However, using this tool will still *occasionally* corrupt the database, but not always, and I am not sure why.

I'm not looking for a review of the code, but I was wondering if there might be **any common reasons why the chainstate database might become corrupted after another program has accessed it (whilst `bitcoind` *isn't* running)?**

**Tags:** leveldb

> **Comments:**
> **username_1**: The no-compression part I can explain: Bitcoin Core links in a modified variant of LevelDB without compression support (reducing dependencies, and it's not useful in our use case). If you open the DB with a tool that has compression enabled, Bitcoin Core won't be able to read it anymore.  
> **username_2**: I used to have the same problem when writing my utxo analysis tool in Python and fixed it by disabling compression. Never had an issue with it afterwards. It may sound dumb (I haven't checked the code), but have you made sure that you properly close the db every time? It could also be the case that the go library for leveldb has a bug that the Python does not, but that seems less likely.  
> **username_0**: Me not closing the database correctly sounds like the most likely cause. Thank you both.  

---

## 0 answers

