Wondering out loud: Which should Chinese miners support - Core, Classic or another?

[watashi-kokoto]

That's a half-truth.

I'm sorry, care to elaborate? I forgot why you're ignored

[johnyj]

I don't think a constitution will fly. Bitcoin is an incentives machine. If something changes it will be because the incentive structure has changed somehow.

Innit?

Of course incentives is also part of the picture. Since currently there is no such kind of code, anything can be openly discussed, you can look at Classic where they are trying to make such constitution, to decide on some basic rules that should never change

It can be very specific, for example always 21 million coin supply.  But it can also be very abstract, like to keep the miner incentive intact, for example averagely 50 bitcoins per block forever (This unavoidably will limit the block size)

The constitution is about the part that almost never changes, so that if you disagree with those rules, for example 21M bitcoin, you better leave for another coin

Another part is about the decision making, e.g. how to reach consensus in a community full of different people with different political/culture/religion ideology. There is still no good way to count user's opinion, using hash power voting is not a really good method

[BlindMayorBitcorn]

I don't think a constitution will fly. Bitcoin is an incentives machine. If something changes it will be because the incentive structure has changed somehow.

Innit?

Of course incentives is also part of the picture. Since currently there is no such kind of code, anything can be openly discussed, you can look at Classic where they are trying to make such constitution, to decide on some basic rules that should never change

It can be very specific, for example always 21 million coin supply.  But it can also be very abstract, like to keep the miner incentive intact, for example averagely 50 bitcoins per block forever (This unavoidably will limit the block size)

The constitution is about the part that almost never changes, so that if you disagree with those rules, for example 21M bitcoin, you better leave for another coin

Another part is about the decision making, e.g. how to reach consensus in a community full of different people with different political/culture/religion ideology. There is still no good way to count user's opinion, using hash power voting is not a really good method

https://en.bitcoin.it/wiki/Prohibited_changes

That's a half-truth.

I'm sorry, care to elaborate?

Fatty's not a shill.

[johnyj]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

[BlindMayorBitcorn]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

But that's what BIP's are for.

[johnyj]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

But that's what BIP's are for.

BIP's  are design proposals, but how are they get approved? That's decision making mechanism

Currently they are approved by the 5 core devs that have Git commit right, but their approval does not mean the approval of miners and other interested community members. And this is especially problematic when those 5 core devs have a conflict of interest themselves

[BlindMayorBitcorn]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

But that's what BIP's are for.

BIP's  are design proposals, but how are they get approved? That's decision making mechanism

Currently they are approved by the 5 core devs that have Git commit right, but their approval does not mean the approval of miners and other interested community members. And this is especially problematic when those 5 core devs have a conflict of interest

Conflict of interest is a problem in principle. I agree. But there's no such thing as an unbiased position.

Can you elaborate on the specific conflicts?

[Luke-Jr]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

But that's what BIP's are for.

BIP's  are design proposals, but how are they get approved? That's decision making mechanism

Currently they are approved by the 5 core devs that have Git commit right, but their approval does not mean the approval of miners and other interested community members. And this is especially problematic when those 5 core devs have a conflict of interest themselves

Not quite. First of all, git commit access is not a privilege at all - it is only a job of merging things which has passed peer review.
Secondly, BIPs do not require approval from any Core devs.

Most BIPs simply need approval from multiple software projects (Core or otherwise) which implement them. For example, lots of wallets implement BIP 13 (p2sh address format), and a number of mining programs implement BIP 22 (getblocktemplate).

Softfork BIPs need approval from a supermajority of miners. For example, BIP 65 not long ago was adopted by 95% of the network hashrate.

Hardfork BIPs need approval from everyone using Bitcoin. The only hardfork ever in the history of Bitcoin was in the aftermath of the 2013 crisis, with no argument against it whatsoever. We do not yet have a single example of a hardfork deployed in non-crisis situations or by planned agreement in advance, much less a contentious hardfork that has successfully been forced on a subset of the community.

[johnyj]

Conflict of interest is a problem in principle. I agree. But there's no such thing as an unbiased position.

Can you elaborate on the specific conflicts?

Just because conflict of interest will always happen in a community full of libertarian type of people, you can not use traditional top-down model decision making mechanism

Consensus decision making model has been promoted before the HongKong conference, but judging from that conference, everyone is working on their own agenda blindly

[johnyj]

The most important is the decision making mechanism

Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource

But that's what BIP's are for.

BIP's  are design proposals, but how are they get approved? That's decision making mechanism

Currently they are approved by the 5 core devs that have Git commit right, but their approval does not mean the approval of miners and other interested community members. And this is especially problematic when those 5 core devs have a conflict of interest themselves

Not quite. First of all, git commit access is not a privilege at all - it is only a job of merging things which has passed peer review.
Secondly, BIPs do not require approval from any Core devs.

