Quote from: d5000 on July 09, 2017, 04:16:05 PM

Quote from: DooMAD on July 09, 2017, 10:28:53 AM

Developers. Are. Not. Governors.
[...]
A hard fork resulting from a significant majority of those securing the network (that's a mix of both mining nodes and non-mining full nodes) freely choosing to run code enforcing new rules is exactly how Bitcoin was designed to work and is NOT a change in governance.

Allow me to _slightly_ disagree (although I support your conclusion - a hard fork supported by miners & economy is perfectly legit for me).

Developers have a kind of "informal" (de facto) power not granted by the protocol, but that was probably taken into account when Bitcoin was conceived. I would describe it as social leadership.

Miners and economic nodes - the two groups you're referring as the two main power holders - do not decide "out of thin air" what client/protocol version they run. They must choose from the available implementations. If they want to create an own implementation, there are a lot of costs for them because they would not only probably need to pay developers, but also they'd need a marketing fund to assure most Bitcoin users run compatible software.

That is only a descriptive analysis - I simply recognize that people perceive developers as "leaders", but that should not mean that I think they should dictate development. But they are an important power group. One of the reasons is probably that good developers are scarce, and so there is not much competition between development teams - so not every idea can get enough traction to be transformed into an implementation that works (and is essentially bug-free enough for a multi-billion dollar network like Bitcoin).

With the small caveat that it doesn't always have to be a single group of developers, I'd go with that, yes. There's an equilibrium to maintain. The direction can't be entirely dictated by nodes, miners or developers, so each have an important role to play.

Quote from: JayJuanGee on July 09, 2017, 08:17:57 PM

Thanks for your perspective, yet I am not going to concede that I am talking about this matter incorrectly...

Maybe we are getting caught up on semantics, yet the main framework of my contention should be obvious.

The fact of the matter has been that since XT, Classic and BU there have been various whiny attempts to complain that bitcoin is too stagnant and bitcoin needs to be able to change more easily and bitcoin was designed to be able to change easily... blah blah blah.. therefore hardfork and hardfork frequently in order that bitcoin can adjust to changing markets and become more competitive with modern payment systems blah blah blah.. bitcoin is broken the way it is and therefore it should be easier to change.

Those are attempts at changes in governance because they attempt to make bitcoin easier to change based on false premises and by assertions that there are technical problems and that bitcoin is broke and bitcoin should be x, y or z and it is not achieving.. blah blah blah.. Arguing that there is an emergency in order to deceive and trick into lowering consensus levels and consensus mechanisms.

So whether you disagree with my understanding or not or my use of the term 'governance", my point remains valid that there are ongoing complaints about the system that is in place (concededly evolving with the passage of time as you mentioned examples of possible ways to evolve) in order to attempt to lower various consensus thresholds and to make bitcoin more moldable, and even if some of those changes do occur over time, as you mentioned with your examples, it does not mean that there is not going to be resistance to various more extreme attempts, such as attempts to hardfork at lower consensus levels.

I only recall people saying that the code shouldn't ossify completely to the point where no change can ever be made. The notion that consensus should be easier to change was a smallblockist strawman and a baseless accusation from what I remember seeing. Maybe I just missed that particular argument, I don't know.

Plus, consensus changing once doesn't necessarily mean it's easier to change again, unless those who decided they couldn't follow along volunteered to fork away, meaning their voice would hold no weight in future forks. Think about it. If everyone who is involved in securing the network now remains part of the network after a fork, it's no easier or harder for consensus to change again in future because every participant still has the same power they always had. There's still no change in the consensus mechanism. It's still not a change in governance. You're still wide of the mark.