BIP1xx DynamicMaxBlockSize

[Meuh6879]

Where were you a month ago when someone was spamming transactions? Don't give me BS about a "stress test" it was most definitely a spam attack. It caused 80000 unconfirmed txs, many of them legitimate.

well, if people don't emit bitcoin without fees ... at the first step 

[teukon]

I dislike the whole approach of BIP1xx.  The proposal(s) attempt to set a block size limit by considering first and foremost the demand for block space.  Centralisation concerns are completely neglected for the sake of capacity.

The problem is not that blocks are being filled, it is that blocks are being filled despite the fact that today's technology can accommodate a well-decentralised network with larger blocks.  We don't have an infinity of resources that we can just dynamically raise the block size limit into, but we do have some resources which the 1MB limit prevents us from employing.

[tvbcof]

Bitcoin is not like linux, which can have different flavor. It is a medium of exchange and a medium of exchange requires trust. If bitcoin splits, that would severely hamper that trust.

That is simply not true in my case.  What is 'hampering trust' in my mind is the 'Free Shit Nation' gaggle of hangers-on who demand free transactions that are subsidized by others because that is how life has always worked for them.  I would love to wave them goodbye and wish them the best on their bloatchain fork then be able to move forward building a rock solid and truly distributed foundation which would have a multitude of uses.  Including, ironically, many opportunities for the 'Free Shit Minions' to get exactly what they are after.

Seems you support the bidding of Tx fee to subsidize miners while block subsidy goes down. In that case, Proposal 2 of BIP 1xx might interest you.

Personally, I am undecided about this. Because one of the reason many people got attracted towards bitcoin was very cheap or almost no transfer cost. For those who thinks the same may like Proposal 1 of BIP 1xx.

The obvious course of action is to do nothing until it is needed which would probably be years from now.  All these hysterics about the block size are a fabricated PR stunt.  A surprisingly effective one at that.

Miners are almost as big a problem as the no-fee Free Shit Nation people and there is an association which is beyond the scope of this note.  I hope that the skilled people in the community make the best of this manufactured 'crisis' and get rid of that problem as well by adjusting the POW scheme.  I'm not holding my breath for that though.

[DooMAD]

I dislike the whole approach of BIP1xx.  The proposal(s) attempt to set a block size limit by considering first and foremost the demand for block space.  Centralisation concerns are completely neglected for the sake of capacity.

The problem is not that blocks are being filled, it is that blocks are being filled despite the fact that today's technology can accommodate a well-decentralised network with larger blocks.  We don't have an infinity of resources that we can just dynamically raise the block size limit into, but we do have some resources which the 1MB limit prevents us from employing.

Perhaps there needs to be a balance struck somewhere between BIP1xx and BIP100.  BIP1xx only considers the demand for block space, but BIP100 only considers what benefits the miners and not the network as a whole.  The prospect of having an entity choose a variable that primarily benefits them still doesn't sit well with me, when we can define it algorithmically like we do with everything else.  BIP100, as it currently stands, simply places too much emphasis and power on one side.

To save all the arguing, the compromise we should all agree on is to find a solution that splits the demand for block space and the demand for decentralisation 50/50.  Can we at least agree on that much?  Something that maintains an equilibrium between resources, incentive and capacity.  That way almost everyone gets what they want.  Almost.  I know some people think the demand for block space shouldn't be considered at all and that centralisation concerns are the only thing that's important, but clearly they're not going to budge on that, so frankly they can get left behind if they aren't willing to make even the slightest concessions.  One way or another, the blocksize is increasing, it's just agreeing on how to implement it in a stable way.

[teukon]

I dislike the whole approach of BIP1xx.  The proposal(s) attempt to set a block size limit by considering first and foremost the demand for block space.  Centralisation concerns are completely neglected for the sake of capacity.

The problem is not that blocks are being filled, it is that blocks are being filled despite the fact that today's technology can accommodate a well-decentralised network with larger blocks.  We don't have an infinity of resources that we can just dynamically raise the block size limit into, but we do have some resources which the 1MB limit prevents us from employing.

