What is the particular reason why you are refusing to change the batch size?
Is there some real concern or a significant problem with such a change?
I would assume there must be a strong reason why you didn’t just do it instantly and instead came here to express your dissatisfaction with the CHIP?
there has never been more rejection to any BCH update than this one
shoving that update down the throat of everyone INVOLUNTARY is absolutely insane
we all agreed that BCH was worth it until now, well it depends, i do not know how invested some people here are who make this decision and have the control over the repository, some devs might have zero holdings and some might have made more salary working on BCH than they had ever invested
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
from my perspective the attitude HOW this update is ordered top down is totally contrary to what Bitcoin as a voluntary bottom up movement stands for
from my perspective it is so absolutely insane that my only explanation is that the objective is to harm and demonstrate that BCH is as corrupted as BTC
this update is not about technology it is about philosophy, there is no technical challenge in changing the block time but the effects it has on the whole ecosystem are immense
$5,559,659,576 is the total market cap of BCH and i wonder if these who make the decisions here have only 1% meaning 55 million invested into BCH
Has anyone reached out to Binance?
Sent them a query just now, and I will continue sending requests to all other stakeholders using the “Standard Approval Request Template” here: stakeholders.md · master · ac-0353f40e / Faster Blocks for Bitcoin Cash · GitLab Update: e-mail to support@binance.com bounced, I’ll try some other channel. Edit2: someone gave me another e-mail, sent and it didn’t bounce.
I think SHV solves this. If you think there is a better alternative, can you give us a solution we can study and test? SHV seems like a good solution to pair with 1-minute blocks. When SHV was proposed for BCHN, its initial review by @cculianu noted that supporting these proofs for light clients “mitigates like 80% of the concern regarding faster block times”. I don’t understand the concern exactly, as I feel most of it has been addressed. Most of the Bitcoin Cash community is putting effort into making this upgrade as smooth as possible. I have never seen the community this alive and active before, with everyone trying to help in their own way.
Thanks for mentioning this. There is also current progress I have already addressed most of @quest review in the BCHD PR: each getshv now gets exactly one shv reply with a status per entry, oversized requests get an empty reply, and heights are compact size. The remaining points are wording changes to the CHIP itself.
There is also a PR for Knuth, in anticipation of 1-minute blocks: https://github.com/k-nuth/kth/pull/805. Once it’s merged in BCHD, I will follow up on Knuth and ask @fpelliccioni to review it.
The below table is quick snapshot of the effort on the current SHV implementations (CHIP-2026-02) status, as of 6 November:
| Software | Role | Status |
|---|---|---|
| BCHN | Node | MR !2045 closed on 7 October as a proof of concept. As I understand from @bitcoincashautist comment, it might get re-implemented later with the index on disk instead of RAM, once the P2P messages have had more feedback |
| BCHD | Node | PR #769 open. The index is kept in RAM (about 30 MB, rebuilt from the block index at startup), so every proof is served straight from memory. Review found the construction solid; its message changes are already in the PR, and the remaining points are CHIP wording |
| Knuth | Node | PR #805 open as a draft, with the same in-RAM index as BCHD; to follow once the BCHD PR is merged |
| Fulcrum | Electrum server | Already serves the proofs SHV uses (blockchain.block.header with cp_height); per the CHIP, Electrum servers need no changes |
| OPTN Wallet | Wallet | SHV client code is in v1.7.4; PR #103, which uses it for sync recovery, is open |
| XO | Wallet | SHV for headers announced on 8 October |
| Electron Cash | Wallet | PR #3205 open since March: smaller proof-backed header chunks when checking old transactions |
First wave of e-mail outreach sent: https://gitlab.com/0353F40E/fablous/-/commit/cdc408b2cf8b6789878470ce156944a7e40b1412
Did you miss this response? CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent) - #43 by bitcoincashautist
That may be when compared with disapprovals for past CHIPs, but it’s still outweighed by all the approval & support which is also bigger than for any past CHIP!
And the support came not only in words (talk is cheap), but in concrete actions: people helped with outreach, operational support, built things like consensus.cash, started addressing concerns on CHIP’s behalf without me having to do everything, proactively built testing infrastructure, helped reproduce CHIP’s security claims, helped review CHIP & code with their AI agents, etc.
How can you claim that it is top down when there’s overwhelming evidence it is not: this CHIP has shown incredible grassroots support! Users have wanted faster blocks since forever, and the CHIP is just a vessel to deliver that.
Anyway, Binance has been now been contacted by both me and @ABLA and the support escalated to “appropriate channels” and we could get an answer in 1-2 business days.
No offense intended, but I recognize this account and it is the account of one of biggest troublemakers/trolls in BCH ecosystem that constantly spewed conflict and controversy over the course of last 6-8 years.
I am 100% disregarding anything this account has to say and recommend for everybody else to do the same.
You should seriously disregard and ignore whatever @realbitcoinclub has to say, he is disingenuous and is posting here in bad faith.
I have been a moderator for 5+ years, I have high level of expertise in this matter.
Yes, I know him since ABLA. His first post in this thread was OK, but then he ruined it with the 2nd one. Oh well…
Ultimately that account does not seek resolution and is not constructive, so it always ends up that way. It seeks trouble and controversy, it is highly adversarial.
it does not.
They are completely different things.
Would you kindly be so nice and answer the question please, Tom?
Before you ask: You know which question.
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.
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.
That’s your opinion; your mistaken opinion, however.
I respect your freedom to say it, but what you are saying makes no sense.
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.
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.
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.
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.
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.
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:
Thank you for the support and kind words, much appreciated!
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.
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. 
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.
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.