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 too
BCH's frequent slow blocks is the outcome of low relative hashrate and swing mining.
This can only be solved with a hashing algorithm change.
I tend to agree. We will probably have to change hashing algorithm if we keep loosing hasrate vs BTC.
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.
