Actually, BCH is (one of) the market leaders. E.g. BTC is not a competition, virtually everybody here knows why. USDT is not a competition any more than USD is. Etc…
1 Like
Literally all of BTC, USD & USDT are BCH’s competition. All crypto & fiat currencies (in fact, all objects literal and figurative in existence) are competing to be the most accepted currency.
So we need to be as good as we can in that category, because there’s so much competition.
Funny. OK, a proof:
-
BTC has resigned on the media of exchange function. So, no, it is not a competition of BCH in the media of exchange competition.
-
USD is a competition, actually the strongest one.
-
USDT is not a competition, since by definition, it cannot survive USD’s defeat.
1 Like
Actually, the claim about economical benefits of cutting the block times is easy to falsify: It suffices to take examples of coins that have cutted their block times and check how it influenced their market capitalization compared to average coins not doing that.
2 Likes
“X is responsible for price move” is not a falsifiable claim, we don’t have multiverses in which we can examine how just changing the blocktime and keeping everything else equal would play out. Everything else is not equal. How do you know it’s not something else responsible for mcap of those other coins?
Zcash had a 2 year bull run immediatelly following faster blocks activation. Can I prove that faster blocks were the sole cause? I can’t. Can you prove they didn’t contribute? You can’t.
Other coins are mentioned in the CHIP not to prove blocktime-mcap relationship but to falsify the claim raised by critics that changing the block time will break exchange & wallet support etc.
Reducing block time will improve UX for all BCH users, regardless of what the price does.
2 Likes
Indeed.
Seems like we need a new name, perhaps “Price thinking” for this style of argumentation. As we gain prominence, we’ll get more BTC migrants bringing their “Price is an unqualified complete argument” ideas. Price is downstream of value delivered by the ecosystem, albeit it does loop on itself through liquidity increases & marketing hype (rising price is obviously good). But this subtlety escapes many and emerges in this simplistic price-based analysis.
2 Likes
Although in my own personal opinion 1 minute blocks will help price, I think it is important that we refrain from any price arguments in regards to this CHIP.
Please keep it to technical arguments. No one actually knows or can know the effect on price.
4 Likes
Confirmation time is so important that ETH L2s are trying to find ways to innovate from a 2 second block time down to a 0.25 second block time!!
3 Likes
We’ve integrated Flashblocks, built by the team at Flashbots, reducing effective block times from 2 seconds to 250 milliseconds.
So I assume these “FlashBlocks” would be something like Infrastructure Blocks, but on ETH? Also with PoS instead of PoW?
Did I get it right?
PoW L1 will always be limited by practicalities like orphan rate and non-pruneable overheads.
Still, if we have a reliable L1 then us too can experiment with some PoS L2 (stake BCH to some L1 contract to become validator on L2) for high frequency trading or bespoke L2 for a retail payment solution.
L2s have their own risks and trade-offs, and our L1 needs to be good enough to keep enough volume on L1, because our security and future depends on L1 volume. That’s why we still need 1-minute blocks even if we could get 0.25-second blocks on an L2.
4 Likes
This brings to mind the very insightful story of the technical guy that did marketing, he explained all that was awesome about his product and, as he is technical, noticed the problems in his explaining of how awesome the product is. He added that in the next release those issues will be fixed, however. It could be easy to overlook the fact that the product was indeed by far the best on the market.
The predictable result was that the people didn’t buy the product. Only very few got sold because the would-be customers ended up waiting for the next release. The end result is that the company went bankrupt.
The story illustrates that product quality and market share are not at all the same thing.
Being the best doesn’t lead you to be ‘market leader’. And vice-versa.
This is all a long explanation of how Jeremy is utterly wrong about the above quoted conclusion. In a very dangerous and destructive way!
The way to get Bitcoin Cash marketshare to increase is based on first determining what your market is (how do you measure market share). Do you want to optimize for high price, or for lots of people using it as cash?
Most important step here is to realize that Bitcoin Cash is already actually technically superior over the vast majority of its competition. Which, as soon as you accept that, leads to the obvious question: but why are we not leading in those measurements we set ourselves as goal? In other words, why are we not market leaders?
This is when you really can get stuff moving, realizing that the product as is (the coin, the consensus rules, the community) is healthy and strong.
Then we can move to try to sell it to real people. Find out what needs work. Block waiting time is obviousy an annoyance, but not having repeat payments is a bigger one. Not having a 1000 different features that the banking system offers companies and users today are really quite a big more important to the sales-pitch than sometimes needing to wait.
Because at the end of the day, the competition is what people use already. Which is the banking system using fiat. Which is the products the banks and card companies ship. The apple pay / google pay / 𝕏 pay. What do they have which the bitcoin cash experience lacks? Can that work be done in services and wallets? Or does it REALLY need to be the coin that is changing?
The focus on “changing the coin” is misguided. The product is easily better than most (all) of the competition. If you don’t believe that, what on earth are you doing here?
If you DO believe that, go out and sell it. Go out and improve the wallets and the services to be able to do what people expect from a financial system.
Stop trying to push technical debt into the core of the coin because you think that helps you sell it easier. That’s just lazy.
ps. as an aside, the term “market leader” derives it’s name from the leader being the first. Not the most successful. The market leader is very often the first to market and gains the most as a result. Dictating the market as a whole.
This also answers why market leaders are actually quite often NOT the technical best. Are often not the ones with the most features.
This further illustrating the point in bold at the top of my post.
1 Like
Here is take in another context; first mover is extremely strong way to get a big market share. While often actually being the weakest technically.
This ties back to the bad take that in order for BCH to rise in price, it needs to technically be improved. This bad take is extremely damaging to our self-confidence, rating our technical-capabilities based on market value is not a good idea at all!
Lets make the rest of the world aware of what we already can do with the bitcoin cash chain. 
1 Like
Why not do both?
When I came back into BCH the ABLA upgrade had just happened and I was super excited to see all the technical advancements that happened while I was not paying attention to BCH.
People will slowly trickle in, when they do show up it is a great strategy to have all the technicals in place so they can fully switch to BCH as it will be capable of everything, and doing it well.
1 Like
Protocol upgrades are not paid by the people that decide they want to have them. They cost “us” all. They are a one time tax that companies have actuall stated are a reason for them to not support Bitcoin Cash.
The cost is mostly invisible to the many people discussing it on this forum, as they are not business owners, they are not node maintainers or infrastructure maintainers. The many people here discussing things like ‘faster blocks’ are essentially arguing for free cool stuff that “somehow” happens with nothing more than them saying loudly that they want it.
But changes are not free to many others. Those maintainers, devops, designers, testers and many others need to put time and effort in it while getting mostly nothing in return.
And we are doing that, there are quite a lot of upgrades planned for 2026. Some more planned for after.
The cost/benefit of such changes is something that needs balance.
1 Like
Heads up that Tom is desperately trolling for attention. He’s not going to make any logical arguments, he just wants someone to reply. He’ll say whatever he can to try and bait someone into asking him about it. He wants it so badly he was replying to his own posts to try snag someone & unfortunately you bit.
Just be aware of this pattern for future interactions.
At this time there’s no indications mods will put a stop to it, but it seems mostly everyone has learnt to avoid it regardless.
4 Likes
Wanted to share a blogpost @bitcoincashautist & @BitcoinCashPodcast brought up in Telegram that has been stuck in my mind. Jihan Wu supported shorter block times, and this old argument from the early days deserves more attention in this discussion.
Back in November 2017, he proposed it in the Chinese community and got immediate pushback from most people. But after a year, the majority flipped to support. A survey of the Chinese core communities found over 61% of supporters had originally been opposed before changing their minds. The BCH block size debate taught us that, sufficient discussion and patience tend to bring people around.
He basically had the whole CHIP written as a medium blog post back in 2019: https://medium.com/@ChangyongLiu/proposal-to-shorten-the-block-time-of-bch-1d7e8e897497
- Two highlights worth reading from the blogpost:
-
On 10 minutes vs 2 minutes doesn’t matter.
Lol this one is funny
-
Why do we need shorter blocks when we have 0-conf
His arguments are in favor of making 1-conf faster because shorter block times and 0-conf aren’t contradictory; each serves a different scenario, and together they improve BCH UX. These arguments haven’t aged a day and I hope 1-minute blocks gain support for the May 2027 upgrade.
4 Likes
I love how cautiously rational the real Bitcoin community is. We will take Bitcoin back!
2 Likes
I’m opposed to this proposal for the following reasons:
- For 1-conf applications, purportedly the primary beneficary, it trades security for speed. At current rates the cost of an attack goes from the order of $1,000 to the order of ~$100. This is a huge change.
- Reducing block times from 10 minutes to 1 minutes wouldn’t eliminate MEV (this is a direct quote from the CHIP).
- Reducing block times from 10 minutes to 1 minute wouldn’t eliminate mempool contention (also a direct quote from the CHIP).
- The change involves a signficant and complex change to BCHN which risks introducing new bugs, at a time when we are especially vulnerable to adversaries due to advancement in AI and low hashrate.
- The change requires a new concept, ticks, to be introduced to the nomenclature, implementation, documentation, etc. Not only does that carry a cost and cognitive burden, but I will admit that I find it aesthetically unpleanant.
In my view the risks outweigh the benefits.
Regarding the document itself, I commend the author on their herculean effort, however:
- I found it very long and dense, almost certainly the longest CHIP ever published.
- I felt bambooozled by the comparisons, for example, in the introduction, a 20% number is compared with a 95% number and a 73min duration is compared with a 79min duration. This continues throughtout the document: every 4th, every 7th, 1 out of 5 time, 25% of cases, 30% of the time, etc.
- There is no disclosure about the use of AI in the development of drafting, nor a confirmation that AI wasn’t used. Although this has not been done in the past, we have reached a point with LLM development where it is neccessary for credibiliy.
There remains much to explore in the non-consesus solution space. For example:
- For defi UTXO contention, an imperfect but effective solution is to set
broadcast: falsein WalletConnect and have the dApp broadcast the transaction. Since most dApps have one front-end, they can easily to made to bradcast via one node which will significantly reduce mempool divergence. - DSPs and ZCEs have not been widely implemented in wallets, which seems like low hanging fruit. There should be UI for DSPs and a market for converting uncofirmed UTXOs into ZCE-secured payments.
- Nodes introduce random aritficial delays when relaying transactions to improve privacy but this exacerbates double spends and mempool divergence. Can this tradeoff be put to the user as a choice?
2 Likes
Weird, I am not entirely sure I understand this argument.
The security, measured in 10 minutes in time, should remain pretty much constant.
Where does the 90% decrease of security come from?
Just to splatter my thoughts here from a twitter post the other day:
I am now mildly in favor of the proposal since I did find something useful out of it - I was previously purely on the side of (1, 2, 3) would just declare it outright not useful in practical applications. I’ve since found something I can’t just overlook - that it is useful to have locktimes on the order of minutes instead of hours. Even if security on those locktimes are weak!
With that said, what @rnbrady said in #4 here is significant, and I’m not gonna sugarcoat the complexity of a constant that is in every nook and cranny of the codebase. Unlike Litecoin we’d also need to transition this. So I would leave it to more capable C++ hands to inform us how hard it is - is it '27 ready? better for '28? Or maybe if we’re gonna go for something that complex, maybe we should just go straight for Sunlight (more writeups and slides incoming)?
I don’t have good answers for these so I’m just gonna scurry back to my hole and work through it for now.
@ShadowOfHarbringer for applications currently hardcoded for one conf, the confirmation will come faster and with less variance, but carrying weaker security. So applications who do that would need to switch to 10conf to get the same weight.
2 Likes