Why I support Jeff's BIP100

[jonny1000]

Balanced compromise
Rational miners will vote to maximise their revenue.  When the block reward is low, this can be calculated from the following equation.
Mining revenue = the economic value of network security = bitcoin fx rate * transaction volume * average fee

BIP100 is a balanced, dynamic and market driven compromise, which maximises the product of these three important metrics. Many people are arguing about the relative importance of these three metrics, BIP100 could be the long term solution we are after.

Reacting to demand
BIP100 does reflect adoption/demand. If demand increases the price elasticity of demand may fall, therefore miners may vote to increase the limit. Miners vote to maximise their revenue and they therefore need to evaluate the price elasticity of demand when they vote.  BIP100 enables capacity to adjust to meet demand.  Over time miners will become better at voting.  This method is better than estimating what demand will look like now for the next 20+ years, which is very difficult for anybody to do.

Why can't miners apply their own voluntary size limit?
For example, a miner may prefer smaller blocks so that fees are higher. i.e. the miner thinks the negative impact from a reduction in volume would be smaller than the positive impact of a fee increase from the smaller blocks. Therefore the miner wants smaller blocks.

However, the miner could make a large block anyway to benefit from larger fees in the short term, from that block, in the hope other miners make smaller blocks. This plan will fail because each miner will also operate in their own selfish interest and make larger blocks. Fees then downwardly spiral to zero and network security falls.

This is happening in the oil market right now, loss making oil companies are pumping more and more oil to get cash in the short term and the oil price keeps falling. Oil firms then get more desperate for short term cash. Each oil company hopes other firms will reduce production so the price increases, but the nash equilibrium is for each oil producer to keep pumping. We must not allow this race to the bottom to occur in bitcoin mining. Lets learn the lesson from oil production and the mining of other commodities.

For oil of course this does not matter, eventually oil firms go bankrupt and shut down, then supply falls and the oil price rises. This correction can not occur in bitcoin because supply does not correct. Bitcoin miners keep the network secure, they do not supply capacity. One remaining miner can provide all the capacity we need, but not the security. Due to this imbalance, a blocksize limit is required.

If the above is true, why fees are not zero now, despite blocks not being full?.
It is for the following four reasons:

• Orphan risk costs are high, however in the long term these may fall due to bandwidth improvements and other technology like IBLT.
• Mining is not competitive enough. There are currently a few large pools, however if Bitcoin is to succeed in the long term, there needs to be many miners and a high level of competition.
• Miners are not mature businesses yet. Miners are often pro bitcoin people or bitcoin speculators, miners often care about the health of bitcoin. In the long term they may be more focused on margins and profit.
• The block reward is high, therefore miners don't worry much about fee income as it is small relative to revenue. The block reward will fall in the long term and miners will therefore focus on maximising fee income.

Is BIP100 like a price cartel?
Yes, BIP100 is like a cartel for price fixing in some ways. What BIP100 does is allow the price to be fixed as if a cartel like structure existed, but actually have many competing miners. This is why BIP100 is quite clever. It is ironic like Bitcoin in a way. Bitcoin is about achieving abosolute order, while at the time ensuring everyone has freedom to do what they want. BIP100 has cartel like pricing, but with many members who have freedom to do what they want.

Without BIP100, the only way for price fixing to occur is if there was a very small group of miners who controlled the network. BIP100 would not be needed then and the price would be fixed. Without BIP100, if there were too many miners the cartel would fall apart, as members would defect from the cartel.

BIP100 kind of provides a framework for a cartel like structure to apply, but with many competing members. As Meni pointed out when BIP100 was released, under many assumptions as to what Bitcoin is for, this may mean volumes are too low or suboptimal. I still think BIP100 is the best proposal out there, although its far from perfect or even complete.

List of points requiring further clarification
1. What voting options will be available?  e.g. choices between -50%, -10%, -5%, 0%, +10%, +50% and +100%?
2. Will the miner vote for the size limit be rolling or happen every set number of blocks?
3. Over how many blocks will the miner vote occur?
4. Will there be a lower bound 1MB cap on the size limit?
5. How will voting take place? Is it the lowest 20% + 1 for an increase and the lowest 80% - 1 for a decrease?

