diff options
author | Jeffrey Burdges <burdges@gnunet.org> | 2017-08-21 17:43:04 +0200 |
---|---|---|
committer | Jeffrey Burdges <burdges@gnunet.org> | 2017-08-21 17:43:04 +0200 |
commit | 757227f8877f1356c2fdfd9b6208c8b78f966a50 (patch) | |
tree | c825ad1230b05d21e689a70bc78ede9d79b50049 /comparison | |
parent | d6de554abbe6737c0b56b824ee795f6f5f89fa78 (diff) | |
download | papers-757227f8877f1356c2fdfd9b6208c8b78f966a50.tar.gz papers-757227f8877f1356c2fdfd9b6208c8b78f966a50.tar.bz2 papers-757227f8877f1356c2fdfd9b6208c8b78f966a50.zip |
Improve discussion
Diffstat (limited to 'comparison')
-rw-r--r-- | comparison/comparison.tex | 20 |
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 |