The case for stability

Communication
#1

BitcoinCash is currently having a yearly protocol upgrade, it used to be a bi-yearly one in order to catch up after the BTC enforced no-upgrades for too long.

The advances made were amazing, but they did have a cost.
First, we lost most of our full node implementations. The JavaScript ‘bcash’, the ‘bchd’ and the ‘flowee’ ones no longer are in consensus.
More important is the building-on-top-of-bitcoincash situation, as that is literally our stated plan to conquer the world. Adoption through apps, wallets and other such opportunities.

Most of us have probably at least watched the builders get burned after the SLP and sbch projects being scuttled, and only a small number (in comparison) is now building on cashtokens.
If you have been around as long as I have, you’ll be able to remember quite a lot of places that similarly tried and left. Bigger companies probably won’t even try to build on a chain that changes every year.

If you want to counter this with facts, stating it is not that bad, you might make a case and I won’t be trying to prove you wrong. But the point isn’t really facts, the point is that our chain has taken a serious popularity hit and most people, including contributors here, have a very negative opinion about stability.
One just has to look at a recent reddit topic where someone detects an inconsistency on blockchair. The issue turned out to be a bug on the side of blockchair, all the facts were available to realize it had nothing to do with the May upgrade. (900 blocks is a week, May is much longer ago). Yet, the vast majority of people instantly jumped to the conclusion it must have been due to the May upgrade. Reddit thread.

Any honest long term bcasher will likely remember more such situations. BitcoinCash does not do well in the public opinions when it comes to being stable to build on.

Why is this important?

The BitcoinCash I love is one that I see grow in usage, where more people can see themselves use it as actual money for normal daily things.

In order to get there we need to have a LOT more infrastructure. Payment processors like bitpay and gocrypto are awesome to accept BitcoinCash already but nobody will mind if they get competition which also accepts BCH.

Direct payments are not the only thing, by far. Daily finance touches an immense number of applications and the companies that build them need to extend such applications for BitcoinCash. The dividend payments idea (from Jason) based on CashTokens to be used by companies will have to be written by someone, and integrated into said company infrastructure by someone else.

One suggestion

The upcoming blocksize algorithm feature is nearly done in BCNH, it has been thought we should do that as a May 15th protocol upgrade.

I have nothing against that in principle, it is a sleek way of doing so. Let that happen. Really, don’t need to change anything there at all.

What we can do is consider our way of advertising this to the wider public. If we don’t say anything it will be seen as our traditional breaking-change May upgrade.

On the other hand the people (bca/bchn) that push this change can choose to instead make it clear that people can build, run the latest BCHN and be carefree about any breaking changes until at least May 2025.

Some things actually are possible to build in 18 months, so it feels like a good opportunity to take and attract more people that way.

3 Likes
#2

On Telegram some people correctly pointed out that whatever we do to address the points in my post, it should NOT take away from the very important message that we are final and absolutely leaving behind any lock-in problems with regards to blocksize.

So the idea here is to keep both lines in mind and make both important messages come through. They need not be mutually exclusive.

Thank everyone for considering!

#3

:point_up_2: this, plus the fact that the last Bitcoin hackathon was nearly 3yrs ago, smh :sob:

imo, a blockchain that doesn’t take advantage of a “bear market” to focus on #BUIDLing, has simply grown complacent with being “good enough” and will likely remain stationary (while some continue to advance and others fall by the wayside)

also imo, the Bitcoin Cash “Community” does an excellent job of building & shipping great technology, however, falls very short on delivery “actual value” to end-users…

Developer ≠ Builder … and BCH needs waayyy more BUILDERS! :nerd_face: to :rocket:

2 Likes
#4

This is a problem for builders, no doubt. BCHD is finally soon going to be updated to be in consensus with the May 2023 upgrade, but the 2024 upgrade is right around the corner. PayButton functionality was completely broken, as an example, and although they are eCash primarily, they support BCH but most don’t want to rebuild around a new node to make it work.

Perhaps a method that could be considered is every even year we can have a hard-fork upgrade, and every odd year we can have a soft-fork upgrade. 2-year absolute buffer for nodes, in this case. Heck, could even say that hardforks need to be locked in 12 months prior to network upgrade. So for example, could work like this:
May 15, 2024 - Adaptive Blocksize Limit Algo (Hard Fork)
Nov 15, 2024 - Soft Fork Proposal for May 15, 2025
May 15, 2025 - Soft Fork Implemented
May 15, 2025 - Hard Fork Proposal Lock for May 15, 2026
Nov 15, 2025 - [Nothing?]
May 15, 2026 - Hard Fork Upgrade

