1 \documentclass{article} |
|
2 \usepackage{../style} |
|
3 \usepackage{../graphics} |
|
4 \usepackage{../langs} |
|
5 \usepackage{../data} |
|
6 |
|
7 %https://crypto.stanford.edu/cs251/ |
|
8 %https://programmingblockchain.gitbooks.io/programmingblockchain/content/ |
|
9 |
|
10 % bug in smart contracts |
|
11 % https://www.benthamsgaze.org/2016/06/17/smart-contracts-beyond-the-age-of-innocence/ |
|
12 % http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/ |
|
13 |
|
14 % hard forks |
|
15 % https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki |
|
16 |
|
17 % only 25% needed to obtain larger shares of mining |
|
18 % http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf |
|
19 |
|
20 % re-identification attacks |
|
21 % https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf |
|
22 |
|
23 % bit-coin papers |
|
24 % https://crypto.stanford.edu/cs251/syllabus.html |
|
25 |
|
26 % bit coin talk --- at 20:00 mins |
|
27 %https://www.usenix.org/conference/lisa16/conference-program/presentation/perlman |
|
28 |
|
29 % In fact, far from freeing people from the oppression of the state, |
|
30 % blockchains perversely promise the perfect tool for a fully |
|
31 % auditable, tax compliant, cashless society. Similarly, the belief it |
|
32 % is an anonymous digital cash has quickly vanished and we are now |
|
33 % seeing a large number of analytics companies, set-up specifically to |
|
34 % work with law enforcement agencies, to police this new parallel |
|
35 % financial system. |
|
36 % |
|
37 % But today blockchain is riddled with |
|
38 % contradictions and misunderstandings. Most of its problems are very |
|
39 % fixable, if you want to fix them |
|
40 |
|
41 |
|
42 % history of bitcoins |
|
43 % https://futurism.com/images/this-week-in-tech-jan-15-22-2016/ |
|
44 |
|
45 \begin{document} |
|
46 \fnote{\copyright{} Christian Urban, 2014, 2015} |
|
47 |
|
48 \section*{Handout 7 (Bitcoins)} |
|
49 |
|
50 In my opinion Bitcoins are an elaborate Ponzi |
|
51 scheme\footnote{\url{http://en.wikipedia.org/wiki/Ponzi_scheme}}---still |
|
52 the ideas behind them are really beautiful and not too |
|
53 difficult to understand. Since many colourful claims about |
|
54 Bitcoins float around in the mainstream and not-so-mainstream |
|
55 media, it will be instructive to re-examine such claims from a |
|
56 more technically informed vantage point. For example, it is |
|
57 often claimed that Bitcoins are anonymous and free from any |
|
58 potential government meddling. It turns out that the first |
|
59 claim ignores a lot of research in de-anonymising social |
|
60 networks, and the second underestimates the persuasive means a |
|
61 government has at its disposal. |
|
62 |
|
63 There are a lot of articles, blogposts, research papers |
|
64 etc.~available about Bitcoins. Below I will follow closely the |
|
65 very readable explanations from |
|
66 |
|
67 \begin{center} |
|
68 \url{http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/} \;\;and\smallskip\\ |
|
69 \url{http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html} |
|
70 \end{center} |
|
71 |
|
72 \noindent The latter also contains a link to a nice youtube |
|
73 video about the technical details behind Bitcoins. I will |
|
74 also use some of their pictures. |
|
75 |
|
76 Let us start with the question who invented Bitcoins? You |
|
77 could not make up the answer, but we actually do not know who |
|
78 the inventor is. All we know is that the first paper |
|
79 |
|
80 \begin{center} |
|
81 \url{https://bitcoin.org/bitcoin.pdf} |
|
82 \end{center} |
|
83 |
|
84 \noindent is signed by Satoshi Nakamoto, which however is |
|
85 likely only a pen name. There is a lot of speculation who |
|
86 could be the inventor, or inventors, but we simply do not |
|
87 know. This part of Bitcoins is definitely anonymous so far. |
|
88 The paper above is from the end of 2008; the first Bitcoin |
|
89 transaction was made in January 2009. The rules in Bitcoin are |
|
90 set up so that there will only ever be 21 Million Bitcoins |
|
91 with the maximum reached around the year 2140. Currently there |
|
92 are already 11 Million Bitcoins in `existence'. Contrast this |
|
93 with traditional fiat currencies where money can be printed |
|
94 almost at will. The smallest unit of a Bitcoin is called a |
|
95 Satoshi, which is the $10^{-8}$th part of a Bitcoin. Remember |
|
96 a Penny is the $10^{-2}$th part of a Pound. |
|
97 |
|
98 The two main cryptographic building blocks of Bitcoins are |
|
99 cryptographic hashing functions (SHA-256) and public-private |
|
100 keys using the elliptic-curve encryption scheme for digital |
|
101 signatures. Hashes are used to generate `fingerprints' of data |
|
102 that ensure integrity (absence of tampering). Public-private |
|
103 keys are used for signatures. For example sending a message, |
|
104 say $msg$, together with the encrypted version |
|
105 |
|
106 \[ |
|
107 msg, \{msg\}_{K^{priv}} |
|
108 \] |
|
109 |
|
110 \noindent allows everybody with access to the corresponding |
|
111 public key $K^{pub}$ to verify that the message came from the |
|
112 person who knew the private key. Signatures are used in |
|
113 Bitcoins for verifying the addresses where the Bitcoins are |
|
114 sent from. Addresses in Bitcoins are essentially the public |
|
115 keys. There are $2^{160}$ possible addresses, which is such a |
|
116 vast amount that there is not even a check for duplicates, or |
|
117 already used addresses. If you start with a random number to |
|
118 generate a public-private key pair it is very unlikely that |
|
119 you step on somebody else's shoes. Compare this with the |
|
120 email-addresses you wanted to register with, say |
|
121 Gmail, but which are always already taken. |
|
122 |
|
123 One major difference between Bitcoins and traditional banking |
|
124 is that you do not have a place, or few places, that record the |
|
125 balance on your account. Traditional banking involves a |
|
126 central ledger which specifies the current balance in each |
|
127 account, for example |
|
128 |
|
129 \begin{center} |
|
130 \begin{tabular}{l|r} |
|
131 account owner & balance\\\hline |
|
132 Alice & \pounds{10.01}\\ |
|
133 Bob & \pounds{4.99}\\ |
|
134 Charlie & -\pounds{1.23}\\ |
|
135 Eve & \pounds{0.00} |
|
136 \end{tabular} |
|
137 \end{center} |
|
138 |
|
139 \noindent Bitcoins work differently in that there is no such |
|
140 central ledger, but instead a public record of all |
|
141 transactions ever made. This means spending money corresponds |
|
142 to sending messages of the (oversimplified) form |
|
143 |
|
144 \begin{equation} |
|
145 \{\text{I, Alice, am giving Bob one Bitcoin.}\}_{K^{priv}_{Alice}} |
|
146 \end{equation} |
|
147 |
|
148 \noindent These messages, called transactions, are the only |
|
149 data that is ever stored in the Bitcoin system (we will come |
|
150 to the precise details later on). The transactions are |
|
151 encrypted with Alice's private key so that everybody, |
|
152 including Bob, can use Alice's public key $K^{pub}_{Alice}$ to |
|
153 verify that this message came really from Alice, or more |
|
154 precisely from the person who knows $K^{priv}_{Alice}$. |
|
155 |
|
156 The problem with such messages in a distributed system is that |
|
157 what happens if Bob receives 10, say, of these transactions? |
|
158 Did Alice intend to send him 10 Bitcoins, or did the message |
|
159 get duplicated by for example an attacker re-playing a sniffed |
|
160 message? What is needed is a kind of serial number for such |
|
161 transactions. This means transaction messages shoul look more like |
|
162 |
|
163 \begin{center} |
|
164 $\{\text{I, Alice, am giving Bob Bitcoin \#1234567.}\}_{K^{priv}_{Alice}}$ |
|
165 \end{center} |
|
166 |
|
167 \noindent There are two difficulties, however, that need to be |
|
168 solved with serial numbers. One is who is assigning serial |
|
169 numbers to Bitcoins and also how can Bob verify that Alice |
|
170 actually owns this Bitcoin to pay him? In a system with a bank |
|
171 as trusted third-party, Bob could do the following: |
|
172 |
|
173 \begin{itemize} |
|
174 \item Bob asks the bank whether the Bitcoin with that serial |
|
175 number belongs to Alice and Alice hasn't already spent |
|
176 this Bitcoin. |
|
177 \item If yes, then Bob tells the bank he accepts this Bitcoin. |
|
178 The bank updates the records to show that the Bitcoin |
|
179 with that serial number is now in Bob’s possession and |
|
180 no longer belongs to Alice. |
|
181 \end{itemize} |
|
182 |
|
183 \noindent But for this banks would need to be trusted and |
|
184 would also be an easy target for any government interference, |
|
185 for example. Think of the early days of music sharing where |
|
186 the company Napster was the trusted third-party but also the single point of ``failure'' which |
|
187 was taken offline by law enforcement. Bitcoins is more like a |
|
188 system such as BitTorrent without a single central entity that |
|
189 can be taken offline.\footnote{There is some Bitcoin |
|
190 infrastructure that is not so immune from being taken offline: |
|
191 for example Bitcoin exchanges, HQs of Bitcoin mining pools, |
|
192 Bitcoin developers and so on.} |
|
193 |
|
194 Bitcoins solve the problem of not being able to rely on a bank |
|
195 by making everybody the ``bank''. Everybody who cares can have |
|
196 the entire transaction history starting with the first |
|
197 transaction made in January 2009. This history of transactions |
|
198 is called the \emph{blockchain}. Bob, for example, can use his |
|
199 copy of the blockchain for determining whether Alice owned the |
|
200 Bitcoin he received, and if she did, he transmits the message |
|
201 that he owns it now to every other participant on the Bitcoin |
|
202 network. An illustration of a three-block segment of the |
|
203 blockchain is (simplified) as follows |
|
204 |
|
205 \begin{equation} |
|
206 \includegraphics[scale=0.4]{../pics/bitcoinblockchain0.png} |
|
207 \label{segment} |
|
208 \end{equation} |
|
209 |
|
210 \noindent The chain grows with time. Each block contains a |
|
211 list of individual transactions, written txn in the picture |
|
212 above, and also a reference to the previous block, written |
|
213 prev. The data in a block (txn's and prev) is hashed so that |
|
214 the reference and transactions in them cannot be tampered |
|
215 with. This hash is also the unique serial number of each |
|
216 block. Since this previous-block-reference is also part of the |
|
217 hash, the whole chain is robust against tampering. I let you |
|
218 think why this is the case?\ldots{}But does it actually |
|
219 eliminate all possibilities of fraud? |
|
220 |
|
221 We can check the consistency of the blockchain by checking |
|
222 whether all the references and hashes are correctly recorded. |
|
223 I have not tried it myself, but it is said that with the |
|
224 current amount of data (appr.~12GB) it takes roughly a day to |
|
225 check the consistency of the blockchain on a normal computer. |
|
226 Fortunately this ``extended'' consistency check usually only |
|
227 needs to be done once. Afterwards the blockchain only needs to |
|
228 be updated consistently. |
|
229 |
|
230 Recall I wrote earlier that Bitcoins do not maintain a ledger, |
|
231 which lists all the current balances in each account. Instead |
|
232 only transactions are recorded. While a current balance of an |
|
233 account is not immediately available, it is possible to |
|
234 extract from the blockchain a transaction graph that looks |
|
235 like the picture shown in Figure~\ref{txngraph}. Each |
|
236 rectangle represents a single transaction. Take for example |
|
237 the rightmost lower transaction from Charles to Emily. This |
|
238 transaction has as receiver the address of Emily and as the |
|
239 sender the address of Charles. In this way no Bitcoins can |
|
240 appear out of thin air (we will discuss later how Bitcoins are |
|
241 actually generated). If Charles did not have a transaction of |
|
242 at least the amount he wants to give Emily to his name |
|
243 (i.e.~send to an address with his public-private key) then |
|
244 there is no way he can make a payment to Emily. Equally, if |
|
245 now Emily wants to pay for a coffee, say, with the Bitcoin she |
|
246 received from Charles she can essentially only forward the |
|
247 message she received. The only slight complication with this |
|
248 setup in Bitcoins is that ``incoming'' Bitcoins can be |
|
249 combined in a transaction and ``outgoing'' Bitcoins can be |
|
250 split. For example in the leftmost upper transactions in |
|
251 Figure~\ref{txngraph}, Fred makes a payment to Alice. But this |
|
252 payment (or transaction) combines the Bitcoins that were send |
|
253 by Jane to Fred and also by Juan to Fred. This allows you to |
|
254 ``consolidate'' your funds: if it were only possible to split |
|
255 transactions, then the amounts would get smaller and smaller. |
|
256 |
|
257 In Bitcoins you have the ability to both combine incoming |
|
258 transactions, but also to split outgoing transactions to |
|
259 potentially more than one receiver. The latter is also needed. |
|
260 Consider again the rightmost transactions in |
|
261 Figure~\ref{txngraph} and suppose Alice is a coffeeshop owner |
|
262 selling coffees for 1 Bitcoin. Charles received a transaction |
|
263 from Zack over 5 Bitcoins, say. How does Charles pay for the |
|
264 coffee? There is no explicit notion of \emph{change} in the |
|
265 Bitcoin system. What Charles has to do instead is to make one |
|
266 single transaction with 1 Bitcoin to Alice and with 4 Bitcoins |
|
267 going back to himself, which then Charles can use to give to |
|
268 Emily, for example. |
|
269 |
|
270 \begin{figure}[t] |
|
271 \begin{center} |
|
272 \includegraphics[scale=0.4]{../pics/blockchain.png} |
|
273 \end{center} |
|
274 \caption{Transaction graph that is implicitly recorded in the |
|
275 public blockchain.\label{txngraph}} |
|
276 \end{figure} |
|
277 |
|
278 Let us consider another example. Suppose Emily received 4 |
|
279 Bitcoins from Charles and independently received another |
|
280 transaction (not shown in the picture) that sends 6 Bitcoins |
|
281 to her. If she now wants to buy a coffee from Alice for 1 |
|
282 Bitcoin, she has two possibilities: She could just forward the |
|
283 transaction from Charles over 4 Bitcoins to Alice split in |
|
284 such a way that Alice receives 1 Bitcoin and Emily sends the |
|
285 remaining 3 Bitcoins back to herself. In this case she would |
|
286 now be in the possession of two unspend Bitcoin transactions, |
|
287 one over 3 Bitcoins and the independent one over 6 Bitcoins. |
|
288 Or, Emily could combine both transactions (one over 4 Bitcoins |
|
289 from Charles and the independent one over 6 Bitcoins) and then |
|
290 split this amount with 1 Bitcoin going to Alice and 9 Bitcoins |
|
291 going back to herself. |
|
292 |
|
293 I think this is a good time for you to pause to let this |
|
294 concept of transactions to really sink in\ldots{}You should |
|
295 come to the conclusion that there is really no need for a central ledger and no |
|
296 need for an account balance as familiar from traditional |
|
297 banking. The closest what Bitcoin has to offer for the notion |
|
298 of a balance in a bank account are the unspend transactions |
|
299 that a person (more precisely a public-private key address) |
|
300 received. That means transactions that can still be forwarded. |
|
301 |
|
302 After the pause also consider the fact that whatever |
|
303 transaction is recorded in the blockchain will be in the |
|
304 ``historical record'' for the Bitcoin system. If a transaction |
|
305 says 1 Bitcoin goes from address $A$ to address $B$, then this |
|
306 is what will be---$B$ has then the possibility to spend the |
|
307 corresponding Bitcoins, whether the transaction was done |
|
308 fraudulently or not. There is no exception to this rule. |
|
309 Interestingly this is also how Bitcoins can get lost: One |
|
310 possibility is that you send Bitcoins to an address for which |
|
311 nobody has generated a private key, for example because of a |
|
312 typo in the address field---bad luck for fat |
|
313 fingers\footnote{\url{http://en.wikipedia.org/wiki/Typographical_error}} |
|
314 in the Bitcoin system. The reason is that nobody has a private |
|
315 key for this erroneous address and consequently cannot forward |
|
316 the transaction anymore. Another possibility is that you |
|
317 forget your private key and you had messages forwarded to the |
|
318 corresponding public key. Also in this case bad luck: you will |
|
319 never be able to forward this message again, because you will |
|
320 not be able to form a valid message that sends this to |
|
321 somebody else (we will see the details of this later). But |
|
322 this is also a way how you can get robbed of your Bitcoins. By |
|
323 old-fashioned hacking-into-a-computer crime, for example, an |
|
324 attacker might get hold of your private key and then quickly |
|
325 forwards the Bitcoins that are in your name to an address the |
|
326 attacker controls. You will never again have access to these |
|
327 Bitcoins, because for the Bitcoin system they are assumed to |
|
328 be spent. And remember with Bitcoins you cannot appeal to any |
|
329 higher authority. Once the Bitcoins are gone, they are gone. |
|
330 This is much different in traditional banking where at least |
|
331 you can try to harass the bank to roll back the transaction. |
|
332 |
|
333 This brings us to back to problem of double spend. Suppose Bob |
|
334 is a merchant. How can he make sure that Alice does not cheat |
|
335 him? She could for example send a transaction to Bob. But also |
|
336 forward the ``same'' transaction to Charlie, or even herself. |
|
337 If Alice manages to get the second transaction into the |
|
338 blockchain, Bob will be cheated out of his money. The problem |
|
339 in such conflicting situations is how should the network |
|
340 update their blockchain? You might end up with a picture like |
|
341 this |
|
342 |
|
343 \begin{center} |
|
344 \includegraphics[scale=0.4]{../pics/bitcoindisagreement.png} |
|
345 \end{center} |
|
346 |
|
347 \noindent where Alice convinced some part of the ``world'' |
|
348 that she is still the owner of the Bitcoin and some other part |
|
349 of the ``world'' thinks it's Bob's. How should such a |
|
350 disagreement be resolved? This is actually the main hurdle |
|
351 where Bitcoin really innovated. The answer is that Bob needs |
|
352 to convince ``enough'' people on the network that the |
|
353 transaction from Alice to him is legit. |
|
354 |
|
355 What does, however, ``enough'' mean in a distributed system? |
|
356 If Alice sets up a network of a billion, say, puppy identities |
|
357 and whenever Bob tries to convince, or validate, that he is |
|
358 the rightful owner of the Bitcoin, then the puppy identities |
|
359 agree. Bob would then have no reason to not give Alice her |
|
360 coffee. But behind his back she has convinced everybody else |
|
361 on the network that she is still the rightful owner of the |
|
362 Bitcoin. After being outvoted, Bob would be a tad peeved. |
|
363 |
|
364 The reflex reaction to such a situation would be to make the |
|
365 process of validating a transaction as cheap as possible. The |
|
366 intention is that Bob will easily get enough peers to agree with him |
|
367 that he is the rightful owner. But such a solution has always |
|
368 the limitation of Alice setting up an even bigger network of |
|
369 puppy identities. The really cool idea of Bitcoin is to go |
|
370 into the other direction of making the process of transaction |
|
371 validation (artificially) as expensive as possible, but reward |
|
372 people for helping with the validation. This is really a novel |
|
373 and counterintuitive idea that makes the whole system of |
|
374 Bitcoins work so beautifully. |
|
375 |
|
376 \subsubsection*{Proof-of-Work Puzzles} |
|
377 |
|
378 In order to make the process of transaction validation |
|
379 difficult, Bitcoin uses a kind of puzzle. Solving the puzzles |
|
380 is called \emph{Bitcoin mining}, where whoever solves a puzzle |
|
381 will be awarded some Bitcoins. At the beginning this was 50 |
|
382 Bitcoins, but the rules of Bitcoin are set up such that this |
|
383 amount halves every 210,000 transactions or so. Currently you |
|
384 will be awarded 25 Bitcoins for solving a puzzle. Because the |
|
385 amount will halve again and then later again and again, around |
|
386 the year 2140 it will go below the level of 1 Satoshi. In that |
|
387 event no new Bitcoins will ever be created again and the |
|
388 amount of Bitcoins stays fixed. There will be still an |
|
389 incentive to help with validating transactions, because there |
|
390 is the possibility in Bitcoins to offer a transaction fee to |
|
391 whoever solves a puzzle. At the moment this fee is usually set |
|
392 to 0, since the incentive for miners is the 25 Bitcoins that |
|
393 are currently awarded for solving puzzles. |
|
394 |
|
395 What do the puzzles that miners have to solve look like? The |
|
396 puzzles can be illustrated roughly as follows: Given a string, |
|
397 say \code{"Hello, world!"}, what is the salt so that the hash |
|
398 starts with a long run of zeros? Let us look at a concrete |
|
399 example. Recall that Bitcoins use the hash-function SHA-256. |
|
400 Suppose we call this hash function \code{h}, then we could try |
|
401 the salt \code{0} as follows: |
|
402 |
|
403 \begin{quote} |
|
404 \code{h("Hello, world!0") =}\\ |
|
405 \mbox{}\quad\footnotesize\pcode{1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64} |
|
406 \end{quote} |
|
407 |
|
408 \noindent OK this does not have any zeros at all. We could |
|
409 next try the salt \code{1}: |
|
410 |
|
411 \begin{quote} |
|
412 \code{h("Hello, world!1") =}\\ |
|
413 \mbox{}\quad\footnotesize\pcode{e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8} |
|
414 \end{quote} |
|
415 |
|
416 \noindent Again this hash value does not contain any leading |
|
417 zeros. We could now try out every salt until we reach |
|
418 |
|
419 \begin{quote} |
|
420 \code{h("Hello, world!4250") =}\\ |
|
421 \mbox{}\quad\footnotesize\pcode{0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9} |
|
422 \end{quote} |
|
423 |
|
424 \noindent where we have four leading zeros. If four zeros are |
|
425 enough, then the puzzle would be solved with this salt. The |
|
426 point is that we can very quickly check whether a salt solves |
|
427 a puzzle, but it is hard to find one. Latest research suggest |
|
428 it is an NP-problem. If we want the output hash value to begin |
|
429 with 10 zeroes, say, then we will, on average, need to try |
|
430 $16^{10} \approx 10^{12}$ different salts before we find a |
|
431 suitable one. |
|
432 |
|
433 In Bitcoins the puzzles are not solved according to how many |
|
434 leading zeros a hash-value has, but rather whether it is below |
|
435 a \emph{target}. The hardness of the puzzle can actually be |
|
436 controlled by changing the target according to the available |
|
437 computational power available. I think the adjustment of the |
|
438 hardness of the problems is done every 2060 blocks |
|
439 (appr.~every two weeks). The aim of the adjustment is that on |
|
440 average the Bitcoin network will most likely solve a puzzle |
|
441 within 10 Minutes. |
|
442 |
|
443 \begin{center} |
|
444 \includegraphics[scale=0.37]{../pics/blockchainsolving.png} |
|
445 \end{center} |
|
446 |
|
447 \noindent It could be solved quicker, but equally it could |
|
448 take longer, but on average after 10 Minutes somebody on the |
|
449 network will have found a solution. |
|
450 |
|
451 Remember that the puzzles are a kind of proof-of-work that |
|
452 make the validation of transactions artificially expensive. |
|
453 Consider the following picture with a blockchain and some |
|
454 unconfirmed transactions. |
|
455 |
|
456 \begin{equation} |
|
457 \includegraphics[scale=0.38]{../pics/bitcoin_unconfirmed.png} |
|
458 \label{unconfirmed} |
|
459 \end{equation} |
|
460 |
|
461 \noindent The puzzle is stated as follows: There are some |
|
462 unconfirmed transactions. Choosing some of them, the miner |
|
463 (i.e.~the person/computer that tries to solve a puzzle) will |
|
464 form a putative block to be added to the blockchain. This |
|
465 putative block will contain the transactions and the reference |
|
466 to the previous block. The serial number of such a block is |
|
467 simply the hash of all the data. The puzzle can then be stated |
|
468 as the ``string'' corresponding to the block and which salt is |
|
469 needed in order to have the hashed value being below the |
|
470 target. Other miners will choose different transactions and |
|
471 therefore work on a slightly different putative block and |
|
472 puzzle. |
|
473 |
|
474 The intention of the proof-of-work puzzle is that the |
|
475 blockchain is at every given moment linearly ordered, see the |
|
476 picture shown in \eqref{unconfirmed}. If we don’t have such a |
|
477 linear ordering at any given moment then it may not be clear |
|
478 who owns which Bitcoins. Assume a miner David is lucky and |
|
479 finds a suitable salt to confirm some transactions. Should he |
|
480 celebrate? Not yet. Typically the blockchain will look as |
|
481 follows |
|
482 |
|
483 \begin{center} |
|
484 \includegraphics[scale=0.65]{../pics/block_chain1.png} |
|
485 \end{center} |
|
486 |
|
487 \noindent But every so often there will be a fork |
|
488 |
|
489 \begin{center} |
|
490 \includegraphics[scale=0.65]{../pics/block_chain_fork.png} |
|
491 \end{center} |
|
492 |
|
493 \noindent What should be done in this case? Well, the tie is |
|
494 broken if another block is solved, like so: |
|
495 |
|
496 \begin{center} |
|
497 \includegraphics[scale=0.4]{../pics/bitcoin_blockchain_branches.png} |
|
498 \end{center} |
|
499 |
|
500 \noindent The rule in Bitcoins is: If a fork occurs, people on |
|
501 the network keep track of all forks (they can see). But at any |
|
502 given time, miners only work to extend whichever fork is |
|
503 longest in their copy of the block chain. Why should miners |
|
504 work on the longest fork? Well their incentive is to mine |
|
505 Bitcoins. If somebody else already solved a puzzle, then it |
|
506 makes more sense to work on a new puzzle and obtain the |
|
507 Bitcoins for solving that puzzle, rather than waste efforts on |
|
508 a fork that is shorter and therefore less likely to be |
|
509 ``accepted''. Note that whoever solved a puzzle on the |
|
510 ``loosing'' fork will actually not get any Bitcoins as reward. |
|
511 Tough luck. |
|
512 |
|
513 |
|
514 \subsubsection*{Alice against the Rest of the World} |
|
515 |
|
516 Let us see how the blockchain and the proof-of-work puzzles |
|
517 avoid the problem of double spend. If Alice wants to cheat |
|
518 Bob, she would need to pull off the following ploy: |
|
519 |
|
520 \begin{center} |
|
521 \includegraphics[scale=0.4]{../pics/bitcoin_blockchain_double_spend.png} |
|
522 \end{center} |
|
523 |
|
524 \noindent Alice makes a transaction to Bob for paying, for |
|
525 example, for an online order. This transaction is confirmed, |
|
526 or validated, in block 2. Bob ships the goods around block 4. |
|
527 In this moment, Alice needs to get into action and try to |
|
528 validate the fraudulent transaction to herself instead. At |
|
529 this moment she is in a race against all the computing power |
|
530 of the ``rest of the world''. Because the incentive of the |
|
531 rest of the world is to work on the longest chain, that is the |
|
532 one with the transaction from Alice to Bob: |
|
533 |
|
534 \begin{center} |
|
535 \includegraphics[scale=0.4]{../pics/bitcoin_doublespend_blockchain_race.png} |
|
536 \end{center} |
|
537 |
|
538 \noindent As shown in the picture she has to solve the puzzles |
|
539 2a to 5a one after the other, because the hash of a block is |
|
540 determined via the reference by all the data in the previous |
|
541 block. She might be very lucky to solve one puzzle for a block |
|
542 before the rest of the world, but to be lucky many times is |
|
543 very unlikely. This principle of having to race against the |
|
544 rest of the world avoids the ploy of double spend. |
|
545 |
|
546 In order to raise the bar for Alice even further, merchants |
|
547 accepting Bitcoins use the following rule of thumb: A |
|
548 transaction is ``confirmed'' if |
|
549 |
|
550 \begin{itemize} |
|
551 \item[(1)] it is part of a block in the longest fork, and |
|
552 \item[(2)] at least 5 blocks follow it in the longest fork. In |
|
553 this case we say that the transaction has 6 |
|
554 confirmations. |
|
555 \end{itemize} |
|
556 |
|
557 \noindent A simple calculation shows that this amount of |
|
558 confirmations can take up to 1 hour and more. While this seems |
|
559 excessively long, from the merchant's point of view it is not |
|
560 that long at all. For this recall that ordinary creditcards |
|
561 can have their transactions been rolled-back for 6 months or |
|
562 so. The point however is that the odds for Alice being able to |
|
563 cheat are very low, unless she can muster more than 50\% of |
|
564 the world Bitcoin mining capacity. In this case she could |
|
565 out-race the rest of the world. The point is however that |
|
566 amassing such an amount of computing power is practically |
|
567 impossible for a single person or even a moderately large |
|
568 group. |
|
569 |
|
570 Connected with the 6-confirmation rule is an interesting |
|
571 phenomenon. On average, it would take several years for a |
|
572 typical computer to solve a proof-of-work puzzle, so an |
|
573 individual’s chance of ever solving one before the rest of the |
|
574 world, which typically takes only 10 minutes, is negligibly |
|
575 low. Therefore many people join groups called \emph{mining |
|
576 pools} that collectively work to solve blocks, and distribute |
|
577 rewards based on work contributed. These mining pools act |
|
578 somewhat like lottery pools among co-workers, except that some |
|
579 of these pools are quite large, and comprise more than 20\% of |
|
580 all the computers in the network. It is said that BTCC, a |
|
581 large mining pool, has limited its number of members in order |
|
582 to not solve more than 6 blocks in a row. Otherwise this would |
|
583 undermine the trust in Bitcoins, which is also not in the |
|
584 interest of BTCC, I guess. Some statistics on mining pools can |
|
585 be seen at |
|
586 |
|
587 \begin{center} |
|
588 \url{https://blockchain.info/pools} |
|
589 \end{center} |
|
590 |
|
591 \noindent Here is an interesting problem: You are part of a lottery |
|
592 pool, if you chip in some of the money to buy a lottery ticket. In |
|
593 this setting it is clear when you are in or outside of the pool. But |
|
594 how do you make sure people work hard in a mining pool in order to |
|
595 justify a fraction of any reward? If evil me had its way, I would just |
|
596 claim I do work and then sit back and relax. Or even if I do some work |
|
597 for a mining pool and I happen to find a correct salt, I would keep it |
|
598 secret and submit it to the bitcoin network on the ``side''. Actually, |
|
599 the idea of mining pools has opened up a full can of interesting |
|
600 problems. |
|
601 |
|
602 |
|
603 |
|
604 \subsubsection*{Bitcoins for Real} |
|
605 |
|
606 Let us now turn to the nitty gritty details. As a participant |
|
607 in the Bitcoin network you need to generate and store a |
|
608 public-private key pair. The public key you need to advertise |
|
609 in order to receive payments (transactions). The private key |
|
610 needs to be securely stored. For this there seem to be three |
|
611 possibilities |
|
612 |
|
613 \begin{itemize} |
|
614 \item an electronic wallet on your computer |
|
615 \item a cloud-based storage (offered by some Bitcoin services) |
|
616 \item paper-based |
|
617 \end{itemize} |
|
618 |
|
619 \noindent The first two options of course offer convenience |
|
620 for making and receiving transactions. But given the nature of |
|
621 the private keys and how much security relies on them (recall |
|
622 if somebody gets hold of it, your Bitcoins are quickly lost |
|
623 forever) I would opt for the third option for anything except |
|
624 for trivial amounts of Bitcoins. As we have seen earlier in |
|
625 the course, securing a computer system that it can withstand a |
|
626 targeted breakin is still very much an unsolved problem. |
|
627 |
|
628 An interesting fact with Bitcoin keys is that there is no |
|
629 check for duplicate addresses. This means when generating a |
|
630 public-private key, you should really start with a carefully |
|
631 chosen random number such that there is really no chance to |
|
632 step on somebody's feet in the $2^{160}$ space of |
|
633 possibilities. Again if you share an address with somebody |
|
634 else, he or she has access to all your unspend transactions. |
|
635 The absence of such a check is easily explained: How would one |
|
636 do this in a distributed system? The answer you can't. It is |
|
637 possible to do some sanity check of addresses that are already |
|
638 used in the blockchain, but this is not a fail-proof method. |
|
639 One really has to trust on the enormity of the $2^{160}$ |
|
640 space for addresses. |
|
641 |
|
642 Let us now look at the concrete data that is stored in an transaction |
|
643 message: |
|
644 |
|
645 \lstinputlisting[language=Scala]{../slides/msg} |
|
646 |
|
647 \noindent The hash in Line 1 is the hash of all the data that |
|
648 follows. It is a kind of serial number for the transaction. |
|
649 Line 2 contains a version number in case there are some |
|
650 incompatible changes to be made. Lines 3 and 4 specify how |
|
651 many incoming transactions are combined and how many outgoing |
|
652 transactions there are. In our example there are one for each. |
|
653 Line 5 specifies a lock time for when the transaction is |
|
654 supposed to become active---this is usually set to 0 to become |
|
655 active immediately. Line 6 specifies the size of the message; |
|
656 it has nothing to do with the Bitcoins that are transferred. |
|
657 Lines 7 to 11 specify where the Bitcoins in the transaction |
|
658 are coming from. The has in line 9 specifies the incoming |
|
659 transaction and the \pcode{n} in Line 10 specifies which |
|
660 output of the transaction is referred to. The signature in |
|
661 line 11 specifies the address (public key $K^{pub}$) from |
|
662 where the Bitcoins are taken and the digital signature of the |
|
663 address, that is $\{K^{pub}\}_{K^{priv}}$. Lines 12 to 15 |
|
664 specify the value of the first outgoing transaction. In this |
|
665 case 0.319 Bitcoins. The hash in Line 14 specifies the address |
|
666 to where the Bitcoins are transferred. |
|
667 |
|
668 As can be seen there is no need to issue serial numbers for |
|
669 transactions, the hash of the transaction data can do this |
|
670 job. The hash will contain the sender addresses and |
|
671 hash-references to the incoming transactions, as well as the |
|
672 public key of the incoming transaction. This uniquely |
|
673 identifies a transaction and the hash is the unique |
|
674 fingerprint of it. The in-field also contains the address to |
|
675 which a earlier transaction is made. The digital signature |
|
676 ensures everybody can check that the person who makes this |
|
677 transaction is in the possession of the private key. Otherwise |
|
678 the signature would not match up with the public-key address. |
|
679 |
|
680 When mining the blockchain it only needs to be ensured that |
|
681 the transactions are consistent (all hashes and signatures |
|
682 match up). Then we need to generate the correct previous-block |
|
683 link and solve the resulting puzzle. Once the block is |
|
684 accepted, everybody can check the integrity of the whole |
|
685 blockchain. |
|
686 |
|
687 A word of warning: The point of a lottery is that some people |
|
688 win. But equally, that most people lose. Mining Bitcoins has |
|
689 pretty much the same point. According to the article below, a |
|
690 very large machine (very, very large in terms of June 2014) |
|
691 could potentially mine \$40 worth of Bitcoins a day, but would |
|
692 require magnitudes more of electricity costs to do so. |
|
693 |
|
694 \begin{center} |
|
695 \url{http://bitcoinmagazine.com/13774/government-bans-professor-mining-bitcoin-supercomputer/} |
|
696 \end{center} |
|
697 |
|
698 \noindent Bitcoin mining nowadays is only competitive, or |
|
699 profitable, if you get the energy for free, or use special |
|
700 purpose computing devices. |
|
701 |
|
702 This about ``free'' energy can actually hurt you very badly in |
|
703 unexpected ways. You probably have heard about, or even used, |
|
704 Amazon's Elastic Compute Cloud (EC2). Essentially, Amazon is |
|
705 selling computing power that you can use to run your web site, |
|
706 for example. It is \emph{elastic} in the sense that if you |
|
707 have a lot of visitors, you pay a lot, if you have only a few, |
|
708 then it is cheap. In order to bill you, you need to set |
|
709 up an account with Amazon and receive some secret keys in |
|
710 order to authenticate you. The clever (but also dangerous) bit |
|
711 is that you upload the code of your web site to GitHub and |
|
712 Amazon will pull it from there. You can probably already guess |
|
713 where this is going: in order to learn about Amazon's API, it |
|
714 gives out some limited computing power for free. Somebody used |
|
715 this offer in order to teach himself Ruby on Rails with a |
|
716 mildly practical website. Unfortunately, he uploaded also his |
|
717 secret keys to GitHub (this is really an easy mistake). Now, |
|
718 nasty people crawl GitHub for the purpose of stealing such |
|
719 secret keys. What can they do with this? Well, they quickly |
|
720 max out the limit of computing power with Amazon and mine |
|
721 Bitcoins (under somebody else's account). Fortunately for this |
|
722 guy, Amazon was aware of this scam and in a goodwill gesture |
|
723 refunded him the money the nasty guys incurred over |
|
724 night with their Bitcoin mining. If you want to read the |
|
725 complete story, google for ``My \$2375 Amazon EC2 Mistake''. |
|
726 |
|
727 \subsubsection*{Multi-Signature Transactions} |
|
728 |
|
729 To be explained. |
|
730 |
|
731 \subsubsection*{Anonymity with Bitcoins} |
|
732 |
|
733 One question one often hears is how anonymous is it actually |
|
734 to pay with Bitcoins? Paying with paper money used to be a |
|
735 quite anonymous act (unlike paying with credit cards, for |
|
736 example). But this has changed nowadays: You cannot come to a |
|
737 bank anymore with a suitcase full of money and try to open a |
|
738 bank account. Strict money laundering and taxation laws mean |
|
739 that not even Swiss banks are prepared to take such money and |
|
740 open a bank account. That is why Bitcoins are touted as |
|
741 filling this niche again of anonymous payments. |
|
742 |
|
743 While Bitcoins are intended to be anonymous, the reality is |
|
744 slightly different. I fully agree with the statement by |
|
745 Nielsen from the blog article I referenced at the beginning: |
|
746 |
|
747 \begin{quote}\it{}``Many people claim that Bitcoin can be used |
|
748 anonymously. This claim has led to the formation of |
|
749 marketplaces such as Silk Road (and various successors), which |
|
750 specialize in illegal goods. However, the claim that Bitcoin |
|
751 is anonymous is a myth. The block chain is public, meaning |
|
752 that it’s possible for anyone to see every Bitcoin transaction |
|
753 ever. Although Bitcoin addresses aren't immediately associated |
|
754 to real-world identities, computer scientists have done a |
|
755 great deal of work figuring out how to de-anonymise |
|
756 `anonymous' social networks. The block chain is a marvellous |
|
757 target for these techniques. I will be extremely surprised if |
|
758 the great majority of Bitcoin users are not identified with |
|
759 relatively high confidence and ease in the near future.'' |
|
760 \end{quote} |
|
761 |
|
762 \noindent The only thing I can add to this is that with the Bitcoin |
|
763 blockchain we will in the future have even more pleasure hearing |
|
764 confessions from reputable or not-so-reputable people, like the |
|
765 infamous ``I did not inhale'' from an US |
|
766 president.\footnote{\url{www.youtube.com/watch?v=Bktd_Pi4YJw}} The |
|
767 whole point of the blockchain is that it public and will always be. |
|
768 |
|
769 There are some precautions one can take for boosting anonymity, for |
|
770 example to use a new public-private key pair for every new |
|
771 transaction, and to access Bitcoin only through the Tor network. But |
|
772 the transactions in Bitcoins are designed such that they allow one to |
|
773 combine incoming transactions. In such cases we know they must have |
|
774 been made by the single person who knew the corresponding private |
|
775 keys. So using different public-private keys for each transaction |
|
776 might not actually make the de-anonymisation task much harder. And the |
|
777 point about de-ano\-nymising `anonymous' social networks is that the |
|
778 information is embedded into the structure of the transition |
|
779 graph. And this cannot be erased with Bitcoins. |
|
780 |
|
781 One paper that has fun with spotting transactions made to Silk Road (2.0) |
|
782 and also to Wikileaks is |
|
783 |
|
784 \begin{center} |
|
785 \url{http://people.csail.mit.edu/spillai/data/papers/bitcoin-transaction-graph-analysis.pdf} |
|
786 \end{center} |
|
787 |
|
788 \noindent |
|
789 A paper that gathers some statistical data about the blockchain is |
|
790 |
|
791 \begin{center} |
|
792 \url{https://eprint.iacr.org/2012/584.pdf} |
|
793 \end{center} |
|
794 |
|
795 \subsubsection*{Government Meddling} |
|
796 |
|
797 Finally, what are the options for a typical Western government to |
|
798 meddle with Bitcoins? This is of course one feature the proponents of |
|
799 Bitcoins also tout: namely that there aren't any options. In my |
|
800 opinion this is far too naive and far from the truth. Let us assume |
|
801 some law enforcement agencies would not have been able to uncover the |
|
802 baddies from Silk Road 1.0 and 2.0 (they have done so by uncovering |
|
803 the Tor network, which is an incredible feat on its own). Would the |
|
804 government in question have stopped? I do not think so. The next |
|
805 target would have been Bitcoin. If I were the government, this is |
|
806 what I would consider: |
|
807 |
|
808 \begin{itemize} |
|
809 \item The government could compel ``mayor players'' to blacklist |
|
810 Bitcoins (for example at Bitcoin exchanges, which are usually |
|
811 located somewhere in the vicinity of the government's reach). This |
|
812 would impinge on what is called \emph{fungibility} of Bitcoins and |
|
813 make them much less attractive to baddies. Suddenly their |
|
814 ``hard-earned'' Bitcoin money cannot be spent anymore. The attraction |
|
815 of this option is that this blacklisting can be easily done |
|
816 ``whole-sale'' and therefore be really be an attractive target for |
|
817 governments \& Co. |
|
818 \item The government could attempt to coerce the developer |
|
819 community of the Bitcoin tools. While this might be a |
|
820 bit harder, we know certain governments are ready to |
|
821 take such actions (we have seen this with Lavabit, just |
|
822 that the developers there refused to play ball and shut |
|
823 down their complete operation). |
|
824 \item The government could also put pressure on mining pools |
|
825 in order to blacklist transactions from baddies. Or be a |
|
826 big miner itself. Given the gigantic facilities that |
|
827 are built for institutions like the NSA (pictures from |
|
828 the Utah dessert) |
|
829 |
|
830 \begin{center} |
|
831 \includegraphics[scale=0.04]{../pics/nsautah1.jpg} |
|
832 \hspace{3mm} |
|
833 \includegraphics[scale=0.031]{../pics/nsautah2.jpg} |
|
834 \end{center} |
|
835 |
|
836 this would not be such a high bar to jump over. Remember it |
|
837 ``only'' takes to be temporarily in control of 50\%-plus of the |
|
838 mining capacity in order to undermine the trust in the |
|
839 system. Given sophisticated stories like Stuxnet (where we still |
|
840 do not know the precise details) maybe even such large |
|
841 facilities are not really needed. What happens, for example, if |
|
842 a government starts DoS attacks on existing miners? They have |
|
843 complete control (unfortunately) of all mayor connectivity |
|
844 providers, i.e.~ISPs. |
|
845 |
|
846 There are estimates that the Bitcoin mining capacity |
|
847 outperforms the top 500 supercomputers in the world, |
|
848 combined(!): |
|
849 |
|
850 \begin{center}\small |
|
851 \url{http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/} |
|
852 \end{center} |
|
853 |
|
854 But my gut feeling is that these are too simplistic |
|
855 calculations. In security (and things like Bitcoins) the |
|
856 world is never just black and white. The point is once |
|
857 the trust is undermined, the Bitcoin system would need |
|
858 to be evolved to Bitcoins 2.0. But who says that Bitcoin |
|
859 2.0 will honour the Bitcoins from Version 1.0? |
|
860 \end{itemize} |
|
861 |
|
862 \noindent A government would potentially not really |
|
863 need to follow up with such threads. Just the rumour that it |
|
864 would, could be enough to get the Bitcoin-house-of-cards to |
|
865 tumble. Some governments have already such an ``impressive'' |
|
866 trackrecord in this area, such a thread would be entirely |
|
867 credible. Because of all this, I would not have too much hope |
|
868 that Bitcoins are free from interference by governments \& Co when |
|
869 it will stand in their way, despite what everybody else is |
|
870 saying. To sum up, the technical details behind Bitcoins are |
|
871 simply cool. But still the entire Bitcoin ecosystem is in my |
|
872 humble opinion rather fragile. |
|
873 |
|
874 |
|
875 \subsubsection*{Isn't there anything good with Bitcoins?} |
|
876 |
|
877 As you can see, so far my argument was that yes the Bitcoin system is |
|
878 based on a lot of very cool technical ideas, but otherwise it is a big |
|
879 scam. You might wonder if there is not something good (in terms of |
|
880 valuable for civilisation) in the bitcoin system? I think there is |
|
881 actually: diamonds are quite valuable and because of this can be |
|
882 used as a form of `money'---just remember the song with the line |
|
883 `diamonds are forever'. |
|
884 |
|
885 The problem with diamonds is that in some places where they are found, |
|
886 they also fund some stupid wars. You like to set up a usable system |
|
887 whereby you can check whether a diamond comes from a reputable source |
|
888 (not funding any wars) or from a dodgy source. For this you have to |
|
889 know that `clearing houses' for diamonds can engrave with lasers |
|
890 unique numbers inside the diamonds. These engravings are invisible to |
|
891 the naked eye and as far as I remember these numbers cannot be removed, |
|
892 except by destroying the diamond. Even if it can be removes, diamonds |
|
893 without the number cannot (hopefully) be sold. |
|
894 |
|
895 How do bitcoins come into the picture? The idea is called |
|
896 \emph{coloured coins}, where you attach some additional information to |
|
897 some `coins'. In the diamond example the bitcoin transactions are |
|
898 supposed to act as a certificate where diamonds are from (reputable |
|
899 sources or not). For this you have to know that you can attach a very |
|
900 short custom-made message with each bitcoin transaction. So you would |
|
901 record the diamond number inside the message. |
|
902 |
|
903 Now, you would set the system up so that a trusted entity (which |
|
904 exists in the diamond world) buys with their public key bitcoins (or |
|
905 smaller amounts). These trusted entities are essentially the places |
|
906 that also cut the raw diamonds. The idea is whenever you buy a |
|
907 diamond, you like to have also the corresponding bitcoin |
|
908 transaction. If you want to sell the diamond, you make a transaction |
|
909 to the new owner. The new owner will ask for this message, because |
|
910 otherwise he/she cannot sell it later on. |
|
911 |
|
912 The advantage is that for each diamond you can trace back that the |
|
913 transaction must have originated from the trusted entity. If yes, your |
|
914 diamond will be sellable. If you do not have the message, the diamond |
|
915 comes from a dodgy source and will (hopefully) not be sellable later |
|
916 on. In this way you skew the incentives such that only legitimate |
|
917 diamond are of value. The bitcoin system just helps with being able to |
|
918 check whether the message originates from the trusted entity or |
|
919 not....you do not have to consult anybody else and pay money for this |
|
920 consultation. Or in any way reveal your identity by such a consultation |
|
921 (the police might just keep a particularly close an eye on who contacts |
|
922 such a clearing house). |
|
923 |
|
924 Since we hopefully all agree that funding stupid wars is bad, any |
|
925 system that can starve funds for such wars must be good. Piggy-bagging |
|
926 on the trust established by the bitcoin system on the public block chain |
|
927 makes such a system realisable. |
|
928 |
|
929 \subsubsection*{Further Reading} |
|
930 |
|
931 Finally, finally, the article |
|
932 |
|
933 \begin{center}\small |
|
934 \url{http://www.extremetech.com/extreme/155636-the-bitcoin-network-outperforms-the-top-500-supercomputers-combined} |
|
935 \end{center} |
|
936 |
|
937 \noindent makes an interesting point: If people are willing to |
|
938 solve meaningless puzzles for hard, cold cash and with this |
|
939 achieve rather impressive results, what could we achieve if |
|
940 the UN, say, would find the money and incentivise people to, |
|
941 for example, solve protein folding |
|
942 puzzles?\footnote{\url{http://en.wikipedia.org/wiki/Protein_folding}} |
|
943 For this there are projects like |
|
944 Folding@home.\footnote{\url{http://folding.stanford.edu}} |
|
945 This might help with curing diseases such as Alzheimer or |
|
946 diabetes. The same point is made in the article |
|
947 |
|
948 \begin{center}\small |
|
949 \url{http://gizmodo.com/the-worlds-most-powerful-computer-network-is-being-was-504503726} |
|
950 \end{center} |
|
951 |
|
952 A definitely interesting and worthy use of Bitcoins has been explored |
|
953 in the thesis |
|
954 |
|
955 \begin{center} |
|
956 \url{http://enetium.com/resources/Thesis.pdf} |
|
957 \end{center} |
|
958 |
|
959 \noindent where the author proposes ways of publishing information |
|
960 that is censor-resistant as part of the blockchain. The idea is that |
|
961 if a government wants to use Bitcoins, it would also have to put up |
|
962 with plain-text data that can be included in a transaction. |
|
963 |
|
964 Ken Shirrif in his blog at |
|
965 |
|
966 \begin{center}\small |
|
967 \url{http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html} |
|
968 \end{center} |
|
969 |
|
970 \noindent writes that every day the electricity consumption of mining |
|
971 for bitcoins is roughly 15 Mega Watts---the energy consumption of a country |
|
972 like Cambodia. He writes: |
|
973 |
|
974 \begin{quote} |
|
975 \it{}``The difficulty of mining a block is astounding. At the |
|
976 current difficulty, the chance of a hash succeeding is a bit less |
|
977 than one in $10^{19}$. Finding a successful hash is harder than |
|
978 finding a particular grain of sand from all the grains of sand on |
|
979 Earth. To find a hash every ten minutes, the Bitcoin hash rate needs |
|
980 to be insanely large. Currently, the miners on the Bitcoin network |
|
981 are doing about 25 million gigahashes per second. That is, every |
|
982 second about 25,000,000,000,000,000 blocks gets hashed. I estimate |
|
983 (very roughly) that the total hardware used for Bitcoin mining cost |
|
984 tens of millions of dollars and uses as much power as the country of |
|
985 Cambodia.'' |
|
986 \end{quote} |
|
987 |
|
988 \end{document} |
|
989 |
|
990 bit coin |
|
991 |
|
992 A fistful of bitcoins |
|
993 http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf |
|
994 http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf |
|
995 |
|
996 Ross Anderson & Co (no dispute resolution; co-ercion) |
|
997 http://www.cl.cam.ac.uk/~sjm217/papers/fc14evidence.pdf |
|
998 |
|
999 http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ |
|
1000 http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html |
|
1001 |
|
1002 http://randomwalker.info/bitcoin/ |
|
1003 |
|
1004 Jeffrey Robinson |
|
1005 Bitcon: The Naked Truth about Bitcoin |
|
1006 |
|
1007 The Bitcoin Backbone Protocol: Analysis and Applications |
|
1008 https://eprint.iacr.org/2014/765.pdf |
|
1009 |
|
1010 Bitcoin book |
|
1011 http://chimera.labs.oreilly.com/books/1234000001802/ch04.html#public_key_derivation |
|