Episode 88: Hashcash and Bit Gold

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost Yo, yo.

Aaron van Wirdum Are you going to do the jingle again?

Sjors Provoost I am not, but I know now that you are the best ad reader, so please read the ad.

Aaron van Wirdum Dear listener, are you looking for a hardware wallet? Well, you're in luck, because our sponsor, Coinkite, produces hardware wallets. They're called the COLDCARD. They also have all kinds of other hardware stuff. Sjors, do you know what else they have? They have the OPENDIME. They have the BLOCKCLOCK, I think, right?

Sjors Provoost SATSCARD.

Aaron van Wirdum SATSCARD. They got everything you need. What a coincidence. That's our sponsor, Coinkite. All right, Sjors. That was my read. Hey, that's an improvement compared to last week, I think.

Sjors Provoost Yeah, probably.

Aaron van Wirdum What do you think? We're getting there.

Sjors Provoost So, Aaron, you wrote a book.

Aaron van Wirdum Yeah. Oh, yes, I did.

Sjors Provoost Cool.

Aaron van Wirdum Well, at the time of recording, it's almost published. So we're publishing it tomorrow, January 3rd. But that's like midnight actually UTC. So it's like our, it's one our time. So in a couple of hours, my book will be live. Yeah. So that's kind of cool. It is called the Genesis Book, Sjors, and it tells the, the prehistory of Bitcoin, the origin story of Bitcoin. It's the story of the people and projects that inspired Bitcoin. So Sjors, to celebrate that, we're going to discuss some of the topics from my book.

Sjors Provoost That's right.

Aaron van Wirdum So it's actually kind of for the first time, I think, not really an episode about Bitcoin. Have we done something about...

Sjors Provoost Well, we've done an episode about DigiCash.

Aaron van Wirdum Well, hang on. We also did the episode about the Tornado Cash. That was actually not about Bitcoin, kind of.

Sjors Provoost Exactly.

Aaron van Wirdum Anyways.

Sjors Provoost And we'll still cover things that are very relevant to Bitcoin.

Aaron van Wirdum Right. Well, my entire book is very relevant to Bitcoin. Everything in my book is relevant to Bitcoin. So, of course, also what we're going to discuss.

Sjors Provoost Excellent.

Aaron van Wirdum Did I mention it's called the Genesis Book? And you can find it on the Bitcoin magazine store and Amazon and I don't know where else.

Sjors Provoost Sounds good.

Aaron van Wirdum I think thegenesisbook.com should be live by the time you listen to this, hopefully.

Sjors Provoost All right.

Aaron van Wirdum You want to know anything more about where you can find my book, Sjors?

Sjors Provoost No, we will put it in the show notes.

Aaron van Wirdum Okay, we'll go to the episode then. So yeah, we're going to discuss. So, okay. I discuss in my book, there are sort of five main digital cash projects that sort of precursors to Bitcoin in a way. There are more and there's also, there's a lot more in the book, Sjors. There's all kinds of background and stories and colors and...

Sjors Provoost Yeah, from the parts I've read, you...

Aaron van Wirdum Adventures and...

Sjors Provoost Yeah, from what I've been reading, you cover Austrian economic stories and sort of alternate the digital money story versus the political story.

Aaron van Wirdum Anyway, enough with the shilling. Let's get to the actual episode. So there's five electronic cash projects in the book that sort of have a bigger focus than some of the more minor ones. So the first one of that is eCash, which was produced by DigiCash. We're not going to talk about that because we kind of already did in episode 52, which was about, what was it about? Fedimint, right?

Sjors Provoost Yeah, in episode 52 of Fedimint, we start all the way back with how David Chaum's eCash works, how blinded signatures work. Definitely recommended listening. And then we go all the way to how that's now applied to, well. Fedimints and Cashu.

Aaron van Wirdum We're going to skip that one. We're not going to talk about that again. Instead, this episode will be about Hashcash and bit gold. I think this will be sort of... I don't know how we're going to do this format because usually I'm kind of the one who asks questions. We just still do that. I don't know. We'll figure it out, I think. Actually, I have no idea how to do this now.

Sjors Provoost Well, you should tell a little bit of the story, and then we'll get to some of the technical juicy bits.

Aaron van Wirdum Yeah, that works.

Sjors Provoost Where I might have some opinions, too.

Aaron van Wirdum Okay, cool, yeah. So the first one is Hashcash. So the background here is... So in the 90s, the internet was becoming more popular, and also there was the Cypherpunks mailing list. And they had... First of all, they had their own mailing list where they were discussing... privacy technologies, but also more ideological types of posts or how to create digital cash, of course, and all these kinds of discussions. And they were also, a bunch of the cypherpunks were running remailers. So this was sort of the precursor of Tor. So it was a way to send an email anonymously, send an email without the recipients knowing where the email came from. The problem was that spam was becoming popular around this time as well. the Cypherpunk mailing list itself was being spammed. Anyone else who had an email address was being spammed. And especially also these remails or remailers were starting to be spammed to the extent that it was becoming burdensome to run one. So it was potentially an attack on these remailers. Either it was a spam attack that remailers were being abused for, or maybe it was just an attack on the remailers themselves as sort of a denial of service type of situation. So people wanted to create, Cypherpunks specifically wanted to create digital cash.

