Quote from: etotheipi on September 20, 2013, 06:02:16 AM

Quote from: halfawake on September 20, 2013, 05:41:46 AM

It's probably a seriously non-trivial thing to do, code wise. Mostly the reason I was curious is that this kind of update would effectively double the hard drive demands of bitcoin since you'd have the 11.9 GB of the blockchain that bitcoin-qt manages, and the (presumably also) 11.9 GB of space that Armory would require from what you mentioned earlier. 24 GB is kind of a lot of space just to be able to keep Armory running happily, even in the era of hard drives with a lot of space.

2.2x the blockchain size is a lot of space especially when the blockchain is 50 GB. But if you're going to go put 128 GB of RAM in your server, it'll be a lot cheaper to just buy a single 2 TB HDD for $80 which will sustain you for another year or two even at absolute maximum blockchain growth.

Also, the alternative is that you only hold 1x the blockchain. Obviously, it's less than 2.2x, but it's the same order of magnitude, which means if 2.2x is enough for you to be concerned, 1x is still a lot.

A workaround that doesn't involve any work for me: make yourself a RAM disk and put all the data on there. It should be fast as hell. But of course, everything goes poof on a power-cycle.

As I said, I'll think about how it might be done. Especially if DB performance becomes a real issue. But I might wait until that happens before I put too much effort into the RAM solution.

At the rate the bitcoin blockchain grows in size, 2.2x the growth worries me a lot more than 1x growth. But you're right about cost, it's a lot cheaper to buy a really big hard drive than it is to buy a ton of RAM. That said, I do think the hard drive solution is the right way to go since hard drive space is generally much more plentiful than RAM.