whoa there BIP100 at 61%?? Let's talk about this first...

[BitProdigy]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

[1715126495]

1715126495

[1715126495]

1715126495

[1715126495]

1715126495

[1715126495]

1715126495

[1715126495]

1715126495

[knight22]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

[achow101]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

BIP 100 doesn't even have a client implementing it, so even if they reach the threshold, it won't do anything. The threshold is also 90% (not the 75% used by BIP 101) and requires 12000 blocks which is 3 months worth of blocks.

[LiteCoinGuy]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago)

[Amph]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

BIP 100 doesn't even have a client implementing it, so even if they reach the threshold, it won't do anything. The threshold is also 90% (not the 75% used by BIP 101) and requires 12000 blocks which is 3 months worth of blocks.

i don't think it's to hard for the them to impelment this in a client, only a few tweak here and there in the code

and this was much smaller back then around 27% now it's already double the amount

[marky89]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago)

I think that's reasonable enough. BIP 102 is an easy fix, is not very controversial and gives us ample time to both observe scaling and devise a more reasonable, permanent solution.

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast!

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

Now you know how some of us feel when XT/BIP 101 is/was presented as the only alternative to permanent 1 MB blocks.

The vote is just an opinion, nothing to do with a hard fork.

[Mickeyb]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago)

At the end, this just might be a solution. I am afraid though, that in this case, we would just prolong this block size agony.

On the other side, the fast gaining traction BIP100 just shows us that people might be just a bit tired of all of this debate. I mean nothing is coded in BIP100, no client, but such a support. I am also afraid that we are rushing a bit in a solution with this BIP. It seems to me that many people don't even understand about what this BIP100 is all about.

But I guess that's what you get once people fed up of drama.

[uxgpf]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago)

At the end, this just might be a solution. I am afraid though, that in this case, we would just prolong this block size agony.

On the other side, the fast gaining traction BIP100 just shows us that people might be just a bit tired of all of this debate. I mean nothing is coded in BIP100, no client, but such a support. I am also afraid that we are rushing a bit in a solution with this BIP. It seems to me that many people don't even understand about what this BIP100 is all about.

But I guess that's what you get once people fed up of drama.

I assume that BIP100 support comes mainly from miners, simply because it moves power balance towards them. (less power to the rest of the community, more power to miners in deciding blocksize limits.)

For the rest of the community, especially for merchants the BIP 101 seems like a better choice as it offers clear predictability (markets don't like uncertainty), gives enough initial rise in blocksize cap to support large influx of new users (so the fees don't go thru the roof even if we had another price bubble) and it maintains the balance of power that bitcoin currently has.

More options is good and I'll probably be ok with whatever the community consensus will support. (altho I would prefer BIP 101)

[Realpra]

Just want to add my 2 cents/ask if I got it right.

This I believe is the central core of BIP100, copied from the documentation:
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.

(link)

The way I understand it, it means this:
1. The 20% lowest and highest votes from miners are dropped.
2. "The most common floor is chosen" - a floor function converts decimals to integers, so a vote for 8.9 mb becomes a 8 mb vote. (Is that correct?)
3. In the case that there are equal votes for say 7mb and 8mb the lowest (minimum) floor is chosen - so 7mb.

Honestly I think that sentence is pretty unclear. What if there are floors 9, 10, 11, 12, 13 with all "one" vote each and I come in with 20-30% of mining power and vote twice for 0?
Under that definition my floor of 0 would win right?

Can someone spell it out for me?

Alternative understanding:
Block size is set to be the lowest 21 percentile vote - not safe!


I think a better implementation/description would be:
"50 percentile median of votes - done". (not average - MEDIAN)

That way if its broken, well you are already under 51% attack and need to do something anyway.

[DooMAD]

Is there a possible way to combine BIP100 and BIP106?  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  Isn't the obvious answer to try and find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes?  That way we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

[franky1]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

note to all
if your not a miner and if you dont even bother running a full node.. then you have nothing to bitch about

no forum begging will change the consensus,, if you want to vote.. get your full node running and show the network what you prefer

[teukon]

Just want to add my 2 cents/ask if I got it right.

This I believe is the central core of BIP100, copied from the documentation:
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.

(link)

The way I understand it, it means this:
1. The 20% lowest and highest votes from miners are dropped.
2. "The most common floor is chosen" - a floor function converts decimals to integers, so a vote for 8.9 mb becomes a 8 mb vote. (Is that correct?)
3. In the case that there are equal votes for say 7mb and 8mb the lowest (minimum) floor is chosen - so 7mb.

Honestly I think that sentence is pretty unclear. What if there are floors 9, 10, 11, 12, 13 with all "one" vote each and I come in with 20-30% of mining power and vote twice for 0?
Under that definition my floor of 0 would win right?

Can someone spell it out for me?

Jeff clarified this on the bitcoin-dev mailing list:

I have been reading the pdf and one thing I can't figure out is what you mean by "most common floor". Is that the smallest block size that has a vote or the block size with the most votes or something else?