Sjors Provoost And I think, well, one step back, I think they also, they wanted to fix the spam problem, right? With digital cash maybe in the back of their mind.

Aaron van Wirdum Sorry, I said digital cash. I meant digital postage. And that's what you're getting.

Sjors Provoost Yes, digital postage stamps. But it might be interesting, something you also mentioned in the book. is that there was a worry that if the cypherpunks didn't fix this problem, then governments would step in and they would start dealing with spam. And this would be a problem because then you would get... If governments have to fight spam, then the way they would probably do that is by de-anonymizing everyone and basically KYC-ing email to the extent of where if there's a spammer, they know who they are.

Aaron van Wirdum Yeah, plus the government would then have to make a judgment call about what is spam and what kind of relevant to Bitcoin these days, actually, with the whole ordinal thing. But yeah, then governments have to make a judgment call about what is spam. So what actually is legal. And then by the time they can find a spammer, yeah, there would have to be some sort of identification.

Sjors Provoost And they would have to ban anonymous email, which is, you know, the kind of thing they were trying to do.

Aaron van Wirdum Right. So the cypherpunks didn't like this. And specifically, Adam Back didn't like this. Adam Back was, of course, one of these cypherpunks. I don't think he needs an introduction to anyone who listens to this podcast. So Adam Back wanted to come up with digital postage. Maybe should I...

Sjors Provoost First, I think we should go back in time, right? Because everybody talks about Hashcash and how Adam Back invented that, and he did. But it was not the first time it was invented, as often happens in history.

Aaron van Wirdum Yeah, I was also considering if I should talk about the other ways they were thinking about digital postage. But I think we should skip that, right? That's what you can find in the book.

Sjors Provoost Exactly.

Aaron van Wirdum Okay, so yeah. Okay, so shall I hand it to you here? Because yes. So actually, Adam Back was not the first person to invent digital postage. He did think he was, like he was not aware of the previous proposal, but there was actually another proposal that's a bit older and quite similar to Adam Back's proposal, which was the names from the top of my head.

Sjors Provoost Dwork and Naor.

Aaron van Wirdum Yeah, I was thinking of the first name, but yeah, their last names were definitely Dwork and Naor. Moni Naor and Cynthia Dwork I think

Sjors Provoost yeah and they did not come from it from a cypherpunk background they came from it with a just hey we are people using email and we don't like spam background right and so

Aaron van Wirdum well they were for IBM right they were

Sjors Provoost Yeah, they weren't random people, but they were not saying, how can we prevent the government coming into this email world? It's just like, how do we get rid of spam? And so they invented, essentially they came up with the idea of introducing proof of work for email, and they came up with three different... work algorithms yeah

Aaron van Wirdum and to be clear the term proof of work didn't exist yet at this time

Sjors Provoost I don't know exactly what they call it but something along the lines of like a challenge or but basically they picked three algorithms and I think one of them boiled down to finding If you take a number and you want to figure out which two primes are necessary, can be multiplied to get to the number. So let's say you pick the number 100 and you say, tell me which two prime numbers multiply to 100. And you would say, I don't know, because it's 10 times 10. So that's not, those are not prime.

Aaron van Wirdum Kind of a bad example.

Sjors Provoost No, it's a fine example, but it shows that as soon as you give me the right answer, I can very quickly verify that yes, these two numbers multiply. to this total. Actually, I think you didn't have to find prime numbers. It's just modulo prime number.

Aaron van Wirdum I think the way it works is you have two very big prime numbers. These are factored into another big number. And then the big number is, it can only be produced by two specific prime numbers then, right?

Sjors Provoost I think that's what, that's RSA.

Aaron van Wirdum Yes.

Sjors Provoost But not what this concept. I think this was much simpler. This was something called modulo prime number. So if you take a much smaller number, we know the number 13 is prime, right? And so you would say, okay, here's the number 10. Find me two numbers that you can multiply to get the number 10, but you can multiply and then you do modulo 13. So you can say, this is not very good in math, but if you do 3 times 4, that's 12, so that's not enough. If you do 3 times 5, that's 15, modulo 13 is 2, right? So you can do etc. etc. You keep looking for this number that if you go around in circles around this prime number gets you the correct result.

Aaron van Wirdum Okay, we're getting very into the weeds now. Let's get back to the main road. So they had three ideas.