Granted, this would be a change to a system that “is not broken” for upgrades, so this would likely not be taken well by many, but just a concept.

1 Like
#5

What is a problem? Having protocol upgrades, or (temporarily) losing node implementations on which some apps depended on?

We didn’t lose bchd because we had protocol upgrades, we lost it because maintainers moved on to do other things (Chris Pacia is starting a new blockchain, and Josh Ellithorpe is focused more on game dev. and apps). Sure, if there would’ve been no upgrades then bchd would’ve stayed in consensus by default, but it would’ve only delayed the problem. Whatever you’re building, is it wise to depend on a stale project with effectively no maintainers? Should the whole ecosystem be delayed because one project lost its maintainers? Also, remember that we lost some of BitcoinUnlimited builders due to changes being too slow.

Having protocol upgrades brought in more builders, especially the CashTokens upgrade, and the builders are hungry for more protocol changes (like VM limits, OP_MULDIV, etc.) because it would enable them to build what couldn’t be built before the change or build more efficiently.
Losing bchd had the impact on some projects, but on net, a lot of new projects have popped up and are hungry to build, and part of that building energy will come back to bchd and it will come back online: last update from OPReturn indicates that he may spin up a working bchd node this month!

That doesn’t make any sense. Technically, 2 out of 4 CHIPs of '23 upgrade were soft forking changes (P2SH32 and TX version CHIP), and the other 2 were hard forking changes (CashTokens and TX size CHIP). It’s not like there’s some committee gathering to decide “Do we want a HF or do we want a SF this year?”. If we’re agreeing we want some improvement, and if that improvement is naturally a hard forking change then it will be a hard fork, and if it is a soft forking change then it will be a soft fork. We’re not doing the Core thing of shoehorning a change that’s naturally a HF into a SF.

The whole terminology of “hard” vs “soft” was poisoning the discourse back when Bitcoin was still one, let’s not carry that over to BCH even though we inherited some terminology. There’s nothing easy about soft forks and there’s nothing hard about hard forks. Node developers implement a change, set the activation time, everyone starts running the new version before the activation time, and voila, the network has been upgraded.

We get upgrades when they’re ready, I don’t see a need for intentionally delaying upgrades. A lot of work goes into an upgrade being ready so they’ll naturally get stretched out anyway. Token upgrade was first targeting '22 activation but it was not ready so we got it in '23.
Then, people were more interested in building stuff with CashTokens instead of working on the next protocol upgrade so for '24 only the adaptive blocksize limit CHIP got ready and so that’s the only one we’re getting even though there’s desire for more.

1 Like
#6

Don’t do that. This is a friendly forum and you can read the answer to your question in the opening posts. In detail.
Not actually responding to those posts but pretending it wasn’t written (and going on a tangent where you may have a case, I guess) is toxic behavior and toxic has no place on this forum.

1 Like
#7

Ok, let me correct it now :slight_smile:

The upcoming upgrade will rely on the same pattern established with previous upgrades: that of new software getting released months ahead and later everyone smoothly sailing through the MTP. Even the '21 upgrade, which didn’t include any consensus-sensitive changes, was deployed in similar fashion.
Node implementations will announce new software releases, people will download and run them instead of old versions, and we will once again smoothly sail through the activation MTP.

Because the '24 upgrade doesn’t really touch consensus, other than auto-adjusting the value in the existing max-accept rule, this upgrade will really be easy on all downstream software and libraries like libauth, mainnet-cash, cashscript etc.

This cycle they can focus on other improvements, and I too feel like everyone will appreciate catching a breath in '24. Acknowledging that it’s good to catch breath doesn’t mean I have to agree we should intentionally slow down. I know you didn’t explicitly say we should, but it’s just the vibe of your opening post.

If you just wanted to say that it’s good that '24 will be easy on builders, then I agree! But for '25 I have my hopes for some more CHIPs getting through as we now have more time to do the work needed to deliver them! :smiley:

Maybe we should also ask the question: why didn’t Verde & kth have any trouble keeping up, what sets them apart from others?

And we didn’t lose “most”, we lost 2 out of 6 (or 3 out of 7 if you count bcash), and for different reasons. Let’s examine when / how / why we lost each.