[HostFat]

As I said elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.

The market needs fixed rules that they must know years before.

The majority of the businesses will just move elsewhere.

[entertainment]

As I sait elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.

The market needs fixed rules that it must know years before.

The majority of the businesses will just move elsewhere.

Exactly. Unpredictability is a very bad feature for a coin.

[DooMAD]

BIP100 doesn't sit well with me, seems to grant far too much power to miners.  Would much rather see this proposal instead.  It's adaptive, so the blocksize can increase or decrease as required, based on what the network is actually using.

[RocketSingh]

As I sait elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.

The market needs fixed rules that it must know years before.

The majority of the businesses will just move elsewhere.

Exactly. Unpredictability is a very bad feature for a coin.

Difficulty is unpredictable as well. That is not the problem. The problem is miners (effectively pool operators) are getting super power in block size decision, irrespective of Tx volume in mempool, which represents market demand.

BIP100 doesn't sit well with me, seems to grant far too much power to miners.  Would much rather see this proposal instead.  It's adaptive, so the blocksize can increase or decrease as required, based on what the network is actually using.

Exactly. My vote goes for this proposal as well. But, it seems core devs are intentionally ignoring it to provide any BIP no.

[HostFat]

Difficulty is unpredictable as well

But it just affect the business of the miners and not anyone else.

The block size instead change fees and confirmation time.
Both directly influence deeply the day by day decisions of the Businesses on the Bitcoin network.

[jl2012]

Difficulty is unpredictable as well

But it just affect the business of the miners and not anyone else.

The block size instead change fees and confirmation time.
Both directly influence deeply the day by day decisions of the Businesses on the Bitcoin network.

As you can see there are so many small or empty blocks on the blockchain, the effective block size is already unpredictable. Miners could always limit the block size, by a soft limit or even a soft fork.

Even with Gavin's BIP101, miners will not mine a full block if the fee could not cover the risk of block orphaning. If businesses want a bigger block, they should pay more fee and rational miners will increase the block size to collect the fee. There is no free lunch

[HostFat]

Forcing "a limit" by votes takes away the total competition between miners.
If a miner want to limit his own block, that's ok, but he know that there are others than can give more space on their block.

This is also the reasons that I think that an unlimited size will be a better solution, where nodes give like more priority to smaller blocks.


https://groups.google.com/d/msg/bitcoin-xt/oFmzqn46v74/B1CKY7bNBgAJ

BIP 100 isn't currently implemented. I guess we'd put together some more concrete thoughts if and when it is coded up.

My initial thoughts are that I prefer BIP 101 because:
The BIP 100 voting mechanism doesn't seem fully thought out. A majority of miners can always win any vote because they can just orphan blocks that contain votes for something they don't like. So the more complex approach doesn't seem really robust.

But that'd require special code. If most miners just adopt the defaults, then it's possible for a minority of hash power to drag the block size down to nearly nothing.

It's quite common for miners to just accept whatever the defaults are, regardless of whether they make sense. That's why we still see 750kb blocks sometimes when the network is actually backlogged (XT fixes this).

I think the reason is that miners, not unreasonable, assume the Bitcoin Core developers are selecting default behaviour in sensible ways. Alas it's not the case anymore, because they feel choosing opinionated defaults is "centralising". This is why the XT manifesto specifically states we will pick defaults as we think best.

The BIP100 default is 1 megabyte. Thus by default miners would be voting for no change. However what we need is change!

It gives miners additional power to modify the system for no obviously good reason beyond "some miners are saying they'd like more power". Miners are not the only stakeholders. Users, merchants, exchanges, etc matter too - if not more!

The upper limit is meant to be a kind of DoS limit, to stop troll miners generating giant mega-blocks. It's not meant to be a stick that miners can use to beat important but voteless economic players.