Perhaps there needs to be a balance struck somewhere between BIP1xx and BIP100.  BIP1xx only considers the demand for block space, but BIP100 only considers what benefits the miners and not the network as a whole.  The prospect of having an entity choose a variable that primarily benefits them still doesn't sit well with me, when we can define it algorithmically like we do with everything else.  BIP100 simply places too much emphasis and power on one side.

To save all the arguing, the compromise we should all agree on is to find a solution that splits the demand for block space and the demand for decentralisation 50/50.  Can we at least agree on that much?  Something that maintains an equilibrium between resources, incentive and capacity.  That way almost everyone gets what they want.  Almost.  I know some people think the demand for block space shouldn't be considered at all and that centralisation concerns are the only thing that's important, but clearly they're not going to budge on that, so frankly they can get left behind if they aren't willing to make even the slightest concessions.  One way or another, the blocksize is increasing, it's just agreeing on how to implement it in a stable way.

Firstly, nice post.  You've helped me focus a bit better on the issues.

"demand for block space" and "decentralisation" are necessarily measured on different scales.  As a result, there is no real "50/50" here.

As far as deriving a balance algorithmically goes, notice that such an algorithm must have as inputs "block space demand" and "level of decentralisation".  Bitcoin can easily fathom the first but has no way of measuring the second.  As far as Bitcoin knows, the entire Bitcoin system to date could be nothing more than a simulation on a single machine.  Bitcoin has to be told about this "decentralisation" thing by us humans, either by setting core parameters (kicking the can) or setting up some kind of voting.

Of course, humans respond to incentives.  If care is not taken to make sure these incentives align with choosing/voting good parameters, Bitcoin will degrade in the long term.  Miner voting is a fairly clever attempt because miners typically do have an incentive to help Bitcoin succeed.  Unfortunately, each miner is also driven to control as large a piece of the transaction-fee pie as they can, throwing the quality of the data gathered through voting into question.

I've tried to think of some way to have humans vote/bet on good block size limits where their financial incentives are more clearly aligned with Bitcoin's long-term health (like provably locking up bitcoins for 10 years to vote) but have had no real success yet.  Ugly though it may seem, I currently believe the can-kicking BIP101 proposal is the best under consideration.

[Klestin]

The obvious course of action is to do nothing until it is needed which would probably be years from now.

Two years ago the average block size was 120k.  One year ago it was 220k.  Now it is 400k.  That shows nearly a doubling of block size per year.  And that's average block size - the peaks are of course much higher.  This kind of change should not be rolled out at the last minute.  If the uncertainty of the block size cap change isn't hurting adoption now, it will be soon.

[tvbcof]

The obvious course of action is to do nothing until it is needed which would probably be years from now.

Two years ago the average block size was 120k.  One year ago it was 220k.  Now it is 400k.  That shows nearly a doubling of block size per year.  And that's average block size - the peaks are of course much higher.  This kind of change should not be rolled out at the last minute.  If the uncertainty of the block size cap change isn't hurting adoption now, it will be soon.

The blocks are chock full of trivial nonsense transaction which don't belong there.  When each on-chain transaction represents thousands of off-chain coffee purchases and a few $100,000+ (equiv) transactions from people/entities balancing their risk and it still fills up and push fees into the start of the area that banks charge for (much lesser) service, then we start to need a solution to what is currently a non-problem.  That is why I say 'years'.

Of course you and I dis-agree about where the value of Bitcoin lies.  I see your argument as being:  "Oh no!  The cake I bake every night is almost gone by the morning because the mice are eating it.  Need to start baking bigger cakes."  My argument is that the mice are shitting all over the house and tearing up the pillows and there is no reason to cater to them.  I actually don't want the little buggers to starve to death and I have an infinite supply of food with a little development work so I could let them feed to their heart's content outdoors.

The trouble with your argument (as I see it) is that bloating the blockchain to support all uses for everything on-chain is destined to destroy the solution completely as a support mechanism for nearly infinite subordinate chains.  That is why I will fight with all my effort to avoid this.