Most BIPs simply need approval from multiple software projects (Core or otherwise) which implement them. For example, lots of wallets implement BIP 13 (p2sh address format), and a number of mining programs implement BIP 22 (getblocktemplate).

Softfork BIPs need approval from a supermajority of miners. For example, BIP 65 not long ago was adopted by 95% of the network hashrate.

Hardfork BIPs need approval from everyone using Bitcoin. The only hardfork ever in the history of Bitcoin was in the aftermath of the 2013 crisis, with no argument against it whatsoever. We do not yet have a single example of a hardfork deployed in non-crisis situations or by planned agreement in advance, much less a contentious hardfork that has successfully been forced on a subset of the community.

Of course it is not a strict benevolent dictator type of management, but still those changes are seldom communicated well with miners before they are implemented

Soft fork can cause unprepared hard fork, the July 04 fork is an example. It indicated that miners don't fully understand the consequence of BIP66, that is because they did not took part in the decision making process of BIP 66, thus they blindly follow the recommendation from core devs, and as a result, lost lots of coins

[achow101]

Of course it is not a strict benevolent dictator type of management, but still those changes are seldom communicated well with miners before they are implemented

Soft fork can cause unprepared hard fork, the July 04 fork is an example. It indicated that miners don't fully understand the consequence of BIP66, that is because they did not took part in the decision making process of BIP 66, thus they blindly follow the recommendation from core devs, and as a result, lost lots of coins

What do you mean they did not take part in the decision making? Of course they did, that was how the fork happened, when most of the miners supported BIP66 by producing the properly versioned blocks. It is just that they were SPV mining so they didn't check the validity of the invalid block they mined on which is what caused the fork. What does that have to do with then not participating the decision making?

Besides, Wang Chun, the operator of F2pool, actively participates in development. He posts on the mailing list, sometimes on IRC, and sometimes on Github. He is definitely a part of the decision making process. I'm sure that several other large pool operators do the same, I just don't know their names.

[johnyj]

Of course it is not a strict benevolent dictator type of management, but still those changes are seldom communicated well with miners before they are implemented

Soft fork can cause unprepared hard fork, the July 04 fork is an example. It indicated that miners don't fully understand the consequence of BIP66, that is because they did not took part in the decision making process of BIP 66, thus they blindly follow the recommendation from core devs, and as a result, lost lots of coins

What do you mean they did not take part in the decision making? Of course they did, that was how the fork happened, when most of the miners supported BIP66 by producing the properly versioned blocks. It is just that they were SPV mining so they didn't check the validity of the invalid block they mined on which is what caused the fork. What does that have to do with then not participating the decision making?

Besides, Wang Chun, the operator of F2pool, actively participates in development. He posts on the mailing list, sometimes on IRC, and sometimes on Github. He is definitely a part of the decision making process. I'm sure that several other large pool operators do the same, I just don't know their names.

If they really actively participated in the decision making process of BIP66, they would have known that BIP66 might create a hard fork, thus they will reject BIP66 from the beginning. Or do much more preparation to prevent such a hard fork from happening. Just like we are now discussing the hard fork that Segwit soft fork could generate

The problem is technical and language barrier, so that miners might never reach same level of understanding like core devs, thus there must be enough good communication to be sure they are totally clear of all the consequences of a change. In fact even core devs themselves can not see all the possible attack vector if the solution is too complex

But this is too technical, basically the communication between core devs and rest of the community is broken because of the technical and complexity barrier, but as long as this barrier is there, there is no way to reach consensus, thus the way to reach consensus becomes politics/culture/religion. I guess that if some day Arabic countries control majority of hash power, only Muslim devs code will get their support  

Technical barrier is usually used in centralized organizations to enforce their decision. But in bitcoin community, it has exactly opposite effect, e.g. it makes sure that no consensus thus no decision can be made

[Luke-Jr]

If they really actively participated in the decision making process of BIP66, they would have known that BIP66 might create a hard fork, thus they will reject BIP66 from the beginning.

BIP66 could not and did not create a hard fork.

[hdbuck]

If they really actively participated in the decision making process of BIP66, they would have known that BIP66 might create a hard fork, thus they will reject BIP66 from the beginning.

BIP66 could not and did not create a hard fork.

pretty sloppy tho:

http://www.contravex.com/2015/07/04/bitcoins-4th-of-july-independence-from-america-day/

no more americans  

[BitUsher]

Some Chinese translations of current sentiments on Classic-

https://bitcoinzh.com/chinese-response-to-bitcoin-classic-hard-fork/

BitcoinZH Introduction: Disappointment with Gavin's failure to support the Chinese 90%/2MB proposal, and offense caused by his concerns around miner centralization mark a lukewarm response to Bitcoin Classic on 8btc.com

https://bitcoinzh.com/has-anyone-upgraded-to-bitcoin-classic/

[BlindMayorBitcorn]

Some Chinese translations of current sentiments on Classic-

