Bitcoin Forum

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?

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.

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

BIP100 doesn't sit well with me, seems to grant far too much power to miners.  Would much rather see this proposal (https://bitcointalk.org/index.php?topic=1154536.0) instead.  It's adaptive, so the blocksize can increase or decrease as required, based on what the network is actually using.

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.


Exactly. My vote goes for this proposal (https://bitcointalk.org/index.php?topic=1154536.0) as well. But, it seems core devs are intentionally ignoring it to provide any BIP no.

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

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

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 (https://bitcointalk.org/index.php?topic=1154536.0) to adjust maximum block size cap.

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.

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.

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.


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.


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.

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?

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.

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 (https://bitcointalk.org/index.php?topic=813324.msg9135332#msg9135332) growth rate of BIP101.  I'm no expert and am open to being swayed to other parameters (e.g. sipa's proposal (https://gist.github.com/sipa/c65665fc360ca7a176a6)).

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.

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.

BIP100 cut the competition between miners, so even if there are some miners that are able to spread blocks with higher size and faster, they will not be able to, because a cartel between miners, without risking so much, just a vote for a smaller size.

With BIP101 businesses will know that at a certain time they can be sure that there is a space to have blocks of certain size.
They will need for sure to know day by day which is the average size of the blocks, but they know that if there is the demand, some miners can still try to cover it.

With BIP100, nothing is certain, every 3 month the size can go UP or DOWN (worst case)
So it is totally impossible to make any little plan for the future.

Are you sure?
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/

Nope, in which case I take that part back.

It is true miners may also want to drive other miners away and lower difficulty, however there is no clear voting method in BIP100 which achieves this, in my view.  I can think of three strategies which could attempt to do this:
1. A large well connected miner voting for larger blocks, such that smaller miners cannot compete with propagation.  Response - The upper bound in BIP100 should defend against this.
2. A miner with large cash reserves votes for smaller blocks, the plan is to limit bitcoin capacity and then reduce utility and therefore the exchange rate.  Other miners without cash reserves then exit the industry and the miner with large cash reserves take short term losses before voting to increase the limit again. Response - This attack seems extremely unlikely and a long enough voting period makes this unfeasible.
3. The reverse of 2, voting to increase the limit to drive down fees and force other miners to exit the industry.

If you have another voting strategy which could drive down the difficulty, please let me know.  In my view a long enough voting period will make these strategies unfeasible.



The reasoning in my comments are mostly about economics and incentives, not technical limits.  BIP100 should have an upper bound, which reflects technical considerations like propagation time, storage costs ect



I agree an upper bound may be required for technical reasons.  The points I made above are mostly the economic reasons for BIP100.  The current 32MB limit would be fine, although I would be happy to compromise and have BIP101 as the upper bound, if this ensures BIP100 gets more support.



I don't think this is right.  Miners may vote for smaller blocks to prevent other miners making larger blocks.  Sure each miner has the flexibility to soft limit down their own blocks, but they can't force others to do so.  Understanding BIP100 is about evaluating the incentive differences between all the miners and each specific miner.

Thanks for the detailed response.

I wasn't so concerned with "voting strategies" as with the disconnect between miners voting to maximise profit (both short and long term) and miners voting for a good balance between capacity and decentralisation.  Without data I cannot tell how miners might vote but, assuming transaction volume/fee concerns are relatively small, I'd imagine that each miner would like the block size limit to be as large as they could manage.  If this persisted then, every three months, the block size limit would be raised so that the 20% least capable miners were driven out of the market, increasing revenues for the remaining 80%.

I'm not so worried about a minority of miners attacking the system (the long time periods and quintiles take care of that) but of a tragedy of the commons that could cause the block size limit to spiral out of control even assuming each miner is well-meaning.


Right, I think I'm with you.  I've been operating under the assumption that the block size limit management of BIP100 is intended to tackle the capacity-decentralisation trade-off.  I find it questionable in this regard.

However, if the focus is more about creating a fee market, allowing miners to co-ordinate a way to maximise revenue, then it seems far more interesting.  In this case, I have to admit that the incentives of the miners seem well aligned to this end.  I'm not yet sure that maximising the real value of transaction fees with time is necessarily good or that this mechanism can afford a robust market for network security but both seem plausible.

With a more thoughtfully set ceiling, I see no clear reason to reject BIP 100.

What is a more thoughtfully set ceiling to the proposed one of 32MB?

we still have numbers of XT node users, as this granted, most of the people only with the XT node wallet (or BIP100) would not be able to afford those storage as the limit grows.

BIP 101 (https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki), Block size following technological growth (https://gist.github.com/sipa/c65665fc360ca7a176a6), and arguably 8MB.  Far from being thoughtfully set, the 32 MiB ceiling of BIP 100 is just an old limit revealed.

I should say that even with such a change I wouldn't be a supporter of BIP 100.  It's just that my main concern with BIP 100 evaporates if the limit is confined to a safe range.

You just said you're for BIP 100. With that comment I can't tell if you're for BIP 100 or 101. What do you mean a safe range? BIP 100 with an 8GB limit in 2016 is open to abuse immediately, yet 101 eventually goes up to 101 in decades only. 32MB is what I would call "confined to a safe range". Your comment says "no clear reason to reject BIP 100", but I really don't know what you're supporting with your follow up comment.

I said I could see no clear reason to reject BIP 100.  I've never claimed to support it.  I realised my earlier comment might be misleading (I meant it literally) so I thought I'd clarify my position.  I found jonny1000's comments interesting because it highlighted that perhaps BIP 100 and BIP 101 were really doing different things.


Is there some mechanism in BIP 100 that prevents us from reaching a block size limit of 32 MiB within a few years?  I don't see why miners voting to maximise their profits would keep growth slow, especially not if there is a large uptick in adoption.


Right now I support BIP 101 (and have done since it was drafted).  My preferences at the moment (not that they matter much):
BIP 101 > sipa's proposal > Straight jump to 8MB > BIP 100 + BIP 101 > Straight jump to 32 MiB > BIP 100 > Do nothing.

I consider BIP 100 better than doing nothing (don't see how it hurts Bitcoin).  I do not support it because I think there are many better alternatives.

This is a good point, the reason to vote for a lower limit in BIP100 only really comes into play once the block reward is low.  Therefore we need to be careful in the early years that the size limit does not get too large.  Therefore I agree BIP100 with BIP101 as an upper bound may be a better idea than allowing 32MB too quickly.

For what it is worth, here are my order preferences:

BIP100 with BIP101 as the upper bound > BIP100 > Sipa proposal > One off shift to 8MB > Do Nothing > BIP101

Interesting.  So it seems that you're particularly wary of the proposals which speculate long-term exponential growth of resources like bandwidth.  I certainly understand that, it's a huge drawback to BIP 101 no question.

For myself, as much as I am uncertain about future bandwidth growth, I am fairly certain that the bitcoiners of 2025 (if there are any) will be less interested in decentralisation than we are today and far more amenable to the formation of a special organisation to manage the protocol.

Just out of curiosity, how would you feel about BIP100 + Sipa's proposal?

Yes, in particular I don't like speculating about demand for the next 20 years (as well as bandwidth).


I would be happy to support BIP100 with Sipa's proposal as a lower bound and BIP101 as the upper bound.  In the long run it could be better if we remove the BIP100 "stabilizers", of both the upper and lower bound, once we can rely more on the voting mechanism.

The way I see it:

• BIP100 measures demand
• BIP101 speculates supply

I believe both have problems and that we'd ideally like something which measures supply.

The political philosopher in me doubts that Bitcoin will remain sound in the long term if it regularly requires protocol updates to correct past speculation (Official Bitcoin protocol organisation).  The economist in me doubts that Bitcoin will remain sound if the artificial capacity limits are driven by demand (miner centralisation).


Interesting idea to grow both bounds.  I must admit I've not been paying much attention to the lower 1MB bound.  I guess there's a potential 21% attack that a growing lower bound could help mitigate.

In the long run I don't think the upper bound can be safely removed without significantly changing the algorithm.

As demand increases, there will be pressure to increase the limit (to increase supply).  So long as miners can cope with the increased demand they have an incentive to vote to raise the limit for greater profits.  This is all well and good; we want these free-market efficiencies.

However, the algorithm itself pays no attention to the level of decentralisation.  From BIP100:
So if 80% of the mining network wants to meet increased demand by supplying larger blocks and 20% of the mining network wouldn't be able to cope with the increased demand then this 20% will be driven out of mining.  We'd be slowly boiling a frog.

There is no such problem. Miners voting at the bottom end will simply have their votes ignored. It has zero effect on their ability to keep mining.

Part of a miner's costs is in maintaining a full node.  With more transactions, these costs increase.  If a miner cannot make enough profit to cover its costs it must go out of business.

It is very possible for a block size limit increase under this scheme to push miners at the bottom end out of business.

Again there is no such problem. I suspect you're unaware of what the mining scene is today. Virtually no miner mines for himself with his own node any more. All the mining nodes are at the pool end and pools will in no way have any difficulty storing large block sizes.

Local node sizes will only affect regular node users who choose to stick with bitcoin core or a full blockchain application as their wallet - miners will be unaffected.

I'm aware of pools.  I've had plenty of experience both mining solo and mining as part of a pool.

Perhaps you missed that I was responding to jonny1000's notion of eventually removing BIP100s stabilizers (the 1MB and 32MiB limits).  No matter how big the pool, there is a limit to its resources.  1MB blocks may be trivial, but 1GB blocks wouldn't be, and 1TB blocks would be out of the question today even the largest miner.

So there is not problem to take away any kind of limit :)
None is going to use 1TB blocks (and not even 1GB now)

Not now.  Of course BIP100 won't lead to instant disaster.  Even with no block size limit we'll not see a 1GB block anytime soon.  I argue simply that without a ceiling BIP100 will tend to miner centralisation in the long-term.

Without the 32MiB limit, I would expect a BIP100 limit to grow more quickly than a BIP101 limit (even were they both set to start at 8MB).

Lots of crosstalk then in this discussion, but I'd be very happy if bitcoin became so popular that we had 1GB of transactions regularly... Not sure where we'd find 1TB of transactions in a year let alone every 10 minutes, real or spammed.

Yeah, I feel I could have been clearer.  Sorry if I mislead anyone.

I can't imagine demand for 1TBs worth of block space every 10 minutes but I believe that if we had the resources to provide this at very low prices that people will find a use for the space.

We are talking about how miners should set supply, we do not need to measure supply to do this.  What we need to measure is the price elasticity of demand and then set supply accordingly.  BIP100 encourages miners to do this, at first they may be poor at doing so, but over time miners will improve.



Miners may also have an incentive to vote for a lower limit, probably not in the first few years, but once the block reward is low they may vote to maximize revenue.  This would happen depending on what miners think about the price elasticity of demand.  Basically it depends on the demand curve, if reducing supply from S1 to S2 increases the price from P1 to P2, such that S1 * P1 < S2 * P2, miners should vote for a lower limit.

Illustrative demand curve with supply limit
https://i.imgur.com/MVnY4H2.png
Notes: Where the yellow and blue line cross is the equilibrium price, miner revenue is the area formed by a rectangle between this point and the point 0,0.  Miners can vote to lower the limit, if the demand curve is steep enough then revenue will increase when the limit falls.

You can reverse the argument with BIP101.

"BIP101 cut the competition between miners, so if there are some miners that are not able to spread blocks with higher size and faster, they will be obliged to, because a cartel between miners, without risking so much, just push bigger blocks"


Isn't it also the case with BIP100 ? if there is demand, miners will try to cover it thus increasing the size.


Even with BIP101 you can't be certain that miner will not adopt a small limit instead of a bigger one, so it change nothing.

The only valable argument I think of for BIP101 is about short term peak demand that BIP100 can't adapt for quickly. But this is an exceptional case.

What if the price elasticity of demand asks for a very high supply (i.e. Bitcoin takes off in a big way).  Will a miner vote for a block size limit that he himself does not have the resources to handle?

It seems like the BIP100 algorithm is trying to set a kind of "ideal supply" that would work well for the current demand.  What if we don't have enough resources to supply the "ideal supply"?


I agree (and this is a cool corollary of BIP100).  But notice that miner's are voting for lower block limits because demand is low.  What happens when these entrepreneurial miners correctly estimate that S * P is maximised at a point where S is very large?

BIP100 is likely to result in blocksize increases quite quickly at first, because when the block reward is high as there is little reason to vote for a lower limit, this should make it similar to BIP101 in the early years.

As time progresses and the block reward falls, if the network is fee driven it is likely to be able to handle short term demand variations much better, for various market driven reasons.  BIP100 can handle longer term variations.

For example if demand is high during peak shopping hours in the US, or at Christmas, the mining industry can allocate more power to mining and find blocks faster.  This is similar to how the national grid operates at the moment.  In the UK, when the national football team play an important match, at half time millions of national grid users make tea.  This causes a surge in power demand, however electricity producers predicted this in advance and respond by producing more energy.  Large amount of potential energy stored up in hydro facilities can be realized in one go, so the UK population can make their tea (http://news.bbc.co.uk/1/hi/uk/5059904.stm).  Bitcoin miners could also respond to demand surges and release large amounts of energy to increase their hash-power, temporarily producing faster blocks.

If we do not allow a fee market to exist, amazing features like this may not occur.

No it's different, no miner is obliged to use bigger blocks, neither BIP100 or BIP101.
The miner can always chose to make smaller blocks than the actual version of the protocol can support.
It is NOT true the opposite.

The BIP100 can cut the possibility of some good miners to spread bigger blocks if the network can support them, because a minirity/cartel has chosen to.

This is an assumption.

This is true, but still there will be the space that someone can try to cover, with BIP100 it is NOT, the BIP100 can cut this possibility, because it opens an easy way to make cartels of miners.

BIP100 can increse the block size in 12 months to 32MB, by doubling it every 3 months, still it can cut the size, and this is the real problem.

Have you checked BIP 1xx (https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki) ?

Yes, under BIP100 the blocksize limit could be very large if demand is large.  With respect to resources an upper bound could be in place for technical reasons.

Many BIP101 proponents make comments like "In 20 years your watch will be able to download the whole blockchain in seconds".  I have no idea if this is correct, if it is then maybe the technical limitations may become insifgnificant in relation to the market driven blocksize under BIP100.  This is why I think the stabilizers (on both sides) could be removed in the future.

Exactly.  BIP100 can handle demand spikes as well as any other block size limit method (except arguably Meni's (https://bitcointalk.org/index.php?topic=1078521.0)).  BIP101 has no principle advantage here.


While a fee-market focused limit might make reserve hashing power more commonplace, I fail to see why this in itself is a good thing.  Certainly, it is better to counter a surge with fast blocks than to not counter it at all.  Better still though would be to mitigate the surge by just having bigger blocks to begin with.  This way, people get their transactions confirmed even more quickly, and for a lower fee!

In a BIP101 universe, surges could be handled in the same way.

The small miners can get kicked out of the market by a single or minority of miner which made a huge big blocks.
Also, BIP100 does not prevent a small miner to make a small block either, it only limit how a single miner can kick with big blocks.

Isn't your's also ?

If there is one or zero does not change a lot since only the average size count.

I don't get why you are so sure BIP100 allows cartel while 101 does not. It is actually the reverse with big blocks a big miners can kick the small one out of the market.

Yes, this is roughly what I'm arguing.  Growth is great but if we run into a problem with real resources then we'll need some kind of upper bound (or else mining centralisation).  So long as real supply is much larger than the "ideal supply" being calculated by BIP100 then things should work just fine.


Wow, sounds pretty wild.

My intuition is the other way around.  I expect humanity will demonstrate an apparently insatiable appetite for blockspace, just as it has for storage and bandwidth.  I myself could use 50 GB of blockspace were the price low enough.

I could be wrong.  It might be that block space becomes so vast and cheap that human desire simply can't keep up.  Block space would be as plentiful as air.  In this world, BIP100 would work fine but I'd still question the point of it.  Why, for example, would we want to artificially restrict the atmosphere to create an air market?  All I can think of is that without a fee market, transaction fees would tend to the largest miner's transaction-processing costs and the network security afforded by the fees would tend to zero.

This is a good point and I kind of agree with you, although supporters of BIP101 seem to disagree with this.  BIP101 supportrs typically think blocks may not be full.  This is why I advocate a lower and upper bound in BIP100 for now.  My point is that what if there is a stable optimal economic limit under BIP100, based on miner expectations of demand curves, that is much lower than the limit when bandwidth and other constraints begin to come into play?  This could happen, as although there could be an "insatiable appetite for blockspace", users may not be willing to bid a high enough fee.  Therefore miners vote for a lower limit than the elastic demand not supported by strong fee bids.

Lets consider a hypothetical scenario in 2035:
Size limit based on BIP100 voting: 2GB
Upper bound in the protocol: 8GB
Technical limitations, based on broadband speed and storage costs, ect, in 2035: 5TB

If we experience the above scenario for many years, we may decide we no longer need the upper and lower bounds, as we have high confidence in the voting process and high confidence the optimal miner voting strategy will not bring the limit near what can safely technically be done.

Ok, let's see if I understand.

In this scenario, without the 2GB limit, blocks would not generally fill up.  This is not necessarily because no-one can think of any more uses for the space, but because the costs of relaying, processing, and storing any further transactions outweigh the benefits of using the space.  (I'll note that if this is true, we're probably operating under a different idea of "technical limitation").

With the 2GB limit in place, the total transaction volume is reduced but the total value of all transactions actually increases (following the S * P logic from earlier).

If this persisted for decades (as you suggest above 2 decades to 2035 + still more years of the same) I agree that it begins to look pretty safe to remove the 8GB limit.  In this case, I will have been practically proven wrong about my concerns.

Question: Why not remove both the 2GB limit and the 8GB limit?  With both limits gone, mankind will enjoy more transactions and lower fees.  Why should we prefer fewer transactions, higher fees, and a more complex protocol?

This is not true no.  In my hypothetical scenario the costs of relaying, processing, and storing any further transactions are very low.  "Technically" the limit could be increased to 5TB and there would be no propagation or storage issues.  Because by 2035 my hypothetical smart watch has a 20TB/s connection and 500EB SSD or whatever.  The 2GB limit is imposed by a miner vote under BIP100 to maximize mining revenue.


I think we may not need the 8GB upper bound limit in this scenario, but we still need the 2GB BIP100 voting limit.  The 2GB is imposed by miners to ensure fees are higher enough.  

Example Continued - The year is 2035

• 2GB BIP100 block limit
• All blocks are full
• $0.01 average fee

Miners then vote under BIP100 to increase the limit to 8GB, the situation changes to the following:

• 8GB BIP100 block limit
• All blocks are full
• $0.0001 average fee

Transaction volume is up, and users have more utility, but users are only prepared to pay $0.0001 per transaction, so the economic utility of these extra transactions for the users are low.  Mining revenue and therefore security has fallen by 25x (excluding the block reward).  This is why we prefer fewer transactions and lower fees, despite the fact "technically" the network could handle more.  Under BIP100 it is up to the miners to decide, in this scenario miners may think they have increased the limit too much and try to lower it again to increase average fees.  Remember more economic utility for users means the Bitcoin exchange rate may be higher, which would drive up mining revenue.  This would also be considered by miners when voting.

The above describes why BIP100 so brilliant.  Miners consider the economic utility of the transactions, to the user, by considering the fee the user will pay.  BIP100 may restrict the volume to a lower level than could technically be achieved, however this is done in a balanced way reflecting the impact on the bitcoin price and the utility users would get from these extra transactions.

Ok, my misunderstanding.

(emphasis mine)

Nice clear example.  I agree.  A fee market may cause profit-seeking miners to increase network security.

That said, I don't find network security to be a particularly compelling reason for having a fee market.  There seems to be practically no connection between a miner's incentives regarding voting and true demand for network security.  I could easily imagine this method yielding far too little security or far too much.  I believe there are better solutions to the large-block low-fee tragedy of the commons problem.

If each of the variables:

• The optimal level of network security;
• The point of unit elasticity (where S * P is maximal);
• The artificial limit derived by BIP100, driven by all of a miner's incentives;
• The limit of what a well-decentralised network can supply,

happen to have a particular relationship with one another then I'm sure BIP100 will behave superbly (even in the long term and without limits).  It wouldn't surprise me to learn that there is some subtle robustness (mechanisms naturally drawing these quantities into a healthy relationship) given the technical brilliance of the people that helped created the proposal but it's also possible that BIP100 is built upon a certain amount of wishful thinking.  I've warmed to it slightly thanks to your efforts but I remain cautious.

I don't think this takes into consideration competition.  Transactors will simply move more and more off chain, even to altcoins, if fees are kept relatively high by low block size limits.  Because of this, tx fees alone will not provide enough security for the network.

Miners are driven to maximise the purchasing power of their income, not simply their nominal bitcoin income.  If most miners felt that a larger block size would yield greater real value then I don't see why they wouldn't vote for it.

Or, as jonny1000 noted:

I still can't see any reason to give miners the vote to lower the size.
BIP100 can be "considerable" only if the vote to lower the size isn't present.

One simple reason is that without this option miners may be too relucant to increase the limit, as the decision could not be reversed.

Another potential reason is a cyclical fall in demand for using bitcoin.

This is a good reason to not give them any possibility to vote.
Anyone of them can chose, individually, if they want to make blocks bigger or smaller.

This isn't a good reason, miners can always lower the size of their block, none is forced to make them bigger, neither with the BIP101.

Just to remember everyone, that the limit for the block was put on the protocol only to avoid DoS attack, blocks bigger than the network (nodes) can spread between them self.

Satoshi was probably worried because at the time a fund or a government was able to make a big pool full of GPU, without spending so much and making big blocks (32 MB) to DoS the network.

Your view appears to be that miners are not forced to make blocks bigger and therefore miners can make small blocks if they want anyway, so why have BIP100?  This is probably the consensus view in the community at the moment.  It could be correct, however I think it is likely to be wrong.

Each individual miner will try to maximize their own profit and share of revenue.  Miners will therefore be incentivized to sweep up as large a share of the transaction fees as they can.  In the example I made above, there is little downside in doing this as the level of technology could enable blocks far greater than the blocksize limit, due to  insignificant propagation costs.  The is just like the classic tragedy of the commons scenario, each individual miner produces larger blocks, in the hope that other miners produce smaller blocks, to maintain a reasonable average fee level.  However the Nash equilibrium ensures that each miner makes larger blocks.  Miners need to maximise their own profit to remain competitive and they would have little choice but to produce larger blocks.  Fee levels would then fall and the equilibrium difficulty would be too low.

The consensus response in the community is that this line of thought is too theoretical and has too much unproven game theory.  I disagree and think this is highly likely to be the outcome.  In fact this is the behavior that is currently occurring in the global commodity space, and has happened time and time again.  Each individual miner producers more and more resources, to maximise their own profit, in the hope that other producers reduce production to allow prices to increase.  Each individual miner acts against the interests of the whole industry and increases production.

Why can miners not voluntarily individually produce smaller blocks?  

This is the common question, but who is this question about, each individual miner or the whole mining industry?  I could ask the analogous questions:

• In 2015, why is Iran increasing oil production?  Can Iran not voluntarily individually produce less oil to support the price, as the industry is currently loss making?
• In 2015, why is BHP Billiton increasing iron ore production?   Can BHP Billiton not voluntarily individually  produce less iron ore to support the price, as the industry is currently loss making?
• In 2015, why is Goldcorp increasing gold production?   Can Goldcorp not voluntarily individually produce less  gold to support the price, as the industry is currently loss making?
• In 2015, why is Freeport-McMoRan increasing copper production?   Can Freeport-McMoRan not voluntarily individually produce less copper to support the price, as the industry is currently loss making?

Or what about these questions:

• In 2015, why are oil producers increasing oil production?  Can they not voluntarily produce less oil to support the price, as the industry is currently loss making?
• In 2015, why are iron ore miners increasing iron ore production?   Can they not voluntarily produce less iron ore to support the price, as the industry is currently loss making?
• In 2015, why are gold miners increasing gold production?   Can they not voluntarily produce less  gold to support the price, as the industry is currently loss making?
• In 2015, why are copper miners increasing copper production?   Can they not voluntarily produce less copper to support the price, as the industry is currently loss making?

The answer, (to all of the above questions) is of course, no.  The Nash equilibrium is for each miner to increase production or produce bigger blocks.  Miners keep producing large volumes until they close the mine, or in the case of Bitcoin, miners keep producing larger blocks until they stop mining altogether.

In the examples above, had there been an effective cartel of producers, miners would be able to collaborate and keep production down to support the price.  The industry would have been supported.  This would be against the interests of consumers.  Luckily in 2015, any cartels have mostly broken down and the prices of these commodities are crashing.  The consumer wins and gets lower prices.  As a result, we see a global commodity super cycle, we see periods where prices fall and industry players fail, capacity then falls and the commodity prices increase again.  Producers then over invest in capacity and the cycle repeats.  This may be a reasonably healthy cycle.

However, Bitcoin mining is different in two respects, first we need a healthy and viable mining industry at all times and secondly, the above cycle cannot occur, because when transaction fees start to fall and miners begin to fail, this will not reduce capacity.  Any one miner can provide all the capacity we need.  All that will happen is we enter a downward spiral when fees fall and miners fail and then difficulty falls.  There are several ways this can be prevented:
1 - A low blocksize limit
2 - Hoping a cartel naturally emerges, which implies mining is centralized
3 - Adopt BIP100 and allow cartel like prices to occur, without an actual centralized cartel

I favor BIP100, which I consider the only viable option.

They like it more for two reasons :D

- The BIP101 is limited to 8GB.
Miners don't like all this fork drama, and they want to avoid it again as long as possible.

- Miners want a BIT100 without the 32 MB limit.

So what they really want is something more huge then the BIP101, and something the Core team will NOT like it even more.

If you go around looking at their replies and even the last one from BitFury, you will find this ;)


I'm kinda ok on all about this, I just don't like at all the possibility to decrease the block size.

Please explain why we should let miners increase the limit to meet increasing demand, but not lower the limit with falling demand?

Also I would be happy supporting BIP100 with BIP101, or something even more aggresive as the upper bound.

Because there is no economic reason, it has only disadvantages.

It is like asking for "more features! more features!", even the bads.

I've already wrote, if there is demand, a business can't make a long plan in the future if there is the fear that an unpredictable time, the miners will force a smaller block, making fees enormously, slow confirmations, breaking plans and investments.

It's full of competitors to Bitcoin that are waiting every seconds to take away users/market from it.

Even the uncertainty that the miners will vote for a bigger blocks is bad, but not so bad as the possibility of decreasing it.

You've lost me here.  You explained that prices were artificially high due to cartels.  However, you then say that a cycle is complete when "producers over invest".  How does over investment necessarily lead back to cartels?


Another difference to bear in mind: block space is not treated as a fungible commodity the way oil, iron, gold, and copper are.  Many people are willing to pay more for a faster first confirmation.

Sorry I was not clear.  There were never cartels in my examples.  I just said "had there been" cartels.  In commodity markets copper and oil prices, ect, will recover when supply falls as firms in the industry shut down

I am not sure about this.  With no economic blocksize limit, every miner will include as many transactions in the block as possible.  The mempool will be empty and you will not need to outbid anyone to get a fast confirmation.

An economically relevant blocksize limit is therefore required.

Honestly, I'm not sure either.  I'm applying the same elasticity of demand thinking you described above but to a single miner.

Imagine a world where basically all fees are <= 1 satoshi.  Suppose Alice is a miner with 5% of the network's total hashrate.  Alice could advertise that she will no longer be processing all transactions but only those that pay at least 10 satoshis.  Each bitcoin user now has the option of paying 9 extra satoshi to reduce the expected first transaction waiting time by about 30 seconds.  Supposing this extra utility is worth the 9 satoshi in enough cases, Alice would increase her revenue.

I also wonder about store of value.  The commodities you listed can all store value but I don't think this can be done with block space.  Supposing commodity super cycles are driven by speculation, what is the equivalent mechanic in Bitcoin?

Not necessarely. You should look at the problem the other way around. If all miners will only mine fee F transactions, and suddenly one of them decides to just indiscriminately wipe the mempool for every block it finds, then the average fee will go down.

You should also consider the tapering of inflation. Currently the coinbase reward composes the grand majority of miner revenue, so they can afford to mine small blocks as a result of refusing to integrate any transaction with fee < F. That will certainly push the average fee up. However, as the coinbase reward keeps diminishing, we will eventually reach an equilibrium where a miner cannot afford to mine too small a block (based on the fee density he expects) and will either have to take on these transactions paying below F, or not mine blocks until the mempool is "plump" enough (which is not viable).

Agreed.  The miner that sweeps the mempool would profit from this action.  Thus, all miners accepting only fee F transactions is an unstable situation.

What I was arguing is that all miners processing any fee-paying transactions could also be unstable.  It may be profitable for a miner to increase the minimum fee they will accept.  These two situations do not contradict one another.


Yes.


Even with no block subsidy and assuming all other miners always sweep the mempool I expect F will be greater than zero.  I think Alice from the example above could still find a viable mining strategy in only accepting 10-satoshi transactions and waiting for the mempool to grow sufficiently "plump" before beginning to hash.

I can try posting a clearly specified, concrete example if anyone is interested.

That's assuming block size demand is superior to block size supply. Otherwise the mempool would essentially be empty after every block. Clearly there is a debate on the projected supply vs demand, but in the absence of a block size limit, I'm expecting the technological gain from fast relay networks will keep the supply way ahead of the demand for pretty much ever.

My expectation is that as long as there is a realistic block size limit in place, the Nash equilibrium will put upward pressure on fees. With the absence of a realistic limit, the Nash equilibrium will induce the opposite effect and fees will be not be sufficiently high to support proper difficulty.

So my response to this:


would be "only if the Nash equilibrium supports it". Which is the same as saying that demand will outgrow supply, which implies there is not enough block space to wipe the mempool of fee paying transactions.

The corollary to this statement would be that if a miner can wipe the mempool, then competing miners cannot afford to do any less.

No, I was assuming that the mempool would be completely emptied with each block.


Fair enough.  I expect that demand will catch up with and put pressure on supply myself.


Just to be clear, I don't argue that with no block size limit that fees could support "proper difficulty".  I just don't see why each miner clearing the mempool with each of their blocks as the only stable, competitive outcome.


As far as this Nash equilibrium is concerned, I'm not sure exactly what the game is.  I suspect that by taking into account long-term thinking and the utility of faster confirmations that there could be more than one Nash equilibrium.

I'll post a draft example to better explain what I'm thinking.  Perhaps you'd be kind enough to pick a hole in it for me.

Draft example:
    1. Assume that at all points in time, difficulty is such that blocks are found once every 10 minutes on average.
    2. Suppose all transactions pay a fee of 1 satoshi (ignore free transactions and fee per kB for simplicity).
    3. Suppose these transactions are produced at a constant rate.
    4. Suppose there is no block subsidy (so all miner revenue comes from transaction fees).
    5. Suppose each miner has the resources to completely empty the mempool with each block.  Suppose that this is the strategy currently employed by each miner.
    6. Suppose each miner only hashes when it is economically beneficial to do so (miners wait for a suitably plump mempool).
    7. Suppose at least 50% of all transactions are such that, to the creator, a reduction of the time to first confirmation by 10 seconds is worth more than 9 satoshis.

At this point we have a Nash equilibrium.

    8. Let Alice be a miner.
    9. Suppose that under the current scheme, Alice finds 5% of all blocks.
    10. Suppose Alice employs a new strategy: she only accepts transactions paying 10 satoshis.
    11. Suppose no transaction creators or other miners change their strategies.

At this point, Alice is doing worse than she was before (definition of Nash equilibrium).  From (6) we can see that Alice will in fact mine no blocks.

    12. Suppose transaction creators learn of Alice's strategy and co-ordinate a new strategy for themselves: the 50% of all transactions which would most benefit from a reduced time to first confirmation are broadcast with a 10 satoshi fee instead.
    13. Suppose that these 10-satoshi-fee transactions are distributed uniformly with time.

At this point, we can reasonably assume that Alice will find it profitable to hash at certain times.  She will be at a disadvantage relative to other miners, both for claiming smaller rewards and for having to wait for a larger mempool before she can begin mining.

    14. Suppose Alice finds 4% of all blocks.

At this point, Alice is earning much more than she was before (10) (Her revenue has increased dramatically.  Her costs also increase (1) but so do her profits (3), (13), (6)).  From (1), (5), (10), and (14) we can calculate that 1-satoshi-fee transactions must, on average, wait 25 seconds longer than 10-satoshi-fee transactions for their first confirmation (and suffer a higher waiting time variance).  By (7) and (12) we see that each of the 10-satoshi-fee transaction creators are better off than they were paying 1-satoshi fees.

Transaction creators continue to pay 10-satoshi fees frequently because, in this new scenario, the higher fee yields them utility.  Alice will be tempted to revert to her old strategy for even greater short-term profits but this will cause transaction creators to stop creating 10-satoshi-fee transactions, leaving Alice worse off in the long term.  Alice maintains her new strategy simply in caring about her long-term profitability.

(1), (4), (5) and (6) imply that all miners are withholding all hash power until the total fee in mempool hits a desired threshold. I don't think that equilibrium can exists. Indeed any miner has the opportunity to orphan the last top to "steal" the transaction in that block while the network is waiting for the mempool to fill. Consequently any miner has to "defend" their block after finding a solution by mining on top of it, and will naturally add all fee paying transactions they can get on the way, forcing every other miner to commit at least some hashing power as soon as a new block is propagated.

You could rework your example with the assumption that miners are throttling their hash rate based on total fees in the mempool but even that may not stand in view of this previous counter argument.


(13) coupled with (6) will reduce the average time it takes for every miner to start committing hash power, not just Alice. Generally, it means (7) is true with or without Alice. It also means that Alice may never hit her expected fee density.

In the Bitcoin network, block space suppliers compete for market share only by lowering prices, since the notion of quality does not apply to block bytes. You are speculating that Alice can exist in this market at a higher sell price only by waiting for demand to periodically outweigh supply. However (5) contradicts that strategy, as it suggest supply is infinite for intents and purposes. As stated previously, other miners will not sit at this equilibrium.

Assume my counter argument does not stand and Alice can still build "fat" blocks periodically regardless of the implications of (5). If she chooses to stick to this strategy despite the current equilibrium, the rest of the network will have a double incentive to orphan her:

1) Because of the first counter argument, as other miners know she is withholding all hash power until the mempool is attractive enough (according to (12), tx emitters know of her strategy, so there is no reason to believe other miners won't)
2) Because her blocks have higher than average fee density.

I'd not considered the strategy of attempting to orphan existing blocks.  Good point.  I'll need to think about this.

Is this not a general problem with (4) and (5)?  Ignoring Alice, is sweeping the mempool always economically unwise absent a block subsidy?


I imagine the global stock of mining hardware will remain fairly heterogeneous.  I expect that some hardware will be more efficient than other hardware and so will be put to work sooner.  Alice, being a very large miner, would likely have some very efficient miners as well as some more aged hardware which can only earn its electricity consumption as the mempool grows large.

I certainly don't expect a situation where all miners have equally efficient hardware worldwide and all this hardware is put to work in unison at some special threshold.

(13) coupled with (6) will indeed reduce the average time the moment (13) comes into play.  By (1) I intend at each step to allow difficult to adjust appropriately to look for long-term stabilities.


This is the simplification I'm challenging with my example.


Yes, I'm assuming infinite supply in this sense.  However, while transaction creators demand the space, they also care about the time they must wait for the space.  Alice can do nothing about the first but she can have a small effect on the second.  For the lowest possible expected time to first confirmation of 10 minutes, a transaction creator needs every last miner willing to process their transactions.


I honestly haven't thought much about what other miners will do in this situation.  I guess that the most they could do to undermine Alice's strategy is to simply continue with their own, sweeping up every transaction they can find.


Given (5), I wouldn't expect miners to care only about fee mass and pay no attention to fee density.

I admit it seems rational that miners would try to orphan Alice's blocks in this scenario.  I'll need to think a bit harder about what might happen.  However, at this point I expect that another miner, Bob say, would experience an even greater burden.  Breaking one of Bob's blocks would give another miner access to all the transactions of the previous round, not just the 10-satoshi transactions.  When trying to break one of Alice's blocks, a miner is forgoing the opportunity to try and grab the 1-satoshi transactions she left on the table.

In the above example Alice has 5% of the hashing power, therefore if she refuses to include transactions with a fee of less than 10 satoshis, users have a choice to pay 10x more in fees to be confirmed on average c5.3% faster.  Whether users choose to do this depends on their preferences, maybe c5.3% is enough and maybe it is not, clearly the higher the percentage the more compelling this is for users.  However, you need to also consider the game theory at play here, if users are willing to pay 10x the price for 5.3% faster confirmations, in the long term the best strategy could be to only create 1 satoshi fee transactions and wait it out, for Alice to go out of business or back down.  Therefore the dynamic is more complicated, a kind of game of chicken between Alice and the users.

It is clear that if Alice has a high enough proportion of the hashpower, she can win and drive fees up.  We cannot say what this level is.  Another possibility is that Alice forms a "cartel" of other miners and they all demand 10 satoshi fees.  The key point is that it is in the interests of users and coin holders, for many reasons other than fee market dynamics, for the mining industry not to consolidate and to have a wide distribution of hashing power.  A distributed mining industry is a necessary but not sufficient condition for Bitcoin to succeed, otherwise it will lack enough distinguishing characteristics from more traditional forms of money. Therefore, for the purposes of discussing these fee dynamics many years away, we should assume the mining industry is decentralized, otherwise this discussion is not relevant as Bitcoin would have failed.  Therefore, its likely that Alice will not have enough hashing power, or will be unable to form a cartel to drive up prices in the way you suggest.

BIP100 may therefore be necessary to allow miners to restrict supply, but at the same time remain decentralized and avoid forming an actual cartel.

Thanks for taking a look at this.  I'm aware that my posts are getting lengthy.


True, but this would require actual co-ordination between the bulk of the transaction creators to achieve (the co-ordination in (12) is technically unnecessary and was assumed for simplicity).  The spirit of the situation is to assume that the miners do not collude; I consider it only natural to assume the same of the transaction creators.

Given (7), I see no way for Alice to lose a game of chicken with a payment processing entity responsible for about 5% of all transactions.


Agreed.  I'll note that I consider the existence a single mining entity that acquires about 5% of all blocks to be well in line with "a wide distribution of hashing power" (Pareto distribution and all that).  I'd be interested to hear if you see "wide distribution of hashing power" differently.


Certainly, BIP100 creates a framework for miner coordination, setting cartel-like prices but not creating an actual cartel.  I also believe that in some situations, BIP100 will actually function to prevent miner centralisation.  However, I think there are other natural situations where BIP100 without limits will be powerless to stop miner centralisation (situations where there is a lot of demand for block space).

Perhaps there is a resistance here.  My intuition still tells me that Alice would win but I'll admit it's not clear cut.


Interesting idea.  As you note, such an exotic situation is unlikely to occur and probably couldn't be sustained.  I'd imagine the costs of mining capital would change to reflect the risks of this potential attack (more efficient miners would become slightly more valuable and less efficient miners slightly less).  Still, I agree with you that it would be better to robustly block these niggling attack possibilities for a more predictable and efficient system overall.


Possibly, but there may be a trade-off here.  Miners would also have less power to track changing demand (seasonal surges and declines) and so the voting mechanic will be less effective in increasing network security.

Maybe there are other ways the proposal could be made robust against such attacks.  Maybe an annual voting scheme could be combined with a new protocol mechanism to smooth out miner income across the year.  Maybe it can be shown that these medium-term surges and declines are no big deal.

One possibly silly idea: Could BIP100 come along with a protocol rule making coinbase outputs unspendable for 4 years?  I'd be a bit more comfortable were votes undivorcably attached to long-term investments in Bitcoin.

It would be good to get your thoughts on this.  Could it work?  Is there something obvious I've overlooked?

Edit:
Transaction creators could channel their fees to miners using an OP_TRUE output, avoiding the coinbase lock described above.

I do not think BIP100 or economic policy should be used to cater to seasonal demand variations.  Although I guess its imposible to draw a clear line between short term and long term demand variations.

Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.

Ah yes, that might do the trick.

Yes.  Although I don't know if BIP100 and Meni's idea can occur at the same time, as people may say its too complicated.  We could do one and then the other.

I was looking at some sort of hybrid between BIP100 and BIP106, so that the increase or decrease would take both the miner vote and the network traffic into account.  The change would only go ahead if the two were in alignment.  Also, the doubling/halving part might prove excessive, so felt that needed curtailing:

This seems like the best solution to me. I don't think it's fair that miners have as much influence over the price as proposed by BIP100. At least with this proposal the interests of bitcoin users are taken into account.

Fortunately, both BIP100 and BIP101 are very smooth already; not even close to suddenly doubling or halving.

I reject the whole "if needed" approach.  If demand were high and supply were low then we'd effectively have to choose between small blocks (hundreds of competing payment processors) and large blocks (one payment processor, the majority miner).  Even with 1MB blocks it's possible to cheaply process many more transactions than would be required for the hundreds of competing payment processors scenario.


I don't see how "fairness" enters into the debate.  I'm much more interested in finding something which works and is robust.

the uncertainty with BIP100 too large.

BIP 100 always has reminded me of what a Union represents in the US. Workers (in this case miners) will have a say so in the minimal wage for their job that they need to perform to get paid. If the "boss" doesn't comply (in this case, everyone who transacts in bitcoins), then the workers will go on strike. 

This could be very devastating for bitcoin in general. No workers means no security in transactions... Unions in the beginning meant to give people optimal working conditions and not promote a slave type of labor; since in this case we're talking about miners who use computers to do their work, this isn't necessarily valid.  I understand that miners are coming to the brink of whether they make a profit or not, but obviously something needs to be done to create a less costly way to mine coins.  If that were to happen then everything will be perfectly fine.

I have been thinking about BIP100 carefully.  I think the voting process in BIP100  is not consistent with the existing power structure so could be undermined. This is with respect to a vote for a decreases in the blocksize limit, with an 80% majority being required. In some circumstances (but not all) 50% of the miners can impose a lower limit anyway, if they collaborate and orphan all blocks above a certain size. (Please note the opposite is not true, as all full nodes, and not just miners, are required to implement an increase in the limit)  This fact needs to be reflected in the voting mechanism, otherwise the voting can be considered to ignore reality.

For example, if 79% vote for a decrease and 21% vote for an increase, then under BIP100 the limit is unchanged.  This "defeat" for the 79% could serve as a catalyst for collusion to impose the lower limit anyway and undermine the voting process.  I think BIP100 should be constructed in such a way to avoid this disconnect from the actual power in the mining industry.

In conclusion, these voting systems need to be constructed such that 50% of votes or less, should be required for a reduction in the limit and 50% of votes or more, should be required for an increase in the limit. Therefore, to avoid the perception of small block bias, I think a simple 50th percentile rule is best.

BIP100 should be modified to a simple 50th percentile voting system.

Pools are voting for BIP100:

https://bitcoinnewsmagazine.com/wp-content/uploads/2015/09/screenshot-data-bitcoinity-org-2015-11-09-15-22-37.png

By thinking of bitcoin as a currency, everyone will day no to this. Currencies are meant to be stable, and be used like a ruler to measure the price of a good. If the scale of the ruler is changing each day, what's the point of that?

Bitcoin's stability doesn't stem primarily from the blocksize limit, though.  There are a multitude of factors affecting that, like the block reward and supply cap which won't be altered.  A variable blocksize only makes the system unstable if it's too large and we lose nodes or miners as a result.   The tricky part is determining how large is too large.