Why I support Jeff's BIP100

[HostFat]

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.

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.

[HostFat]

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

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

[-ck]

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

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.

[jonny1000]

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.

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.

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.

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

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

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

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.

[teukon]

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.

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.

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.

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.

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

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

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.

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.

[-ck]

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?

[lottery248]

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.

[teukon]

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?

BIP 101, Block size following technological growth, 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.

[-ck]

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?

BIP 101, Block size following technological growth, 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.

[teukon]

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?

BIP 101, Block size following technological growth, 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.

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.

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.

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.

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.

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.

[jonny1000]

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.

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

[teukon]

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.

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?

[jonny1000]

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.

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

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

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.

[teukon]

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.

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

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

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

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.

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:

9. Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig, e.g. “/BV8000000/” to vote for 8M.  Votes are evaluated by dropping bottom 20% and top 20%, and then the most common floor (minimum) is chosen.

This creates a framework whereby the network may increase the block size by consensus, a lower and less politically risky hurdle than hard fork.

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.

[-ck]

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.

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.

[teukon]

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.

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.

[-ck]

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.

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.

[teukon]

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.

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.

[HostFat]

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)

[teukon]

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