* [Bitcoin-development] A critique of bitcoin open source community
@ 2013-10-19 16:38 Mitar
2013-10-19 16:50 ` Melvin Carvalho
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
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 [flat|nested] 28+ messages in thread* Re: [Bitcoin-development] A critique of bitcoin open source community 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 2013-10-19 22:33 ` Mike Hearn 2 siblings, 0 replies; 28+ messages in thread From: Melvin Carvalho @ 2013-10-19 16:50 UTC (permalink / raw) To: Mitar; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 9620 bytes --] On 19 October 2013 18:38, Mitar <mmitar@gmail•com> wrote: > Hi! > > Interesting read: > > > http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html > Im sympathetic to some of the points, but it seems slightly harsh. I do agree that we're lucky to have the excellent leadership of Gavin, who I think is a great role model. Perhaps the bitcoin community is at a size where it may benefit from a loose code of conduct. The ubuntu code of conduct has been excellent in this respect, in helping to grow that community: http://www.ubuntu.com/about/about-ubuntu/conduct [[ Ubuntu Code of Conduct v2.0 Community Ubuntu is about showing humanity to one another: the word itself captures the spirit of being human. We want a productive, happy and agile community that can welcome new ideas in a complex field, improve every process every year, and foster collaboration between groups with very different needs, interests and skills. We gain strength from diversity, and actively seek participation from those who enhance it. This code of conduct exists to ensure that diverse groups collaborate to mutual advantage and enjoyment. We will challenge prejudice that could jeopardise the participation of any person in the project. The Code of Conduct governs how we behave in public or in private whenever the project will be judged by our actions. We expect it to be honored by everyone who represents the project officially or informally, claims affiliation with the project, or participates directly. We strive to: Be considerate Our work will be used by other people, and we in turn will depend on the work of others. Any decision we take will affect users and colleagues, and we should consider them when making decisions. Be respectful Disagreement is no excuse for poor manners. We work together to resolve conflict, assume good intentions and do our best to act in an empathic fashion. We don't allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one. Take responsibility for our words and our actions We can all make mistakes; when we do, we take responsibility for them. If someone has been harmed or offended, we listen carefully and respectfully, and work to right the wrong. Be collaborative What we produce is a complex whole made of many parts, it is the sum of many dreams. Collaboration between teams that each have their own goal and vision is essential; for the whole to be more than the sum of its parts, each part must make an effort to understand the whole. Collaboration reduces redundancy and improves the quality of our work. Internally and externally, we celebrate good collaboration. Wherever possible, we work closely with upstream projects and others in the free software community to coordinate our efforts. We prefer to work transparently and involve interested parties as early as possible. Value decisiveness, clarity and consensus Disagreements, social and technical, are normal, but we do not allow them to persist and fester leaving others uncertain of the agreed direction. We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction. Ask for help when unsure Nobody is expected to be perfect in this community. Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful. Step down considerately When somebody leaves or disengages from the project, we ask that they do so in a way that minimises disruption to the project. They should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. Leadership, authority and responsibility We all lead by example, in debate and in action. We encourage new participants to feel empowered to lead, to take action, and to experiment when they feel innovation could improve the project. Leadership can be exercised by anyone simply by taking action, there is no need to wait for recognition when the opportunity to lead presents itself. Delegation from the top Responsibility for the project starts with the "benevolent dictator", who delegates specific responsibilities and the corresponding authority to a series of teams, councils and individuals, starting with the Community Council ("CC"). That Council or its delegated representative will arbitrate in any dispute. We are a meritocracy; we delegate decision making, governance and leadership from senior bodies to the most able and engaged candidates. Support for delegation is measured Nominations to the boards and councils are at the discretion of the Community Council, however the Community Council will seek the input of the community before confirming appointments. Leadership is not an award, right, or title; it is a privilege, a responsibility and a mandate. A leader will only retain their authority as long as they retain the support of those who delegated that authority to them. We value discussion, data and decisiveness We gather opinions, data and commitments from concerned parties before taking a decision. We expect leaders to help teams come to a decision in a reasonable time, to seek guidance or be willing to take the decision themselves when consensus is lacking, and to take responsibility for implementation. The poorest decision of all is no decision: clarity of direction has value in itself. Sometimes all the data are not available, or consensus is elusive. A decision must still be made. There is no guarantee of a perfect decision every time - we prefer to err, learn, and err less in future than to postpone action indefinitely. We recognise that the project works better when we trust the teams closest to a problem to make the decision for the project. If we learn of a decision that we disagree with, we can engage the relevant team to find common ground, and failing that, we have a governance structure that can review the decision. Ultimately, if a decision has been taken by the people responsible for it, and is supported by the project governance, it will stand. None of us expects to agree with every decision, and we value highly the willingness to stand by the project and help it deliver even on the occasions when we ourselves may prefer a different route. Open meritocracy We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence. Teamwork A leader's foremost goal is the success of the team. "A virtuoso is judged by their actions; a leader is judged by the actions of their team." A leader knows when to act and when to step back. They know when to delegate work, and when to take it upon themselves. Credit A good leader does not seek the limelight, but celebrates team members for the work they do. Leaders may be more visible than members of the team, good ones use that visibility to highlight the great work of others. Courage and considerateness Leadership occasionally requires bold decisions that will not be widely understood, consensual or popular. We value the courage to take such decisions, because they enable the project as a whole to move forward faster than we could if we required complete consensus. Nevertheless, boldness demands considerateness; take bold decisions, but do so mindful of the challenges they present for others, and work to soften the impact of those decisions on them. Communicating changes and their reasoning clearly and early on is as important as the implementation of the change itself. Conflicts of interest We expect leaders to be aware when they are conflicted due to employment or other projects they are involved in, and abstain or delegate decisions that may be seen to be self-interested. We expect that everyone who participates in the project does so with the goal of making life better for its users. When in doubt, ask for a second opinion. Perceived conflicts of interest are important to address; as a leader, act to ensure that decisions are credible even if they must occasionally be unpopular, difficult or favourable to the interests of one group over another. This Code is not exhaustive or complete. It is not a rulebook; it serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter. The Ubuntu Code of Conduct is licensed under the Creative Commons Attribution-Share Alike 3.0 license. You may re-use it for your own project, and modify it as you wish, just please allow others to use your modifications and give credit to the Ubuntu Project! ]] > > > Mitar > > -- > http://mitar.tnode.com/ > https://twitter.com/mitar_m > > > ------------------------------------------------------------------------------ > 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: 11137 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 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 2013-10-19 21:09 ` Mitar 2013-10-19 21:16 ` Jean-Paul Kogelman 2013-10-19 22:33 ` Mike Hearn 2 siblings, 2 replies; 28+ messages in thread From: Gregory Maxwell @ 2013-10-19 20:40 UTC (permalink / raw) To: Mitar; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 20:40 ` Gregory Maxwell @ 2013-10-19 21:09 ` Mitar 2013-10-19 21:16 ` Jean-Paul Kogelman 1 sibling, 0 replies; 28+ messages in thread From: Mitar @ 2013-10-19 21:09 UTC (permalink / raw) To: Gregory Maxwell; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 20:40 ` Gregory Maxwell 2013-10-19 21:09 ` Mitar @ 2013-10-19 21:16 ` Jean-Paul Kogelman 2013-10-19 22:29 ` Luke-Jr 1 sibling, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-19 21:16 UTC (permalink / raw) To: Gregory Maxwell; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 21:16 ` Jean-Paul Kogelman @ 2013-10-19 22:29 ` Luke-Jr 2013-10-19 23:20 ` Gregory Maxwell 2013-10-19 23:21 ` Jean-Paul Kogelman 0 siblings, 2 replies; 28+ messages in thread 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 22:29 ` Luke-Jr @ 2013-10-19 23:20 ` Gregory Maxwell 2013-10-19 23:35 ` Jean-Paul Kogelman 2013-10-20 10:00 ` Wladimir 2013-10-19 23:21 ` Jean-Paul Kogelman 1 sibling, 2 replies; 28+ messages in thread From: Gregory Maxwell @ 2013-10-19 23:20 UTC (permalink / raw) To: Luke-Jr; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 23:20 ` Gregory Maxwell @ 2013-10-19 23:35 ` Jean-Paul Kogelman 2013-10-19 23:57 ` Peter Todd 2013-10-20 10:00 ` Wladimir 1 sibling, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-19 23:35 UTC (permalink / raw) To: Gregory Maxwell; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 23:35 ` Jean-Paul Kogelman @ 2013-10-19 23:57 ` Peter Todd 2013-10-20 0:52 ` Jean-Paul Kogelman 0 siblings, 1 reply; 28+ messages in thread From: Peter Todd @ 2013-10-19 23:57 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 23:57 ` Peter Todd @ 2013-10-20 0:52 ` Jean-Paul Kogelman 2013-10-20 22:43 ` Peter Todd 0 siblings, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-20 0:52 UTC (permalink / raw) To: Peter Todd; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-20 0:52 ` Jean-Paul Kogelman @ 2013-10-20 22:43 ` Peter Todd 2013-10-20 23:11 ` Peter Todd 2013-10-21 0:27 ` Jeff Garzik 0 siblings, 2 replies; 28+ messages in thread From: Peter Todd @ 2013-10-20 22:43 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-20 22:43 ` Peter Todd @ 2013-10-20 23:11 ` Peter Todd 2013-10-21 0:27 ` Jeff Garzik 1 sibling, 0 replies; 28+ messages in thread From: Peter Todd @ 2013-10-20 23:11 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-20 22:43 ` Peter Todd 2013-10-20 23:11 ` Peter Todd @ 2013-10-21 0:27 ` Jeff Garzik 2013-10-21 6:25 ` Peter Todd 1 sibling, 1 reply; 28+ messages in thread From: Jeff Garzik @ 2013-10-21 0:27 UTC (permalink / raw) To: Peter Todd; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 0:27 ` Jeff Garzik @ 2013-10-21 6:25 ` Peter Todd 2013-10-21 6:40 ` Jean-Paul Kogelman 0 siblings, 1 reply; 28+ messages in thread From: Peter Todd @ 2013-10-21 6:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 6:25 ` Peter Todd @ 2013-10-21 6:40 ` Jean-Paul Kogelman 2013-10-21 6:43 ` Peter Todd 0 siblings, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-21 6:40 UTC (permalink / raw) To: Peter Todd; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 6:40 ` Jean-Paul Kogelman @ 2013-10-21 6:43 ` Peter Todd 2013-10-21 6:52 ` Jean-Paul Kogelman 0 siblings, 1 reply; 28+ messages in thread From: Peter Todd @ 2013-10-21 6:43 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 6:43 ` Peter Todd @ 2013-10-21 6:52 ` Jean-Paul Kogelman 2013-10-21 7:03 ` Martin Sustrik 0 siblings, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-21 6:52 UTC (permalink / raw) To: Peter Todd; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 6:52 ` Jean-Paul Kogelman @ 2013-10-21 7:03 ` Martin Sustrik 2013-10-21 7:07 ` Jean-Paul Kogelman 2013-10-21 9:36 ` Melvin Carvalho 0 siblings, 2 replies; 28+ messages in thread From: Martin Sustrik @ 2013-10-21 7:03 UTC (permalink / raw) To: Jean-Paul Kogelman, Peter Todd; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 7:03 ` Martin Sustrik @ 2013-10-21 7:07 ` Jean-Paul Kogelman 2013-10-21 7:28 ` Martin Sustrik 2013-10-21 9:36 ` Melvin Carvalho 1 sibling, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-21 7:07 UTC (permalink / raw) To: Martin Sustrik; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 7:07 ` Jean-Paul Kogelman @ 2013-10-21 7:28 ` Martin Sustrik 0 siblings, 0 replies; 28+ messages in thread From: Martin Sustrik @ 2013-10-21 7:28 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 7:03 ` Martin Sustrik 2013-10-21 7:07 ` Jean-Paul Kogelman @ 2013-10-21 9:36 ` Melvin Carvalho 2013-10-21 9:44 ` Arto Bendiken 1 sibling, 1 reply; 28+ messages in thread From: Melvin Carvalho @ 2013-10-21 9:36 UTC (permalink / raw) To: Martin Sustrik; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 9:36 ` Melvin Carvalho @ 2013-10-21 9:44 ` Arto Bendiken 2013-10-21 9:49 ` Jean-Paul Kogelman 0 siblings, 1 reply; 28+ messages in thread From: Arto Bendiken @ 2013-10-21 9:44 UTC (permalink / raw) To: Melvin Carvalho; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 9:44 ` Arto Bendiken @ 2013-10-21 9:49 ` Jean-Paul Kogelman 2013-10-21 10:21 ` Jorge Timón 0 siblings, 1 reply; 28+ messages in thread From: Jean-Paul Kogelman @ 2013-10-21 9:49 UTC (permalink / raw) To: Arto Bendiken; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-21 9:49 ` Jean-Paul Kogelman @ 2013-10-21 10:21 ` Jorge Timón 0 siblings, 0 replies; 28+ messages in thread From: Jorge Timón @ 2013-10-21 10:21 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 23:20 ` Gregory Maxwell 2013-10-19 23:35 ` Jean-Paul Kogelman @ 2013-10-20 10:00 ` Wladimir 1 sibling, 0 replies; 28+ messages in thread From: Wladimir @ 2013-10-20 10:00 UTC (permalink / raw) To: Gregory Maxwell; +Cc: 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 22:29 ` Luke-Jr 2013-10-19 23:20 ` Gregory Maxwell @ 2013-10-19 23:21 ` Jean-Paul Kogelman 2013-10-19 23:22 ` Jean-Paul Kogelman 1 sibling, 1 reply; 28+ messages in thread 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 2013-10-19 23:21 ` Jean-Paul Kogelman @ 2013-10-19 23:22 ` Jean-Paul Kogelman 0 siblings, 0 replies; 28+ messages in thread 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 [flat|nested] 28+ messages in thread
* Re: [Bitcoin-development] A critique of bitcoin open source community 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 @ 2013-10-19 22:33 ` Mike Hearn 2 siblings, 0 replies; 28+ messages in thread From: Mike Hearn @ 2013-10-19 22:33 UTC (permalink / raw) To: Mitar; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 792 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 967 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2013-10-21 10:21 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2013-10-19 21:09 ` Mitar 2013-10-19 21:16 ` Jean-Paul Kogelman 2013-10-19 22:29 ` Luke-Jr 2013-10-19 23:20 ` Gregory Maxwell 2013-10-19 23:35 ` Jean-Paul Kogelman 2013-10-19 23:57 ` Peter Todd 2013-10-20 0:52 ` Jean-Paul Kogelman 2013-10-20 22:43 ` Peter Todd 2013-10-20 23:11 ` Peter Todd 2013-10-21 0:27 ` Jeff Garzik 2013-10-21 6:25 ` Peter Todd 2013-10-21 6:40 ` Jean-Paul Kogelman 2013-10-21 6:43 ` Peter Todd 2013-10-21 6:52 ` Jean-Paul Kogelman 2013-10-21 7:03 ` Martin Sustrik 2013-10-21 7:07 ` Jean-Paul Kogelman 2013-10-21 7:28 ` Martin Sustrik 2013-10-21 9:36 ` Melvin Carvalho 2013-10-21 9:44 ` Arto Bendiken 2013-10-21 9:49 ` Jean-Paul Kogelman 2013-10-21 10:21 ` Jorge Timón 2013-10-20 10:00 ` Wladimir 2013-10-19 23:21 ` Jean-Paul Kogelman 2013-10-19 23:22 ` Jean-Paul Kogelman 2013-10-19 22:33 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox