goals.tex

We identify three crucial properties for a group decisionmaking protocol that
keeps power decentralized.

First, the protocol's computation must be distributed. If the adversary has
control of the network infrastructure, it can easily block access to any central
component of a protocol (such as a Tor relay \tocite or voting
registrar\todoword{use the literature terminology}). If blocking one or a small
subset of nodes in the group is sufficient to break the protocol, this again
weakens our decentralization guarantees and renders the protocol less useful. A
fault tolerant, distributed protocol, however, can easily recover from arbitrary
changes in the network topology.

Next, the protocol must be verifiable --- any particiapnt or external auditor
should be able to examine a transcript of the protocol and determine whether or
not it was performed honestly. Without this property, it would be necessary to
trust that some portion of the group acted honestly without verification ---
this constitutes centralized trust, and is therefore inadequate.

Finally, the protocol must be anonymous --- it should be computationally hard to
attribute any vote or any petition to any specific participant. This is
essential to preserve the safety of members suggesting or voting for unpopular
proposals.

We now formalize these notions:
\section{Distributed Computation}\label{Subsection:distr}
Our intention in defining a decentralization property is to approximate the
human notion of decentralized power: We would like to ensure that initially, all
nodes are situated equally, and that it is impossible for the system to enter a
state in which any centralization or delegation of power is irrevokable. In
practice, we take this to mean
\begin{itemize}
  \item We make no assumptions about any subset of nodes having particular
    capabilities not available to all nodes,
  \item $\NumHonest$ honest nodes can always recover from any attempt to disrupt
    the protocol by $\NumClients - \NumHonest$ colluding malicious nodes.
\end{itemize}

\section{Verifiability}\label{Section:verif}
A protocol is verifiable if its output can be inspected to confirm that the
protocol was carried out correctly. A simple example of this is signing a
message with the private key associated with a well-known public key: Anyone
who knows the public key can verify the validity of the signature.

Voting protocols can be evaluated in their provision of three different
kinds of verifiability \cite{kremer_election_2010}: \emph{individual}
verifiability ensures that a voter can verify their vote was included
correctly. \emph{Universal} verifiability requires that anybody can verify
the election result correctly represents the collection of ballots cast.
Finally, \emph{Eligibility} verifiability allows anybody to verify that
only eligible voters voted, and that each voter voted only once.

\section{Anonymity}
Members of any group often face reprocussions if they participate in group
governance in ways that run contrary to the interests of other members of
the group. For this reason, election protocols often incorporate some notion
of anonymity. A protocol guarantees \emph{anonymity} in some operation a
client can complete if the output of that operation is unlinkable (or, more
precisely, cryptographically very difficult to link) to the participant who
completed it\cite{ford_hiding_2014}.

We are interested in two types of anonymity: First, within an election,
each voter's confidentiality should be preserved. Second, the instigator of an
election, who may also be the author of the proposed petition, should be
anonymous.

\section{Threat Model}
We assume the adversary controls an arbitrary subset of the nodes in the network
--- that is, it sees their internal state, and also controls what messages they
send. We additionally assume the adversary can monitor all messages transmitted
among all nodes (an NSA-like global passive adversary).

\section{Limitations and Non-Goals}
  \paragraph{Intersection Attacks:} The \texttt{Peer} and \texttt{Member} sets
  are known. In Dissent in Numbers, clients need not know the IP addresses of
  any other clients. We believe it is useful to have a protocol for a group with
  static membership.  If there is membership churn, our protocol remains
  vulnerable to intersection attacks.
  \paragraph{Coercion-Resistance:} In order to use anonymous ring signatures for
  voting, it is necessary for each signature within a scope to correspond to a
  specific member. An adversary with the power to coerce \texttt{Member}s into
  revealing their private keys after the fact may prove that a particular member
  voted a particular way\cite{lrs}.
%
% ``An important and fundamental downside,
% however, is that linkable signatures do NOT offer forward-secure anonymity. If
% an anonymity set member's private key is later released, it is trivial to check
% whether or not that member produced a given signature. Also, anonymity set
% members who did NOT sign a message could (voluntarily or under coercion) prove
% that they did not sign it, e.g., simply by signing some other message in that
% linkage context and noting that the resulting linkage tag comes out different.
% Thus, linkable anonymous signatures are not appropriate to use in situations
% where there may be significant risk that members' private keys may later be
% compromised, or that members may be persuaded or coerced into revealing whether
% or not they produced a signature of interest.''
  \paragraph{Forward Progress:} A protocol that guarantees forward progress
  given certain conditions will eventually make progress as long as those
  conditions are met. More strict bounds on what ``eventually'' means are
  possible. In the original Dissent, for example, forward progress can be
  guaranteed if all clients follow the protocol and remain online, but not
  otherwise: The accountability mechanism was so arduous that $f$ disrupting
  clients could prevent any messages from being transmitted for $f$ hours
  \cite{verdict}. Protocols that make use of quorums rather than being fully
  peer-to-peer are able to provide stronger guarantees of forward progress
  \cite{paxos}. Since we do not handle traditional fault tolerance or network
  churn,  this is an area for future work.