One comment on the concept of "voting" being problematic

In many cases it is largely irrelevant whether miners have upgraded. What matters more is whether the larger community of participants (I'll call these users, but I include in that group major commercial participants such as exchanges, etc.) have upgraded.

If most miners upgrade but nearly all users don't, what will happen come fork time is the majority of miners will find their blocks rejected. The difficulty will drop, which (assuming the coin retains value) in turn will attract new miners (and/or encourage existing miners to switch over).

Likewise if nearly all users do upgrade but most miners don't, again most of those miners' blocks will be rejected, the difficulty will drop on the chain users accept, and miners will show up there in response to the lower difficulty.

Now if you have a situation where say, half the user community wants to upgrade and half doesn't, then you will have chaos because people won't agree on the state of the blockchain and won't be able to transact, again regardless of what miners are doing. Both sets of users will see a blockchain (with different difficulties) but they won't be able to agree on which is the correct one.

If the user community doesn't unify behind one fork, then the coin will likely be destroyed by the resulting chaos. But if it does unify, then it doesn't really matter what the miners do. As long as there are some miners on the users' fork, then blocks will continue to be produced, difficulty will adjust if necessary, and miners (possibly the same ones, possibly different ones) will come.

Unfortunately, the problem is that it is much harder to measure users' adoption decisions than miners', so in many cases this idea of miner voting is overemphasized because of the http://en.wikipedia.org/wiki/Streetlight_effect

Miner voting is most useful for simple technical corrections where there is little contraversy and upgrading is unlikely to ever by an issue for users beyond an "oops" when they see a message that their client is out of date. It has been proposed as part of a plan to address transaction malleability in bitcoin, and is probably good for that. It is also very nice, certainly ideal, that any hard fork have strong support from both users and miners, and of course that requires miners' support as a subset. Miner voting can tell you that at least.

It would be a terrible way to handle the bitcoin blocksize debate, though.

Where'd ArticMine's reply go?

My initial reaction to this is that while this makes a lot of sense over the next 18 months with the impact felt over the next 30 months I would advise extreme caution after that. I believe there are important lessons here from Bitcoin and also from Ripple and even Dash.

The reason why Bitcoin is hard to fork can best be summarized as a result of maturity. Satoshi did not have any problem implementing the 1MB limit in 2010, now compare this with the debate over the 1MB limit that has been raging since at least 2013. There were clear warnings back in 2010 with Bitcoin as can be seen from the following thread. https://bitcointalk.org/index.php?topic=1347.0;all The following quote from caveden in November 2010 is prophetic.

“Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.”

The reality is that for a true Decentralized Virtual Currency (I am using the FinCEN Definition http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.html ) it becomes very hard to hard fork after two years, unless the hard fork is driven by an emergency or it fundamentally does not change any of the economic aspects of the currency. This is the key lesson from Bitcoin. We must consider that as more and more services are built on top of Monero it will become harder and harder to hard fork. Even something like changing the number of block per hour has in Monero has already become harder simply because of the advent of XMR.TO. XMR.TO relies on confirming a Monero transaction and having Bitcoin sent to a Bitcoin address withing the 10-15 min period that many Bitcoin payment processor use. Now change the blocktime from 1 min to say 2 min and the economics of XMR.TO as a business are fundamentally changed. Just take a look on how hard it is for the Internet to change from IPv4 to IPv6. This change will only happen when the pain of not changing becomes real. Hard forks are possible in Bitcoin now but they must be driven by significant pain, such as for example the hard fork that occurred in the Spring of 2013. I believe Bitcoin will hard fork over the 1MB, but only after the pain becomes obvious, as will the Internet “hard fork” to IPv6 but again only after the pain is felt.

The alternative is what Ripple has done and to a large degree what Dash is doing. While it is simple for Ripple Labs to “hard fork” Ripple this comes at the huge cost of becoming a Centralized Virtual Currency. This makes the developers MSBs and give a regulator the leverage they need to push through the protocol changes they desire. This is precisely what has happened to Ripple. Dash will likely provide an important test case because it literally straddles the Decentralized Virtual Currency / Centralized Virtual Currency Definition. How regulators deal with Dash will provide critical precedents and lessons not just for Monero but for many Virtual Currencies. The lesson here is make hard forks easy and efficient and one runs the very real risk of becoming a Centralized Virtual Currency with the developers as the “Administrators”.

One a related note the idea of forcing software upgrades every 6 months to a year as an ongoing policy is doomed to failure. One only needs to take a look at the fierce resistance most business big and small have to Microsoft's software upgrade cycle. Who can blame them. Upgrading Windows means significant costs with miniscule if any productivity gains. The proper response from any business is to delay the upgrade as much as possible in order to minimize these costs. This resistance is also manifested for example in the Internet IPv4 to IPv6 upgrade for exactly the same reason.

In conclusion I say what is being proposed will work very well for only two maybe three six month cycles after that Monero will become like SMTP, IPv4/IPv6 etc with hard forks only possible in emergencies and / or when the pain of not hard forking is patently obvious. The alternative is a degree of centralization and regulatory risk that most members of the community will find unacceptable.

Edit: Fork and pray keeps the regulator away.

Isn't this going to create a debate on which hard-fork to implement every six months? Could this cause a schism? Is there a possibility of a hardfork tie? Or too many hardfork possibilities leading to a break?

I guess my main question is who decides on the hardfork attributes, how is their position determined, will it be more than a one person decision? If it is more than one person, how will consensus be achieved in the hardfork's attributes? And if there isn't consensus, will it be miner's voting and what prevents a tie or multiple forks from occurring?

I'm worried about the human factors more than computer factors here; people lusting after power or money has always had unintended consequences, and the more Monero grows, the more these factors will take effect.

One can see how difficult it is to hard-fork in Bitcoin. People are legitimately afraid of it because it's handled in such a ad-hoc way everytime it must happen.

If Monero can have such an organized hard-fork-release schedule right from the beginning, all users and developers will feel at ease with these inevitable events in the future. So I completely support this idea!

Overall I agree with the general sentiment that this is better than the other alternative listed here.

My initial reaction also included a small bit of recoil. My nature is conservative (to a fault at times) and I am inclined to "leave well enough alone". Sometimes budgets scare me since some people approach a budget like: "So.. we have M10,000, but only see M7,000 worth of stuff to spend it on... what else should we buy".

In this way I would hate to think this would foster an environment of change for change sake.

"Well the next fork is coming... what should we use it on?"

Another way of saying it is this: Bitcoin is struggling somewhat against it's own constraints. And many of us can see the negative in this. However, there is a sort of stability that comes with these constraints. We know fundamental change is less likely with the way Bitcoin is built and guided by it's core community.

OK. All that said... In the final analysis I see this is a generally positive idea. I just wanted to shoot out that one caveat.

i want to talk mostly about quality assurance and change management in this post. writing english takes me a lot of energy so i try to make it short:-) First of all, i have no experience in open source projects and its change/release management methods, but i know how big banks and payment processors develop financial software. Also i do not know anything about the deployment process and policy of monero testnet.

