Then demonstrate it. He has been raising quite valid points over the maintenance of bitcoin core.
This is the same problem as the changes to consensus rules in bitcoin core: they aren't explicitly defined for the external audience. Thus forcing people to lobby for hard forks. 2015-06-28 21:16 GMT+01:00 Mark Friedenbach <[email protected]>: > Milly you are absolutely wrong as has been pointed out by numerous people > numerous times. Your idea of how bitcoin development decision making works > is demonstrably false. Please stop filling our inboxes with trolling > accusations, or else this will have to become a moderated list. And no one > wants that. > > On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <[email protected]> wrote: >> >> I really don't know who has power to do what behind the scenes. From what >> i understand, if push comes to shove, it is under the ultimate control of >> one person who can revoke commit privileges. Maybe I am wrong about that >> but the point is most people don't know for sure. >> >> You are correct about the people having the choice to download but the >> influence of the official release is way beyond the influence of any forked >> release. What that means in the real world is an open question and would be >> different depending upon the specific circumstances and difficult to >> predict. It is significant power to have control over the official release >> at the present time. If they did not have significant power people would >> not spend significant efforts lobbying them to make changes. Any new >> developers hired by companies will do so because they can influence over the >> official release since that is the only incentive. >> >> It seems to me that this block size fork is only the beginning of the >> issues that will arise over the coming years. Whatever powers the core >> maintainers have it is going to be exploited one way or another as time goes >> on. Maybe there are enough feedback mechanisms to protect against that, I >> don't really know. >> >> Russ >> >> >> >> >> >> On 6/28/2015 3:05 PM, Patrick Murck wrote: >> >> Wladimir has no more or less “power” to push change to the Bitcoin Core >> codebase than any other person with commit privileges to the GitHub repo. If >> I’m not mistaken there are 7 people with commit 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 they are merged, among other >> things. >> >> Furthermore even assuming the Core Maintainer commits a change to Bitcoin >> Core (that isn’t reverted and that gets packaged up into the next code >> release) that still doesn’t push a change to the bitcoin network. There is >> no auto-update on Bitcoin Core so individuals and companies running Bitcoin >> Core software have to choose to upgrade. Further still, developers that >> maintain alternative implementations would have to decide to merge those >> changes to the codebase they are indepently maintaining (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 "teh Bitcoin" but the reality is that the >> Core Maintainer role is really about cat herding and project management of >> Bitcoin Core the open-source software project and not the bitcoin network. >> We’re lucky Wladimir has agreed to take on so much of the scut work to keep >> the project moving forward. >> >> The process might get ugly and inefficient but that’s the cost of having >> no wizard behind the curtain. >> >> -pm >> >> -- >> Patrick Murck >> >> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin ([email protected]) wrote: >> >> The core maintainer has always been in control of the consensus rules. >> Satoshi came up with the rules and put them in there. Since then any >> changes to any part of the code go through the core maintainer. It >> looks to me as if people are saying it somehow changed along the way >> because they don't want to hurt people's feeling, upset up, get them to >> quit, etc. Sure there are checks and balances and people don't have to >> use the main code base but if they change the consensus rules they are >> incompatible. >> >> The notion that because people can download different rules and run them >> is interesting from a theoretical perspective but that is constrained by >> the network effect. I can say the US government is not the "decider" of >> laws because I can vote them out, recall them, challenge things in >> court, or secede and start my own country. You can also say the >> judge/jury in a criminal court case is not a "decider" because the >> president can always issue a pardon. But those points are generally not >> useful in a practical sense. >> >> The issue about the developers is the tremendous influence they have to >> veto any changes. I don't have veto power yet I have more bitcoins than >> garzik says he has. The whole Bitcoin software development system is >> subject to attack from just a couple of people who have this veto >> power. With all the crying and moaning about centralization on this >> list I would think that would be a concern. >> >> Russ >> >> >> >> On 6/28/2015 11:35 AM, Jorge Timón wrote: >> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <[email protected]> >> > 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 was >> >> 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 >> >> have >> >> 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 >> >> rejected. >> > 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 >> >> little >> >> influence and are not "deciders" because anyone can fork the code. That >> >> has >> >> already been discussed at length and such an argument is faulty because >> >> 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. >> > >From there, you can pay your own developers (if you don't know how to >> > 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 >> >> rules >> >> except to go through the core maintainer unless you get everybody on >> >> the >> >> network to switch to your fork. People who keep repeating that the >> >> software >> >> development is "decentralized because you fork the code" without >> >> explaining >> >> 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 >> >> never >> >> said he has "control over the consensus rules." 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 >> >> lobbying >> >> 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 >> > "decider" 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 "influence". >> > Maybe Andreas Antonopolous has more "influence" than I have because he >> > is a more public figure? >> > 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 >> >> context >> >> of miners, users, merchants, and exchanges. Again, the developers try >> >> to >> >> place themselves on some kind of pedestal where they are the protectors >> >> and >> >> pure and everyone else (miners, users, merchants) are abusers, >> >> spammers, >> >> 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 >> >> that >> >> he has a minimal stake in Bitcoin holdings yet he goes around making >> >> major >> >> decisions about Bitcoin and trying to dictate who is allowed to >> >> participate >> >> in discussions. If a core developer has minimal stake in Bitcoin yet >> >> has >> >> 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 >> > pedestal. >> > 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 >> >> Internet >> >> 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 >> >> people. >> > Well, for now the process we have is seeking consensus, and although >> > our definition of "uncontroversial" is very vague, I think it is quite >> > obvious when a proposed change is not "uncontroversial" (like in the >> > block size debate). >> > It seems to me that any other "formal process" 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). >> > >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
