OK thanks for that clarification. To help me understand better: Say there are 1,000,000 people with Bitcoin accounts then how many people would have a copy of the block chain (based on present stats)?
As many as are required to keep the network decentralized. I'd say 3,000 is enough, but it's possible to make do with less.
I'm definitely getting the sense from the various answer there actually is a problem in the Bitcoin architecture i.r.o. scalability which has not yet been resolved. And this is clearly an issue. Relying on Moore's Law or hoping that a solution will "emerge" in the future when it is needed, is a dangerous way to proceed IMHO. Has anyone articulated a detailed solution yet whereby Bitcoin could scale to say 1 billion users (each making 1 transaction per day)?
Did you read the page in the wiki about scalability that was linked in a previous comment?
The solutions don't need to emerge, the solutions are known and just need to be implemented.
Does anyone know how many Bitcoin users there presently are? Or what the current average transactions per day are?
How many users is anyone's guess, depends also on whom you call a user. In the past 24 hours there were 20338 transactions.
Wow only 0.3% - that would make a difference in how I'm thinking about it.
I did read the wiki, and understood it to a degree (I'm not that tech) - but I still get the sense that it's not all worked out - and that it will be tricky to scale. It seems it's the fact that the architecture is decentralized in first place that makes for bandwidth issues. At 1 billion users and 1 transaction each per day (total 11ktps) and assuming 0.3% of people have the block chain that needs updating, that's still 11,000 writes to 3,000,000 locations each second. Sounds like a lot of traffic to me. I haven't worked out the numbers though...
It doesn't scale linearly. I wouldn't be surprised if a single node could technically serve all users. But we need many nodes to keep the network healthy, robust and competitive. My guesstimate is that 3,000 is good, and that's just as true when there are 1B users as when there are 1M.
Assuming each transaction is 1KB, we're talking about 10K tps * 1KB = 10 MB/s per node, which is a high-end home internet connection now, let alone a business-grade connection in the future. It should be well within the ability of any company that receives a lot of payments and has an interest both in the health of Bitcoin and its own safety of payments.
What is your understanding about the practical implementation of the solutions to make for full scalability? Is it happening as we speak? Progress being made?
I'm more of a theory guy but there's progress. We have some lightweight clients, and there's a new construct design by etothepii that gives lightweight clients even more power than in Satoshi's original design. Also I think there's work being done with respect to pruning, which will keep storage requirements relatively low.
And a personal question: With all of your knowledge and understanding of the system, do you think it can actually scale to a billion transactions per day, with its present architecture, and not choke the entire global Internet? Do you personally think Bitcoin is truly a sustainable system that could support most of the world using it as its primary currency. Will the architecture actually scale ALL the way?
Yes, I believe even with the existing ideas and technology it can technically scale to a billion transactions per day. No doubt there will also be new ideas and hardware advances that will make things even easier. If someone comes up with a completely different architecture that is even more scalable, Bitcoin can migrate to it while keeping people's savings intact.
Also, as MoonShadow points out, it doesn't
need to scale to a billion raw transactions per second. Bitcoin's role main role is to be a superior alternative to physical cash; just as there are services to overcome the deficiencies of cash, so can there be services to overcome any deficiencies of Bitcoin. But because Bitcoin is digital and has a very powerful scripting system, these services can be much more lightweight and competitive, and hence better and more efficient, than with the current system.
For example, you can have a client that stores the majority of your savings locally (preferably with some multiple signature arrangement for added safety) but automatically keeps some in an eWallet service. Whenever you make a small transaction it is done internally in the eWallet (with reciprocity with other eWallets); only for large transfers/eWallet replenishment you make a raw Bitcoin transaction. This already can cut maybe 90% transactions.
Also, solutions such as Ripple and Open Transactions can work much better with Bitcoin as their foundation, and they have much lower resource requirements for global commerce.
The real problem isn't with the feasibility, it's with the incentive structure. Running a node should be relatively easy, but it will still have costs, and not much direct gain - it's a Tragedy of the Commons problem. There could be a situation where everyone tries to freeload on the other. This can be resolved if the costs can be kept low enough that companies won't be fussy about it, with a market for node services, or with a transaction propagation incentivization schemes as in the "On Bitcoin and Red Balloons" paper.
And, the real problem isn't with the marginal resource cost of handling transactions, either. It's with the amortized cost of securing transactions with hashing. Depending on how strong the incentives of potential attackers, funding the defense efforts is going to cost a lot for the Bitcoin economy, regardless of the technical solution chosen. This I think is the main challenge, and while there are some proposed mitigating schemes, they are not popular.
