How a floating blocksize limit inevitably leads towards centralization

[misterbigg]

Include the soft limit into the verification rules of as many clients as possible, and miners who first comment out that rule for themselves will be punished by the network at least until a majority of users upgrade their clients to match.  The rest of the miners that didn't commetn out the rule would benefit from teh harm the first mover takes upon himself.

Huh...wha...eh??? This makes no sense. The "soft limit" is not a verification rule, it is part of the algorithm that the mining example code uses to put together a candidate block. It stops when it reaches 250kb. This doesn't mean that miners will reject blocks that are over 250kb, it just means that they will not PRODUCE them (unless someone modifies the code). This is neither a hard fork, nor a soft fork. Think of it as a "canary in the coal mine." Right now, there is little economic incentive to modify the piece of code. For two reasons: 1) the transaction volume is not high enough, and 2) block subsidies are orders of magnitude larger than fees. When these conditions change, miners at the margin will have a financial incentive to change the code. Someone like Gavin can study the blocks in the block chain to see what fraction of blocks are larger than 250kb. This will provide insights into how miners react to the soft limit.

Making the 250kb a verification rule of clients is a fork (not sure if its a hard fork or a soft fork). It makes no sense to do this. You can't assume that everyone is going to upgrade to this version, nor should you assume that once this rule is adopted by clients that it will ever go away. You have effectively reduced the 1 megabyte hard limit down to a 250 kilobyte hard limit. Good job, LOL, the opposite of what people are arguing for here!      

The fundamental market logic behind that idea seems solid enough that it actually doesn't matter too much how the relation is calculated.

But it does, and I gave an example. The transition from FPGA/GPU to ASIC will cause the network hashing rate to skyrocket in a way that is totally unconnected to the value of Bitcoin or the amount collected in fees. This alone should tell you that the connection between hash rate and transaction scarcity is tenuous at best (non-existent at worst, as is the case currently). If we had this system in place now, it would cause the block size to grow despite the absence of scarcity, resulting in less miner revenue not more.

I hope that we can put to rest the idea that tying the block size to the network hash rate is a bad idea.

I believe that any scheme for adjusting the maximum block size should:

1) React to scarcity
2) Prevent centralization by forcing out marginal miners

[1714134030]

1714134030

[1714134030]

1714134030

[MoonShadow]

Include the soft limit into the verification rules of as many clients as possible, and miners who first comment out that rule for themselves will be punished by the network at least until a majority of users upgrade their clients to match.  The rest of the miners that didn't commetn out the rule would benefit from teh harm the first mover takes upon himself.

Huh...wha...eh??? This makes no sense. The "soft limit" is not a verification rule, it is part of the algorithm that the mining example code uses to put together a candidate block. It stops when it reaches 250kb. This doesn't mean that miners will reject blocks that are over 250kb, it just means that they will not PRODUCE them (unless someone modifies the code).

I know what it means.

Making the 250kb a verification rule of clients is a fork (not sure if its a hard fork or a soft fork). It makes no sense to do this. You can't assume that everyone is going to upgrade to this version, nor should you assume that once this rule is adopted by clients that it will ever go away. You have effectively reduced the 1 megabyte hard limit down to a 250 kilobyte hard limit. Good job, LOL, the opposite of what people are arguing for here!      

I've done nothing of the sort.  If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?  Unless a majority of users also do so, I've done nothing.  Perhaps I dno't drpop it from my own chain, I just don't forward it.  It's something that I can do right now, and it's only effective if a significant number of others also do so.  However, if it does exist, it's presence becomes an enforcement mechanism upon the soft limit that miners presently abide by, that can be easily removed simply by a significant portion of the users agreeing that it should be done, and upgrading to the next versiuon of their client that has a higher soft limit.

For all we know, there are already clients that quietly drop blocks based upon the block reward address not being in their whitelist, or any other such metric.  Or even randomly.  None of this would matter until half of users followed the same rule.

[misterbigg]

if we scale up to a point where only the Googles of the world are capable of keeping up, what does that buy us?

We should

1) Have a more rigorous argument / test data that shows how a block size above a certain threshold will push miners off the system

2) Figure out how to relate measurements of the network to estimating the largest block size threshold

[Pieter Wuille]

I've done nothing of the sort.  If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?

Nothing, but you've kicked yourself off the network (until a majority of mining power + a significant amount of full nodes on the network implement your rule too.

[misterbigg]

If I add a rule to my client that it quietly drops blocks that are over 250Kb, what have I done to you?

The change you are suggesting is to set MAX_BLOCK_SIZE to 250kb. Isn't that a hard fork?

[paraipan]

we should see what happens as we run into the soft blocksize limits...what do you predict will happen?

In this order:

1. Most blocks are at or near the 250 kilobyte soft limit.
2. The memory pool of transactions grows due to insufficient space in blocks.
3. Users notice trend of transactions taking longer to confirm, or not confirming at all.
4. Fees increase as users pay more to improve confirmation times.
5. Miners (or mining pools) modify code to select transactions with the highest fees per kilobyte to fit into blocks. They remote the 250 kilobyte soft limit. Some miners disallow free transactions entirely.
6. Transactions clear much more quickly now, but fees decrease.
7. Blocks increase in size until they are at or near the one megabyte hard limit.
8. Fees start increasing. Free transactions rarely confirm at all now.
9. Small transactions are eliminated since they are not economically feasible. SatoshiDice increases betting minimums along with fees. The volume of SatoshiDice transactions decrease.
10. Users at the margins of transaction profitability with respect to fees are pushed off the network.
11. Many people, most non-technical, clamor for the block size limit to be lifted.
12. Fees reach an equilibrium where they remain stable.
13. Spurred by the profitability of Bitcoin transactions, alternate chains appear to capture the users that Bitcoin lost.
14. Pleased with their profitability, miners refuse to accept any hard fork to block size.

^ I like this, what do you think Gavin? Could be what Satoshi had in mind when implementing the halving of block rewards?

[Technomage]

But it does, and I gave an example. The transition from FPGA/GPU to ASIC will cause the network hashing rate to skyrocket in a way that is totally unconnected to the value of Bitcoin or the amount collected in fees. This alone should tell you that the connection between hash rate and transaction scarcity is tenuous at best (non-existent at worst, as is the case currently). If we had this system in place now, it would cause the block size to grow despite the absence of scarcity, resulting in less miner revenue not more.

I hope that we can put to rest the idea that tying the block size to the network hash rate is a bad idea.

I don't think we can put it to rest quite yet. Remember that currently we have a fixed reward of 25 BTC per block for mining. If this reward was in place forever, block size scarcity in terms of miner incentive would be irrelevant. Well not completely, even with a fixed reward it would eventually be such a small part of the monetary base that it wouldn't be enough. But that would take a very long time.

The point is that if this system was in place, and the fixed reward was small, there would be no "ASIC boom 2". There would be no "massive investments in next gen ASIC". This is because there would be a super incentive to not have too much mining power. Not only would the difficulty increase massively, so would the block size, leading to less fees from the users. Justifying the investments in massive amounts of new mining would be quite impossible.

There could be a limit on how much the block size can grow in any adjustment (which is what MoonShadow proposed) to have some kind of compromise though.

[markm]

How about a simple as Satohshi's reward-halving method?

Simply double the block size when you halve the block-reward size.

Voila, all done for the next 136 years, nice and predictable, plenty of time to prepare for etc etc etc.

-MarkM-

[misterbigg]

there would be a super incentive to not have too much mining power.

So your tradeoff would be to sacrifice network hash rate in favor of more transactions? I can't imagine anyone would accept that.

[markm]

The point is that if this system was in place, and the fixed reward was small, there would be no "ASIC boom 2". There would be no "massive investments in next gen ASIC". This is because there would be a super incentive to not have too much mining power. Not only would the difficulty increase massively, so would the block size, leading to less fees from the users. Justifying the investments in massive amounts of new mining would be quite impossible.

And carrying out a 51% attack that much cheaper for attackers.

-MarkM-

[wtfvanity]

How about a simple as Satohshi's reward-halving method?

Simply double the block size when you halve the block-reward size.

Voila, all done for the next 136 years, nice and predictable, plenty of time to prepare for etc etc etc.

-MarkM-

Bingo. And we should double it in the next 12 months for the first one because we missed the first half.

Dynamic, not open ended, and completely predictable. Probably not what yays or nays want but simple middle ground.

[Technomage]

The cost would scale directly with how many transactions are sent and how much fees are paid. We have no way of knowing how much protection is enough. We can't define it in a fixed fashion. The best way is to have some sort of a market. More transactions and more fees would lead to more protection. Less would lead to less protection.

What is enough and what is not enough? That is a problematic fundamental question.

[misterbigg]

How about a simple as Satohshi's reward-halving method?

Simply double the block size when you halve the block-reward size.

This doesn't respond directly to scarcity. It will either produce too little scarcity, or too much. And for long periods of time too, since the reward changes only once every four years. Furthermore, we don't know if the maximum block size would cross the threshold that pushes smaller miners out. It breaks both of the guidelines I established earlier:

1) React to scarcity
2) Prevent centralization by forcing out marginal miners

I think that leaving the maximum block size is preferable to doubling it periodically, because at least with the current scheme of fixed size we are guaranteed not to marginalize small miners (but it fails to react to scarcity).

[Technomage]

I don't like that solution either. It's not linked to actual usage in any way and could lead to issues. Simply doubling it based on time is a totally arbitrary decision.

[misterbigg]

We have no way of knowing how much protection is enough. We can't define it in a fixed fashion.

If by protection you mean hash rate, I think there's only one right answer, "as much as possible." Someone said earlier that Bitcoin should be thought of as the block chain with the largest amount of hashing power of any block chain and I think that's the right way of looking at it. Any less, and it is vulnerable to a competing block chain that offers more security. Or it is vulnerable to an attack. I believe that any increase in the maximum block size is going to reduce the maximum hashing power that can be reached at any given time, because increasing the block size will inevitably lead to a decrease in fees, can anyone provide a counter argument?

