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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z5acp-00007V-Rz
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 14:17:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.171 as permitted sender)
client-ip=209.85.212.171; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f171.google.com;
Received: from mail-wi0-f171.google.com ([209.85.212.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5ack-0000bC-0e
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 14:17:03 +0000
Received: by wiwd19 with SMTP id d19so24474781wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 07:16:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.205.168 with SMTP id lh8mr27423187wic.95.1434637012054;
Thu, 18 Jun 2015 07:16:52 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 07:16:51 -0700 (PDT)
In-Reply-To: <20150618140544.GA7674@amethyst.visucore.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
<CANEZrP04SUHShoqUkA3aSs3yEP3GSsZ_3ZOGFXyJfNve5KTPfA@mail.gmail.com>
<20150618140544.GA7674@amethyst.visucore.com>
Date: Thu, 18 Jun 2015 16:16:51 +0200
X-Google-Sender-Auth: NE9uCowMU7u61i79-JIYxvb5yk4
Message-ID: <CANEZrP0zxfK_SqveYyaPxAxVn_kM2347VrjstmkbHkXJC9suZw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c38ace7c3ca10518cb75e5
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Z5ack-0000bC-0e
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
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, 18 Jun 2015 14:17:03 -0000
--001a11c38ace7c3ca10518cb75e5
Content-Type: text/plain; charset=UTF-8
>
> If you think it's not clear enough, which may explain why you did not even
> attempt to follow it for your block size increase, feel free to make
> improvements.
>
As the outcome of a block size BIP would be a code change to Bitcoin Core,
I cannot make improvements, only ask for them. Which is what I'm doing.
I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany
his patch, because BIPs are best when they describe working code, and BIP 1
*is* at least clear about that. Otherwise it can turn out during
implementation that something was different to what was anticipated. I'm
sure you agree with this.
So a BIP is coming. However, BIP 1 also says this:
Vetting an idea publicly before going as far as writing a BIP is meant to
> save the potential author time
and
BIP authors are responsible for collecting community feedback on a BIP
> before submitting it for review
OK. Gavin has been vetting the idea publicly and collecting community
feedback. Note that the entire Bitcoin community is not on this list, so he
published a series of blog posts to get wider feedback, and then was
criticised for not doing it all here instead.
But anyway - so far, so good. The procedure is being followed.
What happens once a BIP is written? The process says:
For a BIP to be accepted it must meet certain minimum criteria. It must be
> a clear and complete description of the proposed enhancement. The
> enhancement must represent a net improvement. The proposed implementation,
> if applicable, must be solid and must not complicate the protocol unduly.
> Once a BIP has been accepted, the reference implementation must be
> completed.
This is where the problem starts.
The BIP process you refer to *does not state how acceptance will happen*.
It merely sets out a few minimum requirements like making some sort of
sense, having code. It's also full of extremely vague descriptions like
"must represent a net improvement". Improvement according to who? That's
left unexplained.
And then it says what happens once a BIP is accepted.
The middle bit is missing. When there is disagreement over a consensus BIP,
how are decisions made?
--001a11c38ace7c3ca10518cb75e5
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"><blo=
ckquote 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;paddi=
ng-left:1ex">If you think it's not clear enough, which may explain why =
you did not even attempt to follow it for your block size increase, feel fr=
ee to make improvements.<br></blockquote><div><br></div><div>As the outcome=
of a block size BIP would be a code change to Bitcoin Core, I cannot make =
improvements, only ask for them. Which is what I'm doing.</div><div><br=
></div><div>I agree that BIP 1 is not clear enough. Gavin is writing a BIP =
to accompany his patch, because BIPs are best when they describe working co=
de, and BIP 1 <i>is</i>=C2=A0at least clear about that. Otherwise it can tu=
rn out during implementation that something was different to what was antic=
ipated. I'm sure you agree with this.</div><div><br></div><div>So a BIP=
is coming. However, BIP 1 also says this:</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><span style=3D"color:rgb(51,51,51);font-family:'Helvetica Neue'=
;,Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;lin=
e-height:20.4799995422363px">Vetting an idea publicly before going as far a=
s writing a BIP is meant to save the potential author time</span></blockquo=
te><div><span style=3D"color:rgb(51,51,51);font-family:'Helvetica Neue&=
#39;,Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;=
line-height:20.4799995422363px"><br></span></div>and<div><span style=3D"col=
or:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe =
UI',Arial,freesans,sans-serif;font-size:16px;line-height:20.47999954223=
63px"><br></span></div><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"><span style=3D"color:rgb(51,51,51);=
font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,fre=
esans,sans-serif;font-size:16px;line-height:20.4799995422363px">BIP authors=
are responsible for collecting community feedback on a BIP before submitti=
ng it for review</span></blockquote><div><br></div>OK. Gavin has been vetti=
ng the idea publicly and collecting community feedback. Note that the entir=
e Bitcoin community is not on this list, so he published a series of blog p=
osts to get wider feedback, and then was criticised for not doing it all he=
re instead.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">But anyway - so far, so good.=C2=A0 The procedure is being followed.<=
/div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">What h=
appens once a BIP is written? The process says:</div><div class=3D"gmail_qu=
ote"><br></div><div class=3D"gmail_quote"><blockquote style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex" class=3D"gmail_quote">For a BIP to be =
accepted it must meet certain minimum criteria. It must be a clear and comp=
lete description of the proposed enhancement. The enhancement must represen=
t a net improvement. The proposed implementation, if applicable, must be so=
lid and must not complicate the protocol unduly.</blockquote><div>=C2=A0</d=
iv><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bord=
er-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" cl=
ass=3D"gmail_quote">=C2=A0Once a BIP has been accepted, the reference imple=
mentation must be completed.=C2=A0</blockquote><div class=3D"gmail_quote"><=
br></div>This is where the problem starts.</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">The BIP process you refer to <b>does n=
ot state how acceptance will happen</b>. It merely sets out a few minimum r=
equirements like making some sort of sense, having code. It's also full=
of extremely vague descriptions like "must represent a net improvemen=
t". Improvement according to who? That's left unexplained.</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">And then it s=
ays what happens once a BIP is accepted.</div><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">The middle bit is missing. When there is=
disagreement over a consensus BIP, how are decisions made?</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div></div></div=
>
--001a11c38ace7c3ca10518cb75e5--
|
