path: root/1d/e4e8ba999626f91d95f5e7cf3b694ce63c3754

Return-Path: <alp.bitcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C9423902
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  7 Mar 2017 19:13:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com
	[209.85.192.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1F31184
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  7 Mar 2017 19:13:30 +0000 (UTC)
Received: by mail-pf0-f181.google.com with SMTP id v190so4150497pfb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 07 Mar 2017 11:13:30 -0800 (PST)
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=Lbu9W88SQyNCge8Ke7GUDF0/sp+k3gEFRz0s/e1Taec=;
	b=rvyJKZd6l483Y25tktvZpQ0HWAzt5mfXQi5iDpry5XQYtdaXsxwgjl3huSgreSj8rZ
	/kC+c6M5EMR6T8r38MQYw3dHGpgVQrBm4B9P4h67pGK7dGYa5yf7ascS0DXYaymcVzdz
	7Q5KRHN98gMu++Xr07Sx4GLGYkmuH43BTja/KcLoxeVBM8hhYYo+zS5EuL7Ga4+NlNZR
	pjaWEKbSX0EZhqrDHUGHg4UdajanO/cew7GU9wUtngPTD8K7WZd4IRrE/7Ao4O5jYTEe
	1S57EAr+qQeVFxGRcnxSVN4U3ZwXu8maID7T92wie25seU53K8g4Kv+9HStMWpNNBLB+
	RUrg==
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=Lbu9W88SQyNCge8Ke7GUDF0/sp+k3gEFRz0s/e1Taec=;
	b=PEbOYcMAvAJsTnR7u+by2iis1GLakBIZAeSc1J6/nDxSPfH/UhgbbdAnDBJV4JHBb3
	ncmCx/hbT11Y1M03uVeEzD4PIa7XPB+81lpZDdSxNNOL66Uwsm3AAV3XsZ+XhWu0JN7F
	TJ8sHn+LwpD2y5DEgTbZDsUkFKGvoI6Or3AyVT/XHEPXMShZ2vRDYOjwh3l6ojDa2pww
	khYouSgqurhlRt258LBE93BLGxkRkCQTnt2UhNgyXx20fJw/qX9z0CBsFFHpUV84AAVz
	4SDr/7XxglZkv1uthIDEFxwOPd0VARsq2eKsGbe0Q5zD+xV9n4FhsX+NVJ7dP3EgaR3j
	n4rw==
X-Gm-Message-State: AMke39lQGmUfxLBIKgQfOLrv4B7N3zi7/BkyXhCqdg467WblL8NiV6GaevI1u8evLPo0df6o5G4E9lvNXo7M7Q==
X-Received: by 10.98.200.136 with SMTP id i8mr2168580pfk.120.1488914010505;
	Tue, 07 Mar 2017 11:13:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.182.161 with HTTP; Tue, 7 Mar 2017 11:13:29 -0800 (PST)
In-Reply-To: <9086552.5NYgjOP6f4@strawberry>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
	<CA+su7OV0Cpe=4AKdNhJXOCbYVriEN1vHSoA_0r31GXCAP1=NCA@mail.gmail.com>
	<964E4801-234F-4E30-A040-2C63274D27F2@posteo.net>
	<9086552.5NYgjOP6f4@strawberry>
From: Alphonse Pace <alp.bitcoin@gmail.com>
Date: Tue, 7 Mar 2017 13:13:29 -0600
Message-ID: <CAMBsKS-rqkTtx3tzF5RKwMUVtGqBMoqj+sZ8jjo6bKrVHiDufA@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1445aab288aa054a28ce20
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
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
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: Tue, 07 Mar 2017 19:13:31 -0000

--94eb2c1445aab288aa054a28ce20
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I fail to see how any non-mining user can attack a miner.  The worst they
can do is refuse to buy their coinbase transaction.  Do you believe that
users are obligated to buy coins from miners?  If not, then all miners are
voluntarily choosing a set of rules to enforce and a set of policy to mine.

>Don=E2=80=99t be mistaken; a hash-minority attacking the hash-majority is =
in actual
fact an attack upon Bitcoin as a whole.

Can you outline how a minority of hash rate can attack a majority? Users
are free to follow tighter rules than before, or they may reject it.  The
majority of hash rate can continue the old rules or not.  Where is the
attack?  I see a disagreement being resolved peacefully through unilateral
separation.

>If this were possible then next year we=E2=80=99d see governments try to p=
ush
through changes in the same UASF way. I=E2=80=99m very happy that UASFs can=
=E2=80=99t work
because that would be the end of Bitcoin's freedom and decentralized nature=
.

Governments would be much more equipped to simply go directly to the miners
to enforce this for them - why even bother with millions of distributed
miners when you can knock on a few doors and get your policy?

>If the majority of the users are hostile and reject blocks that the miners
create, or change the POW, then what the miners bring to the table is also
removed.

I don't understand how users can be hostile to Bitcoin.  Users are
Bitcoin.  Everyone else serves the users.  All participants are voluntary
and can choose to participate or not.  Where is the attack or hostility?

-Alphonse

On Tue, Mar 7, 2017 at 3:17 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev
> wrote:
> > What you're describing is a hashpower activated soft fork to censor
> > transactions, in response to a user activated soft fork that the majori=
ty
> > of hashpower disagrees with.
>
> It is incorrect to say that censoring of transactions is what Edmund
> suggested. It's purely about the form they take, you can re-send the
> transaction in a different form with the same content and they go through=
.
> Hence, not transaction censoring.
>
> I do believe the point that Edmund brought up is a very good one, the ide=
a
> that a set of users can force the miners to do something is rather silly
> and
> the setup that a minority miner fraction can force the majority to do
> something is equally silly. This is because the majority mining hashpower
> can fight back against this attack upon them.
>
> Don=E2=80=99t be mistaken; a hash-minority attacking the hash-majority is=
 in actual
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we=E2=80=99d see governments try to =
push
> through changes in the same UASF way. I=E2=80=99m very happy that UASFs c=
an=E2=80=99t work
> because that would be the end of Bitcoin's freedom and decentralized
> nature.
>
> > It is always possible for a majority of hashpower to censor transaction=
s
> > they disagree with. Users may view that as an attack, and can always
> > respond with a POW hard fork.
>
> I definitely welcome that approach.
>
> The result would be that you have two chains, but also you ensure that th=
e
> chain that the miners didn=E2=80=99t like will no longer be something the=
y can
> mine.
> Not even the minority set of miners that like the softfork can mine on it=
.
> This is a win-win and then the market will decide which one will "win".
>
> > Bitcoin only works if the majority of hashpower is not hostile to the
> > users.
>
> This goes both ways, miners both generate value (in the form of security)
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miner=
s
> create, or change the POW, then what the miners bring to the table is als=
o
> removed.
> Bitcoin would lose the security and in the short term even the ability to
> mine blocks every 10 minutes.
>
> So, lets correct your statement a little;
> =C2=ABBitcoin only works when the majority of the hashpower and the (econ=
omic)
>   majority of the users are balanced in power and have their goals
> aligned.=C2=BB
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c1445aab288aa054a28ce20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I fail to see how any non-mining user can attack a miner.=
=C2=A0 The worst they can do is refuse to buy their coinbase transaction.=
=C2=A0 Do you believe that users are obligated to buy coins from miners?=C2=
=A0 If not, then all miners are voluntarily choosing a set of rules to enfo=
rce and a set of policy to mine.<div><br><div>&gt;<span style=3D"font-size:=
12.8px">Don=E2=80=99t be mistaken; a hash-minority attacking the hash-major=
ity is in actual</span></div><span style=3D"font-size:12.8px">fact an attac=
k upon Bitcoin as a whole.</span></div><div><span style=3D"font-size:12.8px=
"><br></span></div><div><span style=3D"font-size:12.8px">Can you outline ho=
w a minority of hash rate can attack a majority? Users are free to follow t=
ighter rules than before, or they may reject it.=C2=A0 The majority of hash=
 rate can continue the old rules or not.=C2=A0 Where is the attack?=C2=A0 I=
 see a disagreement being resolved peacefully through unilateral separation=
.</span></div><div><span style=3D"font-size:12.8px"><br></span><div>&gt;I<s=
pan style=3D"font-size:12.8px">f this were possible then next year we=E2=80=
=99d see governments try to push</span></div><span style=3D"font-size:12.8p=
x">through changes in the same UASF way. I=E2=80=99m very happy that UASFs =
can=E2=80=99t work</span><br style=3D"font-size:12.8px"><span style=3D"font=
-size:12.8px">because that would be the end of Bitcoin&#39;s freedom and de=
centralized nature.</span><br style=3D"font-size:12.8px"></div><div><span s=
tyle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12=
.8px">Governments would be much more equipped to simply go directly to the =
miners to enforce this for them - why even bother with millions of distribu=
ted miners when you can knock on a few doors and get your policy? =C2=A0</s=
pan></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span=
 style=3D"font-size:12.8px">&gt;I</span><span style=3D"font-size:12.8px">f =
the majority of the users are hostile and reject blocks that the miners</sp=
an></div><span style=3D"font-size:12.8px">create, or change the POW, then w=
hat the miners bring to the table is also</span><br style=3D"font-size:12.8=
px"><span style=3D"font-size:12.8px">removed.</span><div><span style=3D"fon=
t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">I don=
&#39;t understand how users can be hostile to Bitcoin.=C2=A0 Users are Bitc=
oin.=C2=A0 Everyone else serves the users.=C2=A0 All participants are volun=
tary and can choose to participate or not.=C2=A0 Where is the attack or hos=
tility?</span></div><div><span style=3D"font-size:12.8px"><br></span></div>=
<div><span style=3D"font-size:12.8px">-Alphonse</span></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Mar 7, 2017 at 3:1=
7 AM, Tom Zander via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</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"><=
span class=3D"">On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via b=
itcoin-dev wrote:<br>
&gt; What you&#39;re describing is a hashpower activated soft fork to censo=
r<br>
&gt; transactions, in response to a user activated soft fork that the major=
ity<br>
&gt; of hashpower disagrees with.<br>
<br>
</span>It is incorrect to say that censoring of transactions is what Edmund=
<br>
suggested. It&#39;s purely about the form they take, you can re-send the<br=
>
transaction in a different form with the same content and they go through.<=
br>
Hence, not transaction censoring.<br>
<br>
I do believe the point that Edmund brought up is a very good one, the idea<=
br>
that a set of users can force the miners to do something is rather silly an=
d<br>
the setup that a minority miner fraction can force the majority to do<br>
something is equally silly. This is because the majority mining hashpower<b=
r>
can fight back against this attack upon them.<br>
<br>
Don=E2=80=99t be mistaken; a hash-minority attacking the hash-majority is i=
n actual<br>
fact an attack upon Bitcoin as a whole.<br>
If this were possible then next year we=E2=80=99d see governments try to pu=
sh<br>
through changes in the same UASF way. I=E2=80=99m very happy that UASFs can=
=E2=80=99t work<br>
because that would be the end of Bitcoin&#39;s freedom and decentralized na=
ture.<br>
<span class=3D""><br>
&gt; It is always possible for a majority of hashpower to censor transactio=
ns<br>
&gt; they disagree with. Users may view that as an attack, and can always<b=
r>
&gt; respond with a POW hard fork.<br>
<br>
</span>I definitely welcome that approach.<br>
<br>
The result would be that you have two chains, but also you ensure that the<=
br>
chain that the miners didn=E2=80=99t like will no longer be something they =
can mine.<br>
Not even the minority set of miners that like the softfork can mine on it.<=
br>
This is a win-win and then the market will decide which one will &quot;win&=
quot;.<br>
<span class=3D""><br>
&gt; Bitcoin only works if the majority of hashpower is not hostile to the<=
br>
&gt; users.<br>
<br>
</span>This goes both ways, miners both generate value (in the form of secu=
rity)<br>
and they take value (in the form of inflation).<br>
If the majority of the users are hostile and reject blocks that the miners<=
br>
create, or change the POW, then what the miners bring to the table is also<=
br>
removed.<br>
Bitcoin would lose the security and in the short term even the ability to<b=
r>
mine blocks every 10 minutes.<br>
<br>
So, lets correct your statement a little;<br>
=C2=ABBitcoin only works when the majority of the hashpower and the (econom=
ic)<br>
=C2=A0 majority of the users are balanced in power and have their goals ali=
gned.=C2=BB<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
_________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c1445aab288aa054a28ce20--