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