Even solid state drive cant handle such database where this curve points to. I dont talk about CPU and RAM speed. So we have the situation where regular participant cant be a full member of decentralized network. So we run to unpredictable point in future with such database.
About unspent transactions. Sure the client has not to verify them, just keep. But in this way he will not know whether transaction valid or not.
In current Bitcoin client there is DoS protection, which banning remote node if it relayed invalid TX one or several times (i tried to craft invalid TX and relay it and my node was banned).
So if client will remove the TX verification, it will be vulnerable to DoS. The fork trap again: kill your HDD or be vulnerable to DoS.
Of course, Gavin's magick alert key for all doors will salvate our asses when we all be in long position. But not too much power for one person?
Oh dear, you thought Bitcoin is decentralized? I am sorry for disappointment
I expected the down-move, too. But this looks like FUD.
With the current implementation of "Ultraprune" the pruned copy of the blockchain is about 100MiB (vs. 3-4 GiB unpruned). The size of this pruned copy does not grow as fast as the blockchain itself, because addresses, that currently do not hold any coins are removed. In an extreme case, the size of the pruned copy even can go down (this already happened, as you can see here:
https://bitcointalksearch.org/topic/m.1257750). However, the block history has to be kept somewhere to bootstrap new nodes from zero. You can imagine this as the pruned copy being the current state of the system and to recreate this state the block history has to be replayed. But this also means, that the block history only needs to be stored on some large drive and there is no need for highly performant IO throughput (well, except that the faster the storage, the faster a new node can be bootstrapped from zero.).
