Quisquis: A New Design for Anonymous
Cryptocurrencies
Prastudy Fauzi
1
, Sarah Meiklejohn
2
, Rebekah Mercer
3
, and Claudio Orlandi
4
1
Simula UiB, Norway
2
University College London, UK
3
O(1) Labs, USA
4
Department of Computer Science, DIGIT, Aarhus University, Denmark
Abstract. Despite their usage of pseudonyms rather than persistent
identifiers, most existing cryptocurrencies do not provide users with any
meaningful levels of privacy. This has prompted the creation of privacy-
enhanced cryptocurrencies such as Monero and Zcash, which are specif-
ically designed to counteract the tracking analysis possible in curren-
cies like Bitcoin. These cryptocurrencies, however, also suffer from some
drawbacks: in both Monero and Zcash, the set of potential unspent coins
is always growing, which means users cannot store a concise representa-
tion of the blockchain. Additionally, Zcash requires a common reference
string and the fact that addresses are reused multiple times in Monero
has led to attacks to its anonymity.
In this paper we propose a new design for anonymous cryptocurrencies,
Quisquis, that achieves provably secure notions of anonymity. Quisquis
stores a relatively small amount of data, does not require trusted setup,
and in Quisquis each address appears on the blockchain at most twice:
once when it is generated as output of a transaction, and once when
it is spent as input to a transaction. Our result is achieved by com-
bining a DDH-based tool (that we call updatable keys) with efficient
zero-knowledge arguments.
1 Introduction
Bitcoin was introduced in 2008 [31], and at a high level it relies on the use of
addresses, associated with a public and private key pair, to keep track of who
owns which coins. Users of the system can efficiently create and operate many
different addresses, which gives rise to a form of pseudo-anonymity. As is now
well known, however, Bitcoin and other cryptocurrencies relying on this level
of pseudo-anonymity can, in practice, have these addresses linked together and
even linked back to their real-world identities with little effort [34,35,3,27,38,29].
Due to this, there has now been an extensive body of work aiming to provide
privacy-enhanced solutions for cryptocurrencies, although even some of these
new solutions have also been subjected to empirical analyses pointing out the
extent to which they can be de-anonymized as well [30,26,28,21,20,19,41]. These
solutions typically fall into two main categories.
First, tumblers (also known as mixers or mixing services) act as opt-in over-
lays to existing cryptocurrencies such as Bitcoin [24,37,17] and Ethereum [25],
and achieve enhanced privacy by allowing senders to mix their coins with those
of other senders. While these are effective and arguably have a high chance of
adoption due to their integration with existing cryptocurrencies, they also have
some limitations. In particular, they are generally either dependent on trusting
a central mixer, which leaves users vulnerable to attacks on availability, or they
require significant coordination amongst the parties wishing to mix, which leads
to higher latency as users must wait for other people to mix with them.
Second, there are cryptocurrencies with privacy features built in at the pro-
tocol level. Of these, the ones that have arguably achieved the most success
are Dash [1], Monero [32], and Zcash [6]. Dash is derived from a tumbler solu-
tion, Coinjoin [24], and thus inherits the properties discussed there. In Monero,
senders specify some number of addresses to “mix in” to their own transaction,
and then use this list of public keys to form a ring signature and hide which
specific address was theirs. Observers of the blockchain thus learn only that
some unknown number of coins have moved from one of these input public keys.
In Zcash, users can put coins into a “shielded pool.” When they wish to spend
these coins, they prove in zero-knowledge that they have the right to spend some
specific coins in the pool, without revealing which ones.
Between Monero and Zcash, there are already several differences. For exam-
ple, because users in Monero specify rings themselves, they achieve a form of
plausible deniability: no one can tell if a user meant to be involved in a given
transaction, or if their address was simply used in a ring without their consent.
In Zcash, in contrast, every other user in a user’s anonymity set has no such
deniability, as they at one point intentionally put coins into the shielded pool.
One limitation central to both cryptocurrencies, however, is the information
that peers in the network are required to keep. In Bitcoin, the list of all addresses
with a positive balance can be thought of as a set of unspent transaction outputs
(UTXOs). When a sender spends coins, their address ceases to be a UTXO,
so is replaced in the set with the address of their recipient. Full nodes can thus
collapse the blockchain into this UTXO set, and check for double spending simply
by checking if a given input address is in the set or not. In other words, it acts
as a concise representation of the entire history of the blockchain. In October
2017, for example, there had been over 23 million Bitcoin transactions and the
total size of the blockchain was over 130 GB, but the size of the UTXO set was
only 3 GB [12].
In Monero and Zcash, however, addresses can (essentially) never be removed
from the UTXO set, as it is never clear if an address has spent its contents or
was simply used as part of the anonymity set in the transaction of a different
sender. The size of the UTXO set is thus monotonically increasing: with every
transaction, it can only grow and never shrink. This has a significant impact
on full nodes, as they must effectively store the entire blockchain without the
option of the concise representation possible in Bitcoin.
2
Our Contributions We present Quisquis, a new design for anonymous cryp-
tocurrencies that resolves the limitations outlined above for existing solutions.
In particular, users are able to form transactions on their own, so do not need
to wait for other interested users and incur the associated latency. They can
also involve the keys of other users without their permission, which gives the
same degree of plausible deniability as Monero. Finally, each transaction acts
to replace all the input public keys in the UTXO set with all the output public
keys, thus allowing the UTXO set to behave in the same manner as in Bitcoin.
Furthermore, our transactions are relatively inexpensive to compute and verify,
taking around 471ms to compute and 71ms to verify for an anonymity set of size
16, with proofs of size approximately 13kB.
As a brief technical overview, Quisquis achieves anonymity using a primi-
tive that we formalize in Section 3 called updatable public keys, which allows
users to create updated public keys, indistinguishable from ones that are freshly
generated, without changing the underlying secret key. After formally defining
our threat model in Section 4, we present our full construction of Quisquis in
Section 5. Roughly, senders take the keys of other users, including their intended
recipients, to form a list of public keys that act as the input to a transaction.
A sender can now “re-distribute their wealth” among these input keys, acting to
move some of their own coins to the recipient and keeping the (hidden) balances
of the other members of the anonymity set the same. To ensure anonymity, the
output public keys are all updated, and all balances and amounts are given only
in committed form. Thus, by design, in Quisquis every address can only ever
appear at most twice on the blockchain: once when it is generated in the output
of the transaction, and once when it is spent as input to a different transaction.
This greatly reduces (compared, e.g., to Monero) the ability of an attacker to
perform de-anonymization attacks based on how often a certain address partic-
ipates in transactions.
To ensure integrity, the sender proves in zero-knowledge that they have cor-
rectly updated the keys and have not taken money away from anyone except
themselves. Crucially, because the witness for the zero-knowledge proof is lim-
ited to this single transaction (as opposed to encompassing other parts of the
blockchain), we can use standard discrete-log-based techniques as opposed to
the heavyweight zk-SNARKs required in Zcash. This means that security can
depend entirely on DDH, and no trusted setup is required (as we use the random
oracle model to make the proofs non-interactive and to generate other system
parameters and random values using “nothing up my sleeves” methods). As the
design of Quisquis is modular, other tradeoffs could be achieved as well: for in-
stance, it could be possible to instantiate Quisquis with zk-SNARKs as well,
thus achieving even smaller transactions and faster verification at the cost of
much slower transaction generation and the stronger assumptions underlying
zk-SNARKs.
To demonstrate the efficiency of Quisquis, we implement it and present per-
formance benchmarks in Section 7. We then provide a thorough comparison with
existing solutions in Section 8 before concluding in Section 9.
3
2 Cryptographic Primitives
2.1 Notation
Let log
g
h be the discrete log of h with respect to g. Define (a, b)
c
:= (a
c
, b
c
)
and (a, b) · (c, d) := (ac, bd). For vectors a and b, let a ◦ b be the Hadamard
product of a and b; i.e., the vector c such that c
i
= a
i
b
i
. We use y ← A(x)
to denote assigning to y the output of a deterministic algorithm A on input
x, and y
$
← A(x) if A is randomized; i.e., we sample a random r and then
run y ← A(x; r). We use [A(x)] to denote the set of values that have non-zero
probability of being output by A on inputs x. We use r
$
← R for sampling an
element r uniformly at random from a set R. If y = (y
1
, . . . , y
n
)
$
← A(x) then
we often denote y
i
by y
i
.
2.2 Zero-knowledge arguments of knowledge
Let R be a binary relation for instances x and witnesses w, and let L be its
corresponding language; i.e., L = {x | ∃w : (x, w) ∈ R}. An interactive proof is
a protocol where a prover P tries to convince a verifier V , by an exchange of
messages, that an instance x is in the language L. The set of messages exchanged
is known as a transcript, from which a verifier can either accept or reject the
proof. The proof is public-coin if an honest verifier generates his responses to
P uniformly at random. An interactive proof is a special honest-verifier zero-
knowledge argument of knowledge if it satisfies the following properties:
– Perfect completeness: if x ∈ L, an honest P always convinces an honest V .
– Special honest-verifier zero-knowledge (SHVZK): there exists a simulator S
that, given x ∈ L and an honestly generated verifier’s challenge c, produces
an accepting transcript which has the same (or indistinguishably different)
distribution as a transcript between honest P, V on input x.
– Argument of knowledge: if P convinces V of an instance x, there exists an
extractor with oracle access to P that runs in expected polynomial-time to
extract the witness w.
A public-coin SHVZK argument of knowledge can be turned into a non-
interactive zero knowledge (NIZK) argument of knowledge using the Fiat-Shamir
heuristic. Essentially, non-interactivity is achieved by replacing the verifier’s ran-
dom challenge with the output of a hash function, which in the security proof is
modeled as a random oracle.
2.3 Commitments
We use a commitment scheme Commit relative to a public key pk that, given a
message m ∈ M and randomness r ∈ R, computes com ← Commit
pk
(m; r). Our
commitments must satisfy two properties: first, they are computationally hiding,
meaning for any two messages m
0
, m
1
, an adversary has negligible advantage in
4
distinguishing between Commit
pk
(m
0
; U
R
) and Commit
pk
(m
1
; U
R
), where U
R
is
the uniform distribution over the randomness space. Second, they are uncondi-
tionally binding, meaning even given the sk relative to pk, a commitment cannot
be opened to two different messages.
Beyond these two basic properties, we require two extra properties from our
commitments. First, they must be homomorphic in the sense that for some op-
eration it holds that Commit
pk
(m) Commit
pk
(m
0
) = Commit
pk
(m + m
0
) (for
appropriate randomness). Second, they must be key-anonymous, meaning that
for any honestly generated keys pk
0
, pk
1
and adversarially chosen m, the tuple
(m, pk
0
, pk
1
, Commit
pk
0
(m)) is indistinguishable from (m, pk
0
, pk
1
, Commit
pk
1
(m)).
We can construct such commitments in a group (G, g, p) where the DDH
problem is hard, by essentially performing an ElGamal encryption in the expo-
nent relative to public keys of the form pk = (g
i
, h
i
) (which are what we use in
our later constructions). In particular, Commit
pk
(v; r) returns com = (c, d) where
c = g
i
r
and d = g
v
h
i
r
. It is easy to verify that this commitment scheme is un-
conditionally binding, computationally hiding, key-anonymous, and additively
homomorphic.
Finally, we also use extended Pedersen commitments in the constructions of
our zero-knowledge (ZK) arguments; i.e., schemes that commit to a vector of
values using a single group element.
3 Updatable Public Keys
This section introduces the notion of an updatable public key (UPK), in which
public keys can be updated in a public fashion, and such that they are indis-
tinguishable from freshly generated keys. This idea has been considered before
in the context of several cryptographic primitives, such as signatures [15,4] and
public-key encryption [40], but we wish to define it solely for keys, regardless of
the primitive they are used to support.
We begin by defining security for UPKs. Our definitions of indistinguisha-
bility and unforgeability resemble those that have already been used for Bitcoin
stealth keys [25] and in the context of other cryptographic primitives [4,40,23].
Indeed, we could continue to be inspired by stealth keys in our construction
of a UPK scheme, but given their reliance on hash functions this would render us
unable to prove statements about the keys using discrete log-based techniques, as
we would like to do in our construction of Quisquis in Section 5. We thus present
instead a purely algebraic UPK scheme based on DDH, inspired by “incomparable
public keys” [40].
3.1 Security definitions
An updatable public key system (UPK) is described by the following algorithms:
– params
$
← Setup(1
κ
) outputs the parameters of the scheme, including the
public and secret key spaces PK, SK. These are given implicitly as input to
all other algorithms.
5