Last bcash commit was in 2019, and apparently it fell out when BCH got Schnorr signatures & SegWit recovery. Who was using this bcash implementation and who was at a loss here? If people really wanted a JavaScript node, you’d think that since 2019 someone would pick it up?
I did a little research just now and learned that this one was originally released by purse.io, probably for their own needs. I guess they just switched to another implementation and abandoned the project, or they close-sourced the node implementation. Later, at the end of 2022, they dropped BCH entirely, and finally in 2023 they stopped operating. I don’t think that BCH upgrade schedule is at fault for one company making bad decisions.

Then flowee fell out in 2022, and your explanation at the time was that docs weren’t good enough. Later, I remember you said somewhere that you want to focus on the wallet more, so I guess you’re really just constrained by being a mostly solo developer? Who else depended on flowee node and how did it impact them?

Then bchd barely made the 2022 cut, releasing the upgrade just 10 days before activation date. Already at that time, Chris Pacia was not as involved with BCH as he used to be, and I believe he speed-ran the implementation (took him just 2 weeks judging by the commits) as a favor to people who depended on bchd. Now this was a node on which a bunch of projects, including sBCH, depended on. Losing bchd was the most impactful loss IMO.
Even so, can we really say that BCH upgrade schedule was at fault here? There was enough time (almost 1.5 years of time) for those projects to find a new maintainer for the node they depended on, but thing is - some of those same projects that depended on bchd had lots of troubles of their own - the whole sBCH ecosystem got rugged by CoinFLEX. Had that not happened, I’m sure that stakeholders who had incentive in bchd keeping up would have found a way to upgrade it on time.

It’s also worth noting that in 2023, BCHUnlimited almost didn’t make it. Thankfully it managed because @dagurval showed up and almost single-handedly speed-ran the implementation, and it was a close call with the release being made on May 8th. In the meantime @dagurval and some others built the CauldronDEX, so here’s an example of a change enabling builders to build and providing incentive to do the necessary work. Ironically, we lost a bunch of other BU members to their new blockchain not because we had too many changes but because we had too little too late for them, and I doubt we’ll ever get them back because they’re too busy powering on with their new blockchain and there’s no incentive for them to go back to BCH even though they could now build the apps they originally wanted to build on BCH.

I don’t agree that was related to our upgrade schedule. IMO SLP was just bad architecture and result of BCH’s failure to get the real deal tokens back in '18 because BCHers were still infighting a lot and it was impossible at the time to work out something like CashTokens. sBCH got rugged thanks to CoinFLEX.

The numbers are growing and will keep growing and if the trend continues then they will outgrow whatever we had before, because everyone now recognizes it’s a solid foundation and one that enables a lot of stuff to get built. Builders have shown they are hungry for building, as this video by @MathieuG demonstrates that with showcasing some of what got built in just 6 months:

Ethereum had an aggressive schedule of upgrades, at times more often than once per year, and yet it didn’t stop companies from building on top of it, how so?

Agreed! Thankfully, with CashTokens, we now have a solid foundation that enabled whole classes of new apps to get built and drive adoption to our L1 platform, and it will be synergistic with our cash use since it will give our cash more uses.

I’m tired, too. Getting a CHIP through is really exhausting, by the way. However, we’re are not done and we can’t afford to intentionally slow down L1 developments. It’s already slowed down due to resource constraints. Already some builders are desiring more VM features, features that could be enabled without increasing node operating costs but someone has to think through, interact with all the stakeholders, and implement those features - i.e. someone (or, a bunch of someones) has to pay the capex cost of unlocking more functionality. Why didn’t we already get the VM limits and bounded loops CHIP over the line? Because Someone™ must do the necessary work to get those CHIPs across the finish line, and our someones were busy with other things. Everyone is spread thin, but we’re pulling through!

3 Likes
#8

Quick thoughts running in order:

Quite clearly, this. And this is addressing the OP.

I completely agree here - there are a lot of very neat upgrades in discussion. I’d love to see many of them happen. I think, though, that certain changes face resistance because they break backwards compatibility too (iirc PMv3 was one of those). But that’s a debate of change now while young and face tech falling off, or change later when established and much higher cost. Frankly, that would be an interesting discussion to have. But no doubt, we don’t want to stagnate entirely, because then we’ll be like BTC which would ofc not be good.

This is another take, of which I also agree, but BU left (oversimplifying here based on the posts and explanations by devs on reddit/elsewhere) not just because changes were too slow, but because agreeing upon changes was too slow. The idea for CashTokens and otherwise links back to early BU talk, if I’m not mistaken. Other projects/ideas as well. But agreeing on a change and the rate of change are two separate issues.

