Yeah, it may work until project is small, with mostly controlled community.
Its a general Problem in IT, old software at some point doesn´t get any more support, the best examples are microsoft windows XP, old unmaintained linux kernels, older android builds or iphones. Users have to upgrade in a given timeframe if they want to expect everything to work, its not ideal but it is how it is.
For example Whatsapp stopped working on Iphone 3G, because they demand a newer IOS version which isn´t available for 3g.
Starcraft II stopped working on older MAC OSX version, because after an upgraded it required a newer OSX version which isn´t available on older Hardware.
If we think like that and always care about backwards compatibility we would be stuck in IT stone age.
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 ?
I see it like DGA:
https://bitcointalk.org/index.php?topic=624223.msg8048067#msg8048067Yeah some users might have problems but does it justify not to enhance the software for the majority of users?
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 ?
Is the code implemented in Boolberry from the start? You could point me to the implementation? If its not in the codebase yet aren´t you effectively the one who will decide it when you implement it?
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.
Careful like this?
http://siliconangle.com/blog/2013/05/13/bitcoin-blockchain-hard-fork-coming-may-15th-final-warning/https://bitcoin.org/en/alert/2013-03-15-upgrade-deadlineOr the Dogecoin hardforks or the Darkcoin hardforks?
I agree it causes issues for users but can be done carefully planned.
Quote
...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.
I do agree also that of course not doing a hardfork is preferred.
What i do totally disagree with is this
"this should be used only in extra situations, where you have no other way to fix issue."I think, and its my personal opinion like everything i write, that a fork is justified whenever a sufficient improvement to the code or an economic flaw can be made.
Instead of just deciding to roll out feature XY at launch it should be done like Tromp does it for Cuckoo Cycle:
https://bitcointalk.org/index.php?topic=707879.20He has my utmost respect of how he handles his research.
I know your PoW has been also discussed in a seperate thread but somehow you didn´t get the right feedback, which isn´t your fault but still Cbuchner abused it to great extent.
You even thought about hardforking to cn.
For example your ALIAS feature, i totally disagree with how it works, as you can see here:
http://boolberry.com/state.htmlThere are aliases registered for exchanges, for example this:
poloniex 1JVrM7Qg64Y5C3ANFegoCZjQokhkC5UtRQjddeuBDc7S7bjZWPpUCq8TBPbXxDVmHkWjugxf1Pk1CbZ
D8gHQx4i4U22XywU
poloniex.com 1G467p3k4qGiqQCwFPDqSc46wzQZ9qnXB9JtLW9WD7T5UbnnT3imGsLeMnfjW5tsbBAibLbafcARU5e
jW17mgYSd2Nxnq2W
Now, there´s no way to check if even one of them is really from Poloniex, which i doubt because miners control the whole alias infrastructure.
That opens doors for scammers litterally. You advertise it as a feedback but i see it as a drawback tbh.
It´s not the only thing where i see problems with some stuff you have build.
I also do think that Bitcoin (and we CN coins too) should do something against the Pool/Mining centralisation problem and it will prolly require a hardfork, but its a problem which definately needs to be solved sooner or later.
Or maybe Litecoin should have forked to counter the ASICs, they somehow lost their selling point with them, so at least for me its a "bug" which should have been fixed.
I can think of tons of improvements where a hardfork is simply justified.
a) We have more real GUI than you guys, it's just a fact.
b) Architectural changes that will require hardfork better to implement before launch, so i implemented those features that i supposed to be important fixes of CN and can't be fixed in future without hardforks. You prefer to build community instead of it and later torment network with hardforks ? ... well, Monero obviously had no choice since it was launched by TFT, and i could understand it. But trying to convince people now that it is normal practice sounds senseless.
a) We have 2 guis that are released and 1 gui in the works.
That makes a total of 3 guis, is 1 gui more real gui than 3 guis? Sorry i am not up2date with GUI-Math ;-)
Your GUI is insufficient for the broader mass.
I could argue now that we have more daemon and other stuff...but oh well...i better don´t start.
b) But see the alias for example, its flawed for me. I think such decisions should not be made by a single person. If you think a feature is good doesn´t mean its good in general.
b) It's obviously that db is not critical for next few months. Atm end-user won't feel any difference - in BBR we have about 1-2 seconds for loading blockchain from storage file. So now better to focus on really critical issues.
The only reason a DB is not needed for BBR is the lack of transaction and the thus small blockchain.
But i argue, it IS needed to drive adoption and tooling for services around CN. I am still totally shocked that the CN codebase was released without a DB in mind.
The endusers don´t feel a difference, in your case at the moment, but every business or programmer interested in CN services or tooling will see a big difference.
Also our Daemon stuff is important for that, its not enough to please users with a simple GUI, the other side of the economy also needs to be supported.
