summaryrefslogtreecommitdiff
path: root/33/9a087f3a2e7e7637663e80fd79f91bed49204e
blob: a1418965dcbc1941ab7976d05ec5bda795c12d54 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <melvincarvalho@gmail.com>) id 1UgAh6-0004So-Bt
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 May 2013 09:23:20 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.44 as permitted sender)
	client-ip=209.85.215.44; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f44.google.com; 
Received: from mail-la0-f44.google.com ([209.85.215.44])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UgAh5-0000V1-2o
	for bitcoin-development@lists.sourceforge.net;
	Sat, 25 May 2013 09:23:20 +0000
Received: by mail-la0-f44.google.com with SMTP id fr10so5237019lab.31
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 25 May 2013 02:23:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.22.4 with SMTP id z4mr10507648lae.37.1369473792241; Sat,
	25 May 2013 02:23:12 -0700 (PDT)
Received: by 10.112.190.67 with HTTP; Sat, 25 May 2013 02:23:12 -0700 (PDT)
In-Reply-To: <201305250853.19603.luke@dashjr.org>
References: <CAM_a8Jwo_7NJJoaKYUYo6T7U8AsDfT5=MZSXjmdYU4330OHNmw@mail.gmail.com>
	<CAKaEYhKOmSc+Mz=vA-M=34aXOs=VfC0jvCP+qNSdjE_2WVUfkg@mail.gmail.com>
	<201305250853.19603.luke@dashjr.org>
Date: Sat, 25 May 2013 11:23:12 +0200
Message-ID: <CAKaEYhJycyXjEBa26PJrNdBWEeTUqW+HKEvvjTi-R4PTOSy85w@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e0158b8e2ea76fe04dd8776b3
X-Spam-Score: -0.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
	(melvincarvalho[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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
X-Headers-End: 1UgAh5-0000V1-2o
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] (no subject)
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: Sat, 25 May 2013 09:23:20 -0000

--089e0158b8e2ea76fe04dd8776b3
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 10:53, Luke-Jr <luke@dashjr.org> wrote:

> On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> > It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> > out separately
>
> Bitcoin is a consensus system. You can't run clients with different rules
> on
> the same blockchain/network - it just won't work! Maybe we're now talking
> about mere client default policies? In which case, you should be able to
> configure previous behaviour...
>

[[ Not wishing to stray too far off topic ]]

I think you are perhaps underestimating the effect of 'mere' default
policies.

It would be nice to think that every node was a free thinking individual
that is motivated to vote with their feet, but in practice most people dont
have time.

There is research showing that 80% of users tend to accept defaults.

Rule changes and changing defaults would seem to be things worth weighing.
Bug fixes hopefully should be fairly unanimous.  Of course a grey area
exists in between.


>
> If you want just bug fixes and rule changes, without policy default
> changes,
> new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised
> these are short-term solutions and won't be maintained forever - so you
> really
> should try to get the behaviour you want from the current release. If you
> can't for some reason, please do report a bug explaining what it is the
> older
> version was capable of that the new one isn't!
>
> Luke
>

--089e0158b8e2ea76fe04dd8776b3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 10:53, Luke-Jr <span dir=3D"ltr">&lt;<a href=3D"mail=
to:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrot=
e:<br>
&gt; It might be an idea to have &#39;rule change&#39; fixes and &#39;bug f=
ix&#39; releases go<br>
&gt; out separately<br>
<br>
</div>Bitcoin is a consensus system. You can&#39;t run clients with differe=
nt rules on<br>
the same blockchain/network - it just won&#39;t work! Maybe we&#39;re now t=
alking<br>
about mere client default policies? In which case, you should be able to<br=
>
configure previous behaviour...<br></blockquote><div><br></div><div>[[ Not =
wishing to stray too far off topic ]]<br></div><div><br></div><div>I think =
you are perhaps underestimating the effect of &#39;mere&#39; default polici=
es.=A0 <br>
<br></div><div>It would be nice to think that every node was a free thinkin=
g individual that is motivated to vote with their feet, but in practice mos=
t people dont have time.<br></div><div><br>There is research showing that 8=
0% of users tend to accept defaults.<br>
<br></div><div>Rule changes and changing defaults would seem to be things w=
orth weighing.=A0 Bug fixes hopefully should be fairly unanimous.=A0 Of cou=
rse a grey area exists in between.<br></div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<br>
If you want just bug fixes and rule changes, without policy default changes=
,<br>
new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised<=
br>
these are short-term solutions and won&#39;t be maintained forever - so you=
 really<br>
should try to get the behaviour you want from the current release. If you<b=
r>
can&#39;t for some reason, please do report a bug explaining what it is the=
 older<br>
version was capable of that the new one isn&#39;t!<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div></div>

--089e0158b8e2ea76fe04dd8776b3--