new branch means new risk. to be on the safe side and flexible enough with this kind of branching i would recommend you having at least one more testnet instance. also i do not know how far you can run the trunk/your own branch locally, so its difficult to give an advice without really knowing how you prefer to work.

as long as open bugs still can be fixed, one month freeze sounds fine, maybe a little long, but depends on the testing efficiency too.

you devs know best if 6 months is enough or if 3 would be better (and off after 6), there is no need to punish yourself with this. as long as emergency changes are excluded of course (should be possible to completely disable this feature and hardfork immediately) me personally would welcome 3 months, but i do not know if this is possible with still keeping quality high and risks low.

in general i would not make to many rules so in the end you have to make a lot of exceptions. as light as possible is best. my feeling is that 1 year is too long for now, but if we mature more it will be very useful for users to have this. (as we know allready, usability is key). even more non functional things like reliability and robustness of the network profit from it.

maybe you should also think about a method to estimate how much nodes/blocks allready use the new branch, so you can lower the praying even more once the real hard fork kicks in.

all in all, i like it. if i have more info i can give better advise regarding quality assurance

it puts Monero right on its track as scalable cryptocurrency, as long as emission and other key economic aspect that were already agreed upon by the community are maintained, from the record I can see most improvements will be made towards better privacy and more efficiency. So I support this idea as well.

Yes, dates with GMT times for clients dropping off network, very elegant approach fluffy. I support it

Without going into details why it is so, I believe that the benefits of the stated approach reasonably overweigh the alternative, which is to "fork and pray" as the OP put it.

My only concern would be if this method opens a avenue for attack. GA makes a good point as well.