I acknowledge that eurekafag posted before me about a similar idea in
https://bitcointalksearch.org/topic/coins-checking-and-snapshotting-473 In the near future there's a decent chance that BitCoin will be run on mobile phones and used as a substitute for cash and cards. The main barrier to adoption will be that while the block chain is not ridiculously large, it's larger than it needs to be and as the rate of transactions ramps up, it's going to get larger faster.
Also, people are already annoyed with downloading the whole block chain and hacks have sprung up to get around this. This shows that it's already a problem and it's just going to get worse.
When we're calculating a balance we're not interested in the detail of transactions that happened a year ago although the block chain will happily tell us. We just crunch all this data to work it out. Let's say that a "balance sheet" is a sorted list of all public keys with positive balances followed by the amount of BitCoins they have received. When any block is published we should all be able to calculate identical balance sheets.
I propose that the hash of the balance sheet for block n be hashed into block n+1. When a new client starts up, unless they're interested in all the historical detail they ask for the current block and balance sheet. In my other suggestion, block numbers are tied to times so, if the client knows the time, they know which block number to ask for. They work out how paranoid p they are. They then ask for the previous p blocks. Using the current balance sheet and undoing transactions they recalculate the previous p balance sheets and they check that the hashes match the blocks. They are then up-to-date and can make transactions and participate in block generation if they wish.
If p is chosen to be at least twice as large as the number of blocks required to make a transaction to go confirmed then the scheme is at least as secure as any normal BitCoin transaction.
Similarly clients could keep a historical balance sheet and reclaim the disc space taken by all the preceeding blocks.
The size in bytes of the balance sheet has to be considerably smaller than that of the block chain. Could some kind person please calculate the current size for me?
In order to keep balance sheets small we could agree to omit from the balance sheet keys "containing" small amount of BitCoin but this sophistication introduces some complications.
The cost of my proposal is one more hash field per block. It would save a lot of network traffic from nodes getting historical blocks, a lot of storage space and a fair amount of users time.
I imagine that this scheme is superior to the Merkle hash tree, which could be dispensed with for some considerable saving in code complexity.
ByteCoin
