Changing all Numbers to CompactSize can effectively clean up 3.5%-5.5% (up to 50 KB) of wasted block sizes and open up room for additional transactions.Ever since I saw this irrelevant question I have been working on this theory that transactions are wasting some space the way they are.For instance, the first field iswhich is wasting 3 bytes where it only needs 1 byte. Ever since the first transaction in 2009 version was 1 and any change will not shoot it up to 253 (the first value which needs 3 bytes in CompactSize)The same goes for the following:And the thing is that these numbers can be defined as a CompactSize Unsigned Integers freeing up those extra bytes.I ran some statistical analysis on some random blocks between 440300 and 441300 heights and medium results are as follows:Note: These numbers of average of about 20 random blocks.Tx Count: 2,298Average TxSize: 541 (bytes)Clean Up Size: 46501 (bytes)Clean Up %: 4.16%Additional Tx that can be added after clean up: 94This is not limited to current block size but it is applicable to now and the possible future and the bigger the block size the bigger the effect of this change.p.s. I have created this topic to get some feedback on this opinion before I go ahead and increase the number of blocks I analyze. Each block is 2 MB raw dataCoded in C♯

♯ Have you coded a change that can be listed on git? That's a better place for this discussion. That will allow your idea to be scrutinized by people that understand what your talking about (as opposed to the fools here that just want to argue without understanding). Maybe someone on git can help you develop a proposal that leads to a pull request. At the very least, move this to the dev and tech section of the forum.

That would be some nice optimization u got there but... need of hardfork completly ruins your idea even if it will be confirmed to actually give this kind of improvement. Its too low gain (5%) to hassle, amount of work needed and danger associated with hard fork. So its something for future, if hard fork will be needed in future, maybe this will be deployed then.