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
|
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 745C5305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Mar 2017 18:10:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com
[209.85.128.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF149F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Mar 2017 18:10:17 +0000 (UTC)
Received: by mail-wr0-f176.google.com with SMTP id u108so102706103wrb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Mar 2017 10:10:17 -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=i4I2ma1TEo2EBHjrgqNx1pVkAsYBZ27RjzIwPp7GouA=;
b=Xsoy9C+PBO69IuzpLvbjfd3le1NAdy+A5PKpGFEdhJnXfLrXXwBzCRtTNmIOtN4UuS
KqpjyPm7dORTK2gM1LO8emUtYvLuqmD/sp2VHwV0N7Y8+zaD1L0PAKJ4qFey3AAXCOsA
sBZCIdXIczOP2S2e1Hy7BukTjmFk3TuOrb3CdeuXsek5b4J+HgdZMqjoueSVDduHAGL/
Km2toKLieny8ozecWE4P6xBlqodSPBZk+l6AkQJwQfbhGxt4ZM4XOBETUJbptwyYZtvH
AAHJvQ9whAHWmenS+hslZOp6dLsOzkaWwDhM17G2njMMMMycWsAoSM+nEgywCVInbxBs
NaJg==
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=i4I2ma1TEo2EBHjrgqNx1pVkAsYBZ27RjzIwPp7GouA=;
b=GuS8GRrEbDV+Lqlieta1FJEZNxHlhh6Vz5G3F5BsUniQUGy0CgHcIE8MuWUJ1kX8x8
qDFvmLgtQ79XpgnZ0+cfkr5KHfSrD199WDf/Qr6j5V+0TCickv8sqZs1VWS8FEmSncTU
Gks8iRcRSSJZ+X6wwXabNRWnG8F4R6TwV80geTkSxV/hi6d1yiML2tl+hIR41T8pYFea
7rO5gJFI3blnNYNarE46rmCaGhTM8oSTK8cFuld3OzeBMoUbN/9lH+w5Z4E0lEQgDjTp
u08gW+Lx/3IDnMW/6vfSmD2Bh1Um9Ui/iprKi8sXwu9yStqSb0uXyDap2pfzjC/34BcS
4rUQ==
X-Gm-Message-State: AMke39lTR2prIWQiO1WmnL4A8vRxsF2pNBUYfvuJbRT5M56ohmUUcivQ94AaMt3nECTQbZQACIO7gEunlA2cTA==
X-Received: by 10.223.136.183 with SMTP id f52mr10589748wrf.68.1488737416048;
Sun, 05 Mar 2017 10:10:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.92.193 with HTTP; Sun, 5 Mar 2017 10:10:15 -0800 (PST)
Received: by 10.28.92.193 with HTTP; Sun, 5 Mar 2017 10:10:15 -0800 (PST)
In-Reply-To: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
References: <0ba5bf9c-5578-98ce-07ae-036d0d71046b@riseup.net>
From: David Vorick <david.vorick@gmail.com>
Date: Sun, 5 Mar 2017 13:10:15 -0500
Message-ID: <CAFVRnyomgeXu2pRO=+B7bwB-bZdEL2DcpJNPMz=tAhht6eZXAQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Chris Belcher <belcher@riseup.net>
Content-Type: multipart/alternative; boundary=001a11492e06d8f9f60549ffb045
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
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:10:18 -0000
--001a11492e06d8f9f60549ffb045
Content-Type: text/plain; charset=UTF-8
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).
The success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.
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
and 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 get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would 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 follow majority
economic value.
A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.
That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.
If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade, the flag day should remain upset, as the risk of
coin split will be non-zero.
I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.
--001a11492e06d8f9f60549ffb045
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div style=3D"fon=
t-family:sans-serif;font-size:13.696px" dir=3D"auto">I also think that the =
UASF is a good idea. Hashrate follows coin price. If the UASF has the highe=
r 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 ca=
n be trivially stolen on the majority chain).</div><div style=3D"font-famil=
y: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">The success of the UASF =
depends entirely on the price. And actually, the price is easy to manipulat=
e. If you, as an economically active full node, refuse to acknowledge the o=
ld chain and demand that incoming coins arrive over the UASF chain. In doin=
g so, you drive down the utility of the old chain and drive up the utility =
of the new chain. This ultimately impacts the price.</div><div style=3D"fon=
t-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">I think it woul=
d 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 and then exclusiv=
ely accept UASF coins. I don't have a comprehensive list, but if we cou=
ld sign on 75% of the major exchanges and payment processors, and get 75% o=
f the wallets to upgrade, then the UASF would be very likely to successfull=
y obliterate the old rules, as miners would be unable to sell their coins o=
r pay their bills by stubbornly sticking to the old chain. It's less ri=
sky 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.</d=
iv><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"auto"><b=
r></div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"aut=
o">A serious proposal I think would get all the code ready and merged, but =
without setting a flag day. Then we would get signatures from the major ins=
titutions promising to use the software and saying that they are ready for =
a flag day. After that, you release a patch with a flag day 12 months in th=
e future. People can upgrade immediately, and have a full year to transitio=
n.</div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=3D"aut=
o"><br></div><div style=3D"font-family:sans-serif;font-size:13.696px" dir=
=3D"auto">That gives tons of time for people to upgrade, and tons of confid=
ence that the UASF will end up as the majority chain.</div><div style=3D"fo=
nt-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">If we cannot ge=
t enough major exchanges, payment processors, and other economic hubs to up=
grade, =C2=A0the flag day should remain upset, as the risk of coin split wi=
ll be non-zero.</div><div style=3D"font-family:sans-serif;font-size:13.696p=
x" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font-size:13=
.696px" dir=3D"auto">I would suggest that a carefully executed UASF is much=
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>
--001a11492e06d8f9f60549ffb045--
|
