[bitcoin-dev] Trinary Version Signaling for softfork upgrades

[eric at voskuil.org]

All good questions.

 

> Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants?

 

It’s important that people understand that “economic” does not refer to people interested in, HODLing, coding, or selling Bitcoin. It is only those who are *presently accepting* it. We refer to these as “economic nodes”. Those are the people with the economic power to reject coin that they consider invalid. Only their validation is of any economic consequence in the event of a split. I see no reason to assume that the economy is any less centralized than mining is pooled. Today the support of the economy would be best measured by meeting with exchange operators. If they did not go along, any unenforced soft fork (split) would isolate everyone who thought they could continue to trade their coin on exchanges.

 

I’d also question the use of the term “majority”. It applies to hash power, by design, but not to the economy. A split of any size is possible, requiring no majority. All it requires is other people to trade with.

 

Exchanges are highly regulated and compliant institutions. Mining operations are heavily pooled. Neither of these is inherently better than the other. Everyone can have a say by being a miner or being a merchant. Subeconomies can split, majority hash power can censor (which is the exact mechanism of soft fork enforcement). These ideas are straightforward and hardly worthy of debate. The interesting question is how one gets others to go along with his new coin. Make no mistake, any rule change (soft or hard) is a new coin. If hash power doesn’t enforce the new rules of a soft fork, the chain is split just as if it was a hard fork.

 

I’m sure people will continue to try and devise ways to figure out who wants to come along, to try and convince people (including exchanges and miners) to do so, to reassure them that everyone else will “have to”, and to mislead them about the actual behavior and risks. We’ve seen permanent splits, and we’ve seen hash power enforced soft forks. We’re likely to see more of both. But as core devs we have a responsibility to inform people, honestly, and let them decide. My only beef with this whole process has been that a widespread belief had formed, supported by far too many core devs (and even embedded in the text of deployed BIPs), that soft forks are inherently “backward compatible”. This is unequivocally not true. The only such compatibility is majority hash power enforcement of a soft fork. This is not a matter of opinion, it’s the core innovation of Bitcoin. Proof of Work settles the question of who has authority to order transactions. Majority hash power has that authority. Merchants can split again and again, but their miners will still have that authority. If one wants a say, one can mine.

 

e

 

From: Billy Tetrud <billy.tetrud at gmail.com> 
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric at voskuil.org>
Cc: Jorge Timón <jtimon at jtimon.cc>; Luke Dashjr <luke at dashjr.org>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

 

@Jorge

 

>I don't think we should avoid splits at all costs.

 

I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain. 

 

>  I don't think we should avoid splits when possible, 

 

I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules?

 

Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist? 

 

If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there. 

 

@Luke

 

Are you in agreement with Jorge here that we should not even attempt to avoid chain splits? 

 

> The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network.

 

There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future? 

 

I'm asking these questions to try and figure out why we disagree here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/cdb30f7e/attachment.html>