WEBVTT - Bonus: The Crypto Story by Matt Levine - Part 2 0:00:03.640 --> 0:00:06.720 This is Bloomberg Crypto, a daily Bloomberg I Heard podcast, 0:00:07.120 --> 0:00:10.119 and I'm Stacy Marie Ishmael, Managing editor of Crypto for 0:00:10.160 --> 0:00:28.440 Bloomberg News. Let me cut to the chase. Matt Levine, 0:00:28.520 --> 0:00:30.560 my colleague on the Bloomberg Opinion side of the house, 0:00:31.160 --> 0:00:34.959 is perhaps the greatest finance blogger ever to do it, 0:00:35.560 --> 0:00:37.640 and in what is both a flex and a service, 0:00:37.960 --> 0:00:40.920 He's just written tens of thousands of words on the 0:00:40.960 --> 0:00:44.640 subject of crypto for a special issue of Bloomberg Business Week. 0:00:45.840 --> 0:00:49.200 Matt's gone deep into the blockchain to break down its origins, 0:00:49.400 --> 0:00:52.640 it's possible, futures, and the current state of a technology 0:00:52.680 --> 0:00:55.960 that's showing up everywhere in industries ranging from finance to 0:00:56.040 --> 0:00:59.600 shipping too, of course video games. And we're going to 0:00:59.680 --> 0:01:03.360 be bringing his exploration to you in audio form thanks 0:01:03.360 --> 0:01:06.120 to the talents of Bloomberg editor and professional voice actor 0:01:06.319 --> 0:01:10.080 Mark Ledoff. You'll get weekly chapters of the special Crypto 0:01:10.120 --> 0:01:14.240 issue of Bloomberg Business Week. Welcome to the second chapter 0:01:14.440 --> 0:01:16.920 of the special audio edition of the Bloomberg Business Week 0:01:16.959 --> 0:01:20.640 Crypto issue, written by Matt Levine and narrated by Mark Leadoff. 0:01:21.160 --> 0:01:23.119 Did you miss a chapter? You can find it right 0:01:23.160 --> 0:01:41.560 here in the Bloomberg Crypto podcast feed, section three one 0:01:41.760 --> 0:01:47.559 final diggression the crypto in crypto, cryptography is the study 0:01:47.600 --> 0:01:51.480 of secret messages, of coding and decoding. Most of what 0:01:51.560 --> 0:01:54.280 I talked about in this article won't be about cryptography. 0:01:54.800 --> 0:01:57.680 It will be about you know, pon zis. But the 0:01:57.720 --> 0:02:01.080 base layer of crypto really is about crypt photography, so 0:02:01.120 --> 0:02:03.080 it will be helpful to know a bit about it. 0:02:03.400 --> 0:02:06.120 The basic thing that happens in cryptography is that you 0:02:06.200 --> 0:02:09.160 have an input a number, a word, a string of text, 0:02:09.480 --> 0:02:11.919 and you run some function on it and it produces 0:02:11.919 --> 0:02:14.760 a different number or word or whatever as an output. 0:02:15.240 --> 0:02:18.600 The function might be the Caesar cipher. Shift each letter 0:02:18.639 --> 0:02:20.880 of a word by one or more spots in the alphabet, 0:02:21.160 --> 0:02:25.960 so Caesar becomes dib fits or pig Latin, shift the 0:02:25.960 --> 0:02:28.560 first consonants of the word to the end, and add a, 0:02:29.280 --> 0:02:34.760 so Caesar becomes easier say, or something more complicated. A 0:02:34.880 --> 0:02:39.320 useful property in cryptographic function is that it be one way. 0:02:39.400 --> 0:02:41.800 This means it's easy to turn the input string into 0:02:41.800 --> 0:02:44.639 the output string, but hard to do it in reverse. 0:02:45.200 --> 0:02:47.720 It's easy to compute the function in one direction, but 0:02:47.840 --> 0:02:51.760 impossible in the other. The classic example is that multiplying 0:02:51.800 --> 0:02:55.960 two large prime numbers is quite straightforward, factoring an enormous 0:02:56.040 --> 0:03:00.160 number into two large primes is hard. The Caesars for 0:03:00.360 --> 0:03:03.240 is easy to apply and easy to reverse, but some 0:03:03.400 --> 0:03:06.119 forms of encoding are easy to apply and much more 0:03:06.120 --> 0:03:09.360 difficult to reverse. That makes them better for secret codes. 0:03:09.880 --> 0:03:12.000 What I call a one way function in the text 0:03:12.200 --> 0:03:15.119 is more strictly a function that we hope is one 0:03:15.120 --> 0:03:18.560 way based on current understanding of computer technology and math 0:03:18.639 --> 0:03:22.639 and cryptography. One example of this is a hashing function, 0:03:23.120 --> 0:03:25.440 which takes some input text and turns it into a 0:03:25.480 --> 0:03:28.400 long number of a fixed size. So I could run 0:03:28.400 --> 0:03:31.359 a hashing function on this article. A popular one is 0:03:31.400 --> 0:03:34.600 called shaw to six, which was invented by the National 0:03:34.600 --> 0:03:38.640 Security Agency, and generate a long incomprehensible number from it. 0:03:39.160 --> 0:03:42.000 To make it more incomprehensible, it's customary to write this 0:03:42.080 --> 0:03:44.880 number in hexadecimal so that it will have the digit 0:03:45.000 --> 0:03:48.760 zero through nine, but also a through f. I could 0:03:48.800 --> 0:03:51.320 send you the number, and say I wrote an article 0:03:51.440 --> 0:03:54.280 and rent it through a shaw toft si hashing algorithm, 0:03:54.560 --> 0:03:57.480 and this number was the result. You'd have the number, 0:03:57.640 --> 0:03:59.560 but you wouldn't be able to make heads or tails 0:03:59.600 --> 0:04:02.320 of it. In particular, you couldn't PLoP it into a 0:04:02.360 --> 0:04:05.080 computer program and to code it, turning the hash back 0:04:05.160 --> 0:04:08.360 into this article. If you want to try it for yourself, 0:04:08.520 --> 0:04:12.280 there are various shaw to fifty six calculators online. One 0:04:12.360 --> 0:04:15.480 is at zorbin dot com. Or if you want to 0:04:15.520 --> 0:04:18.600 program it yourself or do some hashing with pencil and paper, 0:04:18.960 --> 0:04:21.960 there is a US government publication f I p s 0:04:22.120 --> 0:04:27.880 pub that spells out the algorithm, or it's on Wikipedia. 0:04:28.160 --> 0:04:31.040 The hashing function is one way. The hash tells you 0:04:31.160 --> 0:04:34.320 nothing about the article, even if you know the hashing function. 0:04:34.880 --> 0:04:37.920 The hashing function basically shuffles the data in the article. 0:04:38.320 --> 0:04:40.919 It takes each letter of the article, represented as a 0:04:40.920 --> 0:04:44.599 binary number, a series of bits zeros and ones, and 0:04:44.600 --> 0:04:47.279 then shuffles around the zeros and ones lots of times, 0:04:47.560 --> 0:04:50.960 mashing them together until they are all jumbled up and unrecognizable. 0:04:51.440 --> 0:04:54.359 The hashing function gives clear, step by step instructions for 0:04:54.400 --> 0:04:56.760 how to shuffle the bits together, but they don't work 0:04:56.760 --> 0:05:01.159 in reverse. It's like stirring cream into coffee. Easy to do, 0:05:01.640 --> 0:05:05.880 hard to undo. Applying a shaw to fifty six algorithm 0:05:05.960 --> 0:05:08.520 will create a sixty four digit number for data of 0:05:08.560 --> 0:05:12.200 any size. You can imagine hash of the entire text 0:05:12.240 --> 0:05:16.640 of James Joyce's seven thirty page novel Ulysses goes three 0:05:16.640 --> 0:05:18.960 F one two zero four two b six d F 0:05:19.000 --> 0:05:24.200 two three by eight or eight night. It fits in 0:05:24.240 --> 0:05:27.080 the same sixty four character space as the hash of 0:05:27.400 --> 0:05:30.960 Hi I'm Matt, which starts with eight six d and 0:05:31.120 --> 0:05:34.400 ends with zero four four. But what if I wrote 0:05:34.720 --> 0:05:38.760 hi I'm Matt with a comma instead of an exclamation mark. 0:05:39.400 --> 0:05:42.000 Then it starts with nine f five and ends with 0:05:42.120 --> 0:05:46.520 fifty eight B. There's no apparent relationship between the numbers 0:05:46.560 --> 0:05:51.040 for Hi I'm Matt and Hi I'm Matt. The two 0:05:51.040 --> 0:05:55.080 original inputs were almost exactly identical, the hash outputs are 0:05:55.120 --> 0:05:58.159 wildly different. This is a critical part of the hashing 0:05:58.200 --> 0:06:02.680 function being one way. If similar inputs mapped to similar outputs, 0:06:02.880 --> 0:06:05.000 then it would be too easy to reverse the function 0:06:05.080 --> 0:06:09.720 and decipher messages. But for practical purposes, each input maps 0:06:09.760 --> 0:06:13.839 to a random output. Since hashes spit out a fixed 0:06:13.920 --> 0:06:17.280 number of digits, it's possible that two different inputs could 0:06:17.320 --> 0:06:20.240 map to the same hash. This is called a collision, 0:06:20.839 --> 0:06:23.880 but a sixty four digit hexadecimal number allows for a 0:06:23.960 --> 0:06:28.360 lot of different hashes. Sixteen to sixty four or about 0:06:28.440 --> 0:06:32.040 ten to the seventy seven of them, or many billion 0:06:32.120 --> 0:06:35.760 times more than the number of atoms on Earth. What's 0:06:35.800 --> 0:06:38.520 the point of a secret code that can't be decoded? 0:06:39.040 --> 0:06:41.600 For one thing, it's a way to verify. If I 0:06:41.640 --> 0:06:44.320 sent you a hash of this article, it wouldn't give 0:06:44.320 --> 0:06:47.479 you the information you need to recreate the article. But 0:06:47.560 --> 0:06:49.919 if I then sent you the article, you could plot 0:06:50.000 --> 0:06:52.920 that into a computer program the show to fifty six 0:06:53.000 --> 0:06:56.400 algorithm and generate a hash, and the hash you generate 0:06:56.440 --> 0:07:00.200 will exactly match the number I sent you, and you'll say, 0:07:00.240 --> 0:07:04.280 ah ha, yes, you hashed that article. All right. It's 0:07:04.320 --> 0:07:07.600 impossible for you to decode the hash, but it's easy 0:07:07.640 --> 0:07:11.480 for you to check that I encoded it correctly. Exercise 0:07:11.560 --> 0:07:14.440 for the reader. I have included some hashes of some 0:07:14.560 --> 0:07:17.320 texts in this article, and I have talked about the 0:07:17.320 --> 0:07:20.600 hash of this article, but I haven't included the hash 0:07:20.640 --> 0:07:24.920 of this article in the article? Why not believe me? 0:07:25.080 --> 0:07:28.440 I wanted to. This would be dumb to do with 0:07:28.480 --> 0:07:31.960 this article, but the principle has uses. A simple everyday 0:07:31.960 --> 0:07:34.800 one is passwords If I have a computer system and 0:07:34.880 --> 0:07:37.240 you have a password to log into the system, I 0:07:37.280 --> 0:07:39.720 need to be able to check that your password is correct. 0:07:40.200 --> 0:07:42.160 One way to do this is for my system to 0:07:42.200 --> 0:07:44.880 store your password and check what you tie up against 0:07:44.920 --> 0:07:47.560 what I've stored. I have a little text file with 0:07:47.600 --> 0:07:50.680 all the passwords, and it has password one two three 0:07:50.800 --> 0:07:53.720 written next to your user name, and you type password 0:07:53.760 --> 0:07:56.440 one two three on the login screen, and my system 0:07:56.560 --> 0:07:58.760 checks what you type against the file and sees that 0:07:58.800 --> 0:08:01.280 they match and lets you log in. But this is 0:08:01.320 --> 0:08:05.120 a dangerous system. If someone steals the file, they would 0:08:05.120 --> 0:08:08.680 have everyone's password. It's better practice for me to hash 0:08:08.760 --> 0:08:12.120 the passwords. You type password one two three as your 0:08:12.120 --> 0:08:14.640 password when setting up the account, and I run it 0:08:14.640 --> 0:08:18.040 through a hash function and get back zero zero eight 0:08:18.080 --> 0:08:20.960 dot dot dot six zero one, and I store that 0:08:21.080 --> 0:08:23.440 on my list. When you try to log in, you 0:08:23.520 --> 0:08:26.120 type your password and I hash it again, and if 0:08:26.160 --> 0:08:28.560 it matches the hash on my list, I let you in. 0:08:29.440 --> 0:08:32.680 If someone steals the list, they can't decode your password 0:08:32.720 --> 0:08:35.920 from the hash, so they can't log into the system. 0:08:35.960 --> 0:08:38.720 It's beyond the scope here, but there's a lot more 0:08:38.720 --> 0:08:44.439 cryptographic fund Rainbow tables salt, etcetera involved in defeating or 0:08:44.520 --> 0:08:49.120 strengthening this type of security. There are other more crypto 0:08:49.200 --> 0:08:53.160 nerdy uses for hashing. One is a sort of time stamping. 0:08:53.679 --> 0:08:56.160 Let's say you predict some future event and you want 0:08:56.200 --> 0:08:58.720 to get credit when it does happen, but you don't 0:08:58.720 --> 0:09:00.680 want to just go on Twitter and now and say 0:09:00.880 --> 0:09:02.960 I predict that the Jets will win the super Bowl 0:09:03.000 --> 0:09:07.600 in to avoid being embarrassed or influencing the outcome, or whatever. 0:09:08.200 --> 0:09:10.800 One thing you could do is right the Jets will 0:09:10.840 --> 0:09:14.040 win the super Bowl in four on a piece of paper, 0:09:14.480 --> 0:09:17.320 put it in an envelope, Seal the envelope, and ask 0:09:17.400 --> 0:09:20.400 me to keep it until the super Bowl, after which 0:09:20.440 --> 0:09:22.720 you'll tell me either to open the envelope or burn it. 0:09:23.200 --> 0:09:25.840 But this requires you and everyone else to trust me. 0:09:26.800 --> 0:09:29.760 Another trustless thing you could do is type the Jets 0:09:29.760 --> 0:09:33.319 will win the super Bowl in four into a cryptographic 0:09:33.360 --> 0:09:36.240 hash generator, and it will spit out six four b 0:09:36.679 --> 0:09:39.400 dot dot dot eight four seven, and then you can 0:09:39.400 --> 0:09:42.680 tweet here is a shot to fifty six hash of 0:09:42.679 --> 0:09:45.719 a prediction. I am making six four b dot dot 0:09:45.760 --> 0:09:50.840 dot eight four seven. Everyone will say, well, aren't you annoying? 0:09:51.360 --> 0:09:54.120 But they won't be able to decode your prediction, and 0:09:54.160 --> 0:09:56.480 then in a while, when the Jets win the Super Bowl, 0:09:56.600 --> 0:10:00.120 you can say, see I called it. You retweet the 0:10:00.120 --> 0:10:02.920 hashed tweet and the plain text of your prediction. If 0:10:02.960 --> 0:10:05.200 anyone is so inclined, they can go to a hash 0:10:05.280 --> 0:10:08.320 calculator and check that the hash really matches your prediction. 0:10:08.840 --> 0:10:13.240 Then all the glory will accrue to you. Aside from hashing, 0:10:13.400 --> 0:10:17.600 another important one way function is public key encryption. I 0:10:17.720 --> 0:10:21.800 have two numbers called a public key and a private key. 0:10:21.920 --> 0:10:24.920 These numbers are long and random looking, but they're related 0:10:24.960 --> 0:10:28.760 to each other using a publicly available algorithm. One number 0:10:28.760 --> 0:10:30.960 can be used to lock a message and the other 0:10:31.040 --> 0:10:34.440 can unlock it. The two key system solves a classic 0:10:34.480 --> 0:10:37.440 problem with codes. If the key I used to encrypt 0:10:37.440 --> 0:10:39.160 a message is the same one, you will need to 0:10:39.200 --> 0:10:41.920 decode it. At some point. I'll have to have sent 0:10:42.000 --> 0:10:45.120 you that key. Anyone who steals the key in transit 0:10:45.280 --> 0:10:49.439 can read our messages. With public key encryption, no one 0:10:49.520 --> 0:10:52.959 needs to share the secret key. The public key is public, 0:10:53.320 --> 0:10:55.360 I can send it to everyone posted on my Twitter 0:10:55.400 --> 0:10:58.920 feed whatever. The private key is private, and I don't 0:10:58.920 --> 0:11:01.160 give it to anyone you want to send me a 0:11:01.200 --> 0:11:03.760 secret message. You write the message and run it through 0:11:03.760 --> 0:11:07.520 the encryption algorithm which uses one the message and to 0:11:08.000 --> 0:11:11.400 my public key, which you have to generate an encrypted 0:11:11.440 --> 0:11:13.920 message that you send to me. Then I run the 0:11:13.920 --> 0:11:17.320 message through a decryption program that uses one the encrypted 0:11:17.360 --> 0:11:21.240 message and to my private key, which only I have 0:11:21.720 --> 0:11:25.560 to generate the original message, which I can read. You 0:11:25.600 --> 0:11:29.000 can encrypt the message using my public key, but nobody 0:11:29.040 --> 0:11:32.079 can decrypt it using the public key. Only I can 0:11:32.120 --> 0:11:35.360 decrypt it using my private key. The function is one 0:11:35.360 --> 0:11:38.040 way as far as you're concerned, but I can reverse 0:11:38.080 --> 0:11:41.160 it with my private key. A related idea is a 0:11:41.200 --> 0:11:44.720 digital signature. Again, I have a public key and a 0:11:44.760 --> 0:11:48.240 private key. My public key is posted in my Twitter bio. 0:11:48.679 --> 0:11:50.560 I want to send you a message, and I want 0:11:50.600 --> 0:11:52.720 you to know that I wrote it. I run the 0:11:52.760 --> 0:11:56.160 message through an encryption program that uses one the message 0:11:56.280 --> 0:11:59.800 and to my private key. Then I send you one 0:12:00.120 --> 0:12:04.360 the original message and to the encrypted message. You use 0:12:04.360 --> 0:12:07.720 a decryption program that uses one the encrypted message and 0:12:07.800 --> 0:12:11.600 to my public key to decrypt the message. The decrypted 0:12:11.600 --> 0:12:15.040 message matches the original message. This proves to you that 0:12:15.120 --> 0:12:18.000 I encrypted the message, so you know that I wrote it. 0:12:18.600 --> 0:12:20.840 I could have just sent you a Twitter d M instead, 0:12:21.160 --> 0:12:25.560 but this is more cryptographic. Imagine a simple banking system 0:12:25.640 --> 0:12:28.680 in which bank accounts are public. There's a public list 0:12:28.679 --> 0:12:31.520 of accounts, and each one has a public balance and 0:12:31.559 --> 0:12:35.000 a public key. I say to you, I control account 0:12:35.080 --> 0:12:37.560 number zero zero, one, two, three, four, five, six, seven, 0:12:37.640 --> 0:12:40.520 eight nine, which has two fifty dollars in it, and 0:12:40.559 --> 0:12:43.280 I'm going to send you fifty dollars. I send you 0:12:43.320 --> 0:12:46.880 a digitally signed message saying here's fifty dollars, and you 0:12:46.960 --> 0:12:49.640 decode that message using the public key for the account, 0:12:49.960 --> 0:12:52.000 and then you know that I do, in fact control 0:12:52.040 --> 0:12:55.880 that account, and everything checks out. That's the basic idea 0:12:55.920 --> 0:12:59.000 at the heart of bitcoin, though there are also more 0:12:59.200 --> 0:13:02.959 complicated I d is. We'll be right back with more 0:13:03.000 --> 0:13:06.120 from Bloomberg Business Week Special Crypto issue, written by Matt 0:13:06.200 --> 0:13:20.960 Levine a narrated by Mark Ledorff. Section four. Now back 0:13:21.000 --> 0:13:24.720 to bitcoin. How does it work? The simple form of 0:13:24.720 --> 0:13:28.199 bitcoin goes like this. There's a big public list of addresses, 0:13:28.480 --> 0:13:31.080 each with a unique label that looks like random numbers 0:13:31.080 --> 0:13:34.080 and letters and some balance of bitcoin in it. An 0:13:34.080 --> 0:13:37.240 address might have the label one A, one Z P, 0:13:37.480 --> 0:13:39.960 one e f F two, the mpt f L five 0:13:40.840 --> 0:13:43.680 f n A and a balance of sixty eight point 0:13:43.720 --> 0:13:47.200 six bitcoin. By the way, that address one A one 0:13:47.240 --> 0:13:50.240 dot dot dot f n A is famous in crypto lore. 0:13:50.640 --> 0:13:54.400 It's the address that received the first bitcoin. Presumably it 0:13:54.480 --> 0:13:59.839 belongs to Satoshi Nakamoto. The address acts as a public key. 0:14:00.080 --> 0:14:03.160 Actually it's a hash of the public key, but it 0:14:03.320 --> 0:14:06.840 is in fact perfectly legitimate cryptographic terminology to refer to 0:14:06.880 --> 0:14:10.400 the pub key hash as a public key itself, wrote 0:14:10.440 --> 0:14:15.960 Metallic Bitterran, creator of Ethereum, another major blockchain, in white paper, 0:14:16.040 --> 0:14:19.720 explaining that project good enough for Vitalic, good enough for 0:14:19.800 --> 0:14:24.040 me if I own those bitcoin. What that means is 0:14:24.080 --> 0:14:27.600 I possess the private key corresponding to that address, effectively 0:14:27.640 --> 0:14:31.760 the password accessing the account. Because I have the private key, 0:14:31.880 --> 0:14:33.880 I can send you a bitcoin by signing a message 0:14:33.920 --> 0:14:36.560 to you with my private key. You can check that 0:14:36.640 --> 0:14:39.600 signature against my public key and against the public list 0:14:39.640 --> 0:14:43.320 of addresses and bitcoin balances. That information is enough for 0:14:43.360 --> 0:14:45.640 you to confirm that I control the bitcoin that I'm 0:14:45.680 --> 0:14:48.240 sending you, but not enough for you to figure out 0:14:48.240 --> 0:14:51.040 my private key and steal the rest of my bitcoin. 0:14:52.240 --> 0:14:54.600 That kind of means I can send you a bitcoin 0:14:54.680 --> 0:14:58.640 without you trusting me, or me trusting you, or either 0:14:58.720 --> 0:15:00.760 of us trusting a bank to verify that I have 0:15:00.800 --> 0:15:04.120 the money. We define an electronic coin as a chain 0:15:04.160 --> 0:15:08.080 of digital signatures, so Toshi wrote, the combination of public 0:15:08.080 --> 0:15:11.040 address and private key is enough to define a coin. 0:15:11.640 --> 0:15:17.440 Cryptocurrency is called cryptocurrency because it's a currency derived from cryptography. 0:15:17.960 --> 0:15:20.040 You'll notice that all we've done here is exchange a 0:15:20.080 --> 0:15:23.520 message and somehow called the result of that a currency. 0:15:23.840 --> 0:15:27.560 The traditional financial system isn't so different. Banks don't move 0:15:27.600 --> 0:15:30.800 around sacks of gold or even very many paper bills. 0:15:30.840 --> 0:15:35.120 They're keepers of databases. What happens, roughly when I make 0:15:35.160 --> 0:15:37.760 a hundred dollar payment to you is my bank sends 0:15:37.760 --> 0:15:41.720 a message to your bank telling it to update its ledger. Similarly, 0:15:41.960 --> 0:15:45.520 in bitcoin, the messages change a public ledger of who 0:15:45.520 --> 0:15:49.920 holds what, but who maintains that. The rough answer is 0:15:49.960 --> 0:15:53.360 that the Bitcoin network, thousands of people who use bitcoin 0:15:53.440 --> 0:15:56.320 and run it software on their computers, keeps the ledger 0:15:56.640 --> 0:16:01.200 collaboratively and redundantly. There are thousands of copies of the ledger. 0:16:01.520 --> 0:16:03.680 Every note on the network has its own list of 0:16:03.720 --> 0:16:07.200 how many bitcoin are in each address. Then when we 0:16:07.280 --> 0:16:10.120 do a transaction, when I send you a bitcoin, we 0:16:10.200 --> 0:16:13.200 don't just do it privately. We broadcast it to the 0:16:13.400 --> 0:16:16.800 entire network, so everyone can update their lists. If I 0:16:16.840 --> 0:16:19.520 send you a bitcoin from my address and my signature 0:16:19.520 --> 0:16:22.720 on the transaction is valid, everyone will update their ledgers 0:16:22.760 --> 0:16:25.560 to add one bitcoin to your address and subtract one 0:16:25.640 --> 0:16:28.720 from mine. The ledger is not really just a list 0:16:28.800 --> 0:16:32.160 of addresses and their balances. It's actually a record of 0:16:32.320 --> 0:16:37.360 every single transaction. Actually it's only that, not a list 0:16:37.400 --> 0:16:40.160 of addresses and their balances at all. I describe it 0:16:40.200 --> 0:16:42.880 that way in the text for convenience, and you can 0:16:42.920 --> 0:16:45.560 reconstruct the list of addresses and balances from the record 0:16:45.560 --> 0:16:49.640 of all transactions, and people do. But that's not technically 0:16:49.680 --> 0:16:53.120 what a bitcoin's ledger is. The ledger is maintained by 0:16:53.160 --> 0:16:56.840 everyone on the network, keeping track of every transaction for themselves. 0:16:57.440 --> 0:17:00.680 There's a section in the Bitcoin white paper titled Reclaiming 0:17:00.760 --> 0:17:04.000 disk Space about how the network can in effect compress 0:17:04.080 --> 0:17:06.560 some of the data it keeps about old transactions using 0:17:06.720 --> 0:17:09.879 Merkel trees, all of which is beyond the scope of 0:17:09.880 --> 0:17:14.119 this piece. But people in crypto say Merkel trees a lot. 0:17:14.600 --> 0:17:18.080 So there you go. All of that's nice, but now 0:17:18.160 --> 0:17:20.280 instead of trusting a bank to keep the ledger of 0:17:20.320 --> 0:17:24.399 your money, you're trusting thousands of anonymous strangers. What if 0:17:24.440 --> 0:17:28.160 we accomplished Well, it's not quite as bad as that 0:17:28.760 --> 0:17:32.600 each transaction is provably correct. If I send a bitcoin 0:17:32.680 --> 0:17:34.840 from my address to yours and sign it with my 0:17:34.960 --> 0:17:38.919 private key, the network will include the transaction. If I 0:17:38.960 --> 0:17:41.399 try to send a bitcoin from someone else's addressed to 0:17:41.440 --> 0:17:44.440 yours and don't have the private key, everyone on the 0:17:44.480 --> 0:17:47.600 network can see that it's fake and won't include the transaction. 0:17:48.320 --> 0:17:51.359 Everyone runs open source software to update the ledger for 0:17:51.400 --> 0:17:55.760 transactions that are verifiable. Everyone keeps the ledger, but you 0:17:55.840 --> 0:17:58.240 can prove that every transaction in the ledger is valid, 0:17:58.440 --> 0:18:01.560 so you don't have to trust them too much much. Incidentally, 0:18:01.640 --> 0:18:04.719 I am saying that everyone keeps the ledger, and that 0:18:04.800 --> 0:18:08.679 was probably roughly true in early bitcoin's life, but no longer. 0:18:09.119 --> 0:18:12.640 There are thousands of people running full nodes which download 0:18:12.680 --> 0:18:16.560 and maintain and verify the entire Bitcoin ledger themselves using 0:18:16.600 --> 0:18:20.520 open source official bitcoin software, but there are millions more 0:18:20.720 --> 0:18:23.840 not doing that, just having some bitcoin and trusting that 0:18:23.880 --> 0:18:27.520 everybody else will maintain the system correctly. Their basis for 0:18:27.600 --> 0:18:30.639 this trust, though, is slightly different from the basis for 0:18:30.680 --> 0:18:34.760 your trust in your bank. They could, in principle verify 0:18:34.880 --> 0:18:40.320 that everyone verifying the transactions is verifying them correctly. Philosophically, 0:18:40.440 --> 0:18:43.399 they're part of a trustless system, so they can feel 0:18:43.400 --> 0:18:46.920 a bit better about trusting it. Notice too, that there's 0:18:46.920 --> 0:18:50.439 a financial incentive for everyone to be honest. If everyone 0:18:50.560 --> 0:18:52.919 is honest, then this is a working payment system that 0:18:53.000 --> 0:18:56.119 might be valuable. If lots of people are dishonest and 0:18:56.200 --> 0:18:59.120 put fake transactions in their ledgers, then no one will 0:18:59.160 --> 0:19:02.120 trust bitcoin and it will be worthless. What's the point 0:19:02.160 --> 0:19:05.320 of stealing bitcoin if the value of bitcoin is zero. 0:19:05.840 --> 0:19:09.399 This is a standard approach in crypto cryptosystems try to 0:19:09.480 --> 0:19:12.920 use economic incentives to make people act honestly, rather than 0:19:12.960 --> 0:19:16.240 trusting them to act honestly. That's most of the story, 0:19:16.600 --> 0:19:19.439 but it leaves some small problems. Where did all the 0:19:19.440 --> 0:19:22.760 bitcoin come from? It's fine to say that everyone on 0:19:22.800 --> 0:19:25.520 the network keeps a ledger of every bitcoin transaction that 0:19:25.560 --> 0:19:28.320 ever happened, and your bitcoin can be traced back through 0:19:28.320 --> 0:19:32.080 a series of previous transactions, but traced back to what 0:19:32.920 --> 0:19:36.080 how do you start the ledger. Another problem is that 0:19:36.160 --> 0:19:39.840 the order of transactions matters. If I have one bitcoin 0:19:39.880 --> 0:19:41.960 in my account and I send it to you, and 0:19:42.000 --> 0:19:44.800 then I send it to someone else who actually has 0:19:44.840 --> 0:19:49.360 the bitcoin. This seems almost trivial, but it's tricky. Bitcoin 0:19:49.520 --> 0:19:53.399 is a decentralized network that works by broadcasting transactions to 0:19:53.520 --> 0:19:57.119 thousands of nodes, and there's no guarantee they'll all arrive 0:19:57.200 --> 0:20:00.639 in the same order everywhere, and if everyone doesn't agree 0:20:00.640 --> 0:20:04.679 on the order, bad things double spending or people sending 0:20:04.680 --> 0:20:09.080 the same bitcoin to two different places can happen. Transactions 0:20:09.119 --> 0:20:12.320 must be publicly announced road Satoshi, and we need a 0:20:12.359 --> 0:20:15.080 system for participants to agree on a single history of 0:20:15.119 --> 0:20:18.640 the order in which they were received. That system, I'm 0:20:18.680 --> 0:20:23.000 sorry to say, is the blockchain. Coming up next, you'll 0:20:23.000 --> 0:20:26.280 hear more from Matt Levine's special Crypto issue of Bloomberg 0:20:26.280 --> 0:20:40.480 Business Week, narrated by Mark Leadoff, Section five oh the blockchain. 0:20:41.760 --> 0:20:46.280 Every Bitcoin transaction is broadcast to the network. Some computers 0:20:46.280 --> 0:20:50.040 on the network they're called miners, compile the transactions as 0:20:50.040 --> 0:20:53.160 they arrive into a group called a block. At some point, 0:20:53.240 --> 0:20:55.800 a version of a block becomes as it were official, 0:20:56.320 --> 0:20:58.960 the list of transactions in that block, in the order 0:20:58.960 --> 0:21:02.440 in which they're listed, becomes canonical part of the official 0:21:02.520 --> 0:21:07.160 bitcoin record. We say that the block has been mined. Actually, 0:21:07.200 --> 0:21:10.920 a block becomes really canonical when it has five confirmations, 0:21:11.280 --> 0:21:13.600 when it has been mined, and then another block has 0:21:13.600 --> 0:21:16.040 been mined that refers back to it, and then another 0:21:16.040 --> 0:21:18.639 block has been mined referring to that block, et cetera, 0:21:18.960 --> 0:21:22.560 five times, so that the chain has continued five blocks 0:21:22.600 --> 0:21:26.520 after the block in question. In bitcoin, a new block 0:21:26.600 --> 0:21:29.520 is mined roughly every ten minutes. You can see a 0:21:29.520 --> 0:21:34.040 finished block online on any block explorer site. For example, 0:21:34.240 --> 0:21:38.480 block seven five nine six five mined on September is 0:21:38.480 --> 0:21:41.960 basically a list of two d and sixty six transactions 0:21:42.000 --> 0:21:46.040 between different addresses. An address starting BC one q and 0:21:46.240 --> 0:21:48.919 S sent point zero zero five to bitcoin to an 0:21:48.920 --> 0:21:53.040 address starting sixteen q z C seven thirty nine v 0:21:53.160 --> 0:21:56.439 g g L split point zero one two bitcoin between 0:21:56.720 --> 0:21:59.720 one four in r d K and thirty seven oh 0:22:00.040 --> 0:22:04.240 one E three, and so on. The miners then start 0:22:04.359 --> 0:22:07.600 compiling a new block, which will also eventually be mined 0:22:07.640 --> 0:22:11.960 and become official. Here's where hashing becomes important. That new 0:22:12.000 --> 0:22:14.680 block will refer to the block before it by containing 0:22:14.680 --> 0:22:17.680 a hash of that block. This confirms that the block 0:22:17.760 --> 0:22:20.840 before it one is correct and accepted by the network, 0:22:20.880 --> 0:22:25.160 and two came before it. In time, each block will 0:22:25.200 --> 0:22:28.440 refer to the previous block in a chain. Oh, yes, 0:22:28.920 --> 0:22:32.879 a block chain. The blockchain creates an official record of 0:22:32.920 --> 0:22:35.640 what transactions the network has agreed on and in what order. 0:22:36.160 --> 0:22:39.600 The hashes are time stamps, they create an agreed order 0:22:39.600 --> 0:22:43.600 of transactions. You could imagine a simple system for doing this. 0:22:44.200 --> 0:22:47.120 Every ten minutes, a minor proposes a list of transactions 0:22:47.320 --> 0:22:49.760 and all the computers on the Bitcoin network vote on it. 0:22:50.240 --> 0:22:52.639 If it gets a majority, it becomes official and is 0:22:52.720 --> 0:22:56.919 entered into the blockchain. Unfortunately, this is a bit too simple. 0:22:57.400 --> 0:23:00.119 There are no rules about who can join the Bitcoin network. 0:23:00.480 --> 0:23:02.800 Anyone who hooks up a computer and runs the open 0:23:02.800 --> 0:23:05.600 source Bitcoin software can do it. You don't have to 0:23:05.640 --> 0:23:08.919 prove you're a good person or even a person. You 0:23:08.960 --> 0:23:12.080 can hook up a thousand computers if you want. This 0:23:12.160 --> 0:23:15.240 creates a risk of what's sometimes called a Sibyl attack, 0:23:15.800 --> 0:23:19.120 named not after the ancient Greek prophetesses, but rather after 0:23:19.160 --> 0:23:21.680 the ninety three book about a woman who claimed to 0:23:21.720 --> 0:23:25.639 have multiple personalities. The idea of a cibil attack is 0:23:25.680 --> 0:23:28.639 that in a system where the ledger is collectively maintained 0:23:28.680 --> 0:23:31.680 by the group, and anyone can join the group without permission, 0:23:32.080 --> 0:23:34.199 you can spin up a bunch of computer nodes so 0:23:34.200 --> 0:23:37.720 that you look like thousands of people. Then you verify 0:23:37.840 --> 0:23:41.320