From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 01A0DAE7 for ; Sun, 28 Jun 2015 19:05:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5FABB12C for ; Sun, 28 Jun 2015 19:05:22 +0000 (UTC) Received: by pactm7 with SMTP id tm7so93344490pac.2 for ; Sun, 28 Jun 2015 12:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type; bh=BnGzuW46oAzUn3nDJH0nJlE9y6VmlGvBsprO2e068aY=; b=ipee6XcdouJsnQLmHmgfarbK99n6HzMHSkS2OqLx6zbrpXMh3/cOAv9Ft/6orWPckl PIO87uTB99B/ovcs5R11ue5T8bayCogE8qqGsHpT6aIyjH8d0+vRFMDThAsdYC5qYzlj TJc6yOoIbAqoA0M33ycorJ2cyjkJRgDtuJGE4M6SOOUC1LA2ofvOgOJtWC8uNzXYuE16 jkwe3F4aIcQ9UQD3X2MPEaHrBEwnE5xWr2zLHvW6VIp/WWSK5Z7+owDDgK4mbw8+V3NJ dK5UtbjYVoWS14/UfnqeMUxMXUlAgCNvt2OmtU89Sp/KUWVpUXFwtQdGaLSUCNTEO6nQ MAqA== X-Received: by 10.70.52.1 with SMTP id p1mr23958119pdo.113.1435518322078; Sun, 28 Jun 2015 12:05:22 -0700 (PDT) Received: from Patricks-MacBook-Pro-2.local ([2601:602:8900:ff:792d:7217:c042:324c]) by mx.google.com with ESMTPSA id oh4sm4151553pdb.42.2015.06.28.12.05.20 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jun 2015 12:05:21 -0700 (PDT) Date: Sun, 28 Jun 2015 12:05:04 -0700 From: Patrick Murck To: bitcoin-dev@lists.linuxfoundation.org, Milly Bitcoin Message-ID: In-Reply-To: <55901F7D.4000001@bitcoins.info> References: <558B7352.90708@bitcoins.info> <558D46EC.6050300@bitcoins.info> <558E9C06.9080901@bitcoins.info> <558FF307.9010606@bitcoins.info> <55901F7D.4000001@bitcoins.info> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5590456f_1bf2bd2_23f7" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP Process and Votes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 19:05:24 -0000 --5590456f_1bf2bd2_23f7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Wladimir has no more or less =E2=80=9Cpower=E2=80=9D to push change to th= e Bitcoin Core codebase than any other person with commit privileges to t= he GitHub repo. If I=E2=80=99m not mistaken there are 7 people with commi= t privileges and five of them are active. If Wladimir committed a change = it could be reverted by any of the others. This is by design and ensures = that changes will have reached some level of technical consensus before t= hey are merged, among other things. =46urthermore even assuming the Core Maintainer commits a change to Bitco= in Core (that isn=E2=80=99t reverted and that gets packaged up into the n= ext code release) that still doesn=E2=80=99t push a change to the bitcoin= network. There is no auto-update on Bitcoin Core so individuals and comp= anies running Bitcoin Core software have to choose to upgrade. =46urther = still, developers that maintain alternative implementations would have to= decide to merge those changes to the codebase they are indepently mainta= ining (and their users would need to update, etc.). I understand why it might *seem* to be the case that the Core Maintainer = is empowered to make changes to =22teh Bitcoin=22 but the reality is that= the Core Maintainer role is really about cat herding and project managem= ent of Bitcoin Core the open-source software project and not the bitcoin = network. We=E2=80=99re lucky Wladimir has agreed to take on so much of th= e scut work to keep the project moving forward. The process might get ugly and inefficient but that=E2=80=99s the cost of= having no wizard behind the curtain. -pm --=C2=A0 Patrick Murck On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly=40bitcoins.info) wro= te: The core maintainer has always been in control of the consensus rules. =20 Satoshi came up with the rules and put them in there. Since then any =20 changes to any part of the code go through the core maintainer. It =20 looks to me as if people are saying it somehow changed along the way =20 because they don't want to hurt people's feeling, upset up, get them to =20 quit, etc. Sure there are checks and balances and people don't have to =20 use the main code base but if they change the consensus rules they are =20 incompatible. The notion that because people can download different rules and run them = =20 is interesting from a theoretical perspective but that is constrained by = =20 the network effect. I can say the US government is not the =22decider=22 = of =20 laws because I can vote them out, recall them, challenge things in =20 court, or secede and start my own country. You can also say the =20 judge/jury in a criminal court case is not a =22decider=22 because the =20 president can always issue a pardon. But those points are generally not =20 useful in a practical sense. The issue about the developers is the tremendous influence they have to =20 veto any changes. I don't have veto power yet I have more bitcoins than =20 garzik says he has. The whole Bitcoin software development system is =20 subject to attack from just a couple of people who have this veto =20 power. With all the crying and moaning about centralization on this =20 list I would think that would be a concern. Russ On 6/28/2015 11:35 AM, Jorge Tim=C3=B3n wrote: > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin = wrote: >> I never said something was approved by garzik added something after it= was >> opposed. What I said was a proposal was made and 4 people commented on= the >> Github. He then tweeted there was near universal approval before most >> people even heard about the subject. It was not controversial but i wa= s >> pointing out the arrogance of some of the developers. He considers the= >> entire universe of Bitcoin stakeholders to be a very small group of >> insiders, not the entire universe of Bitcoin users. Another thing I ha= ve >> seen on Github for bitcoin.org is how some the maintainers change the = rules >> on the fly. Sometimes they say a proposal had no objections so it is >> approved. Other times they say a proposal has no support so it is reje= cted. > Ok, I misunderstood. > Well, the fact is that the number of capable reviewers is quite small. > If more companies hired and trained more developers to become bitcoin > core developers that situation could change, but that's where we are > now. > >> You are also trying to say that the core developers actually have litt= le >> influence and are not =22deciders=22 because anyone can fork the code.= That has >> already been discussed at length and such an argument is faulty becaus= e >> there is a constraint that your software is incompatible with everyone= else. > Only if you change the consensus rules (which are, in fact, a > relatively small part of the code). > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches > with the replace by fee policy, libbitcoin also changes many > non-consensus things, there's code written in other languages... > There's multiple counter-examples to your claim of that argument being = faulty. > Seriously, forking the project is just one click. You should try it > out like at least 9627 other people have done. > >=46rom there, you can pay your own developers (if you don't know how t= o > code yourself) and maybe they're also fine being insulted by you as > part of the job. > What you still can't do is unilaterally change the consensus rules of > a running p2p consensus system, because you cannot force the current > users to run any software they don't want to run. > >> The issue is that there is no way right now to change the consensus ru= les >> except to go through the core maintainer unless you get everybody on t= he >> network to switch to your fork. People who keep repeating that the sof= tware >> development is =22decentralized because you fork the code=22 without e= xplaining >> the constraints are just cultists. > Please, stop the cultist crap. Maybe insulting people like that is how > you got people to call you a troll. > But, yes, you are right: there's no known mechanism for safely > deploying controversial changes to the consensus rules > >> The discussion has nothing to do with who has the position now and I n= ever >> said he has =22control over the consensus rules.=22 The maintainer has= a very >> large influence way beyond anyone else. As for your claim that I want >> someone hurt because I am explaining the process, that is ridiculous. = If >> the Core maintainers did not have significant influence to change the >> consensus rules then everybody would not be spending all this time lob= bying >> them to have them changed. > Well, if you don't think he has control over the consensus rules we're > advancing. > I think that was implied from some of your previous claims. He is no > =22decider=22 on consensus changes. > Insisting on it can indeed get him hurt, so I'm happy that you're > taking that back (or clarifying that really wasn't your position). > Influence is very relative and not only core devs have =22influence=22.= > Maybe Andreas Antonopolous has more =22influence=22 than I have because= he > is a more public figure=3F > Well, that's fine I think. I don't see the point in discussing who has > how much influence. > >> The outside influences and stake of the developer is a relevant topic.= The >> same types of things are discussed on this list all the time in the co= ntext >> of miners, users, merchants, and exchanges. Again, the developers try = to >> place themselves on some kind of pedestal where they are the protector= s and >> pure and everyone else (miners, users, merchants) are abusers, spammer= s, >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made = an >> issue of how many bitcoins he holds and he made that issue in the same= place >> where he announces many of the technical issues. It is very relevant t= hat >> he has a minimal stake in Bitcoin holdings yet he goes around making m= ajor >> decisions about Bitcoin and trying to dictate who is allowed to partic= ipate >> in discussions. If a core developer has minimal stake in Bitcoin yet h= as >> major veto power over code change that is a problem. > Please, don't generalize. I don't think I put myself in any kind of ped= estal. > That is insulting to me and many others (you may not even know and > you're insulting them). > And I think my Bitcoin holdings are completely irrelevant when judging > my contributions to the software: either they're good or not, and who > I am or how many Bitcoins I have at any given time shouldn't matter. > Again, nobody forces you to use our software, as said there's > alternatives (including forking the project right now). > >> You are correct that you cannot give power to any person over the Inte= rnet >> which is why some kind of process needs to be developed that does not >> involve trying to convince one person to make the changes or a system = that >> depends on unwritten, ever-changing rules maintained by a handful of p= eople. > Well, for now the process we have is seeking consensus, and although > our definition of =22uncontroversial=22 is very vague, I think it is qu= ite > obvious when a proposed change is not =22uncontroversial=22 (like in th= e > block size debate). > It seems to me that any other =22formal process=22 would imply > centralization in the decision making of the consensus rules (and from > there you only have to corrupt that centralized organization to > destroy Bitcoin). > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F bitcoin-dev mailing list bitcoin-dev=40lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --5590456f_1bf2bd2_23f7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline