Best method of changing the maximum block size

[misterbigg]

After hearing everything, I believe this is so far the best method proposed:

1) A boolean flag is added to each block. The flag represents the block solver's yes or no vote for increasing the block size. The independent miner or mining pool sets this flag according to their preference for an increase.

2) Every time the difficulty is adjusted, the number of yes votes is counted from the last adjustment. If the number of yes votes is greater than 90%, then the block size is increased by 1%. Both percentages are baked-in constants, requiring a hard fork to change.

I don't like any of my other proposals for the reason I don't think any of them can accurately take into account all of the complex variables that determine if the block size should increase. The increased bandwidth requirements of a larger block size should weigh into the decision of whether or not to increase it, which is something that Gavin's proposal does. But it happens in a fragile way that requires measurements and doesn't come to a rapid consensus.

The voting method is the simplest and most robust way for increasing the block size, because it lets individual miners choose whatever method they want for making the decision. Some may decide that bandwidth matters. Others may want simply to limit the total scarcity. Voting is a proxy for deferring the implementation of the "decision function" for raising the block size to later. It gives us a flexible system that requires most of the mining community to agree, without tying us down to a specific formula like doubling the size periodically or requiring difficult to agree on measurements.

The optimum method for increasing the block size would have to factor in the exchange rate, people's tolerance for fees, and the effects of the increased bandwidth requirement. I do not believe this can be modeled in an automated fashion. Therefore, we solve the problem in parallel by letting miners try to solve this complex equation for their own use-case and vote on the result.


The 90% and 1% figures are just examples, other values may work better (but once they are published they can never change).

I'm not sure whether or not I am in favor of even increasing the block size. There is definitely a strong argument to be made for just leaving it alone. However, if we do decide to increase the block size I think this is the best method so far. I would love to hear counter examples or criticisms.

[solex]

This is not a criticism of the voting strategy above or any adaptive strategy for changing the maximum block size, just an interim solution if there is no consensus and time is drifting on.

This simple solution does the minimum necessary to preserve the status quo until a permanent strategy is implemented.

It is suggested that in the next version of bitcoin-qt and bitcoind the 1Mb block size limit constant becomes a variable that increases by 20% if the average block within the previous difficulty period is >80% of the max size limit.

The importance of an interim solution is that as many nodes as possible can be upgraded at the convenience of their owners. This drastically reduces the odds of forking the bitcoin blockchain with many users "on each side" which may well result if there was an emergency change required after a sharp growth in transaction volumes causing 1Mb block saturation.

[markm]

That seems like just an invitation for someone to game it.

How much percent of the hashing power would it take to just drive block size up forever using that formula?

(20% per step! Srsly? At least the 1% in original post would take 100 difficulty periods (or so; is it closer to 70 really?) to double it but compound interest is a bitch, ask investors whether 1% per difficulty interest on an investment would be legit or a ponzi...)

-MarkM-

[solex]

20% only when 2016 blocks are over 80% full. That cannot be gamed by anyone.

[TierNolan]

20% only when 2016 blocks are over 80% full. That cannot be gamed by anyone.

Sure it can.  Miners just have to pad all blocks to > MAX_BLOCK_SIZE * 0.8.

The effect is that it can be increased if 80% of miners agree. 

[solex]

20% only when 2016 blocks are over 80% full. That cannot be gamed by anyone.

Sure it can.  Miners just have to pad all blocks to > MAX_BLOCK_SIZE * 0.8.

The effect is that it can be increased if 80% of miners agree. 

That's a ridiculous argument because this risk has existed for four years already. You are describing the effect of a 51% attack where more than half the hashing power wants to harm bitcoin! If that is the case the existing situation is worse because 80% of the blocks could also be padded to 1Mb and that would be enough to cause indefinite transaction backlogs.

[markm]

No they don't want to harm bitcoin, they want to increase their 80% to 100% by eliminating the 20%, and don't care if they have to blow out the nation's infrastructure to do it.

That is, they don't care if they have to exceed the block size that protects the infrastructure against coalitions of terrorists and axes of allied enemy nations. In short they are willing to act like coalitions of terrorists or axes of allied enemy nations, or enlist the help of such groups, to get that remaining 20% for themselves.

-MarkM-

[solex]

Thanks, that's really encouraging. If these are the best arguments against it then I am happy now that it is a good idea.

[TierNolan]

That's a ridiculous argument because this risk has existed for four years already. You are describing the effect of a 51% attack where more than half the hashing power wants to harm bitcoin! If that is the case the existing situation is worse because 80% of the blocks could also be padded to 1Mb and that would be enough to cause indefinite transaction backlogs.

There is very little cost in padding to 80%, so a potential cartel has an advantage.

What about this rule instead:

Add a soft cap at MAX_BLOCK_SIZE * 0.5.

Blocks above the soft cap are allowed, but only if 25% of the fees (minting + tx) is paid to "true".

This means that the miner for the next block gets the money.

If 75% of the blocks in the last 2016 exceed the soft cap, then the cap is increased by 15%.

This means that a miner who votes "yes" for increasing the block size incurs a cost.  A cartel of miners is now harder to form, since it is in the interests of each member of the cartel to defect.

[misterbigg]

Note that all of these responses to the OP are still voting systems, even the one where miners pad blocks.

[TierNolan]

Another thing to consider (mentioned in the bumped thread on the issue) is to have a timeout.

For example, if <rule-met>, then the max block size is increased beginning at <this-block> + 20,000.

This gives 4-5 months notice at 1 block every 10 mins.

This would give all miners a chance to upgrade their internet connection.

[markm]

Good, yes.

