Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 29AF989E for ; Sun, 26 Mar 2017 11:27:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B0EB196 for ; Sun, 26 Mar 2017 11:27:32 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id o67so1451122oib.1 for ; Sun, 26 Mar 2017 04:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dxBKMPaVe3yzfXeapf5b5Nop4yO/NdbjHEPYyD6LF+M=; b=MEU4Aepg6rD9EQeMS9/8tlLe43keWRQLMppIjIoBXDNAX2qS/vGDAF1sTwLxZwg2Zj 2pmObhJX37zYVC1nyurEu1IemfnOcFg8U8VEAGrAe/iyz+yMM6msykBwhn/TQfub7ZXR hx2GPLdqXRo7VVdxM31UI2CmDVLTkt7XEGezbopLmaEMeBVWMd+0VfANZMqINLlDBETS re+2ceAW/f0XrXCHsN6QyhDqe4/O+q2NR+70qTdxYxKS7CRPSAHK1NT9g1ySstdXopwY OkuhnkEVQw4l+u+g4+5KaUYImrE0iaHIXvhOIsAMxc/ib2wDVEfCk4zNMCECMJ7EA0hM Os5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dxBKMPaVe3yzfXeapf5b5Nop4yO/NdbjHEPYyD6LF+M=; b=IrIafvD6OPNGXKMmBgOGy9E979RWrpt0bbVwtdQ+vu7N/DUHxDAoh/uJ9pLUvxsnOd s2c2pr4ict//pzWWFAvT9UGTTVv//9baOXcNkRsl9nOtPaKs/CogX9c89Xm5OrkEfyUq q/7cfDOs4lJc2SEvlTTgRtCSTBCMWrehuBWLptWaP+CrLPutl+tx4AEWVqHx0eBBcvAA YMMKaKKJhpp0RjzGm/zZzZOLwhKchRnRUGxOsjl0hLuxUQ0oWrYOlEIp0eZ3zDHIyqh8 687iOoz73ejFi5MkfAdHZaOtQaorz5eRREguHR4jBsyUTyR4q8E8EYvvw6fs2LXQUiDm FNmQ== X-Gm-Message-State: AFeK/H0eY58ZpM703Dp7VjWeNHYl/qGF55X8C0X9qF/C5bCagcmuvyInG4x4WauJw6FI3hZly7tLwrD7hmiJnQ== X-Received: by 10.202.69.130 with SMTP id s124mr8907481oia.17.1490527651402; Sun, 26 Mar 2017 04:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.246.102 with HTTP; Sun, 26 Mar 2017 04:27:30 -0700 (PDT) In-Reply-To: References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info> <35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com> <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com> From: Alex Morcos Date: Sun, 26 Mar 2017 06:27:30 -0500 Message-ID: To: Chris Pacia Content-Type: multipart/alternative; boundary=001a113ddd2e309a44054ba083d1 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 11:27:33 -0000 --001a113ddd2e309a44054ba083d1 Content-Type: text/plain; charset=UTF-8 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 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. > > > --001a113ddd2e309a44054ba083d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No I actually agree with a lot of what you said.

<= div>I feel there has been a lack of precision and consistency in talking ab= out these things in the past.=C2=A0 This is not intentional, but its just w= hat happens when a lot of different people are all giving their own argumen= ts.

I tried to be a bit more clear by talking abou= t how soft forks have historically been done.=C2=A0 But certainly the techn= ical definition of a soft fork is a slippery slope.=C2=A0 I completely disa= gree with the idea that miners have any right to enforce a soft fork.=C2=A0= Even more strongly, I don't think they have the ability.=C2=A0 Censori= ng 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.=C2=A0 It is necessarily transient. It requires nodes to enforce = the rules to make it a permanent soft fork.

I do t= hink there are differences between soft forks and hard forks and consensus = requirements and safety for rolling them out.=C2=A0 But as mentioned in my = email, I think soft forks should still have a very high bar for consensus.= =C2=A0 It's an open question as to whether Core misjudged this for segw= it, although if so, I think it was a close call.=C2=A0 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). =C2=A0 It seems to m= e that the vast majority of the community is in favor of segwit.=C2=A0 I= 9;m not sure about your comment that it is obvious to an observer than a si= zable portion of the community is opposed.=C2=A0 It is certainly some, and = perhaps more than expected.=C2=A0 But this is exactly why the new version b= its soft fork roll out mechanism allows proposals to expire. We did do an e= xtensive 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 minorit= y.=C2=A0 No business we contacted was opposed.=C2=A0 If it turns out we got= it wrong then the proposal will expire harmlessly.=C2=A0 I for one am cert= ainly opposed to forcing segwit or any other fork of any kind on a signific= ant 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.=C2=A0 There= is some logic behind this idea.=C2=A0 But these are all subtleties which a= re hard to make strong right and wrong statements about.=C2=A0 See some of = the past discussion on this list.


<= br>

On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <ctpacia@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 split= ting.

I just want to point out what appears to be doublespeak= going on here.=C2=A0

Fi= rst, 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 consi= deration was given to these people when designing segwit as a softfork. I b= elieve it was Luke who went as far as saying consensus does not matter when= it comes softforks.=C2=A0

Furthermore, when segwit was first introduced it kicked off a round of s= oftfork/hardfork debate which I participated in. The primary concern that I= and other raised was precisely what is going on now.. that miners could un= ilaterally impose an unpopular change to the protocol rules.=C2=A0

At the time I told, rather force= fully, by multiple people that miners have an "absolute right" to= softfork in whatever rules they want. Which, of course, is absurd on it= 9;s face.

But I don'= t see how people can make such claims on the one hand, and then complain wh= en this process is used against them.

It amounts to nothing more than "When it's rules I l= ike we get to impose them on non-consenting users. When it's rules I do= n't like it's an attack on the network".=C2=A0

It was completely obvious this entire= time that softforks were a very slippery slope, now we are indeed sliding = down that slope.=C2=A0

<= br>

--001a113ddd2e309a44054ba083d1--