From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 885AC14AA for ; Wed, 7 Oct 2015 05:08:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D54AEB0 for ; Wed, 7 Oct 2015 05:08:18 +0000 (UTC) Received: by ykdz138 with SMTP id z138so6476274ykd.2 for ; Tue, 06 Oct 2015 22:08:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=ONDQvD9iDyfhZl22kn4rhA/rsXOHW0ht3KKLW/pK85Q=; b=McQqg8VY0Dg69sgLfJf/DpyyB2Jp0V9OVozKYx9s15ICMouWXzp4ARdrcDWrcXINJ8 4MB7b89B8w9VfG4y7GnrN30yOPtsE/h9jgO7TIP4l2IQ17bj+HtRstIYDxRyvwM19NgW 6uOSgwk/1BTrcSpD4Q9t3SSJyhNW0k+Wveth1kODmj0GxibcyKf2g1fNNgNMyJkTf2Lw wwiEWDTw/ZpPn1caLzIqIPUy710QqzYIXqf7BxZH0nOjT6hBuGhlU8xB3DxzgVWKBpar +Q+/g7jLWQoqi2mJXvfX+3wanEC9SX4IPgV9IqRwbCKc2IfMQGmqxqoj9fXKvTWOoQ3c 1I/Q== X-Gm-Message-State: ALoCoQk/mqnMT6n2antFRGEQZU0ixE4dGJJ9q9Pi55A6uRG9MfEE29kMSgkyeKWCFH6oJlJyzlB4 X-Received: by 10.13.213.86 with SMTP id x83mr4593221ywd.217.1444194497859; Tue, 06 Oct 2015 22:08:17 -0700 (PDT) MIME-Version: 1.0 Sender: rgrant@rgrant.org Received: by 10.37.215.197 with HTTP; Tue, 6 Oct 2015 22:07:48 -0700 (PDT) From: Ryan Grant Date: Wed, 7 Oct 2015 01:07:48 -0400 X-Google-Sender-Auth: iNyLDtxu5kX-YU4jgAKdgz9C_hs Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, TO_NO_BRKTS_PCNT autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] on rough consensus X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 05:08:20 -0000 Bitcoin's participants can improve their ability to stay on a valuable and censorship resistant blockchain by individually and informally absorbing cultural wisdom regarding "rough consensus". This does not require writing any formal rules about what rough consensus is. It is a matter of participation with an understanding. https://www.ietf.org/tao.html#rfc.section.2 In many ways, the IETF runs on the beliefs of its participants. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". A June 2015 bitcoin-dev thread, arguing about consensus, included the usual range of responses; ranging from claims that any objection must block consensus to a definition based on US Justice Stewart's "I'll know it when I see it". (It's funny because it's true. We can explain it better, though.) "Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers" http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008772.html An August 2015 cryptography-list thread presents the idea that rough consensus can be used as a tool for hindering progress. The specific threat was that two protocol options could be made to seem equally good. To solve this example, identify that as the problem, then engage a judgement to pick one solution "good enough" (but that does not lead to a dead-end for other goals of the project), and go with it. There is room, within "rough consensus", for such action to defend against the attack; as you can see from other excerpts in this message. "[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack" http://www.metzdowd.com/pipermail/cryptography/2015-August/026151.html To learn about forming a useful "rough consensus", see the very readable "Tao of the IETF", and RFC 7282. "The Tao of the IETF" https://www.ietf.org/tao.html (previously RFC 4677) RFC 7282 "On Consensus and Humming in the IETF" https://tools.ietf.org/html/rfc7282 Strong objections don't block rough consensus: https://www.ietf.org/tao.html#getting.things.done Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong. https://tools.ietf.org/html/rfc7282 Having full consensus, or unanimity, would be ideal, but we don't require it: Requiring full consensus allows a single intransigent person who simply keeps saying "No!" to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding. The working group chair's responsibility is different from that of either a vote counter or a benign dictator: http://tools.ietf.org/html/rfc2418 Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. https://tools.ietf.org/html/rfc7282 3. Rough consensus is achieved when all issues are addressed, but not necessarily accommodated [...] If the chair finds, in their technical judgement, that the issue has truly been considered, and that the vast majority of the working group has come to the conclusion that the tradeoff is worth making, even in the face of continued objection from the person(s) who raised the issue, the chair can declare that the group has come to rough consensus. (And even though this is framed in terms of a "vast majority", even that is not necessarily true. This point is discussed in more detail in Sections 6 and 7.) [...] The chair of a working group who is about to find that there is only rough consensus is going to have to decide that not only has the working group taken the objection seriously, but that it has **fully examined the ramifications** of not making a change to accommodate it, and that the outcome does not constitute a failure to meet the technical requirements of the work. [...] 6. One hundred people for and five people against might not be rough consensus [...] one of the great strengths of using consensus over voting: It isn't possible to use "vote stuffing" (simply recruiting a large number of people to support a particular side, even people who have never participated in a working group or the IETF at all) to change the outcome of a consensus call. As long as the chair is looking for outstanding technical objections and not counting heads, vote stuffing shouldn't affect the outcome of the consensus call. 7. Five people for and one hundred people against might still be rough consensus [...Sybil attack] it is within bounds for the chair to say, "We have objections, but the objections have been sufficiently answered, and the objectors seem uninterested in participating in the discussion. Albeit rough in the extreme, there is rough consensus to go with the current solution." [...] it is likely that if a working group got this dysfunctional, it would put the whole concept of coming to rough consensus at risk. But still, the correct outcome in this case is to look at the very weak signal against the huge background noise in order to find the rough consensus. Working group chairs can help direct discussion: https://www.ietf.org/tao.html#rfc.section.4.1 Sometimes discussions get stuck on contentious points and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over. Some working groups segregate the role of forming a consensus from communicating the consensus: https://www.ietf.org/tao.html#rfc.section.4.2 Another method that some Working Groups adopt is to have a Working Group "secretary" to handle the juggling of the documents and the changes. The secretary can run the issue tracker if there is one, or can simply be in charge of watching that all of the decisions that are made on the mailing list are reflected in newer versions of the documents. Bitcoin Core is neither an IETF working group, nor should it aim to curate its network protocol ruleset as one. The IETF uses a steering group, formal variance procedures, an appeals board, and a director (to send even higher appeals to). All of those positions could become points of attack, if Bitcoin were to attempt to use or copy them. That said, most IETF appeal routes are merely authorized to undo a prior ruling of consensus, opening for reconsideration prior dismissed points of argument (on their technical merits). In Bitcoin, if developers know what to work on, and can speak clearly enough to the economic majority, then the system is working; regardless of whether any role exists taking all the responsibility that an IETF working group chair would take. It is absolutely the case that resolving excessive roughness in shared consensus takes more work than either votes or dictatorship. It is also the case that rough consensus is a good defense against committing to decisions with subtle undesirable long-term effects. That is why the IETF cares about it, and that same long-term threat is important in Bitcoin's ecosystem as well. /// References and Selected IETF Excerpts /// "The Tao of the IETF" https://www.ietf.org/tao.html A 2012 continuation of 2006's RFC 4677, itself first published in 1994. BCP 25 http://tools.ietf.org/html/rfc2418 (1998) 3.3. Session management Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. In the case where a consensus, which has been reached during a face-to-face meeting, is being **verified on a mailing list**, the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this. [...] To facilitate making forward progress, a Working Group Chair may wish to decide to reject or defer the input from a member, based upon the following criteria: - Old The input pertains to a topic that already has been resolved and is redundant with information previously available; - Minor The input is new and pertains to a topic that has already been resolved, but it is felt to be of minor import to the existing decision; - Timing The input pertains to a topic that the working group has not yet opened for discussion; or - Scope The input is outside of the scope of the working group charter. [...] RFC 2026 "The Internet Standards Process -- Revision 3" http://tools.ietf.org/html/rfc2026#section-6.5 6.5 Conflict Resolution and Appeals [...] RFC 7282 "On Consensus and Humming in the IETF" https://tools.ietf.org/html/rfc7282 1. Introduction [...] our credo is that we don't let a single individual dictate decisions (a king or president), nor should decisions be made by a vote, nor do we want decisions to be made in a vacuum without practical experience. Instead, we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs. Having full consensus, or unanimity, would be ideal, but we don't require it: Requiring full consensus allows a single intransigent person who simply keeps saying "No!" to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding. 2. Lack of disagreement is more important than agreement [...] **determining** consensus and **coming to** consensus are different things than **having** consensus [emphasis in original]. [...]If at the end of the discussion some people have not gotten the choice that they prefer, but they have become convinced that the chosen solution is acceptable, albeit less appealing, they have still come to consensus. Consensus doesn't require that everyone is happy and agrees that the chosen solution is the best one. Consensus is when everyone is sufficiently satisfied with the chosen solution, such that they **no longer have specific objections** to it. [...] "Can anyone not live with choice A?" is more likely to only hear from folks who think that choice A is impossible to engineer given some constraints. Following up with, "What are the reasons you object to choice A?" is also essential. [...] There is also an important point to be made about reaching consensus and "compromising": Unfortunately, the word "compromise" gets used in two different ways, and though one sort of compromising to come to consensus is good (and important), the other sort of compromising in order to achieve consensus can actually be harmful. As mentioned earlier, engineering always involves balancing tradeoffs, and figuring out whether one engineering decision makes more sense on balance compared to another involves making engineering "compromises": We might have to compromise processor speed for lower power consumption, or compromise throughput for congestion resistance. Those sorts of compromises are among **engineering choices**, and they are **expected and essential**. We always want to be weighing tradeoffs and collectively choosing the set that best meets the full set of requirements. However, there is another sense of "compromise" that involves compromising between people, not engineering principles. For example, a minority of a group might object to a particular proposal, and even after discussion still think the proposal is deeply problematic, but decide that they don't have the energy to argue against it and say, "Forget it, do what you want". That surely can be called a compromise, but a chair might mistakenly take this to mean that they agree, and have therefore come to consensus. But really all that they've done is capitulated; they've simply given up by trying to appease the others. That's not coming to consensus; there still exists an outstanding unaddressed objection. Again, if the objection is only that the choice is not ideal but is otherwise acceptable, such a compromise is fine. But **conceding** when there is a real outstanding technical objection **is not coming to consensus**. [...] Coming to consensus is when everyone (including the person making the objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but **merely a matter of taste**. Of course, coming to full consensus like that does not always happen. That's why in the IETF, we talk about "rough consensus". 3. Rough consensus is achieved when all issues are addressed, but not necessarily accommodated [...] If the chair finds, in their technical judgement, that the issue has truly been considered, and that the vast majority of the working group has come to the conclusion that the tradeoff is worth making, even in the face of continued objection from the person(s) who raised the issue, the chair can declare that the group has come to rough consensus. (And even though this is framed in terms of a "vast majority", even that is not necessarily true. This point is discussed in more detail in Sections 6 and 7.) [...] The chair of a working group who is about to find that there is only rough consensus is going to have to decide that not only has the working group taken the objection seriously, but that it has **fully examined the ramifications** of not making a change to accommodate it, and that the outcome does not constitute a failure to meet the technical requirements of the work. In order to do this, the chair will need to have a good idea of the purpose and architecture of the work being done, perhaps referring to the charter of the working group or a previously published requirements document, or even consulting with other experts on the topic, and then the chair will use **their own technical judgement** to make sure that the solution meets those requirements. It is possible that the chair can come to the wrong conclusion, and the chair's conclusion is always appealable should that occur, but the chair must use their judgement in these cases. What can't happen is that the chair bases their decision solely on hearing a large number of voices simply saying, "The objection isn't valid." That would simply be to take a vote. A **valid justification needs to me made**. [...] Indeed, RFC 2418 adds on to [old talk of balloting] by stating, "Note that 51% of the working group does not qualify as 'rough consensus' and 99% is better than rough." This document actually disagrees with the idea that simply balloting or otherwise looking at percentages can "determine" consensus. While counting heads might give a good guess as to what the rough consensus will be, doing so can allow important minority views to get lost in the noise. One of the strengths of a consensus model is that minority views are addressed, and using a rough consensus model should not take away from that. That is why this document talks a great deal about looking at open issues rather than just counting the number of people who do or do not support any given issue. Doing so has some interesting and surprising implications that are discussed in subsequent sections. Any finding of rough consensus needs, at some level, to provide a **reasoned explanation** to the person(s) raising the issue of why their concern is not going to be accommodated. A good outcome is for the objector to **understand the decision taken and accept the outcome**, even though their particular issue is not being accommodated in the final product. Remember, if the objector feels that the issue is so essential that it must be attended to, they always have the option to file an appeal. A technical error is always a valid basis for an appeal. [...] 4. Humming should be the start of a conversation, not the end [...] a show of hands might leave the impression that the number of people matters in some formal way. 5. Consensus is the path, not the destination We don't try to reach consensus in the IETF as an end in itself. We use consensus-building as a tool to get to the best technical (and sometimes procedural) outcome when we make decisions. Experience has shown us that traditional voting leads to gaming of the system, "compromises" of the wrong sort as described earlier, important minority views being ignored, and, in the end, worse technical outcomes. 6. One hundred people for and five people against might not be rough consensus [...] one of the great strengths of using consensus over voting: It isn't possible to use "vote stuffing" (simply recruiting a large number of people to support a particular side, even people who have never participated in a working group or the IETF at all) to change the outcome of a consensus call. As long as the chair is looking for outstanding technical objections and not counting heads, vote stuffing shouldn't affect the outcome of the consensus call. [...] Even if no particular person is still standing up for an issue, that doesn't mean an issue can be ignored. As discussed earlier, simple capitulation on an issue is not coming to consensus. But even in a case where someone who is not an active participant, who might not care much about the fate of the work, raises a substantive issue and subsequently disappears, the issue needs to be addressed before the chair can claim that rough consensus exists. 7. Five people for and one hundred people against might still be rough consensus [...Sybil attack] it is within bounds for the chair to say, "We have objections, but the objections have been sufficiently answered, and the objectors seem uninterested in participating in the discussion. Albeit rough in the extreme, there is rough consensus to go with the current solution." [...] it is likely that if a working group got this dysfunctional, it would put the whole concept of coming to rough consensus at risk. But still, the correct outcome in this case is to look at the very weak signal against the huge background noise in order to find the rough consensus. 9. Security Considerations "He who defends with love will be secure." -- Lao Tzu