It's an open source project, so that's not quite the way it works (right now and in the future). I'll put up another post later about changes we want to make to the way contributors and code works, but suffice it to say that nobody will download a new version with a code snippet that gives fluffypony 50 billion XMR. Attempts to hide stuff in the code will be spotted. Attempts to change constants / agorithms without discussion will be rejected. So this isn't a free-for-all and then everyone is forced to update. Anything controversial will be pushed back and discussed (in fact it'll be discussed publicly before code is even written).

Where'd ArticMine's reply go?

the default view sux and make posts "disappear", set it to oldest or latest and you'll find his comment.

It is set on "latest". His first post is showing, but his second post is not showing. I can only see the very start of it by hovering his name in the "Reply to: sylviaplathlikestobake fluffypony ArticMine fluffy pony ArticMine" above the posts.

It wraps up replies you've already read so you can see the ones you haven't...possibly we've broken something in Latest/Oldest with this change, will have to investigate

@opennux can you send me a screenshot of what you're seeing so we can investigate?

@fluffypony - Give me a sec. Specifically it is post 1266. I can't even click it, like other replies. So "go to #post-1266", doesn't bring anything. Maybe ArticMine just deleted it?

I'm aware of the fold out option that exists also.

I hope the full presentation alleviates my concerns. I'm just leery of the Devs having too much influence when more power (in all its forms) gets introduced into the system.

@opennux this is what I see: http://i.imgur.com/Fq8wCR2.png - if I click on that "fluffypony and 3 others have replied" then I can see #1266

fluffypony did address, in the IRC dev channel, my key concern of unofficial node and / or mining clients, that otherwise meet the protocol requirements, being blocked from the Monero network by the regular “forced” upgrades. This is not going to happen. It is critical that these unofficial clients not be blocked in order to prevent the concentration of power in the devs and the regulatory risk that this would entail.

The case for the using the regular schedule for proactive / preventive hard forks is actually very strong. Yes there is on average an additional 3 month delay; however this has to be counterbalanced by removing the requirement to advise everyone that a hard fork is coming, and the time the devs would have to spend advising everyone.

There is both an upside and a downside to this approach. The upside is that surprise hard forks will not happen except in an emergency, so this means that the community will have plenty of notice. The downside is that this places an additional requirement of vigilance on the part of the community since in some respects this is more of an opt out rather than opt in approach.

With the above in mind I am prepared to support this proposal for at least 3 years subject of course to a material change in the full presentation.

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.