A critique of bitcoin open source community

A critique of bitcoin open source community
2013-10-19 16:50 ` Melvin Carvalho
                   ` (2 more replies)
  
From: Mitar @ 2013-10-19 16:38 UTC (permalink / raw)
  To: bitcoin-development

Hi!

Interesting read:

http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m



 permalink raw reply	[|nested]
2013-10-19 16:50 ` 
                   ` 
  
From: Mitar @ 2013-10-19 16:38 UTC (permalink / raw)
  To: bitcoin-development

Hi!

Interesting read:

http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m



 permalink raw reply	[|nested]
2013-10-19 16:38 [Bitcoin-development] A critique of bitcoin open source community Mitar
  2013-10-19 16:50 ` Melvin Carvalho

  2013-10-19 21:09   ` Mitar
  2013-10-19 21:16   ` Jean-Paul Kogelman
  2013-10-19 22:33 ` Mike Hearn
  
From: Gregory Maxwell @ 2013-10-19 20:40 UTC (permalink / raw)
  To: Mitar;  Bitcoin Development

On Sat, Oct 19, 2013 at 9:38 AM, Mitar <mmitar@gmail•com> wrote:
> Hi!
> Interesting read:
> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html

Hopefully Nick will show up someplace and offer some specific pointers
to where we failed him.

The only interaction I can find from him on IRC is in #bitcoin, rather
than #bitcoin-dev:

--- Day changed Mon Sep 16 2013
11:45 < csmpls> Hi, I'm interested in contributing to the official
bitcoin project. Is there a mailing list I can join?
11:46 < neo2> csmpls, contributing how?
11:47 < csmpls> neo2 - probably start by approaching a low priority
issue like this one https://github.com/bitcoin/bitcoin/issues/2545
11:48 < michagogo> csmpls: There *is* a mailing list
11:48 < michagogo> ;;google bitcoin-dev mailing list
11:48 <@gribble> SourceForge.net: Bitcoin: bitcoin-development:
<http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>;
Bitcoin-development Info
11:48 < csmpls> Great, thanks.
11:48 < michagogo> I don't know how active it is, though
11:49 < michagogo> There's also the #bitcoin-dev channel

I got involved with Bitcoin without previously interacting with other
contributors (AFAIK) and maybe things have changed in ways invisibly
to me. But I don't think so. Michagogo, who was answering there, is a
newer participant and I don't think anyone knows him from anywhere.
Certainly if things have become less welcome to new participants that
would be bad.

I can point out a number of other recent contributors who, as far as I
can tell, just showed up and stared contributing.  But I don't think
that the existence of exceptions is sufficiently strong evidence that
there isn't a problem.

The specific complaints I can extract from that article are:

"I wasn't even allowed to edit the wiki"

