* Re: [bitcoin-dev] BIP Process and Votes @ 2015-06-25 3:00 Raystonn 2015-06-25 3:19 ` Milly Bitcoin 2015-06-25 19:03 ` Tom Harding 0 siblings, 2 replies; 51+ messages in thread From: Raystonn @ 2015-06-25 3:00 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev [-- Attachment #1: Type: text/html, Size: 6546 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 3:00 [bitcoin-dev] BIP Process and Votes Raystonn @ 2015-06-25 3:19 ` Milly Bitcoin 2015-06-26 11:13 ` Jorge Timón 2015-06-25 19:03 ` Tom Harding 1 sibling, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 3:19 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 6743 bytes --] The more specific answer (from a user's perspective) is that there is unanimous approval within the constraints of the Bitcoin system. The constraint is that your software must be compatible with merchants and exchanges for your coins to have value. Stating "unanimous approval" without identifying the constraint is misstating the issue. As for developers, the consensus on code changes are almost never 100% and someone has to make the decision about what is an a acceptable consensus. Most of the cultish answers completely overlook this issue even though it is main point of the question. Russ On 6/24/2015 11:00 PM, Raystonn wrote: > > > Consensus-code changes are unanimous. They must be. > > Excellent. Now we are getting to some actual written rules. How about > updating the BIP process documentation with this? Everyone should be > able to read the rules of the coin they are buying. > > One moment though. Can you tell me how this particular rule came to > be? The creator of Bitcoin violated this rule many times. So it must > have been adopted after his departure. What process was followed to > adopt this new rule? Was there consensus for it at the time? A huge > portion of the user community is under the impression that Satoshi's > written plans, some of which violate this new rule, will be > implemented. So there certainly would not be consensus for this rule > today. > > On 24 Jun 2015 6:51 pm, Mark Friedenbach <mark@friedenbach.org> wrote: > > I'm sorry but this is absolutely not the case, Milly. The reason > that people get defensive is that we have a carefully constructed > process that does work (thank you very much!) and is well > documented. We talk about it quite often in fact as it is a > defining characteristic of how bitcoin is developed which differs > in some ways from how other open source software is developed -- > although it remains the same in most other ways. > > Changes to the non-consensus sections of Bitcoin Core tend to get > merged when there are a few reviews, tests, and ACKs from > recognized developers, there are no outstanding objections, and > the maintainer doing the merge makes a subjective judgement that > the code is ready. > > Consensus-changes, on the other hand, get merged into Bitcoin Core > only after the above criteria are met AND an extremely long > discussion period that has given all the relevant stakeholders a > chance to comment, and no significant objections remain. > Consensus-code changes are unanimous. They must be. > > The sort of process that exists in standards bodies for example, > with working groups and formal voting procedures, has no place > where changes define the nature and validity of other people's > money. Who has the right to reach into your pocket and define how > you can or cannot spend your coins? The premise of bitcoin is that > no one has that right, yet that is very much what we do when > consensus code changes are made. That is why when we make a change > to the rules governing the nature of bitcoin, we must make sure > that everyone is made aware of the change and consents to it. > > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without > issue. Every indication is that BIP 66 will complete deployment in > the very near future, and we intend to repeat this process for > more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY. > > This isn't about no one stepping forward to be the "decider." This > is about no one having the right to decide these things on the > behalf of others. If a contentious change is proposed and not > accepted by the process of consensus, that is because the process > is doing its job at rejecting controversial changes. It has > nothing to do with personality, and everything to do with the > nature of bitcoin itself. > > > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin > <milly@bitcoins.info <mailto:milly@bitcoins.info>> wrote: > > I have seen this question asked many times. Most developers > become defensive and they usually give a very vague 1-sentence > answer when this question is asked. It seems to be it is > based on personalities rather than any kind of definable > process. To have that discussion the personalities must be > separated out and answers like "such-and-such wouldn't do > that" don't really do much to advance the discussion. Also, > the incentive for new developers to come in is that they will > be paid by companies who want to influence the code and this > should be considered (some developers take this statement as > an insult when it is just a statement of the incentive process). > > The other problem you are having is the lead developer does > not want to be a "decider" when, in fact, he is a very > significant decider. While the users have the ultimate choice > in a practical sense the chief developer is the "decider." > Now people don't want to get him upset so nobody wants to push > the issue or fully define the process. Now you are left with > a broken, unwritten/unspoken process. While this type of > thing may work with a small group of developers > businesses/investors looking in from the outside will see this > as a risk. > > Until you get passed all the personality-based arguments you > are going to have a tough time defining a real process. > > Russ > > > > > > > On 6/24/2015 7:41 PM, Raystonn wrote: > > I would like to start a civil discussion on an undefined, > or at least unwritten, portion of the BIP process. Who > should get to vote on approval to commit a BIP > implementation into Bitcoin Core? Is a simple majority of > these voters sufficient for approval? If not, then what is? > > Raystonn > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11380 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 3:19 ` Milly Bitcoin @ 2015-06-26 11:13 ` Jorge Timón 2015-06-26 12:34 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Jorge Timón @ 2015-06-26 11:13 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev On Thu, Jun 25, 2015 at 2:42 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > "Cultish" means making claims without any supporting facts. On Thu, Jun 25, 2015 at 5:19 AM, Milly Bitcoin <milly@bitcoins.info> wrote: > As for developers, the consensus on code changes are almost never 100% and > someone has to make the decision about what is an a acceptable consensus. This statement seems "cultish" by your own definition. I'm going to make the opposite statement: the consensus on code changes is almost always 100%. Mark has already given a couple examples of changes to consensus rules (the most risky type of change), here's a few thousand other examples of changes to the bitcoin core's code that had no opposition: https://github.com/bitcoin/bitcoin/commits/master Can you please point us to a few examples were changes were made with opposition to them? In those cases (which you assure is what happens almost always), would you say that the result of letting a decider decide instead of fixing or addressing all the concerns (either by changing the proposed code or explaining it) better in restrospective? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-26 11:13 ` Jorge Timón @ 2015-06-26 12:34 ` Milly Bitcoin 2015-06-27 11:28 ` Jorge Timón 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-26 12:34 UTC (permalink / raw) To: bitcoin-dev Without looking up specific links I am confident people like Mircea Popescu will oppose just about any change. Maybe they don't post their objection to Github but the point I am making is that no matter what change you make someone, somewhere will be against it. Some of the developers think that Github is the only place that matters and that the only opinions that matter is a tiny group of insiders. I don't think that way which is the reasoning behind my statement. I am saying that after all the concerns are addressed as far as reasonably possible someone, somewhere has to decide whether or not to commit the changes to the official release. Right now the only person who makes that decision if the version manager. I agree it should not fall onto the shoulders of one person who is also very busy doing other things. I am saying there should be some process to move forward and make decisions when needed. Also, you already saw one of the Core developers calling me a "troll" and telling others to ignore my messages. I have heard of several people who just drop out of the github discussions because of stuff like that. They also delete message from Gihub discussions so that archive is not 100% credible. I have seen things like a Github discussion between 3 or 4 people and then Garzik send out a tweet that there is near universal approval for the proposed change as it nobody is allowed to question it. After watching the github process for a couple years I simply don't trust it because the developers in charge have a dictatorial style and they shut out many stakeholders instead of soliciting their opinions. I view the Github system as the biggest centralized choke-point in Bitcoin and probably its biggest threat to its continued survival. Anyone can come in and hire a couple core developers and veto any change they don't want. Russ On 6/26/2015 7:13 AM, Jorge Timón wrote: > On Thu, Jun 25, 2015 at 2:42 PM, Milly Bitcoin <milly@bitcoins.info> wrote: >> "Cultish" means making claims without any supporting facts. > On Thu, Jun 25, 2015 at 5:19 AM, Milly Bitcoin <milly@bitcoins.info> wrote: >> As for developers, the consensus on code changes are almost never 100% and >> someone has to make the decision about what is an a acceptable consensus. > This statement seems "cultish" by your own definition. > I'm going to make the opposite statement: the consensus on code > changes is almost always 100%. > Mark has already given a couple examples of changes to consensus rules > (the most risky type of change), here's a few thousand other examples > of changes to the bitcoin core's code that had no opposition: > > https://github.com/bitcoin/bitcoin/commits/master > > Can you please point us to a few examples were changes were made with > opposition to them? > In those cases (which you assure is what happens almost always), would > you say that the result of letting a decider decide instead of fixing > or addressing all the concerns (either by changing the proposed code > or explaining it) better in restrospective? > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-26 12:34 ` Milly Bitcoin @ 2015-06-27 11:28 ` Jorge Timón 2015-06-27 12:50 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Jorge Timón @ 2015-06-27 11:28 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev On Fri, Jun 26, 2015 at 2:34 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > Without looking up specific links I am confident people like Mircea Popescu > will oppose just about any change. Maybe they don't post their objection to > Github but the point I am making is that no matter what change you make > someone, somewhere will be against it. Some of the developers think that > Github is the only place that matters and that the only opinions that matter > is a tiny group of insiders. I don't think that way which is the reasoning > behind my statement. Yes, I understand that it may be difficult to define "uncontroversial", as I explain in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html > I have seen things like a Github discussion between 3 or 4 people > and then Garzik send out a tweet that there is near universal approval for > the proposed change as it nobody is allowed to question it. After watching > the github process for a couple years I simply don't trust it because the > developers in charge have a dictatorial style and they shut out many > stakeholders instead of soliciting their opinions. Can you provide anything to back your claim? Note that even if that's true, still, Bitcoin core != Bitcoin consensus rules. > I view the Github system > as the biggest centralized choke-point in Bitcoin and probably its biggest > threat to its continued survival. Anyone can come in and hire a couple core > developers and veto any change they don't want. Well, yes, github is centralized and so it is bitcoin core development. But bitcoin core developers don't decide hardfork changes. So far, softfork changes have been made because they have been considered "uncontroversial", not because there's any centralized negotiating table or voting process to decide when to force every user to adapt their software to new consensus rules. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-27 11:28 ` Jorge Timón @ 2015-06-27 12:50 ` Milly Bitcoin 2015-06-28 12:30 ` Jorge Timón 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-27 12:50 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4875 bytes --] On 6/27/2015 7:28 AM, Jorge Timón wrote: > On Fri, Jun 26, 2015 at 2:34 PM, Milly Bitcoin <milly@bitcoins.info> wrote: >> Without looking up specific links I am confident people like Mircea Popescu >> will oppose just about any change. Maybe they don't post their objection to >> Github but the point I am making is that no matter what change you make >> someone, somewhere will be against it. Some of the developers think that >> Github is the only place that matters and that the only opinions that matter >> is a tiny group of insiders. I don't think that way which is the reasoning >> behind my statement. > Yes, I understand that it may be difficult to define > "uncontroversial", as I explain in > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html > >> I have seen things like a Github discussion between 3 or 4 people >> and then Garzik send out a tweet that there is near universal approval for >> the proposed change as it nobody is allowed to question it. After watching >> the github process for a couple years I simply don't trust it because the >> developers in charge have a dictatorial style and they shut out many >> stakeholders instead of soliciting their opinions. > Can you provide anything to back your claim? > Note that even if that's true, still, Bitcoin core != Bitcoin consensus rules. I saw this problem first hand when Andreas Antonopolis got into a big dispute with some of the core developers over the press contacts. The github made up their rules as they went along and simply ignored input from anyone outside their inner circle. Since that time several people have told me they dropped out of participating in the github process. The maintainers deleted some of my messages and I have been told I am banned form github. Further, as you can see on here Jeff Garzik, a guy who claims only to hold a few hundred Bitcoin, told people on this list to ignore my messages. There is also the incident where Gavin lambasted someone for "hiding behind anonymity" when the whole project is based on an anonymous contributor. I find it interesting that many developers who work on a decentralized system. I don't like the general attitude of the developers that they are the protectors of the system and that everyone else is trying to exploit or do damage. they often characterize different users/businesses/miners as abusers, spammers, people trying to game the system, etc. while they characterize the developers as pure and good. When the issue comes up about authority over the code (which includes the consensus rules) they spout all kinds of nonsense about how they don't have significant control and are not deciders yet they never point to who does decide. If they weren't the deciders then people would not be spending all that time lobbying them. just because there are some checks and balances does not mean it is "decentralized" or they are not deciders. As for your proclamation**at Bitcoin core != Bitcoin consensus rules, that is simply not true in practice. There is one piece of software with one maintainer. If you want it changed you have to convince that one person to approve the change. >> I view the Github system >> as the biggest centralized choke-point in Bitcoin and probably its biggest >> threat to its continued survival. Anyone can come in and hire a couple core >> developers and veto any change they don't want. > Well, yes, github is centralized and so it is bitcoin core development. > But bitcoin core developers don't decide hardfork changes. > So far, softfork changes have been made because they have been > considered "uncontroversial", not because there's any centralized > negotiating table or voting process to decide when to force every user > to adapt their software to new consensus rules. > The core developers have the biggest influence by far to decide hard fork changes. There is no other place to go. While anyone can fork the code someone compare it to the river Thames. if you don't like where the river runs you can dig a new one ... here is a spoon. I can vote in elections but that does not mean the US government is "decentralized." The core maintainer has decided on a hard fork change, he has decided not to do it. In any case what happened in the past does not matter. What is going to happen now is the question. If nothing happens and everybody sits around saying they are not in charge of the consensus rules and nothing ever gets done I see Bitcoin just fading away into oblivion. I am under the impression that at least some of the developers (such as Garzik) don't actually hold that many bitcoins and don't have a large stake in the system yet they have significant control. Anyone can attack the system by simply hiring a couple core developers and creating the gridlock we see now. Russ [-- Attachment #2: Type: text/html, Size: 6044 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-27 12:50 ` Milly Bitcoin @ 2015-06-28 12:30 ` Jorge Timón 2015-06-28 13:13 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Jorge Timón @ 2015-06-28 12:30 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 2:50 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > On 6/27/2015 7:28 AM, Jorge Timón wrote: > I have seen things like a Github discussion between 3 or 4 people > and then Garzik send out a tweet that there is near universal approval for > the proposed change as it nobody is allowed to question it. After watching > the github process for a couple years I simply don't trust it because the > developers in charge have a dictatorial style and they shut out many > stakeholders instead of soliciting their opinions. > [...] > > I saw this problem first hand when Andreas Antonopolis got into a big > dispute with some of the core developers over the press contacts. The > github made up their rules as they went along and simply ignored input from > anyone outside their inner circle. Since that time several people have told > me they dropped out of participating in the github process. The maintainers > deleted some of my messages and I have been told I am banned form github. I wasn't asking for an example of something that was rejected, there's plenty of those. You were saying people were opposing a change and jgarzik unilaterally added it. When did that happen? > As for your proclamation at Bitcoin core != Bitcoin consensus rules, that is > simply not true in practice. There is one piece of software with one > maintainer. If you want it changed you have to convince that one person to > approve the change. There are many pieces of software and many maintainers, libbitcoin, for example, is another full node implementation different from Bitcoin core. Also, to change Bitcoin core I don't need to convince anyone, I do it all the time here https://github.com/jtimon/bitcoin > The core developers have the biggest influence by far to decide hard fork > changes. There is no other place to go. While anyone can fork the code > someone compare it to the river Thames. if you don't like where the river > runs you can dig a new one ... here is a spoon. I can vote in elections but > that does not mean the US government is "decentralized." The core > maintainer has decided on a hard fork change, he has decided not to do it. Maybe Bitcoin core devs have more influence, but still, they don't have the power to decide for everyone else what the consensus rules are. Your analogy is ridiculous, it literally takes seconds to fork bitcoin and is as simple as clicking a button. Wladimir has explained many times that he hasn't decided anything because he can't decide that. You keep insisting that he has control over consensus rules. Are you doing it because you want him to be threaten, tortured, kidnapped or killed? If you don't, please stop making false claims about powers he doesn't have because some bad guy could believe you. > I am under the > impression that at least some of the developers (such as Garzik) don't > actually hold that many bitcoins and don't have a large stake in the system > yet they have significant control. For the last time, they may have control over Bitcoin core (one implementation of the Bitcoin protocol), not the consensus rules. Why are anyone's bitcoin holdings relevant in any technical discussion? Please, keep this kind of offtopic comments out. > Anyone can attack the system by simply > hiring a couple core developers and creating the gridlock we see now. As said several times, yes, it is hard to define "uncontroversial" without giving veto powers to any random guy on the internet. But this is clearly not what is happening now. Most Bitcoin core devs are against the current proposals, that cannot be considered uncontroversial for any sane definition of it. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 12:30 ` Jorge Timón @ 2015-06-28 13:13 ` Milly Bitcoin 2015-06-28 15:35 ` Jorge Timón 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-28 13:13 UTC (permalink / raw) Cc: bitcoin-dev 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. 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. 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. 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. 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. 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. Russ On 6/28/2015 8:30 AM, Jorge Timón wrote: > On Sat, Jun 27, 2015 at 2:50 PM, Milly Bitcoin <milly@bitcoins.info> wrote: >> On 6/27/2015 7:28 AM, Jorge Timón wrote: >> I have seen things like a Github discussion between 3 or 4 people >> and then Garzik send out a tweet that there is near universal approval for >> the proposed change as it nobody is allowed to question it. After watching >> the github process for a couple years I simply don't trust it because the >> developers in charge have a dictatorial style and they shut out many >> stakeholders instead of soliciting their opinions. >> [...] >> >> I saw this problem first hand when Andreas Antonopolis got into a big >> dispute with some of the core developers over the press contacts. The >> github made up their rules as they went along and simply ignored input from >> anyone outside their inner circle. Since that time several people have told >> me they dropped out of participating in the github process. The maintainers >> deleted some of my messages and I have been told I am banned form github. > I wasn't asking for an example of something that was rejected, there's > plenty of those. > You were saying people were opposing a change and jgarzik unilaterally added it. > When did that happen? > >> As for your proclamation at Bitcoin core != Bitcoin consensus rules, that is >> simply not true in practice. There is one piece of software with one >> maintainer. If you want it changed you have to convince that one person to >> approve the change. > There are many pieces of software and many maintainers, libbitcoin, > for example, is another full node implementation different from > Bitcoin core. > Also, to change Bitcoin core I don't need to convince anyone, I do it > all the time here https://github.com/jtimon/bitcoin > >> The core developers have the biggest influence by far to decide hard fork >> changes. There is no other place to go. While anyone can fork the code >> someone compare it to the river Thames. if you don't like where the river >> runs you can dig a new one ... here is a spoon. I can vote in elections but >> that does not mean the US government is "decentralized." The core >> maintainer has decided on a hard fork change, he has decided not to do it. > Maybe Bitcoin core devs have more influence, but still, they don't > have the power to decide for everyone else what the consensus rules > are. > Your analogy is ridiculous, it literally takes seconds to fork bitcoin > and is as simple as clicking a button. > Wladimir has explained many times that he hasn't decided anything > because he can't decide that. > You keep insisting that he has control over consensus rules. Are you > doing it because you want him to be threaten, tortured, kidnapped or > killed? > If you don't, please stop making false claims about powers he doesn't > have because some bad guy could believe you. > >> I am under the >> impression that at least some of the developers (such as Garzik) don't >> actually hold that many bitcoins and don't have a large stake in the system >> yet they have significant control. > For the last time, they may have control over Bitcoin core (one > implementation of the Bitcoin protocol), not the consensus rules. > Why are anyone's bitcoin holdings relevant in any technical discussion? > Please, keep this kind of offtopic comments out. > >> Anyone can attack the system by simply >> hiring a couple core developers and creating the gridlock we see now. > As said several times, yes, it is hard to define "uncontroversial" > without giving veto powers to any random guy on the internet. > But this is clearly not what is happening now. Most Bitcoin core devs > are against the current proposals, that cannot be considered > uncontroversial for any sane definition of it. > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 13:13 ` Milly Bitcoin @ 2015-06-28 15:35 ` Jorge Timón 2015-06-28 16:23 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Jorge Timón @ 2015-06-28 15:35 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly@bitcoins.info> 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). ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 15:35 ` Jorge Timón @ 2015-06-28 16:23 ` Milly Bitcoin 2015-06-28 19:05 ` Patrick Murck 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-28 16:23 UTC (permalink / raw) To: bitcoin-dev 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 <milly@bitcoins.info> 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). > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 16:23 ` Milly Bitcoin @ 2015-06-28 19:05 ` Patrick Murck 2015-06-28 20:10 ` Milly Bitcoin 2015-06-28 20:21 ` NxtChg 0 siblings, 2 replies; 51+ messages in thread From: Patrick Murck @ 2015-06-28 19:05 UTC (permalink / raw) To: bitcoin-dev, Milly Bitcoin [-- Attachment #1: Type: text/plain, Size: 9559 bytes --] 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 (milly@bitcoins.info) 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 <milly@bitcoins.info> 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 bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 12062 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 19:05 ` Patrick Murck @ 2015-06-28 20:10 ` Milly Bitcoin 2015-06-28 20:16 ` Mark Friedenbach 2015-06-28 20:21 ` NxtChg 1 sibling, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-28 20:10 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 11318 bytes --] 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 (milly@bitcoins.info > <mailto:milly@bitcoins.info>) 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 >> <milly@bitcoins.info> 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 >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 17967 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 20:10 ` Milly Bitcoin @ 2015-06-28 20:16 ` Mark Friedenbach 2015-06-28 20:26 ` Ricardo Filipe 2015-06-28 23:52 ` Milly Bitcoin 0 siblings, 2 replies; 51+ messages in thread From: Mark Friedenbach @ 2015-06-28 20:16 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 11910 bytes --] 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" <milly@bitcoins.info> 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 (milly@bitcoins.info) 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 <milly@bitcoins.info> > <milly@bitcoins.info> 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 18737 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 20:16 ` Mark Friedenbach @ 2015-06-28 20:26 ` Ricardo Filipe 2015-06-28 21:00 ` Adam Back 2015-06-28 23:52 ` Milly Bitcoin 1 sibling, 1 reply; 51+ messages in thread From: Ricardo Filipe @ 2015-06-28 20:26 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev 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 <mark@friedenbach.org>: > 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" <milly@bitcoins.info> 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 (milly@bitcoins.info) 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 <milly@bitcoins.info> >> > 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 >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 20:26 ` Ricardo Filipe @ 2015-06-28 21:00 ` Adam Back 2015-06-29 0:13 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Adam Back @ 2015-06-28 21:00 UTC (permalink / raw) To: Ricardo Filipe; +Cc: bitcoin-dev I think we need a second mailing list: bitcoin-process for people to learn about bitcoin process. And someone to write a FAQ on it's sign up page so people interested could at least discuss from a starting point of understanding how and why it works the way it does! Adam ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 21:00 ` Adam Back @ 2015-06-29 0:13 ` Milly Bitcoin 2015-06-29 0:23 ` Andrew Lapp 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-29 0:13 UTC (permalink / raw) To: bitcoin-dev The concern with that is that any FAQ will be developed by the same small group that controls the github now so they will spin it in an unrealistic way. You see the problem now with the Bitcoin wiki. While the wiki has some valuable information, it also has a number of incorrect and cult-like claims about how Bitcoin works. Tim Swanson has made some good videos that describe some of the misinformation that often gets repeated on the Wiki and other places. I had suggested the info on the Wiki be reevaluated piece-by-piece and moved to Bitcoin.org but the developers didn't like that. Attempts to edit the Wiki often leads to the articles being defaced by the maintainers so that is a waste of time. Russ On 6/28/2015 5:00 PM, Adam Back wrote: > I think we need a second mailing list: bitcoin-process for people to > learn about bitcoin process. > > And someone to write a FAQ on it's sign up page so people interested > could at least discuss from a starting point of understanding how and > why it works the way it does! > > Adam > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-29 0:13 ` Milly Bitcoin @ 2015-06-29 0:23 ` Andrew Lapp 2015-06-29 1:11 ` Milly Bitcoin 0 siblings, 1 reply; 51+ messages in thread From: Andrew Lapp @ 2015-06-29 0:23 UTC (permalink / raw) To: bitcoin-dev Your discussion is taking up a lot of room in my inbox and it doesn't seem like either side is getting through to the other. Perhaps you could create a document outlining all the failure modes possible due to the current system, the current systems security assumptions and possible solutions. Now it seems this is just a semantic debate and would probably be better solved with you writing a BIP and having that reviewed and critiqued. -Andrew Lapp On 06/28/2015 08:13 PM, Milly Bitcoin wrote: > The concern with that is that any FAQ will be developed by the same > small group that controls the github now so they will spin it in an > unrealistic way. You see the problem now with the Bitcoin wiki. > While the wiki has some valuable information, it also has a number of > incorrect and cult-like claims about how Bitcoin works. Tim Swanson > has made some good videos that describe some of the misinformation > that often gets repeated on the Wiki and other places. > > I had suggested the info on the Wiki be reevaluated piece-by-piece and > moved to Bitcoin.org but the developers didn't like that. Attempts to > edit the Wiki often leads to the articles being defaced by the > maintainers so that is a waste of time. > > Russ > > > > On 6/28/2015 5:00 PM, Adam Back wrote: >> I think we need a second mailing list: bitcoin-process for people to >> learn about bitcoin process. >> >> And someone to write a FAQ on it's sign up page so people interested >> could at least discuss from a starting point of understanding how and >> why it works the way it does! >> >> Adam >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-29 0:23 ` Andrew Lapp @ 2015-06-29 1:11 ` Milly Bitcoin 0 siblings, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-29 1:11 UTC (permalink / raw) To: bitcoin-dev That sounds like a good idea except I have been told by the powers that be that I am not allowed to post to Github. Any Bip proposal is supposed to be vetted on the mailing list first. My suggestion has been to continue development of the risk analysis started by the Bitcoin Foundation found at https://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf. The idea is to create a living document of risks and mitigations as well as a decentralization metric. When a change is proposed it is measured against these risks and metrics in a somewhat standard fashion. If someone wants to post something like that to Github I can work on it. I am familiar with the process as I worked on something similar for many years for the US FAA. I worked in information security for large aviation systems in the R&D stage applying the NIST 800-series documents to the process (http://csrc.nist.gov/publications/PubsSPs.html). Russ On 6/28/2015 8:23 PM, Andrew Lapp wrote: > Your discussion is taking up a lot of room in my inbox and it doesn't > seem like either side is getting through to the other. Perhaps you > could create a document outlining all the failure modes possible due > to the current system, the current systems security assumptions and > possible solutions. Now it seems this is just a semantic debate and > would probably be better solved with you writing a BIP and having that > reviewed and critiqued. > > -Andrew Lapp > > On 06/28/2015 08:13 PM, Milly Bitcoin wrote: >> The concern with that is that any FAQ will be developed by the same >> small group that controls the github now so they will spin it in an >> unrealistic way. You see the problem now with the Bitcoin wiki. >> While the wiki has some valuable information, it also has a number of >> incorrect and cult-like claims about how Bitcoin works. Tim Swanson >> has made some good videos that describe some of the misinformation >> that often gets repeated on the Wiki and other places. >> >> I had suggested the info on the Wiki be reevaluated piece-by-piece >> and moved to Bitcoin.org but the developers didn't like that. >> Attempts to edit the Wiki often leads to the articles being defaced >> by the maintainers so that is a waste of time. >> >> Russ >> >> >> >> On 6/28/2015 5:00 PM, Adam Back wrote: >>> I think we need a second mailing list: bitcoin-process for people to >>> learn about bitcoin process. >>> >>> And someone to write a FAQ on it's sign up page so people interested >>> could at least discuss from a starting point of understanding how and >>> why it works the way it does! >>> >>> Adam >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 20:16 ` Mark Friedenbach 2015-06-28 20:26 ` Ricardo Filipe @ 2015-06-28 23:52 ` Milly Bitcoin 1 sibling, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-28 23:52 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 14515 bytes --] Nobody has pointed out I am "wrong," it is just semantics about the term "decider" and I am just essentially repeating things said by others. As for the term "troll," that is used primarily used by teenagers to deal with people they don't agree with. Unfortunately the developers are often 20-something kids like yourself who have never dealt with a large system of diverse stakeholders or anything outside of their specific technical areas. As for your claim that I accused someone of something, I don't know what you are talking about. If you don't like my messages then don't read them. It looks to me like you don't like the idea of the developers being questioned about their authority which is understandable as one of the people involved in Blocksteam because you want the system to stay the way it is. If you want to moderate the list the go ahead, I can't stop you but I am not going to listen to anyone who uses the term "troll." Russ On 6/28/2015 4:16 PM, Mark Friedenbach wrote: > > 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" <milly@bitcoins.info > <mailto:milly@bitcoins.info>> 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 >> (milly@bitcoins.info <mailto:milly@bitcoins.info>) 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 >>> <milly@bitcoins.info> <mailto:milly@bitcoins.info> 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 <http://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 >>> bitcoin-dev@lists.linuxfoundation.org >>> <mailto:bitcoin-dev@lists.linuxfoundation.org> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 23009 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-28 19:05 ` Patrick Murck 2015-06-28 20:10 ` Milly Bitcoin @ 2015-06-28 20:21 ` NxtChg 1 sibling, 0 replies; 51+ messages in thread From: NxtChg @ 2015-06-28 20:21 UTC (permalink / raw) To: Patrick Murck, bitcoin-dev, Milly Bitcoin On 6/28/2015 at 10:05 PM, "Patrick Murck" <patrick.murck@gmail.com> wrote: >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. It's not about pushing a change, it's about refusing a change on the grounds of controversy. This is _not_ an attack on Wladimir. His position in view of circumstances is perfectly reasonable: to take the safest option. Even at the risk of stagnation, as he pointed out, at least your funds won't be expropriated. It's a noble position to defend the minority. Unfortunately (or fortunately), the majority of power usually gets what it wants. Of course, "they will have it their way anyway" is not an appropriate reason to flip-flop on an ethical position, so nobody expects Wladimir to change his mind. Thus, we are playing a variation of prisoner's dilemma here: the best solution would be an agreement on both sides, if only they could agree. In reality, there's a good chance that Gavin's fork will win, creating precisely the problems and risks, which Wladimir tries to avoid, only more. And we will end up with lose-lose situation. But we lack any other mechanism for a scenario where interests of some of those 7 committers become misaligned with interests of the majority (which seems to be the case). And every time Bitcoin will face similar disagreement in the future we will go through it again... ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 3:00 [bitcoin-dev] BIP Process and Votes Raystonn 2015-06-25 3:19 ` Milly Bitcoin @ 2015-06-25 19:03 ` Tom Harding 1 sibling, 0 replies; 51+ messages in thread From: Tom Harding @ 2015-06-25 19:03 UTC (permalink / raw) To: bitcoin-dev, Raystonn On 6/24/2015 8:00 PM, Raystonn wrote: > > > Consensus-code changes are unanimous. They must be. > > Excellent. Now we are getting to some actual written rules. How about > updating the BIP process documentation with this? Everyone should be > able to read the rules of the coin they are buying. > > One moment though. Can you tell me how this particular rule came to > be? The creator of Bitcoin violated this rule many times. So it must > have been adopted after his departure. What process was followed to > adopt this new rule? Was there consensus for it at the time? A huge > portion of the user community is under the impression that Satoshi's > written plans, some of which violate this new rule, will be > implemented. So there certainly would not be consensus for this rule > today. > Great question; very fair. I, for one, eagerly await Mark's answer. I hope nobody forgot to tell adversaries totally outside the open source ecosystem what the rules for hard forking changes are. The Chinese miners have it right - we have to work together. If you want to see who's trying, look at who has written a concrete BIP/code vs. who hasn't; who has made changes in response to feedback, and who hasn't. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes @ 2015-06-25 3:53 Raystonn 0 siblings, 0 replies; 51+ messages in thread From: Raystonn @ 2015-06-25 3:53 UTC (permalink / raw) To: Gareth Williams; +Cc: bitcoin-dev [-- Attachment #1: Type: text/html, Size: 1514 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes @ 2015-06-25 0:18 Raystonn 0 siblings, 0 replies; 51+ messages in thread From: Raystonn @ 2015-06-25 0:18 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/html, Size: 2164 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* [bitcoin-dev] BIP Process and Votes @ 2015-06-24 23:41 Raystonn 2015-06-24 23:49 ` Jeff Garzik 2015-06-25 0:07 ` Milly Bitcoin 0 siblings, 2 replies; 51+ messages in thread From: Raystonn @ 2015-06-24 23:41 UTC (permalink / raw) To: bitcoin-dev I would like to start a civil discussion on an undefined, or at least unwritten, portion of the BIP process. Who should get to vote on approval to commit a BIP implementation into Bitcoin Core? Is a simple majority of these voters sufficient for approval? If not, then what is? Raystonn ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-24 23:41 Raystonn @ 2015-06-24 23:49 ` Jeff Garzik 2015-06-25 0:11 ` Bryan Bishop 2015-06-25 0:21 ` Milly Bitcoin 2015-06-25 0:07 ` Milly Bitcoin 1 sibling, 2 replies; 51+ messages in thread From: Jeff Garzik @ 2015-06-24 23:49 UTC (permalink / raw) To: Raystonn; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 923 bytes --] BIPs are accepted into BIP repo with a low "reasonable" threshold. Code is accepted into the Bitcoin Core repo when it is likely that the community will accept a change. There is no voting in the way you think. Devs commit changes the users will accept and use. Users "fire" developers by choosing different devs or different software. Standard open source method. On Jun 24, 2015 4:41 PM, "Raystonn" <raystonn@hotmail.com> wrote: > I would like to start a civil discussion on an undefined, or at least > unwritten, portion of the BIP process. Who should get to vote on approval > to commit a BIP implementation into Bitcoin Core? Is a simple majority of > these voters sufficient for approval? If not, then what is? > > Raystonn > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1431 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-24 23:49 ` Jeff Garzik @ 2015-06-25 0:11 ` Bryan Bishop 2015-06-25 0:21 ` Milly Bitcoin 1 sibling, 0 replies; 51+ messages in thread From: Bryan Bishop @ 2015-06-25 0:11 UTC (permalink / raw) To: Jeff Garzik, Bryan Bishop; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 799 bytes --] On Wed, Jun 24, 2015 at 6:49 PM, Jeff Garzik <jgarzik@gmail.com> wrote: > There is no voting in the way you think. Devs commit changes the users > will accept and use. Users "fire" developers by choosing different devs or > different software. I think that statement is too weak. Users are all personally responsible for evaluating all rules for themselves. Many have chosen and will continue to choose to just keep an ear out for rule changes that they may be interested in using. Ever user should be educated on this topic... otherwise there are too many principal agent problems, even with the ability to "fire" developers (a.k.a "use different software"). It's similar to the reasons why it's important to see all the transactions on the network. - Bryan http://heybryan.org/ 1 512 203 0507 [-- Attachment #2: Type: text/html, Size: 1228 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-24 23:49 ` Jeff Garzik 2015-06-25 0:11 ` Bryan Bishop @ 2015-06-25 0:21 ` Milly Bitcoin 1 sibling, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 0:21 UTC (permalink / raw) To: Jeff Garzik, bitcoin-dev >There is no voting in the way you think. Devs commit changes the users will accept and use. Users "fire" developers by choosing different devs or different software. >Standard open source method. Most open source projects do not require 100% user adoption in order for other users to be compatible. Very different than most open source projects. Repeating "stock" answers does nothing to advanced the discussion. Russ ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-24 23:41 Raystonn 2015-06-24 23:49 ` Jeff Garzik @ 2015-06-25 0:07 ` Milly Bitcoin 2015-06-25 1:50 ` Mark Friedenbach ` (2 more replies) 1 sibling, 3 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 0:07 UTC (permalink / raw) To: bitcoin-dev I have seen this question asked many times. Most developers become defensive and they usually give a very vague 1-sentence answer when this question is asked. It seems to be it is based on personalities rather than any kind of definable process. To have that discussion the personalities must be separated out and answers like "such-and-such wouldn't do that" don't really do much to advance the discussion. Also, the incentive for new developers to come in is that they will be paid by companies who want to influence the code and this should be considered (some developers take this statement as an insult when it is just a statement of the incentive process). The other problem you are having is the lead developer does not want to be a "decider" when, in fact, he is a very significant decider. While the users have the ultimate choice in a practical sense the chief developer is the "decider." Now people don't want to get him upset so nobody wants to push the issue or fully define the process. Now you are left with a broken, unwritten/unspoken process. While this type of thing may work with a small group of developers businesses/investors looking in from the outside will see this as a risk. Until you get passed all the personality-based arguments you are going to have a tough time defining a real process. Russ On 6/24/2015 7:41 PM, Raystonn wrote: > I would like to start a civil discussion on an undefined, or at least unwritten, portion of the BIP process. Who should get to vote on approval to commit a BIP implementation into Bitcoin Core? Is a simple majority of these voters sufficient for approval? If not, then what is? > > Raystonn > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 0:07 ` Milly Bitcoin @ 2015-06-25 1:50 ` Mark Friedenbach 2015-06-25 2:30 ` Alex Morcos ` (2 more replies) 2015-06-25 3:42 ` Gareth Williams 2015-06-25 13:36 ` s7r 2 siblings, 3 replies; 51+ messages in thread From: Mark Friedenbach @ 2015-06-25 1:50 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4503 bytes --] I'm sorry but this is absolutely not the case, Milly. The reason that people get defensive is that we have a carefully constructed process that does work (thank you very much!) and is well documented. We talk about it quite often in fact as it is a defining characteristic of how bitcoin is developed which differs in some ways from how other open source software is developed -- although it remains the same in most other ways. Changes to the non-consensus sections of Bitcoin Core tend to get merged when there are a few reviews, tests, and ACKs from recognized developers, there are no outstanding objections, and the maintainer doing the merge makes a subjective judgement that the code is ready. Consensus-changes, on the other hand, get merged into Bitcoin Core only after the above criteria are met AND an extremely long discussion period that has given all the relevant stakeholders a chance to comment, and no significant objections remain. Consensus-code changes are unanimous. They must be. The sort of process that exists in standards bodies for example, with working groups and formal voting procedures, has no place where changes define the nature and validity of other people's money. Who has the right to reach into your pocket and define how you can or cannot spend your coins? The premise of bitcoin is that no one has that right, yet that is very much what we do when consensus code changes are made. That is why when we make a change to the rules governing the nature of bitcoin, we must make sure that everyone is made aware of the change and consents to it. Everyone. Does this work? Does this scale? So far, it does. Uncontroversial changes, such as BIP 66, are deployed without issue. Every indication is that BIP 66 will complete deployment in the very near future, and we intend to repeat this process for more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY. This isn't about no one stepping forward to be the "decider." This is about no one having the right to decide these things on the behalf of others. If a contentious change is proposed and not accepted by the process of consensus, that is because the process is doing its job at rejecting controversial changes. It has nothing to do with personality, and everything to do with the nature of bitcoin itself. On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > I have seen this question asked many times. Most developers become > defensive and they usually give a very vague 1-sentence answer when this > question is asked. It seems to be it is based on personalities rather than > any kind of definable process. To have that discussion the personalities > must be separated out and answers like "such-and-such wouldn't do that" > don't really do much to advance the discussion. Also, the incentive for > new developers to come in is that they will be paid by companies who want > to influence the code and this should be considered (some developers take > this statement as an insult when it is just a statement of the incentive > process). > > The other problem you are having is the lead developer does not want to be > a "decider" when, in fact, he is a very significant decider. While the > users have the ultimate choice in a practical sense the chief developer is > the "decider." Now people don't want to get him upset so nobody wants to > push the issue or fully define the process. Now you are left with a > broken, unwritten/unspoken process. While this type of thing may work with > a small group of developers businesses/investors looking in from the > outside will see this as a risk. > > Until you get passed all the personality-based arguments you are going to > have a tough time defining a real process. > > Russ > > > > > > > On 6/24/2015 7:41 PM, Raystonn wrote: > >> I would like to start a civil discussion on an undefined, or at least >> unwritten, portion of the BIP process. Who should get to vote on approval >> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >> these voters sufficient for approval? If not, then what is? >> >> Raystonn >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5613 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 1:50 ` Mark Friedenbach @ 2015-06-25 2:30 ` Alex Morcos 2015-06-25 2:34 ` Milly Bitcoin 2015-06-25 20:05 ` Tier Nolan 2 siblings, 0 replies; 51+ messages in thread From: Alex Morcos @ 2015-06-25 2:30 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4915 bytes --] +1 Mark! On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark@friedenbach.org> wrote: > I'm sorry but this is absolutely not the case, Milly. The reason that > people get defensive is that we have a carefully constructed process that > does work (thank you very much!) and is well documented. We talk about it > quite often in fact as it is a defining characteristic of how bitcoin is > developed which differs in some ways from how other open source software is > developed -- although it remains the same in most other ways. > > Changes to the non-consensus sections of Bitcoin Core tend to get merged > when there are a few reviews, tests, and ACKs from recognized developers, > there are no outstanding objections, and the maintainer doing the merge > makes a subjective judgement that the code is ready. > > Consensus-changes, on the other hand, get merged into Bitcoin Core only > after the above criteria are met AND an extremely long discussion period > that has given all the relevant stakeholders a chance to comment, and no > significant objections remain. Consensus-code changes are unanimous. They > must be. > > The sort of process that exists in standards bodies for example, with > working groups and formal voting procedures, has no place where changes > define the nature and validity of other people's money. Who has the right > to reach into your pocket and define how you can or cannot spend your > coins? The premise of bitcoin is that no one has that right, yet that is > very much what we do when consensus code changes are made. That is why when > we make a change to the rules governing the nature of bitcoin, we must make > sure that everyone is made aware of the change and consents to it. > > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without issue. Every > indication is that BIP 66 will complete deployment in the very near future, > and we intend to repeat this process for more interesting changes such as > BIP65: CHECKLOCKTIMEVERIFY. > > This isn't about no one stepping forward to be the "decider." This is > about no one having the right to decide these things on the behalf of > others. If a contentious change is proposed and not accepted by the process > of consensus, that is because the process is doing its job at rejecting > controversial changes. It has nothing to do with personality, and > everything to do with the nature of bitcoin itself. > > > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > >> I have seen this question asked many times. Most developers become >> defensive and they usually give a very vague 1-sentence answer when this >> question is asked. It seems to be it is based on personalities rather than >> any kind of definable process. To have that discussion the personalities >> must be separated out and answers like "such-and-such wouldn't do that" >> don't really do much to advance the discussion. Also, the incentive for >> new developers to come in is that they will be paid by companies who want >> to influence the code and this should be considered (some developers take >> this statement as an insult when it is just a statement of the incentive >> process). >> >> The other problem you are having is the lead developer does not want to >> be a "decider" when, in fact, he is a very significant decider. While the >> users have the ultimate choice in a practical sense the chief developer is >> the "decider." Now people don't want to get him upset so nobody wants to >> push the issue or fully define the process. Now you are left with a >> broken, unwritten/unspoken process. While this type of thing may work with >> a small group of developers businesses/investors looking in from the >> outside will see this as a risk. >> >> Until you get passed all the personality-based arguments you are going to >> have a tough time defining a real process. >> >> Russ >> >> >> >> >> >> >> On 6/24/2015 7:41 PM, Raystonn wrote: >> >>> I would like to start a civil discussion on an undefined, or at least >>> unwritten, portion of the BIP process. Who should get to vote on approval >>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>> these voters sufficient for approval? If not, then what is? >>> >>> Raystonn >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6392 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 1:50 ` Mark Friedenbach 2015-06-25 2:30 ` Alex Morcos @ 2015-06-25 2:34 ` Milly Bitcoin 2015-06-25 5:07 ` Jeff Garzik 2015-06-25 20:05 ` Tier Nolan 2 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 2:34 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 6993 bytes --] I'm sorry but that is the kind of defensive, cultish response everyone gets when they ask that question. If you had a well constructed documented process then you would be able to point to it ... but you can't. While there are a few bits and pieces scattered about in different places there is no coherent plan or process. It is easy to make statements like "consensus must be unanimous" but the issue is that you never have true 100% consensus yet you have to move forward in some fashion and everyone has to run software with the same consensus rules. The issue is how you move forward is the question that nobody wants to answer because (a) it is a hard question to answer and (b) developers see it as a threat to their authority/position. If people just keep shutting down the discussion with a bunch of cultish stock answers then you are never going to move forward with developing some kind of process. From what I can see much of the discussion is personality-driven and not based on Computer Science or and defined process. The issue is that a personality has changed so the process is perceived to be different and some people want to hard fork. Previously, the cultish answer is that Bitcoin development is decentralized because people can fork the code. Now that some developers want to fork the code suddenly it is a big problem. Is forking the code part of the consensus process or is it the work of the devil? The fact that there is so much diverse opinion on this shows a defined process has never been fully vetted or understood. I have worked on these processes for many years for projects orders of magnitudes larger than Bitcoin. I can absolutely assure you the current mishmash does not scale and huge amounts of time are wasted. That should be readily apparent from the recent discussions and the recent concern it has caused from people outside the developer's inner circle. Lack of defined process = high risk and wasted effort. Russ On 6/24/2015 9:50 PM, Mark Friedenbach wrote: > I'm sorry but this is absolutely not the case, Milly. The reason that > people get defensive is that we have a carefully constructed process > that does work (thank you very much!) and is well documented. We talk > about it quite often in fact as it is a defining characteristic of how > bitcoin is developed which differs in some ways from how other open > source software is developed -- although it remains the same in most > other ways. > > Changes to the non-consensus sections of Bitcoin Core tend to get > merged when there are a few reviews, tests, and ACKs from recognized > developers, there are no outstanding objections, and the maintainer > doing the merge makes a subjective judgement that the code is ready. > > Consensus-changes, on the other hand, get merged into Bitcoin Core > only after the above criteria are met AND an extremely long discussion > period that has given all the relevant stakeholders a chance to > comment, and no significant objections remain. Consensus-code changes > are unanimous. They must be. > > The sort of process that exists in standards bodies for example, with > working groups and formal voting procedures, has no place where > changes define the nature and validity of other people's money. Who > has the right to reach into your pocket and define how you can or > cannot spend your coins? The premise of bitcoin is that no one has > that right, yet that is very much what we do when consensus code > changes are made. That is why when we make a change to the rules > governing the nature of bitcoin, we must make sure that everyone is > made aware of the change and consents to it. > > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without issue. > Every indication is that BIP 66 will complete deployment in the very > near future, and we intend to repeat this process for more interesting > changes such as BIP65: CHECKLOCKTIMEVERIFY. > > This isn't about no one stepping forward to be the "decider." This is > about no one having the right to decide these things on the behalf of > others. If a contentious change is proposed and not accepted by the > process of consensus, that is because the process is doing its job at > rejecting controversial changes. It has nothing to do with > personality, and everything to do with the nature of bitcoin itself. > > > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly@bitcoins.info > <mailto:milly@bitcoins.info>> wrote: > > I have seen this question asked many times. Most developers > become defensive and they usually give a very vague 1-sentence > answer when this question is asked. It seems to be it is based on > personalities rather than any kind of definable process. To have > that discussion the personalities must be separated out and > answers like "such-and-such wouldn't do that" don't really do much > to advance the discussion. Also, the incentive for new developers > to come in is that they will be paid by companies who want to > influence the code and this should be considered (some developers > take this statement as an insult when it is just a statement of > the incentive process). > > The other problem you are having is the lead developer does not > want to be a "decider" when, in fact, he is a very significant > decider. While the users have the ultimate choice in a practical > sense the chief developer is the "decider." Now people don't want > to get him upset so nobody wants to push the issue or fully define > the process. Now you are left with a broken, unwritten/unspoken > process. While this type of thing may work with a small group of > developers businesses/investors looking in from the outside will > see this as a risk. > > Until you get passed all the personality-based arguments you are > going to have a tough time defining a real process. > > Russ > > > > > > > On 6/24/2015 7:41 PM, Raystonn wrote: > > I would like to start a civil discussion on an undefined, or > at least unwritten, portion of the BIP process. Who should > get to vote on approval to commit a BIP implementation into > Bitcoin Core? Is a simple majority of these voters sufficient > for approval? If not, then what is? > > Raystonn > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11259 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 2:34 ` Milly Bitcoin @ 2015-06-25 5:07 ` Jeff Garzik 2015-06-25 5:41 ` Milly Bitcoin 2015-06-25 7:51 ` cipher anthem 0 siblings, 2 replies; 51+ messages in thread From: Jeff Garzik @ 2015-06-25 5:07 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 7192 bytes --] Ladies & gents, please do not feed the troll. This has been explained to Milly multiple times in the past, on previous mailing list & github with no impact. On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > I'm sorry but that is the kind of defensive, cultish response everyone > gets when they ask that question. If you had a well constructed documented > process then you would be able to point to it ... but you can't. While > there are a few bits and pieces scattered about in different places there > is no coherent plan or process. > > It is easy to make statements like "consensus must be unanimous" but the > issue is that you never have true 100% consensus yet you have to move > forward in some fashion and everyone has to run software with the same > consensus rules. The issue is how you move forward is the question that > nobody wants to answer because (a) it is a hard question to answer and (b) > developers see it as a threat to their authority/position. If people just > keep shutting down the discussion with a bunch of cultish stock answers > then you are never going to move forward with developing some kind of > process. > > From what I can see much of the discussion is personality-driven and not > based on Computer Science or and defined process. The issue is that a > personality has changed so the process is perceived to be different and > some people want to hard fork. Previously, the cultish answer is that > Bitcoin development is decentralized because people can fork the code. Now > that some developers want to fork the code suddenly it is a big problem. > Is forking the code part of the consensus process or is it the work of the > devil? The fact that there is so much diverse opinion on this shows a > defined process has never been fully vetted or understood. > > I have worked on these processes for many years for projects orders of > magnitudes larger than Bitcoin. I can absolutely assure you the current > mishmash does not scale and huge amounts of time are wasted. That should > be readily apparent from the recent discussions and the recent concern it > has caused from people outside the developer's inner circle. > > Lack of defined process = high risk and wasted effort. > > Russ > > > > > > On 6/24/2015 9:50 PM, Mark Friedenbach wrote: > > I'm sorry but this is absolutely not the case, Milly. The reason that > people get defensive is that we have a carefully constructed process that > does work (thank you very much!) and is well documented. We talk about it > quite often in fact as it is a defining characteristic of how bitcoin is > developed which differs in some ways from how other open source software is > developed -- although it remains the same in most other ways. > > Changes to the non-consensus sections of Bitcoin Core tend to get merged > when there are a few reviews, tests, and ACKs from recognized developers, > there are no outstanding objections, and the maintainer doing the merge > makes a subjective judgement that the code is ready. > > Consensus-changes, on the other hand, get merged into Bitcoin Core only > after the above criteria are met AND an extremely long discussion period > that has given all the relevant stakeholders a chance to comment, and no > significant objections remain. Consensus-code changes are unanimous. They > must be. > > The sort of process that exists in standards bodies for example, with > working groups and formal voting procedures, has no place where changes > define the nature and validity of other people's money. Who has the right > to reach into your pocket and define how you can or cannot spend your > coins? The premise of bitcoin is that no one has that right, yet that is > very much what we do when consensus code changes are made. That is why when > we make a change to the rules governing the nature of bitcoin, we must make > sure that everyone is made aware of the change and consents to it. > > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without issue. Every > indication is that BIP 66 will complete deployment in the very near future, > and we intend to repeat this process for more interesting changes such as > BIP65: CHECKLOCKTIMEVERIFY. > > This isn't about no one stepping forward to be the "decider." This is > about no one having the right to decide these things on the behalf of > others. If a contentious change is proposed and not accepted by the process > of consensus, that is because the process is doing its job at rejecting > controversial changes. It has nothing to do with personality, and > everything to do with the nature of bitcoin itself. > > > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly@bitcoins.info> > milly@bitcoins.info> wrote: > >> I have seen this question asked many times. Most developers become >> defensive and they usually give a very vague 1-sentence answer when this >> question is asked. It seems to be it is based on personalities rather than >> any kind of definable process. To have that discussion the personalities >> must be separated out and answers like "such-and-such wouldn't do that" >> don't really do much to advance the discussion. Also, the incentive for >> new developers to come in is that they will be paid by companies who want >> to influence the code and this should be considered (some developers take >> this statement as an insult when it is just a statement of the incentive >> process). >> >> The other problem you are having is the lead developer does not want to >> be a "decider" when, in fact, he is a very significant decider. While the >> users have the ultimate choice in a practical sense the chief developer is >> the "decider." Now people don't want to get him upset so nobody wants to >> push the issue or fully define the process. Now you are left with a >> broken, unwritten/unspoken process. While this type of thing may work with >> a small group of developers businesses/investors looking in from the >> outside will see this as a risk. >> >> Until you get passed all the personality-based arguments you are going to >> have a tough time defining a real process. >> >> Russ >> >> >> >> >> >> >> On 6/24/2015 7:41 PM, Raystonn wrote: >> >>> I would like to start a civil discussion on an undefined, or at least >>> unwritten, portion of the BIP process. Who should get to vote on approval >>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>> these voters sufficient for approval? If not, then what is? >>> >>> Raystonn >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11792 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 5:07 ` Jeff Garzik @ 2015-06-25 5:41 ` Milly Bitcoin 2015-06-25 6:06 ` Pindar Wong 2015-06-25 7:51 ` cipher anthem 1 sibling, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 5:41 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 9174 bytes --] These are the kind of silly responses you often get when this subject comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see no need for him to use the list to attack people he doesn't agree with and/or try to interfere with discussions of others on the list. He turns it into a personality discussion rather than a discussion of Systems Engineering. He also tries to intimate anyone who brings up the discussion and "punish" them as a lesson to anyone else who may raise the issue. It is interesting that people like that are attracted to a decentralized system. The reply is simply an attempt at protecting turf which is why Mr. Garzik's vague replies are never taken seriously on the subject of decision-making process for the software. Russ On 6/25/2015 1:07 AM, Jeff Garzik wrote: > Ladies & gents, please do not feed the troll. This has been explained > to Milly multiple times in the past, on previous mailing list & github > with no impact. > > > On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info > <mailto:milly@bitcoins.info>> wrote: > > I'm sorry but that is the kind of defensive, cultish response > everyone gets when they ask that question. If you had a well > constructed documented process then you would be able to point to > it ... but you can't. While there are a few bits and pieces > scattered about in different places there is no coherent plan or > process. > > It is easy to make statements like "consensus must be unanimous" > but the issue is that you never have true 100% consensus yet you > have to move forward in some fashion and everyone has to run > software with the same consensus rules. The issue is how you move > forward is the question that nobody wants to answer because (a) it > is a hard question to answer and (b) developers see it as a threat > to their authority/position. If people just keep shutting down > the discussion with a bunch of cultish stock answers then you are > never going to move forward with developing some kind of process. > > From what I can see much of the discussion is personality-driven > and not based on Computer Science or and defined process. The > issue is that a personality has changed so the process is > perceived to be different and some people want to hard fork. > Previously, the cultish answer is that Bitcoin development is > decentralized because people can fork the code. Now that some > developers want to fork the code suddenly it is a big problem. > Is forking the code part of the consensus process or is it the > work of the devil? The fact that there is so much diverse > opinion on this shows a defined process has never been fully > vetted or understood. > > I have worked on these processes for many years for projects > orders of magnitudes larger than Bitcoin. I can absolutely assure > you the current mishmash does not scale and huge amounts of time > are wasted. That should be readily apparent from the recent > discussions and the recent concern it has caused from people > outside the developer's inner circle. > > Lack of defined process = high risk and wasted effort. > > Russ > > > > > > On 6/24/2015 9:50 PM, Mark Friedenbach wrote: >> I'm sorry but this is absolutely not the case, Milly. The reason >> that people get defensive is that we have a carefully constructed >> process that does work (thank you very much!) and is well >> documented. We talk about it quite often in fact as it is a >> defining characteristic of how bitcoin is developed which differs >> in some ways from how other open source software is developed -- >> although it remains the same in most other ways. >> >> Changes to the non-consensus sections of Bitcoin Core tend to get >> merged when there are a few reviews, tests, and ACKs from >> recognized developers, there are no outstanding objections, and >> the maintainer doing the merge makes a subjective judgement that >> the code is ready. >> >> Consensus-changes, on the other hand, get merged into Bitcoin >> Core only after the above criteria are met AND an extremely long >> discussion period that has given all the relevant stakeholders a >> chance to comment, and no significant objections remain. >> Consensus-code changes are unanimous. They must be. >> >> The sort of process that exists in standards bodies for example, >> with working groups and formal voting procedures, has no place >> where changes define the nature and validity of other people's >> money. Who has the right to reach into your pocket and define how >> you can or cannot spend your coins? The premise of bitcoin is >> that no one has that right, yet that is very much what we do when >> consensus code changes are made. That is why when we make a >> change to the rules governing the nature of bitcoin, we must make >> sure that everyone is made aware of the change and consents to it. >> >> Everyone. Does this work? Does this scale? So far, it does. >> Uncontroversial changes, such as BIP 66, are deployed without >> issue. Every indication is that BIP 66 will complete deployment >> in the very near future, and we intend to repeat this process for >> more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY. >> >> This isn't about no one stepping forward to be the "decider." >> This is about no one having the right to decide these things on >> the behalf of others. If a contentious change is proposed and not >> accepted by the process of consensus, that is because the process >> is doing its job at rejecting controversial changes. It has >> nothing to do with personality, and everything to do with the >> nature of bitcoin itself. >> >> >> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin >> <milly@bitcoins.info <mailto:milly@bitcoins.info>> wrote: >> >> I have seen this question asked many times. Most developers >> become defensive and they usually give a very vague >> 1-sentence answer when this question is asked. It seems to >> be it is based on personalities rather than any kind of >> definable process. To have that discussion the personalities >> must be separated out and answers like "such-and-such >> wouldn't do that" don't really do much to advance the >> discussion. Also, the incentive for new developers to come in >> is that they will be paid by companies who want to influence >> the code and this should be considered (some developers take >> this statement as an insult when it is just a statement of >> the incentive process). >> >> The other problem you are having is the lead developer does >> not want to be a "decider" when, in fact, he is a very >> significant decider. While the users have the ultimate >> choice in a practical sense the chief developer is the >> "decider." Now people don't want to get him upset so nobody >> wants to push the issue or fully define the process. Now you >> are left with a broken, unwritten/unspoken process. While >> this type of thing may work with a small group of developers >> businesses/investors looking in from the outside will see >> this as a risk. >> >> Until you get passed all the personality-based arguments you >> are going to have a tough time defining a real process. >> >> Russ >> >> >> >> >> >> >> On 6/24/2015 7:41 PM, Raystonn wrote: >> >> I would like to start a civil discussion on an undefined, >> or at least unwritten, portion of the BIP process. Who >> should get to vote on approval to commit a BIP >> implementation into Bitcoin Core? Is a simple majority >> of these voters sufficient for approval? If not, then >> what is? >> >> Raystonn >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 18162 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 5:41 ` Milly Bitcoin @ 2015-06-25 6:06 ` Pindar Wong 2015-06-25 6:15 ` Mark Friedenbach 2015-06-25 6:16 ` Warren Togami Jr. 0 siblings, 2 replies; 51+ messages in thread From: Pindar Wong @ 2015-06-25 6:06 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 8900 bytes --] In the process of 'mining consensus', perhaps before voting there should be robust system testing and telemetry. May I ask a questions w.r.t. Process BIPs, what is the process for establishing a new testnet (e.g. for testing with 8MB blocks)? p. On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > These are the kind of silly responses you often get when this subject > comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see > no need for him to use the list to attack people he doesn't agree with > and/or try to interfere with discussions of others on the list. > He turns it into a personality discussion rather than a discussion of > Systems Engineering. He also tries to intimate anyone who brings up the > discussion and "punish" them as a lesson to anyone else who may raise the > issue. > > It is interesting that people like that are attracted to a decentralized > system. The reply is simply an attempt at protecting turf which is why > Mr. Garzik's vague replies are never taken seriously on the subject of > decision-making process for the software. > > Russ > > > > On 6/25/2015 1:07 AM, Jeff Garzik wrote: > > Ladies & gents, please do not feed the troll. This has been explained to > Milly multiple times in the past, on previous mailing list & github with no > impact. > > > On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > >> I'm sorry but that is the kind of defensive, cultish response everyone >> gets when they ask that question. If you had a well constructed documented >> process then you would be able to point to it ... but you can't. While >> there are a few bits and pieces scattered about in different places there >> is no coherent plan or process. >> >> It is easy to make statements like "consensus must be unanimous" but the >> issue is that you never have true 100% consensus yet you have to move >> forward in some fashion and everyone has to run software with the same >> consensus rules. The issue is how you move forward is the question that >> nobody wants to answer because (a) it is a hard question to answer and (b) >> developers see it as a threat to their authority/position. If people just >> keep shutting down the discussion with a bunch of cultish stock answers >> then you are never going to move forward with developing some kind of >> process. >> >> From what I can see much of the discussion is personality-driven and not >> based on Computer Science or and defined process. The issue is that a >> personality has changed so the process is perceived to be different and >> some people want to hard fork. Previously, the cultish answer is that >> Bitcoin development is decentralized because people can fork the code. Now >> that some developers want to fork the code suddenly it is a big problem. >> Is forking the code part of the consensus process or is it the work of the >> devil? The fact that there is so much diverse opinion on this shows a >> defined process has never been fully vetted or understood. >> >> I have worked on these processes for many years for projects orders of >> magnitudes larger than Bitcoin. I can absolutely assure you the current >> mishmash does not scale and huge amounts of time are wasted. That should >> be readily apparent from the recent discussions and the recent concern it >> has caused from people outside the developer's inner circle. >> >> Lack of defined process = high risk and wasted effort. >> >> Russ >> >> >> >> >> >> On 6/24/2015 9:50 PM, Mark Friedenbach wrote: >> >> I'm sorry but this is absolutely not the case, Milly. The reason that >> people get defensive is that we have a carefully constructed process that >> does work (thank you very much!) and is well documented. We talk about it >> quite often in fact as it is a defining characteristic of how bitcoin is >> developed which differs in some ways from how other open source software is >> developed -- although it remains the same in most other ways. >> >> Changes to the non-consensus sections of Bitcoin Core tend to get merged >> when there are a few reviews, tests, and ACKs from recognized developers, >> there are no outstanding objections, and the maintainer doing the merge >> makes a subjective judgement that the code is ready. >> >> Consensus-changes, on the other hand, get merged into Bitcoin Core only >> after the above criteria are met AND an extremely long discussion period >> that has given all the relevant stakeholders a chance to comment, and no >> significant objections remain. Consensus-code changes are unanimous. They >> must be. >> >> The sort of process that exists in standards bodies for example, with >> working groups and formal voting procedures, has no place where changes >> define the nature and validity of other people's money. Who has the right >> to reach into your pocket and define how you can or cannot spend your >> coins? The premise of bitcoin is that no one has that right, yet that is >> very much what we do when consensus code changes are made. That is why when >> we make a change to the rules governing the nature of bitcoin, we must make >> sure that everyone is made aware of the change and consents to it. >> >> Everyone. Does this work? Does this scale? So far, it does. >> Uncontroversial changes, such as BIP 66, are deployed without issue. Every >> indication is that BIP 66 will complete deployment in the very near future, >> and we intend to repeat this process for more interesting changes such as >> BIP65: CHECKLOCKTIMEVERIFY. >> >> This isn't about no one stepping forward to be the "decider." This is >> about no one having the right to decide these things on the behalf of >> others. If a contentious change is proposed and not accepted by the process >> of consensus, that is because the process is doing its job at rejecting >> controversial changes. It has nothing to do with personality, and >> everything to do with the nature of bitcoin itself. >> >> >> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly@bitcoins.info> >> milly@bitcoins.info> wrote: >> >>> I have seen this question asked many times. Most developers become >>> defensive and they usually give a very vague 1-sentence answer when this >>> question is asked. It seems to be it is based on personalities rather than >>> any kind of definable process. To have that discussion the personalities >>> must be separated out and answers like "such-and-such wouldn't do that" >>> don't really do much to advance the discussion. Also, the incentive for >>> new developers to come in is that they will be paid by companies who want >>> to influence the code and this should be considered (some developers take >>> this statement as an insult when it is just a statement of the incentive >>> process). >>> >>> The other problem you are having is the lead developer does not want to >>> be a "decider" when, in fact, he is a very significant decider. While the >>> users have the ultimate choice in a practical sense the chief developer is >>> the "decider." Now people don't want to get him upset so nobody wants to >>> push the issue or fully define the process. Now you are left with a >>> broken, unwritten/unspoken process. While this type of thing may work with >>> a small group of developers businesses/investors looking in from the >>> outside will see this as a risk. >>> >>> Until you get passed all the personality-based arguments you are going >>> to have a tough time defining a real process. >>> >>> Russ >>> >>> >>> >>> >>> >>> >>> On 6/24/2015 7:41 PM, Raystonn wrote: >>> >>>> I would like to start a civil discussion on an undefined, or at least >>>> unwritten, portion of the BIP process. Who should get to vote on approval >>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>>> these voters sufficient for approval? If not, then what is? >>>> >>>> Raystonn >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 18321 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 6:06 ` Pindar Wong @ 2015-06-25 6:15 ` Mark Friedenbach 2015-06-25 6:16 ` Warren Togami Jr. 1 sibling, 0 replies; 51+ messages in thread From: Mark Friedenbach @ 2015-06-25 6:15 UTC (permalink / raw) To: Pindar Wong; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 9493 bytes --] You don't need to ask permission for testnet. Here is one with 100MB blocks: https://github.com/pstratem/bitcoin/tree/testnet4 On Jun 24, 2015 11:06 PM, "Pindar Wong" <pindar.wong@gmail.com> wrote: > In the process of 'mining consensus', perhaps before voting there should > be robust system testing and telemetry. > > May I ask a questions w.r.t. Process BIPs, what is the process for > establishing a new testnet (e.g. for testing with 8MB blocks)? > > p. > > > On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > >> These are the kind of silly responses you often get when this subject >> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see >> no need for him to use the list to attack people he doesn't agree with >> and/or try to interfere with discussions of others on the list. >> He turns it into a personality discussion rather than a discussion of >> Systems Engineering. He also tries to intimate anyone who brings up the >> discussion and "punish" them as a lesson to anyone else who may raise the >> issue. >> >> It is interesting that people like that are attracted to a decentralized >> system. The reply is simply an attempt at protecting turf which is why >> Mr. Garzik's vague replies are never taken seriously on the subject of >> decision-making process for the software. >> >> Russ >> >> >> >> On 6/25/2015 1:07 AM, Jeff Garzik wrote: >> >> Ladies & gents, please do not feed the troll. This has been explained to >> Milly multiple times in the past, on previous mailing list & github with no >> impact. >> >> >> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> >> wrote: >> >>> I'm sorry but that is the kind of defensive, cultish response everyone >>> gets when they ask that question. If you had a well constructed documented >>> process then you would be able to point to it ... but you can't. While >>> there are a few bits and pieces scattered about in different places there >>> is no coherent plan or process. >>> >>> It is easy to make statements like "consensus must be unanimous" but the >>> issue is that you never have true 100% consensus yet you have to move >>> forward in some fashion and everyone has to run software with the same >>> consensus rules. The issue is how you move forward is the question that >>> nobody wants to answer because (a) it is a hard question to answer and (b) >>> developers see it as a threat to their authority/position. If people just >>> keep shutting down the discussion with a bunch of cultish stock answers >>> then you are never going to move forward with developing some kind of >>> process. >>> >>> From what I can see much of the discussion is personality-driven and not >>> based on Computer Science or and defined process. The issue is that a >>> personality has changed so the process is perceived to be different and >>> some people want to hard fork. Previously, the cultish answer is that >>> Bitcoin development is decentralized because people can fork the code. Now >>> that some developers want to fork the code suddenly it is a big problem. >>> Is forking the code part of the consensus process or is it the work of the >>> devil? The fact that there is so much diverse opinion on this shows a >>> defined process has never been fully vetted or understood. >>> >>> I have worked on these processes for many years for projects orders of >>> magnitudes larger than Bitcoin. I can absolutely assure you the current >>> mishmash does not scale and huge amounts of time are wasted. That should >>> be readily apparent from the recent discussions and the recent concern it >>> has caused from people outside the developer's inner circle. >>> >>> Lack of defined process = high risk and wasted effort. >>> >>> Russ >>> >>> >>> >>> >>> >>> On 6/24/2015 9:50 PM, Mark Friedenbach wrote: >>> >>> I'm sorry but this is absolutely not the case, Milly. The reason that >>> people get defensive is that we have a carefully constructed process that >>> does work (thank you very much!) and is well documented. We talk about it >>> quite often in fact as it is a defining characteristic of how bitcoin is >>> developed which differs in some ways from how other open source software is >>> developed -- although it remains the same in most other ways. >>> >>> Changes to the non-consensus sections of Bitcoin Core tend to get >>> merged when there are a few reviews, tests, and ACKs from recognized >>> developers, there are no outstanding objections, and the maintainer doing >>> the merge makes a subjective judgement that the code is ready. >>> >>> Consensus-changes, on the other hand, get merged into Bitcoin Core only >>> after the above criteria are met AND an extremely long discussion period >>> that has given all the relevant stakeholders a chance to comment, and no >>> significant objections remain. Consensus-code changes are unanimous. They >>> must be. >>> >>> The sort of process that exists in standards bodies for example, with >>> working groups and formal voting procedures, has no place where changes >>> define the nature and validity of other people's money. Who has the right >>> to reach into your pocket and define how you can or cannot spend your >>> coins? The premise of bitcoin is that no one has that right, yet that is >>> very much what we do when consensus code changes are made. That is why when >>> we make a change to the rules governing the nature of bitcoin, we must make >>> sure that everyone is made aware of the change and consents to it. >>> >>> Everyone. Does this work? Does this scale? So far, it does. >>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every >>> indication is that BIP 66 will complete deployment in the very near future, >>> and we intend to repeat this process for more interesting changes such as >>> BIP65: CHECKLOCKTIMEVERIFY. >>> >>> This isn't about no one stepping forward to be the "decider." This is >>> about no one having the right to decide these things on the behalf of >>> others. If a contentious change is proposed and not accepted by the process >>> of consensus, that is because the process is doing its job at rejecting >>> controversial changes. It has nothing to do with personality, and >>> everything to do with the nature of bitcoin itself. >>> >>> >>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly@bitcoins.info> >>> milly@bitcoins.info> wrote: >>> >>>> I have seen this question asked many times. Most developers become >>>> defensive and they usually give a very vague 1-sentence answer when this >>>> question is asked. It seems to be it is based on personalities rather than >>>> any kind of definable process. To have that discussion the personalities >>>> must be separated out and answers like "such-and-such wouldn't do that" >>>> don't really do much to advance the discussion. Also, the incentive for >>>> new developers to come in is that they will be paid by companies who want >>>> to influence the code and this should be considered (some developers take >>>> this statement as an insult when it is just a statement of the incentive >>>> process). >>>> >>>> The other problem you are having is the lead developer does not want to >>>> be a "decider" when, in fact, he is a very significant decider. While the >>>> users have the ultimate choice in a practical sense the chief developer is >>>> the "decider." Now people don't want to get him upset so nobody wants to >>>> push the issue or fully define the process. Now you are left with a >>>> broken, unwritten/unspoken process. While this type of thing may work with >>>> a small group of developers businesses/investors looking in from the >>>> outside will see this as a risk. >>>> >>>> Until you get passed all the personality-based arguments you are going >>>> to have a tough time defining a real process. >>>> >>>> Russ >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 6/24/2015 7:41 PM, Raystonn wrote: >>>> >>>>> I would like to start a civil discussion on an undefined, or at least >>>>> unwritten, portion of the BIP process. Who should get to vote on approval >>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>>>> these voters sufficient for approval? If not, then what is? >>>>> >>>>> Raystonn >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 19217 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 6:06 ` Pindar Wong 2015-06-25 6:15 ` Mark Friedenbach @ 2015-06-25 6:16 ` Warren Togami Jr. 2015-06-25 6:27 ` Pindar Wong 1 sibling, 1 reply; 51+ messages in thread From: Warren Togami Jr. @ 2015-06-25 6:16 UTC (permalink / raw) To: Pindar Wong; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 9757 bytes --] https://github.com/pstratem/bitcoin/commits/testnet4 See these two commits for an example of changing all the testnet chain parameters to create an entirely separate testnet network. This example "testnet4" changed to different port numbers, pchMessageStart magic, and with stupid large block sizes. http://rusty.ozlabs.org/?p=509 Rusty used this to test block propagation latency. On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong@gmail.com> wrote: > In the process of 'mining consensus', perhaps before voting there should > be robust system testing and telemetry. > > May I ask a questions w.r.t. Process BIPs, what is the process for > establishing a new testnet (e.g. for testing with 8MB blocks)? > > p. > > > On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > >> These are the kind of silly responses you often get when this subject >> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see >> no need for him to use the list to attack people he doesn't agree with >> and/or try to interfere with discussions of others on the list. >> He turns it into a personality discussion rather than a discussion of >> Systems Engineering. He also tries to intimate anyone who brings up the >> discussion and "punish" them as a lesson to anyone else who may raise the >> issue. >> >> It is interesting that people like that are attracted to a decentralized >> system. The reply is simply an attempt at protecting turf which is why >> Mr. Garzik's vague replies are never taken seriously on the subject of >> decision-making process for the software. >> >> Russ >> >> >> >> On 6/25/2015 1:07 AM, Jeff Garzik wrote: >> >> Ladies & gents, please do not feed the troll. This has been explained to >> Milly multiple times in the past, on previous mailing list & github with no >> impact. >> >> >> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> >> wrote: >> >>> I'm sorry but that is the kind of defensive, cultish response everyone >>> gets when they ask that question. If you had a well constructed documented >>> process then you would be able to point to it ... but you can't. While >>> there are a few bits and pieces scattered about in different places there >>> is no coherent plan or process. >>> >>> It is easy to make statements like "consensus must be unanimous" but the >>> issue is that you never have true 100% consensus yet you have to move >>> forward in some fashion and everyone has to run software with the same >>> consensus rules. The issue is how you move forward is the question that >>> nobody wants to answer because (a) it is a hard question to answer and (b) >>> developers see it as a threat to their authority/position. If people just >>> keep shutting down the discussion with a bunch of cultish stock answers >>> then you are never going to move forward with developing some kind of >>> process. >>> >>> From what I can see much of the discussion is personality-driven and not >>> based on Computer Science or and defined process. The issue is that a >>> personality has changed so the process is perceived to be different and >>> some people want to hard fork. Previously, the cultish answer is that >>> Bitcoin development is decentralized because people can fork the code. Now >>> that some developers want to fork the code suddenly it is a big problem. >>> Is forking the code part of the consensus process or is it the work of the >>> devil? The fact that there is so much diverse opinion on this shows a >>> defined process has never been fully vetted or understood. >>> >>> I have worked on these processes for many years for projects orders of >>> magnitudes larger than Bitcoin. I can absolutely assure you the current >>> mishmash does not scale and huge amounts of time are wasted. That should >>> be readily apparent from the recent discussions and the recent concern it >>> has caused from people outside the developer's inner circle. >>> >>> Lack of defined process = high risk and wasted effort. >>> >>> Russ >>> >>> >>> >>> >>> >>> On 6/24/2015 9:50 PM, Mark Friedenbach wrote: >>> >>> I'm sorry but this is absolutely not the case, Milly. The reason that >>> people get defensive is that we have a carefully constructed process that >>> does work (thank you very much!) and is well documented. We talk about it >>> quite often in fact as it is a defining characteristic of how bitcoin is >>> developed which differs in some ways from how other open source software is >>> developed -- although it remains the same in most other ways. >>> >>> Changes to the non-consensus sections of Bitcoin Core tend to get >>> merged when there are a few reviews, tests, and ACKs from recognized >>> developers, there are no outstanding objections, and the maintainer doing >>> the merge makes a subjective judgement that the code is ready. >>> >>> Consensus-changes, on the other hand, get merged into Bitcoin Core only >>> after the above criteria are met AND an extremely long discussion period >>> that has given all the relevant stakeholders a chance to comment, and no >>> significant objections remain. Consensus-code changes are unanimous. They >>> must be. >>> >>> The sort of process that exists in standards bodies for example, with >>> working groups and formal voting procedures, has no place where changes >>> define the nature and validity of other people's money. Who has the right >>> to reach into your pocket and define how you can or cannot spend your >>> coins? The premise of bitcoin is that no one has that right, yet that is >>> very much what we do when consensus code changes are made. That is why when >>> we make a change to the rules governing the nature of bitcoin, we must make >>> sure that everyone is made aware of the change and consents to it. >>> >>> Everyone. Does this work? Does this scale? So far, it does. >>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every >>> indication is that BIP 66 will complete deployment in the very near future, >>> and we intend to repeat this process for more interesting changes such as >>> BIP65: CHECKLOCKTIMEVERIFY. >>> >>> This isn't about no one stepping forward to be the "decider." This is >>> about no one having the right to decide these things on the behalf of >>> others. If a contentious change is proposed and not accepted by the process >>> of consensus, that is because the process is doing its job at rejecting >>> controversial changes. It has nothing to do with personality, and >>> everything to do with the nature of bitcoin itself. >>> >>> >>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly@bitcoins.info> >>> milly@bitcoins.info> wrote: >>> >>>> I have seen this question asked many times. Most developers become >>>> defensive and they usually give a very vague 1-sentence answer when this >>>> question is asked. It seems to be it is based on personalities rather than >>>> any kind of definable process. To have that discussion the personalities >>>> must be separated out and answers like "such-and-such wouldn't do that" >>>> don't really do much to advance the discussion. Also, the incentive for >>>> new developers to come in is that they will be paid by companies who want >>>> to influence the code and this should be considered (some developers take >>>> this statement as an insult when it is just a statement of the incentive >>>> process). >>>> >>>> The other problem you are having is the lead developer does not want to >>>> be a "decider" when, in fact, he is a very significant decider. While the >>>> users have the ultimate choice in a practical sense the chief developer is >>>> the "decider." Now people don't want to get him upset so nobody wants to >>>> push the issue or fully define the process. Now you are left with a >>>> broken, unwritten/unspoken process. While this type of thing may work with >>>> a small group of developers businesses/investors looking in from the >>>> outside will see this as a risk. >>>> >>>> Until you get passed all the personality-based arguments you are going >>>> to have a tough time defining a real process. >>>> >>>> Russ >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 6/24/2015 7:41 PM, Raystonn wrote: >>>> >>>>> I would like to start a civil discussion on an undefined, or at least >>>>> unwritten, portion of the BIP process. Who should get to vote on approval >>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>>>> these voters sufficient for approval? If not, then what is? >>>>> >>>>> Raystonn >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 19798 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 6:16 ` Warren Togami Jr. @ 2015-06-25 6:27 ` Pindar Wong 0 siblings, 0 replies; 51+ messages in thread From: Pindar Wong @ 2015-06-25 6:27 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 10139 bytes --] Thank you very much Mark and Warren this is most helpful. Regards, p. On Thu, Jun 25, 2015 at 2:16 PM, Warren Togami Jr. <wtogami@gmail.com> wrote: > https://github.com/pstratem/bitcoin/commits/testnet4 > > See these two commits for an example of changing all the testnet chain > parameters to create an entirely separate testnet network. This example > "testnet4" changed to different port numbers, pchMessageStart magic, and > with stupid large block sizes. > > http://rusty.ozlabs.org/?p=509 > Rusty used this to test block propagation latency. > > On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pindar.wong@gmail.com> > wrote: > >> In the process of 'mining consensus', perhaps before voting there should >> be robust system testing and telemetry. >> >> May I ask a questions w.r.t. Process BIPs, what is the process for >> establishing a new testnet (e.g. for testing with 8MB blocks)? >> >> p. >> >> >> On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly@bitcoins.info> >> wrote: >> >>> These are the kind of silly responses you often get when this subject >>> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see >>> no need for him to use the list to attack people he doesn't agree with >>> and/or try to interfere with discussions of others on the list. >>> He turns it into a personality discussion rather than a discussion of >>> Systems Engineering. He also tries to intimate anyone who brings up the >>> discussion and "punish" them as a lesson to anyone else who may raise the >>> issue. >>> >>> It is interesting that people like that are attracted to a decentralized >>> system. The reply is simply an attempt at protecting turf which is why >>> Mr. Garzik's vague replies are never taken seriously on the subject of >>> decision-making process for the software. >>> >>> Russ >>> >>> >>> >>> On 6/25/2015 1:07 AM, Jeff Garzik wrote: >>> >>> Ladies & gents, please do not feed the troll. This has been explained >>> to Milly multiple times in the past, on previous mailing list & github with >>> no impact. >>> >>> >>> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> >>> wrote: >>> >>>> I'm sorry but that is the kind of defensive, cultish response >>>> everyone gets when they ask that question. If you had a well constructed >>>> documented process then you would be able to point to it ... but you >>>> can't. While there are a few bits and pieces scattered about in different >>>> places there is no coherent plan or process. >>>> >>>> It is easy to make statements like "consensus must be unanimous" but >>>> the issue is that you never have true 100% consensus yet you have to move >>>> forward in some fashion and everyone has to run software with the same >>>> consensus rules. The issue is how you move forward is the question that >>>> nobody wants to answer because (a) it is a hard question to answer and (b) >>>> developers see it as a threat to their authority/position. If people just >>>> keep shutting down the discussion with a bunch of cultish stock answers >>>> then you are never going to move forward with developing some kind of >>>> process. >>>> >>>> From what I can see much of the discussion is personality-driven and >>>> not based on Computer Science or and defined process. The issue is that a >>>> personality has changed so the process is perceived to be different and >>>> some people want to hard fork. Previously, the cultish answer is that >>>> Bitcoin development is decentralized because people can fork the code. Now >>>> that some developers want to fork the code suddenly it is a big problem. >>>> Is forking the code part of the consensus process or is it the work of the >>>> devil? The fact that there is so much diverse opinion on this shows a >>>> defined process has never been fully vetted or understood. >>>> >>>> I have worked on these processes for many years for projects orders of >>>> magnitudes larger than Bitcoin. I can absolutely assure you the current >>>> mishmash does not scale and huge amounts of time are wasted. That should >>>> be readily apparent from the recent discussions and the recent concern it >>>> has caused from people outside the developer's inner circle. >>>> >>>> Lack of defined process = high risk and wasted effort. >>>> >>>> Russ >>>> >>>> >>>> >>>> >>>> >>>> On 6/24/2015 9:50 PM, Mark Friedenbach wrote: >>>> >>>> I'm sorry but this is absolutely not the case, Milly. The reason >>>> that people get defensive is that we have a carefully constructed process >>>> that does work (thank you very much!) and is well documented. We talk about >>>> it quite often in fact as it is a defining characteristic of how bitcoin is >>>> developed which differs in some ways from how other open source software is >>>> developed -- although it remains the same in most other ways. >>>> >>>> Changes to the non-consensus sections of Bitcoin Core tend to get >>>> merged when there are a few reviews, tests, and ACKs from recognized >>>> developers, there are no outstanding objections, and the maintainer doing >>>> the merge makes a subjective judgement that the code is ready. >>>> >>>> Consensus-changes, on the other hand, get merged into Bitcoin Core >>>> only after the above criteria are met AND an extremely long discussion >>>> period that has given all the relevant stakeholders a chance to comment, >>>> and no significant objections remain. Consensus-code changes are unanimous. >>>> They must be. >>>> >>>> The sort of process that exists in standards bodies for example, with >>>> working groups and formal voting procedures, has no place where changes >>>> define the nature and validity of other people's money. Who has the right >>>> to reach into your pocket and define how you can or cannot spend your >>>> coins? The premise of bitcoin is that no one has that right, yet that is >>>> very much what we do when consensus code changes are made. That is why when >>>> we make a change to the rules governing the nature of bitcoin, we must make >>>> sure that everyone is made aware of the change and consents to it. >>>> >>>> Everyone. Does this work? Does this scale? So far, it does. >>>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every >>>> indication is that BIP 66 will complete deployment in the very near future, >>>> and we intend to repeat this process for more interesting changes such as >>>> BIP65: CHECKLOCKTIMEVERIFY. >>>> >>>> This isn't about no one stepping forward to be the "decider." This is >>>> about no one having the right to decide these things on the behalf of >>>> others. If a contentious change is proposed and not accepted by the process >>>> of consensus, that is because the process is doing its job at rejecting >>>> controversial changes. It has nothing to do with personality, and >>>> everything to do with the nature of bitcoin itself. >>>> >>>> >>>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly@bitcoins.info> >>>> milly@bitcoins.info> wrote: >>>> >>>>> I have seen this question asked many times. Most developers become >>>>> defensive and they usually give a very vague 1-sentence answer when this >>>>> question is asked. It seems to be it is based on personalities rather than >>>>> any kind of definable process. To have that discussion the personalities >>>>> must be separated out and answers like "such-and-such wouldn't do that" >>>>> don't really do much to advance the discussion. Also, the incentive for >>>>> new developers to come in is that they will be paid by companies who want >>>>> to influence the code and this should be considered (some developers take >>>>> this statement as an insult when it is just a statement of the incentive >>>>> process). >>>>> >>>>> The other problem you are having is the lead developer does not want >>>>> to be a "decider" when, in fact, he is a very significant decider. While >>>>> the users have the ultimate choice in a practical sense the chief developer >>>>> is the "decider." Now people don't want to get him upset so nobody wants >>>>> to push the issue or fully define the process. Now you are left with a >>>>> broken, unwritten/unspoken process. While this type of thing may work with >>>>> a small group of developers businesses/investors looking in from the >>>>> outside will see this as a risk. >>>>> >>>>> Until you get passed all the personality-based arguments you are going >>>>> to have a tough time defining a real process. >>>>> >>>>> Russ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 6/24/2015 7:41 PM, Raystonn wrote: >>>>> >>>>>> I would like to start a civil discussion on an undefined, or at least >>>>>> unwritten, portion of the BIP process. Who should get to vote on approval >>>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of >>>>>> these voters sufficient for approval? If not, then what is? >>>>>> >>>>>> Raystonn >>>>>> _______________________________________________ >>>>>> bitcoin-dev mailing list >>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > [-- Attachment #2: Type: text/html, Size: 20324 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 5:07 ` Jeff Garzik 2015-06-25 5:41 ` Milly Bitcoin @ 2015-06-25 7:51 ` cipher anthem 2015-06-25 10:09 ` nxtchg 2015-06-25 12:42 ` Milly Bitcoin 1 sibling, 2 replies; 51+ messages in thread From: cipher anthem @ 2015-06-25 7:51 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/html, Size: 10062 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 7:51 ` cipher anthem @ 2015-06-25 10:09 ` nxtchg 2015-06-25 12:42 ` Milly Bitcoin 1 sibling, 0 replies; 51+ messages in thread From: nxtchg @ 2015-06-25 10:09 UTC (permalink / raw) To: cipher anthem, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 359 bytes --] You just proved his point once again with yet another ad hominem :) Good job. On 6/25/2015 at 10:56 AM, "cipher anthem" wrote:+1 on this! I have come across Milly a couple of times on reddit and disqus and she basically dismisses anyone who doesn't agree with her opinions. always labeling them "cultish". Please ignore her so you can stay productive. [-- Attachment #2: Type: text/html, Size: 660 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 7:51 ` cipher anthem 2015-06-25 10:09 ` nxtchg @ 2015-06-25 12:42 ` Milly Bitcoin 1 sibling, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 12:42 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 9664 bytes --] "Cultish" means making claims without any supporting facts. Labeling Open Source software as being "decentralized" just because people can choose which version to run is a "cultish" claim. Just because Bitcoin uses the mining process to come to consensus over the state of the ledger that does not mean the software versions have the same level of decentralization because users can decide which version to run. I am in the USA and I can vote in elections but I would not call the US government "decentralized." It is a very complicated issue and cannot be explained in one or two sentences of hand-waiving arguments like you often see here. Russ On 6/25/2015 3:51 AM, cipher anthem wrote: > +1 on this! > > I have come across Milly a couple of times on reddit and disqus and > she basically dismisses anyone who doesn't agree with her opinions. > always labeling them "cultish". Please ignore her so you can stay > productive. > *Sent:* Thursday, June 25, 2015 at 5:07 AM > *From:* "Jeff Garzik" <jgarzik@gmail.com> > *To:* bitcoin-dev@lists.linuxfoundation.org > *Subject:* Re: [bitcoin-dev] BIP Process and Votes > Ladies & gents, please do not feed the troll. This has been explained > to Milly multiple times in the past, on previous mailing list & github > with no impact. > On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > > I'm sorry but that is the kind of defensive, cultish response > everyone gets when they ask that question. If you had a well > constructed documented process then you would be able to point to > it ... but you can't. While there are a few bits and pieces > scattered about in different places there is no coherent plan or > process. > > It is easy to make statements like "consensus must be unanimous" > but the issue is that you never have true 100% consensus yet you > have to move forward in some fashion and everyone has to run > software with the same consensus rules. The issue is how you move > forward is the question that nobody wants to answer because (a) it > is a hard question to answer and (b) developers see it as a threat > to their authority/position. If people just keep shutting down > the discussion with a bunch of cultish stock answers then you are > never going to move forward with developing some kind of process. > > >From what I can see much of the discussion is personality-driven > and not based on Computer Science or and defined process. The > issue is that a personality has changed so the process is > perceived to be different and some people want to hard fork. > Previously, the cultish answer is that Bitcoin development is > decentralized because people can fork the code. Now that some > developers want to fork the code suddenly it is a big problem. > Is forking the code part of the consensus process or is it the > work of the devil? The fact that there is so much diverse > opinion on this shows a defined process has never been fully > vetted or understood. > > I have worked on these processes for many years for projects > orders of magnitudes larger than Bitcoin. I can absolutely assure > you the current mishmash does not scale and huge amounts of time > are wasted. That should be readily apparent from the recent > discussions and the recent concern it has caused from people > outside the developer's inner circle. > > Lack of defined process = high risk and wasted effort. > > Russ > > > > > > On 6/24/2015 9:50 PM, Mark Friedenbach wrote: > > I'm sorry but this is absolutely not the case, Milly. The > reason that people get defensive is that we have a carefully > constructed process that does work (thank you very much!) and > is well documented. We talk about it quite often in fact as it > is a defining characteristic of how bitcoin is developed which > differs in some ways from how other open source software is > developed -- although it remains the same in most other ways. > Changes to the non-consensus sections of Bitcoin Core tend to > get merged when there are a few reviews, tests, and ACKs from > recognized developers, there are no outstanding objections, > and the maintainer doing the merge makes a subjective > judgement that the code is ready. > Consensus-changes, on the other hand, get merged into Bitcoin > Core only after the above criteria are met AND an extremely > long discussion period that has given all the relevant > stakeholders a chance to comment, and no significant > objections remain. Consensus-code changes are unanimous. They > must be. > The sort of process that exists in standards bodies for > example, with working groups and formal voting procedures, has > no place where changes define the nature and validity of other > people's money. Who has the right to reach into your pocket > and define how you can or cannot spend your coins? The premise > of bitcoin is that no one has that right, yet that is very > much what we do when consensus code changes are made. That is > why when we make a change to the rules governing the nature of > bitcoin, we must make sure that everyone is made aware of the > change and consents to it. > Everyone. Does this work? Does this scale? So far, it does. > Uncontroversial changes, such as BIP 66, are deployed without > issue. Every indication is that BIP 66 will complete > deployment in the very near future, and we intend to repeat > this process for more interesting changes such as BIP65: > CHECKLOCKTIMEVERIFY. > This isn't about no one stepping forward to be the "decider." > This is about no one having the right to decide these things > on the behalf of others. If a contentious change is proposed > and not accepted by the process of consensus, that is because > the process is doing its job at rejecting controversial > changes. It has nothing to do with personality, and everything > to do with the nature of bitcoin itself. > On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin > <milly@bitcoins.info> wrote: > > I have seen this question asked many times. Most > developers become defensive and they usually give a very > vague 1-sentence answer when this question is asked. It > seems to be it is based on personalities rather than any > kind of definable process. To have that discussion the > personalities must be separated out and answers like > "such-and-such wouldn't do that" don't really do much to > advance the discussion. Also, the incentive for new > developers to come in is that they will be paid by > companies who want to influence the code and this should > be considered (some developers take this statement as an > insult when it is just a statement of the incentive process). > > The other problem you are having is the lead developer > does not want to be a "decider" when, in fact, he is a > very significant decider. While the users have the > ultimate choice in a practical sense the chief developer > is the "decider." Now people don't want to get him upset > so nobody wants to push the issue or fully define the > process. Now you are left with a broken, > unwritten/unspoken process. While this type of thing may > work with a small group of developers businesses/investors > looking in from the outside will see this as a risk. > > Until you get passed all the personality-based arguments > you are going to have a tough time defining a real process. > > Russ > > > > > > > On 6/24/2015 7:41 PM, Raystonn wrote: > > I would like to start a civil discussion on an > undefined, or at least unwritten, portion of the BIP > process. Who should get to vote on approval to commit > a BIP implementation into Bitcoin Core? Is a simple > majority of these voters sufficient for approval? If > not, then what is? > > Raystonn > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 24495 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 1:50 ` Mark Friedenbach 2015-06-25 2:30 ` Alex Morcos 2015-06-25 2:34 ` Milly Bitcoin @ 2015-06-25 20:05 ` Tier Nolan 2015-06-26 0:42 ` Milly Bitcoin 2 siblings, 1 reply; 51+ messages in thread From: Tier Nolan @ 2015-06-25 20:05 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2888 bytes --] On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <mark@friedenbach.org> wrote: > I'm sorry but this is absolutely not the case, Milly. The reason that > people get defensive is that we have a carefully constructed process that > does work (thank you very much!) and is well documented. > There is no process for handling hard forks, which aren't bug fixes. Soft forks have a defined process of something like - BIP proposal + discussion - Proposed code - Dev acceptance - Release - Miner vote/acceptance The devs have a weak veto. If they refuse to move forward with changes, miners could perform a soft fork on their own. They don't want to do that, as it would be controversial and the devs know the software better. The miner veto is stronger (for soft forks) but not absolute. The devs could checkpoint/blacklist a chain if miners implemented a fork that wasn't acceptable (assuming the community backed them). When ASICs arrived, it was pointed out by some that the devs could hit back if ASICs weren't made publicly available. If they slightly tweaked the hashing algorithm, then current generation of ASICs would be useless. The potential threat may have acted as a disincentive for ASIC manufacturers to use the ASICs themselves. Moving forward with agreement between all involved is the recommended and desirable approach. Consensus between all parties is the goal but isn't absolutely required. This escape valve is partly what makes consensus work. If you dig your heels in, then the other side can bypass you, but they have an incentive to try to convince you to compromise first. The outcome is better if a middle ground can be found. Hard forks are different. The "checks and balances" of weak vetoes are not present. This means that things can devolve from consensus to mutual veto. Consensus ceases to be a goal and becomes a requirement. This is partly a reflection of the nature of hard forks. Everyone needs to upgrade. On the other hand, if most of the various groups upgrade, then users of the legacy software would have to upgrade or get left behind. If 5% of the users decided not to upgrade, should they be allowed to demand that nobody else does? There is clearly some kind of threshold that is reasonable. The fundamental problem is that there isn't agreement on what the block size is. Is it equal in status to the 21 million BTC limit? If Satoshi had said that 1MB was part of the definition of Bitcoin, then I think people would accept it to the same extent as they accept the 21 million coin limit. It might cause people to leave the coin though. It was intended to be temporary, but people have realized that it might be a good idea to keep it. In effect both sides could argue that they should be considered the status quo. I wonder if a coin toss would be acceptable :). "Come to an agreement or we decide by coin toss" [-- Attachment #2: Type: text/html, Size: 3632 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 20:05 ` Tier Nolan @ 2015-06-26 0:42 ` Milly Bitcoin 2015-07-01 22:34 ` odinn 0 siblings, 1 reply; 51+ messages in thread From: Milly Bitcoin @ 2015-06-26 0:42 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4605 bytes --] That description makes sense. It also makes sense to separate out the hard fork from the soft fork process. Right now some people want to use the soft fork procedure for a hard fork simply because there is no other way to do it. I am under the impression that most users expect changes/improvements that would require a hard fork so I think some kind of process needs to be developed. Taking the responsibility off the shoulder of the core maintainer also makes sense. The hard fork issue is too much of a distraction for people trying to maintain the nuts and bolts of the underlying system. I saw a suggestion that regularly scheduled hard forks should be planned. That seems to make sense so you would have some sort of schedule where you would have cut off dates for hard-fork BIP submissions. That way you avoid the debates over whether there should be hard forks to what should be contained within the hard fork (if needed). It makes sense to follow the BIP process as close as possible. Possibly adding another step after "Dev acceptance" to include input from others such as merchants/exchanges/miners/users. It will only be an approximation of "decentralization" and the process won't be perfect but if you want to move forward then you need some way to do it. Russ On 6/25/2015 4:05 PM, Tier Nolan wrote: > On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach > <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote: > > I'm sorry but this is absolutely not the case, Milly. The reason > that people get defensive is that we have a carefully constructed > process that does work (thank you very much!) and is well documented. > > > There is no process for handling hard forks, which aren't bug fixes. > > Soft forks have a defined process of something like > > - BIP proposal + discussion > - Proposed code > - Dev acceptance > - Release > - Miner vote/acceptance > > The devs have a weak veto. If they refuse to move forward with > changes, miners could perform a soft fork on their own. They don't > want to do that, as it would be controversial and the devs know the > software better. > > The miner veto is stronger (for soft forks) but not absolute. The > devs could checkpoint/blacklist a chain if miners implemented a fork > that wasn't acceptable (assuming the community backed them). > > When ASICs arrived, it was pointed out by some that the devs could hit > back if ASICs weren't made publicly available. If they slightly > tweaked the hashing algorithm, then current generation of ASICs would > be useless. The potential threat may have acted as a disincentive > for ASIC manufacturers to use the ASICs themselves. > > Moving forward with agreement between all involved is the recommended > and desirable approach. > > Consensus between all parties is the goal but isn't absolutely > required. This escape valve is partly what makes consensus work. If > you dig your heels in, then the other side can bypass you, but they > have an incentive to try to convince you to compromise first. The > outcome is better if a middle ground can be found. > > Hard forks are different. The "checks and balances" of weak vetoes > are not present. This means that things can devolve from consensus to > mutual veto. Consensus ceases to be a goal and becomes a requirement. > > This is partly a reflection of the nature of hard forks. Everyone > needs to upgrade. On the other hand, if most of the various groups > upgrade, then users of the legacy software would have to upgrade or > get left behind. If 5% of the users decided not to upgrade, should > they be allowed to demand that nobody else does? > > There is clearly some kind of threshold that is reasonable. > > The fundamental problem is that there isn't agreement on what the > block size is. Is it equal in status to the 21 million BTC limit? > > If Satoshi had said that 1MB was part of the definition of Bitcoin, > then I think people would accept it to the same extent as they accept > the 21 million coin limit. It might cause people to leave the coin > though. > > It was intended to be temporary, but people have realized that it > might be a good idea to keep it. In effect both sides could argue > that they should be considered the status quo. > > I wonder if a coin toss would be acceptable :). "Come to an agreement > or we decide by coin toss" > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 7579 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-26 0:42 ` Milly Bitcoin @ 2015-07-01 22:34 ` odinn 0 siblings, 0 replies; 51+ messages in thread From: odinn @ 2015-07-01 22:34 UTC (permalink / raw) To: Milly Bitcoin, bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Possibly relevant to this discussion (though old) https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I think?) and https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork (which cites gavin's gist shown above) On 06/25/2015 05:42 PM, Milly Bitcoin wrote: > That description makes sense. It also makes sense to separate out > the hard fork from the soft fork process. Right now some people > want to use the soft fork procedure for a hard fork simply because > there is no other way to do it. > > I am under the impression that most users expect > changes/improvements that would require a hard fork so I think some > kind of process needs to be developed. Taking the responsibility > off the shoulder of the core maintainer also makes sense. The hard > fork issue is too much of a distraction for people trying to > maintain the nuts and bolts of the underlying system. > > I saw a suggestion that regularly scheduled hard forks should be > planned. That seems to make sense so you would have some sort of > schedule where you would have cut off dates for hard-fork BIP > submissions. That way you avoid the debates over whether there > should be hard forks to what should be contained within the hard > fork (if needed). It makes sense to follow the BIP process as > close as possible. Possibly adding another step after "Dev > acceptance" to include input from others such as > merchants/exchanges/miners/users. It will only be an approximation > of "decentralization" and the process won't be perfect but if you > want to move forward then you need some way to do it. > > Russ > > > On 6/25/2015 4:05 PM, Tier Nolan wrote: >> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach >> <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote: >> >> I'm sorry but this is absolutely not the case, Milly. The reason >> that people get defensive is that we have a carefully >> constructed process that does work (thank you very much!) and is >> well documented. >> >> >> There is no process for handling hard forks, which aren't bug >> fixes. >> >> Soft forks have a defined process of something like >> >> - BIP proposal + discussion - Proposed code - Dev acceptance - >> Release - Miner vote/acceptance >> >> The devs have a weak veto. If they refuse to move forward with >> changes, miners could perform a soft fork on their own. They >> don't want to do that, as it would be controversial and the devs >> know the software better. >> >> The miner veto is stronger (for soft forks) but not absolute. >> The devs could checkpoint/blacklist a chain if miners implemented >> a fork that wasn't acceptable (assuming the community backed >> them). >> >> When ASICs arrived, it was pointed out by some that the devs >> could hit back if ASICs weren't made publicly available. If they >> slightly tweaked the hashing algorithm, then current generation >> of ASICs would be useless. The potential threat may have acted >> as a disincentive for ASIC manufacturers to use the ASICs >> themselves. >> >> Moving forward with agreement between all involved is the >> recommended and desirable approach. >> >> Consensus between all parties is the goal but isn't absolutely >> required. This escape valve is partly what makes consensus work. >> If you dig your heels in, then the other side can bypass you, but >> they have an incentive to try to convince you to compromise >> first. The outcome is better if a middle ground can be found. >> >> Hard forks are different. The "checks and balances" of weak >> vetoes are not present. This means that things can devolve from >> consensus to mutual veto. Consensus ceases to be a goal and >> becomes a requirement. >> >> This is partly a reflection of the nature of hard forks. >> Everyone needs to upgrade. On the other hand, if most of the >> various groups upgrade, then users of the legacy software would >> have to upgrade or get left behind. If 5% of the users decided >> not to upgrade, should they be allowed to demand that nobody else >> does? >> >> There is clearly some kind of threshold that is reasonable. >> >> The fundamental problem is that there isn't agreement on what >> the block size is. Is it equal in status to the 21 million BTC >> limit? >> >> If Satoshi had said that 1MB was part of the definition of >> Bitcoin, then I think people would accept it to the same extent >> as they accept the 21 million coin limit. It might cause people >> to leave the coin though. >> >> It was intended to be temporary, but people have realized that >> it might be a good idea to keep it. In effect both sides could >> argue that they should be considered the status quo. >> >> I wonder if a coin toss would be acceptable :). "Come to an >> agreement or we decide by coin toss" >> >> >> _______________________________________________ bitcoin-dev >> mailing list bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI= =n7Pa -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 0:07 ` Milly Bitcoin 2015-06-25 1:50 ` Mark Friedenbach @ 2015-06-25 3:42 ` Gareth Williams 2015-06-25 4:10 ` Milly Bitcoin 2015-06-25 13:36 ` s7r 2 siblings, 1 reply; 51+ messages in thread From: Gareth Williams @ 2015-06-25 3:42 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly@bitcoins.info> wrote: <snip> > Also, the incentive for new > developers to come in is that they will be paid by companies who want to > influence the code and this should be considered <snip> > Now you are left with a broken, unwritten/unspoken process. Your former statement is a great example of why "rough consensus and running code" is superior to design by committee. An argument should be assessed on its technical merit alone, not on the number of people advancing it -- a process that would be open to exactly the type of external manipulation you say you are concerned about. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 3:42 ` Gareth Williams @ 2015-06-25 4:10 ` Milly Bitcoin 0 siblings, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 4:10 UTC (permalink / raw) To: bitcoin-dev I am not giving an opinion on the incentive process for developers. I am just saying it exists and it needs to be taken into account when developing a process. Pretending it doesn't exist or taking it as some kind of personal insult does not do anything to advance the process. The developer incentives feeds into the consensus process. Depending on some kind of "rough consensus" with unstated personality-based rules of the game works fine with small projects. As the project gets larger that does not scale as can be seen with the recent events. That is just a taste of what will happen in the future as new issue arise. Developers will end up spending all day tweeting and making videos instead of writing code. The current process does not guarantee changes are approved on technical merit alone and that is part of the problem. Since there is no defined process people make claims of all sorts of motives that may or may not exist. The idea is to get a defined process that gives a certain level of assurance to outsiders that the process is based on things like technical merit. Russ On 6/24/2015 11:42 PM, Gareth Williams wrote: > On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly@bitcoins.info> > wrote: > <snip> >> Also, the incentive for new >> developers to come in is that they will be paid by companies who want to >> influence the code and this should be considered > <snip> >> Now you are left with a broken, unwritten/unspoken process. > Your former statement is a great example of why "rough consensus and > running code" is superior to design by committee. > An argument should be assessed on its technical merit alone, not on > the number of people advancing it -- a process that would be open to > exactly the type of external manipulation you say you are concerned > about. > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 0:07 ` Milly Bitcoin 2015-06-25 1:50 ` Mark Friedenbach 2015-06-25 3:42 ` Gareth Williams @ 2015-06-25 13:36 ` s7r 2015-06-25 13:41 ` Eric Lombrozo 2 siblings, 1 reply; 51+ messages in thread From: s7r @ 2015-06-25 13:36 UTC (permalink / raw) To: Milly Bitcoin, bitcoin-dev I guess you mean Wladimir here. You are wrong, Wladimir does decide and if you look at the commit history on github.com for bitcoin core you will see, that he does actually decide and does it really good. He just does not want to decide (and he really should not) on CONSENSUS changes or protocol changes. This is totally different. Stop the analogy with "other open source projects". This is an open source project (the code part) but unlike any other open source projects which can just be forked, without affecting the other users, in bitcoin we need all the users to trust a single blockchain, so it'll have value. If some users fork the blockchain and change consensus rules, they are not just harming themselves, they are affecting ALL the users, since such a thing would have strong impact over the BTC/FIAT rate, affecting everyone in the ecosystem. There is economics involved here and human element, things which are hard to fix via code, even if the code is developed in open source style. It's one thing to decide to merge some patches, improve the code, etc. and another thing to decide for consensus rules when you literary play with 4 billion united states dollars of other people's money. This shouldn't be Wladimir's responsibility, it's just unfair for people to throw this on his shoulders. I do not under any circumstances suggest that the consensus should remain as it is now forever. We need to improve it, but this should not be on the maintainer. I've seen smart suggestions on this mail list where consensus changes can be made during a long period of time, through soft forks, where all users/miners/exchangers/merchants get the chance to choose / take action. On 6/25/2015 3:07 AM, Milly Bitcoin wrote: > I have seen this question asked many times. Most developers become > defensive and they usually give a very vague 1-sentence answer when this > question is asked. It seems to be it is based on personalities rather > than any kind of definable process. To have that discussion the > personalities must be separated out and answers like "such-and-such > wouldn't do that" don't really do much to advance the discussion. Also, > the incentive for new developers to come in is that they will be paid by > companies who want to influence the code and this should be considered > (some developers take this statement as an insult when it is just a > statement of the incentive process). > > The other problem you are having is the lead developer does not want to > be a "decider" when, in fact, he is a very significant decider. While > the users have the ultimate choice in a practical sense the chief > developer is the "decider." Now people don't want to get him upset so > nobody wants to push the issue or fully define the process. Now you are > left with a broken, unwritten/unspoken process. While this type of > thing may work with a small group of developers businesses/investors > looking in from the outside will see this as a risk. > > Until you get passed all the personality-based arguments you are going > to have a tough time defining a real process. > > Russ > > > > > > On 6/24/2015 7:41 PM, Raystonn wrote: >> I would like to start a civil discussion on an undefined, or at least >> unwritten, portion of the BIP process. Who should get to vote on >> approval to commit a BIP implementation into Bitcoin Core? Is a >> simple majority of these voters sufficient for approval? If not, then >> what is? >> >> Raystonn >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 13:36 ` s7r @ 2015-06-25 13:41 ` Eric Lombrozo 2015-06-25 13:51 ` s7r ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: Eric Lombrozo @ 2015-06-25 13:41 UTC (permalink / raw) To: s7r; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4423 bytes --] Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please. - Eric Lombrozo > On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip.org> wrote: > > I guess you mean Wladimir here. You are wrong, Wladimir does decide and > if you look at the commit history on github.com for bitcoin core you > will see, that he does actually decide and does it really good. > > He just does not want to decide (and he really should not) on CONSENSUS > changes or protocol changes. This is totally different. > > Stop the analogy with "other open source projects". This is an open > source project (the code part) but unlike any other open source projects > which can just be forked, without affecting the other users, in bitcoin > we need all the users to trust a single blockchain, so it'll have value. > If some users fork the blockchain and change consensus rules, they are > not just harming themselves, they are affecting ALL the users, since > such a thing would have strong impact over the BTC/FIAT rate, affecting > everyone in the ecosystem. There is economics involved here and human > element, things which are hard to fix via code, even if the code is > developed in open source style. > > It's one thing to decide to merge some patches, improve the code, etc. > and another thing to decide for consensus rules when you literary play > with 4 billion united states dollars of other people's money. This > shouldn't be Wladimir's responsibility, it's just unfair for people to > throw this on his shoulders. > > I do not under any circumstances suggest that the consensus should > remain as it is now forever. We need to improve it, but this should not > be on the maintainer. I've seen smart suggestions on this mail list > where consensus changes can be made during a long period of time, > through soft forks, where all users/miners/exchangers/merchants get the > chance to choose / take action. > > On 6/25/2015 3:07 AM, Milly Bitcoin wrote: >> I have seen this question asked many times. Most developers become >> defensive and they usually give a very vague 1-sentence answer when this >> question is asked. It seems to be it is based on personalities rather >> than any kind of definable process. To have that discussion the >> personalities must be separated out and answers like "such-and-such >> wouldn't do that" don't really do much to advance the discussion. Also, >> the incentive for new developers to come in is that they will be paid by >> companies who want to influence the code and this should be considered >> (some developers take this statement as an insult when it is just a >> statement of the incentive process). >> >> The other problem you are having is the lead developer does not want to >> be a "decider" when, in fact, he is a very significant decider. While >> the users have the ultimate choice in a practical sense the chief >> developer is the "decider." Now people don't want to get him upset so >> nobody wants to push the issue or fully define the process. Now you are >> left with a broken, unwritten/unspoken process. While this type of >> thing may work with a small group of developers businesses/investors >> looking in from the outside will see this as a risk. >> >> Until you get passed all the personality-based arguments you are going >> to have a tough time defining a real process. >> >> Russ >> >> >> >> >> >> On 6/24/2015 7:41 PM, Raystonn wrote: >>> I would like to start a civil discussion on an undefined, or at least >>> unwritten, portion of the BIP process. Who should get to vote on >>> approval to commit a BIP implementation into Bitcoin Core? Is a >>> simple majority of these voters sufficient for approval? If not, then >>> what is? >>> >>> Raystonn >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 13:41 ` Eric Lombrozo @ 2015-06-25 13:51 ` s7r 2015-06-25 14:08 ` Milly Bitcoin 2015-06-25 17:03 ` Jeff Garzik 2 siblings, 0 replies; 51+ messages in thread From: s7r @ 2015-06-25 13:51 UTC (permalink / raw) To: Eric Lombrozo; +Cc: bitcoin-dev +1 for Wladimir, as I said. Anyone who checks the commit history on github can see that he decides quite well all the time for code changes. These fake arguments are thrown by people who hope they will force him into deciding for consensus / protocol changes. This won't happen. On 6/25/2015 4:41 PM, Eric Lombrozo wrote: > Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please. > > - Eric Lombrozo > >> On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip.org> wrote: >> >> I guess you mean Wladimir here. You are wrong, Wladimir does decide and >> if you look at the commit history on github.com for bitcoin core you >> will see, that he does actually decide and does it really good. >> >> He just does not want to decide (and he really should not) on CONSENSUS >> changes or protocol changes. This is totally different. >> >> Stop the analogy with "other open source projects". This is an open >> source project (the code part) but unlike any other open source projects >> which can just be forked, without affecting the other users, in bitcoin >> we need all the users to trust a single blockchain, so it'll have value. >> If some users fork the blockchain and change consensus rules, they are >> not just harming themselves, they are affecting ALL the users, since >> such a thing would have strong impact over the BTC/FIAT rate, affecting >> everyone in the ecosystem. There is economics involved here and human >> element, things which are hard to fix via code, even if the code is >> developed in open source style. >> >> It's one thing to decide to merge some patches, improve the code, etc. >> and another thing to decide for consensus rules when you literary play >> with 4 billion united states dollars of other people's money. This >> shouldn't be Wladimir's responsibility, it's just unfair for people to >> throw this on his shoulders. >> >> I do not under any circumstances suggest that the consensus should >> remain as it is now forever. We need to improve it, but this should not >> be on the maintainer. I've seen smart suggestions on this mail list >> where consensus changes can be made during a long period of time, >> through soft forks, where all users/miners/exchangers/merchants get the >> chance to choose / take action. >> >> On 6/25/2015 3:07 AM, Milly Bitcoin wrote: >>> I have seen this question asked many times. Most developers become >>> defensive and they usually give a very vague 1-sentence answer when this >>> question is asked. It seems to be it is based on personalities rather >>> than any kind of definable process. To have that discussion the >>> personalities must be separated out and answers like "such-and-such >>> wouldn't do that" don't really do much to advance the discussion. Also, >>> the incentive for new developers to come in is that they will be paid by >>> companies who want to influence the code and this should be considered >>> (some developers take this statement as an insult when it is just a >>> statement of the incentive process). >>> >>> The other problem you are having is the lead developer does not want to >>> be a "decider" when, in fact, he is a very significant decider. While >>> the users have the ultimate choice in a practical sense the chief >>> developer is the "decider." Now people don't want to get him upset so >>> nobody wants to push the issue or fully define the process. Now you are >>> left with a broken, unwritten/unspoken process. While this type of >>> thing may work with a small group of developers businesses/investors >>> looking in from the outside will see this as a risk. >>> >>> Until you get passed all the personality-based arguments you are going >>> to have a tough time defining a real process. >>> >>> Russ >>> >>> >>> >>> >>> >>> On 6/24/2015 7:41 PM, Raystonn wrote: >>>> I would like to start a civil discussion on an undefined, or at least >>>> unwritten, portion of the BIP process. Who should get to vote on >>>> approval to commit a BIP implementation into Bitcoin Core? Is a >>>> simple majority of these voters sufficient for approval? If not, then >>>> what is? >>>> >>>> Raystonn >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 13:41 ` Eric Lombrozo 2015-06-25 13:51 ` s7r @ 2015-06-25 14:08 ` Milly Bitcoin 2015-06-25 17:03 ` Jeff Garzik 2 siblings, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 14:08 UTC (permalink / raw) To: bitcoin-dev I agree with all this. However, as a practical matter the consensus rules are not separated out so one person decides whether the "rough consensus" has been reached and if the consensus rules should be changed. It really has nothing to do with any personality involved or whether they do a good or bad job. The final decision should probably not fall into the lap of one person but it does for now and that is just the way it is because there is no better way to do it if you want to get things done. I am also not saying any specific process is good or bad, I am saying the lack of a defined process causes wasted time and effort. Once you define the process you have now (the baseline) then you can evaluate whether parts of it are good or bad. As the developer system transitions into a paid system where commercial entities hire developers then there is no incentive for them to do that if changes can never be made. A defined process will give more assurance for commercial entities to bring more developers on board. Russ On 6/25/2015 9:41 AM, Eric Lombrozo wrote: > Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please. > > - Eric Lombrozo > >> On Jun 25, 2015, at 6:36 AM, s7r <s7r@sky-ip.org> wrote: >> >> I guess you mean Wladimir here. You are wrong, Wladimir does decide and >> if you look at the commit history on github.com for bitcoin core you >> will see, that he does actually decide and does it really good. >> >> He just does not want to decide (and he really should not) on CONSENSUS >> changes or protocol changes. This is totally different. >> >> Stop the analogy with "other open source projects". This is an open >> source project (the code part) but unlike any other open source projects >> which can just be forked, without affecting the other users, in bitcoin >> we need all the users to trust a single blockchain, so it'll have value. >> If some users fork the blockchain and change consensus rules, they are >> not just harming themselves, they are affecting ALL the users, since >> such a thing would have strong impact over the BTC/FIAT rate, affecting >> everyone in the ecosystem. There is economics involved here and human >> element, things which are hard to fix via code, even if the code is >> developed in open source style. >> >> It's one thing to decide to merge some patches, improve the code, etc. >> and another thing to decide for consensus rules when you literary play >> with 4 billion united states dollars of other people's money. This >> shouldn't be Wladimir's responsibility, it's just unfair for people to >> throw this on his shoulders. >> >> I do not under any circumstances suggest that the consensus should >> remain as it is now forever. We need to improve it, but this should not >> be on the maintainer. I've seen smart suggestions on this mail list >> where consensus changes can be made during a long period of time, >> through soft forks, where all users/miners/exchangers/merchants get the >> chance to choose / take action. >> >> On 6/25/2015 3:07 AM, Milly Bitcoin wrote: >>> I have seen this question asked many times. Most developers become >>> defensive and they usually give a very vague 1-sentence answer when this >>> question is asked. It seems to be it is based on personalities rather >>> than any kind of definable process. To have that discussion the >>> personalities must be separated out and answers like "such-and-such >>> wouldn't do that" don't really do much to advance the discussion. Also, >>> the incentive for new developers to come in is that they will be paid by >>> companies who want to influence the code and this should be considered >>> (some developers take this statement as an insult when it is just a >>> statement of the incentive process). >>> >>> The other problem you are having is the lead developer does not want to >>> be a "decider" when, in fact, he is a very significant decider. While >>> the users have the ultimate choice in a practical sense the chief >>> developer is the "decider." Now people don't want to get him upset so >>> nobody wants to push the issue or fully define the process. Now you are >>> left with a broken, unwritten/unspoken process. While this type of >>> thing may work with a small group of developers businesses/investors >>> looking in from the outside will see this as a risk. >>> >>> Until you get passed all the personality-based arguments you are going >>> to have a tough time defining a real process. >>> >>> Russ >>> >>> >>> >>> >>> >>> On 6/24/2015 7:41 PM, Raystonn wrote: >>>> I would like to start a civil discussion on an undefined, or at least >>>> unwritten, portion of the BIP process. Who should get to vote on >>>> approval to commit a BIP implementation into Bitcoin Core? Is a >>>> simple majority of these voters sufficient for approval? If not, then >>>> what is? >>>> >>>> Raystonn >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 13:41 ` Eric Lombrozo 2015-06-25 13:51 ` s7r 2015-06-25 14:08 ` Milly Bitcoin @ 2015-06-25 17:03 ` Jeff Garzik 2015-06-25 17:29 ` Milly Bitcoin 2 siblings, 1 reply; 51+ messages in thread From: Jeff Garzik @ 2015-06-25 17:03 UTC (permalink / raw) To: Eric Lombrozo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 295 bytes --] On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo@gmail.com> wrote: > Wladimir is doing an amazing job under difficult circumstances. Give the > guy a break, please A+ agreed. He is not an elected decider - he is the Bitcoin Core release manager, and has been doing a damn fine job. [-- Attachment #2: Type: text/html, Size: 617 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [bitcoin-dev] BIP Process and Votes 2015-06-25 17:03 ` Jeff Garzik @ 2015-06-25 17:29 ` Milly Bitcoin 0 siblings, 0 replies; 51+ messages in thread From: Milly Bitcoin @ 2015-06-25 17:29 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1117 bytes --] In the context of this discussion the Bitcoin Core release manager is the "decider" of what goes into the release. Nobody said he was elected. The discussion also has nothing to do with any specific person and nobody said anyone did anything wrong. One of the reason why a process needs to be developed so issues are not sidetracked into a dramatized discussion over personalities which is a big waste of time. Some of the developers are now essentially full time drama queens who write a little bit of code on the side. Russ On 6/25/2015 1:03 PM, Jeff Garzik wrote: > On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo@gmail.com > <mailto:elombrozo@gmail.com>> wrote: > > Wladimir is doing an amazing job under difficult circumstances. > Give the guy a break, please > > > A+ agreed. He is not an elected decider - he is the Bitcoin Core > release manager, and has been doing a damn fine job. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2401 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2015-07-01 22:34 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-25 3:00 [bitcoin-dev] BIP Process and Votes Raystonn 2015-06-25 3:19 ` Milly Bitcoin 2015-06-26 11:13 ` Jorge Timón 2015-06-26 12:34 ` Milly Bitcoin 2015-06-27 11:28 ` Jorge Timón 2015-06-27 12:50 ` Milly Bitcoin 2015-06-28 12:30 ` Jorge Timón 2015-06-28 13:13 ` Milly Bitcoin 2015-06-28 15:35 ` Jorge Timón 2015-06-28 16:23 ` Milly Bitcoin 2015-06-28 19:05 ` Patrick Murck 2015-06-28 20:10 ` Milly Bitcoin 2015-06-28 20:16 ` Mark Friedenbach 2015-06-28 20:26 ` Ricardo Filipe 2015-06-28 21:00 ` Adam Back 2015-06-29 0:13 ` Milly Bitcoin 2015-06-29 0:23 ` Andrew Lapp 2015-06-29 1:11 ` Milly Bitcoin 2015-06-28 23:52 ` Milly Bitcoin 2015-06-28 20:21 ` NxtChg 2015-06-25 19:03 ` Tom Harding -- strict thread matches above, loose matches on Subject: below -- 2015-06-25 3:53 Raystonn 2015-06-25 0:18 Raystonn 2015-06-24 23:41 Raystonn 2015-06-24 23:49 ` Jeff Garzik 2015-06-25 0:11 ` Bryan Bishop 2015-06-25 0:21 ` Milly Bitcoin 2015-06-25 0:07 ` Milly Bitcoin 2015-06-25 1:50 ` Mark Friedenbach 2015-06-25 2:30 ` Alex Morcos 2015-06-25 2:34 ` Milly Bitcoin 2015-06-25 5:07 ` Jeff Garzik 2015-06-25 5:41 ` Milly Bitcoin 2015-06-25 6:06 ` Pindar Wong 2015-06-25 6:15 ` Mark Friedenbach 2015-06-25 6:16 ` Warren Togami Jr. 2015-06-25 6:27 ` Pindar Wong 2015-06-25 7:51 ` cipher anthem 2015-06-25 10:09 ` nxtchg 2015-06-25 12:42 ` Milly Bitcoin 2015-06-25 20:05 ` Tier Nolan 2015-06-26 0:42 ` Milly Bitcoin 2015-07-01 22:34 ` odinn 2015-06-25 3:42 ` Gareth Williams 2015-06-25 4:10 ` Milly Bitcoin 2015-06-25 13:36 ` s7r 2015-06-25 13:41 ` Eric Lombrozo 2015-06-25 13:51 ` s7r 2015-06-25 14:08 ` Milly Bitcoin 2015-06-25 17:03 ` Jeff Garzik 2015-06-25 17:29 ` Milly Bitcoin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox