No its not; you dont need to wait on anyone, you simply make a block out where the hardfork gets active, lets say 1 month in the future. So people have at least a month time to uprade their software.
Yeah, it may work until project is small, with mostly controlled community.
What it needs to do a hardfork is communication with the users and service providers and our communication with them is pretty good.
Funny enough that you will also have to hardfork as mentinoed in the XMR economy thread; when the blockreward runs out and we simply rely on tx fees, this won´t work in the next years, a minimum block reward is needed.
Sorry but its just naive to think that the current cryptocurrencies will survive the next 100 years without a single hardfork.
Sorry but its just naive to think that you could communicate with users and services in world famous product. It's mostly not possible to convince people to update their software even if you have product users subscribed emails or followers or whatever. They just lazy or don't care. Not to mention cryptocurrencies, where you have no idea who are using your coin.
Imagine what would happen if significant part of network won't update it(by different reasons) at time of block X ?
but it has some contradictions with crypto-currency nature (in my vision):
Says the one who decides which ring signatures to cut off in BBR...
I'm not decides which,
all RS will be cut-off after reaching some level of deepness. And this won't hurt anonimity or mixins. Or, if you think different, could you mention concrete technical objection ?
It´s simple: the users will decide if they accept the changes or not.
Here you contradict with yourself - if you do hardfork in the way you mentioned(just hardforked from block X) you not giving a way for users to decide.
I mean if some of them really decide against - then you just fuckup hardfork with network split at the moment of block X.
This why bitcoin have careful protocol for hardforking, where you have to wait until network will update to needed version and really give users a way to decide.
I didn't say that hardfork is not an option at all.
The flame started from my words:
...Architectural changes that will require hardfork better to implement before launch...
and I am deeply convinced of this.
So my point is that hardfork is risky and/or slow case, this should be used only in extra situations, where you have no other way to fix issue.
And i do not rule that we in BBR would be forced to make hardfork once a day. And probably more than once, i agree that nobody can foresee everything in advance.