Quote from: bfever on May 25, 2012, 07:38:14 PM

Quote from: BrightAnarchist on May 25, 2012, 03:54:04 PM

Here is what I propose:

In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!

If you want to be able to verify transactions from "most recent balance block + transactions since this balance block", this "balance block" does not only need to record the balance of each bitcoin address, but in fact (the full details of) each "non-spent" transaction.
Some data around block height 181185: there are 659574 bitcoin addresses with a non-zero balance, and 1591739 "non-spent" transactions. This is at least 391 Mb of data you need to include in the balance block (at least 258 bytes per transaction), if my math is correct. Or at least a 1 hour download on a decent DSL line (not taking into account other nodes will want to get the data too).

So this can reduce storage space requirements (Mbytes instead of GBytes) and transaction lookup times, but network load will be higher (peers need also to relay the second chain).
At the current transaction volume (1100 transactions/h = 400 kb/h or 9.6Mb a day), it is definitely not a good solution: 1 balance block a day = 400 Mb a day (390Mb for that 1 block + 9.6Mb of new transactions), or an increase of 40 times the network load !

Why would the balance chain need to be shared on the network? It can easily be computed using the transaction chain, since each balance block specifically covers "up to" a certain transaction block. Only the nonce values would have to be shared on the network for the balance blocks.