Topic: Why I support Jeff's BIP100 - page 4. (Read 10572 times)

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?

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

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.

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.

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.

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.

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

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.

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.

Nope, in which case I take that part back.

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

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.

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.

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.

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

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.

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.

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?

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

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.