Quote from: deisik on January 23, 2017, 09:09:50 AM

Really, what's the sense of adding empty space to the block just to keep its size to 1Mb in all cases?

It would have had some reasons, like better parsing speed for the client or predictability for the future size of the blockchain.
However, I did a quick search and now I know that I was wrong and I should have researched before talking. Sorry.
I will leave my post as it is now, because others may have the same misconception and my learn something of it, especially if they are as lazy as I am.

So.. the block is already variable with upper limit so all I said was on the wrong assumption.
Now I am puzzled why there's so much debate on increasing the block size, since the "effort" of the blockchain would not be so big.

From what I've read and understood, even a completely dynamic blocksize is achievable without much of a change, since in the block, the bytes 4-7 (0-based) tell the total size of the block, which can be a 4 bytes = 32 bits number, so up to ~4GB (!).

~~~~~~~~~~~~~~~~

Now back to the original discussion:
1. If 100% dynamic block is an issue, then fix the issue or limit it (even if limiting it makes it work like now), but at least limit it to something a couple of levels higher than what we have now (much higher than 2MB).
2. Such move may need a fork and then SegWit can be even forced "in the same package".

I know that this kind of move would cause more debate, but.. we have it already and we can see that SegWit is not adopted by the ones that should