https://bitcoinzh.com/chinese-response-to-bitcoin-classic-hard-fork/

BitcoinZH Introduction: Disappointment with Gavin's failure to support the Chinese 90%/2MB proposal, and offense caused by his concerns around miner centralization mark a lukewarm response to Bitcoin Classic on 8btc.com

https://bitcoinzh.com/has-anyone-upgraded-to-bitcoin-classic/

I'm a notorious big blocks shill (it seems) and even I think 75% is too low.

[Fatman3001]

Some Chinese translations of current sentiments on Classic-

https://bitcoinzh.com/chinese-response-to-bitcoin-classic-hard-fork/

BitcoinZH Introduction: Disappointment with Gavin's failure to support the Chinese 90%/2MB proposal, and offense caused by his concerns around miner centralization mark a lukewarm response to Bitcoin Classic on 8btc.com

https://bitcoinzh.com/has-anyone-upgraded-to-bitcoin-classic/

I'm a notorious big blocks shill (it seems) and even I think 75% is too low.

There'll be a lot of cat herding for 90%. And I cannot think of anyone in the Bitcoin community who doesn't cause offense consistently.

[BlindMayorBitcorn]

Some Chinese translations of current sentiments on Classic-

https://bitcoinzh.com/chinese-response-to-bitcoin-classic-hard-fork/

BitcoinZH Introduction: Disappointment with Gavin's failure to support the Chinese 90%/2MB proposal, and offense caused by his concerns around miner centralization mark a lukewarm response to Bitcoin Classic on 8btc.com

https://bitcoinzh.com/has-anyone-upgraded-to-bitcoin-classic/

I'm a notorious big blocks shill (it seems) and even I think 75% is too low.

There'll be a lot of cat herding for 90%. And I cannot think of anyone in the Bitcoin community who doesn't cause offense consistently.

IDK. I don't usually participate in technical discussions.

Can we do this here?

[BitUsher]

I'm a notorious big blocks shill (it seems) and even I think 75% is too low.

Peter Todd explains how one can deploy hardforks more safely by setting the bar to 99+% and than if the threshold is not met in a month of stagnation below that threshold one can use a method to softfork the code down to 96%

To give Garzik a little bit of credit , he attempted to raise the the threshold to a slightly better number of 80% but was shutdown by Olivier Janssens in a couple minutes with support of the lead classic dev

https://twitter.com/_jonasschnelli_/status/693461617296678912
https://github.com/bitcoinclassic/bitcoinclassic/pull/60#issuecomment-177162092

It doesn't appear that Classic will budge to the concerns to the miners wanting at least 90%.

There'll be a lot of cat herding for 90%. And I cannot think of anyone in the Bitcoin community who doesn't cause offense consistently.

This exemplifies one of the key political differences between many Core Devs and the Classic Supporters. Classic supporters are ok with democracy determining hard forks, while most Core Devs believe that near complete consensus should be met for a change in the consensus mechanism that could fork/force off old versions of the code.

[sturle]

If they really actively participated in the decision making process of BIP66, they would have known that BIP66 might create a hard fork, thus they will reject BIP66 from the beginning.

BIP66 could not and did not create a hard fork.

pretty sloppy tho:

http://www.contravex.com/2015/07/04/bitcoins-4th-of-july-independence-from-america-day/

no more americans  

All chainforks are not hardforks.  Short chainforks happens every day.  Usually because miners can't distribute their newfound blocks fast enough.  This one was caused by a malicious miner not validating blocks, and mining on top of an invalid one.  It disappeared as soon as the correctly validated chain overtook it.  This only show the dangers of one miner controlling too much hashrate.  All nodes, new and old, accepted the correctly validated chain as soon as it overtook the bad chain, and nobody were forced to upgrade anything.  (Those who hadn't upgraded were potentially vulnerable to double spends however, as with all chainforks when you don't require enough confirmations.  This is a good reason for merchants to stay up to date.)

The August 2010 fork was much longer, btw.  That fork was caused by a bug which had to be fixed for the nodes to reject the faulty chain.

A hard fork is different.  In a hard fork where the fork has a miner majority, the two chains will live on in parallel.  Correctly validating nodes will never switch to the fork.  The so-called "Classic", "XT", "Unlimited", etc forks are especially dangerous, since upgrading won't help either.  There will just be different coins, and you have to make a choice of one of them.  Due to incompetent fork developers, you can't even run one of the other coins on the same computer at the same time as Bitcoin Core, since they demand to bind to the same ports.  Constantly keeping up with which fork to use this week is too much for most users, and since their SPV wallets will be rendered useless, they will probably just try to get rid of their coins ASAP.  It would be sad end for Bitcoin, I think.

If some competent developer should think about forking bitcoin, he should start here and get 100% consensus first.  There are many good reasons for a fork.  Forking for a simple block size change is just dumb, and most people see that.