Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't work for Coinbase, but I'll try to answer (someone correct me if I'm wrong):

> - 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).



> 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.

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.


Do you have a link with more about that?

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.



It's not that difficult, as long as the vast majority of users agree to upgrade by a certain date. New versions of clients are coded to switch the parameter after a certain block number, far enough in the future to give everyone plenty of time to upgrade.


> It's not that difficult, as long as the vast majority of users agree to upgrade by a certain date.

In other words, a hard fork. These things should not be done done casually.


"The block transaction cap is just a hardcoded value in the client"

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...


Many reasons are outlined in the link of the grandparent's post. https://en.bitcoin.it/wiki/Scalability (Check out the rest of the wiki, it's quite informative.)

To summarize: It helps reduce some DoS attack vectors and helps encourage the use of transaction fees early on.


The fact that there is a risk of a DoS attack without hard-coded limits on global transaction volume sounds like a much deeper flaw in the design of Bitcoin. It is particularly troublesome given the existence of protocols that do not have this problem, like Chaum's offline digital cash systems (which have been extensively researched by cryptographers).

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.


I don't think Bitcoin is even trying to solve the same problem Chaum's ecash was. Bitcoin is about creating a distributed, consistent transaction ledger; ecash is more like a conditionally anonymized electronic certified check.


OK, so what is the formal definition of a "distributed consistent transaction ledger?" How is security defined here?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: