ELI5 for BIP100?

[DarkHyudrA]

There are some things that aren't clear for me about BIP100, like when it says:

The historical 32MB limit remains."

So it means that even if miners "vote" to increase block size, it cannot pass 32MB?

And I have no idea what calculation he means here:

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

[LiteCoinGuy]

i guess you are right, it cant pass 32 MB.

[achow101]

There is a historical limit of 32 Mb on Bitcoin message sizes, thus also limiting blocks since blocks are passed in the block p2p message.

Miners vote for block sizes within the range of half of the current to double the current block size (e.g if the block size is 1 mb, then miners can vote to change the block size to somewhere between 0.5 mb and 2 mb. They cannot go below 0 or greater than 32 mb whatsoever. The hard fork is scheduled to occur after 90% of the last 12000 blocks support BIP 100 and the date is past Jan 11 2016. Presumably (the bip is unclear on when the votes are counted) the block size limit is also changed every 12000 blocks. Miners vote by encoding ‘BV’+BlockSizeRequestValue into the coinbase script to vote for their block size limit. The final size is determined by dropping the highest 20% and lowest 20% votes and then choosing the minimum (the bip is not very clear on what is actually chosen).

[oblivi]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

[achow101]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

No, it is just a historical limit that Satoshi originally had and this BIP does not remove. The limit was on p2p message sizes which were and still are limited to a maximum of 32 MB. This includes blocks because blocks are sent as p2p messages. Thus blocks are limited to 32 MB and Garzik chose not to remove this limit.

[RocketSingh]

i guess you are right, it cant pass 32 MB.

Not only that. It gives all voting right to pool operators. End users have no right to exercise. Size of mempool needs to be considered. My vote goes for this proposal.

[pereira4]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

No, it is just a historical limit that Satoshi originally had and this BIP does not remove. The limit was on p2p message sizes which were and still are limited to a maximum of 32 MB. This includes blocks because blocks are sent as p2p messages. Thus blocks are limited to 32 MB and Garzik chose not to remove this limit.

Satoshi said the limit should be 32MB? where can I read satoshi quote on this? i remember satoshi saying the 1MB limit was temporal but dont recall reading anything on a limit being set.

[achow101]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

No, it is just a historical limit that Satoshi originally had and this BIP does not remove. The limit was on p2p message sizes which were and still are limited to a maximum of 32 MB. This includes blocks because blocks are sent as p2p messages. Thus blocks are limited to 32 MB and Garzik chose not to remove this limit.

Satoshi said the limit should be 32MB? where can I read satoshi quote on this? i remember satoshi saying the 1MB limit was temporal but dont recall reading anything on a limit being set.

He didn't say anything. I think it was just in the code from day one probably to prevent people from DoS attacking nodes with massive messages. I will see if I can find you a code reference.

[LiteCoinGuy]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

for that kind of adoption you would need 100+ MB blocks - 32 MB is just a temporary solution.

@pereira4

you are right. satoshi said, that at some point normal people cant run full nodes anymore as today not everyone can run a server.

http://crypt.la/2014/01/06/satoshi-nakamoto-quotes/

[Amph]

i guess you are right, it cant pass 32 MB.

it would be a problem if in the future we need to surpass that limit, i guess everything that does not contemplate a possible scenario in the future, and it is limited should not be seen as a good alternative

[DarkHyudrA]

i guess you are right, it cant pass 32 MB.

it would be a problem if in the future we need to surpass that limit, i guess everything that does not contemplate a possible scenario in the future, and it is limited should not be seen as a good alternative

Ah well, those are near-mid future solutions.
One simple ultimate solution can't be made like a miracle.
I'm pretty much OK wih BIP100 even with the recent not-so-FUD of the 21% attack.

[achow101]

It would hard cap 32MB as a security measure. This (I hope) means that 32MB is estimated to be enough to scale Bitcoin worldwide (because anything that isn't Bitcoin worldwide and being able to sustain VISA + MASTERCARD + WESTERN UNION + every other electronic payment processor) is a failure. We need to aim worldwide. So, have they calculated that 32MB blocks and blockstream tech will be enough?

No, it is just a historical limit that Satoshi originally had and this BIP does not remove. The limit was on p2p message sizes which were and still are limited to a maximum of 32 MB. This includes blocks because blocks are sent as p2p messages. Thus blocks are limited to 32 MB and Garzik chose not to remove this limit.

Satoshi said the limit should be 32MB? where can I read satoshi quote on this? i remember satoshi saying the 1MB limit was temporal but dont recall reading anything on a limit being set.

He didn't say anything. I think it was just in the code from day one probably to prevent people from DoS attacking nodes with massive messages. I will see if I can find you a code reference.

I found the source code references.

If you grab a copy of the original 0.1.0 client from this thread: https://bitcointalk.org/index.php?topic=68121.0, the source code is included. There are multiple checks which check whether the messages are less than MAX_SIZE which is set to 0x02000000 which is 33554432 bytes in decimal form which is 33.5544 MB. Thus the maximum size of the message could be no larger than 32 MB.

The code is at line 17 of main.h which was then moved to line 22 of serialize.h at commit 401926283a200994ecd7df8eae8ced8e0b067c46. It currently resides at line 25 of serialize.h in the latest source code.

[RoadTrain]

If you grab a copy of the original 0.1.0 client from this thread: https://bitcointalk.org/index.php?topic=68121.0, the source code is included. There are multiple checks which check whether the messages are less than MAX_SIZE which is set to 0x02000000 which is 33554432 bytes in decimal form which is 33.5544 MB. Thus the maximum size of the message could be no larger than 33.5544 MB.

33554432 bytes is exactly 32 Mb, as one kilobyte contains 1024 bytes.

[achow101]

If you grab a copy of the original 0.1.0 client from this thread: https://bitcointalk.org/index.php?topic=68121.0, the source code is included. There are multiple checks which check whether the messages are less than MAX_SIZE which is set to 0x02000000 which is 33554432 bytes in decimal form which is 33.5544 MB. Thus the maximum size of the message could be no larger than 33.5544 MB.

33554432 bytes is exactly 32 Mb, as one kilobyte contains 1024 bytes.

Fixed that. Damn google with their bad conversions.

[VeritasSapere]

I support BIP101 over BIP100 because of the 32MEG limit within BIP100. However if that 32MEG limit also exists within Bitcoin XT and or BIP101. For me this would actually change my opinion in support of BIP100. Since I do think that the miners are the people that are best incentivised to do what is best for Bitcoin. I certainly do trust proof of work more then I do any development team. lol

Can anyone here with a deeper technical understanding confirm that even if the network forked to XT that this 32MEG limit would still be in place? Since that was the only reason why I preferred BIP101 compared to BIP100.

I have one more concern however, which is that no client that I can download now has BIP100 implemented and no plans for a hard fork have yet been made. Which means that for me to truly and wholeheartedly support BIP100 we would need these things in place and introduced in similar way that Bitcoin XT was. Since I do not want to just trust or believe that the Core team will implement BIP100 into the client themselves, since that was the entire reason for the existence of XT in the first place, since the Core development team seems to be unable to implement any of the BIP proposals. Which is why it will most likely need to be another alternative client that should push for this change. However since this does not exist yet, is why on some levels BIP100 is not a viable solution yet. I do hope that this will change soon.

[achow101]

I support BIP100 over BIP101 because of the 32MEG limit within BIP100. However if that 32MEG limit also exists within Bitcoin XT and or BIP101. For me this would actually change my opinion in support of BIP100. Since I do think that the miners are the people that are best incentivised to do what is best for Bitcoin. I certiainly do trust proof of work more then I do any development team. lol

Can anyone here with a deeper technicall understanding confirm that even if the network forked to XT that this 32MEG limit would still be in place? Since that was the only reoson why I prefered BIP101 compared to BIP100.

It will most definitely be removed. Blocks cannot go to its planned final size of 8 GB if the 32 MB limit on message sizes is not removed.

I have one more concern however, which is that no client that I can download now has BIP100 implemented and no plans for a hard fork have yet been made. Which means that for me to truly and wholeheartly support BIP100 we would need these things in place and introduced in simaliar way that Bitcoin XT was. Since I do not want to just trust or believe that the Core team will implement BIP100 into the client themselves, since that was the entire reoson for the existance of XT in the first place, since the Core development team seems to be unable to implement any of the BIP proposals. Which is why it will most likely need to be another alternitive client that should push for this change. However since this does not exist yet, is why on some levels BIP100 is not a viable solution yet. I do hope that this will change soon.

Jeff Garzik is supposedly working on a client that implements BIP 100. He says that he thinks it will be ready for the Scaling Bitcoin Workshop that begins September 12th.

[VeritasSapere]

I support BIP100 over BIP101 because of the 32MEG limit within BIP100. However if that 32MEG limit also exists within Bitcoin XT and or BIP101. For me this would actually change my opinion in support of BIP100. Since I do think that the miners are the people that are best incentivised to do what is best for Bitcoin. I certiainly do trust proof of work more then I do any development team. lol

Can anyone here with a deeper technicall understanding confirm that even if the network forked to XT that this 32MEG limit would still be in place? Since that was the only reoson why I prefered BIP101 compared to BIP100.

It will most definitely be removed. Blocks cannot go to its planned final size of 8 GB if the 32 MB limit on message sizes is not removed.

I have one more concern however, which is that no client that I can download now has BIP100 implemented and no plans for a hard fork have yet been made. Which means that for me to truly and wholeheartly support BIP100 we would need these things in place and introduced in simaliar way that Bitcoin XT was. Since I do not want to just trust or believe that the Core team will implement BIP100 into the client themselves, since that was the entire reoson for the existance of XT in the first place, since the Core development team seems to be unable to implement any of the BIP proposals. Which is why it will most likely need to be another alternitive client that should push for this change. However since this does not exist yet, is why on some levels BIP100 is not a viable solution yet. I do hope that this will change soon.

Jeff Garzik is supposedly working on a client that implements BIP 100. He says that he thinks it will be ready for the Scaling Bitcoin Workshop that begins September 12th.

Thank you for the clarification, so I presume that this would not require another hard fork then. Jeff garzik will be my new hero when he releases a client that implements BIP100.

[uxgpf]

i guess you are right, it cant pass 32 MB.

it would be a problem if in the future we need to surpass that limit, i guess everything that does not contemplate a possible scenario in the future, and it is limited should not be seen as a good alternative

Ah well, those are near-mid future solutions.
One simple ultimate solution can't be made like a miracle.
I'm pretty much OK wih BIP100 even with the recent not-so-FUD of the 21% attack.

One possible problem is that it would need another hard fork in the future to pass 32 MB limit.  If bitcoin goes mainstream there might be dozens of different bitcoin node implementations. Would such fork be possible? Think how hard it has been to upgrade to IPv6 once the internet has gone mainstrem.

BIP 101 has the advantage that any future blocksize increases can be made via soft fork.

[VeritasSapere]

i guess you are right, it cant pass 32 MB.

it would be a problem if in the future we need to surpass that limit, i guess everything that does not contemplate a possible scenario in the future, and it is limited should not be seen as a good alternative

Ah well, those are near-mid future solutions.
One simple ultimate solution can't be made like a miracle.
I'm pretty much OK wih BIP100 even with the recent not-so-FUD of the 21% attack.

One possible problem is that it would need another hard fork in the future to pass 32 MB limit.  If bitcoin goes mainstream there might be dozens of different bitcoin node implementations. Would such fork be possible? Think how hard it has been to upgrade to IPv6 once the internet has gone mainstrem.

BIP 101 has the advantage that any future blocksize increases can be made via soft fork.

That is what concerns me to most about BIP100 as well. It might be impossible to fork Bitcoin in the future without causing a split. This is something everyone should keep in mind when choosing between BIP100 and BIP101.

https://bitcointalk.org/index.php?topic=1164464.msg12267335#msg12267335

[turvarya]

There is a historical limit of 32 Mb on Bitcoin message sizes, thus also limiting blocks since blocks are passed in the block p2p message.

Miners vote for block sizes within the range of half of the current to double the current block size (e.g if the block size is 1 mb, then miners can vote to change the block size to somewhere between 0.5 mb and 2 mb. They cannot go below 0 or greater than 32 mb whatsoever. The hard fork is scheduled to occur after 90% of the last 12000 blocks support BIP 100 and the date is past Jan 11 2016. Presumably (the bip is unclear on when the votes are counted) the block size limit is also changed every 12000 blocks. Miners vote by encoding ‘BV’+BlockSizeRequestValue into the coinbase script to vote for their block size limit. The final size is determined by dropping the highest 20% and lowest 20% votes and then choosing the minimum (the bip is not very clear on what is actually chosen).

If he said that, he is really bad at math.
If you drop the lowest 20% and take the minimum, it doesn't matter if you also drop the highest 20%, since the minimum stays the same