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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BE7DD1550
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 20:54:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22ABF1DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 20:54:40 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so132120626wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 13:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:content-type;
bh=ujn7b5Q0EPlAxU1WRBKdgJFrtNrFp8XQua0o6qlVZIs=;
b=zD+IKY6hb3pOo287vzjaiy0vuyjPtMAsuTASjq3mYFOpLb3TePBokFaFGjbWX2nujt
s176SpO2YdlOcByGRx3cUAScWehbNGXe7DrKj4hpUblE6ZjVF8agZRD3zR05wN0oXGs+
pmY8/4q93NyNkk+7yPW8WNZJDL4RT6avExZj6Q345yJLdMMaBM5e54s5JBufwmUyb7lN
LGKrDXXZpjKO43gegqZ5sjYZdSgxVFd6XXqkNHRLutqoRoinqVR1gdc5rD5sHJgX4NVO
6Ss0IRIkQR7Dzvf2csOzjwPdF1Uebhkn9pGLVbpgfuSgpMipEJSwhl2lyTqzwetUXob9
C7lw==
MIME-Version: 1.0
X-Received: by 10.194.76.67 with SMTP id i3mr36973646wjw.5.1444078478805; Mon,
05 Oct 2015 13:54:38 -0700 (PDT)
Sender: dscotese@gmail.com
Received: by 10.27.211.132 with HTTP; Mon, 5 Oct 2015 13:54:38 -0700 (PDT)
In-Reply-To: <2081461.sDX5ARzIdv@garp>
References: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
<1489086.kGfJeeyi4a@garp>
<CAAS2fgSyWaRfXHKWZYzZ4X8ksMECaO47dTXum67XwpTTYnbDXg@mail.gmail.com>
<2081461.sDX5ARzIdv@garp>
Date: Mon, 5 Oct 2015 13:54:38 -0700
X-Google-Sender-Auth: hekyjattYvSvxyK3rP5iYKHw4UQ
Message-ID: <CAGLBAhenb3D2FYZQFgGhyWT9JafwwVMzCow=tFbNfQdLJpdx0g@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7bdc87aac1d6b4052161b8d1
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_IMAGE_ONLY_24, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE 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] This thread is not about the soft/hard fork
technical debate
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 05 Oct 2015 20:54:40 -0000
--047d7bdc87aac1d6b4052161b8d1
Content-Type: text/plain; charset=UTF-8
I prefer the hard fork because the complexity introduced by soft forks
scares me.
At
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html
Gregory wrote: "Security requires a bit of vigilance, inherently." and
[A non-upgraded miner will end up] "*> producing invalid blocks forever
until** the owner shuts it down and upgrades. * This is the outcome
guaranteed for absentee miners with a hard fork, but it is not guaranteed
for a soft fork."
It seems that the main benefit of a soft-fork is that it allows
participants on the network to keep participating even if they aren't
vigilant enough to notice and upgrade when that is safest. Are there other
reasons that might entice me if that one by itself is not enough?
Gregory provided two more: [Using soft-forks] "radically lowers (in most of
our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization which
is harmful to decentralization promoting software diversity."
I understand these benefits. The cost in complexity is still too high for
me, and I think most of the pain in "cost of deployment", "industry-wide
flag days," and "tight release synchronization," as well as the
centralizing effect of those things can be minimized with waiting periods.
The promotion of software diversity offered by soft-forks is pretty cool,
but that gets close to messing with fungibility.
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html>
--047d7bdc87aac1d6b4052161b8d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I prefer the hard fork because the complexity introduced b=
y soft forks scares me.<br><div><br>At <a href=3D"http://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2015-September/011309.html" target=3D"_blank"=
>http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/0113=
09.html</a> Gregory wrote: "Security requires a bit of vigilance, inhe=
rently." and <br>[A non-upgraded miner will end up] "<i>> prod=
ucing invalid blocks forever until</i><i> the owner shuts it down and upgra=
des.
</i>
This is the outcome guaranteed for absentee miners with a hard fork,
but it is not guaranteed for a soft fork."<br><br>It seems that=20
the main benefit of a soft-fork is that it allows participants on the=20
network to keep participating even if they aren't vigilant enough to=20
notice and upgrade when that is safest.=C2=A0 Are there other reasons that=
=20
might entice me if that one by itself is not enough?<br><br></div><div>Greg=
ory provided two more: [Using soft-forks] "radically lowers (in most o=
f our experience and<br>
opinion) the cost of deployment; again-- making them different. They preven=
t a industry wide flag day, and tight release synchronization=C2=A0
which is harmful to decentralization promoting software diversity."<br=
><br></div><div>I understand these benefits.=C2=A0 The cost in complexity i=
s still too high for me, and I think most of the pain in "cost of depl=
oyment", "industry-wide flag days," and "tight release =
synchronization," as well as the centralizing effect of those things c=
an be minimized with waiting periods.=C2=A0 The promotion of software diver=
sity offered by soft-forks is pretty cool, but that gets close to messing w=
ith fungibility.=C2=A0 <br></div><div><div class=3D""><div id=3D":66b" clas=
s=3D"" tabindex=3D"0"><img class=3D"" src=3D"https://ssl.gstatic.com/ui/v1/=
icons/mail/images/cleardot.gif"></div></div><a href=3D"http://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2015-September/011309.html" target=3D"_b=
lank"></a></div></div>
--047d7bdc87aac1d6b4052161b8d1--
|
