path: root/c8/f3219a4470807ed214dc66db5b0617035ca284

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 29AF989E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 Mar 2017 11:27:32 +0000 (UTC)
Received: by mail-oi0-f49.google.com with SMTP id o67so1451122oib.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAB+qUq47LUCSNUPZRY=ROrrHH5a6SLYrhwBs4msjWJt9ArUwpA@mail.gmail.com>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
	<35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com>
	<f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
	<9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
	<CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
	<CAB+qUq47LUCSNUPZRY=ROrrHH5a6SLYrhwBs4msjWJt9ArUwpA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
Date: Sun, 26 Mar 2017 06:27:30 -0500
Message-ID: <CAPWm=eXkNzgFEkd_Y23sHhWj3xQP4qtjBrh0J8Man5e6gFGLNQ@mail.gmail.com>
To: Chris Pacia <ctpacia@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 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

<div dir=3D"ltr">No I actually agree with a lot of what you said.<div><br><=
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.</div><div><br></div><div>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&#39;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.</div><div><br></div><div>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&#39;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&#3=
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.</div><div><br></div><div>Despite saying that,=
 I think you will hear some other responses about how soft forks are opt-in=
 and if you don&#39;t like the new features don&#39;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.</div><div><br></div><div><br></div><div><=
br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:ctpacia@gmail.com" target=3D"_blank">ctpacia@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span c=
lass=3D""><br><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gma=
il_quote">On Mar 25, 2017 10:38 PM, &quot;Alex Morcos via bitcoin-dev&quot;=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<blockquote c=
lass=3D"m_1194300450306845563quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>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.</div></div></blockquote></div></div><div dir=3D"auto"><br></div></spa=
n><div dir=3D"auto">I just want to point out what appears to be doublespeak=
 going on here.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">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 &quot;=
rules I want to use instead of just peacefully splitting&quot; 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</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">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</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">At the time I told, rather force=
fully, by multiple people that miners have an &quot;absolute right&quot; to=
 softfork in whatever rules they want. Which, of course, is absurd on it&#3=
9;s face.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But I don&#39;=
t see how people can make such claims on the one hand, and then complain wh=
en this process is used against them.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">It amounts to nothing more than &quot;When it&#39;s rules I l=
ike we get to impose them on non-consenting users. When it&#39;s rules I do=
n&#39;t like it&#39;s an attack on the network&quot;.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It was completely obvious this entire=
 time that softforks were a very slippery slope, now we are indeed sliding =
down that slope.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
br></div><div class=3D"gmail_extra" dir=3D"auto"></div></div>
</blockquote></div><br></div>

--001a113ddd2e309a44054ba083d1--