summaryrefslogtreecommitdiff
path: root/comparison
diff options
context:
space:
mode:
authorJeffrey Burdges <burdges@gnunet.org>2017-08-21 16:20:08 +0200
committerJeffrey Burdges <burdges@gnunet.org>2017-08-21 16:20:08 +0200
commitb7cb064fb50fcd2de7bb235596d08fa2a122aa82 (patch)
tree3a20ff0b5a5b270770ce663f676a3b22fce1541e /comparison
parent6ebf7792c66b13dad54cfb515d4a54160cab621a (diff)
downloadpapers-b7cb064fb50fcd2de7bb235596d08fa2a122aa82.tar.gz
papers-b7cb064fb50fcd2de7bb235596d08fa2a122aa82.tar.bz2
papers-b7cb064fb50fcd2de7bb235596d08fa2a122aa82.zip
Merge refresh and refunds column, remove Endorse, comment out Traceability and Transferability
Diffstat (limited to 'comparison')
-rw-r--r--comparison/comparison.tex102
1 files changed, 51 insertions, 51 deletions
diff --git a/comparison/comparison.tex b/comparison/comparison.tex
index 88db20d..556354d 100644
--- a/comparison/comparison.tex
+++ b/comparison/comparison.tex
@@ -21,6 +21,8 @@
}
\newcommand*\rot{\multicolumn{1}{R{45}{1em}}}% no optional argument here, please!
+\newcolumntype{H}{>{\setbox0=\hbox\bgroup}c<{\egroup}@{}}
+
\title{E-Cash Comparison}
\date{\today}
@@ -32,88 +34,86 @@
\newcommand\Y{\ding{51}} % {\checkmark}
\newcommand\N{\ding{55}}
-\begin{tabular}{r|ccccccccccccc}
+\begin{tabular}{r|cccHHcccccc}
&
\rot{Instant enforcement} &
\rot{Robust anonymity} &
\rot{Key expiration} &
%
-\rot{Traceability} &
-\rot{Transferability} &
+&% \rot{Traceability} &
+&% \rot{Transferability} &
\rot{Taxability} &
%
% \rot{Withdrawal cost} & \rot{Deposit cost} &
\rot{Trustless anonymity} &
-\rot{Realistic Exchange Storage} &
-\rot{Cryptographic Batching} &
-\rot{Change} &
+\rot{Realistic exchange storage} &
+\rot{Cryptographic batching} &
%
-\rot{Receipts} &
-\rot{Endorsed} &
-\rot{Refunds}
+\rot{Change} &
+\rot{Receipts \& Refunds}
\\ \hline
Taler
& \Y & \Y & \Y
& \N & S & \Y
% & $\log n$ & $\log n$
-& \Y & \Y & \N & ON
-& \Y & \Y & Anon
+& \Y & \Y & \N
+& ON & \Y
\\
Digicash \cite{chaum1983,schoenmakers1997security}
& \Y & \Y & \Y
& \N & S & \N
% & $\log n$ & $\log n$
-& \Y & \Y & \N & \N
-& \N & \N & ?
+& \Y & \Y & \N
+& \N & \N
\\
Tracz \cite{tracz2001} % HINDE
& \Y & \Y & %?
& \N & S & \N
% & $\log n$ & $\log n$
-& \Y & \Y & \N & ON
-& \N? & \N? & ?
+& \Y & \Y & \N
+& ON & \N
\\
Offline Chaum \cite{chaum1990}
& \N & \N & %?
& \N & S & \N
% & $\log n$ & $\log n$
-& \Y & \N & OFF
-& \N? & \N? & ?
+& \Y & \N & \N
+& OFF & \N
\\
Compact ECash \cite{camenisch2005}
& \N & \N & %?
& \N & S & \N
% & $\log n$ & $\log n$
-& \Y & \N & W & OFF % We're guessing trustless anonymity because not trusted setup
-& \N? & \N? & \N?
+& \Y & \N & W % We're guessing trustless anonymity because not trusted setup
+& OFF & \N
\\
Martens \cite{maertens2015}
& \N & \N & %?
& \N & S & \N
% & $\log n$ & $\log n$
-& \Y & \N & W & OFF % We're guessing trustless anonymity because not trusted setup
-& \N? & \N? & \N?
+& \Y & \N & W % We're guessing trustless anonymity because not trusted setup
+& OFF & \N
\\
Divisible ECash \cite{canard2015scalable}
& \N & \N & %?
& \N & S & \N
% & $\log n$ & $\log n$
-& \N & \N & W & OFF
-& \N? & \N? & \N?
+& \N & \N & W
+& OFF & \N
\\
Compact Taler
& \Y & \Y & \Y
& \N & S & \Y
% & $\log n$ & $\log n$
-& \Y & \Y & W & ON
-& \Y & \Y & Anon
+& \Y & \Y & W
+& ON & \Y
\\
Divisible Taler
& \Y & \Y & \Y
& \N & S & \Y
% & $\log n$ & $\log n$
-& \N & \Y & WD & ON
-& \Y & \Y & Anon
+& \N & \Y & WD
+& ON & \Y
\\ \hline
\end{tabular}
@@ -149,46 +149,35 @@ Divisible Taler
transaction.
% TODO: Expand definition and cite the successor papers to Zerocash/BOLT
% that handle regulation?
- \item \textbf{Withdrawal cost.}
- Asymptotic time and storage costs for the wallet during and after withdrawal.
- Also frequently bandwidth costs for the withdrawal operation. %TODO: Details?
- FIXME: Do we have a rigorous definition for this? Literature
- only uses big-O for batched withdrawal/deposit.
- \item \textbf{Deposit costs.}
- Asymptotic time and storage costs for the exchange's double spending
- protections required during deposit.
- Frequently ignored, especially in ``constant time'' schemes.
- FIXME: Do we have a rigorous definition for this? Literature
- only uses big-O for batched withdrawal/deposit.
\item \textbf{Change/Divisibility.}
Which mechanism is used for divisibility? (None/OFFline/ONline).
- \item \textbf{Receipts for spending.}
+ \item \textbf{Receipts \& Refunds.}
The customer either can prove that they payed for
- a contract, or they can get their (unlinkable) money back.
- \item \textbf{Endorsed.} Separation of the coin and permission to spend
- it, see \cite{camenisch2007endorsed}. Allows fair exchange (?).
- \item \textbf{Refunds.} Anonymous/Deanonymizing/Payment/None/Unspecified
-
- \item \textbf{Trustless anonymity}
+ a contract, or they can get their (unlinkable) money back,
+ which provides a form of fair exchange ala \cite{camenisch2007endorsed}.
+ Also merchants can issue refunds for completed transactions.
+ These operations must not introduce linkability or otherwise
+ compromise the customer's anonymity.
+ \item \textbf{Trustless anonymity.}
At present, divisible ecash schemes entrust anonymity properties
to a trusted setup phase. Users cannot easily participate in this
trusted setup, so they must entrust some party with their anonymity,
and instantiating such schemes becomes difficult.
- By comparison, blind sugnatures normally provide information theoretic security.
- \item \textbf{Realistic Exchange Storage Requirements.}
+ By comparison, blind signatures normally provide information theoretic security.
+ \item \textbf{Realistic exchange storage requirements.}
Both compact and divisible ecash schemes require the exchange store
coins only as the smallest denomination to prevent double spending.
In practice, these schemes should be adjusted to store larger
- denominations or else the exchange's storage requirments would
+ denominations or else the exchange's storage requirements would
become unrealistic, but doing so
- \item \textbf{Cryptographic Batching.}
+ \item \textbf{Cryptographic batching.}
Compact ECash schemes provide withdrawal operations that extract
many coins with one single withdrawal, reducing overall bandwidth
for fixed denomination values, but not computation. %% VERIFY
Divisible ECash schemes batch both withdrawal and deposit operations,
- providing greater bandwith reduction, and possibly computaiton
+ providing greater bandwith reduction, and possibly computation
reduction. These savings are limited however by the exchange's
- storage requirments, and divisible schemes depend upon trusted setup
+ storage requirements, and divisible schemes depend upon trusted setup
for their anonymity properties.
\end{itemize}
@@ -196,6 +185,17 @@ Divisible Taler
These are discussion items that do not necessarily need to appear in the table.
\begin{itemize}
+ \item \textbf{Withdrawal cost.}
+ Asymptotic time and storage costs for the wallet during and after withdrawal.
+ Also frequently bandwidth costs for the withdrawal operation. %TODO: Details?
+ FIXME: Do we have a rigorous definition for this? Literature
+ only uses big-O for batched withdrawal/deposit.
+ \item \textbf{Deposit costs.}
+ Asymptotic time and storage costs for the exchange's double spending
+ protections required during deposit.
+ Frequently ignored, especially in ``constant time'' schemes.
+ FIXME: Do we have a rigorous definition for this? Literature
+ only uses big-O for batched withdrawal/deposit.
\item \textbf{Robustness under network failures.}
Protocol aborts, including network failures, cannot compromise any party's
financial security or the customer's anonymity.