Reference threads that I can not post to yet.
Proposal for reduction of storage space on all clientshttps://bitcointalk.org/index.php?topic=12376.0
With "Balance sheets" most of the block chain can be forgotten.https://bitcointalk.org/index.php?topic=505.0
Transaction pruning detailshttps://bitcointalk.org/index.php?topic=10663.0
A proposal for a scalable blockchain.https://bitcointalk.org/index.php?topic=52859.0
My Idea on the bitcoin block chain summary.
The block chain is big. 1 gigabyte big. In about 8 years it can become about 4 gigs.
The block chain is basically a ledger of all transactions since the beginning. If we follow the analogy of accounting metaphors, we should also have bitcoin summaries, or ending balances, or closing entries for the previous periods or blocks. This can be daily, weekly, or monthly, for example.
This summary or closing balance block will only contain bitcoin addresses with positive values as of that block, or as of that point in time, thus compressing the block chain from the 1 gigabyte it is today, to maybe 30 megabytes, or some number significantly smaller. The number of bitcoin addresses with something in them (meaning, at least 1 Satoshi) is about 600,000. It takes about 50 bytes (or less) to store an address and its balance. That's how I came up with 30 megabytes. Half a million addresses with balances might be 250 megabytes. This is not using compression or optimization of how the data is stored. I mean, an address right now is 160 bits or 20 bytes and a balance of 500000.00000001 bitcoins can be stored as a 64 bit number or 8 bytes. You can now store 10 million addresses with balances in 133 megabytes. The 600,000 addresses now can be stored in 16 megabytes.
Addresses that have zero balances will simply not be included. And I think there are no such thing as negative balances.
As it is today, a modified bitcoin client can do this block chain summary for itself, and use that as a starting point. Sort of a selfish client. The difference is that it has the balances of the entire block chain, not just of its own public keys or addresses. Adding a key to the wallet file and doing a -rescan will yield identical results for the original client and this modified client.
The client will lose the ability to look at the previous transactions prior to the summary, or perhaps two or three summaries ago. But for most people this might be acceptable.
With a smaller combined block chain and summary, this will bring bitcoin to be more accessible to small devices, cell phones, ipods or ipads, androids, netbooks, etc.
People who like to consolidate their bitcoins into a few addresses will do the world a favor.
The client will of course compute if this block summary is valid, then hash it or whatever it is that miners do.
Desktop computers will be encouraged to retain the entire block chain. Small laptops or small devices will use the block chain summary.
We can extend this further, by having both the monthly block chain summaries and annual summaries, where the annual summary takes over the block chain. Or some other longer length of time, most probably determined by how large the block chain will be. This way, we don't get uber giant terabyte block chains in 20 years and bitcoin will survive into the distant future.
What I am proposing will also effectively put a hard limit on transaction history to say, 5 years worth. Meaning, we will never see transactions going back 6 years ago. But only for those clients that discard the old data.
Attempts to produce a fake summary will of course be rejected by the network, but at least the network is spared from giant block chains, and even with a limit of 1 year, the current block chain is still very secure.
If we like to assume that 6 blocks or 1 hour confirms our transactions, then 4000 blocks or 1 month really confirms our transactions. The difficulty now is 1626553.4813289. The same difficulty can be applied to the miner computing the summary. 6 blocks later, the summary is confirmed and all the previous blocks can be discarded or deleted.
Incidentally, the difficulty gets adjusted every 2016 blocks. That's about 2 weeks worth.
2000 blocks takes up a lot smaller space than 173386 blocks.
So, in theory, we need never keep transaction histories longer than 1 year, or 6 months, or even 1 month. Thus keeping the total block chain and summaries to a reasonable size.
To visualize this, the current system is something like this:
Block 1, Block 2, Block 3, Block 4. . . . . Block 173386.
or to make it even easier to visualize, I will abbreviate it to something like this:
B1, B2, B3, B4, ... B173386. Where B is a Block.
The new system or protocol or implementation would be something like this:
B1, B2, B3, S1, B4, B5, B6, S2, B7 ... S99, B173384, B173385, B173386. Where S is the Summary block.
for something that computes the balances every 3 blocks. The client can then keep the latest 144 blocks with the 48 summaries, and discard everything else, essentially keeping track of the current state of the network as of 1 day.
Clients that are new to the network will not need to download the entire block chain, but the latest summary and blocks. These blocks and summaries will be considered confirmed (and safe and secure) if they go back at least 6 blocks long, isn't it?
Currently, if someone wanted to attack the bitcoin network, he'd need 51 percent of the hashing power, and he'd need it for at least more than 6 blocks worth, and keeping at the attack for a few days. That or someone simply finds a way to compute private keys faster than brute force and steals all our bitcoins.
There are at least two side effects of implementing this block chain summary.
1. clients will be unable to keep track of very old transactions unless the client saves this information.
2. since summaries no longer contain transactions, better anonymity is preserved for older transactions that are no longer being retained in the current block chain.
I say better, because there will be people or entities out there who will still keep the entire block chain, for whatever purpose it will serve them, or simply because they have terabytes of space for it.
But most people will "forget" about old transactions. And depending on consensus, I think that is fine, and some people will probably even like it.
Take note that this suggestion or idea is separate from the Merkle Tree for selfish clients. So you have two methods to shrink the block chain, but mine still retains the records of all address balances. You can even combine the two to have really small selfish clients.
Summary: secure small block chains with the side effect of slightly better anonymity.
If you've read this far and like this idea or think it has merit, you may tip or donate to 1CAnhNTL7n78U9rRHyC1LqbxVbFBWFfSTU
any amount will do, no matter how small.
If this can't or won't work now, then I propose this for the next version of bitcoin. But I'm thinking there is a way to do this, especially when you have everyone upgrade their bitcoin client to version 0.5.4. (or whatever version includes it.)