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
202
203
204
205
206
207
208
209
210
211
212
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1VYBuG-0006Ko-Se
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Oct 2013 09:36:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.49 as permitted sender)
client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com;
helo=mail-la0-f49.google.com;
Received: from mail-la0-f49.google.com ([209.85.215.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VYBuF-0000K7-Iv
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Oct 2013 09:36:12 +0000
Received: by mail-la0-f49.google.com with SMTP id eh20so294739lab.8
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Oct 2013 02:36:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.57.49 with SMTP id f17mr12085815lbq.26.1382348164829;
Mon, 21 Oct 2013 02:36:04 -0700 (PDT)
Received: by 10.112.159.233 with HTTP; Mon, 21 Oct 2013 02:36:04 -0700 (PDT)
In-Reply-To: <5264D1DB.5060107@250bpm.com>
References: <38895569-E6E1-4576-9E36-B00B53F9D3CC@me.com>
<201310192229.19932.luke@dashjr.org>
<CAAS2fgRu1j0w8RsiYutixEDxs1NYZVxQ7D7VRgDVi1b-wx+vUQ@mail.gmail.com>
<19909B49-0895-4130-99FB-9A116140CFE9@me.com>
<20131019235746.GA29032@savin>
<9EF588BB-14B5-495A-8253-82574DCB1A8A@me.com>
<20131020224316.GA25280@savin>
<CAJHLa0OTHKaCOnpVBqapxc3xBwkgr4F9cCi0=15P4b80oVc51w@mail.gmail.com>
<20131021062555.GA10784@savin>
<80401395-792A-4637-A75C-1D499C547F98@me.com>
<20131021064320.GA17190@savin>
<AD405CE3-3E5D-4927-9A0E-43238ED3FDFC@me.com>
<5264D1DB.5060107@250bpm.com>
Date: Mon, 21 Oct 2013 11:36:04 +0200
Message-ID: <CAKaEYhKZtN-wT3puES=iF+6L83z0haHS+P2tYHWZ14T4=Gf+aw@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Martin Sustrik <sustrik@250bpm.com>
Content-Type: multipart/alternative; boundary=001a1133eaca5217fe04e93d03bf
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-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: 1VYBuF-0000K7-Iv
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A critique of bitcoin open source
community
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: Mon, 21 Oct 2013 09:36:13 -0000
--001a1133eaca5217fe04e93d03bf
Content-Type: text/plain; charset=ISO-8859-1
On 21 October 2013 09:03, Martin Sustrik <sustrik@250bpm.com> wrote:
> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> > How about putting them into sub directories that map onto the status of
> the BIP?
> >
> > Reading BIP 1, that would make:
> >
> > Accepted
> > Active
> > Draft
> > Deferred
> > Final
> > Rejected
> > Replaced
> > Withdrawn
>
> Have it been considered to do this via IETF? The process there is
> hardened by 40 years of experience and 7000+ RFCs. Probably better than
> anything you can devise yourself.
>
IETF is great for some things. I think the bitcoin URI scheme is being
registered with them.
However the process can take many years to get to an RFC, for something
relatively simple, not to mention there can be costs too
Given that crypto currencies are a relatively new field, I am unsure the
IETF has a wealth of expertise in this area, compared with the core devs
Maybe IETF is better to standardize some of the communications or
serialization components, but not so much the BIPs. Or perhaps some of the
BIPs can be written up as "Informational" rather than "Proposed Standard"
in the RFC format, and reviewed
I've followed quite a few FLOSS projects over the years. Overall, I've
been amazingly impressed with the BIP process (dont forget it's used in
other systems too -- python?). It seems an agile process, that strikes an
great balance between needed features, and documentation. I think that's
exactly what will continue bitcoin's momentum in the short to medium term.
>
> Martin
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a1133eaca5217fe04e93d03bf
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 21 October 2013 09:03, Martin Sustrik <span dir=3D"ltr"><<a h=
ref=3D"mailto:sustrik@250bpm.com" target=3D"_blank">sustrik@250bpm.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 21/10/13 08:52, Jean-Pa=
ul Kogelman wrote:<br>
> How about putting them into sub directories that map onto the status o=
f the BIP?<br>
><br>
> Reading BIP 1, that would make:<br>
><br>
> Accepted<br>
> Active<br>
> Draft<br>
> Deferred<br>
> Final<br>
> Rejected<br>
> Replaced<br>
> Withdrawn<br>
<br>
</div>Have it been considered to do this via IETF? The process there is<br>
hardened by 40 years of experience and 7000+ RFCs. Probably better than<br>
anything you can devise yourself.<br></blockquote><div><br></div><div>IETF =
is great for some things.=A0 I think the bitcoin URI scheme is being regist=
ered with them.<br><br>However the process can take many years to get to an=
RFC, for something relatively simple, not to mention there can be costs to=
o<br>
<br></div><div>Given that crypto currencies are a relatively new field, I a=
m unsure the IETF has a wealth of expertise in this area, compared with the=
core devs<br><br></div><div>Maybe IETF is better to standardize some of th=
e communications or serialization components, but not so much the BIPs.=A0 =
Or perhaps some of the BIPs can be written up as "Informational" =
rather than "Proposed Standard" in the RFC format, and reviewed<b=
r>
<br></div><div>I've followed quite a few FLOSS projects over the years.=
=A0 Overall, I've been amazingly impressed with the BIP process (dont f=
orget it's used in other systems too -- python?).=A0 It seems an agile =
process, that strikes an great balance between needed features, and documen=
tation.=A0 I think that's exactly what will continue bitcoin's mome=
ntum in the short to medium term.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Martin<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
October Webinars: Code for Performance<br>
Free Intel webinars can help you accelerate application performance.<br>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr=
om<br>
the latest Intel processors and coprocessors. See abstracts and register &g=
t;<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60135031&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60135031&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div>
--001a1133eaca5217fe04e93d03bf--
|
