Quote from: aliashraf on October 15, 2018, 09:01:24 AM

Although I merrited this topic and OP's commitment deserves more appreciation imo, a more general approach to this problem would be more appropriate.

Thanks for the merit.

Quote from: aliashraf on October 15, 2018, 09:01:24 AM

We have UTXO commitment proposals/implementations trending right now with their most important application being pruning and having full nodes with minimum resources and fast bootstrapping, etc. @spartacusrex started a topic in btctalk few days ago for instance and Paul Sztorc's first version of Drivechain released even later (couple of days ago) has already, implemented UTXO snapshotting.

Two most important differences:
1- UTXO snapshots include output scripts as well.
2- A Merkle Tree like and its root hash is generated and maintained for all UTXOs such that commitment to the state at a given height is feasible.

We got advanced algorithms/data structures like MMR and a complete history of interest in UTXOs.

Hhhmm.. interesting... I'm just "for fun" on this topic whilst doing completely unrelated stuff anyways. But i will look in to the links you mentioned. After all, i still have the full node running here anyways and want to play a bit even with the json-rpc and blockchain data format stuff anyways... So maybe i can dig a bit deeper in this chainstate export code to get the output-scripts too.

By the way. On a different run, i just took a list of all my addresses and got any data which is related to it from blockchain.info/com.
There are input and outputs included, but yeah .. calling the blockchain.com api for somewhat more than 1k adresses is not really a nice thing, so i'm already thinking about finding a better way. As i wrote already, getting the data from the bitcoind directly is probably the next thing i try.. Wink

Hacky