add link to crypto primitive benchmarks, fix bibtex issues
This commit is contained in:
parent
f9b0db4146
commit
028fd5bedf
@ -3,6 +3,7 @@
|
||||
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},
|
||||
@ -13,23 +14,6 @@
|
||||
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,
|
||||
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{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},
|
||||
}
|
||||
|
||||
|
@ -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}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user