I did mention this in my second sentence.

Ok, what terminology should be used then? It’s pretty basic and easily understandable (to me, anyways).

No need to be so literal, here. Of course soft fork changes could still be included in that hypothetical schedule.

I see your point in the response, but bigger companies WILL spend time on a chain with a market cap of $240 BILLION, with a large amount of activity. So the point is valid nonetheless, maybe stated somewhat differently.

2 Likes
#9

It’s fine if we clearly define what it means and clarify the impact. My problem is that “soft” can be associated with easy, and “hard” with, well, hard. That’s not the case. Soft forks and their consequences can be harder on node implementers and downstream software. That’s why I said it makes no sense to try to devise some rigid schedule for when we should do SFs and when HFs.

Technically, “hard” is node-breaking, and “soft” is not node-breaking, that’s it. But even the word “breaking” can be off-putting so again there could be bias in thinking that non-breaking is better because it sounds easier, yeah? If some nodes tighten consensus rules, then from PoV of older nodes it will all still validate - but some TXs made by non-upgraded nodes may be rejected for reasons unknown and it will look like TX or block censorship to old nodes. With a node-breaking change, old nodes will reject new node’s blocks/TXs as invalid, and end up on a stranded or persistent fork.

Now, big deal for upgrades is whether it’s breaking downstream software. Can you just swap out the node and everything just works? Our upgrades may be node-breaking but they are NOT breaking user-space, and that’s a good upgrade policy, and we can draw parallel here with the Linux kernel.

BTW it’s possible to break downstream software even without the protocol having any upgrade - changing some node RPC on which some software depends on would do that, this is why it’s important to have stable APIs.

SegWit was an example of a SF which had huge costs, and causes headaches even now. Like, sure, it was all opt in, yeah? You could just ignore SW, yeah? But then most of downstream services opt in and then people have to scratch their heads about how to do simple things like calculate TXID from the raw TX blob they get from an explorer. Learning curve gets tougher because you have to unwrap all these SFs.

Older example: I’m still annoyed by OP_CHECKLOCKTIMEVERIFY (2014, BIP-65) and OP_CHECKSEQUENCEVERIFY (2015, BIP-112) not popping an item off the stack like other *VERIFY opcodes do. Why are these 2 special? Because they were implemented as a SF (they’re OP_NOP to old nodes) when they should have really been a HF (old nodes to fail a TX using the opcodes and have behavior consistent to other *VERIFY opcodes).

Well it didn’t always have that market cap. Before 2021 it was much lower and people kept building and investing into the ecosystem despite the protocol having frequent upgrades.

3 Likes
#10

As @bitcoincashautist said, soft-forks are “soft” only in name. In reality their consequences can be really devastating to the node software because they create more technical debt than hard-forks. The most famous example being SegWit of course.

There is absolutely no point in mixing soft-forks and hard-forks for no technological reason. Generally, hard-forks are safer, cleaner and ultimately better for the network, most of the time.

If we want to use soft-forks at all, doing so has to be thoroughly considered and not be taken lightly.

Indeed, if it’s not broken, don’t try to fix it.

1 Like
#11

ohhhh, so that’s the reason… sloppy, smh

2 Likes
#12

I read his reasons to be;

  1. a certain set of changes are best done and Ok as “soft forks”. (Nobody is suggesting a deliberate crippling just because.) The 2024 upgrade is one of those.
  2. such soft forks are easier for the wider ecosystem since they only affect full nodes. Everyone else can safely ignore them for some time. No looming deadline. Not even a need to follow the BCH news.
  3. intentionally pushing the more disruptive hard forks forward with the goal of having a longer cycle of stable building would then be useful without really having a lot of downsides. Hard forks are not being denied!

I think it merits some thought based on actual expected upgrades. Which are likely to be much less than we had in the last years.

2 Likes
#13

looking forward to a CHIP suggesting deprecation (while never retiring, obviously) those and creating new ones that add the pop.

1 Like
#14

Not sure if that vibe really is there, a re-read doesn’t give me that.
But that is not what I wanted to get across.

It seems your response is based on a misunderstanding of a “vibe”, or reading between the lines. Which is unfortunate and maybe avaidable to spend so much text on in future?

I do really like you agreeing with the overall tone I TRIED to put in there, which is about people appreachating the catching of breath.

Lets build on that.

3 Likes
#15

I had a drafted response but this pretty much covered it in a much more brief way. Thanks!

1 Like