Topic: ELI5 for BIP100? (Read 1344 times)

I disagree the dynamic blocksize limit does not make any sense whatsoever. Remember we're talking about limit not the blocksize.

If we have parameters that determizr the blocksize limit then we should not have limit at all. We're governing the wrong target.

With BIP100 it is possible to arrive to 32 MB in 12 months

Anyone else notice the size of the last block?

974.74 kb  & 2,320 transactions.

https://blockchain.info/block/00000000000000000971eaf8d7ad55052ae8a109f2e723a77dec911c0cadb850

There was a reply by Garzik to the question about how the votes are counted. The block size chosen is the 20th percentile block, meaning that the supposed 21% attack cannot work. This means that it will choose the block size which is greater than 20% of the all of the other votes. Even if a miner had 21% of the mining power, they cannot change or force a minimum since all of their blocks would not be in the 20th percentile, they would probably be in the 1st or 2nd percentile.

Dynamic Blocksize makes alot of sense. It should be made to scale dynamically as adoption and growth scale organically.

That is what I understood from the pdf, but I could be wrong. Someone on the mailing list did ask him for clarification on this but he did not respond yet.

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

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://bitcointalksearch.org/topic/m.12267335

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.

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.

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.

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.

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.

Fixed that. Damn google with their bad conversions.

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

I found the source code references.

If you grab a copy of the original 0.1.0 client from this thread: https://bitcointalksearch.org/topic/v01-68121, 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.

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.

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

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/

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.

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.