Topic: Best method of changing the maximum block size (Read 1620 times)

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-

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×pan=all&scale=1&address=

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.

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-

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.

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.

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-

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.

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.

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-

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.

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

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-

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

For example, if , then the max block size is increased beginning at + 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.

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

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.

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

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-

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.

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.