So, I'm sure everyone knows lots of ways to make money disappear, so I'm going to show you a new one today, how to make money disappear with hash functions. All right, so the kind of money we're going to be dealing with is actually Bitcoin. So the first thing we're going to figure out is what is a Bitcoin address?

What are all the crazy letters and numbers? Where do they come from? How do we build it? And what terrible things will happen when we screw it up? So, long story short, the easiest way to understand Bitcoin is to think of it as a giant balance sheet. So it's just a bunch of account numbers and a bunch of account balances.

So in Bitcoin, these Bitcoin addresses are the account numbers, and there's this big balance sheet. The only difference between this and a regular balance sheet is that this balance sheet is maintained by an anonymous peer-to-peer network. So that's actually kind of amazing, because there are two problems that seem immediate when you try and do that.

First of all, if you have an anonymous network, how come you can't have anybody spending the money in any account? And as it turns out, you can solve that problem with public key cryptography, that ECDSA is the elliptic curve digital signature algorithm, and the idea of using digital signatures for digital money is actually old, it's from the 80s.

Another problem is what happens when someone spends their money on two things at the same time. And that's actually not an easy problem to solve, and this is the thing that sort of made cryptocurrency a thing, is that Bitcoin is the first cryptocurrency to really effectively solve this problem. So to give you an idea, imagine that there's an account that has $5 in it, and I simultaneously

spend that money on two different things at the same time. Then some nodes in the peer-to-peer network are going to receive one transaction first, and some nodes are going to receive the other first. But there's only $5 to spend, so I can't spend it twice. So how's that conflict resolved? And that's resolved by Bitcoin mining, actually. So when you think of mining, most people think of, oh, that's how you create new

Bitcoins. Actually, that's how you solve the double spending problem. The new coins are just an incentive to get people to do it. So when you first see a Bitcoin address, the first thing you notice is all these crazy letters and numbers. All the digits, capital letters, lowercase letters, there are 62 of them, but I claim this is written in base 58.

In fact, it's a 25-byte string in base 58. Why 58? Well, because four of these, I hope maybe you can't see that at the back, but four of these things are very easy to confuse, the I and uppercase I, lowercase L, and the capital O and the zero. So you remove those, and there are 58 left. And you order them kind of like hex. When you're counting up, you would go one, two, three, four, five, six, seven, eight,

nine, capital A, capital B, to capital Z, and so on. And if you look up how to make a Bitcoin address, you will find a picture like this. And again, in the back, you probably can't see this. That's not important, because there are really three steps in this process, and we already know one. The last step is to turn the results into base 58 and add a checksum.

Okay, so we know about that. The first step in this process is to start with a public key. So now let's think about where does the public key come from? Well, as it turns out, it comes from an elliptic curve. And not just any elliptic curve, this elliptic curve. Of all the elliptic curves in the world, they picked y squared equals x cubed plus seven, which is pretty amazing, because it's so simple.

It seems so simple. So elliptic curves are these amazing mathematical objects. They do lots of crazy stuff. But one thing that's amazing about them is that you can add points on elliptic curves, and you can do all kinds of arithmetic. To add two points, all I do is I draw a line through them, I find where that line intersects

the curve, I flip it around the axis, and that is the result of the addition. And the details aren't that important, but what you should know is that you can do that fast. In fact, with a couple additions and a couple multiplications, you can compute the coordinates of the resulting point from the coordinates of the points you're starting with.

And amazingly enough, that same formula that works to compute the, to do the arithmetic works mod a prime, even though the graph goes totally nuts. So these are just all the whole number points, whole numbers between zero and 70, and plugging them into that equation, and the ones that work, I'm coloring red. And as it turns out, I can still do all the arithmetic, and it'll still work, even

in this crazy, ridiculous graph. So to make a public key that we start from, to make a Bitcoin address, all we gotta do is pick a random 256-bit number, and it's really important that it be random, and then take a point P, and add it to itself that number of times.

So that point will get, we'll call Q. And as it turns out, there's a really fast way to do that. It's, I don't have time to go into it, but it's very, very quick to compute that way. But if you tried to go the other way around, if I gave you Q and P, and I asked you to find S, that is a very difficult problem. That's called the elliptic curve discrete log problem.

And we heard about quantum computers yesterday, and this is one of the problems that quantum computers can actually solve quickly. But regular computers, nobody knows a reasonable way to solve it very fast. Okay, so we've got this setup where, if you're the person who picked S, you can do a computation really fast. If you're not the person who picked S, you don't know the relationship between Q and P.

