to fork or not to fork: a decision left to the miners?

[zeuner]

Ok, so miners decide over whether to fork or not by setting their preferred version bits in the mined blocks. But wait! What if a bunch of rogue miners with a lot of hashing power would try to enforce a fork against the will of all other users? As miners will want their revenue, they will want to sell their mined coins. But if no other user would want to pay for coins correlated to the fork, enforcing the fork would mean a costly revenue loss.

While real world scenarios are hardly as simple as the one sketched above, it suggests that Bitcoin may be more democratic for non-miners with respect to forking decisions if common wallet implementations would allow distinguishing between version bits of the blocks where the coins originate from.

Any thoughts or objections?

[illyiller]

Ok, so miners decide over whether to fork or not by setting their preferred version bits in the mined blocks. But wait! What if a bunch of rogue miners with a lot of hashing power would try to enforce a fork against the will of all other users? As miners will want their revenue, they will want to sell their mined coins. But if no other user would want to pay for coins correlated to the fork, enforcing the fork would mean a costly revenue loss.

While real world scenarios are hardly as simple as the one sketched above, it suggests that Bitcoin may be more democratic for non-miners with respect to forking decisions if common wallet implementations would allow distinguishing between version bits of the blocks where the coins originate from.

Any thoughts or objections?

Regarding the bolded -- that's exactly what a contentious hard fork does. And that's exactly why we need a very high threshold for consensus in case we hard fork. (90-95% IMO)