There's a risk that someone comes up with a business plan like this:   we will build a giant ASIC farm in the middle of a desert at the end of a piece of string and tin can (i.e. no bandwidth). This will be super cheap because of abundant land/solar/wind/whatever and the lack of bandwidth won't matter because we can just drag down the block size limit to ensure tiny blocks.

This would of course hurt the entire ecosystem for their own short term benefit, but BIP 100 would let them do that with just a small amount of the overall hash power.

Miners have just one job: order transactions by time. They shouldn't be doing anything else, and arguably, people already freak out about the concentration of power in the hands of big mining pools. BIP 100 would make this issue worse.

[RocketSingh]

Difficulty is unpredictable as well

But it just affect the business of the miners and not anyone else.

The block size instead change fees and confirmation time.
Both directly influence deeply the day by day decisions of the Businesses on the Bitcoin network.

Difficulty does not affect fees, but definitely affect confirmation time. Every 2016 blocks it re-adjust itself to keep the average to 10 minutes. This is similar to what proposed in this proposal to adjust maximum block size cap.

[jl2012]

Forcing "a limit" by votes takes away the total competition between miners.
If a miner want to limit his own block, that's ok, but he know that there are others than can give more space on their block.

51% of miners can always limit the blocksize of the other 49% through a 51% attack. This is an inherent problem of mining

[HostFat]

51% of miners can always limit the blocksize of the other 49% through a 51% attack. This is an inherent problem of mining

This is true, but it costs to them a lot to maintain this situation, even be in agreement all the time.
A vote instead cost like nothing.

[jonny1000]

As I sait elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.

The market needs fixed rules that it must know years before.

The majority of the businesses will just move elsewhere.

Exactly. Unpredictability is a very bad feature for a coin.

If you think the size limit is not important, then it does not matter if its unpredictable.

I think the size limit is economically important and there are risks of the limit being too small or too big.  There is no point having a high level of predictability about any block size limit that happens to have been picked years in advance, what is important is that the limit is appropriate for the level of demand.

[teukon]

Balanced compromise
Rational miners will vote to maximise their revenue.  When the block reward is low, this can be calculated from the following equation.
Mining revenue = the economic value of network security = bitcoin fx rate * transaction volume * average fee

I don't find this convincing.  A miner is driven to maximise the value of the network (considering both the short and long term) but also to drive other miners away, lowering difficulty.  Might it be that BIP100 conceals a tragedy of the commons: miners each vote in a way that inadvertently hurts decentralisation despite their wanting to maintain decentalisation.

Reacting to demand
BIP100 does reflect adoption/demand. If demand increases the price elasticity of demand may fall, therefore miners may vote to increase the limit. Miners vote to maximise their revenue and they therefore need to evaluate the price elasticity of demand when they vote.  BIP100 enables capacity to adjust to meet demand.  Over time miners will become better at voting.  This method is better than estimating what demand will look like now for the next 20+ years, which is very difficult for anybody to do.

This is completely backwards.  Block size reflects demand, the block size limit relates to supply.  If, for example, the world wants 1000 Bitcoin transactions per second but technology is such that, in a well-decentralised network, it is not possible to provide more than 50 transactions per second, then the block size limit should hold us to 50 transactions per second.

4. Will there be a lower bound 1MB cap on the size limit?

More critical would be an upper bound.  I would be more comfortable with BIP 100 if it had BIP 101 as an upper bound.

[-ck]

4. Will there be a lower bound 1MB cap on the size limit?

More critical would be an upper bound.  I would be more comfortable with BIP 100 if it had BIP 101 as an upper bound.

In its current incarnation, BIP100 has a lower bound of 1MB and an upper bound of 32MB.

[99Percent]

I initially thought BIP100 was pretty good too but now after some serious thought I am convinced miners will ALWAYS vote for bigger blocks. It simply gives them more flexibility. They can always soft limit whenever they want.

So once BIP100 is hard coded, miners will continually push and vote for bigger blocks.

I think the real limitation resides in the ability of nodes to relay blocks. Excessively large blocks affects the bitcoin network when nodes aren't up to par (obviously).

