caveden


Offline


Activity: 1106

Merit: 1001


LegendaryActivity: 1106Merit: 1001 Re: How a floating blocksize limit inevitably leads towards centralization February 18, 2013, 08:48:37 PM #21


Also, having fewer participants in a market because these participants are good enough to keep aspiring competitors at bay is not a bad thing. The problem arises when barriers of entry are artificial (legal, bureaucratic etc), not when they're part of the business itself. Barriers of entry as part of the business means that the current market's participants are so advanced that everybody else wanting to enter will have to get at least as good as the current participants for a start.


Quote from: Mike Hearn on February 18, 2013, 07:55:28 PM Removing the block cap means a hard fork, and once we decided to do that we may as well throw in some "no brainer" upgrades as well, like supporting ed25519 which is orders of magnitude faster than ECDSA+secp256k1. Then a single strong machine can go up to hundreds of thousands of transactions per second.


That's cool. Please core devs, consider studying what other hard fork changes would be interesting to put in, because we risk hitting the 1Mb limit quite soon. Great posts from Mike and Gavin in this thread. There's indeed no reason to panic over "too much centralization". Actually, setting an arbitrary limit (or an arbitrary formula to set the limit) is the very definition of "central planning", while letting it get spontaneously set is the very definition of "decentralized order".Also, having fewer participants in a market because these participants are good enough to keep aspiring competitors at bay is not a bad thing. The problem arises when barriers of entry are artificial (legal, bureaucratic etc), not when they're part of the business itself. Barriers of entry as part of the business means that the current market's participants are so advanced that everybody else wanting to enter will have to get at least as good as the current participants for a start.That's cool. Please core devs, consider studying what other hard fork changes would be interesting to put in, because we risk hitting the 1Mb limit quite soon. 18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL

Mike Hearn


Offline


Activity: 1526

Merit: 1006


LegendaryActivity: 1526Merit: 1006 Re: How a floating blocksize limit inevitably leads towards centralization February 18, 2013, 09:12:34 PM #24 Quote from: retep on February 18, 2013, 08:35:12 PM Network assurance contracts are far from a sure thing. It's basically an attempt to solve the tragedy of the commons, and the success rate society has had there is pitiful, even with strong central authorities. Assuming they will work is a big risk.


Sure, there is some risk, but Kickstarter is showing that the general concept can indeed fund public goods.


Quote from: retep on February 18, 2013, 08:35:12 PM I don't see any reason to think CPU power will be the issue. It's network capacity and disk space that is the problem.


1.2 megabytes a second is only ~10 megabits per second - pretty sure my parents house has more bandwidth than that. Google is wiring Kansas City with gigabit fibre right now, and we're not running it as a charity. So network capacity doesn't worry me a whole lot. There's plenty of places in the world that can keep up with a poxy 10 megabits.


3T per month of transfer is again, not a big deal. For a whopping $75 per month bitvps.com will rent you a machine that has 5TB of bandwidth quota per month and 100mbit connectivity.


Lots of people can afford this. But by the time Bitcoin gets to that level of traffic, if it ever does, it might cost more like $75 a year.


Quote from: retep on February 18, 2013, 08:35:12 PM You also have to ask the question, what % of that 3TiB/month results in unspent txouts? Ultimately it's the UTXO set that is the hard limit on the storage requirements for full validating nodes. Even at just 1% volume growth, you're looking at 3GiB/month growth in your requirement for fast-random-access memory.


How did you arrive at 3GB/month? The entire UTXO set currently fits in a few hundred megs of RAM.


Quote from: retep on February 18, 2013, 08:35:12 PM All the time you're spending waiting for transactions to be retrieved from memory is time you aren't hashing.