Sjors Provoost Exactly. So this is one of them. And the key part is that it takes a while to find these numbers, but it's very quick to check. You just multiply modulo and you're done. And they had two other algorithms that I don't want to go into also because I don't know them, but they had an interesting property from them is that you could build an exception into it. So basically saying, well, if you're the mailing list operator, then you can use this special key and you can bypass the work. I don't know whether that would be practical or not, but that's sort of what they came up with.

Aaron van Wirdum Right, the backdoor function.

Sjors Provoost Yeah.

Aaron van Wirdum The points being here, though, so was Naor and Dwork also, the idea they came up with is that whatever calculation you have to make, you have to make it in combination with some data from the email itself.

Sjors Provoost Yes, because you can prove that you did a bunch of work, but if that's unrelated to your email, you would just reuse the same work. So you have to make sure that the work is always a function of the email itself. And ironically, they discovered the use of hash functions for that, or they knew that you needed hash functions for that part. So you take the hash of the email, and then you use the hash as the starting point of your challenge.

Aaron van Wirdum Oh, they did use the hash for that part?

Sjors Provoost Yeah.

Aaron van Wirdum Oh, I didn't know that. That's interesting. Because we should maybe spell this out for those who haven't realized this. So Naor and Dwork were not using hashes for the proof of work. They were using, what's it called? Is there a better term for what they were?

Sjors Provoost They were just using math problems.

Aaron van Wirdum Right. Now the idea was still very similar to, I mean, I think most people that listen sort of know where proof of work came from. That's why we're sort of skipping some parts maybe, but we should actually spell it out. So the idea was, If you attach a little bit of proof of work to an email, then most people that want to send an email, that's not really a problem. That's like a couple of seconds of computing time. However, if you're a spammer that wants to send tens of thousands or maybe even millions of emails, which you usually have to do to be a profitable spammer, then it becomes so expensive that it's not worth it anymore. So that's how it's posted. So it's different in postage in the sense that... You're not buying it from anyone. And also whoever you're sending the email to is not getting the money or anything like that. It's just you're proving that you spend some resources, some energy, and that way it's too expensive for a spammer to be a spammer.

Sjors Provoost Yes, exactly.

Aaron van Wirdum Okay, so that's what Naor and Dwork essentially came up with. This was in 1992. But then independently, basically, it was sort of a parallel invention. Not exactly parallel, though. You know, some time difference. But Adam Back was not aware of this solution. So when they were discussing this problem on the Cypherpunks list, they didn't know it was actually kind of a solved problem. But then he reinvented something very similar.

Sjors Provoost Yes, but then using a hash function. SHA-1 in this case, but that doesn't really matter. And that's... The thing is, it's not actually better or worse than the design that was made before.

Aaron van Wirdum Can you explain how it works?

Sjors Provoost Okay. So you basically take some aspects of the email, as we said before, and then you add a nonce to it. A nonce is a number that you pick randomly. It doesn't matter what it is. But you have to pick it such that the resulting hash starts with a certain number of zeros.

Aaron van Wirdum Right.

Sjors Provoost Notice that in Bitcoin Core, the hash... does not only start with a number, certain numbers of zeros, but actually has a specific value that it has to stay under. But it's roughly the same idea.

Aaron van Wirdum Right. So then, yeah, you would send the email. You include this hash, and then the recipient would check if there's actually a valid hash in it. If not, the email would just bounce.

Sjors Provoost Exactly.

Aaron van Wirdum I guess that was the same with Naor and Dwork's system. I didn't spell that out, but same idea, basically.

Sjors Provoost Yep, they both had the concept of difficulty, essentially, where you can make the hash more or less difficult, depending on what your perceived spam problem is.

Aaron van Wirdum Yeah. So anyways, the recipient would then say, or in the... case of the remailers, right, which I mentioned earlier, the remailer would check, does this have a valid hash? If not, just reject it. And if so, it's forwarded to whoever it needs to be forwarded to. So that's basically the idea of Hashcash, right? That we forget about anything? Yeah, so that's Hashcash. I think that you, well, I can tell you that it, in the early days, there was some adoption of it. So, Apache used... Is that how I pronounce it, actually?

Sjors Provoost I think Apache SpamAssassin.

Aaron van Wirdum Yeah, they used it in SpamAssassin. And Microsoft recreated something very similar. Like, it was incompatible with, you know, different standards, but basically the same idea again. And then more recently...

Sjors Provoost And those two are completely unused right now because [unclear] removed it again and the Microsoft thing doesn't exist anymore. More recently, as you were getting to, Tor has been using proof of work. So again, it's a completely different algorithm. But it is an example of proof-of-work being used outside of a cryptocurrency. So where it's not used to produce value, it's simply to prevent spam. So this concept is still alive and well.

Aaron van Wirdum Right.