Therefore I am tending  to believe that any hard fork will have to deal with verifying transactions in the block that were actually in the mempool and not able to be fabricated by the miner when consolidating his block (or "vote" for larger size).  Is that even possible?

[teukon]

4. Will there be a lower bound 1MB cap on the size limit?

More critical would be an upper bound.  I would be more comfortable with BIP 100 if it had BIP 101 as an upper bound.

In its current incarnation, BIP100 has a lower bound of 1MB and an upper bound of 32MB.

Ha, somehow I skim-read point 4 as something like "The historical 32MB limit is removed".  Thanks.

Still, I believe constant 32 MiB for all time is a far poorer estimation of future potential network capacity than is BIP 101.  All else equal, I'd prefer to see the frequency of these hard-fork crises minimised.

[-ck]

Still, I believe constant 32 MiB for all time is a far poorer estimation of future potential network capacity than is BIP 101.  All else equal, I'd prefer to see the frequency of these hard-fork crises minimised.

At the speed of growth of transactions in bitcoin, 32MB will likely mean we won't have to revisit a hard fork for block size for another decade at least. With possible side chain and who knows what other development in that time, it isn't really clear that we'll need to go beyond that or not but being conservative on that front means we are not committed to allowing gigabyte sized blocks. There's nothing wrong with revisiting it again 10 years from now if we end up just putting everything into the same blockchain in the same current format.

[teukon]

Still, I believe constant 32 MiB for all time is a far poorer estimation of future potential network capacity than is BIP 101.  All else equal, I'd prefer to see the frequency of these hard-fork crises minimised.

At the speed of growth of transactions in bitcoin, 32MB will likely mean we won't have to revisit a hard fork for block size for another decade at least. With possible side chain and who knows what other development in that time, it isn't really clear that we'll need to go beyond that or not but being conservative on that front means we are not committed to allowing gigabyte sized blocks. There's nothing wrong with revisiting it again 10 years from now if we end up just putting everything into the same blockchain in the same current format.

As with most of the proposal disagreements, it seems we're simply making different judgments on the various unknowns and risk factors involved.  I still judge BIP101 to be sufficiently conservative*.  I don't think the extra conservative 32MB limit is worth the cost of needing to revisit the issue sooner.  If we're forced to kick the can down the road then I hope we kick the can good and far to reduce the risk of future bitcoiners forming a committee to make these decisions.

I dislike this idea of "need to go beyond" as it grazes "640K ought to be enough for anyone".

*Note: I may be biased because I was instrumental in defining the double once every two years growth rate of BIP101.  I'm no expert and am open to being swayed to other parameters (e.g. sipa's proposal).

[Nicolas Dorier]

As I said elsewhere, BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.

The market needs fixed rules that they must know years before.

The majority of the businesses will just move elsewhere.

Be specific, what is unpredictable ? Because if you talk about the blocksize, then BIP101 is way more unpredictable.
As you can know what blocksize limit would be in the next minutes with BIP100, you can't say as much with BIP101.

Fastforward 29/08/2020, BIP101 passed, you reach say 1GB limit, what size will be the next block ? Response : Between 32 bytes and 1GB.

So what unpredictability are you talking about, be more specific.

[-ck]

As with most of the proposal disagreements, it seems we're simply making different judgments on the various unknowns and risk factors involved.  I still judge BIP101 to be sufficiently conservative*.  I don't think the extra conservative 32MB limit is worth the cost of needing to revisit the issue sooner.  If we're forced to kick the can down the road then I hope we kick the can good and far to reduce the risk of future bitcoiners forming a committee to make these decisions.

I dislike this idea of "need to go beyond" as it grazes "640K ought to be enough for anyone".

This is hardly comparable to 640k. Should 32MB not suffice, it is revisited... once we've tested the ground up to 32MB without problems, I don't think there'd be much opposition in a decade to push it higher again if it is needed. Note that even in its current only implemented form, BP101 may well push to 8GB maximum but in actual fact the only implementations of it are still limited to 32MB in the client, so another hard fork would be required even for that... That was wrong.