20th percentile, though there is some argument to take the 'mode' of several tranches

Alternative understanding:
Block size is set to be the lowest 21 percentile vote - not safe!


I think a better implementation/description would be:
"50 percentile median of votes - done". (not average - MEDIAN)

That way if its broken, well you are already under 51% attack and need to do something anyway.

There are other problems with taking the median though.  For this to be effective we'd need to assume that a majority of the blocks mined will vote for a limit deemed good for Bitcoin's long-term health.  However, a miner's financial incentives are not particularly well-aligned with that goal.

51%-honesty assumptions doesn't really make sense unless mining is "incentive compatible" (incentive in the broadest sense, altruism accounted for).  Companies are good at seeking profits and I doubt Bitcoin can function long-term on the assumption that more than 50% of an entire industry will regularly act against this most fundamental business instinct.

If a vote were intimately tied to a long-term financial interest in Bitcoin then I'd be more comfortable with this 50% idea.  Something like: "have the coinbase be unspendable for 4 years (rather than just 100 blocks)", but this doesn't quite work.

[Blawpaw]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

I really think that we shouldn't mess with the original protocol. <BIPs are not the best solution! There are other possible solution that could perfectly work that doesn't implicate tampering with the code. eg. Colored coins, Bitcoin Lightning network, and Sidechains...

[teukon]

Relax, no move are going to happen soon. BIP100 is not even coded even less tested. They can't make a move without going in an agreement with the industry that support BIP101 or it could go really messy.

History will slowly unfold.

maybe we should just add 2 MB blocks to win some more time (like Jeff said a few months ago)

At the end, this just might be a solution. I am afraid though, that in this case, we would just prolong this block size agony.

On the other side, the fast gaining traction BIP100 just shows us that people might be just a bit tired of all of this debate. I mean nothing is coded in BIP100, no client, but such a support. I am also afraid that we are rushing a bit in a solution with this BIP. It seems to me that many people don't even understand about what this BIP100 is all about.

But I guess that's what you get once people fed up of drama.

If we do this we can rest easy for a short while.  Eventually, 2MB may become just as worrisome as 1MB is today.  More work will have been done but still there will be no perfect solution.  The notion of simply kicking the can to 4MB will surface with the extra argument of "we've done it before" to support the usual "it needs to be raised now" and "drama is bad for business".

Anyone else notice the parallel with the many US Debt Ceiling debates?

[Realpra]

Jeff clarified this on the bitcoin-dev mailing list[url]:

I have been reading the pdf and one thing I can't figure out is what you mean by "most common floor". Is that the smallest block size that has a vote or the block size with the most votes or something else?

20th percentile, though there is some argument to take the 'mode' of several tranches

I think a better implementation/description would be:
"50 percentile median of votes - done". (not average - MEDIAN)

That way if its broken, well you are already under 51% attack and need to do something anyway.

There are other problems with taking the median though.  For this to be effective we'd need to assume that a majority of the blocks mined will vote for a limit deemed good for Bitcoin's long-term health.  However, a miner's financial incentives are not particularly well-aligned with that goal[...]

Thanks for answering me Teukon!

You're right about medians... we don't really have many great options on the table do we, everything seems to have a catch!

If BIP100 uses the 20% percentile I would guess it would be coded so 1mb is still the minimum limit - so that takes care of the 20% attack setting it to 0mb.
Can anyone confirm that or is it just common sense?

If so I might still like BIP100 even if not perfect.

[BillyBobZorton]

You know I'm not totally sure that BIP100 is the best possible solution? I know we all want to get this over with and behind us but let's not implement an inferior solution out of hast! BIP101 implemented on Core without XT "added features" seems to be to be a superior solution to BIP100… There are also other solutions out there that seem superior. I think BIP100 needs so amendments, clarifications, and modifications before we can realistically implement it…

Whoa there slow down miners! Let's make sure we are making the right decision before we get BIP100 in it's current form over the 75% threshold!!

note to all
if your not a miner and if you dont even bother running a full node.. then you have nothing to bitch about

no forum begging will change the consensus,, if you want to vote.. get your full node running and show the network what you prefer

Indeed. The funny part is, if the blocks get raised way too high, we will not be able to run full nodes because the nodes will be way too heavy for most of us which have modest computers. So in a couple of years forget about node voting because average joes will not be able to run a node. That's the problem.

[teukon]

Thanks for answering me Teukon!

You're most welcome.

If BIP100 uses the 20% percentile I would guess it would be coded so 1mb is still the minimum limit - so that takes care of the 20% attack setting it to 0mb.
Can anyone confirm that or is it just common sense?

The original PDF (published 2015-06-14) doesn't mention a lower limit at all.  This more active equivalent explicitly states:

7. Limit may not decrease below 1MB, nor exceed 32MB.

and includes a short rationale section for this (all added earlier this month).

Note: Now that the upper 32MB limit is explictly part of the specification, the upper bound really is 32MB and not Bitcoin's message limit of 32MiB.