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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <btcdrak@gmail.com>) id 1YqRvY-00050O-W0
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:57:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.54 as permitted sender)
client-ip=209.85.216.54; envelope-from=btcdrak@gmail.com;
helo=mail-vn0-f54.google.com;
Received: from mail-vn0-f54.google.com ([209.85.216.54])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqRvX-0003me-9D
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:57:48 +0000
Received: by vnbf62 with SMTP id f62so3935309vnb.13
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 12:57:41 -0700 (PDT)
X-Received: by 10.52.75.99 with SMTP id b3mr282715vdw.2.1431028661818; Thu, 07
May 2015 12:57:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.63.5 with HTTP; Thu, 7 May 2015 12:57:20 -0700 (PDT)
In-Reply-To: <CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
<CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 7 May 2015 20:57:20 +0100
Message-ID: <CADJgMzueczTRZ57-fvh=JwjytP6KBQoQWzBptXvZLu+VFvvrOQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=bcaec501604b0d1a340515835371
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HK_RANDOM_FROM From username looks random
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.6 HK_RANDOM_ENVFROM Envelope sender username looks random
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(btcdrak[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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqRvX-0003me-9D
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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, 07 May 2015 19:57:49 -0000
--bcaec501604b0d1a340515835371
Content-Type: text/plain; charset=UTF-8
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn <mike@plan99.net> wrote:
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
>> Core are made by consensus. "Controversial" changes are avoided. I am
>> trying to show you that this is just marketing.
>
>
Consensus is arrived when the people who are most active at the time
(active in contributing to discussions, code review, giving opinions etc.)
agreed to ACK. There are a regular staple of active contributors. Bitcoin
development is clearly a meritocracy. The more people participate and
contribute the more weight their opinions hold.
> Nobody can define what these terms even mean. It would be more accurate to
>> say decisions are vetoed by whoever shows up and complains enough,
>> regardless of technical merit. After all, my own getutxo change was merged
>> after a lot of technical debate (and trolling) ..... then unmerged a day
>> later because "it's a shitstorm".
>
>
I am not sure that is fair, your PR was reverted because someone found a
huge exploit in your PR enough to invalidate all your arguments used to get
it merged in the first place.
> So if Gavin showed up and complained a lot about side chains or whatever,
> what you're saying is, oh that's different. We'd ignore him. But when
> someone else complains about a change they don't like, that's OK.
>
> Heck, I could easily come up with a dozen reasons to object to almost any
> change, if I felt like it. Would I then be considered not a part of the
> consensus because that'd be convenient?
>
I don't think it's as simple as that. Objections for the sake of
objections, or unsound technical objections are going to be seen for what
they are. This is a project with of some of the brightest people in the
world in this field. Sure people can be disruptive but their reputation
stand the test of time.
The consensus system might not be perfect, but it almost feels like you
want to declare a state of emergency and suspend all the normal review
process for this proposed hard fork.
--bcaec501604b0d1a340515835371
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, May 7, 2015 at 5:11 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mai=
lto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">Right now there is this nice warm =
fuzzy notion that decisions in Bitcoin Core are made by consensus. "Co=
ntroversial" changes are avoided. I am trying to show you that this is=
just marketing. </blockquote></span></div></div></div></blockquote><div><b=
r></div><div>Consensus is arrived when the people who are most active at th=
e time (active in contributing to discussions, code review, giving opinions=
etc.) agreed to ACK. There are a regular staple of active contributors. Bi=
tcoin development is clearly a meritocracy. The more people participate and=
contribute the more weight their opinions hold.=C2=A0</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">Nobody can define what these terms =
even mean. It would be more accurate to say decisions are vetoed by whoever=
shows up and complains enough, regardless of technical merit. After all, m=
y own getutxo change was merged after a lot of technical debate (and trolli=
ng) ..... then unmerged a day later because "it's a shitstorm"=
;.</blockquote></span></div></div></div></blockquote><div><br></div><div>I =
am not sure that is fair, your PR was reverted because someone found a huge=
exploit in your PR enough to invalidate all your arguments used to get it =
merged in the first place.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>So if G=
avin showed up and complained a lot about side chains or whatever, what you=
're saying is, oh that's different. We'd ignore him. But when s=
omeone else complains about a change they don't like, that's OK.</d=
iv><div><br></div><div>Heck, I could easily come up with a dozen reasons to=
object to almost any change, if I felt like it. Would I then be considered=
not a part of the consensus because that'd be convenient?</div></div><=
/div></div></blockquote><div><br></div><div>I don't think it's as s=
imple as that. Objections for the sake of objections, or unsound technical =
objections are going to be seen for what they are. This is a project with o=
f some of the brightest people in the world in this field. Sure people can =
be disruptive but their reputation stand the test of time.</div><div><br></=
div><div>The consensus system might not be perfect, but it almost feels lik=
e you want to declare a state of emergency and suspend all the normal revie=
w process for this proposed hard fork.</div></div></div></div>
--bcaec501604b0d1a340515835371--
|