I'm confused about this, if he's referring to en.bitcoin.it.  Editing
it is open to anyone who is willing to pay the 0.01
(https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
a policy set by the bitcoin development community, though I'm not sure
that its a terrible one. I've both paid it on behalf of other users
and made edits on behalf of people who didn't want to go to it.  At
least relative to some policy which requires actual approval the
payment antispam is at least open to anyone with Bitcoin.

"My IRC questions about issues on the github page were never answered"

Without a nick I'm unable to find more than the above, unfortunately.
So I don't yet know what we need to improve there.

"#bitcoin-dev would rather talk about conspiracies, or about
destroying other cryptocurrencies"

I've been pretty aggressive about punting out offtopic conversation
from #bitcoin-dev lately. Enough that I worried that my actions would
be the inspiration for this complaint. Much of the time discussion
like that is brought in and primarily continued by people who are not
active in the development community at all, but deflecting it to other
challenge without creating a hostile environment (or one that merely
feels hostile to new people) is hard.  Nicks comments themselves may
be a useful thing for me to show to people in the future on that
point.

"Bitcoiners are a bunch of paranoid, anti-authoritarian nutjobs"

I actually don't think that this stereotype accurately reflects the
development community. (In fact, I personally enjoy the great sport of
being called a statist by some of these aformentioned jutjobs, but
none of them are developers). On his other article Nick also asserts
"Most contributors hide their identities", but this is factually
untrue as far as I can tell. (In that same article he writes,
"Bitcoin's core code is written in Typescript, which is compiled into
C++"…)

"I looked at the many items sitting in pull request purgatory"

Many of the long standing pull requests are actually created by people
with direct commit access.  We use a model which has a relatively long
pipeline, a fact which I think is justified by the safety
criticialness of the software and our current shortages of active
review. Hopefully long term motion towards increased codebase
modularity will allow faster merging of "safe" changes.

But I suspect there will always be a backlog, at least of "unsafe" changes.

Which brings me to,

"I didn't even know what I had to do"

Above all, I think the most important takeaway from this is that we
need to have better introductory materials.

One obvious place to put them would be
http://bitcoin.org/en/development  but the IRC question makes me
believe that Nick hadn't actually found that page, it's a little
buried.



 permalink raw reply	[|nested]
2013-10-19 20:40 ` Gregory Maxwell

  2013-10-19 21:16   ` Jean-Paul Kogelman
  
From: Mitar @ 2013-10-19 21:09 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development

Hi!

Gregory, thank you for your time and answers. Just maybe to clarify
where Nick is coming from, there are two previous articles:

http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign1.html
http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign2.html


Mitar

On Sat, Oct 19, 2013 at 1:40 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Sat, Oct 19, 2013 at 9:38 AM, Mitar <mmitar@gmail•com> wrote:
>> Hi!
>> Interesting read:
>> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
>
> Hopefully Nick will show up someplace and offer some specific pointers
> to where we failed him.
>
> The only interaction I can find from him on IRC is in #bitcoin, rather
> than #bitcoin-dev:
>
> --- Day changed Mon Sep 16 2013
> 11:45 < csmpls> Hi, I'm interested in contributing to the official
> bitcoin project. Is there a mailing list I can join?
> 11:46 < neo2> csmpls, contributing how?
> 11:47 < csmpls> neo2 - probably start by approaching a low priority
> issue like this one https://github.com/bitcoin/bitcoin/issues/2545
> 11:48 < michagogo> csmpls: There *is* a mailing list
> 11:48 < michagogo> ;;google bitcoin-dev mailing list
> 11:48 <@gribble> SourceForge.net: Bitcoin: bitcoin-development:
> <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>;
> Bitcoin-development Info
> 11:48 < csmpls> Great, thanks.
> 11:48 < michagogo> I don't know how active it is, though
> 11:49 < michagogo> There's also the #bitcoin-dev channel
>
> I got involved with Bitcoin without previously interacting with other
> contributors (AFAIK) and maybe things have changed in ways invisibly
> to me. But I don't think so. Michagogo, who was answering there, is a
> newer participant and I don't think anyone knows him from anywhere.
> Certainly if things have become less welcome to new participants that
> would be bad.
>
> I can point out a number of other recent contributors who, as far as I
> can tell, just showed up and stared contributing.  But I don't think
> that the existence of exceptions is sufficiently strong evidence that
> there isn't a problem.
>
> The specific complaints I can extract from that article are:
>
> "I wasn't even allowed to edit the wiki"
>
> I'm confused about this, if he's referring to en.bitcoin.it.  Editing
> it is open to anyone who is willing to pay the 0.01
> (https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
> a policy set by the bitcoin development community, though I'm not sure
> that its a terrible one. I've both paid it on behalf of other users
> and made edits on behalf of people who didn't want to go to it.  At
> least relative to some policy which requires actual approval the
> payment antispam is at least open to anyone with Bitcoin.
>
> "My IRC questions about issues on the github page were never answered"
>
> Without a nick I'm unable to find more than the above, unfortunately.
> So I don't yet know what we need to improve there.
>
> "#bitcoin-dev would rather talk about conspiracies, or about
> destroying other cryptocurrencies"
>
> I've been pretty aggressive about punting out offtopic conversation
> from #bitcoin-dev lately. Enough that I worried that my actions would
> be the inspiration for this complaint. Much of the time discussion
> like that is brought in and primarily continued by people who are not
> active in the development community at all, but deflecting it to other
> challenge without creating a hostile environment (or one that merely
> feels hostile to new people) is hard.  Nicks comments themselves may
> be a useful thing for me to show to people in the future on that
> point.
>
> "Bitcoiners are a bunch of paranoid, anti-authoritarian nutjobs"
>
> I actually don't think that this stereotype accurately reflects the
> development community. (In fact, I personally enjoy the great sport of
> being called a statist by some of these aformentioned jutjobs, but
> none of them are developers). On his other article Nick also asserts
> "Most contributors hide their identities", but this is factually
> untrue as far as I can tell. (In that same article he writes,
> "Bitcoin's core code is written in Typescript, which is compiled into
> C++"…)
>
> "I looked at the many items sitting in pull request purgatory"
>
> Many of the long standing pull requests are actually created by people
> with direct commit access.  We use a model which has a relatively long
> pipeline, a fact which I think is justified by the safety
> criticialness of the software and our current shortages of active
> review. Hopefully long term motion towards increased codebase
> modularity will allow faster merging of "safe" changes.
>
> But I suspect there will always be a backlog, at least of "unsafe" changes.
>
> Which brings me to,
>
> "I didn't even know what I had to do"
>
> Above all, I think the most important takeaway from this is that we
> need to have better introductory materials.
>
> One obvious place to put them would be
> http://bitcoin.org/en/development  but the IRC question makes me
> believe that Nick hadn't actually found that page, it's a little
> buried.



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m



 permalink raw reply	[|nested]
2013-10-19 20:40 ` Gregory Maxwell
  2013-10-19 21:09   ` Mitar

  2013-10-19 22:29     ` Luke-Jr
  
From: Jean-Paul Kogelman @ 2013-10-19 21:16 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On 2013-10-19, at 1:40 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> 
> "I wasn't even allowed to edit the wiki"
> 
> I'm confused about this, if he's referring to en.bitcoin.it.  Editing
> it is open to anyone who is willing to pay the 0.01
> (https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
> a policy set by the bitcoin development community, though I'm not sure
> that its a terrible one. I've both paid it on behalf of other users
> and made edits on behalf of people who didn't want to go to it.  At
> least relative to some policy which requires actual approval the
> payment antispam is at least open to anyone with Bitcoin.


I have a question regarding this part. I wrote a BIP for base 58 encoding / encryption of BIP 32 root keys. The BIP page states that we shouldn't add to this list ourselves, but should contact you for a BIP number. I have contacted you a couple times on bitcointalk for a BIP number, but haven't received a response (or do those requests explicitly have to go to your email address)? 

Proposal in question: https://bitcointalk.org/index.php?topic=258678.0


Cheers,

jp


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-19 21:16   ` Jean-Paul Kogelman

  2013-10-19 23:20       ` Gregory Maxwell
  2013-10-19 23:21       ` Jean-Paul Kogelman
  
From: Luke-Jr @ 2013-10-19 22:29 UTC (permalink / raw)
  To: bitcoin-development

On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
> I have a question regarding this part. I wrote a BIP for base 58 encoding /
> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
> to this list ourselves, but should contact you for a BIP number. I have
> contacted you a couple times on bitcointalk for a BIP number, but haven't
> received a response (or do those requests explicitly have to go to your
> email address)?

See BIP 1 for the process.. proposals go to this mailing list first.

Luke



 permalink raw reply	[|nested]
2013-10-19 16:38 [Bitcoin-development] A critique of bitcoin open source community Mitar
  2013-10-19 16:50 ` Melvin Carvalho
  2013-10-19 20:40 ` Gregory Maxwell

  
From: Mike Hearn @ 2013-10-19 22:33 UTC ( / )
  To: Mitar;  Bitcoin Dev



I was hoping to see something interesting and useful, but all I saw was
absurd ranting. Example quote:

It is not known where bitcoin contributors are based. Gavin Andersson, a
major contributor, is a well-known South African
anarchist/crypto-libertarian. Most contributors hide their identities.
I don't know who this guy is or why anyone should care what he thinks, but
I doubt any of us have time for someone who can't even be bothered spelling
Gavin's name correctly, thinks he is South African or would describe him as
an anarchist.

Open source development can be intimidating and brutal at times, it's
probably one factor that causes the massive gender skew. But many pages
have been written on that topic, here is probably not the right place to
thrash it out for the umpteenth time.
2013-10-19 22:29     ` Luke-Jr

  2013-10-19 23:35         ` Jean-Paul Kogelman
  2013-10-20 10:00         ` Wladimir
  2013-10-19 23:21       ` Jean-Paul Kogelman
  
From: Gregory Maxwell @ 2013-10-19 23:20 UTC (permalink / raw)
  To: Luke-Jr;  Bitcoin Development

On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr•org> wrote:
> See BIP 1 for the process.. proposals go to this mailing list first.

FWIW, he did post to the mailing list and he got an underwhelming response:

http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development

When I responded to him on BCT I said "I was about to suggest you hit
the mailing list for some initial comments first— but I see you've
done that. I'll issue a number in a couple days once there has been a
little chance for some discussion.".

Since much discussion didn't materialize I went and gave it a
technical once over, posting to the forum.  In hindsight, I probably
should have also posted my review to the mailing list, which might
have served to restart some additional discussion.



 permalink raw reply	[|nested]
2013-10-19 22:29     ` Luke-Jr
  2013-10-19 23:20       ` Gregory Maxwell

  2013-10-19 23:22         ` Jean-Paul Kogelman
  
From: Jean-Paul Kogelman @ 2013-10-19 23:21 UTC (permalink / raw)
  To: Luke-Jr, bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

I submitted the proposal to the mailing list on July 19, 2003.

 
On 2013-10-19, at 3:29 PM, Luke-Jr <luke@dashjr•org> wrote:

> On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
>> I have a question regarding this part. I wrote a BIP for base 58 encoding /
>> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
>> to this list ourselves, but should contact you for a BIP number. I have
>> contacted you a couple times on bitcointalk for a BIP number, but haven't
>> received a response (or do those requests explicitly have to go to your
>> email address)?
> 
> See BIP 1 for the process.. proposals go to this mailing list first.
> 
> Luke

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-19 23:21       ` Jean-Paul Kogelman

  
From: Jean-Paul Kogelman @ 2013-10-19 23:22 UTC (permalink / raw)
  To: Luke-Jr, bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]


On 2013-10-19, at 4:21 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:

> I submitted the proposal to the mailing list on July 19, 2003.

That would be 2013. sorry.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-19 23:20       ` Gregory Maxwell

  2013-10-19 23:57           ` Peter Todd
  2013-10-20 10:00         ` Wladimir
  
From: Jean-Paul Kogelman @ 2013-10-19 23:35 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]


On 2013-10-19, at 4:20 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr•org> wrote:
>> See BIP 1 for the process.. proposals go to this mailing list first.
> 
> FWIW, he did post to the mailing list and he got an underwhelming response:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development

Although I agree that the number of responses on the mailing list was minimal, they were overall positive. Mike voiced concerns about not having a date field to limit the rescan when importing, but other than that, most of the discussion was on bitcointalk. I've made a number of revisions, trying to incorporate the suggestions that were given. Obviously this doesn't mean that the draft is final (specifically the KDF's that can be used is still up for debate and having 29 undefined ID's means it's reasonably future proof).

Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.


jp

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-19 23:35         ` Jean-Paul Kogelman

  2013-10-20  0:52             ` Jean-Paul Kogelman
  
From: Peter Todd @ 2013-10-19 23:57 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

On Sat, Oct 19, 2013 at 04:35:13PM -0700, Jean-Paul Kogelman wrote:
> > On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr•org> wrote:
> >> See BIP 1 for the process.. proposals go to this mailing list first.
> > 
> > FWIW, he did post to the mailing list and he got an underwhelming response:
> > 
> > http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development
> 
> Although I agree that the number of responses on the mailing list was minimal, they were overall positive. Mike voiced concerns about not having a date field to limit the rescan when importing, but other than that, most of the discussion was on bitcointalk. I've made a number of revisions, trying to incorporate the suggestions that were given. Obviously this doesn't mean that the draft is final (specifically the KDF's that can be used is still up for debate and having 29 undefined ID's means it's reasonably future proof).
> 
> Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.

Having it on the BIP page *does* make it more official, at least the way
we've been using the BIP page, which is to filter out the proposals that
haven't gotten much support at all. (or maybe are just controversial)

FWIW I myself haven't pushed hard for getting an "official" BIP number
for my draft NODE_BLOOM BIP, even though I've got support from most of
the dev team on the pull-request:
https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
where I could get one assigned - Litecoin for instance has made that
change - but really I just see that as a formality; that it's still a
controversial idea is much more relevant.

In any case I don't see any working code in your email, I'd suggest
writing some. You're BIP would be much more likely to be accepted if you
were more involved in wallet development.

-- 
'peter'[:-1]@petertodd.org
000000000000000ad5e0cbc9438203b9cf2dcae776774f59575e38fcefa802ed

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2013-10-19 23:57           ` Peter Todd

  2013-10-20 22:43               ` Peter Todd
  
From: Jean-Paul Kogelman @ 2013-10-20  0:52 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]


>> Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.
> 
> Having it on the BIP page *does* make it more official, at least the way
> we've been using the BIP page, which is to filter out the proposals that
> haven't gotten much support at all. (or maybe are just controversial)

Interesting. The main reason I wrote my proposal was because the only proposal that came close to covering the same area was BIP 39, which at that time had 2 paragraphs of text (although admittedly did link to a text file off site where the draft was being developed). And currently there are 2 proposals that have numbers allocated but are empty (BIP 40 and 41) with no references to the development or discussion.

I appreciate the fact that acceptance of proposals on the BIP page are more strict, but it may be desirable to have the enforcement be more uniform. Also, BIP 38 is gaining more acceptance out in the community (many sites support the import of these keys and a growing number of paper wallet sites / coin / card vendors are offering it as an option), yet it's still missing from the BIP list, which seems to me a bit counter to the arguments given about community acceptance.

> FWIW I myself haven't pushed hard for getting an "official" BIP number
> for my draft NODE_BLOOM BIP, even though I've got support from most of
> the dev team on the pull-request:
> https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
> where I could get one assigned - Litecoin for instance has made that
> change - but really I just see that as a formality; that it's still a
> controversial idea is much more relevant.


> In any case I don't see any working code in your email, I'd suggest
> writing some. You're BIP would be much more likely to be accepted if you
> were more involved in wallet development.

Good point. I'm developing my own client (which has the code up and running, with unit tests), but I'm not ready to release it just yet until I've got all the client's alpha features working. Would putting contact information there so people can ask for the relevant code be sufficient until I have my client up on github?


jp



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-19 23:20       ` Gregory Maxwell
  2013-10-19 23:35         ` Jean-Paul Kogelman

  
From: Wladimir @ 2013-10-20 10:00 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Sun, Oct 20, 2013 at 1:20 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> Since much discussion didn't materialize I went and gave it a
> technical once over, posting to the forum.


At least I now understand where he got the idea of bitcoin devs being a
bunch of paranoid, anti-authoritarian nutjobs :-) I've been on a lot of
forums in my life but never encountered one with such selfish, unhelpful,
trolling, complaining sods (well maybe apart from 15-year old gamers).

Nick couldn't have got that idea from discussion on this mailing list or
#bitcoin-dev. Please don't send anyone to that jungle. People shouldn't get
the idea that that the forum is our development community, or even endorsed
by the devs.

As for the real developer community, I haven't noticed so much
unfriendliness or closedness. But the core devs are with very few people
(certainly compared to the number of users) and reviewing and testing takes
time so pull requests, proposals and such can linger for a while. Which can
indeed be frustrating.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1710 bytes --]

 permalink raw reply	[|nested]
2013-10-20  0:52             ` Jean-Paul Kogelman

  2013-10-20 23:11                 ` Peter Todd
  2013-10-21  0:27                 ` Jeff Garzik
  
From: Peter Todd @ 2013-10-20 22:43 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Sat, Oct 19, 2013 at 05:52:49PM -0700, Jean-Paul Kogelman wrote:
> Interesting. The main reason I wrote my proposal was because the only proposal that came close to covering the same area was BIP 39, which at that time had 2 paragraphs of text (although admittedly did link to a text file off site where the draft was being developed). And currently there are 2 proposals that have numbers allocated but are empty (BIP 40 and 41) with no references to the development or discussion.
> 
> I appreciate the fact that acceptance of proposals on the BIP page are more strict, but it may be desirable to have the enforcement be more uniform. Also, BIP 38 is gaining more acceptance out in the community (many sites support the import of these keys and a growing number of paper wallet sites / coin / card vendors are offering it as an option), yet it's still missing from the BIP list, which seems to me a bit counter to the arguments given about community acceptance.

No, that just means the authors of BIP 38 know community acceptance is
the most important thing; BIP numbers are secondary.

FWIW I think that BIP's should have been done as a github repository,
allowing for dealing with this stuff transparently as a pull-request.
It'd also be useful to handle BIP's that way to make it easy to archive
them, update them, and keep a log of what and why they were updated.
Just put them in markdown format, which is pretty much feature
equivalent to the wiki now that markdown supports images.

> > FWIW I myself haven't pushed hard for getting an "official" BIP number
> > for my draft NODE_BLOOM BIP, even though I've got support from most of
> > the dev team on the pull-request:
> > https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
> > where I could get one assigned - Litecoin for instance has made that
> > change - but really I just see that as a formality; that it's still a
> > controversial idea is much more relevant.
> 
> 
> > In any case I don't see any working code in your email, I'd suggest
> > writing some. You're BIP would be much more likely to be accepted if you
> > were more involved in wallet development.
> 
> Good point. I'm developing my own client (which has the code up and running, with unit tests), but I'm not ready to release it just yet until I've got all the client's alpha features working. Would putting contact information there so people can ask for the relevant code be sufficient until I have my client up on github?

No, just put the client up on github. If you think actually using it is
dangerous, just delibrately make it hard to use for people who shouldn't
be using it. Leave out compilation documentation for instance, or make
it check that it's on testnet first and refuse to run if it isn't.

Pond for instance doesn't make binaries available:
https://pond.imperialviolet.org/ IIRC only recently have they provided a
makefile.

-- 
'peter'[:-1]@petertodd.org
000000000000000b647feda1820ad95b2ea9efb742e9087b022bd3d37530dc06

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2013-10-20 22:43               ` Peter Todd

  2013-10-21  0:27                 ` Jeff Garzik
  
From: Peter Todd @ 2013-10-20 23:11 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On Sun, Oct 20, 2013 at 06:43:16PM -0400, Peter Todd wrote:
> FWIW I think that BIP's should have been done as a github repository,
> allowing for dealing with this stuff transparently as a pull-request.
> It'd also be useful to handle BIP's that way to make it easy to archive
> them, update them, and keep a log of what and why they were updated.
> Just put them in markdown format, which is pretty much feature
> equivalent to the wiki now that markdown supports images.

Figures, I'm told that's exactly how they were first done -
https://github.com/genjix/bips - only people found it inconvenient and
used the wiki instead.

Pathetic IMO for standards, but it wouldn't exactly be the first time
I've seen strong resistance to using revision control. (I quite
literally work with rocket scientists/satellite engineers who can't be
convinced to use it)

I dunno, maybe something using git submodules or subtrees - letting the
individual BIP "owners" make changes frequently until they're happy -
might have more social acceptance.

-- 
'peter'[:-1]@petertodd.org
000000000000000aff52788645172e4acca1d9fc9387ebe4074d9ce275273b44

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2013-10-20 22:43               ` Peter Todd
  2013-10-20 23:11                 ` Peter Todd

  2013-10-21  6:25                   ` Peter Todd
  
From: Jeff Garzik @ 2013-10-21  0:27 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Development

On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd•org> wrote:
> FWIW I think that BIP's should have been done as a github repository,
> allowing for dealing with this stuff transparently as a pull-request.
> It'd also be useful to handle BIP's that way to make it easy to archive
> them, update them, and keep a log of what and why they were updated.
> Just put them in markdown format, which is pretty much feature
> equivalent to the wiki now that markdown supports images.

Agreed -- let's do it.  I nominate you to do the conversion, and we'll
put it up at github.com/bitcoin/bips.git.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2013-10-21  0:27                 ` Jeff Garzik

  2013-10-21  6:40                     ` Jean-Paul Kogelman
  
From: Peter Todd @ 2013-10-21  6:25 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Sun, Oct 20, 2013 at 08:27:47PM -0400, Jeff Garzik wrote:
> On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd•org> wrote:
> > FWIW I think that BIP's should have been done as a github repository,
> > allowing for dealing with this stuff transparently as a pull-request.
> > It'd also be useful to handle BIP's that way to make it easy to archive
> > them, update them, and keep a log of what and why they were updated.
> > Just put them in markdown format, which is pretty much feature
> > equivalent to the wiki now that markdown supports images.
> 
> Agreed -- let's do it.  I nominate you to do the conversion, and we'll
> put it up at github.com/bitcoin/bips.git.

Done: https://github.com/petertodd/bips/

GitHub supports MediaWiki these days, so just directly copying from
'View Source' in the bitcoin.it wiki worked pretty well; I archived the
exact text of BIP. Tables, images and math is all supported by github
and look fine, although github doesn't seem to support coloration in
tables. Users wishing to edit their pull-req's or create new ones can do
so easily by forking the repository - they can see their changes as they
go in GitHub.

I've probably missed some stuff re: formatting, and I haven't changed
any of the submission guideline text in bip 1 yet, but that's probably
90% of the work done.

-- 
'peter'[:-1]@petertodd.org
000000000000000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2013-10-21  6:25                   ` Peter Todd

  2013-10-21  6:43                       ` Peter Todd
  
From: Jean-Paul Kogelman @ 2013-10-21  6:40 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]


I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 

On 2013-10-20, at 11:25 PM, Peter Todd <pete@petertodd•org> wrote:

> On Sun, Oct 20, 2013 at 08:27:47PM -0400, Jeff Garzik wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd•org> wrote:
>>> FWIW I think that BIP's should have been done as a github repository,
>>> allowing for dealing with this stuff transparently as a pull-request.
>>> It'd also be useful to handle BIP's that way to make it easy to archive
>>> them, update them, and keep a log of what and why they were updated.
>>> Just put them in markdown format, which is pretty much feature
>>> equivalent to the wiki now that markdown supports images.
>> 
>> Agreed -- let's do it.  I nominate you to do the conversion, and we'll
>> put it up at github.com/bitcoin/bips.git.
> 
> Done: https://github.com/petertodd/bips/
> 
> GitHub supports MediaWiki these days, so just directly copying from
> 'View Source' in the bitcoin.it wiki worked pretty well; I archived the
> exact text of BIP. Tables, images and math is all supported by github
> and look fine, although github doesn't seem to support coloration in
> tables. Users wishing to edit their pull-req's or create new ones can do
> so easily by forking the repository - they can see their changes as they
> go in GitHub.
> 
> I've probably missed some stuff re: formatting, and I haven't changed
> any of the submission guideline text in bip 1 yet, but that's probably
> 90% of the work done.
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 000000000000000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-21  6:40                     ` Jean-Paul Kogelman

  2013-10-21  6:52                         ` Jean-Paul Kogelman
  
From: Peter Todd @ 2013-10-21  6:43 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Sun, Oct 20, 2013 at 11:40:26PM -0700, Jean-Paul Kogelman wrote:
> 
> I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 

Sure, I think Jeff mentioned the idea of a specific drafts/ directory
within the repository. (could also do a rejected/)

Less of an issue in some ways when it's all in git - just point people
to your bips fork.

-- 
'peter'[:-1]@petertodd.org
00000000000000099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

 permalink raw reply	[|nested]
2013-10-21  6:43                       ` Peter Todd

  2013-10-21  7:03                           ` Martin Sustrik
  
From: Jean-Paul Kogelman @ 2013-10-21  6:52 UTC (permalink / raw)
  To: Peter Todd;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

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

Would that place NODE_BLOOM and BIP 38 in Deferred?


On 2013-10-20, at 11:43 PM, Peter Todd <pete@petertodd•org> wrote:

> On Sun, Oct 20, 2013 at 11:40:26PM -0700, Jean-Paul Kogelman wrote:
>> 
>> I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 
> 
> Sure, I think Jeff mentioned the idea of a specific drafts/ directory
> within the repository. (could also do a rejected/)
> 
> Less of an issue in some ways when it's all in git - just point people
> to your bips fork.
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 00000000000000099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-21  6:52                         ` Jean-Paul Kogelman

  2013-10-21  7:07                             ` Jean-Paul Kogelman
  2013-10-21  9:36                             ` Melvin Carvalho
  
From: Martin Sustrik @ 2013-10-21  7:03 UTC (permalink / raw)
  To: Jean-Paul Kogelman, Peter Todd;  Bitcoin Development

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.

Martin



 permalink raw reply	[|nested]
2013-10-21  7:03                           ` Martin Sustrik

  2013-10-21  7:28                               ` Martin Sustrik
  2013-10-21  9:36                             ` Melvin Carvalho
  
From: Jean-Paul Kogelman @ 2013-10-21  7:07 UTC (permalink / raw)
  To: Martin Sustrik;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

The list comes from BIP 1.

On 2013-10-21, at 12:03 AM, 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.
> 
> Martin


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-21  7:07                             ` Jean-Paul Kogelman

  
From: Martin Sustrik @ 2013-10-21  7:28 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

On 21/10/13 09:07, Jean-Paul Kogelman wrote:
> The list comes from BIP 1.

Sorry, I haven't meant you personally. It was just a generic question 
about using existing process instead of inventing a new one on the go.

>> 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.
>>
>> Martin
>




 permalink raw reply	[|nested]
2013-10-21  7:03                           ` Martin Sustrik
  2013-10-21  7:07                             ` Jean-Paul Kogelman

  2013-10-21  9:44                               ` Arto Bendiken
  
From: Melvin Carvalho @ 2013-10-21  9:36 UTC (permalink / raw)
  To: Martin Sustrik;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3244 bytes --]

 permalink raw reply	[|nested]
2013-10-21  9:36                             ` Melvin Carvalho

  2013-10-21  9:49                                 ` Jean-Paul Kogelman
  
From: Arto Bendiken @ 2013-10-21  9:44 UTC (permalink / raw)
  To: Melvin Carvalho;  Bitcoin Development

On Mon, Oct 21, 2013 at 11:36 AM, Melvin Carvalho
<melvincarvalho@gmail•com> wrote:
>
> 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.

Indeed. The BIP analogs that immediately come to mind would be the
enhancement proposal processes for Python, XMPP, and BitTorrent:

http://www.python.org/dev/peps/
http://xmpp.org/xmpp-protocols/xmpp-extensions/
http://www.bittorrent.org/beps/bep_0000.html

-- 
Arto Bendiken | @bendiken | http://ar.to



 permalink raw reply	[|nested]
2013-10-21  9:44                               ` Arto Bendiken

  2013-10-21 10:21                                   ` Jorge Timón
  
From: Jean-Paul Kogelman @ 2013-10-21  9:49 UTC (permalink / raw)
  To: Arto Bendiken;  Bitcoin Development


[-- Attachment #1.1: Type: text/plain, Size: 431 bytes --]


On 2013-10-21, at 2:44 AM, Arto Bendiken <arto@bendiken•net> wrote:

> 
> Indeed. The BIP analogs that immediately come to mind would be the
> enhancement proposal processes for Python, XMPP, and BitTorrent:

Bitcoin's BIP process is directly based off of Python's PEP process. 

Quote from BIP 1, History:

This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified.

[-- Attachment #1.2: Type: text/html, Size: 953 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2013-10-21  9:49                                 ` Jean-Paul Kogelman

  
From: Jorge Timón @ 2013-10-21 10:21 UTC (permalink / raw)
  To: Jean-Paul Kogelman;  Bitcoin Development

I think it's great to move BIPs to github.
I also agree with the states -> directories mapping.
Git manages moved files well.


On 10/21/13, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
> On 2013-10-21, at 2:44 AM, Arto Bendiken <arto@bendiken•net> wrote:
>
>>
>> Indeed. The BIP analogs that immediately come to mind would be the
>> enhancement proposal processes for Python, XMPP, and BitTorrent:
>
> Bitcoin's BIP process is directly based off of Python's PEP process.
>
> Quote from BIP 1, History:
>
> This document was derived heavily from Python's PEP-0001. In many places
> text was simply copied and modified.
>


-- 
Jorge Timón

http://freico.in/



 permalink raw reply	[|nested]