Sjors Provoost Now, one interesting aspect I wanted to talk about...

Aaron van Wirdum This is why we're talking about it in a Bitcoin podcast. Why we're focusing on Hashcash more than the Naor-Dwork concept, right? Is that where you're getting at?

Sjors Provoost Yeah, well, there's an interesting kind of a historical coincidence, I would almost say, and this is something you pointed out earlier that I think Adam Back was aware of, and he pointed it out, which is to say that there are two kinds of, although multiple kinds of works, proof of work, but in particular, two different kinds are stochastic and non-stochastic proof of work. And that's a distinction I hadn't really thought about. But the idea here is that with a hash function, you may or may not get the right result, and statistically it will take a certain amount of time before you find a solution, but it's random. So sometimes you find the right solution instantly, other times it takes a very long time. Whereas with these earlier algorithms... there's sort of a guaranteed time of how long it takes to find the square root, for example, of two numbers. So I suppose you could maybe make it random, but assuming you use a standard algorithm, it'll take a fixed amount of time to find a solution. And you might think...

Aaron van Wirdum Yeah, let me give an analogy that I've used, not in the book, actually, I think, but in an article I wrote earlier. It's kind of the difference between, let's say there's 100 lottery tickets. And one person buys 40 tickets and another buys 60. So now the person that has 60 has more chance to win, 60%. But the person that bought 40 still has 40% to win as well. While if you take two cyclists and one of them can ride his bike 60 miles an hour and the other 40 miles. then anytime they do a race, the one that can cycle 60 miles an hour will just win, like every time.

Sjors Provoost Exactly.

Aaron van Wirdum Every time the same cyclist will win, there's no 40% chance that a 40 mile per hour cyclist will ever win. It's just not going to happen.

Sjors Provoost And so if you translate that to the context of Bitcoin mining as it is today, let's say we had picked a non-stochastic form of proof of work. based on that original paper. So basically, if Adam Back had known about the original paper and had not bothered to implement something based on a hash function, because, you know, there's already a solution out there, then you would have the biggest miner, whoever that is, will just always find the next block first, because they would always find that big prime number or whatever the challenge is. They would always find it first.

Aaron van Wirdum Right. It will be like that 60 mile cyclist rather than like currently Bitcoin mining kind of works like this lottery. But if the biggest miner just always wins, then you can't have Bitcoin like we have it today.

Sjors Provoost And of course, we still have some centralization problems in that sense, but this would be centralization on steroids if we did not have hash-based proof of work.

Aaron van Wirdum Yeah, basically Bitcoin wouldn't work, like not as it's designed today.

Sjors Provoost Yeah, or maybe we would have figured it out and then changed it, but definitely would have been not optimal.

Aaron van Wirdum Yeah, so essentially what you alluded to, like we may have been quite lucky in that sense that Adam Back... wasn't aware of the prior proposal, so he invented it in a way that's actually useful for Bitcoin.

Sjors Provoost Exactly, but it's not something he was aware of at the time. Or at least, he didn't put it in the paper.

Aaron van Wirdum As far as I know, and I've discussed it with him, so either my memory is failing me, but I'm pretty sure he only realized that after Bitcoin himself. He only figured that out, so that actually Hashcash specifically only works for Bitcoin. Yeah, no, that was not some sort of pre-planned thing for... Mr. Back.

Sjors Provoost Yeah. Now, before we get to the next topic, which is bit gold, we should talk about something that the author of bit gold observed about proof of work. That's kind of the direction, kind of the bridge I wanted to make.

Aaron van Wirdum Yeah, well, that is also the bridge I make in my book Sjors.

Sjors Provoost Excellent.

Aaron van Wirdum Yes.

Sjors Provoost It's almost like I read it.

Aaron van Wirdum I mean, I think, at least if we're thinking about the same thing. So yeah, you mean, so Hashcash or proof of work essentially for the first time brought something akin to digital scarcity, created something. introduce something akin to digital scarcity because there is an actual cost a physical cost energy in the real world required to produce it yeah so rather than just copying numbers you have to actually invest something real resources and that sort of creates something that you could see as digital scarcity, right? That's what you're getting at.

Sjors Provoost That's not where I was getting it, though it is true. What I'm getting at is that the question is how do you define proof of work or how do you measure it? How is it different from other cryptography?

Aaron van Wirdum This is not a bridge I make in my book, Sjors. Unless I'm completely confused where you're going.

Sjors Provoost It is a new bridge, but basically Nick Szabo wrote an article about something he calls, now I lost a term, that's not smart,

Aaron van Wirdum Oh, you mean secure benchmark functions?

Sjors Provoost Yes, secure benchmark functions. So here's the thing. We know that with normal public key cryptography, for example, and with hash functions like SHA-256, we know that it's easy to verify and easy is then defined as like just takes like a very short time on a typical computer. And impossible or like, you know, would take forever effectively to hack it, to coincidentally go back from the hash to the original, from the public key to the private key, which is then called hard. But with proof of work, you're doing something that's a little bit in between. It is definitely not easy to go back to find a certain number of zeros, for example, in the proof of work, in the hash. But it's also not hard in the sense that it will not take forever. In fact, you don't want it to take forever because then you cannot, you know, make the proof of work on your email if it would take forever to make the proof of work. So then the question is, how do you sort of define that? How hard is hard enough, right? It should not be too easy, it should not be too hard. And Nick Szabo wrote this paper, well, this article about it, basically, the coining a term secure benchmark function. Now, if you look at the 1992 paper about proof-of-work, they were also informally defining it as something that's not too easy, not too hard, somewhere in between. So Szabo put it in slightly more mathy terms. And the analogy we could get into, I guess, is the one-way function, or what it's comparing it with. So we talked about one-way functions in an earlier episode, where you actually were correct, and I was wrong. So.

Aaron van Wirdum I remember that.

Sjors Provoost Good. Keep enjoying that feeling.

Aaron van Wirdum Yes. I think everyone heard that, right? Can you repeat it one more time?

Sjors Provoost So let's just try and explain it correctly because I don't even remember exactly what I was saying.

Aaron van Wirdum Go on.

Sjors Provoost A one-way function is a function that is very easy to go in one way. Like checking that a hash is correct. but very hard to go the other way. which is like trying to produce a fake hash, a fake original, basically. And there are a bunch of one-way functions out there. One is finding the factors in a big number, or these prime factors, as you mentioned, with RSA. Another is a discrete logarithm problem, or that's sort of a more generic one, but that is used for public and private key cryptography, like the elliptic curve. And then there's cryptographic hash functions, like SHA-256, which so far has not been broken. The problem is there is no mathematical proof that this actually exists. So we think these functions are one way, and they better be one way, but it may turn out that some mathematician somewhere proves that they're not. And then you get into the whole P is NP stuff that we're not going to get into. Now, there is a special kind of one-way function called the trapdoor one-way function. That is public key, private key cryptography, where it is very hard to go back. It is very hard to go from a public key to a private key. In fact, take the age of the universe, unless you know the private key. Then it's trivial.

Aaron van Wirdum Yes.

Sjors Provoost I think I said it wrong. It's very hard to fake a signature, for example, but if you know the private key, then it's trivial to make the signature. And that is the trapdoor, the secret passageway through which you can do things. So that was the distinction we wanted to make back then.

Aaron van Wirdum There actually is. There's a chapter about this in my book as well.

Sjors Provoost Yeah, so then the secure benchmark function has to be less strenuous. It can't be a one-way function, because then... you'll never go back. So if you go to the Wikipedia article about one-way functions, it defines this little thing like, okay, for any blah-blah-blah function that you try 100,000 times or whatever, statistically you should almost never find the correct answer. That's sort of how they defined it. And then Szabo basically writes a similar formula, but then explaining what this secure benchmark function should look like.

Aaron van Wirdum Sure, so are we still just making a bridge?

Sjors Provoost Yes, we are.

Aaron van Wirdum This is a big bridge you're building here.

Sjors Provoost I'm almost done with the bridge. One thing that is interesting there is that when it comes to these one-way functions, it doesn't matter what hardware you have. They just seem like you can have the whole universe and you still cannot crack it. You can have a Dyson [unclear] and you can't crack it. But in the secure benchmark function, the device that you use, the machine that you do things on, actually matters in the math. You cannot just... abstract away the machine you have to say okay what is a realistic computer because and then you get back to the spam problem if a spammer has an ASIC a modern day ASIC and let's say the algorithm was SHA-256 instead of SHA-1 well then you as a consumer trying to send an email would have to burn your phone to the ground in order to just send an email but that guy with the ASIC can just spam a million people because per watt of electricity that you're putting into that ASIC You can just produce enormous amounts of spam, whereas your phone is less efficient, so it would just get too hot. And so that's why it's very hard to find functions that are hard enough, like that are easy enough for a phone, hard enough for an ASIC. And he kind of anticipated that problem in that very short paper.

Aaron van Wirdum That was Sjors building the Brooklyn Bridge over here. Beautiful in its own right.

Sjors Provoost Exactly. And that's why he needed, for his bit gold proposal, he says like, yeah, make sure you, you know, whatever you do, because he didn't actually build the project, make sure it's one of those secure benchmark functions.

Aaron van Wirdum Yes. Okay. Yeah. In my book, I sort of muffle this way in a footnote and I just call it hashes because kind of what we're talking about anyways right? okay okay let's sure let's talk about bit gold um you want me to I don't know if there's much uh specifically to introduce unless I you know I can tell the whole story about how the cypherpunks want to create digital cash and Nick Szabo was one of them but let's at some point

