[GNUnet-SVN] [taler-exchange] branch master updated: add link to crypto primitive benchmarks, fix bibtex issues

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new 028fd5b  add link to crypto primitive benchmarks, fix bibtex issues
028fd5b is described below

commit 028fd5bedfe87d05d9a7002e1d30cf9687014f3b
Author: Christian Grothoff <address@hidden>
AuthorDate: Thu May 18 09:59:43 2017 +0200

    add link to crypto primitive benchmarks, fix bibtex issues
---
 doc/paper/taler.bib | 20 +-------------------
 doc/paper/taler.tex | 22 +++++++++++++++-------
 2 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib
index 9f0d290..0dc6080 100644
--- a/doc/paper/taler.bib
+++ b/doc/paper/taler.bib
@@ -3,23 +3,8 @@
   author={Nakamoto, Satoshi},
   year={2008}
 }
address@hidden 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}},
-}
 
address@hidden 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},
-  address@hidden BDL+11,
address@hidden 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 48e4a1c..30f9934 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}
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden