Still irrelevant. You can convince Shadow all you want. But those engineers need to join your movement 
As long as you’re not getting that, this discussion is pointless. We can only repeat this point to you so many times.
I assume that many engineers, if the evidence was compelling enough of the benefit for BCH (& thus, their own BCH investments & ideological hope for BCH) would be willing to accept some marginal level of personal inconvenience.
Maybe not all of them, some may stubbornly prioritise their own Saturday morning 1 day per year over the massive success & adoption of BCH as a global currency and that’s fine, but no CHIP requires universal agreement.
What remains to be seen is the strength of the evidence for such a change as bringing those benefits & that’s fine that’s what I will work on.
A story in 3 pictures:
Good effort on the CHIP, Jeremy, but is it really worth it?
May 15 is equally arbitrary, yes, but inertia is a strong enough argument, especially when faced with the amount of words spent on this already with zero movement… just my 546 sats…
2 Likes
Uh, then like, maybe next time go gather evidence first before actually trying to push a clearly unwanted change on the community?
What are we even doing here?
He doesn’t need to convince me.
If he convinces the engineers doing the hard work, then I will go along with it.
I have said it clearly multiple times: I will agree to whatever weekday as long as engineers that will be working on bugfixes also accept it.
Imo there being a specific day May the 15th is a very clear moment for having the upgrade year over year. As seen in this CHIP to change what day this should be is already stating to sound like a bunch of friends trying to find the right moment to pick to go out for dinner. Changing it now seems like it would open the gate for having the same discussion next year for someone who is convinced that wednesdays are the best for upgrades.
Just keeping it on May 15th seems to be least prone to social captures or confusions in the future.
3 Likes
Yes. The benefit is not just the CHIP itself (which I hope to demonstrate is significantly important), but also in my attempt I am 1. Learning about the CHIP process through first hand experience and 2. Compiling notes & learnings for future CHIP proposers to consider. Don’t underestimate the importance of that, even if the CHIP itself is not accepted.
Furthermore, this CHIP (if accepted) would demonstrate that non-technical changes can be agreed upon in a decentralised governance system - also no trivial thing.
There has not been zero movement, although it has taken a surprisingly long time to move the discussion to “If there was enough obvious benefit, it’s certainly worth considering” from “I hate it, no, no debate”.
How would I know it was a clearly unwanted [by a specific subset] change without putting the idea out there? Why would I do a lot of work on the evidence if everyone loved it and agreed because they could see the point straight away?
Would you agree to a weekend if enough engineers accepted it?
This is a fair point, but is essentially the same argument as the blocksize limit. Think of it like that.
- 1 MB = May 15th. There is no reasoning, it was just the status quo. Only got questioned once someone had a pressing need to, but nevertheless lots of people thought it was fine the way it was.
- [Some new fixed amount] = invitation for endless bickering over the next day or changing one to another.
- Blocksize Adjusting Algorithm = Done once, with lots of evidence & discussion, provided a convincing, evidence-based approach which got agreement not only on the need for a change but also on the reasons how & why, with flexibility for all future requirements.
I hope to produce something akin to the Blocksize Adjusting Algorithm, but for the Upgrade Day and potentially also other cultural or non-technical community disagreements or standards rather than for the blocksize.
There will be a cost to pay in discussing & performing this switch, but if it’s done properly, it should only be a one-time endeavour that pays off exponentially over decades.
NOTE: Please don’t anyone misunderstand this explanation & start up with how an algorithm to pick the upgrade day is the stupidest thing they’ve ever heard. That’s not what I’m talking about.
2 Likes
Emergent did absolutely explain it well. That’s exactly what we’re trying to do. Seems odd there has been much criticism for the reasons Jeremy and I have already laid out.
But living in the past doesn’t accomplish anything (I mean, that’s why so many BTC maxis are stuck in the past). We want and welcome criticism so we can see what this means. But we are not doing this just to do it. We are proposing this because our discussions have shown many want this. But we need points of criticism so we can refine arguments for this.
If this doesn’t end up working out as we go back to the drawing board to propose something we believe is important, then we made our effort and the community would have decided that it’s better not to.
1 Like
Just as a side note, here, as I feel it may have been lost. I don’t believe there has been any hostility from anyone here, and we are all sharing our genuine opinions/feedback. There have been many more circles than necessary, imo, but everything here is very helpful.
I think it important to just mention once more, that while many devs here have not shown interest, there have been many others in the community that have shown interest, so this is not coming out of nowhere. Our events, while not crazy popular, have a lot of traction. We had sponsors with a fairly decent chunk of BCH for the giveaway. The stream does not look to have all the views because of week-long youtube processing and copyright issues from the first 30 seconds of the entire stream. But nonetheless, it gets traction, it gets people active on all forms (X/Twitter, Telegram, Discord, memo, etc.). The streams have people getting active a month(!) before the stream actually happens. The CashTokens TG had a massive bracket for the CashTokens subreddit image to be decided on livestream.
Back to sponsors, some of the longest supporters of BCH, just naming two in particular here, Satoshi’s Angels and Bitdeer (Jihan Wu’s firm), are always first to sponsor. We all want to promote this stuff, and there is a LOT of community engagement.
We will need to quantify the above and more to make a convincing case for why we believe this to be a worthwhile change, however we absolutely understand that no change just happens. We appreciate all the feedback, even though it’s been a clearly bumpy road!
3 Likes
Yes, but they will obviously not.
Not so sure about that. May 15th was OK but I imagine it was more like “just pick a date” and it stuck with us. Nobody’s ever thought too much about that convention - until now 
Some new good arguments were added here, I feel like case could be made for switching to something like “First Saturday coming after May 15th”. It would not have to mean that people have to calculate it to know when is our upgrade.
Next version of BCHN should be released soon, and if release notes & upgrade specification says “MTP 1716033600, May 18th, 2024 12:00 UTC”, would anyone (exchanges, block explorers, Electrum operators) really complain about it?
And everyone would know 6 months ahead of time that this year it will happen on 18th, and could plan for that one day accordingly.
1 Like
Somebody needs to go and actually ask all top contributors to Electron Cash, BCHN, BCHD and other critical software that has to deal with things on upgrade.
Apparently they won’t come here and state their opinion by themselves.
2 Likes
Yup, that’s the job of CHIP owners. They could send a little questionnaire, something like:
- What is your preference for Bitcoin Cash upgrade activation? (select 1)
- ( ) May 15th, 12:00 UTC (current convention)
- ( ) First Saturday after May 15th, 12:00 UTC
- ( ) First Wednesday after May 15th, 12:00 UTC
- ( ) Something else
- Would you object if future upgrades would be activated on
- [YES / NO] May 15th, 12:00 UTC (current convention)
- [YES / NO] First Saturday after May 15th, 12:00 UTC
- [YES / NO] First Wednesday after May 15th, 12:00 UTC
- How are you affected by the choice of timing?
4 Likes
Fair enough 
I do think it’s a bit of a stretch to compare this to arguments for/against blocksize limit changes, though.
With technical arguments, there are clear and obvious tradeoffs, usually one can come to a conclusion with sound logic, and others can come to the same conclusion based on fact and evidence.
With social arguments, I think it will be difficult to find the necessary data and evidence to produce a strongly compelling argument - one where the outcome of the change clearly outweighs the cost of discussing and implementing the change.
But more power to you for trying.
4 Likes
The main point of comparison is just an irrational bias to the status quo. Yes the status quo should carry weight, but certainly less weight if it is a product of happenstance rather than a previous set of analysis & community discussion (in which case an argument to change would need to redo or provide new analysis refuting the old analysis, rather than just make a strong enough case to override inertia).
2 Likes
I too thought that was a strange comparison, especially since keeping it at May 15th does not cripple bitcoin. I Think we can both agree that most likely everything would work very similarly in 10 years if we choose May 15th or the next Saturday after a May 15th.
But I understand your further explanation and there is some merit to reevaluating something that might have been chosen randomly but is sufficient for something that is more optimal. I would also like to thank you guy’s for doing events like this. I really enjoyed the livestream and the media attention created around the event and believe there certainly is value in this.
However changing something like this should come with very clear benefits from for all people involved. For technical changes proving a 2x improvement for example is much easier since these kind of changes tend to be evaluated more objectively. Proving a substantial improvement over a social convention is by nature a subjective matter and will be a lot more difficult. (similar to what kallisti was saying)
Considering the current way of doing things isn’t broken, I would prefer not to stir up the pot. If you can prove that all the people involved in doing these upgrades can unanimously agree on what your proposing, sure problem solved.
I have an opinion on this matter but not particularly a strong one and just wanted to share it here, I will most likely distance myself from further discussing this topic.
4 Likes
It’s not “irrational”. Not sure if you do or if you were even there, but I remember it all. Historical context:
The point of choosing a fixed half-yearly and then yearly upgrade date was to destroy the social construct created by the Core propaganda that claimed that “hard forks are bad and they break things”.
So as a counter, BCH has done timely regular hard forks, as to prove that hard-forks/upgrades are not dangerous by themselves. It has served its purpose and it has done what it was supposed to do.
Instead, what you are proposing is irrational, because you have no idea whether it is even necessary, of your own admission:
So, basically what you are doing is pushing a pointless - at this point of time - “upgrade” which nobody needs, nobody asked for, not “challenging the status quo”.
Status quo isn’t always wrong by default.
“If it’s not broken, don’t fix it” - as somebody famous and accomplished (probably Linus Torvalds) once said.
Further discussion in this thread is pointless, I have no idea why this keeps going.
You should really do your social study first in order to determine if there is a need for such change at all (if it actually “fixes” your Saturday podcast or not), and then create a CHIP.
PS.
While you are at it, doing the “social study” I mean, please do not forget to make the evidence open and public so we can all analyze it and decide whether it makes sense.
Proposing a change to the “status quo” that has no basis and no rational reason is just that - nonsense.
Again, “status quo” is not always automatically wrong or bad - as long as it works alright.
This threads gotten quite long and I apologize if this has already been mentioned a few times, but would like to place additional emphasis on it.
Another, perhaps less obvious but important, stakeholder group are services who support BCH, but are not solely BCH products. For example, exchanges, payment processors, etc.
If, for example, we chose the first Saturday after May 15th as the upgrade date, I could see this potentially causing problems with that group as they might not have the technical resources available on weekends to fix any problems that may arise. And forcing them to be present on a Saturday might rile up bad sentiment towards BCH. Not sure how to properly quote my previous post, but:
I’ve had clients in the past who insisted on go-live’s/upgrades on a Saturday which meant I had to be around to supervise. I detested them for it and the employees at exchanges, etc, might feel similarly.
Rightfully or wrongfully, I don’t think BCH has enough weight to do this and the (in this case, deliberate as opposed to incidental) support burden might brew up bad sentiment in the
they deliberately had to choose to do the upgrades on a f'n weekendsense.
One problem that I anticipate is that eventually we probably are going to want to change the Sat Fee per Byte/KB. It would not surprise me if many services have this hard-coded as 1 byte/sat. So, if a change to this is ever implemented, I do suspect some services (some exchanges, some payment processors) will break. If we plan for Saturdays, these services might have to wait until the next work (week) day for a fix.
Please don’t take this as hostile feedback, I do appreciate that thought is being put into this and, though I do not support this right now, I think a time may come in future where we might want to consider changing the date. As it stands right now though, I don’t think BCH has enough weight (for lack of a better term) to assert that these services should have technical staff on the ready for a Saturday upgrade every year. And trying to do so might agitate those services (or the employees of those services). Where as, If it incidentally lands on a Saturday, I imagine they would be more forgiving.
So, in that sense, I’m not trying to put down the CHIP, but until we become a cryptocurrency that warrants great import in the eyes of these services (hard to measure, I know), I think the cost/risk/dangers outweigh the reward.
I do, however, think it is a GOOD CHIP (and discussion) to have sitting on standby for that moment when we are well-established enough that these types of services are happy to set weekends aside to provide support (and not view us as a “special snowflake that had to choose to do updates on the weekend”).
5 Likes
The point on exchanges and other similar services is definitely well noted. This is a great point. Perhaps this could also lead to a CHIP keeping things on a specific weekday, say, a Tuesday or a Thursday.
3 Likes