why BCH Bitcoin Cash did not get the support
Because they hard-forked without any reason, just like BIP-110. Increasing block size in a soft-fork way is possible, and it happened, which is why we have up to 4 MB blocks now.
bigger block sizes in MB megabytes mean more centralization
This also happened anyway. Currently, it is more likely, that you will find someone asking "how to make it in Electrum", rather than "how to make it in Bitcoin Core". There are many users with SPV wallets, using block explorers, exchanges, and getting fully or partially custodial, banking-like experience, where they don't verify everything, and just check some simple things, while trusting that everything else is fine.
Isn't BIP110 Blake BTC bringing up the same argument
Their current consensus doesn't use double SHA-256 for block headers. They could skip the first 961,639 blocks, set 00000000000000000001bbc439e13f749dca850d32c7a2834165338713027e65 as the permanent previous block hash, preload UTXO set from this point, and remove hundreds of GBs from their chain, because reorging beyond this hard-forking point would make their chain useless anyway, so there is no need to validate these blocks, if they consider SHA-256 to be obsolete, captured by pools, attacked, or whatever (while also using it in transaction IDs, and a lot of other places, because replaying as many transactions as possible is beneficial for them, because they can get more coins in this way).
Im trying to make sense of this after watching youtube vids and asking Ai.
Good luck. Meanwhile, their chain contains some data pushes, and it seems they won't block all ways of pushing it anyway.
Some examples:
https://bitfiles.io/btcb2This transaction is considered as valid by BIP-110:
https://mempool.guide/tx/898c9c3e8bad6604e7be8b9d8c0dabbf4a6e7e3853b0354484d8ce19176b199dAnd it contains this image:
https://bitfiles.io/btcb2/898c9c3e8bad6604e7be8b9d8c0dabbf4a6e7e3853b0354484d8ce19176b199dWhile this one is rejected by BIP-110:
https://mempool.space/tx/909b486928dc415d9b6613fcc70ccdbfb4d2f88516a040522365b95794774608Even though accepted BIP-110-equivalent pushed more data:
https://mempool.guide/tx/61ff0a1070b084d2601245056946480917a5f3efcb30fde082e7dafbd2b17158non-BIP-110: sending to P2PK + spending it: 204 bytes + 305 bytes = 509 bytes
BIP-110: sending to P2WPKH + spending it: 191 bytes + 339 bytes = 530 bytes
So, by blocking P2PK, they actually increased data consumption in historical blocks, for absolutely no reason. And OP_RETURNs up to 80 bytes are still allowed by BIP-110, even though all valid P2PKs are smaller than that, even for uncompressed keys.
Images and videos do not occupy even 5% of Bitcoin's block space, so there would be next to no effect to storage efficiency.
Even if they do, then it still doesn't matter. All historical block data are spammy from the current users' perspective. Would people care in 2110, if some transaction from 2010 used P2PK or P2PKH? They probably won't. Even today, there are many SPV users. And even in early days, people decided to grandfather in some bugs, instead of reorging the chain, so blocks
91812 and
91842 are using identical coinbase transactions. Guess what: nobody decided to reorg the chain around that time to fix it. And nobody will do it now, after so many years.
Most people care mainly about 288 or so recent blocks. Reorging anything beyond it will break some pruned nodes. Reorging things beyond 100 confirmations will affect coins spent by miners. Historical data are important for users, but network doesn't care that much about it, and nodes could stop providing it in the future, if it would be too difficult. Because any weird bugs will be simply grandfathered in, just like transaction
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599 was added as a permanent exception.