Inevitably, in the case of a "civil war" (to use Nick Szabo's words) where we have surviving, competing blockchains, wallets will need to be able to distinguish between inputs that were created before and after the hard fork (and if created after the fork, to which fork they belong).

[zeuner]

Inevitably, in the case of a "civil war" (to use Nick Szabo's words) where we have surviving, competing blockchains, wallets will need to be able to distinguish between inputs that were created before and after the hard fork (and if created after the fork, to which fork they belong).

That's for sure. But I'm talking about the pre-fork situation, where a distinction between coins is not necessary for creating correct (protocol-conforming) transactions.

In this situation, I would argue that there is still an advantage in being able to distinguish between coins coming from miners voting for or against the fork. Then, the free market can decide about the fork.

[killerjoegreece]

Ok, so miners decide over whether to fork or not by setting their preferred version bits in the mined blocks. But wait! What if a bunch of rogue miners with a lot of hashing power would try to enforce a fork against the will of all other users? As miners will want their revenue, they will want to sell their mined coins. But if no other user would want to pay for coins correlated to the fork, enforcing the fork would mean a costly revenue loss.

While real world scenarios are hardly as simple as the one sketched above, it suggests that Bitcoin may be more democratic for non-miners with respect to forking decisions if common wallet implementations would allow distinguishing between version bits of the blocks where the coins originate from.

Any thoughts or objections?

I think the miners have a word in this and they will decide the outcome of this debate

[countryfree]

I've seen some women hiding banknotes in their bra, and some other in their socks. Both banknotes were used and accepted wherever they needed them, with the people receiving those banknotes without any after-thought.

Money's money.

[odolvlobo]

Ok, so miners decide over whether to fork or not by setting their preferred version bits in the mined blocks. But wait! What if a bunch of rogue miners with a lot of hashing power would try to enforce a fork against the will of all other users? As miners will want their revenue, they will want to sell their mined coins. But if no other user would want to pay for coins correlated to the fork, enforcing the fork would mean a costly revenue loss.

While real world scenarios are hardly as simple as the one sketched above, it suggests that Bitcoin may be more democratic for non-miners with respect to forking decisions if common wallet implementations would allow distinguishing between version bits of the blocks where the coins originate from.

Any thoughts or objections?

Miners can't force anyone to use their branch of the block chain any more than Litecoin miners can force someone to switch to Litecoin. Miners just produce a block chain. If there are two branches, then full nodes and other users decide which branch they want to follow.

The winner of the block size debate won't be decided by the miners. It will be decided by the users. If 90% of the users pick the Core branch and 10% pick the XT branch, then the Core branch will dominate even if only 1% of the miners mine it. Miners will be forced to mine the branch that users choose because if they mine the losing chain, they won't be able to use the bitcoins they mine.

Unfortunately, it is possible for both branches to persist, though that would cause major problems (what Nick Szabl calls a "civil war"). To avoid a disaster, there must be enough users choosing one branch to coerce the rest of the users to also choose that branch. This is why Gavin is working to convince exchanges and wallet providers to jump on the XT bandwagon.

[zeuner]

Inevitably, in the case of a "civil war" (to use Nick Szabo's words) where we have surviving, competing blockchains, wallets will need to be able to distinguish between inputs that were created before and after the hard fork (and if created after the fork, to which fork they belong).

While I first dismissed your comment because it was related to a post-fork situation while I tried to discuss pre-fork mechanisms, I do think now that the approach you described may work pretty well to supplement what I suggested. I will try to explain:

0. Developers threaten with a fork because of disagreement over block sizes and use block version numbers to coordinate it.

1. There are now both users who see more merit in small blocks, and users who see more merit in large blocks. Because miners pushing towards the disfavoured option contribute towards an expected future risk of having to deal with the disfavoured block size, those who accept BTC start to refuse accepting BTC coming from the coinbase transaction of a block that chose the disfavoured option, or at least to charge more BTC in this case in order to hedge the risk.

2. Business between small block proponents and large block proponents becomes more difficult.

3. Now, the fork happens, but in step 2, the business relationships have already evolved towards mostly being between proponents of the same block size, so the fork is less disruptive (it essentially only destroys the possibility of moving coins between small-blockers and large-blockers.

Step 0 is what we have.

Step 1 is what I suggested when starting the thread.

Step 3 is the post-fork situation where it became unavoidable to distinguish between the different forked chains.

[zeuner]

Regarding the bolded -- that's exactly what a contentious hard fork does. And that's exactly why we need a very high threshold for consensus in case we hard fork. (90-95% IMO)

I think the bad thing about the current approach may not be the 75% threshold, but the relatively short timespan of 1000 blocks over which it is being measured. In my opinion, miners should be forced to commit themselves towards their block size choice for a much longer time before attempting to fork.

[zeuner]

We get to vote now (somebody made an app for that)


https://bitcointalk.org/index.php?topic=929659.0

https://www.cryptocoinsnews.com/cryptovoter-brings-decentralized-voting-bitcoin-oct-23-vote-increase-block-size/

"Oct. 23, there is a vote on whether to increase the maximum block size.

For the first time, the Bitcoin community can objectively gauge coin-holder support for controversial developer proposals and give developers the mandate they need to implement change,” the company noted in a press release."

Oh great! "Someone made an app for that". What's next? We can now avoid BTC's crypto because someone made an app.

What I'm getting at here is that the BTC protocol may already enable us to vote, because we can avoid accepting BTC from miners who work towards the wrong goal.

[odolvlobo]

Inevitably, in the case of a "civil war" (to use Nick Szabo's words) where we have surviving, competing blockchains, wallets will need to be able to distinguish between inputs that were created before and after the hard fork (and if created after the fork, to which fork they belong).

At first, both branches of the fork would contain the same transactions because the issue does not concern most transactions. The only transactions that would be rejected on one branch would involve the bitcoins rewarded to miners on the other branch. The branches would become more incompatible as the bitcoins rewarded to miners after the fork are circulated.

There would be an interesting situation where coins created before the fork can be spent twice (once on each branch) after the fork.

[zeuner]

Ok, so miners decide over whether to fork or not by setting their preferred version bits in the mined blocks. But wait! What if a bunch of rogue miners with a lot of hashing power would try to enforce a fork against the will of all other users? As miners will want their revenue, they will want to sell their mined coins. But if no other user would want to pay for coins correlated to the fork, enforcing the fork would mean a costly revenue loss.

While real world scenarios are hardly as simple as the one sketched above, it suggests that Bitcoin may be more democratic for non-miners with respect to forking decisions if common wallet implementations would allow distinguishing between version bits of the blocks where the coins originate from.

Any thoughts or objections?

Interesting:

In order to facilitate a more practical approach of investing into a particular vote in a "IsSuperMajority" forking decision (as we have it right now regarding the block sizes), I contacted different BTC marketplace operators in order to survey them on whether they could make it possible to buy only coins coming from blocks with the preferred vote stored in the version number.

I encountered different nuances of interest for this approach. But the most energetic expression of displeasure came from the German marketplace "bitcoin.de", where I was contacted by an executive who held out the prospect of terminating my account in face of my inquiries regarding the qualitative differences of the traded coins. I'm eager to see whether I will receive some objective explanations on why they find this disfavourable. I didn't expect to hit such a "hot" topic with this so that someone would even consider to terminate a multi-year and prosperous business relationship because of this.

[Soros Shorts]

where I was contacted by an executive who held out the prospect of terminating my account in face of my inquiries regarding the qualitative differences of the traded coins. I'm eager to see whether I will receive some objective explanations on why they find this disfavourable. I didn't expect to hit such a "hot" topic with this so that someone would even consider to terminate a multi-year and prosperous business relationship because of this.

I would view your inquiries as a potential threat to the fungibility of coins traded on the exchange. Maybe the executive feels the same?

Imagine if people started pricing coins differently based on who mined them. Next, people would start asking for taint history.