I am not sure about this specific implementation, but normally UTXO database is just a database: keys => records
Keys are usually txid+vout, while records contain at least value+pk_script, though usually also things like block_height, etc.
In case of Bitcon Core, it should be the same, so I'd say: use any LevelDB engine to load the DB and browse through it - that should be exactly what you need.
The format of the records should not be hard to figure out.
Keys are usually txid+vout, while records contain at least value+pk_script, though usually also things like block_height, etc.
In case of Bitcon Core, it should be the same, so I'd say: use any LevelDB engine to load the DB and browse through it - that should be exactly what you need.
The format of the records should not be hard to figure out.
My post above was posted while you were typing but that makes a lot of sense. It is very likely the UXTO reported is just the key (hash & index) that would coincide with the reported size. So the question becomes which file is the UXTO index stored in?
On edit:
Quote
chainstate subdirectory
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent.
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent.
Ok so here is where to start. Lets see if I can decode it. Thanks. Would be nice if the format structure was reported somewhere other than just in the code.
