I am thinking that reducing the block time for BCH to 2.5 or 5 minutes would be helpful for those usecases where a single confirmation is need. Would also largely prevent these super slow blocks >1 hour.This does not change the instant 0-conf usecases, but it would make the network seem quicker I think.
Any changes made now that jeopardise existing smart contracts (if there are any) would deter people from using BCH to make smart contracts in the future.I fear this is a case of *perfect* being the enemy of *good*.
lowering the blocktime really doesn't mean anything as u would need to wait for more confirms for the same certainty. also the blocksize limit/scalability would have to b replanned tooBCH's frequent slow blocks is the outcome of low relative hashrate and swing mining.
This can only be solved with a hashing algorithm change.As I see it, the BCH community is too close minded currently to make this change. This hinders functionality and adoption.Somewhat of a workaround would be to refine 0-conf adoption/acceptance. By default, the probability of double-spending decreases with the time passing between blocks.So it would be rather easy to make it good enough for most point of sale usecases.
Overall, it's a rather overblown issue affecting the crippled btc network.