One of the biggest advantages of the every reward halving idea was knowing well ahead of the exact block size to upgrade for and the date by which to complete the upgrade.

By the way it also occurred to me we aren't necessarily even competing against a six months final settlement with paypal, six months is the optimistic case; if they go bankrupt / into receivership there can be clawbacks going back up to a year. So imagining we need paypal's level of transactions on the blockchain is silly. Nothing a paypal type service 's customer does would even go out to the blockchain for six months, whereupon they can send one amount per other bank, gateway, wallet type service to settle up the grand total balance of trade of all their users six months ago.

Think Ripple IOUs as our paypal layer, with maybe quarterly redeeming of mass of IOUs at a gateway to put actual coins on the blockchain.

-MarkM-

[misterbigg]

Another thing to consider (mentioned in the bumped thread on the issue) is to have a timeout.

Oh...now that's an interesting twist. It's still a voting system though.

[TierNolan]

What about a rule that tries to maximize tx fees for miners.

Every second difficulty period, use MAX_BLOCK_SIZE * 1.25 and MAX_BLOCK_SIZE * 0.75.   Look at the previous 2 periods, ignoring the first and last 25% blocks in each period.  If the higher block size makes more fees, increase by 5%, otherwise decrease by 5%.  Ignoring the first and last 25% is to eliminate transients.

This will set the tx fee at a local maximum (hopefully global) and thus give the network maximum hashing power to secure the network.

[markm]

Again, please no going back.

If it absolutely must be raised, raise it.

But no decreases, ever.

Miners can voluntarily not use the full max size all they want, right now they aren't using the full max size, but we aren't going to lower the max just because they aren't actually using it all yet.

Heck if we want the kind of adaptive that reduces as well as increases we should forget all this yelling about needing to increase it and instead discuss how much and how fast to DECREASE it because MINERS AREN"T USING IT.

-MarkM-

[Technomage]

I have a problem with this system. I mean, why would even a majority of miners, let alone 90%, want to increase the block size at all? Isn't it in the best interest of miners to keep it scarce so they can drive up the fees? Well, at some point it would work against them when Bitcoin users start to switch to alternatives, but how would they know? Transactions would decrease, so how would that incentivize them to then raise it? I can't see why they would ever choose to raise it.

I find a solution where we simply let miners do whatever they want with the blocks, but implement tight rules on full nodes for the validation of them, a better solution than this.

[misterbigg]

Again, please no going back...If it absolutely must be raised, raise it....But no decreases, ever.

I agree with that, since it reduces the number of attack vectors.

...why would even a majority of miners, let alone 90%, want to increase the block size at all?

Now you're asking the right question! I haven't brought this up because it is difficult to understand but consider the following:

1) There is an upper limit to what customers are willing to pay in transaction fees

2) There is an upper limit to how long customers are willing for confirmation times

3) With a fixed block size, fees will rise to an equilibrium at this upper limit

4) As transaction volume continues to increase, confirmation times go up but fees don't rise

5) Transaction volume levels off when no new customers are willing to pay fees for transaction with long confirmation times

Increasing the block size by just enough to bring the confirmation time back down to ten minutes would increase the profitability of blocks (since fees wouldn't go down). I can think of no reliable way to automate this calculation which is why I support voting (i.e. let miners solve the problem in parallel).

tl;dr; There exists a network equilibrium point where a small increase in the block size raises the profitability of blocks.

This analysis ignores the effects of bandwidth knocking miners off the network.

[markm]

Yet we supposedly cannot rely on miners to find that equilibrium point for themselves with respect to the actual soft limit they do get to play around with, we have to let them screw with the "National Security" Absolute Block Size Limit ?

-MarkM-

[misterbigg]

Yet we supposedly cannot rely on miners to find that equilibrium point for themselves with respect to the actual soft limit

What's the soft limit got to do with it? Anyway, the soft limit is meaningless until transaction volume increases. Besides, I already outlined my predictions for what will happen to the soft limit. It's based on every miner acting in their own economic best interest (a rational assumption).

...they do get to play around with, we have to left them screw with the National Security Block Size Limit ?

Hey, I never said it was perfect. I said that if we're going to allow the block size to increase, then voting is the most robust way to do it. I can't even begin to imagine how you could produce an automated system that determines what block size corresponds to maintaining the equilibrium, especially since some of the factors that determine the equilibrium are psychological (the highest fee / confirmation time that customers will tolerate).

There's still a very strong case for leaving it at one megabyte. Or simply increasing it once by some suitably small amount. Say, to three megabytes.

[solex]

That's a ridiculous argument because this risk has existed for four years already. You are describing the effect of a 51% attack where more than half the hashing power wants to harm bitcoin! If that is the case the existing situation is worse because 80% of the blocks could also be padded to 1Mb and that would be enough to cause indefinite transaction backlogs.

There is very little cost in padding to 80%, so a potential cartel has an advantage.

What about this rule instead:

Add a soft cap at MAX_BLOCK_SIZE * 0.5.

Blocks above the soft cap are allowed, but only if 25% of the fees (minting + tx) is paid to "true".

This means that the miner for the next block gets the money.

If 75% of the blocks in the last 2016 exceed the soft cap, then the cap is increased by 15%.

This means that a miner who votes "yes" for increasing the block size incurs a cost.  A cartel of miners is now harder to form, since it is in the interests of each member of the cartel to defect.

Tier, I too think this is a good refinement.
It is still a limit that is simply implemented which means it can be done sooner than later. This has to be the majority concern: to allow the most time for nodes to upgrade which reduces the non-zero probability of a self-inflicted bitcoin train wreck.