Will that lead to more blockchain bloat or not? There is also the mining centralization issue that comes with bigger blocks.
miner centralisation?? nope
you do know that an ASIC has no hard drive.
ASICS do not store the blockchain and do not care about the data of a block or how big a block is.
an asic is just handed a hash and told how many0000 at the start of the solution is needed for a solved hash
1byte of data
65c74c15a686187bb6bbf9958f494fc6b80068034a659a9ad44991b08c58f2d2
or 1000byte
e6631d63c97fb6d9239bd7d1d0a8878e3ea383722635051f94efc5b2790fc441
or a gigabyte
442aaa99d16cf451b853451fbb0515ed696985f236924adf682b34e9531472b1
the hash a asic is given is the same length
the POOL/nodes however that do validate tx data need to ensure they do it in a timely manner.
for instance v0.12 had a txsigop limit of 4000ops.. and a blocksigop limit of 20,000ops
a malicious person can make 5 transactions of 4000ops to use up the blocks limits.
lets say it takes 0.01sec to process 4000ops
that becomes 0.05sec to do the whole block.
now imagine. instead of having
1mb block with 4,000txsopl and 20,000bsopl
we had
2mb block with 8,000txsopl and 40,000bsopl
using native keys quadratics would take 1min 40 seconds for the 5 tx's
where as if we had
2mb block with 4000txsopl and 40,000bsopl
using native keys even with quadratics would take 0.10 seconds for 10tx's
thus alleviating the quadratics scare because your not allowing a single transaction to multiply up the sigops. but allowing more transactions per block.
the real silly thing is,
core have actually put in
1mb base 4mb weight block with 16,000txsopl and 80,000bsopl
which is incredibly stupid and allows native key sigop spammers to do alot within the baseblock
if basing the block sigop limit on the weight. they should be doing
1mb base 4mb weight block with 4,000txsopl and 80,000bsopl
which would allow 20 bloated maxed out tx's instead of 5. but the timing would only be 0.2sec...
not hours and only five maxed out spam tx's that core 0.14+ allows
but now im just ranting.