I cannot deny that some of the people who hold more BTC than I and/or who were in the game longer than I simply see things differently.  That is why I strongly favor simply forking the blockchain itself (via XT or dynamic adjustments or whatever) and letting both sides just move forward with their own philosophies.

[Klestin]

I see your argument as being:  [snip]

No, my argument is: Let the market decide which transactions get in.  Don't have an artificial cap that prevents that transactional market from operating.  There will be other technological solutions that trim the fat, but let the benefits of those solutions be the reason that people move some transactions off the main chain. Don't force them out.

[tvbcof]

I see your argument as being:  [snip]

No, my argument is: Let the market decide which transactions get in.  Don't have an artificial cap that prevents that transactional market from operating.  There will be other technological solutions that trim the fat, but let the benefits of those solutions be the reason that people move some transactions off the main chain. Don't force them out.

Ignoring for a moment the bass-ackwards and nonsensical assertion that failing to relaxing the transaction rate so that it can come under strain 'prevents the transcriptional market from operating'...

Every system has operational parameters.  The 1MB block size is not an 'artificial cap' any more than a 32-bit integer in a compiler is.  It is a design decision which makes a system work in a certain way.  The 1MB block size like any other such parameter has both pros and cons.  The 21x10^6 money supply is another such parameter and it likewise has certain pros and certain cons depending on one's taste.

Like I said in the snipped, I'm more than happy to see the blockchain forked and 'let the market decide.'

[brg444]

I see your argument as being:  [snip]

No, my argument is: Let the market decide which transactions get in.  Don't have an artificial cap that prevents that transactional market from operating.  There will be other technological solutions that trim the fat, but let the benefits of those solutions be the reason that people move some transactions off the main chain. Don't force them out.

There is a reason why the artificial cap exists and that is because the "free market" as you so describes it does not account of the security of the system. To quote:

The reason this is important is some not all miners have an interest in creating artificial scarcity. In the case of a couple they simply couldn't operate above a certain limit. Others could not particularly care.

As technology improves, bigger actors get into the game and the inherent economies of scale take place, orphan risk from including too many transactions will necessarily diminish and large miners will necessarily have an advantage and an ability to drive smaller ones out of business in a precipitated way. This is concerning because while mining consolidating into enormous corporations is by all account an obvious outcome, we cannot afford for the same for nodes.

It helps to think of it as a tragedy of the commons: absent of a blocksize it will eventually become in the miner's best interest to include as many transactions as possible in their blocks and consequently restricting access to governance of the network by way of bloating the blockchain.

[Eastwind]

The dynamic block size limit should not mean the block size go one way up only. The block size soft limit can be 2-3 times of the median of last 10,000 blocks. This limit can be breached to allow more transactions, but miner will get penalty of fees if they allow the block size to be over. That is similar to Monero (coin)

[RocketSingh]

BIP 1xx is leading over BIP 101!!! That's incredible

p.s. ah I know those sock-puppet theories... every BIP backer have them.

[CounterEntropy]

The dynamic block size limit should not mean the block size go one way up only. The block size soft limit can be 2-3 times of the median of last 10,000 blocks. This limit can be breached to allow more transactions, but miner will get penalty of fees if they allow the block size to be over. That is similar to Monero (coin)

What's wrong if mempool is full and Tx volume demands more space in blocks ?

[Carlton Banks]

Ugly though it may seem, I currently believe the can-kicking BIP101 proposal is the best under consideration.

The reason why it seems ugly is because it involves kicking the metaphorical can into the upper atmosphere, not simply kicking it out of sight.

BIP101 is the most aggressive expansion schedule (well, except for the previous revision of BIP101 that advocated 20 MB + 2 yearly doublings). Not my definition of kicking the can, you need to be able to find the can when it's the right time to pick it up again....

[EpicFail]

I think 1MB is good. Keeps the cup-of-coffee-buyers and third-world-small-bag-of-rice-purchaser off the blockchain.

