Anyway, more seriously, thanks for setting me straight. In other threads discussing this, it seemed that the p2p protocol we're using for bitcoin was going to cause a limit of 32mb per block, even under some scheme where miners can indefinitely vote up the block size (bip100). So I guess I wonder how bip101 is supposed to address that issue.
There is a 32 mb limit on bitcoin p2p messages (which includes the block message) so there is an effective 32 mb cap on blocks. BIP 100 keeps this limit so the absolute maximum block size with BIP 100 is 32 mb.I'm not sure how BIP 101 deals with this but I assume that they remove that cap.
There is a current limit on the number of sigops (signature operations) to prevent a miner from creating a block that takes ages to verify due to an extreme number of sigops. Sigops currently include the OP_CHECKSIG and OP_CHECKMULTISIG as well as a few others. The current limit is 20000 sigops per block which is 1000000 (1 MB)/50. Thus the maximum number of block sigops will increase according to the formula of blocksize/50. It will become 40000 for a 2MB maximum.
As for why it is written like that, probably because the code is like that to allow for any blocksize but still preserve the ratio between blocksize in bytes and number of sigops.
As for why it is written like that, probably because the code is like that to allow for any blocksize but still preserve the ratio between blocksize in bytes and number of sigops.
Thanks knightdk. That explains it. I guess bip102 is sorta a kicking-the-can-down-the-road proposal, so to speak. I think my questions are answered then. Presumably bip102 is so terse because there's nothing really to see here, it's just a proposal to more-or-less keep the status quo albeit with slightly larger blocks until a more long term solution is agreed upon.
Quote
In the short term, an increase is needed to continue to facilitate network growth, and buy time for more comprehensive solutions to be developed. This continues the current economic policies with regards to fees, matching market expectations and preventing market disruption.
In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management.
In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management.