Sjors Provoost We know that? I think it might be interesting to mention the I think it was like seven points that he describes that this system should do

Aaron van Wirdum Well, that was Adam Back.

Sjors Provoost Oh, I thought the bit gold paper also lists like seven properties of the system, basically.

Aaron van Wirdum Oh, in the bit gold paper?

Sjors Provoost Yeah, or at least...

Aaron van Wirdum Well, it's been a while since I read that.

Sjors Provoost Well, maybe you just describe it in general terms.

Aaron van Wirdum bit gold itself? Mm-hmm. Okay, so we're getting more to the technical side then.

Sjors Provoost Yes, what the architecture of the system is and how it should work.

Aaron van Wirdum Okay, yeah, I can do that. Okay, so basically Nick Szabo wanted to create digital cash, right? Hashcash was introduced, so now there was something akin to digital scarcity. Now, it wasn't real digital scarcity, obviously, or at least um it was at least not limited because over time it becomes easier and easier to create valid hashes. So there were a number of problems with Hashcash why you couldn't use it as money. Also, of course, you can't pay someone with Hashcash. It's like a one-time use.

Sjors Provoost Yeah, so what you're describing is the inflation problem, right?

Aaron van Wirdum Well, that's the one problem and also you can't transfer it to anyone. Like you can't re-spend Hashcash.

Sjors Provoost Yeah.

Aaron van Wirdum Right? So it wasn't really digital money yet. It was digital postage, essentially. But it did introduce something akin to the digital scarcity. And this idea inspired, for example, Nick Szabo to propose their own digital currency schemes. Now, bit gold was never implemented. It was only ever a proposal. But it's still interesting. So the way it works is you start with a candidate string. The candidate string can be anything, I guess. It doesn't really matter. But let's just say a random string of numbers. And then you with the proof of work or a secure benchmark function as you just explained, that's how Nick Szabo called it in his paper I believe. at least in one of his posts, he very specifically called it.

Sjors Provoost Yeah, I think in the posts I read, he just used all of the terms, but then made this benchmark like a more specific definition.

Aaron van Wirdum Right, exactly.

Sjors Provoost But we can just call it proof of work because that's what it is.

Aaron van Wirdum Yeah, let's call it proof of work. So you use proof of work. So there's a candidate string. Anyone can use proof of work to create a new valid hash, essentially. Now, the person who creates this valid hash becomes the owner of this hash.

Sjors Provoost So whoever creates it first, then?

Aaron van Wirdum Whoever creates it first, yeah. I don't think it was specifically defined or specified how this initial ownership would work. But the obvious solution is you hash your public key with it. And that would just be an easy way to do it, right? Anyway, so whoever creates a valid hash using proof of work on the candidate string gets to own that string. And then the valid hash becomes the new candidate string. So now everyone can start hashing that to find the next candidate string, which then, to find the next valid hash, which then becomes the next candidate string. Okay, so that's how you own these strings, essentially. Transferring strings is much like Bitcoin. You sign a message saying, this string now belongs to this public key. And if that message is cryptographically signed with the corresponding private key of whoever was owning it, whatever public key was owning it, then the transfer is valid. The challenge was who gets to keep track of who owns what. Or perhaps more specifically, how do you prevent double spending? Right? One person could sign one transaction or several transactions go to several people.

Sjors Provoost And how can you prevent afterwards multiple people saying that they found it first? Right, if the new thing was discovered.

Aaron van Wirdum Yes, right. Yes, that's true. So there needs to be, you know, consensus on who owns what. Also smaller, well, other problems are, for example, censorship. Anyways, so double spending, let's just say, is the main problem. And Nick Szabo envisioned like an ownership registry. So there would be a bunch of internet servers and they would essentially vote on... whether or not the transaction is valid or which transaction out of conflicting transaction is valid.

Sjors Provoost Yeah, so the key part there is at least it's not a central party that's doing it.

Aaron van Wirdum Right.

Sjors Provoost But it's somehow decentralized. Multiple people are tracking it. Everybody can sort of check that it's at least, you know, maybe a bit honest. I mean, there's certain things you can check because signatures are signatures. You can't forge them. But if all these public parties keeping records either disagree, it's hard to decide which is right. You can't just count them, for example.

Aaron van Wirdum Yeah, well, the first thing you mentioned is kind of interesting about the signatures. So if... Okay, wait. So the problem is essentially that this registry, these servers, they can be corrupted in different ways. So, for example, it wasn't Sybil-resistant, or at least Nick Szabo hadn't come up with a robust way to make it Sybil-resistant. In other words, one guy could join with 10,000 different servers and just outvote everyone else and double-spend everyone. Like, there was no robust way of stopping that.

Sjors Provoost Yeah, it's basically all the proof-of-stake problems.

Aaron van Wirdum It's similar. Yeah, it didn't use proof of stake itself, but yeah, there was nothing at stake in that sense. That's for sure. Now, Nick Szabo at that time thought a potential sort of mitigation against this is that users themselves can sort of keep an eye of what's going on. And then if there's, let's say there's, let's say the Sybil attack happens. And then the honest servers, the honest nodes in this registry system, they can split off. They can say, no, that's actually someone's trying to cheat. We're just going to start our own registry. And then users who are paying attention can sort of see, yep, this registry is honest and this registry is not. And that was supposed to sort of solve that problem, but it doesn't really. Like, for example, if you're offline and you come online, You weren't paying attention, so to say. You're a new user or something like that. You were just offline. You were on holiday. Who knows? And all of a sudden, there's two registries. There's no way to know which one was cheating and which one was not.

Sjors Provoost Exactly. Sounds like you need to be online all the time and you need to download all the transactions. And then you can sort of... It's like running your own Bitcoin node, although there wasn't an actual blockchain at the time. Well, there may have been, sort of.

Aaron van Wirdum Yeah, wait. The way you're phrasing it now sounds like it would have been a solved problem.

Sjors Provoost No, you would. If you were to implement this system, then it sounds like everybody should just be verifying everything so that there is no third party.

Aaron van Wirdum Well, so that's what we're getting later. But bit gold did not have this idea yet in any case.

Sjors Provoost No, no. The idea would be that there would be multiple servers doing this job, basically. But in order to check the servers, the only logical conclusion to me would be that everybody has to check everything.

Aaron van Wirdum But you're very smart.

Sjors Provoost Well, and I have the benefit of hindsight.

Aaron van Wirdum Maybe mostly that. Or both. Well, actually, so there is a fairly recent sort of analogy we could draw from this sort of non-solution, you could say, which would, for example, be Ethereum Classic and Ethereum, right? At some point, a... valid transfer happened on Ethereum and then that money was stolen back and then the people that stole it back said now we're the real Ethereum and at that point there were two Ethereums and the actual Ethereum was forced to change its name while the Ethereum where the theft happened went on and that's what people today call Ethereum.

Sjors Provoost I mean that's one perspective and the other is that the people who call things Ethereum apparently you know, do not primarily follow what the software says.

Aaron van Wirdum That's kind of the point. So you can debate about this and there's no clear solution. I mean, I still think what I said is correct. Like, I really mean that. But that's sort of, besides the point, the point is you're now expecting users to keep an eye on everything. So it wasn't really a good solution. However, it was, of course, very innovative. It had a very innovative idea of how you could sort of, you know, it was a big step into thinking about creating digital cash, specifically digital cash based on Hashcash that wasn't backed by anything else.

Sjors Provoost Yeah, I think one innovation there compared to DigiCash, because we talked about that earlier, or eCash, in eCash you have... a mint, that's the entity that creates coins, and they are also the entity that is essentially the central bank that clears all transactions. So there is a single point, the entity that issues the coins, that checks all the transactions, that kind of has a monopoly on the transaction log, or maybe not. Whereas at least the issuance now is completely decentralized because everybody can deliver their proof of work. I think that ingredient is there. And the verification, although still a bit hand-wavy, at least the idea is that it shouldn't be one entity. And I think he also was mentioning RPOW already, but that's something to discuss another time.

Aaron van Wirdum He was not mentioning RPOW because RPOW came years later.

Sjors Provoost Okay, then maybe I read a newer paper.

Aaron van Wirdum Yeah, yeah, yeah. Well, that's probably it then. where were we okay yeah so we saw okay let's for the sake of convenience now imagine that this system would have worked so now you can create these strings and you can send them to other people and there's this registry that keeps track of which public key owns which string now we're getting close to something that looks like money but there is a second big problem that bit gold was facing with or that it's sort of solved So the second big problem is that it, over time, becomes cheaper to produce valid hashes, right? So at first, because computers just get better and better, it gets faster and faster, so it's easier and easier, cheaper and cheaper to create valid hashes.

Sjors Provoost And there's more of them. Well, that's actually not important that there's more of them, but it is cheaper, yes. It costs fewer kilowatts of energy to do it.

Aaron van Wirdum Right. So the problem then is that the money isn't. fungible necessarily. It should be that each currency unit is worth the same or each currency unit of the same denomination should be worth the same.

Sjors Provoost Either it's fungible but in that case all the money you created in the past is now worthless so it's fungible but highly inflationary or it's not fungible where you and that's I think the solution that he proposed is where you value all the work more. So you say, because this work was generated 10 years ago on a slower computer, we know that more energy was put into it, therefore we can correct for that. And then the hope is that the market actually does that.

Aaron van Wirdum No, no, the market doesn't have to. If the market doesn't do that, that's even better.

