If you want a more recent "quirk", how about Dec 6 2013?
http://techcrunch.com/2013/12/06/bitcoin-value-loses-its-mind-as-trading-lags-on-the-mt-gox-exchange/40 minute lags and the value bouncing up and down in a nice little pattern? Now, not even getting into that strange trading pattern, how is this going to scale when all of these online retailers are causing more transactions. That's still a problem that as far as I know hasn't been solved.
And how is this proof of manipulation? Doesn't the price need to go up or down for it to be manipulated? Jeebus, whenever there is a blip on the chart you are going to come in here crying manipulation?
I said I was willing to overlook the strange trading pattern. So, about that scalability problem.
you don't think the bitcoin network scales? You do understand that the Mt.Gox trading exchange ≠ the bitcoin network, right?
No, I don't. Do you know what the scalability concerns are from a technical perspective, in even the slightest?
So long as hardware advances outpace Bitcoin usage there will be no scalability concerns. How many tps do you need? Visa handles about 2000tps with a daily peak of 4000tps, busiest points of the holiday period are about ~8500tps.
PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.
Bitcoin: as of late 2012 the network is handling 0.5 transactions/second, and as of 2013 this has doubled to 1 transaction/second.
What is your concern, CPU, Network, or Storage?
CPU
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core Intel Core i7-2670QM 2.2Ghz processor. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.
Network
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.
Storage
At very high transaction rates each block can be over half a gigabyte in size.
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.
