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.
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.
For some usecases, one confirmation of a 2.5 min block will be sufficient although is is technically not as secure as a 10 min block. 1 conf will signal that the payment is now settled