summaryrefslogtreecommitdiff
path: root/doc/paper
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2017-05-18 09:59:43 +0200
committerChristian Grothoff <christian@grothoff.org>2017-05-18 09:59:43 +0200
commit028fd5bedfe87d05d9a7002e1d30cf9687014f3b (patch)
tree8b1ecf2169116c77fc8724ee8ced5649691cae56 /doc/paper
parentf9b0db41464812e9d15e8a5498c3c9b042f3506f (diff)
downloadexchange-028fd5bedfe87d05d9a7002e1d30cf9687014f3b.tar.gz
exchange-028fd5bedfe87d05d9a7002e1d30cf9687014f3b.tar.bz2
exchange-028fd5bedfe87d05d9a7002e1d30cf9687014f3b.zip
add link to crypto primitive benchmarks, fix bibtex issues
Diffstat (limited to 'doc/paper')
-rw-r--r--doc/paper/taler.bib20
-rw-r--r--doc/paper/taler.tex22
2 files changed, 16 insertions, 26 deletions
diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib
index 9f0d2908..0dc60809 100644
--- a/doc/paper/taler.bib
+++ b/doc/paper/taler.bib
@@ -3,23 +3,8 @@
author={Nakamoto, Satoshi},
year={2008}
}
-@inproceedings{ BDL+11,
- author = {Daniel J. Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang},
- title = {High-speed high-security signatures},
- booktitle = {Cryptographic Hardware and Embedded Systems -- {CHES 2011}},
- editor = {Bart Preneel and Tsuyoshi Takagi},
- series = {Lecture Notes in Computer Science},
- publisher = {Springer-Verlag Berlin Heidelberg},
- volume = {6917},
- year = {2011},
- pages = {124--142},
- note = {see also full version \cite{BDL+12}},
-}
-@article{ BDL+12,
- author = {Daniel J. Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang},
- title = {High-speed high-security signatures},
- journal@inproceedings{ BDL+11,
+@inproceedings{ BDL+11,
author = {Daniel J. Bernstein and Niels Duif and Tanja Lange and Peter Schwabe and Bo-Yin Yang},
title = {High-speed high-security signatures},
booktitle = {Cryptographic Hardware and Embedded Systems -- {CHES 2011}},
@@ -29,7 +14,6 @@
volume = {6917},
year = {2011},
pages = {124--142},
- note = {see also full version \cite{BDL+12}},
}
@article{eddsa,
@@ -82,8 +66,6 @@
booktitle = {23nd Annual Network and Distributed System Security Symposium, {NDSS}
2016, San Diego, California, USA, February 21-24, 2016},
year = {2016},
- booktitle = {23nd Annual Network and Distributed System Security Symposium, {NDSS}
- 2016, San Diego, California, USA, February 21-24, 2016},
publisher = {The Internet Society},
}
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 48e4a1c4..30f9934c 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1629,14 +1629,22 @@ Unfortunately it was not possible to experimentally compare the performance of
Taler directly to other e-cash systems, since to our best knowledge there
is no working and publicly available implementation of any of them.
-When compared with the current average confirmation time for Bitcoin payments,
-Taler is many orders of magnitude faster. While a confirmation time of Taler
-is in the order of a few hundered milliseconds (including database access and
-network latency), the time to mine even one block in Bitcoin is around ten
+When compared with the current average confirmation time for Bitcoin
+payments, Taler is many orders of magnitude faster. In a LAN, Taler
+transactions taking about ten milliseconds are doable, given the speed
+of modern SSD drives and RSA/EdDSA signature verification
+algorithms.\footnote{We refer to \url{https://bench.cr.yp.to/} for
+ detailed benchmarks of cryptographic primitives.} In practice, a
+few network round trips for the TCP/HTTPS handshakes and the HTTP
+request dominate overall latency. While the confirmation time of
+Taler is thus typically in the order of a few hundered milliseconds,
+the time to mine even one block in Bitcoin is around ten
minutes \footnote{Data retrieved in May 2017 from
-\url{https://blockchain.info/stats}}. Very conservative Bitcoin merchants,
-such as exchanges, wait up to six blocks until they consider a transaction
-confirmed.
+ \url{https://blockchain.info/stats}}. Bitcoin merchants following
+the Bitcoin specification must wait for six such blocks until they
+consider a transaction confirmed. Thus latency for durable
+transactions in Bitcoin is about three to four orders of magnitude
+lower.
\section{Discussion}