CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent)

[ShadowOfHarbringer]

Would you kindly be so nice and answer the question please, Tom?

Before you ask: You know which question.

[bchvenezuela]

@realbitcoinclub

there has never been more rejection to any BCH update than this one

I disagree with this statement.

This time, more people are discussing the matter—which is natural, given that some previous features involved more technical aspects. But approval is not outweighed by disapproval, and there has been much respect for the opinions of those who dissent or are skeptical.

@realbitcoinclub

i doubt that even 10% of the total user base would support this update and the craziest thing is that major stakeholders are not even asked or reached out to like it was done when cashtokens were introduced (…) the attitude HOW this update is ordered top down is totally contrary to what Bitcoin as a voluntary bottom up movement stands for

We are aware of the views held by those who have participated in the conversation, shared their opinions, or expressed interest. None of those who have expressed themselves for or against have been censored. Claiming to represent an abstract, hypothetical “majority” that is supposedly silent—yet “defended” by the person speaking—is not a serious argument. It is merely an assumption, a piece of self-serving speculation regarding the matter.

It’s a completely different matter if you expect people to ask for permission or stop supporting something just because you say “stop everything, I don’t see how this benefits the use cases I’m limited to”.

That’s NOT what voluntary and permissionless means.

@realbitcoinclub

the objective is to harm and demonstrate that BCH is as corrupted as BTC

That’s your opinion; your mistaken opinion, however.

I respect your freedom to say it, but what you are saying makes no sense.

@realbitcoinclub

I use USDT because BCH deposits are just way too slow on Binance, they require two confirmations to acknowledge the deposit

With Fablous, even if they move to asking for 20 confirmations, it will be faster due to the impact of the greater granularity on the variance. Perhaps you don’t deposit BCH on Binance, and no one would force you to, but 1-minute blocks have a clear impact on the user experience that they do.

@realbitcoinclub

I wonder what would Binance do when the block times change from ten to one minute, would they simply ramp up the deposit confirmations 10x?

They could do that; or they could choose a number between 1 and 10 confirmations; or they could choose a number close to what they require for cryptocurrencies with faster blocks.

Even if they multiply the requirement by 10, the shorter wait time is clear.

@realbitcoinclub

I would want to have statements from mayor stakeholders, especially from Binance, to figure out how they would react on lower block conf times (…) Binance has the biggest BCH wallet of any other user, they should definitely be contacted and be asked for a binding statement

Asking them is fine. You could ask them yourself.

Other users have actually commented that they themselves would ask.

What we won’t do is ask Binance for permission.

@realbitcoinclub

BCH will not be Bitcoin anymore as it would not follow the white paper anymore (…) to be the “real” bitcoin would not be an argument anymore

Sowing doubt about whether BCH is Bitcoin has been your position since I’ve seen you in the BCH ecosystem (you wondered if the real Bitcoin was Dash or something else), so it doesn’t surprise me that you’re saying this this time. People who don’t believe that BCH is a branch of Bitcoin won’t change their minds just because “Fablous” is being cancelled; and this doesn’t change the fact that BCH is a branch of Bitcoin, nor does it distance it from the whitepaper.

With all due respect, you are welcome to stay in the BCH space IF you wish.

If you wish to proclaim some other coin—such as Dash, Doge, Zcash, or XEC—to be the “real Bitcoin,” that is fine; If you don’t want to touch BCH anymore after that update, nobody is going to force you either. But don’t call the voluntary and peaceful action of those who support 1-minute blocks without attacking anyone a top-down movement of a few developers, because that doesn’t match reality.

[ABLA]

@ABLA

So I’m Neutral on activation for now , and will move to Approve once there’s enough confidence that the implementation is ready and safe.

I think my actions have already demonstrated my excitement for 1-minute blocks. My only concern was the technical implementation around it. However, given the information currently available, along with the confidence and endorsement from the technical side, I Strongly Approve of 1-minute blocks and hope the upgrade goes smoothly.

[albaDsl]

