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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QrVfH-0001JG-1y
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 13:51:15 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrVfF-0002sq-Vb
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 13:51:15 +0000
Received: by mail-wy0-f175.google.com with SMTP id 19so2152606wyf.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 06:51:13 -0700 (PDT)
Received: by 10.227.176.65 with SMTP id bd1mr7989744wbb.78.1313070673529;
Thu, 11 Aug 2011 06:51:13 -0700 (PDT)
Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178])
by mx.google.com with ESMTPS id et16sm1566316wbb.53.2011.08.11.06.51.10
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 11 Aug 2011 06:51:11 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Mike Hearn <mike@plan99.net>
Date: Thu, 11 Aug 2011 14:51:04 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102213.09632.andyparkins@gmail.com>
<CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com>
In-Reply-To: <CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1564652.Xm4cfOt2Zi";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201108111451.09296.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: 1QrVfF-0002sq-Vb
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 13:51:15 -0000
--nextPart1564652.Xm4cfOt2Zi
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On 2011 August 11 Thursday, Mike Hearn wrote:
> I don't think Gavin misunderstands how open source works at all. It's
> completely normal for project maintainers to say "no" more often than
> they say "yes". When I worked on open source for a living this was
> part of the natural flow of things.
That wasn't the part I said he didn't understand. It was assuming that you=
=20
can just declare that people should work on bug fixes and not features was =
a=20
misunderstanding. People work on open source (at least at first) to get a=
=20
feature they want. They aren't just going to show up and cry "command me=20
lord".
> It's important to understand that ideas which receive "maybe" or "yes
> but later" or "no unless you convince me" or "perhaps in a different
> way" are not being shot down. These answers are requests for more work
> to be done. You *cannot* get emotional about open source contributions
> and any veteran will tell you this. Open source maintainers cannot and
> do not say yes to every patch or idea that is proposed. I would be
> very worried if Gavin did.
I don't expect them to; as I said, I'm not after everything I say being=20
accepted out of hand, certainly as I haven't even turned up with patches. =
And=20
you are absolutely correct that that would be worrying if it were so. What=
I=20
object to is no guidance is offered to get the suggester what they want, a=
=20
"you could have this if you did it like this", or "perhaps if you explained=
a=20
bit more". It's just "no, your idea is based on your weak understanding of=
=20
bitcoin," perhaps I'm being overly arrogant, but I think I understand it a =
lot=20
more than you presume I do.
I do try not to get emotional about these things; and email is not the best=
=20
medium for conveying level of distress -- I'm certainly not banging on my=20
keyboard, close to a heart attack. My motivation is only that I would like=
to=20
see bitcoin do well, and I do see that the treatment of potential new peopl=
e,=20
while not offensive (nobody says f*ck off), is not encouraging.
> Now let's review these ideas:
Honestly you needn't have bothered. They've been reviewed to death at this=
=20
point; and I'm not that interested in fighting to get them into a project t=
hat=20
doesn't want them. I'll just play with my bricks over in the corner if tha=
t's=20
okay? I offered the list as a demonstration that ideas don't get construct=
ive=20
help as to how progress can be made on them (i.e. how to make them=20
acceptable), they just get rejected.
Anyway; as you've put the time in, I'll do the same and respond.
> > Don't believe me? Here's a list of ideas
> >=20
> > - Extra bits in the service field of the version message to allow nodes
> > to indicate if they are mining; if they are willing to be seed nodes;
> > if they relay transactions; if they want relayed transactions.
>=20
> I think the concept is reasonable but service flags might not be the
> best way to do it, for instance, asking for a filtered transaction
> feed is useful for lightweight clients so you'd want more precision
> that can be fit into service bits.
The service bits just seemed like the "bitcoin way" as the field already=20
existed. Personally I would prefer an additional "capabilities" request wi=
th=20
a variable number of ASCII strings in it, each indicating a capability, and=
if=20
that's good with all of you -- excellent.
> > - getblocks in reverse chronological order so clients can start up
> > quicker while downloading the blocks in the backround. Ironically I was
> > told "patches welcome" by someone who didn't reject this one instantly.
>=20
> I already told you this won't help startup time because you have to
> connect blocks together in sequence. You can't build up the block
> chain backwards unless you don't care about validation at all.
I know you "told me this", but I think you are wrong. This is an example o=
f=20
the problem I'm trying to get across -- I see things differently; but rathe=
r=20
than try and either fix my misunderstanding or see what I'm trying to achie=
ve,=20
it's rejected.
I've already got it well on its way to being implemented is how I know you =
are=20
wrong. It's perfectly possible to validate backwards because you are=20
constructing a coherent chain based on an unvalidated start point. You the=
n=20
request the parent block and either (a) you finally reach the genesis block=
,=20
you have reached a hard-coded valid point and the entire chain is therefore=
=20
instantly validated or (b) you have a new start block, floating but validat=
ed=20
to be part of the chain, if not absolutely validated. Further, with some=20
checkpoints hard coded you don't even need to reach the genesis block to ge=
t a=20
validated chain. The body of a block obviously can't be faked because of t=
he=20
Merkle hash.
And finally... who says I care about validation? Perhaps I plan a situatio=
n=20
where I implicitly trust the peer I'm talking to (which is exactly what I d=
o=20
plan). "There are more things in heaven and earth, Horatio, than are dream=
t=20
of in your philosophy".
> > - Query miners for pending transactions
>=20
> Or just have them send an inv containing them after connect. I don't
> remember this one being "shot down".
I was told it had severe privacy implications; and you told me that it woul=
d=20
be better to wait for some sort of filtering system that was planned, which=
=20
I'd not heard of. I admit it wasn't exactly clear to me how what you=20
described helped with my suggestion. Your suggestion here is a good=20
alternative; but wouldn't it waste bandwidth? After all a receving node ha=
s=20
no idea whether I have been connected to another node for 24 hours before I=
=20
connect to it, and hence wouldn't need the list.
> > - Application version separate from client version
>=20
> You mean separate from protocol version, right?
Yep. I can well imagine that when alternative clients start appearing, som=
e=20
will have bugs. It will be very handy to either work around those bugs or=
=20
simply deny version 1.4.17 of "Andy's Sexy Bitcoin Client" from connecting.=
=20
Even just for monitoring network state it's useful. There is already talk,=
I=20
see, of establishing how much of the network runs each released bitcoin=20
version.
> > - A way of requesting block bodies without headers (saving a lot of
> > traffic for a thin client upgrading)
>=20
> The cost/benefit ratio of this one isn't obvious at all. The resource
> requirements for running a full node are large enough that
> re-downloading 80 bytes per block is the least of your worries if
> you're upgrading.
The benefit I'm aiming at is to imagine a thin client that has done a fast=
=20
startup and only downloaded the headers. Then, it has a finite number of=20
addresses it's interested in and wants to grab only the relevant bodies fro=
m=20
the full chain. Or, fast startup is to grab all the headers, and then slow=
ly=20
grab the transactions from the blocks.
The cost is
if( !bodyOnly )
sendHeader();
sendBody();
I can't say I'm that invested in it; but it was another one for the list of=
=20
"well I don't see what use that is" responses.
> > - Double SHA-256 for a packet checksum? Seriously?
>=20
> Feel free to submit a patch to disable checksum validation and see if
> Gavin accepts it. It needs to still be calculated at send time for
> other implementations.
I do feel free to write any patch I like. It's such a trivial patch though=
,=20
that I feel certain you are being faceitous, knowing full well that it=20
wouldn't be accepted. I'm trying to look five years in the future. I'm no=
t=20
suggesting it be turned off now -- that's impossible and I'm not an idiot. =
=20
I'm trying to think of what the protocol should be and have a way of moving=
to=20
that.
The patch that is needed then is the one that makes the change gracefully.
> > - Sequence number as part of TxIn instead of part of the whole
> > transaction
>=20
> Sequence numbers are already part of the tx inputs. Or do you mean
> they should be part of the whole transaction? If the latter then this
> is indeed an idea that will be shot down, it's deliberate that seqnums
> are part of the txinputs and it needs to be that way for contracts. It
> can't be changed without forking the protocol anyway.
The sequence number (and perhaps I've misunderstood) allows me to replace a=
=20
transaction I've already submitted. I can't replace just one of the inputs=
, I=20
have to replace the whole transaction. It's therefore the transaction that=
=20
should have the sequence number. A signed transaction received with a high=
er=20
sequence number should displace a lower one.
I'm happy to accept that I have missed the use of the current sequence numb=
ers=20
in contracts. (To be fair, the wiki says "Transaction version as defined b=
y=20
the sender. Intended for "replacement" of transactions when information is=
=20
updated before inclusion into a block.")
Perhaps putting it in TxIn was because no one thought of having=20
OP_PUSH_SEQUENCENUMBER as a script operator.
> > Every single one of those has been shot down by one or more of the main
> > developers. I'm not a genius, and not arrogant enough to assume that
> > everything I say is right, but _nothing_? Really? There is no problem
> > that one of the above addresses?
>=20
> Some of your proposals address problems that need to be solved, but
> it's not clear that way is the right way to solve them. Others reflect
> either lack of understanding of the system or the fact that you don't
> value backwards compatibility whereas other people do.
Of the above, only one could be lack of understanding (txIn).
As to not valuing backward compatibility -- I certainly do. That shouldn't=
be=20
used as an excuse to freeze the protocol forever. There are version fields=
in=20
there, sensibly so; they should be used to fix problems. As I said a few=
=20
times, the incompatible changes don't have to activate straight away, they =
can=20
be delayed using the block number. Make it a block number four years away =
if=20
you want, but the sooner those changes go in (whatever they may be), the mo=
re=20
likely it is you'll get the majority of the network to change over. And on=
ce=20
the alternative clients start appearing, the opportunity is gone -- if it's=
=20
hard to get one client to change, imagine how hard it will be to change fiv=
e.
As I said above though, I don't want these fights. I know full well that w=
hat=20
I want is not what you all want as far as client ideas go. I only started=
=20
this response because I thought Gavin's "we don't want new developers for n=
ew=20
features, we want bug fixes" was a bit of a foolish thing to say.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1564652.Xm4cfOt2Zi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk5D3kkACgkQwQJ9gE9xL22A7QCgsjSJBGBnydNQX967YFXp0Y8T
FckAn2nCIXW6ALm5Xl4ACETR6sV5qdsw
=MoAT
-----END PGP SIGNATURE-----
--nextPart1564652.Xm4cfOt2Zi--
|