This having been said, if the community decides that Bitcoin is best served by trading away some of that maximum hashing power in exchange for an increase in the rate of transactions, the maximum block size must be increased. I said earlier that these two guidelines should apply for increasing the block size:

Any change in maximum block size should
1) React to scarcity, to preserve fees
2) Not force out small miners

Does anyone agree with these guidelines, or offer comments or criticisms?

In another thread I proposed two methods for adjusting block size. They directly address #1, and indirectly address #2 (by ensuring mining profitability):

Here's the first one. If you accept the idea that a fixed amount of transaction fees per block is a good idea (arguments for why this might work were expressed earlier in this thread), then you might like it:

1) Block size adjustments happen at the same time that network difficulty adjusts (every 210,000 tx?)
2) On a block size adjustment, the size either stays the same or is increased by a fixed percentage (say, 10%). This percentage is a baked-in constant requiring a hard fork to change.
3) The block size is increased if more than 50% of the blocks in the previous interval have a sum of transaction fees greater than 50BTC minus the block subsidy. The 50BTC constant and the threshold percentage are baked in.

If the idea of having a constant block reward forever bothers you, then here's another scheme:

1) Block size adjustments happen at the same time that network difficulty adjusts
2) On a block size adjustment, the size either stays the same or is increased by a fixed percentage (say, 10%). This percentage is a baked-in constant requiring a hard fork to change.
3) The block size is increased if more than 50% of the blocks in the previous interval have a size greater than or equal to 90% of the max block size. Both of the percentage thresholds are baked in.

As I said, these are just building blocks to stimulate ideas. Both of them directly respond to scarcity, and only look at information in the blockchain (easy consensus).

Can anyone improve on these ideas or offer a better alternative?

Does anyone think that letting miners produce blocks of arbitrary size and letting the network battle it out for them is a good idea? Will this produce more orphans and waste more of that precious bandwidth that everyone is all hopped up about? Is this better than either of the two schemes that I described above? If so, how?

[wtfvanity]

I don't like that solution either. It's not linked to actual usage in any way and could lead to issues. Simply doubling it based on time is a totally arbitrary decision.

Halving the block reward could lead to issues. Simply having it based on time is a totally arbitrary decision.

[misterbigg]

Halving the block reward could lead to issues. Simply having it based on time is a totally arbitrary decision.

That's right, and there is already a discussion of the issue that the block subsidy schedule might cause. Specifically, if the transaction fees and/or the value of Bitcoin do not rise to maintain the profitability of mining, the network hash rate will permanently decrease instead of increase.

[wtfvanity]

Halving the block reward could lead to issues. Simply having it based on time is a totally arbitrary decision.

That's right, and there is already a discussion of the issue that the block subsidy schedule might cause. Specifically, if the transaction fees and/or the value of Bitcoin do not rise to maintain the profitability of mining, the network hash rate will permanently decrease instead of increase.

misterbigg, if I've offended you, I'm sorry. Your posts in here have been about the best ones that I really have enjoyed of those tilting towards not increasing it. That's a very poor way of explaining your arguments, but I am greatful for your input on everything. It was actually your posts that I was reading where I found the Ms. Lawrence. Seemed like an excellent response to someone coming in and saying leave it alone with no explanation. Not too far off from what I feel like Havock is saying. Leave bitcoin alone or I'm leaving. That's hardly constructive.

Regardless of the outcome, there will surely be people upset and probably some that will abandon bitcoin based on the decision.

[misterbigg]

...Leave bitcoin alone or I'm leaving. That's hardly constructive....

Actually, it is VERY constructive! Voluntary usage of Bitcoin is one of the core values. The success of any forking change will be determined by the fraction of users who adopt it. Anything that might cause a significant fraction of users, especially miners, to refuse to adopt the new system is most likely a non-starter.

[wtfvanity]

So let me see if I have the math right according to the scalability article on Bitcoin.

Visa does 2000tps we can do 7. If Bitcoin scaled up to Visa, the wiki says we would need around an 8 megabits/second connection. That would create a block size of approximately 500 megs each. Am I hitting that number right? A home DSL connection would choke up with that and bandwidth caps at home would easily be exceeded. Nothing that serious miners or colocation couldn't handle.

CPU isn't an issue. At 72 GB a day serious pruning would have to be discussed.

At the minimum fee of 0.0005, that's over 600 BTC per block in fees if we increase the limit to 500 megs per block. But the discussion is we shouldn't make big blocks, so the fees increase for the miners? It seems like if you have a million transactions in a block, that there could potentially be more fees. Of course they are smaller fees, but there are much more of them.

As of today, there should be no reason that we could not move the maximum block size to 10x what it currently is and we would probably good for a very long time being able to process more than paypal can. When that wall is approaching we can discuss it again like Satoshi suggested.