Sjors Provoost Then it's highly inflationary. So you mine your coins in 1999, you have 100 of these coins, and now 100 units of work. And now 10 years later, somebody makes 100 units of work in a fraction of a second. So either your 100 units of work are worth nothing in the future, or they are valued because they are old. Whether the market will pick one of these two, I don't think there's any guarantee. He does argue that there are some precedent, like that older collector items are worth more. A bit like ordinals, I guess. but that's not the part of ordinals that's taking off the most.

Aaron van Wirdum Yeah, or like I think misprints of certain postage stamps or something were worth more. Yeah. Anyways, yeah, so indeed, he does argue that. So the idea that he proposed was we'll create a market for these strings, for these hashes, and on these markets, people can trade them against each other. So that's how the markets can figure out how much is a 2005 hash worth in relation to a 2015 hash?

Sjors Provoost Yeah.

Aaron van Wirdum So maybe one 2005 hash is worth 10 2015 hashes. I should note all these hashes are also timestamped. Like, first of all, they're, of course, made in order.

Sjors Provoost You can prove that they are a certain age.

Aaron van Wirdum Yeah. Which is also... Another chapter in my book, Sjors, where I talk about the invention of timestamping.

Sjors Provoost Great.

Aaron van Wirdum But I won't get on that detour. So bit gold, yeah, so there's this market for strings and you can figure out how much these strings are worth in relation to each other. Then Nick Szabo's vision was there will be sort of banks, like in a free banking type of environment, where these banks will collect the different strings and sort of bundle them together into buckets of strings of the same value.

Sjors Provoost This was written before the derivatives markets implosion in 2007, right?

Aaron van Wirdum Yes, we're in 1998. So yes.

Sjors Provoost Yeah, when all these triple A rated buckets and I'm thinking about what happened there.

Aaron van Wirdum Right, right, right. Yeah, has nothing to do with this, Sjors, but

Sjors Provoost thanks for that color.

Aaron van Wirdum So yeah, so in my example earlier where one 2005 hash is worth 10... 2015 hashes one bucket could consist of one 2005 hash and another bucket could consist of 10 2015 hashes so now you have back buckets of the same value and these banks would then use these buckets or these bundles whatever you want to call them to issue coins on top of digital coins still so for example every bucket is worth 10,000 coins and these 10,000 coins are issued to people's account So now you have sort of a digital form of cash that people can pay each other with.

Sjors Provoost And then the idea would be that that is actually DigiCash, right? That layer on top.

Aaron van Wirdum Yeah, you could use eCash for that. I mean, it doesn't have to. It's free banking. You're free to do whatever you want Sjors. But yeah, you could use eCash for that if you want to offer privacy to your customers and get customers that way. But yeah, this was the idea. So once you have 10,000 coins, in my example, you can exchange them for an actual bucket of strings, and then you have the actual bucket, and you can maybe bring them to another bank. And also, because this is all these strings, it's cryptographically provable who owns them. You can also have the proof of reserve type of stuff, like Nick Szabo was already thinking about that kind of stuff, to address your 2008 concern, by the way.

Sjors Provoost Yeah, yeah, it's a free banking system.

Aaron van Wirdum So this is how, yeah, this was basically the idea of bit gold. Did I miss anything?

Sjors Provoost Yeah, so we talked about inflation and I guess this sort of, these buckets also address the change problem, right? Because another issue is that when you had the original... e-cash system you could go to a shop and you would come with your 10 euros worth of this stuff and they would immediately go to the bank essentially redeem it and give you your change back essentially so change wasn't a problem in the original system change is also not a problem in Bitcoin because it you know the the transaction itself creates a change but in this system these strings don't have change so what you could do is somebody could make lots of small little pieces of work and distribute those just like you would distribute small change and then you go to a shop and you get these little strings back for your change but it it may be easier to do all this on a second layer just have big buckets somewhere that don't need to be changed all the time because also it would mean having to track all the movement of all these mini strings like tracking the movement of every penny on the planet essentially

Aaron van Wirdum Right. Yeah, exactly. It's interesting you mentioned that. Nick Szabo was already thinking about second layer solutions, you know, as are being developed and exist on Bitcoin today. This was also sort of an original Nick Szabo vision to have different layers for different types of transactions. Yes. So that's that's bit gold in a nutshell I think, Sjors.

Sjors Provoost All right. Well, then I guess I can conclude Bitcoin fixes this.

Aaron van Wirdum Yeah, well, we're going to make one more Genesis Book shill episode, right?

Sjors Provoost I think so, yeah.

Aaron van Wirdum Maybe next week or the week after, we'll make one on B-Money and RPOW.

Sjors Provoost Cool. All right, then. In that case, thank you for listening to Bitcoin,

Aaron van Wirdum Explained.