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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QrODn-0007Di-Qt
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 05:54:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-wy0-f175.google.com;
Received: from mail-wy0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrODm-0000Dx-Rz
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 05:54:23 +0000
Received: by wyf19 with SMTP id 19so1821632wyf.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 22:54:16 -0700 (PDT)
Received: by 10.216.169.207 with SMTP id n57mr1442691wel.37.1313041659028;
Wed, 10 Aug 2011 22:47:39 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id et16sm1281327wbb.19.2011.08.10.22.47.36
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 10 Aug 2011 22:47:37 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Date: Thu, 11 Aug 2011 06:47:34 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102338.21680.andyparkins@gmail.com>
<CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com>
In-Reply-To: <CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108110647.35194.andyparkins@gmail.com>
X-Spam-Score: -1.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
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrODm-0000Dx-Rz
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
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: Thu, 11 Aug 2011 05:54:23 -0000
On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:
> > However... The version number field combined with the massive
> > complexity of:
> >
> > if( blockNumber > 500000 )
> > new_process();
> > else
> > old_process();
> >
> > Would sort all of your "compatibility" objections out, and would give
> > nodes time to upgrade.
>
> The above has been discussed on the forums. The community seems to
> consider that option one of last resort, because the consequences of
> -not- upgrading immediately become "I cannot access my money." The
Did you even read what I wrote? "if( blockNumber > 5000000 )" is about as
far from immediate as you can get. I'm not an idiot; I understand we can't
lock people out of their money simply because of a software upgrade. It's
not unreasonable to expect people will have upgraded by block 500000 though
(or whatever number the community decided upon).
Again you're missing my point... you are still shooting ideas down.
> community also seems rather hard-wired against breaking changes like
> that, because it implies that we lowly dev peons are daring to mess
> with the Blessed Satoshi Design that has received extensive study, and
> 100% communal agreement.
Well the community had better unhardwire itself or its going to end up with
five developers and no more.
> If the community changes its mind, and there are strong calls to make
> a breaking change, we can certainly do that. Bitcoin is not only open
> source but very much democratic -- people vote by choosing which
> client software to use.
Voting with ones feet should be a last resort. Wouldn't it be better not to
end up with incompatible clients out there?
> Historically speaking, the protocol has had minor tweaks, if you check
> the patch history. Adding new protocol commands is pretty easy, for
> example. Removing commands tends to be high cost for low benefit
> ("protocol removes a harmless redundancy"), if you're messing with the
> initial negotiation sequence. IMO verack is not redundant, anyway.
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am willing to lower to version 5 so I shall continue
or
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am unwilling to lower to version 5 so I shall hang up
or
Client: I speak version 5
Server: hmmm, I speak version 10, but I am willing to speak version 5
or
Client: I speak version 5
Server: hmmm, I speak version 10, and I am unwilling to speak version 5
so I shall hang up
'verack' is redundant. It sends no information and merely says that the
other end is willing to continue. Willing to continue is easily determined
when the remote continues. Handling 'verack' is an annoyance, and adds
nothing.
> But the answer is "what do the users want" not "no" At the end of the
> day we're here to adequately reflect the needs of our userbase at all.
> And so far, the userbase seems highly conservative when it comes to
> incompatible changes. Correct me if I'm wrong...
Please point me at a single incompatible change that has been rejected by
the userbase.
Further: I'm not suggesting incompatible changes alone; that would be
insane. I'm suggesting upgrade paths that delay incompatible changes until
the change has propagated.
> It's negative to weight costs vs. benefits? That is what I expect any
> good engineer to do.
I don't think that's what's happening. Not once have I seen the "benefits"
side of that equation. What I have seen is plenty of "I can't see a use
case for that"; when the key word in that sentence is "I".
> In any case, our -users- are not clamoring for breaking changes of the
> type you describe above, as far as I can see. Just the opposite. So
> if you want to deploy a breaking change, the burden is on you to
> convince the bitcoin users and miners that it's a good idea.
The users aren't typically going to be familiar enough with the internals of
bitcoin to care about many of the changes I suggested. I have repeatedly
said I don't want to break anything, I want to transition in an orderly
fashion (and the majority of my suggestions were backward compatible). But
of course, I don't actually want to do anything with bitcoind itself, it's
been made repeatedly clear to me that anything I might ask for is not going
to happen -- and of course what I was pointing out, _not_ asking for, was
that you can't expect to get new developers on board if they aren't going to
be allowed to scratch their itches.
> If the bitcoin dev team is not accurately reflecting the desire of its
> users, then that should be corrected, and we want to hear feedback.
You've just had some. The response was "you're wrong".
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
