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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1QrMFj-00073L-1v
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 03:48:15 +0000
X-ACL-Warn:
Received: from mail-iy0-f171.google.com ([209.85.210.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrMFh-0003Pt-T1
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 03:48:14 +0000
Received: by iyf13 with SMTP id 13so486158iyf.30
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 20:48:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.91.139 with SMTP id p11mr7602851icm.402.1313032825910; Wed,
10 Aug 2011 20:20:25 -0700 (PDT)
Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 20:20:25 -0700 (PDT)
X-Originating-IP: [99.173.148.118]
In-Reply-To: <201108102338.21680.andyparkins@gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102213.09632.andyparkins@gmail.com>
<CA+8xBpd9QCPt50E0VohfP8THwzf34UuT8gMtCE=gXZw1Sf0BBQ@mail.gmail.com>
<201108102338.21680.andyparkins@gmail.com>
Date: Wed, 10 Aug 2011 23:20:25 -0400
Message-ID: <CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@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: 1QrMFh-0003Pt-T1
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 03:48:15 -0000
On Wed, Aug 10, 2011 at 6:38 PM, Andy Parkins <andyparkins@gmail.com> wrote=
:
> 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? =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.
>
> 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:
>
> =A0if( blockNumber > 500000 )
> =A0 new_process();
> =A0else
> =A0 old_process();
>
> Would sort all of your "compatibility" objections out, and would give nod=
es
> 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
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.
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.
> However, the protocol is being treated as if it is some kind of holy scro=
ll,
> 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".
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.
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...
> I disagree about how set in stone these things are; but yeah; I've accept=
ed
> that I'm on a loser. =A0My list was to demonstrate how negative the commu=
nity
> is; and you have confirmed that for me admirably. =A0Bear that in mind th=
e
> next time you're discussing the lack of manpower for bug fixes.
It's negative to weight costs vs. benefits? That is what I expect any
good engineer to do.
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.
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.
--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
