Create account

Fnuller15
57d
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.
replied 57d
Would this not damage existing long-term smart contracts? Wasn't this one of the objections to grasberg?
replied 57d
Yes. I don't think it's worth it. IMO developing pre-consensus mechanisms like double-spend proofs should be a priority.
Fnuller15
replied 57d
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?
replied 57d
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*.
replied 57d
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.
Fnuller15
replied 57d
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
Fnuller15
replied 57d
I tend to agree. We will probably have to change hashing algorithm if we keep loosing hasrate vs BTC.