2

Spending freshly generated coins is prohibited by the protocol until there are at least 100 blocks on top of the block from which they came. This is because the chances of a 100-block reorg is virtually zero.

The chances of a reorg of 1,000 or 10,000 blocks is even lower. If the chainstate data is normalized, then its hash can be included in each block so that messing with it is as impossible as messing with the blockchain itself. Would we then be able to prune off all but the last 10,000 blocks?

I know the transaction history is valuable, but under the assumption that we will never see a reorg larger than a particular number of blocks, I suspect it isn't necessary for mining once the chainstate is protected as well as the entire blockchain has been.

It seems to me that normalizing the chainstate so that it can be hashed and protected (like block headers are) would allow validation and mining without having to save the entire blockchain. That way, only those who really want the history would need to save it.

Am I missing something?

|improve this question
1

You don't actually need to commit to the chainstate in blocks - just compute it the normal way, but throw away the block data after validation.

In fact, that's exactly what the pruned mode in Bitcoin Core 0.11 does, and it supports mining.

Storing the hash of the chainstate into blocks does have other advantages, like being able to skip processing historical blocks entirely if you're willing to trust a miner majority to commit to a correct one. However, it comes at a very significant cost for validation, as this hash would have to be recomputed and verified with the entry inside every block.

|improve this answer
  • It seems like we could lower the cost of validating it by taking a few measures. For example, 1) the hash of the utxo set could be computed only every 100 blocks, and 2) it could refer to the utxo set from 10 blocks ago, meaning it could be computed in advance. – Nick ODell Jul 26 '15 at 0:22
  • If block N were to contain the hash of block N-1's chainstate, the cost is exactly hashing the chainstate once per block. Does staggering it like that remove the cost problem you mentioned? If not, what did you mean? – Dave Scotese Jul 26 '15 at 22:44
  • Blocks are sometimes found a few seconds apart, so just using the previous block may still affect relay performance significantly for such blocks. You could go back further in time, but that also has costs, as you somehow need to be able to relay old chainstates to new nodes, so they have to be accessible. There has been some work around merkleizing the chainstate itself, so that its root hash can be recomputed on the fly for each update, but this still adds very significant validation costs. – Pieter Wuille Jul 27 '15 at 1:10
  • New nodes need "old" chainstate, but current chainstate will be old as soon as the next block gets solved. Significant chunks of the utxo database will not change. While a new node collects chunks at random, some pieces will be invalidated as new blocks get solved, so it will have to get them again. Eventually, it has complete current chainstate and then it can wait for the next block to validate the whole thing. That leaves only validating the chunks. Torrent files do this already, right? – Dave Scotese Jul 27 '15 at 2:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.