1

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)?

3
  • 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. Commented Jan 8, 2020 at 17:25
  • 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
    Commented Jan 8, 2020 at 17:43
  • Me not closing the database correctly sounds like the most likely cause. Thank you both.
    – inersha
    Commented Jan 9, 2020 at 14:12

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.