* [bitcoin-dev] on rough consensus
@ 2015-10-07 5:07 Ryan Grant
2015-10-07 10:42 ` Adam Back
0 siblings, 1 reply; 2+ messages in thread
From: Ryan Grant @ 2015-10-07 5:07 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-10-07 10:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-07 5:07 [bitcoin-dev] on rough consensus Ryan Grant
2015-10-07 10:42 ` Adam Back
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox