Reduce the max-block-size that is used in new networks by default

[xeroc]

... unless the genesis block is modified manually, or the committee
changes that parameter on the chain.

This fixes the issue that blocks might otherwise become bigger than the
MAX_MESSAGE_SIZE of the p2p code. This far, I am unaware that the p2p
does segmentation of messages.

[abitmore]

Do a replay to make sure it didn't break anything.
If it's really an issue, the committee should change the parameter to a lower value (asap?), and never set it to a higher one before this issue is totally fixed (e.g. p2p message segmentation).

[dnotestein]

I agree that the blocks shouldn't be allowed to be larger than MAX_MESSAGE_SIZE. Messages are not segmented by the p2p code. It's probably a good idea to test that there's no overhead that makes the final message larger than the nominal block size (for example, by creating a block of max size and trying to propagate it).

As a related issue, I don't know why 2MB was chosen as the max message size, but this could certainly be increased some.

[pmconrad]

Setting max block size to the same as max message size won't help, because of the message overhead. You need to stay below that, for example use 2000000 to be on the safe side.

[xeroc]

Someone just exploited this on the testnet

[xeroc]

For reference, this is how you can truncate the blockchain locally:

ls -l .../blockchain/index
# look at size in bytes
# new= subtract 32 * number of blocks
truncate -s new_size blockchain/index

truncating the last 32 bytes effectively pops the last block from your block db

replay is needed

[abitmore]

As @pmconrad mentioned, best change it to an even smaller value.