Question from one of the uninitiated: I heard that the Bitcoin block chain is already many gigabytes. How is this expected to scale over time and are there any challenges for the network if it becomes too large to quickly/easily share? (Or not since only the tail is really needed?)
>I heard that the Bitcoin block chain is already many gigabytes.
True.
>How is this expected to scale over time and are there any challenges for the network if it becomes too large to quickly/easily share?
This is debated.
>(Or not since only the tail is really needed?)
That's basically the first approach.
If you trust someone else to tell you the state at time X (give you a 'checkpoint' basically), then the volume of data still grows with the number of separate accounts that have 'bitcoins' in them, but [where all the remaining money is as of recent time X] is a lot less information than [the complete set of previous transactions for all time].
Or you could have a thin client, that trusts some other service to maintain and monitor the current state of the system, which your thin client regularly queries.
Both of these schemes cut down the data storage requirement a lot, and sort of solve that scalability problem.
However, both require trusting some third party to supply you with an abbreviated version of the transaction history (or group or parties, or chain of authority, etc.), and its open to debate whether, if you do that, you lose some of the 'decentralised' aspects of the system that make it nice. Or you could say that's "just a philosophical concern" that doesn't really matter.
I personally guess that the various developers will be able to engineer around this problem.
I'd be more worried the system handling real time transaction volume, if it became mass adopted, and people tried to do all transactions on the blockchain.
This is the size of the blockchain over time: https://blockchain.info/charts/blocks-size. It's currently 12 GB and has a maximum growth rate of ~6 MB/hour. The hope is that storage and bandwidth get cheaper faster than the blockchain gets bigger.
There are definitely challenges with its current growth rate. As currently designed, it's capped at about 25,000 transactions per hour. The developers are working on addressing this limitation, but the solution is complex and they aren't done yet. We went from ~200 transactions/hour in Jan 2012 to ~2,700 transactions/hour in Dec 2013, so it's conceivable we end up getting pretty close to (or hitting) the cap in the near future.
Does that mean someone can denial-of-service all of bitcoin just by moving a balance between a couple wallets repeatedly? Can one person (or group)'s activity crowd out other people so their transactions can't be added to the blockchain? What prevents that from happening?
25,000/hour is a shockingly small number to me. I feel like I must be misunderstanding something, or else someone from 4chan would have already DOS'd bitcoin for fun.
Transactions normally include a small fee, to incentivize miners and disincentivize abuse. You don't have to pay the fee, but if there are more transactions being broadcast than the blockchain can accommodate, the fee-paying ones get priority. (It's a little more complicated than that: when you generate a transaction, you choose whatever fee you want, and they get prioritized based on a combination of the fee, the transaction size in KB, and how long it's been since those coins were last moved.)
Current transaction fees are typically in the range of 0.1-0.5mBTC, so in order to continuously flood out everyone else, you'd need to spend more than 2.5BTC/hour in fees.
It is definitely a small number. Visa is capable of handling 80 million+ per hour, for example. However, transactions are prioritized by transaction fee so you would have to pay a fee higher than all other transactions to block them out. Currently this would cost you something like $100k per day, but if you started to do this you would rapidly increase the cost of transactions, so the cost to perform this attack would grow much more expensive.
As you say, only the tail (or really, the head, if you think in terms of cons-ing onto a linked list) needs to be present for a client to operate at almost full operation. The only entities that really NEED the full chain are those who are doing historical accounting, like the various blockchain explorers and those who run analytics. These people are already putting some investment into scaling and processing concerns anyway, so I'm not worried about them.
I agree with fragsworth that once Bitcoin is mature the blockchain will grow linearly; in the short term we may see more rapid growth. Most users are not expected to store the whole blockchain; using SPV or UBC a peer can store much less data.
I would check out https://en.bitcoin.it/wiki/Scalability . In the paper published by "Satoshi Nakamoto" he detailed a technique called pruning in which old transactions that can longer affect other transactions are drop from the blockchain
The block chain is designed to grow (roughly) linearly, while storage capacity grows exponentially. Also, the protocol can be changed to accommodate any technical limitations in the future.
I've often wondered how exactly the protocol would be changed. Who is in charge? who would make the change? how would it be implemented and enforced in a decentralized system?
https://bitcoinfoundation.org/about/ There have already been some interesting happenings with upgrades. The blockchain forked and everyone had to roll back to a previous version.
I've been wondering about that exact thing - if incompatible versions could cause an accidental fork, and what would happen. If that has already happened, I would love to know the details.
People code bitcoin clients. People vote for a protocol change by using those clients instead of the old ones.
A change can not be enforced. If a significant subset of clients decides on a different path (for example stay on the old protocol), a fork of the blockchain would be the result. I guess then if you would own 1 BTC before, you'd suddenly own one "old Bitcoin" and one "new Bitcoin".
There are already clients that only download parts of the blockchain, trading storage and bandwidth for reduced security - for example the mobile clients, or Multibit (afaik). I suppose they rely on trusted nodes (not sure).
But suppose SHA256 would be broken and the "vote" would be to change the mining protocol to scrypt. Why wouldn't the nodes and miners change? It's not so different from updating your web server when there has been a security bug. Some people forget to update their web servers and get hacked. The next time, maybe they won't forget to update. Maybe if you installed your bitcoin software with a package manager, it will be automatically updated.
It would be interesting if there was an attempt to enforce "tainted coins" (forcing clients to reject bitcoins that are known to have been through criminal hands). I suppose governments could require businesses to only accept btc that are not tainted. I honestly don't know how things would play out - maybe the community would addopt it, maybe not, or maybe there would be a fork...
All just from my limited understanding, please correct me if necessary.
It's easy to beat an exponential with a linear function, at least over the short term. Anyway, isn't that true only in the limit where the number of transactions per second remains roughly constant?
The original whitepaper already mentions a way to reduce the size of the blockchain using Merkel Hashes (iirc) - they show that it is sufficient to only remember parts of the blockchain. It hasn't been implemented yet, but I suppose if the problem becomes really pressing it will be implemented.
I suppose some of the fun parts would go away then, such as the possibility to view every transaction that has ever been made - in the Merkel Hashed blockchain not all information would be preserved.
Edit: I suppose it would still be possible to monitor all transactions and remember them by some other means, just not in the blockchain.