[teukon]

Ugly though it may seem, I currently believe the can-kicking BIP101 proposal is the best under consideration.

The reason why it seems ugly is because it involves kicking the metaphorical can into the upper atmosphere, not simply kicking it out of sight.

BIP101 is the most aggressive expansion schedule (well, except for the previous revision of BIP101 that advocated 20 MB + 2 yearly doublings). Not my definition of kicking the can, you need to be able to find the can when it's the right time to pick it up again....

Earlier in draft (before becoming a BIP) it was 20 MB + 50%/year (125% per two years).

I would happily support a similar proposal with different parameters if the parameters were well-justified and it grew to have more support than BIP101.

One idea: Is it possible to set up (or does there exist) a platform allowing people to bet on the state of technology 20 years from now?  If there were a lot of money in the pot predicting slower growth than BIP101 needs then you could make a strong case for a more conservative proposal.

[jonald_fyookball]

Every system has operational parameters.  The 1MB block size is not an 'artificial cap' any more than a 32-bit integer in a compiler is.  It is a design decision which makes a system work in a certain way.  The 1MB block size like any other such parameter has both pros and cons.  The 21x10^6 money supply is another such parameter and it likewise has certain pros and certain cons depending on one's taste.

artificial is a meaningless adjective but a cap is exactly what it is.

Each parameter in a system has a certain meaning based on its function. 
Yes it may have pros and cons, but it is a cap.  That's what it does by its very nature.

[_smudger_]

I like BIP1xx but don't think we should double or half the blocksize in one go. Maybe consider plus or minus 20% in one go so there is not so much of a sudden change.

[Carlton Banks]

I would happily support a similar proposal with different parameters if the parameters were well-justified and it grew to have more support than BIP101.

That's not going to be difficult, lol, what support

One idea: Is it possible to set up (or does there exist) a platform allowing people to bet on the state of technology 20 years from now?  If there were a lot of money in the pot predicting slower growth than BIP101 needs then you could make a strong case for a more conservative proposal.

Why not adjust to demand algorithmically at any given time? Trying to predict demand or supply of network resources, decades into the future, is not a sensible approach at all.

If at any stage the blocksize is too much, the fee market is dead, and mining begins to looks unviable without an effective subsidy. Another blocksize change fork (+ debate)? Great.

If at any stage the blocksize is too little, the fee market could becomes so expensive that everyday transactions are priced out. Another blocksize change fork (+ debate)? Great.

If the average blocksize tracks the BIP101 increase schedule very closely, everything will be OK. How likely is this outcome!



I don't support any of the other static limits for the same broad reasons, it's just that under BIP101, "too big for viable mining" is eminently more likely than under any other proposal. It just cannot be portrayed as the "conservative" solution, it's radical, and in completely the wrong way.

[dothebeats]

I'm pretty sure that if we keep this up we will never reach an agreement. Why not just somehow ...

We are never going to reach an agreement.  The sides are way to far apart.

Just do XT/BIP101 and fork the thing.  If people want to try a dynamic adjustment and cannot meet eye-to-eye with the Hearnian people or small-blockists, fork three ways.  Then each side goes on their merry way and makes the best of the basic strategy they've chosen.

It's not even relevant to say 'let the best man win.'  There are advantages and disadvantages to each strategy.  Forking the blockchain is the best way to realize the advantages of each.

I firmly believe that this strategy is the best way to move Satoshi's ideas (whatever they may be) forward, and while there might be some argument that it would damage certain things about Bitcoin they are philosophically fairly weak and the damage being done by trying to make dogs and cats live together in harmony will be far worse.

With this kind of approach, bitcoin will be doomed. The economy wouldn't be able to decide which is which. You can't go your 'merry way' if you choose between the three different bitcoins because it will only confuse those who are in business and those who uses the coins. This is not your common trial-and-error math problem that you will first try out different methods before coming up with the best result. $3 billion dollars is at stake here, you can just play with that by forking it in three ways.