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
199
200
201
|
Return-Path: <adrian.macneil@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ABAF61208
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 31 Dec 2015 23:30:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3EB1124
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 31 Dec 2015 23:30:11 +0000 (UTC)
Received: by mail-ig0-f175.google.com with SMTP id to4so202066257igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 31 Dec 2015 15:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=lSXjo22mSjWj92BHvJ73Cb/d54USqtp6K07k3WDUK5Q=;
b=cXDFzr9+5uS3Nymq8lZcEWdGbq9xicZfLSAESJu9siQ5DiCGYQlEZAIXZ7CiRbnoeF
USCbgimXUN9y0VugH/GS87z7abv6nW41InmOdn4MOjGt4sBnrdXtcdA9MVPVVFdIKcc+
OTnmcRkbaGHSBQJ8sSnub/oy7/DOfOgFvhbmyB6dBGHKmYggozUfAPW/j+s58SifHFyu
RH234GVMXdYsy3AlqqCukgNrUKM3o8GgqAf3EeZU3E9ImXAO7Q9C1dNUz9XbdxJ8RYkO
mkj3PdfElN1691NVSXWfd/7usb3+Ow+vuisdojpIZdmRrv4zSAWmpTA0pdNdgOMLemsf
ccSw==
X-Received: by 10.50.112.137 with SMTP id iq9mr10105243igb.66.1451604611458;
Thu, 31 Dec 2015 15:30:11 -0800 (PST)
MIME-Version: 1.0
References: <CAE0pACJf=aQFFTwRyWn+8SxS2P-v5FmG77kbC35rq_0p42CDEw@mail.gmail.com>
<20151231231440.GA5112@muck>
In-Reply-To: <20151231231440.GA5112@muck>
From: Adrian Macneil <adrian.macneil@gmail.com>
Date: Thu, 31 Dec 2015 23:30:02 +0000
Message-ID: <CAFbKzyNBWju8wsgLVtv4Es9jaOkK1X75OnketGfO7rBq7e5_7Q@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, Marco Pontello <marcopon@gmail.com>
Content-Type: multipart/alternative; boundary=089e013c60ec38719005283a09dc
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 31 Dec 2015 23:47:42 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP numbers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2015 23:30:12 -0000
--089e013c60ec38719005283a09dc
Content-Type: text/plain; charset=UTF-8
I'm not sure if anyone has suggested this in the past, but a novel approach
would be to simply let anyone open a pull request and use the PR # as the
BIP #. This would avoid conflicts, and avoid the chore of having someone
manually assign them.
Downside would be that some numbers will never get used (for example if PRs
are opened to update existing BIPs), but this doesn't seem to be a huge
problem since already many numbers are going unused.
This process can still be independent from approving/merging the BIP into
master, if it meets quality standards.
On Thu, Dec 31, 2015 at 3:14 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 30, 2015 at 05:42:47PM +0100, Marco Pontello via bitcoin-dev
> wrote:
> > Sorry to ask again but... what's up with the BIP number assignments?
> > I thought that it was just more or less a formality, to avoid conflicts
> and
> > BIP spamming. And that would be perfectly fine.
> > But since I see that it's a process that can take months (just looking at
> > the PR request list), it seems that something different is going on.
> Maybe
> > it's considered something that give an aura of officiality of sorts? But
> > that would make little sense, since that should come eventually with
> > subsequents steps (like adding a BIP to the main repo, and eventual
> > approvation).
> >
> > Having # 333 assigned to a BIP, should just mean that's easy to refer to
> a
> > particular BIP.
> > That seems something that could be done quick and easily.
> >
> > What I'm missing? Probably some historic context?
>
> You ever noticed how actually getting a BIP # assigned is the *last*
> thing the better known Bitcoin Core devs do? For instance, look at the
> segregated witness draft BIPs.
>
> I think we have problem with peoples' understanding of the Bitcoin
> consensus protocol development process being backwards: first write your
> protocol specification - the code - and then write the human readable
> reference explaining it - the BIP.
>
> Equally, without people actually using that protocol, who cares about
> the BIP?
>
>
> Personally if I were assigning BIP numbers I'd be inclined to say "fuck
> it" and only assign BIP numbers to BIPs after they've had significant
> adoption... It'd might just cause a lot less headache than the current
> system.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e013c60ec38719005283a09dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm not sure if anyone has suggested this in the past, but a novel appr=
oach would be to simply let anyone open a pull request and use the PR # as =
the BIP #. This would avoid conflicts, and avoid the chore of having someon=
e manually assign them. <br><br>Downside would be that some numbers will ne=
ver get used (for example if PRs are opened to update existing BIPs), but t=
his doesn't seem to be a huge problem since already many numbers are go=
ing unused. <br><br>This process can still be independent from approving/me=
rging the BIP into master, if it meets quality standards. <br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Thu, Dec 31, 2015 at 3:14 PM Peter Todd v=
ia bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">On Wed, Dec 30, 2015 at 05:42:47PM +0100, Marco Pontello=
via bitcoin-dev wrote:<br>
> Sorry to ask again but... what's up with the BIP number assignment=
s?<br>
> I thought that it was just more or less a formality, to avoid conflict=
s and<br>
> BIP spamming. And that would be perfectly fine.<br>
> But since I see that it's a process that can take months (just loo=
king at<br>
> the PR request list), it seems that something different is going on. M=
aybe<br>
> it's considered something that give an aura of officiality of sort=
s? But<br>
> that would make little sense, since that should come eventually with<b=
r>
> subsequents steps (like adding a BIP to the main repo, and eventual<br=
>
> approvation).<br>
><br>
> Having # 333 assigned to a BIP, should just mean that's easy to re=
fer to a<br>
> particular BIP.<br>
> That seems something that could be done quick and easily.<br>
><br>
> What I'm missing? Probably some historic context?<br>
<br>
You ever noticed how actually getting a BIP # assigned is the *last*<br>
thing the better known Bitcoin Core devs do? For instance, look at the<br>
segregated witness draft BIPs.<br>
<br>
I think we have problem with peoples' understanding of the Bitcoin<br>
consensus protocol development process being backwards: first write your<br=
>
protocol specification - the code - and then write the human readable<br>
reference explaining it - the BIP.<br>
<br>
Equally, without people actually using that protocol, who cares about<br>
the BIP?<br>
<br>
<br>
Personally if I were assigning BIP numbers I'd be inclined to say "=
;fuck<br>
it" and only assign BIP numbers to BIPs after they've had signific=
ant<br>
adoption... It'd might just cause a lot less headache than the current<=
br>
system.<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e013c60ec38719005283a09dc--
|
