Since my last statement, there has been additional outreach, implementations and a tempnet. I formally approve of the fablous for lock-in this year and activation in may next year.
8 Likes
As we reach the final lock-in phase—following extensive efforts by the developer community to launch and operate the testnet, and with major nodes successfully completing synchronization—it is worth noting that there remains a substantial period (over half a year) after the lock-in phase during which the network can be further refined and tested. @joemar_taganna @emergent_reasons
Taking everything into account, and considering the needs of various user groups—even though I am not a primary beneficiary—it may well be time to resolve this matter.
I will continue to monitor the status of the primary BCHN node implementation and the level of support from other nodes. @cculianu
As an individual investor who conducts thorough research (approaching “small whale” status)—and also representing two local e-commerce businesses, the Bitcoin Cash Taiwan community, and a small-scale project (1KBCH)—we have decided to shift our stance from “neutral” to “supportive.”
Additionally, as heavy users of CashFusion, we would appreciate some clarification: will it be affected, and is anyone already working on adjustments?
Wishing you all the best—let’s go (LFG)!
7 Likes
Thank you, couldn’t have addressed it better myself! Ping @quest too.
Yes, it’s an ambitious change. Play to win, not to not-lose!
3 Likes
It bears repeating that tests have shown that faster blocks make synching clients block-by-block become too slow and cumbersome when they are not always online. Effectively making it no longer a viable way to sync mobile clients.
This has the effect that in due time the only way for clients that are not always online to get their updates in a user friendly manner is using a server like fulcrum.
Should this CHIP activate there is no future for the currently only client that uses this sync method: Flowee Pay.
I have already stopped working on it some months ago when my explaning this to the chip owner fell on deaf ears. So this is not a threat of anything, it is more a confirmation that I already stopped participating in Bitcoin Cash.
I do feel I need to give people the full information, as I have always felt that Satoshi was right that this is the only way to scale to a millions of users. And it is taken away.
1 Like
Your own code contradicts this claim. It bears repeating that it’s pretty easy to unslow the client: by changing batch size from 10 to 100, which will make the same wall-clock-worth of blocks sync in about the same time and same number of round-trips.
That’s your decision, made by refusing to make a little adjustment to how clients sync, and continuously hand-waving the obvious solution. You could’ve joined everyone in contributing to making 1-min blocks happen, but you yourself chose this other path. Anyone can fork the client, make the adjustments, and keep using the client post-upgrade, so it’s not really lost – assuming at least some people still want to use it.
First, BIP-37 can continue to work fine with 1-min blocks, as evidenced by Dogechain wallet: https://github.com/dogechain-team/dogechain-wallet-docs/blob/main/docs/understanding-spv-lightweight-wallets.md
There is no fundamental reason why BIP-37 should be sensitive to block time change. It just needs a little engineering effort.
Second, Satoshi didn’t prescribe BIP-37 as “the only way” to do SPV. There’s also Neutrino, which will be revived very soon in BCHD thanks to @quest and @ABLA efforts, they’re even implementing SHV over P2P! https://github.com/gcash/bchd/issues/768
So, nothing is taken away.
3 Likes
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?
3 Likes
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?
1 Like
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.
4 Likes
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 |
3 Likes
First wave of e-mail outreach sent: https://gitlab.com/0353F40E/fablous/-/commit/cdc408b2cf8b6789878470ce156944a7e40b1412
4 Likes
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.
3 Likes
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.
5 Likes
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.
3 Likes
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…
4 Likes
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.
3 Likes
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.
1 Like
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.
7 Likes