path: root/68/f3205c1223f2bab987bcb395ada4c6ee0bfc36

Return-Path: <rgrant@rgrant.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 885AC14AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Oct 2015 05:08:18 +0000 (UTC)
Received: by ykdz138 with SMTP id z138so6476274ykd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@rgrant.org>
Date: Wed, 7 Oct 2015 01:07:48 -0400
X-Google-Sender-Auth: iNyLDtxu5kX-YU4jgAKdgz9C_hs
Message-ID: <CAMnpzfpixzTgYzvhQM_v1pWg1OHWZ49oz7qd+q_7NE_Gajqx7w@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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