Bitcoin Forum

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


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.

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.

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-

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.

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-

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

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.

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

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.

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-

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

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.

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-

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.

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


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.

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-

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


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.

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.

Would a "sorry this code is out of date" shutdown for nodes that fail to update in time be "a trainwreck" or just get such nodes out of the way so those that do upgrade in time can smoothly synch in whatever the new system turns out, by then, to be?

Maybe there is starting to even be a case for a Big Bitcoin launch that will allow anyone interested in massive blocks to destroy coins on the old chain in return for being minted coins on a new chain that uses massive blocks.

The new, massive-block chain would still be denominated in bitcoin, without inflating the total number of bitcoins in (spendable) existence.

The new massive chain would be the one to attempt to muscle in on the retail sales market or other markets where handling vast numbers of transactions fast is key.

We could even call the old chain "Bitcoin savings accounts" and the new one "Bitcoin current accounts".

Make it big enough and maybe it will show us the hard way whether blockchains are just too hard/expensive to scale.

Make it a secondary chain in merged-mining, so classic bitcoin need not bother with it at at all but miners huge enough to handle it (let it be really really huge) should be able to easily handle the classic chain as primary to merge with so they don't lose the benefit of all the hashing power being directed at the classic chain.

Maybe the Bitcoin plus Ripple thread I am about to read offers a better idea though...

-MarkM-

This depends on the time-frame. One a six month time-frame a major this could lead to serious problems. One a two year time-frame it would likely not be an issue at all. Was there not recently a time-out on a delayed change that had been implemented by Satoshi that made certain old clients obsolete.

The key here is that delay could cause very serious problems because we will need to implement this with at least a 12 month delay or even better an 18 month delay or longer.

When the blue line touches 345,000 the cow-catcher on Bitcoin's train connects with the buffers...

https://blockchain.info/charts/n-transactions?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address= (https://blockchain.info/charts/n-transactions?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=)

So not until then will we see whether transactions are so worthless that the only application that can afford to pay for them is an application that amounts to a "throw away money" game? No legitimate use can possibly make better use of the space we already have than Satoshi Dice does?

If that is the case we seem to have been throwing away money all along on building the worlds most useless, albeit most powerful, distributed system, thus maybe should rather shut the experiment down than throw even more money at providing unwanted blockchain space that transactors (other than those in the business of throwing away other people's money) do not want.

-MarkM-