summaryrefslogtreecommitdiff
path: root/54/3f708d89bb7d191ef977063140bf5f0a22da3c
blob: 814dcaf2607dd921ee4a768bbad56a1d78c7a371 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
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--