summaryrefslogtreecommitdiff
path: root/comparison
diff options
context:
space:
mode:
authorJeffrey Burdges <burdges@gnunet.org>2017-08-21 17:43:04 +0200
committerJeffrey Burdges <burdges@gnunet.org>2017-08-21 17:43:04 +0200
commit757227f8877f1356c2fdfd9b6208c8b78f966a50 (patch)
treec825ad1230b05d21e689a70bc78ede9d79b50049 /comparison
parentd6de554abbe6737c0b56b824ee795f6f5f89fa78 (diff)
downloadpapers-757227f8877f1356c2fdfd9b6208c8b78f966a50.tar.gz
papers-757227f8877f1356c2fdfd9b6208c8b78f966a50.tar.bz2
papers-757227f8877f1356c2fdfd9b6208c8b78f966a50.zip
Improve discussion
Diffstat (limited to 'comparison')
-rw-r--r--comparison/comparison.tex20
1 files changed, 10 insertions, 10 deletions
diff --git a/comparison/comparison.tex b/comparison/comparison.tex
index 0c6b4f9..ae2920d 100644
--- a/comparison/comparison.tex
+++ b/comparison/comparison.tex
@@ -148,7 +148,8 @@ Taler
% Exculpability under ...
\item \textbf{Key expiration.}
Can the exchange rotate key material without disrupting the operation
- of customers' wallets?
+ of customers' wallets? There are many schemes that do not address this
+ directly and adding it may require larger changes to the protocol.
\item \textbf{Taxability.}
Is income transparent to the exchange? Do transfers among
distrusting parties require that the exchange record the transaction?
@@ -161,19 +162,18 @@ Taler
and instantiating such schemes becomes difficult.
By comparison, blind signatures normally provide information theoretic security.
\item \textbf{Realistic exchange storage requirements.}
- Both compact and divisible e-cash 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 requirements would
- become unrealistic, but doing so
+ Is it possible for the exchange to detect double spending
+ without having to expand a divisible coin into parts of the smallest possible
+ size and store one or more records for each part?
\item \textbf{Cryptographic batching.}
+ Does the scheme save bandwidth through batching?
Compact e-cash schemes provide withdrawal operations that extract
- many coins with one single withdrawal, reducing overall bandwidth
+ many coins with one single withdrawal (W), reducing overall bandwidth
for fixed denomination values, but not computation. %% VERIFY
- Divisible e-cash schemes batch both withdrawal and deposit operations,
+ Divisible e-cash schemes batch both withdrawal and deposit operations (WD),
providing greater bandwidth reduction, and possibly computation
- reduction. These savings are limited however by the exchange's
- storage requirements, and divisible schemes depend upon trusted setup
+ reduction. There is a trade off between these savings and the exchange's
+ storage requirements, and the divisible schemes depend upon trusted setup
for their anonymity properties.
\item \textbf{Change/Divisibility.}
Is there partial spending? If so, is it handled by giving change