From 329be4eb351cb856b7a8bc2d2727b6f0194b3119 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Thu, 17 Aug 2017 17:08:50 +0200 Subject: criterea --- comparison/comparison.tex | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'comparison') diff --git a/comparison/comparison.tex b/comparison/comparison.tex index b47b2bc..1fab2a7 100644 --- a/comparison/comparison.tex +++ b/comparison/comparison.tex @@ -113,10 +113,14 @@ Chaum Offline \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{Robustness under network failures.} @@ -132,6 +136,13 @@ Chaum Offline while the exchange is fixed, the customers/merchant are not, so distributed key generation isn't always an option. It makes it hard to instantiate the scheme and hard to trust the deployed scheme. + \item \textbf{Realistic Exchange Storage Requirements.} + In schemes that have divisibility, the exchange still needs to + store the smallest denomination. Unless the scheme also has multiple denominations, + this storage requirements are unrealistic. + \item \textbf{Cryptographic Batching.} Some schemes allow + withdrawing a wallet with $2^\ell$ coins in $O(1)$ with + $O(1)$ storage and $O(1)$ batch spending. \end{itemize} -- cgit v1.2.3