Quote from: johnyj on February 08, 2016, 07:53:46 PM

Quote from: madjules007 on February 08, 2016, 05:43:21 PM

I implied that the intent of this contentious hard fork is to remove Core's commit access to the dominant software implementation.

Regarding core software commit access, I heard that there are 5 core devs who have it: Gavin, Jeff, Wladmir, Greg, Pieter

So how the implementation of another fork outside of the core repo remove their commit access?

In fact I think in a direction difference situation, if those 5 people could not reach agreement about what should be implemented in the current git repo. Then nothing can be done, since each of them have the permission to revoke any change committed by others. So if one of them want to have one commit which is not welcomed by the other people, fork is the only way to go. Otherwise any implementation will only stay at test net without any hope of entering the core repository

This is the biggest contradiction: If you want a decentralized libertarian style community, you must have hard fork. If you want to avoid hard fork, then you must use a communism model

Read what I wrote again. I bolded the pertinent word. Core no longer has commit access to the dominant implementation if the majority of nodes run node software that is incompatible with Core (i.e. Classic). I'm not suggesting a majority of nodes would actually run Classic in reality, but that's the idea and the intent, yes. If, at the time of the hard fork, both miners and validating nodes do not approach consensus, multiple surviving blockchains are virtually guaranteed.

Forking is fine. Just do it with consensus -- that's all Core supporters ask. Hard forking to different consensus rules with only a temporary majority of hashing power (75% or realistically even less) and no realistic way to determine true node proportions simply threatens to break bitcoin into multiple blockchains. There is zero reason to assume a significant majority of nodes will be running Classic even if miners temporarily pool their hashpower to an extent that activates the hard fork.

Here's the important thing: If miners approach consensus, this ensures that hash power does not continue to build on the pre-fork-consensus chain -- i.e. miners will build on only one blockchain. Achieving node consensus is far less likely -- miners are far more centralized, and many nodes on the network rarely upgrade to newly-released versions, after all. If miners are building only on one chain, it won't matter if nodes have not achieved consensus. Nodes enforcing the old rules will just be observing a dead chain.

But if both miners and nodes do not achieve consensus, miners will build blocks based on different rule sets, and nodes will validate them based on different rule sets. This inevitably results in multiple surviving blockchains that can never be reconciled, and bitcoin will cease to be a single, cohesive ledger. This is why miner consensus (approaching 100%) is so important -- because of the impossibility of achieving full node consensus.

Again, forking is fine. Just do it with consensus -- or otherwise implement your fork as a stated altcoin. There are two camps here: one camp that either doesn't understand or doesn't care whether bitcoin is broken into multiple ledgers forever based on differing rule sets, and another camp that wants to avoid that. The block size debate is not worth breaking consensus over. The issue occurs to me as quite paltry, to be honest.