Topic: [REQUEST FOR COMMENT] Sealing transaction histories versus sealing state (Read 623 times)

Currently, Bitcoin is sealing transaction histories. If a new installation wants to know if there are coins stored at address X which can be used, it has to download the entire block chain upto the current block and check the history of Bitcoin address X. So, there is a first transaction where this address is used. Then, depending on the user, there are some transactions, and finally we are up to date, knowing the current block. Only then can we decide about the value available at X.

This approach is completely safe, but it has a significant disadvantage. Throughout the game the storage efficiency is getting worse and worse.

There is a different approach, which is sealing state. In this approach every block seals the state of all addresses. If this approach is used, knowledge of the latest block (and proof of its "correctness") would be sufficient to know the amount of money encoded at address X.

Of course, this approach is not really feasible for a number of reasons.

First, a single block would have to contain the information of ALL 500.000 and more addresses, which makes the block quite large and would delay handling and hashing the block.

Second, the proof of "correctness" cannot be properly given, since Bitcoin uses the concept that after a certain block-length after a transaction chances are small that a different, competing transaction might "make it into the longest chain". This concept does not sits well with the concept of having a single latest correct block.

However, we could combine these two aspects.

Do we, in the current moment, still have to keep the information on block, say, 1000? Yes, we have to, since Satoshi mined some coins in block 259 and has not yet used them. So we need this information. But: we could look at all the blocks 1 to 1000. Some coins will have changed owners several times and we do not really need to know the entire history of these coins in their past history. We could replace blocks 1 to 1000 by a new data structure, we might call them a state snapshot, and encode a list of all coins at their current addresses (not keeping their past). As a result, the block chain would become shorter.

Now, we could improve this. Assume the current blocknumber is B. It would suffice, if we kept the last, say, 10.000 blocks (to get the difficulty adaption working smoothly), but all the information from block 1 to block B - 10.000 could be "collected" into a snapsho-like state record.

We would thus combine advantages from two concepts: We have compact storage of that information which we must store and we would keep only so much of the development to ensure that we have the right concept of "longest" chain and to keep difficulty adaption running smoothly.

Any comments on this?