And so that's the setup for public key cryptography use. S is our secret key, Q is our public key. All right, so, recap. From this elliptic curve, mod sum huge prime, by the way, that's a huge prime, two to the power 256 is one of these numbers that's beyond anyone human's comprehension.

In fact, I think it's about the same as the number of fundamental particles in the universe. So not just atoms like photons, neutrinos, all the crazy ones that blink in and out of existence, ridiculously huge number. We can generate a key pair. And using elliptic curve digital signatures, actually the network can verify that a

transaction originated from the person who picked S. So that's important. So when you generate the Q, you're the one who knows S, nobody else is. You should think of S as the pin number for the Bitcoin account you're going to make using Q. So you need to provide that when you spend money. Very important, you don't need to provide that at any other time.

When you need the secret key is when you spend money. Cool. So now we know where this public key comes from and also why it has X and Y coordinates. The one step that's left in the middle is this little bit. There's RIPEMV160 and SHA256.

These are cryptographic hashes. So the property the cryptographic hashes have is that one direction is super fast and the other direction is super slow. So slow as to be effectively impossible. All right. So if you know an input for the function, you can send it through. No problem.

But if you sent an input through and you remember the output, then you are never, ever, ever going to get the input back like ever. So that has a very strange consequence, actually, because if I just see an address, I can't get the public key back.

So I can't check whether the point I used to make the address is actually a point on the elliptic curve. I could have chosen any point in the world and made an address. So what you're doing in that case, if you make an address from a point that's not on the curve, you're creating an account, but the account has no pin number. And remember, you only need the pin number when you go to spend.

So that means I can send money into an account that nobody will ever be able to spend from, but the money will still go there. So you're basically throwing money into a big black hole. You're throwing money into the void. And it's a very strange feature of Bitcoin that this is possible.

So I wrote some Python code to generate addresses, and I generated some of these ridiculous addresses. And this website, blockchain.info, is kind enough to provide a nice API I can use in my Python code to query how much money has gone into these addresses.

I tried to make a huge list of sort of simple points that weren't on the curve and send those queries. But as it turns out, I call that making a bang-bang con talk. They call that a denial of service attack, I guess, because when I'm throwing millions

of queries at this remote data, I don't know anything about databases, but I was like, oh, this is going to work no problem. No, it doesn't work that way. So that did not go so well. However, as it turns out, most of the money that's been thrown into these addresses has gone into very few. So you can think about if you're writing a program to make Bitcoin addresses and you mess something up, what is the easiest thing to mess up?

Well, you can build an address from the empty string. That kind of makes sense. You forgot to initialize a variable or something. As it turns out, there is almost 32,000 US dollars in that account. And nobody is ever going to get that money. It's gone. It's gone. You can make an address from the point zero zero, which is a point not on the curve.

That one has about 1600 in it. You can also skip right to the end of the address, sorry, of the process, and just convert some simple hex values to base 58, add correct checksums. So I'm not doing any of the, I'm not going through this whole process. I'm just throwing some simple hex strings in for the 20 bytes at the end.

And yeah, a lot more actually. Just all zeros gets a lot of money. A couple of other ones have a whole bunch. And actually people have done silly things with this. Apparently there's a happy birthday message in the history of Bitcoin transactions where someone took a hex string, which when converted to base 58, makes a message like happy

birthday somebody. I wasn't actually able to find it, but apparently that's happened. So after all this, you can think, okay, well, why did we hash the public key in the first place? We could have just used the public key as the address, and then we'd be able to check if it's a real point on the curve and not throw money into the void when we have these bugs with programs. So the pros of the hashing the public key into this address are most important is compression

by far, because you're going from 64 bits, sorry, 64 bytes down to 25. It's a lot smaller. Security you might think, well, what happens when someone breaks the elliptic curve digital signature algorithm? Then you get all the Bitcoins.

Well, sort of, but not quite because the addresses are hashed public keys. You also have to be able to break SHA-256 and go backwards, but that's, that's only kind of, as it turns out, when you spend Bitcoins, you have to provide the public key. So lots of those public keys are already known. So it's like kind of half kind of a security advantage to hash them.

Obviously the con is this massive pile of money, which nobody ever gets. And the fact that as people write Bitcoin software every time, I mean, bugs are never going to go away. So there's always going to be this kind of leak of money in the system. So it's interesting. An interesting thought is Satoshi, the guy who designed Bitcoin, did you ever think

about this? Or is this just an probably an unintended consequence? I wonder, or maybe he actually thought about this and erred on the side of compression. Cool. So moral of the story, design decisions are hard. Unintended consequences are easy. And that's it.

Thank you very much. If you want to know more about elliptic curves and digital signatures, I couldn't fit it in the talk, but come talk to me after.