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.
Topic: ELI5 for BIP100? - page 2. (Read 1398 times)
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.
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. 
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?
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).
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).
i guess you are right, it cant pass 32 MB.
There are some things that aren't clear for me about BIP100, like when it says:
And I have no idea what calculation he means here:
Quote
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:
Quote
"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"
“/BV8000000/” to vote for 8M. Votes are evaluated by dropping bottom 20% and top
20%, and then the most common floor (minimum) is chosen"
Jump to: