To those who have seen our growing pains - the full intention of raising money is to address those pain points. We look forward to doing our best to eliminate each of them one by one.
- The network imposes a limit of 7 transactions per second (https://en.bitcoin.it/wiki/Scalability); and the information I've seen suggests that it typically averages much less than that (http://blockchain.info/en/charts/n-transactions).
- There is a finite number of Bitcoins, and they can effectively be lost forever if private keys are lost. This has led to people doing things like leaving tips in BTC which expire (https://www.bctip.org/).
This is disregarding the volatility of the price and the fact that it seems to behave like a speculative commodity rather than a real currency -- what is your vision of "mass adoption" of Bitcoin?
2) Bitcoin money supply is currently INFLATING at fast clip of over 10%/year. Refer to nobel economist Milton Friedman and others to read about a constant-supply currency.[1]
The volatility is because the sum(bids+asks) on the exchanges is small relative to speculator's pockets. This is getting better with time.
[1]http://www.econlib.org/library/Columns/y2006/Friedmantranscr...
> - The network imposes a limit of 7 transactions per second (https://en.bitcoin.it/wiki/Scalability); and the information I've seen suggests that it typically averages much less than that (http://blockchain.info/en/charts/n-transactions).
The transaction volume is currently limited by two things. (1) The number of transactions that can be included within each block by miners. (2) The bandwidth required to keep up with the blockchain.
The block transaction cap is just a hardcoded value in the client. Like many things that change on a monthly basis in the reference client, it can and will be changed when the time is right. There are lots of variables which are being adjusted as Bitcoin grows, such as the recommended minimum fee for small transactions.
As for the bandwidth, there are a few options: First part is to only require clients to maintain a tiny summary of each block, rather than the full ledger. This will reduce the sync bandwidth required by at least two orders of magnitude. This solution only applies to clients, not miners. The second less popular plan is to encourage networks of "green addresses" (kind of like trusted banks that don't need to verify transactions between each other) as well as super-nodes which delegate trust by layers. And finally, there is always methods for pruning the Merkle tree to remove unnecessary history, or introduce periodic genesis blocks which put down the current state in stone without requiring the history before it. These are just off the top of my head, there are likely more initiatives in the works, maybe of which have been planned for from the first day that the Bitcoin whitepaper was published.
> - There is a finite number of Bitcoins, and they can effectively be lost forever if private keys are lost. This has led to people doing things like leaving tips in BTC which expire (https://www.bctip.org/).
Both of these things are true.
Keep in mind, a bitcoin can be divided into units of 0.00000001 (what we call a satoshi). That is to say, the finite number of satoshis is 2,100,000,000,000,000 which should be more than enough for a long long time. (More on that here: https://en.bitcoin.it/wiki/Bitcoin)
As for the question of Bitcoin being lost forever, all this means is that everyone else's Bitcoins rise in value slightly (since you're reducing supply).
Why is these even a value? Why does the protocol limit how many transactions can be performed in a given period of time? This seems like an extreme deficiency to me...
To summarize: It helps reduce some DoS attack vectors and helps encourage the use of transaction fees early on.
What is Bitcoin's excuse for this problem? Surely it cannot be that a goal of Bitcoin is to remove central authorities, if some central team of developers has the power to change this system parameter at will. I suppose the only real excuse is that Satoshi was not even aware of that body of work, which would not be all that shocking given the fact that it is not even cited in the Bitcoin paper.
No, the block size is a validation rule. Changing it will require a hard-fork. That must happen if bitcoin is to scale. But it's not an easy change.
I recall reading a discussion on the forums about doubling the value of MAX_BLOCK_SIZE in the near-term. I didn't realize that old clients would outright reject larger blocks.
Either way, sounds like everyone is in agreement that this will have to happen inevitably.
In other words, a hard fork. These things should not be done done casually.
I'm interested to guess at what kind of chunk of this $5mil goes to corporate-level capital concerns like infosec vs. the regular startup sinkholes. Can you colorize for me what kind of chunk of your operating expenses goes toward security in one form or another?