I'm going to respond to the scalability sections of Dan Kaminskys slides. Maybe now Dan is whitelisted he can comment here.
http://www.slideshare.net/dakami/bitcoin-8776098I believe he presented this at Blackhat. As the author of the Scalability page, I was amused to read the "epic scalability quote" that came from me
OK, first up, I really
don't think building a distributed supernode would be very difficult. Perhaps my views on building distributed systems have been warped by spending ~5 years at Google, but Bitcoin nodes are one of the easier things I've seen to spread over a bunch of machines. In fairness, I didn't describe how to do that on the wiki page, and the page is itself a mishmash of things put together at different times. I'll try and clean it up a bit next week. In particular it mixes together stuff that's true today with stuff that could be trivially true in future, and it's not always clear which is which.
The core bottleneck in a Bitcoin node is verifying transactions as they come in from the broadcast network. Other things nodes do are either rare (handling re-orgs) or already distributed (mining) or potentially expensive in a few unusual situations, like if you're sending and receiving tons of spends from your wallet specifically (a big BitBank like InstaWallet). If you're a regular merchant, services provider or even hobbyist your node will spend 99% of its time checking transactions.
Here's one way you could distribute tx checking load: add a new command line switch, call it -trustednode=1.2.3.4:8333. Transactions received from a trusted node would not be checked, they'd be implicitly assumed valid and included in the current block. Obviously it's highly dangerous to mark any node other than another one you run yourself as trusted. Bring up some nodes on different machines and set them all to connect to each other as trusted nodes. These backends are not exposed directly to the p2p network. Instead a load balancer is put in front of them. The load balancer is not a trusted node. It may not even be based on Satoshis code. Its job is to take a transaction and then send it to one of the backends based on some sharding function, eg, dividing by the tx hash. On receiving a tx from the load balancer, a backend machine verifies it, then broadcasts it out to the other backends which then skip verification. Nodes should stay in sync as they all see the same transactions.
Would the load balancer become a bottleneck? I doubt it. Servers at Google are capable of handling thousands of RPCs per second per core. A single 16-core server could balance all the traffic Bitcoin needs for years of growth. If one day the traffic is so huge a single machine can't even load balance them, filtering can be added to the protocol so a connection can opt to receive only a subset of all traffic (eg selected by hash again).
This doesn't scale infinitely, but there's no such thing as a distributed system that has zero scaling bottlenecks at all. After doing that the next problem might become network bandwidth or processing addr broadcasts or handling giant wallets.
On storage, Dan doesn't mention the ability to do tx pruning (perhaps because it is, like so much else, not implemented yet). The savings were calculated to be around 70% of disk space given the current state of the economy, though changes in how Bitcoin is used would change that figure as well. Tx pruning makes outstanding storage linear in the number of unspent outputs, rather than the total history of the economy.
Dan asserts that supernodes are basically banks. I disagree. The word "bank" combines many different things together. A high capacity Bitcoin node has no properties of traditional banks - they don't make loans, take on customers, etc. They just track and verify transactions. Dans assumption is that supernodes would be often combined with other functions like hosting peoples wallets and mining. I don't see any technical reason that should be so, though it might end up that way for other reasons.
How would supernodes be funded? This is like asking how web servers can be funded. Some companies choose to run their own, others choose to outsource. Some people rent personal servers for personal reasons. Whatever route is chosen, there is enough scope for optimization that running a supernode is unlikely to tax any but the poorest of organizations.