Quote from: lucif on June 30, 2013, 10:02:12 AM

Quote from: Eri on June 30, 2013, 06:02:52 AM

2. Your 'ultimate storage' grows with more users, but so does the amount of spam produced. It would solve nothing. I like many others would still prefer to store the entire chain.

You answered this by own in 4. 1000s HDD are anyway better than one.

Quote from: Eri on June 30, 2013, 06:02:52 AM

4. Pruning, would remove all spent transactions that are 2(?) transactions back since they wouldnt be needed, dramatically reducing the size of the blockchain. At which point your solution is entirely moot since anyone could store whats left of it without issue.

This is good solution, but this breaks chain integrity. And who said spent outputs will not be needed by anyone?

Quote from: Eri on June 30, 2013, 06:02:52 AM

5. Storage devices are getting cheaper and larger every day and so is memory. im sure if it were needed at some point in the future someone could build a custom board with a crazy amount of memory on it to store the UTXO set. With the speed memory runs at im sure someone could make a slower, cheaper, larger ramdisks for this purpose.

Everybody blindly repeat this following satoshi. But satoshi said this regarding storage space capacity. HDD also have one more very important property which nobody takes into account: IO capacity. Soon, bitcoind will run out of IO capacity of spinning HDD, and later, solid state drives.

I don't propose to discard whole local chain. I propose don't dig it without need on local side.

I know at least one use case where my solution will bring performance benefits.

I know that DHT storage just moves load from disk IO to network IO. But just realize, we have a new block with thousands transactions.

With regular client, EACH NETWORK NODE will have to dig into own local chain and do a key lookup there for each transaction. Thousands or millions of nodes will have to do same hard IO work on each new block.

With regular client + DHT enabled - only few will do this. They will cache lookup results into local DHT cache and answer to others from there. So in this case, only few nodes will perform local chain lookup. Lookup results will distribute along network in mostly cached answers.

As bonus, there will be google-large peta-scale storage for all chain with its glory.a

This really isnt the place for this.. but...

Pruning does not break chain integrity. From my somewhat limited knowledge about it, pruning just removes the body of a transaction from a block and leaves the header and its hash alone. As a result blocks can still be verified. Each client would do the pruning themselves, at which point if no copies of a old transaction are floating around then its safe to assume that everyones client removed it, it was no longer needed. Regardless im more then sure there will be a few complete unaltered blockchains around if anyone needs to look up such data. Perhaps thats something your model would work for.

Regarding IO capacity of HDDs, i cant say because i dont know. But it doesnt seem to be a problem yet. I also think there are more pressing issues.

While torrent like storage of data does have its benefits i dont think its solving anything that cant already be solved. To be honest, what you want to use it for sounds nice, but im not sure if its workable or even needed. The thread you pointed to doesnt contain any of this information your talking about, and im not going to go look.

Maybe you should write up a paper about it and see if you can get the devs to look at it and tell you if your going in the right direction.