I stated a truth. You do know exactly what you were/are doing and saying! Frankly, I’d be very concerned if you didn’t.
So how about you close it now and stop this foolishness?
Because perhaps we will “update” it 
Either way, you are not the harbinger of what others do or don’t do on this forum (maybe it’s shadow, though, haha)
You know, we can be civil from here on out, would be lovely to have charming conversations. Maybe we can be the best of friends
(see, we can still be lighthearted!)
OK then.
Can I get a clear admission from you and Jeremy that the following(below) is an absolutely terrible idea and having upgrades on Saturday is senseless and not going to work/get implemented?
This should be enough to keep me quiet for a while.
If we come to the conclusion that it is a bad idea, then absolutely. We are not at that stage yet. You’ll find out once we update/close this thread!
1 Like
Could’ve woken up today without having to skim through 30-ish posts of flaming.
Anyway, a while ago I wrote a technical bulletin about changing the TX format (saying we should NOT change it in a breaking way), and as part of it I touched on a framework for evaluating changes, gonna copy here the most relevant parts:
Reasons for Change
We can define two broad categories of rationales:
- Maintenance
- New features
Optimization is part of maintenance, and there were proposals to optimize the format.
It was never really necessary because benefits would be some savings in node operating costs, where costs and risks would clearly outweigh the benefits.
Some catastrophic security flaw would be another, extreme, example of maintenance.
In this scenario, fixing the flaw would be a matter of survival for the network, and if breaking the format or commitment scheme was the only way, then it would have to be done.
Both transaction format and commitment scheme have been tested for almost 12 years, and we see it as unlikely that a severe security flaw would be discovered now.
There were considerations to increase precision of base units (fractional satoshis), which is presently not necessary.
Only in the future, if the value of Bitcoin Cash would grow so much that it would be impractical to make small transactions, could it become a matter of great importance.
The cost of change at a later date would be greater because more software would be reliant on the fixed format and therefore affected.
Would that be a good reason to upgrade the format now while the cost is smaller?
That would be the case only if changing the format would be the only possible way to increase precision.
Similarly, there were considerations to permanently fix transaction malleability.
This could be done by moving signatures from unlocking script into a dedicated transaction field.
They would then be referenced from the unlocking script by signature opcodes, so signatures could sign inputs unlocking scripts, too.
As we will see below, a new field can be added without changing the transaction format.
With new features, we must evaluate the costs vs benefits.
The benefits will be contained to some subset of users who would use the feature.
Maybe the feature would attract more users, in which case everyone would reap the benefits through increased value of Bitcoin Cash.
Some kinds of features can have vaguely defined benefits because their value can come from enabled innovations beyond our control or knowledge, benefits could be speculative.
Burden of proof for benefits is in proving at least some threshold level that would outweigh the costs.
How to set the threshold level when the costs are unknowable? It is impossible.
We should instead strive to make the costs side of the scale knowable.
If there is an alternative approach that has knowable costs and risks, then it is more likely that the alternative would stand a better chance of being implemented.
Conditions for Change
Because there exists an alternative where the cost would be contained to node software, a proposal to change it by breaking it would have to demonstrate that:
- Benefits of the breaking change are significantly greater than the benefits of a non-breaking alternative or at least, any difference in benefits must make up for the difference in costs.
- Majority of known stakeholders have been accounted for in cost estimation, as many as reasonably practicable.
- Majority of known stakeholders have accepted to bear the cost, even knowing there is an alternative which would not require them to bear it.
On the other hand, a non-breaking alternative would have to demonstrate that:
- Benefits are greater than the cost.
- Node developers and miners are OK with the change.
- Other stakeholders are not affected, unless they want to use the new feature.
We can observe here that the burden of proof is much greater for a breaking, non-backwards-compatible change.
It would have to involve the broad ecosystem, everyone who could have their software broken by the change.
The coordination and consensus building effort would be a big meta cost shared by all, and there is no guarantee that the meta cost would be recouped by successful activation.
This is not a matter of soft forking vs hard forking, which are concepts that pertain solely to the nature of node consensus with no consideration for other software and services.
Hard fork protocol upgrades are the preferred way for Bitcoin Cash.
Most hard forks are backwards compatible with regards to dependent software and costs have been contained to nodes and miners.
We can observe here that not all hard forks are the same.
With the non-breaking type everyone can simply upgrade the node, and all their other software will continue to function.
With the breaking type, everyone would have to update not just the node, but all their dependent software.
Note that presently there is one Bitcoin CasH Improvement Proposal (CHIP) which proposes to roll out new features in a way that would break both the TX FORMAT and TX ID:
The CHIP owner has made a good start in attempting to evaluate costs and risks, but because of nature of these costs and risks it is hard to estimate how much more work would be required to capture enough of them, or to even decide how much would be enough to be as-much-as-reasonably-practicable.
2 Likes
This is exactly my problem with your proposal and your attitude in here. This reeks of dishonesty.
Let me explain:
- You make an extremely dumb proposal that has no sense and will clearly damage BCH
- Pretty much every developer is against it or neutral
- When I repeatedly tell you that “this proposal i nonsense and this thread should be closed or renamed”, then you say “dude, why are you so defensive/aggressive and toxic, we are not saying this has to be saturday”.
But that’s dishonest and a half-lie.
You have not resigned and capitulated from making this dumb change with Saturday as the day, you still intend to push this proposal as it was in the beginning, or at least keep this as an option.
This is why you keep this thread going - because you somehow hope that by “overtalking” other discussants with the amount of posts and arguments and making it look that “it’s a process” that will finish and the idea will be implemented. What you are doing here is basically soft-sabotaging the CHIP process.
No wonder my 6th spider sense is being triggered. I am always triggered when I see dishonesty or manipulation used to push a change for BCH.
Where there is dishonesty, there is always some adversarial / malevolent intent.
This is a great reference, thank you!
1 Like
This conversation received several flags.
One of them even requested to remove this thread completely from the forum.
Although I particularly prefer to keep it for the purpose of documenting the discussions around BCH development, I cannot avoid mentioning the request in a transparent way.
If the people involved in the discussion prefer for this post to be eliminated entirety, please state it publicly below.
Thanks.
Critical pieces of information and great arguments that will propel BCH into the future were provided here (among many weak arguments of course). They would disappear if the thread somehow vanished.
I am fine with leaving the thread as it is - it’s important for historical and educational reasons.
“Those who don’t know their history, are doomed to repeat it” or how did it go?
1 Like
It should not be removed.
2 Likes
I want to reiterate a point that is not raised enough, even in this very long thread.
While “the process” is not something set in stone, the concept and detail of it both are a schelling point that very specifically help BCH avoid the need for coercive setups such as voting and dictators.
It is not something to be changed lightly. The bar for changes to such a schelling point are typically much higher than for other types of changes. I made a half-joke half-serious image to demonstrate this issue by comparing the gravity of changes to US Constitutional amendments:
Please don’t take it too seriously, but I think it conveys the point. This is a change to a foundational process and has consequently larger consequences and a higher bar.
1 Like
Small update: The Halving is today (Wednesday) at about 4pm.
I have been requested a BUNCH of times “Are we doing a livestream? I’d love to be a part of that”. I’ve also seen people separately asking around for a livestream and the desire to celebrate as a community.
I was not able to organise anything like that - because it’s in the middle of the work week. As far as I’m aware, neither was anyone else really.
Obviously we cannot control the Halving timing, but we CAN control the upgrade timing. This illustrates the problem we’re looking to address perfectly in this CHIP.
I would just like to take this opportunity for anyone who is skeptical of this CHIP to reflect on it if/when they also see people asking if there is a Halving celebration stream or maybe being a little sad there wasn’t one afterwards. The occasion will pass largely unmarked it appears.
1 Like
Are we still talking Saturdays?
Sorry, NACK 
I received numerous questions as well.
I ended up doing a last minute Twitter/X space, which did get decent attendance and lasted over 3 hours. People were very excited about this once-every-four-years event. And many were asking about the upgrade as well.
People want to be excited. I had people from outside BCH join the space. These are great marketing opportunities.
I hope that people can at least recognize that there is market demand for these events to occur.
1 Like
People getting “excited” is not, and will never be, a good excuse to wreck the work week of most programmers.
People generally (this is a rule, there are obviously exceptions) do not like to work weekends. Period.
This state of reality has multiple reasons, many of them very strong (I already listed them above).
No matter how many “people” want it, “developers” do not want it. This is not a corporation and the developers are not your emplyees. You’re not a Management person here and you cannot tell all people who code now and will be coding this project in the future to work weekends (somehow however I get the feeling you are a management person In Real Life).
This is not your call and this is not the call of all these people on Twitter, Twitch or Youtube.
Open Source developers who code the most critical software like Nodes will be the ones deciding it, not you. And they are not in favor of your idea.
This discussion should be over 6 months ago yet somehow it still it keeps going. I do not like your attitude here. Feels like an attempt of Moving Overton Window, which is one of popular psychomanipulation/sociomanipulation techniques which makes me very itchy and suspicious over the way you behave in this topic.
PS.
Same answer applies to Jeremy of course. You two are so well in sync, as if you discussed this partiucular narrative creation/discourse management strategy together for weeks.
This has to be all a curious coincidence, nothing more. Surely.
Lol Shadow, you’re funny!
I happened to see that there was activity on this thread and looked at it. Is it really that hard to believe xD
No, actually dead serious.
You clearly haven’t capitulated from Saturdays being the upgrade day, you are full of hubris and your used tongue is clearly manipulative/workaround instead of to the point.
BCH dev community has already concluded this idea is dumb and dangerous, but I am still waiting for you to capitulate.
You gonna do it or not?
You cannot speak for all of them. Nor can you discount the possibility that Alex and I can gather increased support with time & further demonstrations of value.
Make whatever assumption you want, but there’s no grand conspiracy. Alex and I are going to keep raising this topic to try and build support over time. That’s because as we have seen from the history of CHIPs and the history of BCH that sometimes take good ideas to build traction in the community & to show the people involved are serious. That includes us, so we will do that.
Yes, we both like this idea and we’re doing what we can to make BCH a success. That includes collaborating on this CHIP.
There’s no mystery or conspiracy - I will very blatantly say yes of course Alex and I have discussed and worked on this together.
1 Like
Judging from this discussion and the devs who spoke in it, AFAIR all node software developers, excluding conditionally Calin Cullianu are against it.
This is what worries me the most.
So if current node devs remain being against it, what you are gonna do (as clearly you are 100% unwilling to capitulate from this dumb idea)?
What will the “support” change here? You cannot change how people run their daily lives with “support”.
Or do you mean you will gather such a massive “support” that you will overthrow their decision or force them to work weekends against their will like slave workforce or something?
Or maybe you will gather enough “support” to build an alternative node team (probably paid and with a proper manager, otherwise what OS developer would want to agree to such terms) that will want work weekends?
Which one is it going to be? Any alternatives to above scenarios here?