-
Notifications
You must be signed in to change notification settings - Fork 1
/
bitcoin-2008.html
1031 lines (1017 loc) · 52.8 KB
/
bitcoin-2008.html
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
<!DOCTYPE html>
<html lang="en-US">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="author" content="Nathan Farrington" />
<meta name="copyright" content="Nathan Farrington" />
<meta name="description" content="A review of the 2008 paper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto.
" />
<meta property="og:type" content="article" />
<meta name="twitter:card" content="summary">
<meta name="keywords" content="bitcoin, paper reviews, " />
<meta property="og:title" content="Bitcoin (2008) "/>
<meta property="og:url" content="./bitcoin-2008.html" />
<meta property="og:description" content="A review of the 2008 paper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto." />
<meta property="og:site_name" content="Nathan Farrington" />
<meta property="og:article:author" content="Nathan Farrington" />
<meta property="og:article:published_time" content="2017-07-17T06:00:00-07:00" />
<meta name="twitter:title" content="Bitcoin (2008) ">
<meta name="twitter:description" content="A review of the 2008 paper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” by Satoshi Nakamoto.">
<title>Bitcoin (2008) · Nathan Farrington
</title>
<link href="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/css/bootstrap-combined.min.css" rel="stylesheet">
<link href="//netdna.bootstrapcdn.com/font-awesome/4.0.1/css/font-awesome.css" rel="stylesheet">
<link rel="stylesheet" type="text/css" href="./theme/css/pygments.css" media="screen">
<link rel="stylesheet" type="text/css" href="./theme/css/math.css" media="screen">
<link rel="stylesheet" type="text/css" href="./theme/tipuesearch/tipuesearch.css" media="screen">
<link rel="stylesheet" type="text/css" href="./theme/css/elegant.css" media="screen">
<link rel="stylesheet" type="text/css" href="./theme/css/custom.css" media="screen">
<link rel="shortcut icon" href="./images/favicon.ico" type="image/x-icon" type="image/png" />
<link rel="icon" href="./images/apple-touch-icon-152x152.png" type="image/png" />
<link rel="apple-touch-icon" href="./images/apple-touch-icon.png" type="image/png" />
<link rel="apple-touch-icon" sizes="57x57" href="./images/apple-touch-icon-57x57.png" type="image/png" />
<link rel="apple-touch-icon" sizes="72x72" href="./images/apple-touch-icon-72x72.png" type="image/png" />
<link rel="apple-touch-icon" sizes="76x76" href="./images/apple-touch-icon-76x76.png" type="image/png" />
<link rel="apple-touch-icon" sizes="114x114" href="./images/apple-touch-icon-114x114.png" type="image/png" />
<link rel="apple-touch-icon" sizes="120x120" href="./images/apple-touch-icon-120x120.png" type="image/png" />
<link rel="apple-touch-icon" sizes="144x144" href="./images/apple-touch-icon-144x144.png" type="image/png" />
<link rel="apple-touch-icon" sizes="152x152" href="./images/apple-touch-icon-152x152.png" type="image/png" />
<link rel="apple-touch-icon-precomposed" sizes="57x57" href="./images/apple-touch-icon-57x57.png" />
<link rel="apple-touch-icon-precomposed" sizes="60x60" href="./images/apple-touch-icon-60x60.png" />
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="./images/apple-touch-icon-72x72.png" />
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="./images/apple-touch-icon-76x76.png" />
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="./images/apple-touch-icon-114x114.png" />
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="./images/apple-touch-icon-120x120.png" />
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="./images/apple-touch-icon-144x144.png" />
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="./images/apple-touch-icon-152x152.png" />
<link rel="icon" type="image/png" href="./images/favicon-16x16.png" sizes="16x16" />
<link rel="icon" type="image/png" href="./images/favicon-32x32.png" sizes="32x32" />
<link rel="icon" type="image/png" href="./images/favicon-96x96.png" sizes="96x96" />
<link rel="icon" type="image/png" href="./images/favicon-128.png" sizes="128x128" />
<link rel="icon" type="image/png" href="./images/favicon-196x196.png" sizes="196x196" />
<meta name="application-name" content="Nathan Farrington"/>
<meta name="msapplication-TileColor" content="#FFFFFF" />
<meta name="msapplication-TileImage" content="./images/mstile-144x144.png" />
<meta name="msapplication-square70x70logo" content="./images/mstile-70x70.png" />
<meta name="msapplication-square150x150logo" content="./images/mstile-150x150.png" />
<meta name="msapplication-wide310x150logo" content="./images/mstile-310x150.png" />
<meta name="msapplication-square310x310logo" content="./images/mstile-310x310.png" />
</head>
<body>
<div id="content-sans-footer">
<div class="navbar navbar-static-top">
<div class="navbar-inner">
<div class="container-fluid">
<a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</a>
<a class="brand" href="./"><span class=site-name>Nathan Farrington</span></a>
<div class="nav-collapse collapse">
<ul class="nav pull-right top-menu">
<li ><a href=".">Home</a></li>
<li ><a href="./papers.html">Papers</a></li>
<li ><a href="./patents.html">Patents</a></li>
<li ><a href="./categories.html">Categories</a></li>
<li ><a href="./tags.html">Tags</a></li>
<li ><a href="./archives.html">Archives</a></li>
<li><form class="navbar-search" action="./search.html" onsubmit="return validateForm(this.elements['q'].value);"> <input type="text" class="search-query" placeholder="Search" name="q" id="tipue_search_input"></form></li>
</ul>
</div>
</div>
</div>
</div>
<div class="container-fluid">
<div class="row-fluid">
<div class="span1"></div>
<div class="span10">
<article>
<div class="row-fluid">
<header class="page-header span10 offset2">
<h1><a href="./bitcoin-2008.html"> Bitcoin (2008) </a></h1>
</header>
</div>
<div class="row-fluid">
<div class="span2 table-of-content">
<nav>
<h4>Contents</h4>
<div class="toc" id="">
<ul class="simple">
<li><a class="reference internal" href="#abstract" id="id7">Abstract</a></li>
<li><a class="reference internal" href="#commentary" id="id8">Commentary</a></li>
<li><a class="reference internal" href="#review" id="id9">Review</a><ul>
<li><a class="reference internal" href="#the-people-problem" id="id10">The People Problem</a></li>
<li><a class="reference internal" href="#the-technical-problem" id="id11">The Technical Problem</a><ul>
<li><a class="reference internal" href="#technical-problem-1-transferring-physical-money" id="id12">Technical Problem #1: Transferring Physical Money</a></li>
<li><a class="reference internal" href="#technical-problem-2-detecting-double-spending-in-digital-money" id="id13">Technical Problem #2: Detecting Double Spending in Digital Money</a></li>
</ul>
</li>
<li><a class="reference internal" href="#proposed-solution" id="id14">Proposed Solution</a><ul>
<li><a class="reference internal" href="#timestamp-server" id="id15">Timestamp Server</a></li>
<li><a class="reference internal" href="#proof-of-work" id="id16">Proof-of-Work</a></li>
<li><a class="reference internal" href="#distributed-timestamp-service" id="id17">Distributed Timestamp Service</a></li>
<li><a class="reference internal" href="#network" id="id18">Network</a></li>
<li><a class="reference internal" href="#incentive" id="id19">Incentive</a></li>
<li><a class="reference internal" href="#reclaiming-disk-space" id="id20">Reclaiming Disk Space</a></li>
<li><a class="reference internal" href="#simplified-payment-verification" id="id21">Simplified Payment Verification</a></li>
<li><a class="reference internal" href="#combining-and-splitting-value" id="id22">Combining and Splitting Value</a></li>
</ul>
</li>
<li><a class="reference internal" href="#author-s-evaluation-of-the-proposed-solution" id="id23">Author’s Evaluation of the Proposed Solution</a></li>
<li><a class="reference internal" href="#my-analysis-of-the-problems-proposed-solution-and-evaluation" id="id24">My Analysis of the Problems, Proposed Solution, and Evaluation</a></li>
<li><a class="reference internal" href="#contributions" id="id25">Contributions</a></li>
<li><a class="reference internal" href="#future-directions" id="id26">Future Directions</a></li>
<li><a class="reference internal" href="#lingering-questions" id="id27">Lingering Questions</a></li>
<li><a class="reference internal" href="#take-away-message" id="id28">Take-Away Message</a></li>
</ul>
</li>
<li><a class="reference internal" href="#references" id="id29">References</a></li>
</ul>
</div>
</nav>
</div>
<div class="span8 article-content">
<div class="section" id="abstract">
<h2><a class="toc-backref" href="#id7">Abstract</a></h2>
<p>In this article,
I review the original 2008 Bitcoin paper
by Satoshi Nakamoto <a class="footnote-reference" href="#id4" id="id1">[1]</a>.
Jake Lerner from <span class="caps">UC</span> Berkeley
has also published a review <a class="footnote-reference" href="#id5" id="id2">[2]</a>.</p>
</div>
<div class="section" id="commentary">
<h2><a class="toc-backref" href="#id8">Commentary</a></h2>
<p>Bitcoin has recently been in the news
because its price reached
an all-time high of about 3,000 <span class="caps">USD</span> per coin.
This was up from a 1-year low
of about 570 <span class="caps">USD</span> per coin.</p>
<img alt="Coinbase chart showing the 1-year price of Bitcoin in USD." src="./images/bitcoin-2008_coinbase.png"/>
<p>Google Trends shows that
the search term “bitcoin”
also reached an all-time high,
coinciding with the peak price.</p>
<img alt='Google trends showing the recent popularity of the search term "bitcoin".' src="./images/bitcoin-2008_google-trends.png"/>
<p>What is Bitcoin?
Is it the digital equivalent of gold?
According to <a class="reference external" href="https://bitcoin.org/en/">bitcoin.org</a>:</p>
<blockquote>
Bitcoin is an innovative payment network and a new kind of money.</blockquote>
<p>So from this one-line definition,
it would appear that the folks at bitcoin.org
do in fact believe that Bitcoin is money.
Is it commodity money?
Fiat money?
Or perhaps it is a new form of money?
What about the <em>innovative payment network</em>
and how does that fit in?</p>
<p>Let’s crack open
the 2008 Bitcoin paper
and see how Nakamoto
originally presented Bitcoin
to the world!</p>
</div>
<div class="section" id="review">
<h2><a class="toc-backref" href="#id9">Review</a></h2>
<div class="section" id="the-people-problem">
<h3><a class="toc-backref" href="#id10">The People Problem</a></h3>
<p>Nakamoto jumps right into the people problem:
eCommerce currently requires
both the buyer and the seller
to <em>trust</em> some 3rd-party
to process the electronic payment.
Nakamoto argues that the involvement
of a trusted 3rd-party
leads to the following problems or limitations:</p>
<ul class="simple">
<li>seller is impacted because non-reversible transactions are not possible</li>
<li>both buyer and seller are impacted because transaction costs are higher</li>
<li>both buyer and seller are impacted because microtransactions are impractical</li>
<li>buyer is impacted because seller requires more information about buyer than necessary</li>
<li>seller is impacted because buyer fraud exists (reversing a transaction?)</li>
</ul>
<p>In addition to this list of problems and limitations,
I would also add the following:</p>
<ul class="simple">
<li>both buyer and seller are impacted because trusted 3rd-party requires more information about buyer and seller than necessary</li>
</ul>
<p>While I do agree that these are real problems,
I would argue that the world has done quite well
with this model so far.
Sellers would prefer to have non-reversible transactions,
but due to competition,
sellers would often wish to accept reversible forms of payment,
such as credit cards.
Transaction costs are not fun,
but they are also not exorbitant.
Compared with government taxes,
transaction costs are almost negligible.
It is true that microtransactions
have yet to materialize
in this model.
However,
it is possible to buy inexpensive items
such as an iTunes song for 0.99 <span class="caps">USD</span>.
From my observations,
buyers and sellers are actually not concerned
with disclosing information about themselves.
And finally,
fraud has not shutdown credit card companies,
online auction sites such as eBay,
or major online merchants such as Amazon.com.</p>
<p>But let’s keep reading,
because even though the problems
that Nakamoto identified
may not be pressing,
the existence of something like Bitcoin
could open up new opportunities to create
value for many people.</p>
</div>
<div class="section" id="the-technical-problem">
<h3><a class="toc-backref" href="#id11">The Technical Problem</a></h3>
<div class="section" id="technical-problem-1-transferring-physical-money">
<h4><a class="toc-backref" href="#id12">Technical Problem #1: Transferring Physical Money</a></h4>
<p>Removing the trusted 3rd-party
would seem to require a world
where the buyer could transfer
physical money to the seller.
But this is often impractical.
First,
for small amounts of money,
the fixed shipping costs could be
impractical.
A current <span class="caps">US</span> postage stamp
is 0.49 <span class="caps">USD</span>,
which is about 50%
of the cost of a 0.99 <span class="caps">USD</span> iTunes song.
Second,
the time taken for payment
to reach the seller
is often on the order of
the time taken for the seller’s
product to reach the buyer.
This means that if the seller
were to wait until receiving payment,
it would effectively double the total
transaction time.
This problem could be fixed by having
both the buyer and the seller
ship simultaneously,
but that exposes the seller
to the risk of buyer fraud.
Third,
sending actual physical money
exposes the buyer to both the risk of theft in transit
and the risk of seller fraud.
The risk of theft in transit
can be reduced by introducing another
trusted 3rd-party,
in this case <span class="caps">USPS</span>,
by converting the buyer’s money into a <span class="caps">USPS</span> money order.
The risk of seller fraud can be reduced
by choosing buyer-vetted sellers,
which increases prices by reducing competition,
and by limiting the maximum purchase
to an amount that the buyer can afford to lose,
which increases prices by incurring opportunity costs.</p>
<p>From the previous paragraph,
most may conclude that it is simply
faster and safer to utilize
trusted 3rd-parties for eCommerce.</p>
</div>
<div class="section" id="technical-problem-2-detecting-double-spending-in-digital-money">
<h4><a class="toc-backref" href="#id13">Technical Problem #2: Detecting Double Spending in Digital Money</a></h4>
<p>The first technical problem
focused on a buyer
transferring <em>physical money</em>
directly to a seller.
The second technical problem
focuses on a buyer
transferring <em>digital money</em>
directly to a seller.
What would this digital money look like
and why doesn’t it exist today (in 2008)?</p>
<p>It is possible to create
a <em>digital coin</em> (also called a digital token)
by using public key cryptography.
Here is the definition of a coin,
as expressed in Python,
using the description from the paper.</p>
<pre class="code python3 literal-block">
<span class="ln"> 1 </span><span class="k">class</span> <span class="nc">Coin</span><span class="p">:</span>
<span class="ln"> 2 </span> <span class="sd">"""Example of a digital coin, as described in the paper.
</span><span class="ln"> 3 </span><span class="sd">
</span><span class="ln"> 4 </span><span class="sd"> NOTE: This is my own interpretation of the paper and most likely does
</span><span class="ln"> 5 </span><span class="sd"> not correspond with Bitcoin or any other actual cryptocurrency.
</span><span class="ln"> 6 </span><span class="sd"> """</span>
<span class="ln"> 7 </span> <span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">first_owner_pubkey</span><span class="p">,</span> <span class="n">first_owner_privkey</span><span class="p">):</span>
<span class="ln"> 8 </span> <span class="sd">"""Create a new coin, using the public and private keys of the
</span><span class="ln"> 9 </span><span class="sd"> original owner."""</span>
<span class="ln">10 </span> <span class="bp">self</span><span class="o">.</span><span class="n">transactions</span> <span class="o">=</span> <span class="p">[{</span>
<span class="ln">11 </span> <span class="s1">'owner_pubkey'</span><span class="p">:</span> <span class="n">first_owner_pubkey</span>
<span class="ln">12 </span> <span class="s1">'signature'</span><span class="p">:</span> <span class="n">first_owner_privkey</span><span class="o">.</span><span class="n">sign</span><span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">first_owner_pubkey</span><span class="p">))</span>
<span class="ln">13 </span> <span class="p">}]</span>
<span class="ln">14 </span> <span class="k">def</span> <span class="nf">transfer</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">new_owner_pubkey</span><span class="p">,</span> <span class="n">current_owner_privkey</span><span class="p">):</span>
<span class="ln">15 </span> <span class="sd">"""Transfer this coin to a new owner."""</span>
<span class="ln">16 </span> <span class="n">prev_transaction</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">transactions</span><span class="p">[</span><span class="o">-</span><span class="mi">1</span><span class="p">]</span>
<span class="ln">17 </span> <span class="bp">self</span><span class="o">.</span><span class="n">transactions</span><span class="o">.</span><span class="n">append</span><span class="p">({</span>
<span class="ln">18 </span> <span class="s1">'owner_pubkey'</span><span class="p">:</span> <span class="n">new_owner_pubkey</span>
<span class="ln">19 </span> <span class="s1">'signature'</span><span class="p">:</span> <span class="n">current_owner_privkey</span><span class="o">.</span><span class="n">sign</span><span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">prev_transaction</span> <span class="o">+</span> <span class="n">prev_transaction</span><span class="o">.</span><span class="n">owner_pubkey</span><span class="p">))</span>
<span class="ln">20 </span> <span class="p">})</span>
<span class="ln">21 </span> <span class="k">def</span> <span class="nf">verify</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="ln">22 </span> <span class="sd">"""Verify that this coin has a valid chain of ownership."""</span>
<span class="ln">23 </span> <span class="n">prev_transaction</span> <span class="o">=</span> <span class="kc">None</span>
<span class="ln">24 </span> <span class="k">for</span> <span class="n">transaction</span> <span class="ow">in</span> <span class="bp">self</span><span class="o">.</span><span class="n">transactions</span><span class="p">:</span>
<span class="ln">25 </span> <span class="k">if</span> <span class="n">prev_transaction</span> <span class="ow">is</span> <span class="kc">None</span><span class="p">:</span>
<span class="ln">26 </span> <span class="n">prev_transaction</span> <span class="o">=</span> <span class="n">transaction</span>
<span class="ln">27 </span> <span class="k">continue</span>
<span class="ln">28 </span> <span class="n">prev_transaction</span><span class="o">.</span><span class="n">owner_pubkey</span><span class="o">.</span><span class="n">verify</span><span class="p">(</span><span class="n">transaction</span><span class="o">.</span><span class="n">signature</span><span class="p">)</span>
<span class="ln">29 </span> <span class="n">prev_transaction</span> <span class="o">=</span> <span class="n">transaction</span>
</pre>
<p>A coin is a list of transactions,
where each transaction
represents the transfer of ownership
of the coin
to a new owner.
Nakamoto uses the term <em>transaction</em>,
but in this context,
it may be better to use
a term such as <em>transference</em>.
Anyone can verify that the coin
was transferred properly
by walking the list of transactions
from beginning to end,
and verifying the signature stored in each transaction
using the public key stored in the previous transaction.</p>
<p>With this definition
of a coin
firmly established,
Nakamoto explains
the technical problem
of <em>double spending</em>.
Double spending occurs
when an owner, Oscar,
makes a copy of his coin,
and transfers copy “A” to Alice
and copy “B” to Bob
(without telling Alice about Bob’s coin
and without telling Bob about Alice’s coin).
In order to prevent chaos,
it is imperative that
if double spending occurs,
that it is at least detected.
But the only way to ensure
that double spending is detected
is to observe all transactions
across all coins in the economy.
Nakamoto mentions that previous solutions
have proposed a trusted 3rd-party
to be the one
to observe and sanction all transactions.
But this proposed solution
does not solve the original problem
of seeking to avoid the use of trusted 3rd-parties.</p>
</div>
</div>
<div class="section" id="proposed-solution">
<h3><a class="toc-backref" href="#id14">Proposed Solution</a></h3>
<p>The proposed solution
to the problem of double spending
is really the main contribution
of this paper.
In a nutshell,
Nakamoto proposes holding all currency,
and the transactions
that record transfers of currency,
in a public database
called a <em>distributed timestamp service</em>.
This new system
solves the problem
of double spending
by making all transactions public.
For example,
Bob (and everyone) can see that
Oscar “double spent” his coin
because he previously transferred
his coin to Alice.
With such a
distributed timestamp service available,
Nakamoto notes</p>
<blockquote>
For our purposes, the earliest transaction is the one that counts,
so we don’t care about later attempts to double-spend.</blockquote>
<p>The remainder of this section
presents the proposed solution
by following the paper outline.</p>
<div class="section" id="timestamp-server">
<h4><a class="toc-backref" href="#id15">Timestamp Server</a></h4>
<p>First,
Nakamoto defines
a traditional timestamp service
that takes a block of data as input
and produces a timestamp as output.
The timestamp proves that
the block of data
<em>existed prior</em> to the creation
of the timestamp,
but does not say
<em>when</em> the block of data
was actually created
(in terms of real human time).
In fact,
the “timestamp” itself
is the output
of a hash function
and does not correspond
to real human time.
But the timestamp
can be associated
with real human time
by publishing the timestamp.
Here is the definition
of a timestamping service,
as expressed in Python,
using the description from the paper.</p>
<pre class="code python3 literal-block">
<span class="ln"> 1 </span><span class="k">class</span> <span class="nc">TimestampService</span><span class="p">:</span>
<span class="ln"> 2 </span> <span class="sd">"""Example of a timestamp service, as described in the paper.
</span><span class="ln"> 3 </span><span class="sd">
</span><span class="ln"> 4 </span><span class="sd"> NOTE: This is my own implementation of a timestamp service and most
</span><span class="ln"> 5 </span><span class="sd"> likely does not correspond with any actual timestamp service.
</span><span class="ln"> 6 </span><span class="sd"> """</span>
<span class="ln"> 7 </span> <span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="ln"> 8 </span> <span class="sd">"""Create a new (empty) timestamp service."""</span>
<span class="ln"> 9 </span> <span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span> <span class="o">=</span> <span class="p">[]</span>
<span class="ln">10 </span> <span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span> <span class="o">=</span> <span class="p">[]</span>
<span class="ln">11 </span> <span class="k">def</span> <span class="nf">add_block</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">block</span><span class="p">):</span>
<span class="ln">12 </span> <span class="sd">"""Add a new block to the blockchain."""</span>
<span class="ln">13 </span> <span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">block</span><span class="p">)</span>
<span class="ln">14 </span> <span class="k">if</span> <span class="nb">len</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="p">)</span> <span class="o">==</span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">15 </span> <span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">block</span><span class="p">))</span>
<span class="ln">16 </span> <span class="k">else</span><span class="p">:</span>
<span class="ln">17 </span> <span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="p">[</span><span class="o">-</span><span class="mi">1</span><span class="p">]</span> <span class="o">+</span> <span class="nb">hash</span><span class="p">(</span><span class="n">block</span><span class="p">))</span>
<span class="ln">18 </span> <span class="k">def</span> <span class="nf">get_timestamp</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="ln">19 </span> <span class="sd">"""Return the most recent hash from the hashchain."""</span>
<span class="ln">20 </span> <span class="k">if</span> <span class="nb">len</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="p">)</span> <span class="o">==</span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">21 </span> <span class="k">return</span> <span class="kc">None</span>
<span class="ln">22 </span> <span class="k">return</span> <span class="bp">self</span><span class="o">.</span><span class="n">hashchain</span><span class="p">[</span><span class="o">-</span><span class="mi">1</span><span class="p">]</span>
</pre>
<p>So how does this timestamp service
solve the double spending problem?
In my opinion,
Nakamoto is not so clear on this point.
I could imagine that blocks could contain coins.
By timestamping a block containing a coin,
one is proving that Alice is the
<em>first</em> recipient of a given coin,
and not Bob.
And from the previous section,
it is enough to prove the first recipient
in order to solve the double spending problem.</p>
<p>So far,
all is well.
But wait!
Who runs the timestamp service?
This traditional solution
does not work for our needs
because it requires
a trusted 3rd-party.</p>
</div>
<div class="section" id="proof-of-work">
<h4><a class="toc-backref" href="#id16">Proof-of-Work</a></h4>
<p>What is proof-of-work?
Sometimes one would like to
control access to a shared resource
to prevent abuse of that resource.
Dwork and Naor (1992) <a class="footnote-reference" href="#id6" id="id3">[3]</a>
presented a scheme where
if Alice wants to access a shared resource,
she is required to “pay” for access
by performing some busywork.
Access to the resource
is then contingent
on Alice’s ability
to prove that she has in fact
done this busywork.
If Alice wishes to
submit some message <span class="formula"><i>x</i></span>
to the shared resource,
then the busywork takes the form
of computing a <em>moderately hard function</em>
<span class="formula"><i>y</i> = <i>f</i>(<i>x</i>)</span>.
Alice then submits
both the message
and the proof-of-work together
<span class="formula">(<i>x</i>, <i>y</i>)</span>.
Principals agree not to accept messages
without valid proofs-of-work.
Bob can validate Alice’s proof-of-work
by computing <span class="formula"><i>y</i>’ = <i>f</i>(<i>x</i>)</span>
and verifying that <span class="formula"><i>y</i> = <i>y</i>’</span>.
As an optimization,
the moderately hard function <span class="formula"><i>f</i>(<i>x</i>)</span>
can be chosen so that checking <span class="formula"><i>y</i></span>
is much faster than computing <span class="formula"><i>y</i></span>.</p>
<p>Nakamoto describes a particular
proof-of-work function <span class="formula"><i>f</i>(<i>x</i>)</span>
that involves searching for an input <span class="formula"><i>x</i></span>
where the hash of that input <span class="formula"><i>y</i> = <i>f</i>(<i>x</i>)</span>
begins with a particular number <span class="formula"><i>k</i> ≥ 1</span>
of zero bits,
which gets exponentially harder with <span class="formula"><i>k</i></span>.
In order to keep up with Moore’s law over time,
the parameter <span class="formula"><i>k</i></span>
is chosen (increased?) automatically
so that a desired number of blocks
are created each hour.</p>
</div>
<div class="section" id="distributed-timestamp-service">
<h4><a class="toc-backref" href="#id17">Distributed Timestamp Service</a></h4>
<p>In my opinion,
Nakamoto does not present
this section of the paper very clearly.
Nakamoto is describing the design
of a distributed timestamp service
where proof-of-work is required
to timestamp a block,
i.e.,
to add a block to the blockchain.
The key is that all of the principals
agree on how to verify that a block
has been timestamped correctly.
All principals possess
a complete copy of the blockchain.
Here is the definition
of a distributed timestamping service,
as expressed in Python,
using the description from the paper.</p>
<pre class="code python3 literal-block">
<span class="ln"> 1 </span><span class="k">class</span> <span class="nc">DistributedTimestampService</span><span class="p">:</span>
<span class="ln"> 2 </span> <span class="sd">"""Example of a distributed timestamp service, as described in the paper.
</span><span class="ln"> 3 </span><span class="sd">
</span><span class="ln"> 4 </span><span class="sd"> NOTE: This is my own implementation of a distributed timestamp service
</span><span class="ln"> 5 </span><span class="sd"> and most likely does not correspond with any actual timestamp service.
</span><span class="ln"> 6 </span><span class="sd"> """</span>
<span class="ln"> 7 </span> <span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">k</span><span class="p">):</span>
<span class="ln"> 8 </span> <span class="sd">"""Create a new (empty) distributed timestamp service."""</span>
<span class="ln"> 9 </span> <span class="bp">self</span><span class="o">.</span><span class="n">k</span> <span class="o">=</span> <span class="n">k</span>
<span class="ln">10 </span> <span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span> <span class="o">=</span> <span class="p">[]</span>
<span class="ln">11 </span> <span class="k">def</span> <span class="nf">add_block</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">block</span><span class="p">):</span>
<span class="ln">12 </span> <span class="sd">"""Add a new block to the blockchain."""</span>
<span class="ln">13 </span> <span class="n">block</span><span class="o">.</span><span class="n">prev_hash</span> <span class="o">=</span> <span class="mi">0</span>
<span class="ln">14 </span> <span class="k">if</span> <span class="nb">len</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="p">)</span> <span class="o">></span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">15 </span> <span class="n">block</span><span class="o">.</span><span class="n">prev_hash</span> <span class="o">=</span> <span class="nb">hash</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="p">[</span><span class="o">-</span><span class="mi">1</span><span class="p">])</span>
<span class="ln">16 </span> <span class="n">block</span><span class="o">.</span><span class="n">N</span> <span class="o">=</span> <span class="mi">0</span> <span class="c1"># start with random number?</span>
<span class="ln">17 </span> <span class="k">while</span> <span class="kc">True</span><span class="p">:</span>
<span class="ln">18 </span> <span class="n">block</span><span class="o">.</span><span class="n">N</span> <span class="o">+=</span> <span class="mi">1</span>
<span class="ln">19 </span> <span class="k">if</span> <span class="nb">bin</span><span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">block</span><span class="p">))[</span><span class="mi">2</span><span class="p">:</span><span class="mi">2</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">k</span><span class="p">]</span> <span class="o">==</span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">20 </span> <span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">block</span><span class="p">)</span>
<span class="ln">21 </span> <span class="k">break</span>
<span class="ln">22 </span> <span class="k">def</span> <span class="nf">verify_block</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">block</span><span class="p">):</span>
<span class="ln">23 </span> <span class="sd">"""Return True if a given block should be added to the blockchain
</span><span class="ln">24 </span><span class="sd"> and also add it to the blockchain."""</span>
<span class="ln">25 </span> <span class="n">prev_hash</span> <span class="o">=</span> <span class="mi">0</span>
<span class="ln">26 </span> <span class="k">if</span> <span class="nb">len</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="p">)</span> <span class="o">></span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">27 </span> <span class="n">prev_hash</span> <span class="o">=</span> <span class="nb">hash</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="p">[</span><span class="o">-</span><span class="mi">1</span><span class="p">])</span>
<span class="ln">28 </span> <span class="k">if</span> <span class="n">block</span><span class="o">.</span><span class="n">prev_hash</span> <span class="o">!=</span> <span class="n">prev_hash</span><span class="p">:</span>
<span class="ln">29 </span> <span class="k">return</span> <span class="kc">False</span>
<span class="ln">30 </span> <span class="k">if</span> <span class="nb">bin</span><span class="p">(</span><span class="nb">hash</span><span class="p">(</span><span class="n">block</span><span class="p">))[</span><span class="mi">2</span><span class="p">:</span><span class="mi">2</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">k</span><span class="p">]</span> <span class="o">!=</span> <span class="mi">0</span><span class="p">:</span>
<span class="ln">31 </span> <span class="k">return</span> <span class="kc">False</span>
<span class="ln">32 </span> <span class="bp">self</span><span class="o">.</span><span class="n">blockchain</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">block</span><span class="p">)</span>
<span class="ln">33 </span> <span class="k">return</span> <span class="kc">True</span>
</pre>
<p>So now we have
the distributed timestamp service
we mentioned
at the beginning
of this section.
The rest of this section
deals with loose ends.</p>
</div>
<div class="section" id="network">
<h4><a class="toc-backref" href="#id18">Network</a></h4>
<p>The paper clearly describes
the Bitcoin protocol.
Essentially,
blocks contain broadcasted transactions (coins)
and there is a great race
to extend the block chain.</p>
</div>
<div class="section" id="incentive">
<h4><a class="toc-backref" href="#id19">Incentive</a></h4>
<p>Why should everyone
race to extend the blockchain?
For money of course!
Each new block created
also creates a new bitcoin,
owned by the person
who created the block.
This is inflationary.
There is also a non-inflationary
incentive: transaction fees.
A transaction must specify
an input value
and an output value.
If the output value
is less than
the input value,
then the person
who creates the block
keeps the difference
for himself
as a transaction fee.</p>
</div>
<div class="section" id="reclaiming-disk-space">
<h4><a class="toc-backref" href="#id20">Reclaiming Disk Space</a></h4>
<p>Not everyone needs to have
a full copy of the blockchain
in order to use Bitcoin.
Nakamoto describes
how the use of Merkle Trees
allow parts of the blockchain
to be discarded
without affecting the ability
to validate later blocks.</p>
</div>
<div class="section" id="simplified-payment-verification">
<h4><a class="toc-backref" href="#id21">Simplified Payment Verification</a></h4>
<p>Combined with the previous section,
anyone can verify a payment
using only a subset of the blockchain.</p>
</div>
<div class="section" id="combining-and-splitting-value">
<h4><a class="toc-backref" href="#id22">Combining and Splitting Value</a></h4>
<p>Do we need a separate transaction
for each minimum unit of currency
(later named a satoshi after the author),
or can we have a single transaction
for a larger amount?
A transaction has one or more inputs
(coins that Alice owns)
and one or two outputs
(Alice and Bob,
where Bob is the recipient).
I felt that
this section
of the paper
was vague.</p>
</div>
</div>
<div class="section" id="author-s-evaluation-of-the-proposed-solution">
<h3><a class="toc-backref" href="#id23">Author’s Evaluation of the Proposed Solution</a></h3>
<p>Throughout the paper,
Nakamoto comments on
how such-and-such particular feature
enables some property of the system,
or prevents some problem.</p>
<p>On <em>preventing attacks</em>:</p>
<blockquote>
We consider the scenario of an attacker trying to generate an alternate
chain faster than the honest chain. Even if this is accomplished, it
does not throw the system open to arbitrary changes, such as creating
value out of thin air or taking money that never belonged to the attacker.
Nodes are not going to accept an invalid transaction as payment, and honest
nodes will never accept a block containing them. An attacker can only try
to change one of his own transactions to take back money he recently spent
… To modify a past block, an attacker would
have to redo the proof-of-work of the block and all blocks after it and
then catch up with and surpass the work of the honest nodes.</blockquote>
<p>Section 11 (Calculations) gives a mathematical treatment on how computationally
difficult it would be for an attacker to double spend, and presents a
theorem without proof.</p>
<p>On <em>determining representation in majority decision making</em>:</p>
<blockquote>
The proof-of-work also solves the problem of determining representation
in majority decision making. If the majority were based on
one-<span class="caps">IP</span>-address-one-vote, it could be subverted by anyone able to
allocate many IPs. Proof-of-work is essentially one-<span class="caps">CPU</span>-one-vote.
The majority decision is represented by the longest chain, which has
the greatest proof-of-work effort invested in it. If a majority of <span class="caps">CPU</span>
power is controlled by honest nodes, the honest chain will grow the fastest
and outpace any competing chains.</blockquote>
<p>On <em>simultaneous broadcasts</em>:</p>
<blockquote>
Nodes always consider the longest chain to be the correct one and will
keep working on extending it. If two nodes broadcast different versions
of the next block simultaneously, some nodes may receive one or the other
first. In that case, they work on the first one they received, but save
the other branch in case it becomes longer. The tie will be broken when the
next proof- of-work is found and one branch becomes longer; the nodes that
were working on the other branch will then switch to the longer one.</blockquote>
<p>On <em>dropped broadcasts</em>:</p>
<blockquote>
New transaction broadcasts do not necessarily need to reach all nodes.
As long as they reach many nodes, they will get into a block before long.
Block broadcasts are also tolerant of dropped messages. If a node does not
receive a block, it will request it when it receives the next block and
realizes it missed one.</blockquote>
<p>On <em>incentives to participate</em>:</p>
<blockquote>
By convention, the first transaction in a block is a special transaction
that starts a new coin owned by the creator of the block. This adds an
incentive for nodes to support the network, and provides a way to initially
distribute coins into circulation, since there is no central authority to
issue them.</blockquote>
<p>On <em>incentives to stay honest</em>:</p>
<blockquote>
The incentive may help encourage nodes to stay honest. If a greedy attacker
is able to assemble more <span class="caps">CPU</span> power than all the honest nodes, he would have
to choose between using it to defraud people by stealing back his payments,
or using it to generate new coins. He ought to find it more profitable to
play by the rules, such rules that favour him with more new coins than
everyone else combined, than to undermine the system and the validity of
his own wealth.</blockquote>
<p>On <em>the blockchain getting too large to use</em>:</p>
<blockquote>
A block header with no transactions would be about 80 bytes. If we suppose
blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.<span class="caps">2MB</span> per
year. With computer systems typically selling with <span class="caps">2GB</span> of <span class="caps">RAM</span> as of 2008,
and Moore’s Law predicting current growth of 1.<span class="caps">2GB</span> per year, storage should
not be a problem even if the block headers must be kept in memory.</blockquote>
<p>On <em>privacy</em>:</p>
<blockquote>
… privacy can still be maintained by breaking the flow of information
in another place: by keeping public keys anonymous. The public can see
that someone is sending an amount to someone else, but without information
linking the transaction to anyone … As an additional firewall, a new
key pair should be used for each transaction to keep them from being
linked to a common owner. Some linking is still unavoidable with
multi-input transactions, which necessarily reveal that their inputs were
owned by the same owner. The risk is that if the owner of a key is
revealed, linking could reveal other transactions that belonged to the
same owner.</blockquote>
</div>
<div class="section" id="my-analysis-of-the-problems-proposed-solution-and-evaluation">
<h3><a class="toc-backref" href="#id24">My Analysis of the Problems, Proposed Solution, and Evaluation</a></h3>
<p>I do not believe
that the people problems
identified in Bitcoin,
the paper,
are of great importance.
However,
I do believe that Bitcoin,
the system,
is making itself important
by disrupting many elements
of society and government.</p>
<p>The technical problems
identified in the paper
are real and well presented.</p>
<p>Frankly,
Nakamoto did a poor job
explaining the proposed solution.
One really has to
dig into this paper
to understand the system.</p>
<p>Also, Nakamoto did a poor job
analyzing the proposed solution.</p>
<p>Overall,
this is not a very good paper.
That said,
I would still encourage
everyone to read this paper
because there is no other
technical source for Bitcoin
that is as authoritative
as this one.
But honestly
I think one would have to
read the source code
to really understand the system.</p>
</div>
<div class="section" id="contributions">
<h3><a class="toc-backref" href="#id25">Contributions</a></h3>
<p>In my opinion,
the main contribution
of this paper
is Nakamoto’s proposed solution
to the problem
of double spending,
and his evaluation
of how computationally
infeasible it is
to double spend
using his solution.
The “great race”
is an ingenious mechanism
to align the incentives
of the principals.
The second contribution
of this paper
is modeling a transaction
with multiple inputs
and two outputs.
The rest of the paper,
and the individual elements
of the proposed solution,
e.g., coins,
timestamp service,
proof-of-work,
Merkle Trees, etc.,
were published previously.</p>
</div>
<div class="section" id="future-directions">
<h3><a class="toc-backref" href="#id26">Future Directions</a></h3>
<p>Bitcoin has come a long way
since 2008,
and I don’t think
that it is possible
to objectively write this section.
One could look at the original
questions and criticisms
from the 2008 to 2009
timeframe to better understand
what folks thought were the
future directions
for Bitcoin back then.</p>
</div>
<div class="section" id="lingering-questions">
<h3><a class="toc-backref" href="#id27">Lingering Questions</a></h3>
<p>I understand that
there is a bit of a mystery
surrounding the author,
Satoshi Nakamoto.
The conventional wisdom
is that his name
is a pseudonym.
But some folks question
whether or not
it was the work
of a single author.
I offer my own opinion
as a system researcher.
Yes,
I believe that
Satoshi Nakamoto
is a single person.
First,
my observation in life
is that the best work
tends to come from
a single creative mind,
and Bitcoin
is clearly
a very cleverly engineered system.
Second,
there are editorial deficiencies
in this paper
which would have been caught
if there had been multiple authors.
Some of the passages
are a bit awkward.
And some of the descriptions
are overly terse.
The author either has
graduate-level training,
or is one of the
very rare individuals
that can teach themselves
how to conduct research.
I would guess that
it is the latter
as it appears to me
that the paper
is copying the style and format
of academic literature
but is missing some key
traditional structures.
For example,
although there are citations,
there is no related work section.
There is also no future work section,
and there is no performance evaluation.
This paper would not have been accepted
to a top-tier conference
as it is currently written.</p>
<p>The paper describes how
the most common attack
would be to rewrite history
to allow an attacker
to double spend
his own coins.
To date,
has this ever
actually happened
in Bitcoin?
Would there be any
tell-tale signs
that this happened?</p>
<p>Should we be investing
in energy companies
and semiconductor fabs?</p>
<p>In the olden days of yore,
wealth was measured in cattle.
In the future,
will wealth be measured
in computational power
and access to electrical power?</p>
</div>
<div class="section" id="take-away-message">
<h3><a class="toc-backref" href="#id28">Take-Away Message</a></h3>
<p>I really enjoyed reading this paper.
If I had read it back in 2008,
then I would have thought that Bitcoin
was a really well-engineered system.
It solves many different problems,
any of which would prevent Bitcoin
from being practical.
Currently Bitcoin is struggling
with scalability problems.
Years of system research
and practical experience
at companies like Google
have shown that scalability
is a very difficult property
to architect for
without the practical experience
of getting it wrong a few times.</p>
<p>As of mid 2017,
most of the eCommerce world continues to operate
as it did in 2008,
with <span class="caps">VISA</span>, MasterCard, American Express, Discover,
and a bit of PayPal for good measure.
On the other hand,
Bitcoin currently has a market cap
of about 41B <span class="caps">USD</span>.
Where did all of this wealth come from?
From someone’s imagination.</p>
</div>
</div>
<div class="section" id="references">
<h2><a class="toc-backref" href="#id29">References</a></h2>
<table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label"/><col/></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>Satoshi Nakamoto.
<strong>Bitcoin: A Peer-to-Peer Electronic Cash System.</strong>
2008.
Available at: <a class="reference external" href="https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/bitcoin.pdf">https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/bitcoin.pdf</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label"/><col/></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td>Jake Lerner.
<strong><span class="caps">UC</span> Berkeley <span class="caps">CS</span> 261 Fall 2015 Scribe Notes: October 6: Bitcoin.</strong>
<span class="caps">UC</span> Berkeley Scribe Notes, 2015-10-08.
Available at: <a class="reference external" href="https://people.eecs.berkeley.edu/~raluca/cs261-f15/scribenotes/Bitcoin.pdf">https://people.eecs.berkeley.edu/~raluca/cs261-f15/scribenotes/Bitcoin.pdf</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label"/><col/></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id3">[3]</a></td><td>C. Dwork and M. Naor.
<strong>Pricing via Processing or Combatting Junk Mail.</strong>
Advances in Cryptology — <span class="caps">CRYPTO</span>’ 92.
Available at: <a class="reference external" href="http://www.weizmann.ac.il/mathusers/naor/PAPERS/pvp.pdf">http://www.weizmann.ac.il/mathusers/naor/<span class="caps">PAPERS</span>/pvp.pdf</a></td></tr>
</tbody>
</table>
</div>
<hr/>
</div>
<section>
<div class="span2" style="float:right;font-size:0.9em;">
<h4>Published</h4>
<time pubdate="pubdate" datetime="2017-07-17T06:00:00-07:00">Jul 17, 2017</time>
<h4>Category</h4>
<a class="category-link" href="./categories.html#paper-reviews-ref">paper reviews</a>
<h4>Tags</h4>
<ul class="list-of-tags tags-in-article">
<li><a href="./tags.html#bitcoin-ref">bitcoin
<span>1</span>
</a></li>
</ul>
</div>
</section>