No I actually agree with a lot of what you said. I feel there has been a lack of precision and consistency in talking about these things in the past. This is not intentional, but its just what happens when a lot of different people are all giving their own arguments.
I tried to be a bit more clear by talking about how soft forks have historically been done. But certainly the technical definition of a soft fork is a slippery slope. I completely disagree with the idea that miners have any right to enforce a soft fork. Even more strongly, I don't think they have the ability. Censoring a certain class of transactions (such as those invalid under a soft fork) is something they can unilaterally do, but it is not the same thing as a soft fork. It is necessarily transient. It requires nodes to enforce the rules to make it a permanent soft fork. I do think there are differences between soft forks and hard forks and consensus requirements and safety for rolling them out. But as mentioned in my email, I think soft forks should still have a very high bar for consensus. It's an open question as to whether Core misjudged this for segwit, although if so, I think it was a close call. The intention is not to let 95% of miners make the rules (although again, note that it is 95%, a very high bar, vastly different than 75% of miners). It seems to me that the vast majority of the community is in favor of segwit. I'm not sure about your comment that it is obvious to an observer than a sizable portion of the community is opposed. It is certainly some, and perhaps more than expected. But this is exactly why the new version bits soft fork roll out mechanism allows proposals to expire. We did do an extensive job assessing support for segwit before roll out, and although we knew of a few loud voices against we judged them to be a very small minority. No business we contacted was opposed. If it turns out we got it wrong then the proposal will expire harmlessly. I for one am certainly opposed to forcing segwit or any other fork of any kind on a significant minority that is opposed. Despite saying that, I think you will hear some other responses about how soft forks are opt-in and if you don't like the new features don't use them. There is some logic behind this idea. But these are all subtleties which are hard to make strong right and wrong statements about. See some of the past discussion on this list. On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <ctpa...@gmail.com> wrote: > > > On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > As a Bitcoin user I find it abhorrent the way you are proposing to > intentionally cripple the chain and rules I want to use instead of just > peacefully splitting. > > > I just want to point out what appears to be doublespeak going on here. > > First, I think it would seem obvious to an observer that a sizable portion > of the community (certainly greater than 5%) view segwit as preventing > "rules I want to use instead of just peacefully splitting" but no > consideration was given to these people when designing segwit as a > softfork. I believe it was Luke who went as far as saying consensus does > not matter when it comes softforks. > > Furthermore, when segwit was first introduced it kicked off a round of > softfork/hardfork debate which I participated in. The primary concern that > I and other raised was precisely what is going on now.. that miners could > unilaterally impose an unpopular change to the protocol rules. > > At the time I told, rather forcefully, by multiple people that miners have > an "absolute right" to softfork in whatever rules they want. Which, of > course, is absurd on it's face. > > But I don't see how people can make such claims on the one hand, and then > complain when this process is used against them. > > It amounts to nothing more than "When it's rules I like we get to impose > them on non-consenting users. When it's rules I don't like it's an attack > on the network". > > It was completely obvious this entire time that softforks were a very > slippery slope, now we are indeed sliding down that slope. > > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
