-
Notifications
You must be signed in to change notification settings - Fork 0
/
Elrond_Whitepaper_FR.bib
1228 lines (1113 loc) · 78.8 KB
/
Elrond_Whitepaper_FR.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
@inproceedings{33,
address = {New York, NY, USA},
series = {{CCS} '01},
title = {Accountable-subgroup {Multisignatures}: {Extended} {Abstract}},
isbn = {978-1-58113-385-1},
shorttitle = {Accountable-subgroup {Multisignatures}},
url = {http://doi.acm.org/10.1145/501983.502017},
doi = {10.1145/501983.502017},
abstract = {Formal models and security proofs are especially important for multisignatures: in contrast to threshold signatures, no precise definitions were ever provided for such schemes, and some proposals were subsequently broken.In this paper, we formalize and implement a variant of multi-signature schemes, Accountable-Subgroup Multisignatures (ASM). In essence, ASM schemes enable any subgroup, S, of a given group, G, of potential signers, to sign efficiently a message M so that the signature provably reveals the identities of the signers in S to any verifier.Specifically, we provide:The first formal model of security for multisignature schemes that explicitly includes key generation (without relying on trusted third parties);A protocol, based on Schnorr's signature scheme [33], that is both provable and efficient:Only three rounds of communication are required per signature.The signing time per signer is the same as for the single-signer Schnorr scheme, regardless of the number of signers.The verification time is only slightly greater than that for the single-signer Schnorr scheme.The signature length is the same as for the single signer Schnorr scheme, regardless of the number of signers.Our proof of security relies on random oracles and the hardness of the Discrete Log Problem.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 8th {ACM} {Conference} on {Computer} and {Communications} {Security}},
publisher = {ACM},
author = {Micali, Silvio and Ohta, Kazuo and Reyzin, Leonid},
year = {2001},
keywords = {digital signature, multisignature},
pages = {245--254}
}
@inproceedings{32,
title = {A public-key cryptosystem suitable for digital multisignatures},
abstract = {K. Itakura and K. Nakamura, “A public-key cryptosystem suitable for digital multisignatures”. NEC J.Res.Dev.71(Oct.1983)},
author = {Itakura, K and Nakamura, K},
year = {1983}
}
@misc{19,
title = {Why we are building {Cardano} - {Introduction}},
url = {https://whycardano.com/},
abstract = {Why we are building Cardano},
urldate = {2018-04-19},
journal = {Why we are building Cardano},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\Z2FLNIXT\\whycardano.com.html:text/html}
}
@misc{noauthor_introduction_nodate,
title = {Introduction},
url = {/},
abstract = {Why we are building Cardano},
urldate = {2018-04-19},
journal = {Why we are building Cardano},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\SS9CX2LC\\whycardano.com.html:text/html}
}
@misc{noauthor_ethereum_2018,
title = {Ethereum {Energy} {Consumption} vs {Bitcoin} {Energy} {Consumption}},
url = {https://digiconomist.net/},
abstract = {The Ethereum Energy Consumption Index provides the latest estimate of the total energy consumption of the Ethereum network.},
language = {en-US},
urldate = {2018-04-19},
journal = {Digiconomist},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\4UILCB26\\ethereum-energy-consumption.html:text/html}
}
@misc{noauthor_bitcoin_2018,
title = {Bitcoin - transaction {Rate}, difficulty growth chart, hashrate distribution},
url = {https://blockchain.info/},
abstract = {The number of Bitcoin transactions added to the mempool per second.},
urldate = {2018-04-19},
journal = {Blockchain.info},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\TYHQAKCF\\transactions-per-second.html:text/html}
}
@misc{mcmahan_federated_2017,
title = {Federated {Learning}: {Collaborative} {Machine} {Learning} without {Centralized} {Training} {Data}},
shorttitle = {Federated {Learning}},
url = {https://research.googleblog.com/2017/04/federated-learning-collaborative.html},
abstract = {Posted by Brendan McMahan and Daniel Ramage, Research Scientists Standard machine learning approaches require centralizing the training da...},
language = {en},
urldate = {2018-04-19},
journal = {Research Blog},
author = {McMahan, Brendan and Ramage, Daniel},
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\JWRSIGWZ\\federated-learning-collaborative.html:text/html}
}
@inproceedings{44,
series = {Lecture {Notes} in {Computer} {Science}},
title = {A {Certified} {Digital} {Signature}},
isbn = {978-0-387-97317-3 978-0-387-34805-6},
url = {https://link.springer.com/chapter/10.1007/0-387-34805-0_21},
doi = {10.1007/0-387-34805-0_21},
abstract = {A practical digital signature system based on a conventional encryption function which is as secure as the conventional encryption function is described. Since certified conventional systems are available it can be implemented quickly, without the several years delay required for certification of an untested system.},
language = {en},
urldate = {2018-04-19},
booktitle = {Advances in {Cryptology} — {CRYPTO}’ 89 {Proceedings}},
publisher = {Springer, New York, NY},
author = {Merkle, Ralph C.},
month = aug,
year = {1989},
pages = {218--238},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\MPX49K73\\Merkle - 1989 - A Certified Digital Signature.pdf:application/pdf;Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\MDRSZER9\\0-387-34805-0_21.html:text/html}
}
@inproceedings{15,
address = {Berkeley, CA, USA},
series = {{OSDI} '99},
title = {Practical {Byzantine} {Fault} {Tolerance}},
isbn = {978-1-880446-39-3},
url = {http://dl.acm.org/citation.cfm?id=296806.296824},
urldate = {2018-04-19},
booktitle = {Proceedings of the {Third} {Symposium} on {Operating} {Systems} {Design} and {Implementation}},
publisher = {USENIX Association},
author = {Castro, Miguel and Liskov, Barbara},
year = {1999},
pages = {173--186}
}
@inproceedings{36,
series = {Lecture {Notes} in {Computer} {Science}},
title = {Multisignatures as {Secure} as the {Diffie}-{Hellman} {Problem} in the {Plain} {Public}-{Key} {Model}},
isbn = {978-3-642-03297-4 978-3-642-03298-1},
url = {https://link.springer.com/chapter/10.1007/978-3-642-03298-1_3},
doi = {10.1007/978-3-642-03298-1_3},
abstract = {A multisignature scheme allows a group of signers to cooperate to generate a compact signature on a common document. The length of the multisignature depends only on the security parameters of the signature schemes and not on the number of signers involved. The existing state-of-the-art multisignature schemes suffer either from impractical key setup assumptions, from loose security reductions, or from inefficient signature verification. In this paper, we present two new multisignature schemes that address all of these issues, i.e., they have efficient signature verification, they are provably secure in the plain public-key model, and their security is tightly related to the computation and decisional Diffie-Hellman problems in the random oracle model. Our construction derives from variants of EDL signatures.},
language = {en},
urldate = {2018-04-19},
booktitle = {Pairing-{Based} {Cryptography} – {Pairing} 2009},
publisher = {Springer, Berlin, Heidelberg},
author = {Le, Duc-Phong and Bonnecaze, Alexis and Gabillon, Alban},
month = aug,
year = {2009},
pages = {35--51},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\PFV8QFWE\\978-3-642-03298-1_3.html:text/html}
}
@inproceedings{34,
series = {Lecture {Notes} in {Computer} {Science}},
title = {The {Power} of {Proofs}-of-{Possession}: {Securing} {Multiparty} {Signatures} against {Rogue}-{Key} {Attacks}},
isbn = {978-3-540-72539-8 978-3-540-72540-4},
shorttitle = {The {Power} of {Proofs}-of-{Possession}},
url = {https://link.springer.com/chapter/10.1007/978-3-540-72540-4_13},
doi = {10.1007/978-3-540-72540-4_13},
abstract = {Multiparty signature protocols need protection against rogue-key attacks, made possible whenever an adversary can choose its public key(s) arbitrarily. For many schemes, provable security has only been established under the knowledge of secret key (KOSK) assumption where the adversary is required to reveal the secret keys it utilizes. In practice, certifying authorities rarely require the strong proofs of knowledge of secret keys required to substantiate the KOSK assumption. Instead, proofs of possession (POPs) are required and can be as simple as just a signature over the certificate request message. We propose a general registered key model, within which we can model both the KOSK assumption and in-use POP protocols. We show that simple POP protocols yield provable security of Boldyreva’s multisignature scheme [11], the LOSSW multisignature scheme [28], and a 2-user ring signature scheme due to Bender, Katz, and Morselli [10]. Our results are the first to provide formal evidence that POPs can stop rogue-key attacks.},
language = {en},
urldate = {2018-04-19},
booktitle = {Advances in {Cryptology} - {EUROCRYPT} 2007},
publisher = {Springer, Berlin, Heidelberg},
author = {Ristenpart, Thomas and Yilek, Scott},
month = may,
year = {2007},
pages = {228--245},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\56MN6CPH\\Ristenpart and Yilek - 2007 - The Power of Proofs-of-Possession Securing Multip.pdf:application/pdf;Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\2CCSLFU7\\978-3-540-72540-4_13.html:text/html}
}
@misc{28,
title = {Schnorr {Signatures} are {Non}-{Malleable} in the {Random} {Oracle} {Model}},
url = {https://download.wpsoftware.net/bitcoin/wizardry/schnorr-mall.pdf},
author = {Poelstra, Andrew},
year = {2014}
}
@inproceedings{26,
series = {Lecture {Notes} in {Computer} {Science}},
title = {Randomly {Failed}! {The} {State} of {Randomness} in {Current} {Java} {Implementations}},
isbn = {978-3-642-36094-7 978-3-642-36095-4},
url = {https://link.springer.com/chapter/10.1007/978-3-642-36095-4_9},
doi = {10.1007/978-3-642-36095-4_9},
abstract = {This paper investigates the Randomness of several Java Runtime Libraries by inspecting the integrated Pseudo Random Number Generators. Significant weaknesses in different libraries including Android, are uncovered.},
language = {en},
urldate = {2018-04-19},
booktitle = {Topics in {Cryptology} – {CT}-{RSA} 2013},
publisher = {Springer, Berlin, Heidelberg},
author = {Michaelis, Kai and Meyer, Christopher and Schwenk, Jörg},
month = feb,
year = {2013},
pages = {129--144},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\DHZSIBBV\\978-3-642-36095-4_9.html:text/html}
}
@article{29,
title = {Bitcoin {Transaction} {Malleability} and {MtGox}},
volume = {8713},
url = {http://arxiv.org/abs/1403.6676},
doi = {10.1007/978-3-319-11212-1_18},
abstract = {In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves. This allows an attacker to mount a malleability attack in which it intercepts, modifies, and rebroadcasts a transaction, causing the transaction issuer to believe that the original transaction was not confirmed. In February 2014 MtGox, once the largest Bitcoin exchange, closed and filed for bankruptcy claiming that attackers used malleability attacks to drain its accounts. In this work we use traces of the Bitcoin network for over a year preceding the filing to show that, while the problem is real, there was no widespread use of malleability attacks before the closure of MtGox.},
urldate = {2018-04-19},
journal = {arXiv:1403.6676 [cs]},
author = {Decker, Christian and Wattenhofer, Roger},
year = {2014},
note = {arXiv: 1403.6676},
keywords = {Computer Science - Computational Engineering, Finance, and Science, Computer Science - Cryptography and Security},
pages = {313--326},
file = {arXiv\:1403.6676 PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\XHLHNGJI\\Decker and Wattenhofer - 2014 - Bitcoin Transaction Malleability and MtGox.pdf:application/pdf;arXiv.org Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\RPRM5K8Q\\1403.html:text/html}
}
@inproceedings{27,
series = {Lecture {Notes} in {Computer} {Science}},
title = {Twisted {Edwards} {Curves}},
isbn = {978-3-540-68159-5 978-3-540-68164-9},
url = {https://link.springer.com/chapter/10.1007/978-3-540-68164-9_26},
doi = {10.1007/978-3-540-68164-9_26},
abstract = {This paper introduces “twisted Edwards curves,” a generalization of the recently introduced Edwards curves; shows that twisted Edwards curves include more curves over finite fields, and in particular every elliptic curve in Montgomery form; shows how to cover even more curves via isogenies; presents fast explicit formulas for twisted Edwards curves in projective and inverted coordinates; and shows that twisted Edwards curves save time for many curves that were already expressible as Edwards curves.},
language = {en},
urldate = {2018-04-19},
booktitle = {Progress in {Cryptology} – {AFRICACRYPT} 2008},
publisher = {Springer, Berlin, Heidelberg},
author = {Bernstein, Daniel J. and Birkner, Peter and Joye, Marc and Lange, Tanja and Peters, Christiane},
month = jun,
year = {2008},
pages = {389--405},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\I8A5RLT7\\978-3-540-68164-9_26.html:text/html}
}
@book{24,
address = {Berlin Heidelberg},
title = {Understanding {Cryptography}: {A} {Textbook} for {Students} and {Practitioners}},
isbn = {978-3-642-04100-6},
shorttitle = {Understanding {Cryptography}},
url = {//www.springer.com/gp/book/9783642041006},
abstract = {Cryptography is now ubiquitous – moving beyond the traditional environments, such as government communications and banking systems, we see cryptographic techniques realized in Web browsers, e-mail programs, cell phones, manufacturing systems, embedded software, smart buildings, cars, and even medical implants. Today's designers need a comprehensive understanding of applied cryptography. After an introduction to cryptography and data security, the authors explain the main techniques in modern cryptography, with chapters addressing stream ciphers, the Data Encryption Standard (DES) and 3DES, the Advanced Encryption Standard (AES), block ciphers, the RSA cryptosystem, public-key cryptosystems based on the discrete logarithm problem, elliptic-curve cryptography (ECC), digital signatures, hash functions, Message Authentication Codes (MACs), and methods for key establishment, including certificates and public-key infrastructure (PKI). Throughout the book, the authors focus on communicating the essentials and keeping the mathematics to a minimum, and they move quickly from explaining the foundations to describing practical implementations, including recent topics such as lightweight ciphers for RFIDs and mobile devices, and current key-length recommendations. The authors have considerable experience teaching applied cryptography to engineering and computer science students and to professionals, and they make extensive use of examples, problems, and chapter reviews, while the book’s website offers slides, projects and links to further resources. This is a suitable textbook for graduate and advanced undergraduate courses and also for self-study by engineers.},
language = {en},
urldate = {2018-04-19},
publisher = {Springer-Verlag},
author = {Paar, Christof and Pelzl, Jan},
year = {2010},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\5RXJ56AU\\9783642041006.html:text/html}
}
@inproceedings{35,
address = {New York, NY, USA},
series = {{CCS} '06},
title = {Multi-signatures in the {Plain} public-{Key} {Model} and a {General} {Forking} {Lemma}},
isbn = {978-1-59593-518-2},
url = {http://doi.acm.org/10.1145/1180405.1180453},
doi = {10.1145/1180405.1180453},
abstract = {A multi-signature scheme enables a group of signers to produce a compact, joint signature on a common document, and has many potential uses. However, existing schemes impose key setup or PKI requirements that make them impractical, such as requiring a dedicated, distributed key generation protocol amongst potential signers, or assuming strong, concurrent zero-knowledge proofs of knowledge of secret keys done to the CA at key registration. These requirements limit the use of the schemes. We provide a new scheme that is proven secure in the plain public-key model, meaning requires nothing more than that each signer has a (certified) public key. Furthermore, the important simplification in key management achieved is not at the cost of efficiency or assurance: our scheme matches or surpasses known ones in terms of signing time, verification time and signature size, and is proven secure in the random-oracle model under a standard (not bilinear map related) assumption. The proof is based on a simplified and general Forking Lemma that may be of independent interest.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 13th {ACM} {Conference} on {Computer} and {Communications} {Security}},
publisher = {ACM},
author = {Bellare, Mihir and Neven, Gregory},
year = {2006},
keywords = {cryptography, digital signatures, forking lemma, multi-signatures},
pages = {390--399}
}
@INPROCEEDINGS{4,
author = {Dan Boneh and Ben Lynn and Hovav Shacham},
title = {Short signatures from the Weil pairing},
booktitle = {Advances in Cryptology – ASIACRYPT ’01, LNCS},
year = {2001},
pages = {514--532},
publisher = {Springer}
}
@INPROCEEDINGS{5,
title={Compact Multi-signatures for Smaller Blockchains},
booktitle={Advances in Cryptology – ASIACRYPT 2018},
series={Lecture Notes in Computer Science},
publisher={Springer},
volume={11273},
pages={435-464},
doi={10.1007/978-3-030-03329-3_15},
author={Dan Boneh and Manu Drijvers and Gregory Neven},
year=2018
}
@techreport{30,
title = {Simple {Schnorr} {Multi}-{Signatures} with {Applications} to {Bitcoin}},
url = {https://eprint.iacr.org/2018/068},
abstract = {We describe a new Schnorr-based multi-signature scheme (i.e., a protocol which allows a group of signers to produce a short, joint signature on a common message), provably secure in the plain public-key model (meaning that signers are only required to have a public key, but do not have to prove knowledge of the private key corresponding to their public key to some certification authority or to other signers before engaging the protocol), which improves over the state-of-art scheme of Bellare and Neven (ACM-CCS 2006) and its variants by Bagherzandi et al. (ACM-CCS 2008) and Ma et al. (Des. Codes Cryptogr., 2010) in two respects: (i) it is simple and efficient, having only two rounds of communication instead of three for the Bellare-Neven scheme and the same key and signature size as standard Schnorr signatures; (ii) it allows key aggregation, which informally means that the joint signature can be verified exactly as a standard Schnorr signature with respect to a single ``aggregated'' public key which can be computed from the individual public keys of the signers. This comes at the cost of a stronger security assumption, namely the hardness of the One-More Discrete Logarithm problem, rather than the standard Discrete Logarithm problem, and a looser security reduction due to a double invocation of the Forking Lemma. As an application, we explain how our new multi-signature scheme could improve both performance and user privacy in Bitcoin.},
number = {068},
urldate = {2018-04-19},
author = {Maxwell, Gregory and Poelstra, Andrew and Seurin, Yannick and Wuille, Pieter},
year = {2018},
keywords = {forking lemma, multi-signatures, Bitcoin, one-more discrete logarithm problem, public-key cryptography, Schnorr signatures},
file = {ePrint IACR Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\X2D6Y2C6\\Maxwell et al. - 2018 - Simple Schnorr Multi-Signatures with Applications .pdf:application/pdf;ePrint IACR Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\ZAVI7GAT\\068.html:text/html}
}
@inproceedings{31,
series = {Lecture {Notes} in {Computer} {Science}},
title = {On the {Exact} {Security} of {Schnorr}-{Type} {Signatures} in the {Random} {Oracle} {Model}},
isbn = {978-3-642-29010-7 978-3-642-29011-4},
url = {https://link.springer.com/chapter/10.1007/978-3-642-29011-4_33},
doi = {10.1007/978-3-642-29011-4_33},
abstract = {The Schnorr signature scheme has been known to be provably secure in the Random Oracle Model under the Discrete Logarithm (DL) assumption since the work of Pointcheval and Stern (EUROCRYPT ’96), at the price of a very loose reduction though: if there is a forger making at most q h random oracle queries, and forging signatures with probability ε F , then the Forking Lemma tells that one can compute discrete logarithms with constant probability by rewinding the forger O(qh/εF)O(qh/εF)\{{\textbackslash}mathcal O\}(q\_h/{\textbackslash}varepsilon\_F) times. In other words, the security reduction loses a factor O(qh)O(qh)\{{\textbackslash}mathcal O\}(q\_h) in its time-to-success ratio. This is rather unsatisfactory since q h may be quite large. Yet Paillier and Vergnaud (ASIACRYPT 2005) later showed that under the One More Discrete Logarithm (OMDL) assumption, any algebraic reduction must lose a factor at least q1/2hqh1/2q\_h{\textasciicircum}\{1/2\} in its time-to-success ratio. This was later improved by Garg et al. (CRYPTO 2008) to a factor q2/3hqh2/3q\_h{\textasciicircum}\{2/3\}. Up to now, the gap between q2/3hqh2/3q\_h{\textasciicircum}\{2/3\} and q h remained open. In this paper, we show that the security proof using the Forking Lemma is essentially the best possible. Namely, under the OMDL assumption, any algebraic reduction must lose a factor f(ε F )q h in its time-to-success ratio, where f ≤ 1 is a function that remains close to 1 as long as ε F is noticeably smaller than 1. Using a formulation in terms of expected-time and queries algorithms, we obtain an optimal loss factor Ω(q h ), independently of ε F . These results apply to other signature schemes based on one-way group homomorphisms, such as the Guillou-Quisquater signature scheme.},
language = {en},
urldate = {2018-04-19},
booktitle = {Advances in {Cryptology} – {EUROCRYPT} 2012},
publisher = {Springer, Berlin, Heidelberg},
author = {Seurin, Yannick},
month = apr,
year = {2012},
pages = {554--571},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\8T57XRUN\\Seurin - 2012 - On the Exact Security of Schnorr-Type Signatures i.pdf:application/pdf;Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\3GVU4KYD\\978-3-642-29011-4_33.html:text/html}
}
@misc{noauthor_poet_2015,
title = {{PoET} 1.0 {Specification} — {Sawtooth} v1.0.2 documentation},
url = {https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/poet.html},
urldate = {2018-04-19},
year = {2015},
file = {PoET 1.0 Specification — Sawtooth v1.0.2 documentation:C\:\\Users\\radu.chis\\Zotero\\storage\\A6S6PPH3\\poet.html:text/html}
}
@inproceedings{yakubu_correlation_2009,
title = {{CORRELATION} {BETWEEN} {LATENCY} {AND} {HOP} {COUNT}},
abstract = {The closeness of the web server (hop count) can simply appeal as a good web server to access. But, this might not be true if the latency is not in correlation with that of the hop count. This paper studies the correlation between latency and hop count. We first discuss the method, tools and utilities used to observe and generate the values of Round Trip Time (RTT) and hops count. Graphical analysis of RTT and hops count is depicted. Likewise, techniques for calculating the correlation coefficient of the RTT and Hops count are explained. The experiment shows that the two variables RTT and Hops count in network analysis are simply correlated.},
author = {Yakubu, Friday and M, Shehu and Aminu, Mustapha and Murtala, Hayatu},
month = dec,
year = {2009},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\EPQG2WJ5\\Yakubu et al. - 2009 - CORRELATION BETWEEN LATENCY AND HOP COUNT.pdf:application/pdf}
}
@phdthesis{buchman_tendermint:_2016,
address = {Guelph, Ontario, Canada},
title = {Tendermint: {Byzantine} {Fault} {Tolerance} in the {Age} of {Blockchains}},
url = {http://hdl.handle.net/10214/9769},
school = {University of Guelph},
author = {Buchman, Ethan},
year = {2016}
}
@misc{noauthor_neo_2018,
title = {{NEO} - {A} distributed network for the {Smart} {Economy} - {White} {Paper}},
url = {http://docs.neo.org/en-us/},
urldate = {2018-04-19},
year = {2018},
file = {NEO Smart Economy:C\:\\Users\\radu.chis\\Zotero\\storage\\BHS5VE8Y\\neo.org.html:text/html}
}
@misc{noauthor_neo_nodate,
title = {{NEO} {White} {Paper}},
url = {http://docs.neo.org/en-us/},
urldate = {2018-04-19},
file = {NEO White Paper:C\:\\Users\\radu.chis\\Zotero\\storage\\6J5KZPWF\\en-us.html:text/html}
}
@misc{20,
title = {Constellation - a blockchain microservice operating system - {White} {Paper}},
shorttitle = {Whitepaper},
url = {https://github.com/Constellation-Labs/Whitepaper},
urldate = {2018-04-19},
year = {2017},
note = {original-date: 2018-01-05T20:42:05Z}
}
@misc{noauthor_ethereum_2018-1,
title = {The {Ethereum} {Wiki} - {Proof} of {Stake} {FAQ}},
shorttitle = {wiki},
url = {https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ},
urldate = {2018-04-19},
month = apr,
year = {2018},
note = {original-date: 2014-02-14T23:05:17Z}
}
@misc{17,
title = {Using {Merklix} tree to shard block validation {\textbar} {Deadalnix}'s den},
url = {https://www.deadalnix.me/2016/11/06/using-merklix-tree-to-shard-block-validation/},
language = {en-US},
urldate = {2018-04-19},
year = {2016},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\C7MWKR85\\using-merklix-tree-to-shard-block-validation.html:text/html}
}
@misc{16,
title = {Op {Ed}: {The} {Many} {Faces} of {Sharding} for {Blockchain} {Scalability}},
shorttitle = {Op {Ed}},
url = {https://bitcoinmagazine.com/articles/op-ed-many-faces-sharding-blockchain-scalability/},
abstract = {Any programmer who has ever sat down to build a DApp at one point has had to think about the limits of current public blockchains, the most important and obvious one being their limited throughput, i.e., the number of transactions processed per second. In order to run a DApp that can handle real-world throughput ...},
language = {en},
urldate = {2018-04-19},
journal = {Bitcoin Magazine},
author = {Jia, Yaoqi},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\IWFYLRAH\\op-ed-many-faces-sharding-blockchain-scalability.html:text/html}
}
@inproceedings{nestmann_welcome_2006,
series = {Lecture {Notes} in {Computer} {Science}},
title = {Welcome to the {Jungle}: {A} {Subjective} {Guide} to {Mobile} {Process} {Calculi}},
isbn = {978-3-540-37376-6 978-3-540-37377-3},
shorttitle = {Welcome to the {Jungle}},
url = {https://link.springer.com/chapter/10.1007/11817949_4},
doi = {10.1007/11817949_4},
abstract = {Almost 30 years ago, the research on process calculi gained a lot of momentum with the invention of ACP, CCS and CSP. Later on, but also already 20 years ago, researchers started to consider so-called mobile variants of process calculi, in which communication channels were themselves treated as the exchanged data. The original Pi us arose out of a reformulation and extension of CCS. In turn, it boosted the invention and study of a whole zoo of further process calculi.In this tutorial, we provide a bird’s-eye view on the jungle of results, techniques and subtleties about mobile process calculi. Next to a rough overview on the zoo of calculi, this includes the coverage of both semantic and pragmatic aspects, ranging from notions of equivalence and expressiveness to challenging application domains.},
language = {en},
urldate = {2018-04-19},
booktitle = {{CONCUR} 2006 – {Concurrency} {Theory}},
publisher = {Springer, Berlin, Heidelberg},
author = {Nestmann, Uwe},
month = aug,
year = {2006},
pages = {52--63},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\J9NTS6N8\\11817949_4.html:text/html}
}
@inproceedings{ongaro_search_2014,
address = {Berkeley, CA, USA},
series = {{USENIX} {ATC}'14},
title = {In {Search} of an {Understandable} {Consensus} {Algorithm}},
isbn = {978-1-931971-10-2},
url = {http://dl.acm.org/citation.cfm?id=2643634.2643666},
abstract = {Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos; this makes Raft more understandable than Paxos and also provides a better foundation for building practical systems. In order to enhance understandability, Raft separates the key elements of consensus, such as leader election, log replication, and safety, and it enforces a stronger degree of coherency to reduce the number of states that must be considered. Results from a user study demonstrate that Raft is easier for students to learn than Paxos. Raft also includes a new mechanism for changing the cluster membership, which uses overlapping majorities to guarantee safety.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 2014 {USENIX} {Conference} on {USENIX} {Annual} {Technical} {Conference}},
publisher = {USENIX Association},
author = {Ongaro, Diego and Ousterhout, John},
year = {2014},
pages = {305--320}
}
@misc{noauthor_rdf_2014,
title = {{RDF} 1.1 {Concepts} and {Abstract} {Syntax}},
url = {https://www.w3.org/TR/rdf11-concepts/},
urldate = {2018-04-19},
year = {2014},
file = {RDF 1.1 Concepts and Abstract Syntax:C\:\\Users\\radu.chis\\Zotero\\storage\\7MKYWIIR\\rdf11-concepts.html:text/html}
}
@misc{23,
title = {{EOS}.{IO} {Technical} {White} {Paper} v2},
shorttitle = {Documentation},
url = {https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md},
urldate = {2018-04-19},
year = {2018},
note = {original-date: 2017-06-06T07:55:17Z}
}
@misc{22,
title = {{DPOS} {Consensus} {Algorithm} - {The} {Missing} {White} {Paper}},
url = {https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper},
abstract = {This is the missing white paper and analysis of delegated proof of stake (DPOS). The goal of this paper is to provide… by dantheman},
language = {en},
urldate = {2018-04-19},
journal = {Steemit},
author = {dantheman},
month = may,
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\87BAWAXE\\dpos-consensus-algorithm-this-missing-white-paper.html:text/html}
}
@misc{21,
title = {Bitshares - {Delegated} {Proof}-of-{Stake} {Consensus}},
url = {https://bitshares.org/technology/delegated-proof-of-stake-consensus/},
urldate = {2018-04-19},
year = {2014},
file = {Delegated Proof-of-Stake Consensus - BitShares:C\:\\Users\\radu.chis\\Zotero\\storage\\YCAKYMPV\\delegated-proof-of-stake-consensus.html:text/html}
}
@article{syta_keeping_2015,
title = {Keeping {Authorities} "{Honest} or {Bust}" with {Decentralized} {Witness} {Cosigning}},
url = {http://arxiv.org/abs/1503.08768},
abstract = {The secret keys of critical network authorities - such as time, name, certificate, and software update services - represent high-value targets for hackers, criminals, and spy agencies wishing to use these keys secretly to compromise other hosts. To protect authorities and their clients proactively from undetected exploits and misuse, we introduce CoSi, a scalable witness cosigning protocol ensuring that every authoritative statement is validated and publicly logged by a diverse group of witnesses before any client will accept it. A statement S collectively signed by W witnesses assures clients that S has been seen, and not immediately found erroneous, by those W observers. Even if S is compromised in a fashion not readily detectable by the witnesses, CoSi still guarantees S's exposure to public scrutiny, forcing secrecy-minded attackers to risk that the compromise will soon be detected by one of the W witnesses. Because clients can verify collective signatures efficiently without communication, CoSi protects clients' privacy, and offers the first transparency mechanism effective against persistent man-in-the-middle attackers who control a victim's Internet access, the authority's secret key, and several witnesses' secret keys. CoSi builds on existing cryptographic multisignature methods, scaling them to support thousands of witnesses via signature aggregation over efficient communication trees. A working prototype demonstrates CoSi in the context of timestamping and logging authorities, enabling groups of over 8,000 distributed witnesses to cosign authoritative statements in under two seconds.},
urldate = {2018-04-24},
journal = {arXiv:1503.08768 [cs]},
author = {Syta, Ewa and Tamas, Iulia and Visher, Dylan and Wolinsky, David Isaac and Jovanovic, Philipp and Gasser, Linus and Gailly, Nicolas and Khoffi, Ismail and Ford, Bryan},
month = mar,
year = {2015},
note = {arXiv: 1503.08768},
keywords = {Computer Science - Cryptography and Security},
annote = {Comment: 20 pages, 7 figures},
file = {arXiv\:1503.08768 PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\I8CI4ZZ4\\Syta et al. - 2015 - Keeping Authorities Honest or Bust with Decentra.pdf:application/pdf;arXiv.org Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\Q4XDPI7K\\1503.html:text/html}
}
@misc{singhal_introducing_2012,
title = {Introducing the {Knowledge} {Graph}: things, not strings},
shorttitle = {Introducing the {Knowledge} {Graph}},
url = {https://www.blog.google/products/search/introducing-knowledge-graph-things-not/},
abstract = {We hope this will give you a more complete picture of your interest, provide smarter search results, and pique your curiosity.},
language = {en},
urldate = {2018-04-19},
journal = {Google},
author = {Singhal, Amit},
month = may,
year = {2012},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\GWBGLE3H\\introducing-knowledge-graph-things-not.html:text/html}
}
@misc{noauthor_introducing_nodate,
title = {Introducing the {Knowledge} {Graph}: things, not strings},
shorttitle = {Introducing the {Knowledge} {Graph}},
url = {https://googleblog.blogspot.com/2012/05/introducing-knowledge-graph-things-not.html},
abstract = {Insights from Googlers into our products, technology, and the Google culture},
language = {en},
urldate = {2018-04-19},
journal = {Official Google Blog},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\H8GP3PGG\\introducing-knowledge-graph-things-not.html:text/html}
}
@misc{singhal_introducing_2012-1,
title = {Introducing the {Knowledge} {Graph}: things, not strings},
shorttitle = {Introducing the {Knowledge} {Graph}},
url = {https://www.blog.google/products/search/introducing-knowledge-graph-things-not/},
abstract = {We hope this will give you a more complete picture of your interest, provide smarter search results, and pique your curiosity.},
language = {en},
urldate = {2018-04-19},
journal = {Google},
author = {Singhal, Amit},
month = may,
year = {2012},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\ST86AM5V\\introducing-knowledge-graph-things-not.html:text/html}
}
@misc{noauthor_icon_2018,
title = {{ICON} - {Hyperconnect} the {World}},
url = {https://icon.foundation/resources/whitepaper/ICON-Whitepaper-EN-Draft.pdf},
year = {2018}
}
@misc{noauthor_aelf_2017,
title = {aelf - {A} {Multi}-{Chain} {Parallel} {Computing} {Blockchain} {Framework}},
url = {https://grid.hoopox.com/aelf_whitepaper_EN.pdf},
year = {2017}
}
@misc{noauthor_pchain_nodate,
title = {{PCHAIN} - {The} first native multichain system that supports {EVM} in the world. {Making} large scale blockchain applications possible},
url = {https://pchain.org/},
urldate = {2018-04-19},
file = {pchain.org:C\:\\Users\\radu.chis\\Zotero\\storage\\SQHPCKTM\\pchain.org.html:text/html}
}
@misc{noauthor_pchain.org_nodate,
title = {pchain.org},
url = {https://pchain.org/},
urldate = {2018-04-19},
file = {pchain.org:C\:\\Users\\radu.chis\\Zotero\\storage\\B2RYLWW5\\pchain.org.html:text/html}
}
@misc{10,
title = {Ethereum: {A} {Secure} {Decentralised} {Generalised} {Transaction} {Ledger}},
url = {https://ethereum.github.io/yellowpaper/paper.pdf},
author = {Wood, Gavin},
year = {2017}
}
@phdthesis{noauthor_notitle_nodate
}
@misc{11,
title = {Solidity — {Solidity} 0.4.21 documentation},
url = {https://solidity.readthedocs.io/en/v0.4.21/},
urldate = {2018-04-19},
file = {Solidity — Solidity 0.4.21 documentation:C\:\\Users\\radu.chis\\Zotero\\storage\\X2ZWRCE8\\v0.4.html:text/html}
}
@misc{38,
title = {Cosmos {Network} - {Internet} of {Blockchains}},
url = {https://cosmos.network/whitepaper},
abstract = {The interoperable, scalable blockchain network. Built for developers.},
urldate = {2018-04-19},
journal = {Cosmos Network},
author = {Kwon, Jae and Buchman, Ethan},
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\EQJ4LL8R\\whitepaper.html:text/html}
}
@misc{noauthor_singularitynet:_2017,
title = {{SingularityNET}: {A} decentralized, open market and inter-network for {AIs}},
url = {https://public.singularitynet.io/whitepaper.pdf},
year = {2017}
}
@misc{12,
title = {web3j},
url = {https://github.com/web3j},
abstract = {JVM language projects for working with Blockchains},
language = {en},
urldate = {2018-04-19},
journal = {GitHub},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\U58C4K7B\\web3j.html:text/html}
}
@misc{2,
title = {The {Ethereum} {Wiki} - {Sharding} {FAQ}},
shorttitle = {wiki},
url = {https://github.com/ethereum/wiki/wiki/Sharding-FAQ},
urldate = {2018-04-19},
year = {2018},
note = {original-date: 2014-02-14T23:05:17Z}
}
@misc{50,
title = {The {Ethereum} {Wiki} - {Mining}},
shorttitle = {wiki},
url = {https://github.com/ethereum/wiki/wiki/Mininghttps://github.com/ethereum/wiki},
urldate = {2018-04-19},
year = {2018},
note = {original-date: 2014-02-14T23:05:17Z}
}
@inproceedings{luu_elastico_2016,
address = {New York, NY, USA},
series = {{CCS} '16},
title = {Elastico - {A} {Secure} {Sharding} {Protocol} {For} {Open} {Blockchains}},
isbn = {978-1-4503-4139-4},
url = {http://doi.acm.org/10.1145/2976749.2978389},
doi = {10.1145/2976749.2978389},
abstract = {Cryptocurrencies, such as Bitcoin and 250 similar alt-coins, embody at their core a blockchain protocol --- a mechanism for a distributed network of computational nodes to periodically agree on a set of new transactions. Designing a secure blockchain protocol relies on an open challenge in security, that of designing a highly-scalable agreement protocol open to manipulation by byzantine or arbitrarily malicious nodes. Bitcoin's blockchain agreement protocol exhibits security, but does not scale: it processes 3--7 transactions per second at present, irrespective of the available computation capacity at hand. In this paper, we propose a new distributed agreement protocol for permission-less blockchains called ELASTICO. ELASTICO scales transaction rates almost linearly with available computation for mining: the more the computation power in the network, the higher the number of transaction blocks selected per unit time. ELASTICO is efficient in its network messages and tolerates byzantine adversaries of up to one-fourth of the total computational power. Technically, ELASTICO uniformly partitions or parallelizes the mining network (securely) into smaller committees, each of which processes a disjoint set of transactions (or "shards"). While sharding is common in non-byzantine settings, ELASTICO is the first candidate for a secure sharding protocol with presence of byzantine adversaries. Our scalability experiments on Amazon EC2 with up to \$1, 600\$ nodes confirm ELASTICO's theoretical scaling properties.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 2016 {ACM} {SIGSAC} {Conference} on {Computer} and {Communications} {Security}},
publisher = {ACM},
author = {Luu, Loi and Narayanan, Viswesh and Zheng, Chaodong and Baweja, Kunal and Gilbert, Seth and Saxena, Prateek},
year = {2016},
keywords = {bitcoin, consensus protocol, sharding},
pages = {17--30}
}
@misc{52,
title = {Chainweb: {A} {Proof}-of-{Work} {Parallel}-{Chain} {Architecture} for {Massive} {Throughput}},
url = {http://kadena.io/docs/chainweb-v15.pd},
author = {Martino, Will and Quaintance, Monica and Popejoy, Stuart},
year = {2018}
}
@misc{noauthor_responsiveness_2018,
title = {Responsiveness},
copyright = {Creative Commons Attribution-ShareAlike License},
url = {https://en.wikipedia.org/w/index.php?title=Responsiveness&oldid=825775229},
abstract = {Responsiveness as a concept of computer science refers to the specific ability of a system or functional unit to complete assigned tasks within a given time. For example, it would refer to the ability of an artificial intelligence system to understand and carry out its tasks in a timely fashion. It is one of the criteria under the principle of robustness (from a v principle). The other three are observability, recoverability, and task conformance.},
language = {en},
urldate = {2018-04-19},
journal = {Wikipedia},
month = feb,
year = {2018},
note = {Page Version ID: 825775229},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\MEEZ27UC\\index.html:text/html}
}
@misc{51,
title = {Transaction throughput},
url = {https://docs.oracle.com/cd/E17276_01/html/programmer_reference/transapp_throughput.html},
urldate = {2018-04-19},
file = {Transaction throughput:C\:\\Users\\radu.chis\\Zotero\\storage\\7QXC2YJ4\\transapp_throughput.html:text/html}
}
@misc{noauthor_enterprise_2018,
title = {Enterprise {Ethereum} {Alliance}},
url = {https://entethalliance.org/},
abstract = {The Enterprise Ethereum Alliance connects Fortune 500 enterprises, startups, academics, and technology vendors with Ethereum subject matter experts.},
language = {en-US},
urldate = {2018-04-19},
journal = {Enterprise Ethereum Alliance},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\JSSPP5IQ\\entethalliance.org.html:text/html}
}
@misc{konstantopoulos_scalability_2018,
title = {Scalability {Tradeoffs}: {Why} “{The} {Ethereum} {Killer}” {Hasn}’t {Arrived} {Yet}},
shorttitle = {Scalability {Tradeoffs}},
url = {https://medium.com/loom-network/scalability-tradeoffs-why-the-ethereum-killer-hasnt-arrived-yet-8f60a88e46c0},
abstract = {Lately I’ve seen a lot of crypto-enthusiasts on Reddit and Telegram making comments like:},
urldate = {2018-04-19},
journal = {Medium},
author = {Konstantopoulos, Georgios},
month = jan,
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\2SHPK53N\\scalability-tradeoffs-why-the-ethereum-killer-hasnt-arrived-yet-8f60a88e46c0.html:text/html}
}
@misc{noauthor_scalability_2018,
title = {Scalability {Tradeoffs}: {Why} “{The} {Ethereum} {Killer}” {Hasn}’t {Arrived} {Yet}},
url = {https://medium.com/loom-network/scalability-tradeoffs-why-the-ethereum-killer-hasnt-arrived-yet-8f60a88e46c0},
urldate = {2018-04-19},
year = {2018},
file = {Scalability Tradeoffs\: Why “The Ethereum Killer” Hasn’t Arrived Yet:C\:\\Users\\radu.chis\\Zotero\\storage\\YIBC3558\\scalability-tradeoffs-why-the-ethereum-killer-hasnt-arrived-yet-8f60a88e46c0.html:text/html}
}
@misc{mcconaghy_dcs_2016,
title = {The {DCS} {Triangle}},
url = {https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc},
abstract = {Decentralized, Consistent, Scalable. Pick any two.},
urldate = {2018-04-19},
journal = {The BigchainDB Blog},
author = {McConaghy, Trent},
month = jul,
year = {2016},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\XWHKSJYH\\the-dcs-triangle-5ce0e9e0f1dc.html:text/html}
}
@techreport{1,
address = {Rochester, NY},
type = {{SSRN} {Scholarly} {Paper}},
title = {2017 {Global} {Cryptocurrency} {Benchmarking} {Study}},
url = {https://papers.ssrn.com/abstract=2965436},
abstract = {The first global cryptocurrency benchmarking study presents a systematic and comprehensive picture of a rapidly evolving industry, illustrating how cryptocurrencies are being used, stored, transacted and mined. The study gathered non-public data from more than 100 cryptocurrency companies and over 30 individual cryptocurrency miners in 38 countries around the world via secure web-based questionnaires, capturing an estimated 75 per cent of the cryptocurrency industry. The study breaks down the cryptocurrency industry into four key sectors – exchanges, wallets, payments and mining. Key findings and highlights from the study include our estimate that over three million unique individuals are actively using cryptocurrency today, data on regulation and compliance practices and costs at firms, and a global map of cryptocurrency mining.},
language = {en},
number = {ID 2965436},
urldate = {2018-04-19},
institution = {Social Science Research Network},
author = {Hileman, Garrick and Rauchs, Michel},
month = apr,
year = {2017},
keywords = {bitcoin, alternative currency, blockchain, cryptocurrency, currency, Dash, Ethereum, Litecoin, Monero, money, remittances, Ripple},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\7NEAPATM\\Hileman and Rauchs - 2017 - 2017 Global Cryptocurrency Benchmarking Study.pdf:application/pdf;Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\4IVKSZQB\\papers.html:text/html}
}
@misc{49,
title = {Crypto {Transaction} {Speeds} 2018 - {All} the {Major} {Cryptocurrencies}},
url = {https://www.abitgreedy.com/transaction-speed/},
abstract = {Are you concerned about transaction speeds? Do you want to find out which cryptocurrency is the fastest? Read this and you will learn everything about fast crypto transactions. Get some tips for speeding up your transactions, the difference of transaction speeds of various cryptocurrencies and more...},
language = {en},
urldate = {2018-04-19},
journal = {aBitGreedy},
author = {Schwarz, Mark},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\D6QLHS5V\\transaction-speed.html:text/html}
}
@misc{47,
title = {Visa - {Annual} {Report} 2017},
url = {https://s1.q4cdn.com/050606653/files/doc_financials/annual/2017/Visa-2017-Annual-Report.pdf},
urldate = {2018-04-19},
year = {2018}
}
@misc{48,
title = {{PayPal} {Reports} {Fourth} {Quarter} and {Full} {Year} 2017 {Results} ({NASDAQ}:{PYPL})},
url = {https://investor.paypal-corp.com/releasedetail.cfm?releaseid=1055924},
urldate = {2018-04-19},
year = {2018},
file = {PayPal Reports Fourth Quarter and Full Year 2017 Results (NASDAQ\:PYPL):C\:\\Users\\radu.chis\\Zotero\\storage\\HGSXZKBV\\releasedetail.html:text/html}
}
@misc{46,
title = {{XRP} - {The} {Digital} {Asset} for {Payments}},
url = {https://ripple.com/xrp/},
urldate = {2018-04-19},
file = {XRP | Ripple:C\:\\Users\\radu.chis\\Zotero\\storage\\92XNULW8\\xrp.html:text/html}
}
@techreport{45,
address = {Rochester, NY},
type = {{SSRN} {Scholarly} {Paper}},
title = {Financial {System} {Classification}: {From} {Conventional} {Dichotomy} to a {More} {Modern} {View}},
shorttitle = {Financial {System} {Classification}},
url = {https://papers.ssrn.com/abstract=2114842},
abstract = {This paper is to provide literature review on traditional financial system classification and offer and alternative classification of financial systems. Conventional wisdom holds that there are basically 2 types of financial systems – bank-based and market-based. But modern research points to the fact that such opinion may be quite biased. We consider several functions of financial system (not only financing, but corporate governance and information dissemination) and construct a database of financial metrics and institutional variables is order to conduct cluster-analysis. Our findings include: dichotomy does not hold; institutional environment is a key driver of financial system development; commodity exporters have inadequately low institutional development level.},
language = {en},
number = {ID 2114842},
urldate = {2018-04-19},
institution = {Social Science Research Network},
author = {Veysov, Alexander and Stolbov, Mikhail},
month = jul,
year = {2012},
keywords = {alternative classification, classification, cluster analysis, financial system},
file = {Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\CANTCKJT\\Veysov and Stolbov - 2012 - Financial System Classification From Conventional.pdf:application/pdf;Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\EXYNHEKE\\papers.html:text/html}
}
@misc{noauthor_rchain_2017,
title = {{RChain} {Platform} {Architecture} — {RChain} {Architecture} 0.9.0 documentation},
url = {http://rchain-architecture.readthedocs.io/en/latest/},
urldate = {2018-04-19},
year = {2017},
file = {RChain Platform Architecture — RChain Architecture 0.9.0 documentation:C\:\\Users\\radu.chis\\Zotero\\storage\\MG72PEBB\\latest.html:text/html}
}
@techreport{7,
title = {{OmniLedger}: {A} {Secure}, {Scale}-{Out}, {Decentralized} {Ledger} via {Sharding}},
shorttitle = {{OmniLedger}},
url = {https://eprint.iacr.org/2017/406},
abstract = {Designing a secure permissionless distributed ledger that performs on par with centralized payment processors such as Visa is challenging. Most existing distributed ledgers are unable to "scale-out'' -- growing total processing capacity with number of participants -- and those that do compromise security or decentralization. This work presents OmniLedger, the first scale-out distributed ledger that can preserve long-term security under permissionless operation. OmniLedger ensures strong correctness and security by using a bias-resistant public randomness protocol to choose large statistically representative shards to process transactions, and by introducing an efficient cross-shard commit protocol to handle transactions affecting multiple shards atomically. In addition, OmniLedger optimizes performance via scalable intra-shard parallel transaction processing, ledger pruning via collectively-signed state blocks, and optional low-latency "trust-but-verify'' validation of low-value transactions. Evaluation of our working experimental prototype shows that OmniLedger's throughput scales linearly in the number of validators available, supporting Visa-level workloads and beyond, while confirming typical transactions in under two seconds.},
number = {406},
urldate = {2018-04-19},
author = {Kokoris-Kogias, Eleftherios and Jovanovic, Philipp and Gasser, Linus and Gailly, Nicolas and Syta, Ewa and Ford, Bryan},
year = {2017},
keywords = {Blockchains, Decentralization, High throughput, Low latency, Scale-Out, Sharding, Trust-but-Verify},
file = {ePrint IACR Full Text PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\9NCTWLN3\\Kokoris-Kogias et al. - 2017 - OmniLedger A Secure, Scale-Out, Decentralized Led.pdf:application/pdf;ePrint IACR Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\RQ6DPLI8\\406.html:text/html}
}
@inproceedings{noauthor_omniledger:_nodate,
title = {{OmniLedger}: {A} {Secure}, {Scale}-{Out}, {Decentralized} {Ledger} via {Sharding}}
}
@misc{noauthor_notitle_nodate-1,
url = {https://cs-services.computer.org/csdl/citation/proceedings/ascii/sp/2018/4353/00/435301a019},
urldate = {2018-04-19},
file = {:C\:\\Users\\radu.chis\\Zotero\\storage\\8DIFAWD6\\435301a019.html:text/html}
}
@misc{noauthor_omniledger:_nodate-1,
title = {{OmniLedger}: {A} {Secure}, {Scale}-{Out}, {Decentralized} {Ledger} - {Semantic} {Scholar}},
shorttitle = {{OmniLedger}},
url = {/paper/OmniLedger%3A-A-Secure%2C-Scale-Out%2C-Decentralized-Kokoris-Kogias-Jovanovic/3ccd8850b72c35cfa727df2d617b93983871c2cb},
abstract = {Designing a secure and open Distributed Ledger (DL) system that performs on par with classic payment-service providers such as Visa is a challenging task. Current proposals either do not scale-out or do so only at the cost of security or decentralization. OmniLedger is a new scalable DL that provides secure, decentralized, horizontal scaling by splitting the state into multiple shards and using distributed randomness to assign validators securely. To maintain intraand cross-shard consistency validators run a novel parallel consensus algorithm for the former and an Atomic Commit protocol for the latter. To mitigate storage cost and enable fast, secure bootstrapping, OmniLedger introduces compact state-blocks that summarize shard-states. OmniLedger offers tunable performance based on the assumed strength of the adversaries, and scales linearly with the number of shards. Experiments show that it achieves Visa-level throughput of 6000 transactions per second (peaking at 50000) for 1800 validators, of which up to 12.5\% (5\%) are assumed to be malicious. Finally, OmniLedger significantly reduces bandwidth cost for out-of-date validators to update: for a one-month-old view, a validator downloads 40\% of the amount of data compared to Bitcoin, whereas a new validator downloads only 7\% while bootstrapping.},
urldate = {2018-04-19},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\IYRCA7LS\\3ccd8850b72c35cfa727df2d617b93983871c2cb.html:text/html}
}
@article{chen_algorand_2016,
title = {Algorand},
url = {http://arxiv.org/abs/1607.01341},
abstract = {A public ledger is a tamperproof sequence of data that can be read and augmented by everyone. Public ledgers have innumerable and compelling uses. They can secure, in plain sight, all kinds of transactions ---such as titles, sales, and payments--- in the exact order in which they occur. Public ledgers not only curb corruption, but also enable very sophisticated applications ---such as cryptocurrencies and smart contracts. They stand to revolutionize the way a democratic society operates. As currently implemented, however, they scale poorly and cannot achieve their potential. Algorand is a truly democratic and efficient way to implement a public ledger. Unlike prior implementations based on proof of work, it requires a negligible amount of computation, and generates a transaction history that will not "fork" with overwhelmingly high probability. Algorand is based on (a novel and super fast) message-passing Byzantine agreement. For concreteness, we shall describe Algorand only as a money platform.},
urldate = {2018-04-19},
journal = {arXiv:1607.01341 [cs]},
author = {Chen, Jing and Micali, Silvio},
month = jul,
year = {2016},
note = {arXiv: 1607.01341},
keywords = {Computer Science - Cryptography and Security, Computer Science - Distributed, Parallel, and Cluster Computing},
file = {arXiv\:1607.01341 PDF:C\:\\Users\\radu.chis\\Zotero\\storage\\HHDUSHIL\\Chen and Micali - 2016 - Algorand.pdf:application/pdf;arXiv.org Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\BXDH9SBW\\1607.html:text/html}
}
@misc{8,
title = {The {ZILLIQA} {Technical} {Whitepaper}},
url = {https://docs.zilliqa.com/whitepaper.pdf},
abstract = {Zilliqa - The Next Generation, High Throughput Blockchain Platform},
language = {en},
urldate = {2018-04-19},
journal = {ZILLIQA},
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\CY9PFFJM\\www.zilliqa.com.html:text/html}
}
@inproceedings{kiayias_ouroboros:_2017,
series = {Lecture {Notes} in {Computer} {Science}},
title = {Ouroboros: {A} {Provably} {Secure} {Proof}-of-{Stake} {Blockchain} {Protocol}},
isbn = {978-3-319-63687-0 978-3-319-63688-7},
shorttitle = {Ouroboros},
url = {https://link.springer.com/chapter/10.1007/978-3-319-63688-7_12},
doi = {10.1007/978-3-319-63688-7_12},
abstract = {We present “Ouroboros”, the first blockchain protocol based on proof of stake with rigorous security guarantees. We establish security properties for the protocol comparable to those achieved by the bitcoin blockchain protocol. As the protocol provides a “proof of stake” blockchain discipline, it offers qualitative efficiency advantages over blockchains based on proof of physical resources (e.g., proof of work). We also present a novel reward mechanism for incentivizing Proof of Stake protocols and we prove that, given this mechanism, honest behavior is an approximate Nash equilibrium, thus neutralizing attacks such as selfish mining.},
language = {en},
urldate = {2018-04-19},
booktitle = {Advances in {Cryptology} – {CRYPTO} 2017},
publisher = {Springer, Cham},
author = {Kiayias, Aggelos and Russell, Alexander and David, Bernardo and Oliynykov, Roman},
month = aug,
year = {2017},
pages = {357--388},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\IZE9EBAV\\978-3-319-63688-7_12.html:text/html}
}
@misc{cobinhood_vitalik_2017,
title = {Vitalik {Unveils} {Ethereum} 2.0 {Roadmap}},
url = {https://medium.com/cobinhood/vitalik-unveils-ethereum-2-0-roadmap-conference-notes-505270a48674},
abstract = {How Ethereum plans to address current problems in the protocol},
urldate = {2018-04-19},
journal = {COBINHOOD},
author = {COBINHOOD},
month = nov,
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\IC3D796J\\vitalik-unveils-ethereum-2-0-roadmap-conference-notes-505270a48674.html:text/html}
}
@misc{14,
title = {The {State} of {Ethereum} {Scaling}, {March} 2018 – {Highlights} from {EthCC} on {Plasma} {Cash}, {Minimum} {Viable} {Plasma}, and {More}… – {Medium}},
url = {https://medium.com/loom-network/the-state-of-ethereum-scaling-march-2018-74ac08198a36},
urldate = {2018-04-19},
year = {2018},
file = {The State of Ethereum Scaling, March 2018 – Loom Network – Medium:C\:\\Users\\radu.chis\\Zotero\\storage\\7EMBLXKB\\the-state-of-ethereum-scaling-march-2018-74ac08198a36.html:text/html}
}
@misc{13,
title = {Casper},
url = {http://ethresear.ch/c/casper},
abstract = {Discussion related to Casper. See also:},
language = {en},
urldate = {2018-04-19},
journal = {Ethereum Research},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\TVKGQQK4\\casper.html:text/html}
}
@misc{noauthor_ethereum_2018-4,
title = {Ethereum {Mining} {Pools} {Impact} {\textbar} {Investoon}},
url = {https://investoon.com/charts/mining/eth},
urldate = {2018-04-19},
year = {2018},
file = {Ethereum Mining Pools Impact | Investoon:C\:\\Users\\radu.chis\\Zotero\\storage\\TRJHT6YY\\eth.html:text/html}
}
@misc{noauthor_bitcoin_2018-1,
title = {Bitcoin {Energy} {Consumption} {Index} - {Digiconomist}},
url = {https://digiconomist.net/bitcoin-energy-consumption},
urldate = {2018-04-19},
year = {2018},
file = {Bitcoin Energy Consumption Index - Digiconomist:C\:\\Users\\radu.chis\\Zotero\\storage\\CCBAXNA8\\bitcoin-energy-consumption.html:text/html}
}
@misc{noauthor_how_2018,
title = {How {Will} {Ethereum} {Scale}? - {CoinDesk}},
url = {https://www.coindesk.com/information/will-ethereum-scale/},
urldate = {2018-04-19},
year = {2018},
file = {How Will Ethereum Scale? - CoinDesk:C\:\\Users\\radu.chis\\Zotero\\storage\\MAIWEU9J\\will-ethereum-scale.html:text/html}
}
@misc{noauthor_ethereum_2018-5,
title = {Ethereum {Transaction} {Growth} {Chart}},
url = {https://etherscan.io/chart/tx},
urldate = {2018-04-19},
year = {2018},
file = {Ethereum Transaction Growth Chart:C\:\\Users\\radu.chis\\Zotero\\storage\\NGXLVE65\\tx.html:text/html}
}
@misc{noauthor_ethereum_nodate,
title = {Ethereum {Transaction} {Growth} {Chart}},
url = {https://etherscan.io/chart/tx},
urldate = {2018-04-19},
file = {Ethereum Transaction Growth Chart:C\:\\Users\\radu.chis\\Zotero\\storage\\Y2NYM67T\\tx.html:text/html}
}
@misc{6,
title = {Ethereum: {A} {Next}-{Generation} {Smart} {Contract} and {Decentralized} {Application} {Platform}},
url = {https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf},
author = {Buterin, Vitalik},
year = {2013}
}
@misc{huynh_beginners_2017,
title = {Beginner’s {Guide} to {Bitcoin}’s {Scalability} {Debate}},
url = {https://hackernoon.com/beginners-guide-to-bitcoin-s-scalability-debate-66060f3799e5},
abstract = {By Kevin Huynh and Steven Chen},
urldate = {2018-04-19},
journal = {Hacker Noon},
author = {Huynh, Kevin},
month = aug,
year = {2017},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\SXX749JR\\beginners-guide-to-bitcoin-s-scalability-debate-66060f3799e5.html:text/html}
}
@inproceedings{sheehan_does_2017,
address = {New York, NY, USA},
series = {{OpenSym} '17},
title = {Does {Miner} {Pooling} {Impact} {Bitcoin}'s {Ability} to {Stay} {Decentralized}?},
isbn = {978-1-4503-5187-4},
url = {http://doi.acm.org/10.1145/3125433.3125462},
doi = {10.1145/3125433.3125462},
abstract = {The Emerging Blockchain technologies have earned substantial attention in the area of Financial Technology in recent years. Its decentralized environment allows for the mining of Bitcoins by miners either independently or in groups. The community of miners have faith in the integrity of each other to sustain the network, through mining pools remaining at a reasonable level of mining power. Blockchain's decentralized system is one of its main selling points and is a source of great attraction for users. However, when these mining pools start to grow and increase their mining power to dangerous levels it can result in a shift towards a centralized environment. This push goes against foundational principles of Bitcoin, leading to ongoing debate among various stakeholders.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 13th {International} {Symposium} on {Open} {Collaboration}},
publisher = {ACM},
author = {Sheehan, David and Gleasure, Rob and Feller, Joe and O'Reilly, Phillip and Li, Shanping and Cristiforo, Jerry},
year = {2017},
keywords = {Bitcoin, Blockchain, decentralization, mining, mining pools},
pages = {25:1--25:4}
}
@inproceedings{gervais_security_2016,
address = {New York, NY, USA},
series = {{CCS} '16},
title = {On the {Security} and {Performance} of {Proof} of {Work} {Blockchains}},
isbn = {978-1-4503-4139-4},
url = {http://doi.acm.org/10.1145/2976749.2978341},
doi = {10.1145/2976749.2978341},
abstract = {Proof of Work (PoW) powered blockchains currently account for more than 90\% of the total market capitalization of existing digital cryptocurrencies. Although the security provisions of Bitcoin have been thoroughly analysed, the security guarantees of variant (forked) PoW blockchains (which were instantiated with different parameters) have not received much attention in the literature. This opens the question whether existing security analysis of Bitcoin's PoW applies to other implementations which have been instantiated with different consensus and/or network parameters. In this paper, we introduce a novel quantitative framework to analyse the security and performance implications of various consensus and network parameters of PoW blockchains. Based on our framework, we devise optimal adversarial strategies for double-spending and selfish mining while taking into account real world constraints such as network propagation, different block sizes, block generation intervals, information propagation mechanism, and the impact of eclipse attacks. Our framework therefore allows us to capture existing PoW-based deployments as well as PoW blockchain variants that are instantiated with different parameters, and to objectively compare the tradeoffs between their performance and security provisions.},
urldate = {2018-04-19},
booktitle = {Proceedings of the 2016 {ACM} {SIGSAC} {Conference} on {Computer} and {Communications} {Security}},
publisher = {ACM},
author = {Gervais, Arthur and Karame, Ghassan O. and Wüst, Karl and Glykantzis, Vasileios and Ritzdorf, Hubert and Capkun, Srdjan},
year = {2016},
keywords = {bitcoin, blockchain, performance, security},
pages = {3--16}
}
@misc{noauthor_hashrate_2018,
title = {Hashrate {Distribution}},
url = {https://blockchain.info/pools},
abstract = {A pie chart showing the hashrate distribution between the major bitcoin mining pools},
urldate = {2018-04-19},
journal = {Blockchain.info},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\AC4435E8\\pools.html:text/html}
}
@misc{noauthor_difficulty_2018,
title = {Difficulty},
url = {https://blockchain.info/difficulty},
abstract = {A relative measure of how difficult it is to find a new block. The difficulty is adjusted periodically as a function of how much hashing power has been deployed by the network of miners.},
urldate = {2018-04-19},
journal = {Blockchain.info},
year = {2018},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\H594HI4B\\difficulty.html:text/html}
}
@phdthesis{malik_history_2016,
address = {Prague},
title = {The history and the future of {Bitcoin}},
url = {https://is.bivs.cz/th/21358/bivs_b/The_future_and_the_history_of_Bitcoin.pdf},
school = {Banking Institute},
author = {Malik, Vladimir},
year = {2016}
}
@article{18,
title = {Bitcoin: {A} {Peer}-to-{Peer} {Electronic} {Cash} {System}},
abstract = {A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.},
language = {en},
author = {Nakamoto, Satoshi},
year = {2008},
pages = {9},
file = {Nakamoto - Bitcoin A Peer-to-Peer Electronic Cash System.pdf:C\:\\Users\\radu.chis\\Zotero\\storage\\9S7IQ7N9\\Nakamoto - Bitcoin A Peer-to-Peer Electronic Cash System.pdf:application/pdf}
}
@misc{dai_dai/nakamoto_2008,
title = {Dai/{Nakamoto} emails - {Gwern}.net},
url = {https://www.gwern.net/docs/bitcoin/2008-nakamoto},
abstract = {Emails in 2009 between Wei Dai and Satoshi Nakamoto discussing Bitcoin draft proposal and B-money},
language = {en},
urldate = {2018-04-19},
author = {Dai, Wei, Satoshi Nakamoto},
year = {2008},
file = {Snapshot:C\:\\Users\\radu.chis\\Zotero\\storage\\GTBFVKVX\\2008-nakamoto.html:text/html}