path: root/54/3f708d89bb7d191ef977063140bf5f0a22da3c

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EAA46C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 18:48:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com
	[209.85.192.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AAAC818E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 18:48:36 +0000 (UTC)
Received: by mail-pf0-f170.google.com with SMTP id o126so3934722pfb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 05 Mar 2017 10:48:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=JiQLh3DkO3e8Pg4Ns+UdNCOLxKDCtyoIN0ZZJI6K1z4=;
	b=x9M1bn3pqE+nU8BVcISbN0M5GXdI73XF7I+YtuE2A/ffTJlWRJ4J4c4ztZ8UrLRqXh
	b3c8i4ABn3mqh9kLsnJ0WcOl8QwkjkUEIf+cZDIKcRIsLA7jGzmab/7Etumkpf6WXtL+
	AKwGMgORrYwQsGnmqSBPQBFiRiSf11WmxbKMBTqoWiMPHD4IgKPvvyoLGKNV1gs3w27b
	+jez66ijkmo2mf2ZFVnPMxYrxyxmTqlfRVfukdA1WP+w030pa/7fr5heu6Lp0eJtYqVe
	t1uG7hw1pMokpuiG1jC2y6Jei+cYfe/2yt2doC34MDx1IeFqtbtaqn0uMBwqW2hPccVX
	6Jzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=JiQLh3DkO3e8Pg4Ns+UdNCOLxKDCtyoIN0ZZJI6K1z4=;
	b=nb++yb9C2NaH3bzH75rkRGDSIK8x/MsStXAkkgpEgSlUKJ2nuZyImmMlXCY36JYsMH
	dsOX7QQjClxMedb4Qr9TaErpVV13gVOpUwmduK3xVxV7i/KJCuX9znlR833ptXcp/EsH
	+4u9P8mytQAY8zqtiLpd972wBwreuPkSPvMD7XvPA4IPIQl85w0B1+GVX2jx4hDL1HS9
	obf0OmwL8YRXcxLU5PJCiSDLmNsEGNvmuq8Fm5iFmrEYAhi31zewYuqJtAuxwmLvXias
	D6PPgcCI27A5vQTcORF9P6h3xE9MZG8pEfWeQ/6N+8irjwjF1sabCijwyTcJhcfqyT1D
	J3WA==
X-Gm-Message-State: AMke39lM7WgV9vQUBDEtqK9rgQlqK+GXf8ZX7Znx6vkI/83FG8dPV1JsJNj1dFDnNRCO6Q==
X-Received: by 10.99.7.206 with SMTP id 197mr8008322pgh.95.1488739716058;
	Sun, 05 Mar 2017 10:48:36 -0800 (PST)
Received: from [10.86.254.225] (mobile-166-176-185-182.mycingular.net.
	[166.176.185.182]) by smtp.gmail.com with ESMTPSA id
	185sm34814736pfg.13.2017.03.05.10.48.35
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 05 Mar 2017 10:48:35 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
Date: Sun, 5 Mar 2017 10:48:33 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <CF179411-8790-4CD9-A785-D7DA7C9AB865@voskuil.org>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
	<CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_LOW autolearn=ham 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: Sun, 05 Mar 2017 18:48:37 -0000


--Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

There are two aspects of system security in Bitcoin, mining (hash power) and=
 payment validation (economy). The security of each is a function of its lev=
el of decentralization. Another way to think of it is that a system with les=
s decentralization has a smaller community (consensus). A large consensus is=
 more secure in that it is more resistant to change (forks) than a system wi=
th a small consensus.

The fact that mining is highly centralized makes it relatively easy to enfor=
ce a fork via miner collaboration, and hard to do so without it.

So clearly the other option, as being discussed here, is to enforce a fork v=
ia the economy. Given the highly centralized nature of the economy, describe=
d below as "economic hubs", it is also relatively easy as well.

Independent of one's opinion on the merits of one fork or another, the state=
 of centralization in Bitcoin is an area of great concern. If "we" can sit d=
own with 75% of the economy and/or 90% of the hash power (which of course ha=
s been done) and negotiate a change to any rule, Bitcoin is a purely politic=
al money.

If "we" can do this, so can "they".

e

> On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>=20
> I also think that the UASF is a good idea. Hashrate follows coin price. If=
 the UASF has the higher coin price, the other chain will be annihilated. If=
 the UASF has a lower coin price, the user activated chain can still exist (=
though their coins can be trivially stolen on the majority chain).
>=20
> The success of the UASF depends entirely on the price. And actually, the p=
rice is easy to manipulate. If you, as an economically active full node, ref=
use to acknowledge the old chain and demand that incoming coins arrive over t=
he UASF chain. In doing so, you drive down the utility of the old chain and d=
rive up the utility of the new chain. This ultimately impacts the price.
>=20
> I think it would be pretty easy to get high confidence of the success of a=
 UASF. Basically you need all the major economic hubs to agree to upgrade an=
d then exclusively accept UASF coins. I don't have a comprehensive list, but=
 if we could sign on 75% of the major exchanges and payment processors, and g=
et 75% of the wallets to upgrade, then the UASF would be very likely to succ=
essfully obliterate the old rules, as miners would be unable to sell their c=
oins or pay their bills by stubbornly sticking to the old chain. It's less r=
isky than a hard fork by far, because there is zero risk of coin split if th=
e UASF has majority hashrate, which will follow majority economic value.
>=20
> A serious proposal I think would get all the code ready and merged, but wi=
thout setting a flag day. Then we would get signatures from the major instit=
utions promising to use the software and saying that they are ready for a fl=
ag day. After that, you release a patch with a flag day 12 months in the fut=
ure. People can upgrade immediately, and have a full year to transition.
>=20
> That gives tons of time for people to upgrade, and tons of confidence that=
 the UASF will end up as the majority chain.
>=20
> If we cannot get enough major exchanges, payment processors, and other eco=
nomic hubs to upgrade,  the flag day should remain upset, as the risk of coi=
n split will be non-zero.
>=20
> I would suggest that a carefully executed UASF is much riskier than a soft=
 fork, but far, far less risky than a hard fork.
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>There are two aspects of sy=
stem security in Bitcoin, mining (hash power) and payment validation (econom=
y). The security of each is a function of its level of decentralization. Ano=
ther way to think of it is that a system with less decentralization has a sm=
aller community (consensus). A large consensus is more secure in that it is m=
ore resistant to change (forks) than a system with a small consensus.</div><=
div><br></div><div>The fact that mining is highly centralized makes it relat=
ively easy to enforce a fork via miner collaboration, and hard to do so with=
out it.</div><div><br></div><div>So clearly the other option, as being discu=
ssed here, is to enforce a fork via the economy. Given the highly centralize=
d nature of the economy, described below as "economic hubs", it is also rela=
tively easy as well.</div><div><br></div><div>Independent of one's opinion o=
n the merits of one fork or another, the state of centralization in Bitcoin i=
s an area of great concern. If "we" can sit down with 75% of the economy and=
/or 90% of the hash power (which of course has been done) and negotiate a ch=
ange to any rule, Bitcoin is a purely political money.</div><div><br></div><=
div>If "we" can do this, so can "they".</div><div><br></div><div>e</div><div=
><br>On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=
=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div style=3D"font-family:=
sans-serif;font-size:13.696px" dir=3D"auto">I also think that the UASF is a g=
ood idea. Hashrate follows coin price. If the UASF has the higher coin price=
, the other chain will be annihilated. If the UASF has a lower coin price, t=
he user activated chain can still exist (though their coins can be trivially=
 stolen on the majority chain).</div><div style=3D"font-family:sans-serif;fo=
nt-size:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-seri=
f;font-size:13.696px" dir=3D"auto">The success of the UASF depends entirely o=
n the price. And actually, the price is easy to manipulate. If you, as an ec=
onomically active full node, refuse to acknowledge the old chain and demand t=
hat incoming coins arrive over the UASF chain. In doing so, you drive down t=
he utility of the old chain and drive up the utility of the new chain. This u=
ltimately impacts the price.</div><div style=3D"font-family:sans-serif;font-=
size:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;f=
ont-size:13.696px" dir=3D"auto">I think it would be pretty easy to get high c=
onfidence of the success of a UASF. Basically you need all the major economi=
c hubs to agree to upgrade and then exclusively accept UASF coins. I don't h=
ave a comprehensive list, but if we could sign on 75% of the major exchanges=
 and payment processors, and get 75% of the wallets to upgrade, then the UAS=
F would be very likely to successfully obliterate the old rules, as miners w=
ould be unable to sell their coins or pay their bills by stubbornly sticking=
 to the old chain. It's less risky than a hard fork by far, because there is=
 zero risk of coin split if the UASF has majority hashrate, which will follo=
w majority economic value.</div><div style=3D"font-family:sans-serif;font-si=
ze:13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;fon=
t-size:13.696px" dir=3D"auto">A serious proposal I think would get all the c=
ode ready and merged, but without setting a flag day. Then we would get sign=
atures from the major institutions promising to use the software and saying t=
hat they are ready for a flag day. After that, you release a patch with a fl=
ag day 12 months in the future. People can upgrade immediately, and have a f=
ull year to transition.</div><div style=3D"font-family:sans-serif;font-size:=
13.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font-s=
ize:13.696px" dir=3D"auto">That gives tons of time for people to upgrade, an=
d tons of confidence that the UASF will end up as the majority chain.</div><=
div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto"><br></d=
iv><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto">If w=
e cannot get enough major exchanges, payment processors, and other economic h=
ubs to upgrade, &nbsp;the flag day should remain upset, as the risk of coin s=
plit will be non-zero.</div><div style=3D"font-family:sans-serif;font-size:1=
3.696px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font-si=
ze:13.696px" dir=3D"auto">I would suggest that a carefully executed UASF is m=
uch riskier than a soft fork, but far, far less risky than a hard fork.</div=
><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto"><br><=
/div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto"><=
br></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-75F0AD18-DBB3-4B00-95E2-62A5E0D8C222--