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
|
Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DC2FC305
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 09:18:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEE08110
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 09:18:40 +0000 (UTC)
Received: by mail-wm0-f41.google.com with SMTP id v203so2946985wmg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Mar 2017 01:18:40 -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=hJG00I5AzU2aOmpmFybiAqsbY46keZAobLvxkGvjKSI=;
b=KSblbu7IGqqPzm7VGtL05JndawIC72eJLOLsH1uE9F1wd8MxPrx6o4eF0lrBrKs3vT
ktwuSorWCZVtb9aFVeQPG0aaUuFIH2UTK7h2LoCvAtG/y9LUPdZHwilyuWjXdmudCkZ1
ujPfiThD07sJfyFh0zZfkZAebkZfmVWtJybyOoe6VriGKJw0eQAyGmCnwGutwXMvuyrK
WSCmYrh1gabgPcZ9b6xuYKnJQawfIrW/Ru0J/y1pYylSOys58+uwF303OoNWFfwruUiy
zlJ0L4KH0Z35vGJRqAVuR5hS9HJNdmYDQQh7ES/uz4sRpYNYv8oVRkSolLbCJ7io5sF0
+9Hw==
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=hJG00I5AzU2aOmpmFybiAqsbY46keZAobLvxkGvjKSI=;
b=T8SAj5z1IgLdD8pejvEH0tIpSlnkApFC8Qtl9Euod2IqQBJsicmItD9ibF1wyBEBUa
m79YSpNJNllBuUo91px3nwqW+7E43B2Zd3n8++iI0a26DyewVHFwRXh5R3hXBKtW6vlZ
m7eCS8mzBICLgG4kP2h9fRM40kmY9aM2dEQpclsKEAWUvn+uWSrfqAArExLRkoq8c8ny
S2vArAlrjmC17GKQLpJNhuW9F8qwT0LxFi2npmvz8tz0u+PCtOzkEMA5BHfqXOLRpm7y
nVVQghrXf44NncAFcD4uTABSg8rQUXI9Ql2h7vO5MGQyuUm2huvAL/bKZStU6E6NF5FG
vmtQ==
X-Gm-Message-State: AMke39np8mQi6tiigDaFpqKLj3LN21u4h9qsQw2WUkwjPmKe3dgeNbn3t78a8Ze2V3XB9GfFYIxDNbBxcgps+g==
X-Received: by 10.28.13.80 with SMTP id 77mr11508341wmn.88.1488791919241; Mon,
06 Mar 2017 01:18:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.92.193 with HTTP; Mon, 6 Mar 2017 01:18:38 -0800 (PST)
Received: by 10.28.92.193 with HTTP; Mon, 6 Mar 2017 01:18:38 -0800 (PST)
In-Reply-To: <CANN4kmcLTcqHL53tEFk=g9o0_PsGzwArm9wgd0__ZXZpvhrs1g@mail.gmail.com>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
<CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
<CANN4kmcLTcqHL53tEFk=g9o0_PsGzwArm9wgd0__ZXZpvhrs1g@mail.gmail.com>
From: David Vorick <david.vorick@gmail.com>
Date: Mon, 6 Mar 2017 04:18:38 -0500
Message-ID: <CAFVRnyr4QoU5Rn2ryQ-jG8sZ18J7NKcpd3Cg+uN1sfiA=FiB+Q@mail.gmail.com>
To: Nick ODell <nickodell@gmail.com>
Content-Type: multipart/alternative; boundary=001a114245067db004054a0c61a7
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Mon, 06 Mar 2017 09:18:42 -0000
--001a114245067db004054a0c61a7
Content-Type: text/plain; charset=UTF-8
On Mar 5, 2017 6:48 PM, "Eric Voskuil" <eric@voskuil.org> wrote:
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 down with 75% of the economy and/or 90% of the hash power (which of
course has been done) and negotiate a change to any rule, Bitcoin is a
purely political money.
If "we" can do this, so can "they".
e
There is no doubt that politics play a big role in all of this. Also no
doubt that broader decentralization would be superior. But miner activated
soft forks and user activated soft forks do not need discussions with
centralized parties to move forward. It is merely two different methods for
pushing a soft fork through the network.
The key is that it's a soft fork. Old nodes continue to work as always,
whether the soft fork deploys or not.
User activated soft forks, or perhaps more accurately called 'economically
forced soft forks' are a tool to use if the miners are in clear opposition
to the broader economy. They only work if the broader economy actually
fully supports the soft fork, which is much more difficult to measure than
miner support. And miners with deeper pockets may be able to resist for
some time, effectively performing a rewardless 51% attack and maintaining a
split network for some time. The miners would lose lots of money, but old
nodes would feel all the burn of a hard fork, followed by a sudden deep
reorg when the network finally 'heals'.
I guess in some sense you'd be playing chicken with the miners. If the
split is not instantly successful there would be a lot of damage to old
nodes, even if the majority of new nodes had upgraded. (but there would
also be a lot of damage to the miners).
On Mar 5, 2017 9:31 PM, "Nick ODell" <nickodell@gmail.com> wrote:
>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).
I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.
This is not relevant to a UASF. The existing nodes on the network have a
single formal definition for longest chain. If the UASF is successful, the
old nodes will follow the new soft fork and there will be only one chain.
Spirit of Bitcoin or not, the UASF is successful and there is no coin split
or network fork.
--001a114245067db004054a0c61a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br style=3D"font-family:sans-serif"><div style=
=3D"font-family:sans-serif" class=3D"elided-text" dir=3D"auto">On Mar 5, 20=
17 6:48 PM, "Eric Voskuil" <<a href=3D"mailto:eric@voskuil.org=
">eric@voskuil.org</a>> wrote:<blockquote style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"au=
to"><div><br></div><div>Independent of one's opinion on the merits of o=
ne fork or another, the state of centralization in Bitcoin is an area of gr=
eat 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 chang=
e to any rule, Bitcoin is a purely political money.</div><div><br></div><di=
v>If "we" can do this, so can "they".</div><font color=
=3D"#888888"></font><div><br></div><div>e</div></div></blockquote></div></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">There is no doubt that pol=
itics play a big role in all of this. Also no doubt that broader decentrali=
zation would be superior. But miner activated soft forks and user activated=
soft forks do not need discussions with centralized parties to move forwar=
d. It is merely two different methods for pushing a soft fork through the n=
etwork.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The key is that =
it's a soft fork. Old nodes continue to work as always, whether the sof=
t fork deploys or not.</div><div dir=3D"auto"><br></div><div dir=3D"auto">U=
ser activated soft forks, or perhaps more accurately called 'economical=
ly forced soft forks' are a tool to use if the miners are in clear oppo=
sition to the broader economy. They only work if the broader economy actual=
ly fully supports the soft fork, which is much more difficult to measure th=
an miner support. And miners with deeper pockets may be able to resist for =
some time, effectively performing a rewardless 51% attack and maintaining a=
split network for some time. The miners would lose lots of money, but old =
nodes would feel all the burn of a hard fork, followed by a sudden deep reo=
rg when the network finally 'heals'.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">I guess in some sense you'd be playing chicken wit=
h the miners. If the split is not instantly successful there would be a lot=
of damage to old nodes, even if the majority of new nodes had upgraded. (b=
ut there would also be a lot of damage to the miners).</div><div dir=3D"aut=
o"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mar 5, 2017=
9:31 PM, "Nick ODell" <<a href=3D"mailto:nickodell@gmail.com"=
target=3D"_blank">nickodell@gmail.com</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"m_-6462332441477987812quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"m_-6462332441477987812quoted-text"><div>>I also think that the UAS=
F is a good idea. Hashrate follows coin price. If the UASF has the higher c=
oin price, the other chain will be annihilated. If the UASF has a lower coi=
n price, the user activated chain can still exist (though their coins can b=
e trivially stolen on the majority chain).</div><div><br></div></div><div>I=
don't think that's true. Say there are two forks of Blahcoin. Alic=
e thinks there's a 55% chance that Fork A will succeed. Bob thinks ther=
e's a 55% chance that Fork B will succeed. Alice trades all of her Fork=
B coins for all of Bob's Fork A coins. Now, Bob and Alice both have a =
stake in one fork or the other succeeding. Alice starts spending more time =
around Fork A users; Bob starts spending his time with Fork B users.</div><=
/div></blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">This is not relevant to a UASF. The existing nodes on the network ha=
ve a single formal definition for longest chain. If the UASF is successful,=
the old nodes will follow the new soft fork and there will be only one cha=
in. Spirit of Bitcoin or not, the UASF is successful and there is no coin s=
plit or network fork.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"></div></div>
--001a114245067db004054a0c61a7--
|
