100% I … hope that’s not what he meant. Definitely we don’t change the name of the coin. That would be a hill I’d be willing to die on. As I am sure many others here would be.
5 Likes
When I started deploying contracts with immutable height based locks four years ago, I knew it could eventually cause a significant headache for whoever had to implement a backwards compatible block time upgrade. I didn’t realize how many other contracts there would be until just now.
I presumed backwards compatibility for height based BIP65/BIP68 contracts based on public conversations among our old leaders. I should have given you more of a heads up, but I didn’t want to initiate the conflict.
Given the context, of how long I’ve been building with heights, and how long you had to implement the CHIP before lock in, I think that your feelings are justified and I’m truly not offended by anything that was said.
I’m just really happy we’re on a path to consensus with this great upgrade.
Hopefully we can make time locks much simpler than they were sometime in the future.
6 Likes
Me too.
No worries man – I had a personal crisis over the nLockTime thing but I’m over it now. I talked to other contract authors and they all are in favor of the current design (as outlined in the CHIP). It’s fine! I apologize for being so crazy about it. I just… it was an emotional reaction to “what Bitcoin is” – to me nLockTIme in height mode was just height.
But I was convinced by others that (1) that’s not that useful necessarily and (2) existing contracts would suffer serious damage.
So, no worries.
I’m happy with the chosen design and it was the lesser of all evils.
Thanks man.
8 Likes
Bitgree have indicated their support in Telegram & also updated their stance to approve on Consensus.cash.
5 Likes
Already had run ins with that guy. He is part of a low effort selective scammer crew.
2 Likes
Disapprove for the one minute block proposal
I want to acknowledge the large amount of work that has gone into this proposal, and understand the desires of many within this community to want to increase the block speed.
First a tiny intro to who I am, as I do stay within the shadows. Most visibly, and least importantly, I’m running the aquarium.cash transaction visualizer, and the blockexplorer.cash block explorer for all Bitcoin Cash chains. I maintain full nodes for testnet3, testnet4, chipnet, tempnet and of course mainnet – with public fulcrum/electrum services on each. The BlockExplorer website isn’t built just to be a great explorer to use (although it is and will be improved more), it’s built as a proof of concept of my connector (.cash) libraries – what used to be called FloweeBridge, but it’s grown way beyond just Flowee. And BlockExplorer runs against a very custom version of Flowee the Hub called Rapids. What I think is amazing, is the speed of these binary APIs. And with a few additional generalized indexes on Rapids that Flowee doesn’t (yet?) have, I was able to build a block explorer that doesn’t even use any databases of its own and doesn’t have much BCH logic in it either. The entire chain abstracted by the connector library. And yet it can serve a whole lot of requests per second so I don’t even have to ban the webcrawlers – I just see them as a free stress test. What other blockexplorer do we have on BCH that is able to do that?
It’s a lot of infrastructure, and it’s being built part-time beside a full-time job and a busy personal life. It’s built for a reason (and the reason isn’t to provide the explorer or the aquarium, they are just fun proof of concepts and test cases). I’m building something that I am genuinely excited for, and I’m keeping under wraps what that is other than that it already works as a proof of concept.
So this is the lens through which I am viewing the 1-minute block proposal.
Of course, 1-minute blocks are already working on Rapids, and through Connector, and on BlockExplorer. So why do I still disapprove? For one, because it increases the full header sync by a factor of 10. Traffic, compute and storage all increases by an order of magnitude, so this impacts all SPV solutions. Although we can handwave away that factor 10 by calling it minimal in absolute terms of bytes, it does mean that BCH will need 10x as many servers to serve the same amount of SPV users in the future, and users will need 10x as much bandwidth and compute. (storage is solveable). It means that slow connections can no longer carry the headers, which is the argument I made about NFC devices synching their SPV-style wallet trustlessly when only connecting with a terminal very briefly.
Nobody has produced such a payment system, and now likely no-one will. The point is mainly to look not only at what is seen, but also at what is unseen. The system that will never be built is a real cost, yet it will never be measured. I acknowledge that this argument cuts both ways – what will never be built on 10-minute blocks that would be built on 1-minute blocks would remain unseen if we never make the change.
There’s also the ‘my plate is full’ argument. Even though much of my code will work fine with the one-minute blocks, I take Tom’s position seriously. It impacts me a whole lot more than many others in this space. Like many people, he spends his free time voluntarily producing amazing codebases others can use. If we lose Flowee (Hub and Pay) from the ecosystem, that is a massive loss. I have no desire to fill that void, even though the value of my infrastructure projects is impacted massively by Flowee leaving the scene. In the past, I’ve worked with Tom to bring Flowee the Hub the updates it needed, and it has been in sync with the network since last may’s upgrade. I’m however not going to ‘take over’ that project. I just don’t have the time or mindspace or patience and skills for that. Losing Flowee devalues all the work I have done over the past many years. Yes Rapids is based on Flowee, but it’s a fast-moving stream where I don’t care for backwards compatibility and don’t worry about how a change might impact someone else. It’s a selfish branch, deliberately so. Don’t expect it to replace Hub, it won’t.
I don’t deny that it’s subjectively nice to see a block come in fast. I honestly enjoy that part of tempnet. It feels good. But what does it solve for me, and how does that compare to the costs to me? I’ve fallen in love with Bitcoin (and after the split BCH), and it always had a 10-minute block. That’s never been an issue, and it didn’t suddenly become one. There can be good and balanced reasons to turn BCH into something it wasn’t, but nothing fundamentally broke that needed fixing. BCH is doing perfectly what it was designed to do. The system didn’t break; the economic model didn’t break. The benefits and the costs are not equally distributed, I don’t consider myself getting the deal of a lifetime here.
If the community moves ahead, I’ll accept that decision. I’ll do my part for my projects but won’t take on more because of it.
2 Likes
Sad to hear that, I really hoped I could convince you. I will log it as written, but I must also address the claims.
That’s understandable, costs are concentrated on a handful of infrastructure maintainers, whom you’re part of while the benefits are diffuse and mostly accrue to people who never run a node. It may not be a deal of a lifetime for you, but the CHIP’s argument is that it’s a good deal overall, for the future of BCH, which you’re part of.
It was always an issue, and this CHIP finally gave it the attention it deserved. The first wave of altcoins happened because it was an issue. And back then (2014) 0-conf still worked fine on the one Bitcoin network. So why did all these alts even have a case for faster blocks? Even the maintainer appointed by Satoshi (Gavin) had an issue with it:
I do think 1-minute blocks would pass a cost/benefit analysis; benefits would be less variance in confirmations-for-whatever-level-of-security (e.g. wait 60 1-minute confirmations has much lower variance than wait 6 10-minute confirmations).
I think it would probably encourage mining decentralization. Easier to solo mine if you’re competing for 1.25 BTC 1-minute block instead of a 12.5 BTC 10-minute block.
… that might not be true, would have to run the numbers for disadvantage due to higher orphan rates…
I have no opinion on whether or not the adjust-difficulty-every-2-weeks should be changed if the block time was changed, but that’s something else to think about.
Disadvantage is that SPV nodes would have to download more headers, but that’s not a huge disadvantage and I think the benefits of an SPV node finding out about a re-org / double-spend quicker probably outweigh them.
One minute is not fast enough for real-time payments, so that’s neither an advantage or disadvantage.
Whether or not to change the 10-minute block time is a separate issue (with its own pros and cons) from whether or not the max block size should change. Status-quo with a faster block time would be 100K max blocks, each with one-tenth the current mining reward.
The CHIP did the work he had asked for.
It’s only header traffic (4.2 MB/year → 42 MB/year), but that does not mean everything does 10x. You clarify below but this reads as an overall claim, so just to put us on the same page.
Yes, headers do 10x. There’s no way around it. SHV is a mitigation for storage, with potential future bandwidth mitigation: skipping historical headers entirely if you can trust a recent checkpoint source (imagine node consensus SHV commitments).
This doesn’t follow from just the headers doing a 10x. The TX data per unit of time stays the same. The user’s pattern (number of received TXs in a day, week, month, whatever) stays the same. It’s just the header overheads that do 10x, everything else stays at 1x.
For BIP-37 specifically: imagine a hypothetical user receiving 1 TX (420 bytes each) every hour, 24 TXs in a day, no matter the block time.
| 10 minutes | 1 minute | |
|---|---|---|
| Headers | 11.5 kB | 115 kB |
| Transactions | 10 kB | 10 kB |
| SPV proofs | 9.2 kB | 6.1 kB |
| Total | 30.7 kB | 131.1 kB |
Multiple: 4.3x. Of course, this depends on usage pattern: more frequent incoming transactions reduce the multiple towards 1x, less frequent increase it towards 10x.
One meme sent via instant messenger is ~50 kB, how many memes or pictures do people exchange daily? Bandwidth is not the bottleneck here. Where are these users who have such horrible Internet that they can’t even send few memes a day with their mobile phones? Even the underdeveloped world has access to good enough mobile broadband. So, for whose sake would we be optimizing by sticking to 10 minutes?
Re. server CPU - the server tests individual transactions against each registered filter, so the number of tests scales with number of transactions, not with number of containers for the transactions.
And this is all assuming BIP-37 is set in stone as the protocol to do P2P SPV with. It is not. Neutrino is P2P SPV too, and there’s no fundamental reason why filter batches must be aligned with block batches. Neutrino could publish a batch once every 10 blocks, and I bet if we tried we could re-engineer BIP-37 to do something similar. There’s no need to bundle header sync with TX sync. What’s the point of merkleblock sending a header if no matching transactions in the block?
The above is considering some steady-state pattern, not initial sync where headers would likely dominate and get us closer to 10x. But for initial sync Flowee already skips around it by providing a checkpointed header blob. Headers are static cacheable data, easy to distribute, and no reason to have to drip them 1 by 1 in merkleblocks (as pointed out above). If checkpointing is fine then SHV makes the checkpointing even lighter. You just ship the checkpoint, not the blob, and the client can only download the headers he needs rather than the whole header chain, and “extend” the checkpoint every time they sync in a way that maintains initial checkpoint’s trust level.
It’s not slow for any current user. Mobile broadband is fast enough for 1-minute blocks. Is it just the hypothetical NFC transfer? NFC transfers are already too slow for 10-minute blocks.
And I demonstrated how that is already impractical even with 10 minute block time:
At the low end of NFC’s rate range the same week of 10-minute headers is already ~6 s, so contact fragility is already prohibitive. post 156 has the full case, including why the payer role doesn’t even need classical SPV.
Interesting to note that credit card tap’n’pay is ~1 kB, which is a ~100 ms tap – and even that short of a tap sometimes breaks if you wiggle, and such tap could only sync 12 headers.
With this in mind, this claim is unfalsifiable:
After activation, it will become impossible to tell: is it because we changed the block time, or because it was already impractical with 10-min, or for some other reason (nobody really cares to do POS this specific way).
Thank you for acknowledging it, even though you give more weight to the other side of the same coin.
The bchd port took @MathieuG five hours and 10–15% of a weekly token limit — the work is dischargeable. You’re not being asked to take over Tom’s project. Whether the ecosystem wants Flowee maintained is a separate question.
5 Likes
This is the same logic as “1MB is fine, it was fine from 2009 to 2016, why change it in 2017?” btw.
You could say “That was different, the rising fees were a change that caused me problems!” to which the answer is “Yes, but many of the people involved in BTC felt like that wasn’t a problem they had, and they expected you to just deal with it.”
It’s exactly the same thing.
Confirmation time has been a persistent & growing problem essentially since Bitcoin was invented (the very first altcoin’s two main changes were lower the block time and change the supply). It may not be a problem for you, but that’s just you.
And nothing about your experience is getting worse, as you can just wait 10x 1 min confs instead of 1x 10 min if you like. The only thing you’ve identified as getting worse is potentially nobody building a hypothetical project (NFC cards) that so far nobody has built anyway. Why would we not do upgrades with tons of benefits & lots of community support in favour of theoretical ideas that nobody has shown basically any actual PoW for? That’s a “seen vs unseen” argument in theory, but really what you’re saying is “let’s ignore this giant pile of seen gold we could dig up, because in theory maybe there is a tiny pile of silver below it which the digging would cause to fall into lava and be gone forever.”
Unseen consequences are important, but all high value, low risk progress can’t be stopped in the perpetual fear of unknown unknows, or hypothetical propositions that obliquely benefit from the status quo.
3 Likes
Absolutely not, and it’s sad to see you push 1 minute blocks so hard that you are arguing like this.
With the 1 MB blocksize ceiling, blocks were being filled up. This totally changed what the system was and how it worked. Transactions were not being confirmed. Fees were increasing. Vendors were stopping accepting BTC because of this. Combining many small payments into a large one was extremely expensive. Limited blocksize totally changed the economics.
And nothing about your experience is getting worse
Did you read my post? I just explained how something I invested YEARS into becomes less useful when Flowee disappears.
perpetual fear of unknown unknows
Are you actively trolling?
4 Likes
@BitcoinCashPodcast please don’t continue the polemic, I answered his concerns already and would prefer you let him engage with my post rather than get engaged in polemic with you.
4 Likes
Thanks for your courage in stating your position for the record and many thanks for the considerable contributions you have made and are making to the community.
Also many thanks to the efforts of Calin Culianu and bchautist and many others for the chip and the chip process. I consider the Bitcoin Cash governance model to be without equal across thousands of cryptos and is IMO a powerful demonstration and a key feature of why Bitcoin Cash will inevitably become sound money for the world. We have seen again and again how the chip process delivers amazing outcomes in the service of the Bitcoin Cash mission.
Stating views and contributing to the chip process is an obligation we all must share as the price for maintaining this extraordinary governance model.
I hope to complete and publish my own position statement later today and wanted to acknowledge support your statement regarding this chip. I am sure whatever the outcome of the lock-in tomorrow, I and the community stand ready to support you and others in any impact the chip may have our your efforts. Your statement adds integrity to our governance and serves to strengthen the outcome whatever that may be.
Bitcoin Cash FTW.
4 Likes
Slow blocks are worse than 1MB blocks. At least with 1MB blocks I could check the mempool and send my TX when it is clear. Slow blocks cannot be predicted,I initiate an invoice that requires a confirmation and expires in 30 minutes and block takes 40 minutes.
BCH can never grow with wildly unpredictable block times.
2 Likes
Position: Neutral (one-minute blocks and November 2026 lock-in)
Name or project: Noel Lovisa – Code Valley Software Components Market, Emergent Coding, Bitcoin Cash City.
Statement:
I am Australia’s greatest Bitcoin Cash advocate, lobbyist for Bitcoin Cash as Australian legal tender, founder, custodian, and defender of Bitcoin Cash City, creator of Code Valley software components market, and currently responsible for greater than 22% of all Bitcoin Cash blockchain economic activity world-wide.
My position on the CHIP-2025-03 Faster Blocks for Bitcoin Cash is Neutral for the following reasons:
-
Impact : Moving to 1m blocks will not impact me, my businesses, technology partners, merchants of the Bitcoin Cash City, or any users I know of. I will be surprised if any merchant will notice any change should the CHIP go ahead. The killer app for Bitcoin Cash is CASH and our superpower is 0-conf. Moving to one minute blocks will not change the extraordinary speed and utility of 0-conf in any way. I disagree that 1minute blocks will reduce 0-conf risk as the bulk of the 0-conf risk occurs in the first second after the transaction is broadcast. Merchants already have excellent tools to detect DS fraud (even without DS proofs), make an arrest etc., regardless of which transaction is eventually confirmed.
-
Nostalgia : While 10min blocks is mentioned in the Bitcoin whitepaper, I note it is only by way of an example in Se ction 7 – Reclaiming Disk Space . However 10min blocks was selected by Satoshi and embodied in the first node implementation and I consider this parameter a tangible link to Bitcoin Cash’s roots as the real Bitcoin and legitimate custodian of the Bitcoin mission. After the hijacking, Bitcoin Cash took the high moral ground of restoring the original cash properties of Bitcoin. It might only be me, but I would love to maintain this link with Bitcoin for the day when Bitcoin Cash is again called Bitcoin.
-
Resources : Moving to 1 minute blocks effectively increases the block header size 10 fold compared to its transaction content. While this is hardly a showstopper for me, and would of course be barely noticeable when that happy day arrives whereupon Bitcoin Cash has overtaken the world’s credit card processors and is fielding ~2.2 GB blocks, we are advocates for on-chain scaling, and I feel we should be constantly improving our block efficiency at every step.
While I personally respectfully disapprove of this CHIP, I register Neutral and hope others may realise an advantage outweighing weakening our link to the original Bitcoin. I respect the CHIP process and will do my utmost to support whichever outcome succeeds. I want to thank Calin Culianu and bchautist, and many others for the enormous effort put into this CHIP. It is an impressive body of work and another great example of the extraordinary performance of our unique governance model. Anyone taking a look at this, or any other CHIP, will be compelled to cite Bitcoin Cash as the leading candidate for global money. While not an obvious feature, our governance provides businesses and industry the quiet confidence to proceed with Bitcoin Cash plans, development, and adoption knowing the Bitcoin mission is in safe hands.
3 Likes
Thank you Noel, much appreciated. I’d like to address some claims:
That’s true, 0-conf already works and it’s great. The aim is to improve the UX in cases where 0-conf has to fall back to 1-conf. Everyone wants to be a 0-conf user, but sometimes the experience gets degraded to 1-conf (DSP score or event) – and this is under recipient’s control, not the sender’s (who always wants 0-conf).
That’s only true for a specific kind of double-spend: simultaneous broadcast of conflicting transactions through public mempool. Anyone-can-spend type of UTXOs can be simultaneously accessed by many users and create unintentional double-spends. If transaction spending that UTXO is then extended in a 0-conf chain to pay some merchant it could get reversed without DSP firing, and with plausible deniability since anyone can double-spend the parent transaction. For such transactions DSP score will be 0 to begin with, so guidance is to require 1-conf for such payments, which is the rough edge faster blocks improve.
If we win, 1-minute block time (or lower, or adaptive) will be seen as the Bitcoin! 
In his statement, Andrew#128 (BCHN & Electron Cash contributor, CashScript-Py maintainer) delivered this gem on the subject:
I have been concerned that changing the 10 minute schedule is distorting the coin too much from its fundamental design. Not because Satoshi established the schedule, but because “10 minute blocks” often tops the bullet-point features of Bitcoin, so it will be an obvious major change if we go to 1 minute blocks.
Bitcoin Cash should have been crowned the BTC ticker at the split and I have always wanted us to be in the best position to contend the throne. But, now that BTC’s reputation is declining; as out-of-date, slow and expensive, with increasing involvement with the dinosaur financial establishment; I am now more motivated to distance ourselves from them. The 10-minute block time itself is easily understandable as one of these old, out-of-touch policies that results in the coin being unwieldy. So let’s break away from it.
It really is unique. And we will only make '27 because of all the people who shown up became proactive in helping the CHIP move forward. CHIP must do the research, which the sole owner can do. But that is not enough. It must also be compelling enough for others to want to help it move, to inspire action in others, and success depends on action of all the others.
5 Likes
Why is the CHIP process NOT focused on the user experience?
How hard can it be, in times of AI, to integrate the future BCH API into a real world application, to then build out an A/B testing frontend, to proof that the hard fork that they are vouching for does actually pay off, meaning the improved user experience outweighs the cost of maintenance and risks of failure?
Why are BCH devs building things without integrating the user base into the decision making process so they realize it is worth investing into BCH?
Why are devs building any feature without asking for funding via flipstarter first?
It would be easy nowadays to integrate the investors (flipstarter) and the users (A/B testing) into the CHIP process, when will that process be updated to meet modern requirements of quality assurance?
Feel free to organize A/B testing with your users. Tomorrow you will have chipnet with 1-min blocks (A), and mainnet with 10-min blocks (B).
2 Likes
I made such a dashboard at https://tempnet.bch.ninja that compares tempnet and chipnet side by side.
Tomorrow I will update it to show chipnet and mainnet side by side.
3 Likes