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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1XzUMh-0007zs-6P
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 17:50:55 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.50 as permitted sender)
client-ip=74.125.82.50; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wg0-f50.google.com;
Received: from mail-wg0-f50.google.com ([74.125.82.50])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XzUMg-0003GZ-6q
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Dec 2014 17:50:55 +0000
Received: by mail-wg0-f50.google.com with SMTP id a1so9808446wgh.9
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Dec 2014 09:50:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.6.7 with SMTP id w7mr28704797wjw.25.1418406648168; Fri,
12 Dec 2014 09:50:48 -0800 (PST)
Received: by 10.27.203.198 with HTTP; Fri, 12 Dec 2014 09:50:48 -0800 (PST)
In-Reply-To: <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com>
<CAE28kUR-PLzMGC23ETesc2Bz1_F1JfgcqyMW4qFvV5Vjk+ubbg@mail.gmail.com>
<CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
Date: Fri, 12 Dec 2014 19:50:48 +0200
Message-ID: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b5d4188694520050a0888ed
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(alex.mizrahi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XzUMg-0003GZ-6q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Setting the record straight on
Proof-of-Publication
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 12 Dec 2014 17:50:55 -0000
--047d7b5d4188694520050a0888ed
Content-Type: text/plain; charset=UTF-8
> I think what Gareth was getting at was that with client-side validation
> there can be no concept of a soft-fork. And how certain are you that the
> consensus rules will never change?
>
Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
Using scheduled updates: client simply stops working at a certain block,
and user is required to download an update.
In Bitcoin we can operate with some assurance that hard-forks will almost
> never happen, exactly because extensions are more likely to occur via
> soft-fork mechanisms. In such a case, old non-updated clients will still
> generate a correct view of the ledger state. But this is not so with client
> side validation!
>
You assume that an ability to operate with zero maintenance is very
important, but is this a case?
There was a plenty of critical bugs in bitcoind, and in many cases people
were strongly encouraged to upgrade to a new version.
So, you urge people to keep their clients up-to-date, but at the same time
claim that keeping very old versions is critically important.
How does this make sense? Is this an exercise at double-think?
An alternative to this is to make updates mandatory. You will no longer
need to maintain compatibility with version 0.1 (which is impossible) and
you can also evolve consensus rules over time.
It looks like people make a cargo cult out of Bitcoin's emergent
properties.
--047d7b5d4188694520050a0888ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think what Gareth was get=
ting at was that with client-side validation there can be no concept of a s=
oft-fork. And how certain are you that the consensus rules will never chang=
e?</div></blockquote><div><br></div><div>Yes, it is true that you can't=
do a soft-fork, but you can do a hard-fork.</div><div>Using scheduled upda=
tes: client simply stops working at a certain block, and user is required t=
o download an update.</div><div><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">In Bitcoin we can operate with some assurance that hard-fork=
s will almost never happen, exactly because extensions are more likely to o=
ccur via soft-fork mechanisms. In such a case, old non-updated clients will=
still generate a correct view of the ledger state. But this is not so with=
client side validation!</div></blockquote><div><br></div><div>You assume t=
hat an ability to operate with zero maintenance is very important, but is t=
his a case?</div><div><br></div><div>There was a plenty of critical bugs in=
bitcoind, and in many cases people were strongly encouraged to upgrade to =
a new version.</div><div>So, you urge people to keep their clients up-to-da=
te, but at the same time claim that keeping very old versions is critically=
important.</div><div>How does this make sense? Is this an exercise at doub=
le-think?</div><div><br></div><div>An alternative to this is to make update=
s mandatory. You will no longer need to maintain compatibility with version=
0.1 (which is impossible) and you can also evolve consensus rules over tim=
e.</div><div><br></div><div>It looks like people make a cargo cult out of B=
itcoin's emergent properties.=C2=A0</div></div></div></div>
--047d7b5d4188694520050a0888ed--
|