I’m updating my statement from disapprove to cautiously APPROVE. In general I believe we can’t rest and need to continually move forward with the Bitcoin Cash consensus design (hopefully allowing the design to gradually converge). Each step forward has to be deliberate and we can’t afford costly mistakes. It is like walking a tightrope: one can’t stand still for long but also can’t make a misstep.

I have great respect for Calin’s work and technical judgment and appreciate that he is open about his reservations about some aspects of the design (https://x.com/cculianu/status/2118422295077441864). It is not ideal to see these concerns before lock-in. At the same time, Calin seems sufficiently comfortable to move forward with the CHIP. The change is reversible and can be tweaked down the road. If necessary, some of the concerns Calin brought up in the post (10x header increase and a 10x difficulty reduction (before aligning the miner-only validation rules)) could be addressed with a more conservative drop to say 2.5 min blocks.

I think the fast advancements in SI and quantum exert a pull on the block time downwards (a desire for increased margin for the lead up to “q-day”) and increase the urgency to move forward on this. At least until alternative algorithms can be efficiently expressed on the VM and are rolled out.

As mentioned before, I believe reductions in block time increase the rigidity of the Bitcoin Cash system which in turn lowers its resilience to network storms. Something worth keeping in mind going forward.

On the benefits to the user experience: I have no doubt end users will be happy with this change (though there is also a risk for some breakage in the wider ecosystem).

Great respect to bitcoincashautist for authoring the CHIP and driving it forward!

My previous statement:

https://bitcoincashresearch.org/t/chip-2025-03-faster-blocks-gathering-statements-of-support-and-dissent/2095/99?u=albadsl

[bitcoincashautist]

Thank you for the support and kind words, much appreciated!

@albaDsl

As mentioned before, I believe reductions in block time increase the rigidity of the Bitcoin Cash system which in turn lowers its resilience to network storms. Something worth keeping in mind going forward.

FWIW this has been on my mind ever since you and @vac raised it. If we were to reduce further I think it should come with a “safety valve” algorithm where any 1 miner could commit all orphan block headers from some epoch to prove orphan rate has become too much for whatever reason – and then algo would slow down for a while – and later, if conditions permit, come back to the hardcoded floor. I actually want to research this next.

[bchvenezuela]

@bitcoincashautist

If we were to reduce further I think it should come with a “safety valve” algorithm where any 1 miner could commit all orphan block headers from some epoch to prove orphan rate has become too much for whatever reason – and then algo would slow down for a while – and later, if conditions permit, come back to the hardcoded floor.

Something like “ABLA” but for temporarily achieving a less frequent block time? It sounds like a mechanism you could have to temporarily shift the block time from a few seconds to 1-min.

It sounds like a nice idea, however, although I’m not an expert in cryptography, by analogy it seems to me that if implemented too lightly, it could be gamified to manipulate block time and alter the perception of BCH’s stability. That would worry me.

Even so, I think it could be debated whether that gamification can be avoided if we need it when the network is optimized (and the technology allows it) to have blocks of less than 1 minute without stressing the entire infrastructure too much.

For now we can focus on 1-minute blocks.

[BitcoinCashPodcast]

@bitcoincashautist

If we were to reduce further I think it should come with a “safety valve” algorithm where any 1 miner could commit all orphan block headers from some epoch to prove orphan rate has become too much for whatever reason – and then algo would slow down for a while – and later, if conditions permit, come back to the hardcoded floor. I actually want to research this next.

Gosh this sounds amazing.

As ever, I am a fan of algorithmic flexibility built into BCH parameters. That’s just so powerful - takes a large effort to do right once, but pays off forever. Every day, while we’re all just quietly going about our business - things like the DAA & ABLA. Hopefully soon also minimum fee floor, maybe blocktime within some bounds like you suggest.

Looking forward to hearing more about this.

[ShadowOfHarbringer]

@bchvenezuela

It sounds like a nice idea, however, although I’m not an expert in cryptography, by analogy it seems to me that if implemented too lightly, it could be gamified to manipulate block time and alter the perception of BCH’s stability. That would worry me.

Yeah, the idea of completely dynamic block time seemed genius af first, but then I read your post.

It would seem allowing miners to change blocktimes on the fly would open another huge attack surface that has not been researched yet.