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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1QrHmO-0004f0-Dn
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 23:01:40 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=andyparkins@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrHmN-0000bP-CL
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 23:01:40 +0000
Received: by fxg11 with SMTP id 11so2191371fxg.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 16:01:33 -0700 (PDT)
Received: by 10.223.47.9 with SMTP id l9mr11822098faf.55.1313015907879;
Wed, 10 Aug 2011 15:38:27 -0700 (PDT)
Received: from grissom.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id l22sm1073483fam.13.2011.08.10.15.38.25
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 10 Aug 2011 15:38:26 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Date: Wed, 10 Aug 2011 23:38:21 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102213.09632.andyparkins@gmail.com>
<CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com>
In-Reply-To: <CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108102338.21680.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: 1QrHmN-0000bP-CL
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: Wed, 10 Aug 2011 23:01:40 -0000
On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote:
> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail.com>
wrote:
> > Don't believe me? Here's a list of ideas I've had "no, no, no"d so
> > far; not one of which would have any financial implication at all.
> > Only some of which would break backward compatibility.
>
> Breaking backwards compatibility means breaking people's access to
> their own money.
I wasn't actually giving a full explanation of how these things could be
done, I was providing a list of "negatively received ideas"; imagine my
surprise that they have been negatively received by you.
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.
> If you remove an "unnecessary" step that existing nodes expect, then
> the cost of disrupting monetary access seems higher than the value of
> that breaking change.
If only there were some way of sending different things to different nodes,
based on some sort of version number field.
> > - Remove verack, as it's completely unnecessary.
>
> Compatibility issues?
if( Version < VERSION_INTRODUCED )
sendVerack();
My point is that you are a clever guy; you are perfectly capable of coming
up with these answers, but you don't want to. Nor does any other bitcoin
developer. The protocol is perfect and there is no way of changing it.
> > - Query miners for pending transactions
>
> I could see value in querying a bitcoind node over JSON-RPC for
> pending transactions... and by extension, supporting that as an RPC on
> various miners' pool servers. Having a local dump of pending TX's
> would be useful.
>
> As an optional bitcoin P2P protocol command, available to anyone,
> seems to negatively impact privacy.
Eh? The transaction list is available on bitcoincharts. If my node had
been connected it would have received that list anyway when each one was
broadcast. What possible privacy loss could there be by making it possible
to request it be repeated?
Again though: the detail isn't the point. It's another half-hearted
objection.
> > - A way of requesting block bodies without headers (saving a lot of
> > traffic for a thin client upgrading)
>
> Do you mean headers without bodies? Gavin wants to work on
> headers-only, from what I've read, but others are welcome to
> contribute patches.
No; I mean being able to ask for just the block without the header. The
reason being that a thin client might request blocks on demand... it's
already got the header and doesn't need it again.
The response: "it's only 80 bytes, blah, blah". 80*150000*N is a non-
trivial amount of traffic.
> > - Double SHA-256 for a packet checksum? Seriously?
>
> Compatibility issues?
Only for the version message. But it would be trivial to do both types of
checksum on the version message, and if either is true to accept the version
message. After which the version is known and a much simpler checksum could
be used for subsequent messages. Eventually the network would be upgraded
enough that the old way can be dropped.
Besides... hasn't TCP already got checksumming? Let's just stop checking
the checksum. Or better still, stop calculating it and sending it. Double
SHA-256 on every single message on every single node to create four checksum
bytes is an enormous waste of CPU.
> > - Sequence number as part of TxIn instead of part of the whole
> > transaction
>
> Compatibility issues?
If only there were a version field in the transaction and block structures.
Again; casual rejection.
> > - Script parameters should be stored outside the script, and reference
> > by the script. All that ridiculous filtering of the scripts in
> > OP_CHECKSIG would then go away.
>
> Compatibility issues?
See above.
> > - MSG_DOUBLESPEND... nope
>
> Does consensus want this?
No, "consensus" doesn't. I was simply listing all the ideas that got
rejected out of hand. The reason "consensus" doesn't think this one is
necessary is because "we can already detect double spends by being widely
connected"; ignoring the fact that a light or intermittently connected
client would not be widely connected. But that's okay because "eventually
payment processors will appear". Yep, my idea for fixing bitcoin is stupid
because eventually someone else will mitigate it.
> > - getblocks to accept MSG_TX and do something sensible
>
> Link to elaboration of use case and need?
It was a few weeks ago; and it was an email from me about getblocks
enhancements. It was patronisingly laughed off as being something that all
you newbie "alternative client" writers go through.
The use case is an on-demand thin client that wants to find the block that
contains a particular transaction ID without downloading and indexing every
single block in the chain. Additionally, _I_ plan to separate the block
chain and wallet executables, so much so that the wallet executable doesn't
necessarily need a local blockchain node and relies on a partially trusted
remote -- it still wants to be able to do spot checks on that remote, and
confirm whatever it's told. I would like to be able to do that using only
commands that are in the official protocol; but I'm rapidly coming to accept
that nothing I ask for will ever go in because there is no "use case".
> Well, one unfortunate current aspect of bitcoin is... there seem to
> be problems aplenty right now :)
As with every project.
However, the protocol is being treated as if it is some kind of holy scroll,
and must not be touched. Bitcoin's ideas are revolutionary, its
implementation is not. If we started again today, it would be done
differently. Shouldn't we be trying to move the current protocol toward
_that_ "done differently" as much as possible while bitcoin is still
relatively small? Rhetorical again... I know the answer, it's "no".
What exactly do the developers mean when they keep talking about bitcoin as
"experimental"? It seems to me they mean "incredibly conservative, with no
changes for the rest of time".
> However demotivating it may be, keeping the current system running
> must take priority over new features.
Nothing I've suggested was to "stop the current system". I'm not even
asking for developers to prioritise my ideas. I would just like mine, or
anyone's ideas to not be instantly rejected out of hand. I mean for
goodness sake, even "splitting into multiple executables" has been stomped
on in this very thread. If something as trivial as that is "impossible"
what chance is there that I would ever get "Change the 64-bit timestamp
field to be microseconds since the epoch instead of seconds" in?
> I also heartily encourage others to do something I always want to do,
> but for lack of time: work on the design for bitcoin v2 ("theme: any
> breaking change is acceptable, it is a new block chain") There you
> may improve the protocol, get rid of the patent-cloudy ECDSA, use
> google's protocol buffers for encoding, make the proof-of-work
> algorithm memory-intensive, and other excellent, thoughtful
> breaking-change suggestions that have been made.
There is a popular idea that some other cryptocurrency will come along and
displace bitcoin. It's not going to happen. Networking effects mean that
there is no reason for people to change. I can just see the queue around
the block now for bitcoin.2; identical in function to bitcoin except it
"doesn't use ECDSA and the it uses protocol buffers on the wire, and uses
more memory". Wow; there's a set of unique selling points. I'll get signs
made.
Let's be practical: technical-only improvements _have_ to be to bitcoin.1.
Bitcoin's financial features are already complete or in progress; and it is
financial features that would make people migrate to a competitor. Nobody
is going to move to bitcoin.v2 because the source code has better comments.
> Securing the integrity of money means that a lot of implementation
> decisions have been cemented into stone, however much we may
> personally dislike them. Backwards compatibility is paramount.
I disagree about how set in stone these things are; but yeah; I've accepted
that I'm on a loser. My list was to demonstrate how negative the community
is; and you have confirmed that for me admirably. Bear that in mind the
next time you're discussing the lack of manpower for bug fixes.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
