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
|
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 <jgarzik@exmulti.com>) id 1QrGQe-0001hd-14
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 21:35:08 +0000
X-ACL-Warn:
Received: from mail-iy0-f171.google.com ([209.85.210.171])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrGQd-00084t-6K
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 21:35:07 +0000
Received: by iyf13 with SMTP id 13so2091793iyf.30
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 14:35:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.244.3 with SMTP id lo3mr7979721icb.335.1313012101439; Wed,
10 Aug 2011 14:35:01 -0700 (PDT)
Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 14:35:01 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
In-Reply-To: <201108102213.09632.andyparkins@gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102032.00373.andyparkins@gmail.com>
<CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com>
<201108102213.09632.andyparkins@gmail.com>
Date: Wed, 10 Aug 2011 17:35:01 -0400
Message-ID: <CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1QrGQd-00084t-6K
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 21:35:08 -0000
On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail.com> wrote=
:
> Don't believe me? =A0Here'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. =A0Only some of
> which would break backward compatibility.
Breaking backwards compatibility means breaking people's access to
their own money.
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.
> =A0- Extra bits in the service field of the version message to allow node=
s
> =A0 to indicate if they are mining; if they are willing to be seed nodes;
> =A0 if they relay transactions; if they want relayed transactions.
My own 'supernode' proposal also includes using the nServices bits.
There's nothing fundamentally incompatible or wrong about that.
> =A0- Remove verack, as it's completely unnecessary.
Compatibility issues?
> =A0- 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.
> =A0- Application version separate from client version
Consensus has already approved this one, AFAIK.
> =A0- A way of requesting block bodies without headers (saving a lot of tr=
affic
> =A0 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.
> =A0- Double SHA-256 for a packet checksum? =A0Seriously?
Compatibility issues?
> =A0- Sequence number as part of TxIn instead of part of the whole transac=
tion
Compatibility issues?
> =A0- Script parameters should be stored outside the script, and reference=
by
> =A0 the script. =A0All that ridiculous filtering of the scripts in OP_CHE=
CKSIG
> =A0 would then go away.
Compatibility issues?
> =A0- MSG_DOUBLESPEND... nope
Does consensus want this?
> =A0- getblocks to accept MSG_TX and do something sensible
Link to elaboration of use case and need?
> You can imagine then that when I read moans about there not being enough =
new
> developers fixing bugs, that I am unsurprised and unsympathetic. =A0I lik=
e
> bitcoin enough to hover on this list; and offer a view of your world from=
a
> potential developer who was chased away.
Well, one unfortunate current aspect of bitcoin is... there seem to
be problems aplenty right now :)
However demotivating it may be, keeping the current system running
must take priority over new features.
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.
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.
--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
