Quote from: gmaxwell on May 10, 2013, 04:48:24 AM

It doesn't need to be in _ram_ in needs to be in fast reliable storage online storage not nearline or offline, not on a tape jukebox in the basement or on on far away storage across a WAN, and the validation time depends on how fast it is. If you put it on storage with a 10ms random access time and your block has 2000 transactions with 10 inputs each, you're looking at 200 seconds just to fetch the inputs which is just going to utterly really bad network convergence and cause a ton of hashrate loss due to forks and make people need more confirmations for security. But in practice it's not quite that bad since _hopefully_ a lot of spent outputs were recently created.

The fact that usually it works because most of the outputs were recently created is incredibly dangerous. If the ratio of best case to worst case performance gets bad enough the attacker just has to come along with a block spending outputs that weren't recently created, or otherwise picked in a way where retrieval happens to be slow, to knock slower miners offline. Even worse is if they can come up with two blocks where each of those blocks trigger performance problems on one implementation but not the other they can split the network. They don't even have to mine those blocks themselves if the transactions in them are standard enough that they can get someone else to mine them.

In Bitcoin any performance problem can become a serious security problem. We only get away with it now because computers are so fast in comparison to the transaction volume and 10 minute target, but if we start needing to "optimize" things, including solutions like aggressively passing around transaction hashes rather than transactions themselves when a new block is propagated, we open ourselves up to serious security problems.