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.
Would this not damage existing long-term smart contracts? Wasn't this one of the objections to grasberg?
Yes. I don't think it's worth it. IMO developing pre-consensus mechanisms like double-spend proofs should be a priority.
Maybe. But how many longterm smart contracts do we actually have on BCH? Wouldn't the benefit outweigh the need for a few contracts to be cancelled/rewritten?
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 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.
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
This does not change the instant 0-conf usecases, but it would make the network seem quicker I think.
