Cedric Youngelman | The Bitcoin Matrix Podcast #114: Adam Back Reflects on the Cypherpunk Movement, Inventing Hashcash, Satoshi & Bitcoin
Link to the YouTube (the timestamps are based on this): https://youtu.be/uCavLyzQMbk
Cedric Youngelman: Adam Back, welcome to The Bitcoin Matrix Podcast, how are you?
Adam Back: It’s good! Thanks for having me on!
Cedric Youngelman: Yeah, this is quite an honor to be chatting with you. Quite frankly: when I started the podcast, I probably didn’t even dream this big! So this is really exciting! And I’d really like to get into you a bit and your background and then obviously encryption, cryptography, and distributed systems, and Bitcoin of course. From what I read, it seems like you got your exposure to computers through video games. Is that true? And how big of a role did video games play in your life?
Adam Back [1:52]: Yeah, I had an early Z80-based computer and I played a few games. I had a go with reverse engineering them, where you could edit the maps or figure out how to bypass limits and things like that. And then I got into programming them — they included a BASIC language on a ROM. And then I also later had to go at teaching myself Z80 machine code and assembly language, which is interesting.
Cedric Youngelman: Was this all self-taught?
Adam Back [2:34]: Yeah I was a teenager at the time, so I was doing this in my free time and I found it fascinating. It’s a sort of thing that people can get a bug for — like, an interest in. The computer’s individual instructions are quite simple at the lowest level, but it’s immensely fast! Even back then, the clock rate on these things was over a megahertz or something. We’re talking gigahertz these days, but already a megahertz is a lot of cycles. Of course, at that point, the instructions took multiple cycles depending on the instruction — nowadays you’d get more instructions per cycle. Computers have moved a lot since that time. This would be mid-80’s — that kind of time frame. But you could do a lot with this thing, and I suppose people who programmed them would get pretty close to the metal, because it’s not that powerful by modern standards. So if you wanted to make it do something interesting, you would have to optimize it a lot to — at a very low level — directly control it. So, it’s an interesting thing for people who like mathematics and physics and generally playing around with computers.
Cedric Youngelman: Right. And before you go off to university, what is your community or social aspect for learning or expanding your knowledge about computers and systems? Do you have teachers in high school? Are there message boards or chat rooms? I mean, this is still really pre-America Online and mainstream chat rooms. Are you connecting with people around these ideas before university?
Adam Back [4:29]: When I was younger — just a few classmates who [also] had a computer at home and were interested in it. But at college — which is age 16–18 in the UK — they had a computer lab, so I taught myself Pascal on those. But there was no taught subject, so you couldn’t do A-Level computer science, for example — otherwise, I would have done that! So you were able to go and use them, so I set about teaching myself Pascal and using it to try and make some kind of rendering for 3D shapes and representing 3D shapes and rotating them and rendering, so just mathematical programming.
Cedric Youngelman: Did you start studying distributed systems before cryptography?
Adam Back [5:31]: Yeah, so I started on distributed systems first, so I got two degrees. I then was able to do computer science as a subject — that was taught at the time. And of course, some years later, you can do computer science even in school at 16. But at that time, it was — at least where I was — only offered at degree level, and even that wasn’t offered in most universities! So I did the computer science degree at Exeter University, and it’s like an undergrad degree: you’re taught different programming languages and theory and data structures and complexity and stuff like that. And then when I finished that, I decided I would like to do a PhD, so I picked distributed systems for that. And so I spent a lot of time — it’s less directed, so you’re more trying experimental things, trying out different languages. And the computer lab had some distributed parallel computers with high speed interconnects called transputers — they had a couple of generations of those. So there were lots of different, interesting things you could do with that and work with your thesis advisor to pick out something to do to, first of all, catch up with what other people were doing in a similar area and see if you could improve something. And during that, one of my friends — who was doing a master’s degree — was using those same transputers, or parallel systems, to try and speed up RSA encryption. I was just chatting to him, so I had heard from him an explanation of what RSA encryption was. And, of course, computers were slower then, so it was interesting to try and speed it up with lots of network-connected cores. And not so long after that, then, PGP was released — that was in the tech news. And so I found that I had a connection because I knew at that point what RSA was, and that’s one of the main pieces of technology in PGP. I found the societal reaction to PGP pretty interesting! The establishment didn’t necessarily like it because it changed the balance of power towards individuals, and so I got interested to find out other things like that and looked around online for where people were exploring new ideas in that space, and that’s where I found the cypherpunks mailing list. So then I actually spent quite a bit of my time learning about applied cryptography self-taught, used up a bit of time in the middle of my PhD, and then finished the distributed systems part at the end.
Cedric Youngelman: When you got into the cypherpunk’s mailing list, would you consider yourself at that time a cypherpunk? Or was that something more that other people would have referred to people interacting in that community? Was it sort of an ethos?
Adam Back [8:42]: Yeah, it’s an interesting mix of computer science and the mathematics of applied cryptography, and using that to try and improve self-determination — the ability for users to take matters into their own hands and assert privacy. So they had a theory for it, and of course different commentators had written about this over the years before then that, in the online world, you were losing a lot of privacy because ISPs were nothing like peer addresses and everything was cleartext. So there’s some sort of default privacy in the physical world because you’re in proximity and nobody’s eavesdropping and things like that. Whereas online, it’s all very global and readable with discussion forums, and e-mails weren’t encrypted and so on. And this was even — originally there were no SSL credit cards on websites, so even that came a bit later. So the cypherpunk’s thought process was: Well, if you want to do something about this you just have to build the software. And if people use it, that will solve the problem! So there was very little concern given to seeking permission to do that, but just more about building things that could improve privacy for the individual. And of course the killer app for this kind of privacy tech was: Well, if you can use the Internet privately, you can browse, you can send e-mails and communicate — you really needed a private way to pay. So electronic cash was the holy grail of Internet privacy tech, but it was much more challenging to build than the other things, which there were implementations of.
Cedric Youngelman: When you came across cryptography — and even more so the cypherpunk movement — did you think that this was a winnable fight? In a David and Goliath kind of sense? That an individual could create free and open source software that could really protect the individual and/or defeat the state in some way? I mean, it seems like a very brave thing to do! Or risky! — to take on this endeavor.
Adam Back [11:18]: Yeah, I mean it wasn’t without political risk. People can use privacy for communication, but they can also use it to send threatening messages that somebody will complain about. And so of course when that happens, sometimes the recipient will complain to the authorities and the authorities — whether that’s the local police or something — will try to figure out who the original sender was. And they’ll arrive at the operator of a piece of privacy tech like a remailer or something. And so they will try to pressure them to provide the information — of course they don’t know it, because these remailers have no logging and it’s all encrypted and it’s multiple hops like Tor, so they really don’t have the information. But nevertheless, some of them would get into legal problems with that — and I think the EFF actually helped defend people in that situation. So I ran one myself for a while, but I was running it in a different country in a rented shell account from a small one-man ISP. And so I just figured I would run it if and until any problems arose and then I’ll shut it down and let somebody else do it. And that way I’d provide useful functionality but avoid making a test case of myself. I mean, the aim was to succeed! Which was to provide privacy — not to engage in prolonged legal arguments which no one had funding for, and was obviously problematic for the people that got stuck in that situation. So it seemed to work out in the end, because eventually they did indeed contact the ISP and he said, Well I’m a small ISP and that’s one of the users. So he told me and I shut it down, and that was the end of it. And there was no further contact. But it lasted for some years, and there were many of them.
Cedric Youngelman: Yeah. In terms of privacy and cryptography though, do you think early on in university or right after university, you thought of this as maybe your life’s work? Or something that you would just always work on during your life? These issues and these problems?
Adam Back [14:01]: Well, I found it very interesting and had a drive to do it. So at that time, I found it the most interesting thing to do! So you get the bug for something and you’re gonna devote a lot of free time to it. And if you’re inventive in mathematics and programming and systems computing, maybe you can find a new technology that can help — that was my skill set. So I tried to build and design different systems. I did one which was an attempt to implement a simplified version of Eternity, which was a distributed file store or a distributed web. You could put files in it, and the point was that it’d be hard to censor — hard to take down because it’s distributed — and that they should stay there for a long period of time. So if somebody forgot to pay a hosting fee, it shouldn’t go away. And there shouldn’t be a hosting company that somebody could call to take it down! And so there was an academic paper called The Eternity Service, by Ross J. Anderson — it was a little elaborate, but I simplified it and used the Usenet discussion broadcast mechanism to broadcast encrypted pages of web content. There were thousands of Usenet hosts online, and if you use this piece of software and point it at your Usenet feed, it could render these web pages. And they could be encrypted, they could be signed, you could make updates to them, but unless you had the key, you couldn’t modify them and you couldn’t delete them and it’d be pretty hard to censor — like, to prevent publication — it’d be pretty hard to take down once it was there. And if people had a password in a group and they were sharing a web page, then somebody who didn’t have that password wouldn’t be able to see it. So it was using PGP. And there were other high level protocols built on top of Usenet. There were people that were ripping movies and posting them in parts on there, and there were tools to reassemble the fragments. So it was a pattern that Usenet was a generically reusable slow speed — it’s not real time, it’s more e-mail speed, let’s say — generally for discussion forums, but you could put machine generated data or encoded data. So, different channels, so you just pick a channel or make a new channel and put your application messages in there that are not really readable without some software, and it will work. So that’s what I did! One of the other things I did was I worked on electronic cash quite a bit trying to find ways to make that work. And one of the things I implemented — which later became used by Bitcoin — was the Proof of Work stamp, and that was actually related to the remailer. So people were spamming through the remailer — because you could use the remailer for sending an e-mail but you could also use it to post on these discussion groups that were broadcast globally — and so in total we used quite a lot of bandwidth. And so it was clear — and the remailer operators were talking about this — that somebody was spamming through the remailer. And it wasn’t like an advertisement — it was just random numbers! And we thought they were doing it to annoy the system administrators of some of these hosts so that they would create a backlash against remailers and put some filtering in place to block such messages or something like that. So anyway, it got me thinking about how to control spam — because the sender is anonymous by design. Most e-mail spam things are based on blocking the sender e-mail address or the sender’s IP address — and that by definition would not be possible here, so I was forced to think about it in a different way. And what I observed is that the real problem is that e-mail is effectively free or extremely low cost, and so people can generally spam to an enormous extent just as a nuisance, or they can send millions of unsolicited bulk e-mails a day with a very low click-through rate and still make money. So I was like, Well maybe I can create a cost? Obviously a credit card is difficult to accept — there was no PayPal at the time, and not everybody has a credit card. And it’s got a minimum fee, it’s got all kinds of scalability problems. And there was no deployed large-scale eCash system like Bitcoin, even though people were building things that were somewhat centralized — like, there was a DigiCash eCash system. And I guess the DigiCash system came afterwards, did it? In any case, the DigiCash original paper was long before Hashcash — that was in 1985 — and HashCash was 1997. But I figured that you could use a little bit of work to prove to the recipient that the sender had spent some effort, and that was using hash collisions. So it’s just the observation that the hash functions behave a bit like random number generators, and so it’s like throwing lots of coins and tossing coins and hoping that a certain number of them come up heads and then you would succeed. And so the only way to really do that was to just keep trying — so brute force — so that’s what creates the cost! It’s very easy to verify — you just run the hash function once and you see how many of them are zeros. But to do the work — if there were 20 leading zeros — it would take a million tries, which might take a few seconds on the computer of the day. And then I made a kind of difficulty for it, which is: you would state in the stamp how much work it was intended to have, and then the recipient would be able to verify that it had that much. And maybe the recipient could also generally increase over time how much work they would demand based on the speed of computers — so it would keep up with computing power improvements. And people ended up using that. I mean, it got integrated into remailers so that you could have to include a stamp to send an e-mail or a Usenet message outside of the system. You could use it later for a number of other systems, like a more expensive stamp for creating a pseudonym to prevent click fraud on websites where people will be incentivized to create advertisement clicks and get paid advertising revenue. There’s a general problem with people making robots that do that to emulate humans! So somebody built a Hashcash-related system to make it more expensive. And it also started a conversation about whether Hashcash was a bit like digital gold, and whether an electronic cash system could be based on it. So the context was not so many years before there had been the Digicash electronic cash system. It was centralized — highly private but centralized — and the company that operated it went out of business eventually, and so then it stopped functioning and you couldn’t actually tell whether a coin you had was spent or not because the database was on the server. Of course, people were very excited about the potential for this Digicash system! The vibe was somewhat Bitcoin-like but on a smaller scale. When that system was running they were trying to get it into commercial adoption. It was a bit like stablecoins in today’s technology, because they were aiming to get a relationship with a bank so that you could feed that money into it and get a token, you could respend the token, eventually somebody could take it out and get the bank balance back. So there was no electronic scarcity, digital scarcity component to it — it was just a bearer tokenized representation of fiat money in a bank account, ultimately. But people had seen that system fail, and one of the lessons that you could take from that was: Well why did it fail? Well one reason is it’s centralized, and the other reason is it needs a relationship with a bank. And those both make it difficult for it to be robust and survive both points — that it would keep running. And so it seemed like multiple people saw Hashcash as a potential building block to help go into the mix of bricks you could put together to try and construct an electronic cash system. The idea basically being that you could mine to create a coin and then you would have a coin with an actual scarcity and a cost that didn’t require a banking interface. But then of course you needed to prevent it from being double-spent, so people were talking about a decentralized double-spend database. Nick Szabo wrote about that. Wei Dai did as well with B-money. And then if you’ve got a decentralized database, then you need to coordinate and deal with race conditions, which is where the Byzantine Generals Problem comes in. It’s a well-known computer science problem definition with some reasonable solutions, but none of those systems got implemented because, to my mind, there seemed to be some gaps in their functionality. So they were not quite buildable or they relied a bit too much on human judgment or something like that. So in B-money, there’s a set of servers involved like supernodes in a peer-to-peer network, and they would vote amongst themselves — I guess, humans — once a month to decide how much work it should take to create coins this month or something like that. So that feels like that’s subject to human judgment, and those guys would then be like a monetary policy committee or something, and might end up in a conflict of interest situation. And Nick Szabo had a different variant — which is a bit more sophisticated. He just said: Well people can make as many coins as they want — or stamps, I think he’s calling them — and then you have a specialized market called a collectibles market where experts would assemble stamps of different scarcity into a book which had a standardized unit of scarcity so it could have lots of not very scarce ones and a few fairly scarce ones and you could assemble a standardized scarcity level and that that would be a coin. And that way, there wouldn’t be a need to set a cost on creating coins directly, and you’d have a standardized scarcity. But of course the scarcity itself would be evolving over time as computers get faster, so I’m not sure if he factored that in. So anyway, neither of these things seemed quite implementable so they didn’t get implemented! But people spent a lot of time over some years brainstorming about how to make it work. And one of the discussions — even very early discussions before B-money and Bit Gold — was: Well if you use this as an electronic cash mining protocol to create coins, won’t you end up with hyperinflation? Because computers get faster, and if people can make money doing it, they’ll just do more and more of it and you’ll have hyperinflation and then they won’t be able to hold on to that value. And so people were trying to figure out how to control the difficulty. And you can see from the B-money approach that it was difficult: it wasn’t obvious to people how to do that in a decentralized way — without human involvement. I suspect part of the problem was that some of the people working at this — like myself, particularly — our problem statement was: Well it should be a stable price. It shouldn’t require a banking relationship, but there should be a varying amount of work selected to make a coin that costs a dollar to produce or something. And it seems very hard for a computer network to do that because it doesn’t know what a dollar is, it doesn’t know how fast the computers are, and it can’t measure it, and stuff like that. So that didn’t go anywhere. Another thing that was designed and actually got built in a prototype form was RPOW by Hal Finney, which is: Reusable Proof of Work. And with that one, you send it a Hashcash token and it sends you back a Digicash — an electronic cash coin that’s respendable. So it does use a centralized server. Now, one of the problems I didn’t mention with the Digicash server approach is that there’s no audit, so you are trusting the server not to issue more coins than it has fiat in a bank account or that people have sent it work for. So it’s in a privileged position. So Hal Finney found a solution to that, which is: he used at that time a new piece of technology called trusted computing, where you would have a tamper-resistant CPU or PCR card and it could give you a hardware signature to convince anybody remotely as to what software it was running. And then, because you would know what software it’s running, you’d know that it would locally prevent double-spending. So it’s a bit of an old concept, but computers have these things in their cores these days — they’re not perfect, but they’re a security model, and that was a hope at the time, that that could become a widely used and dependable building block for security programming. So he built it as a prototype and left it running for a while. There were some less well-known ideas, but that was the main one of the three, plus Hashcash before that. And Digicash before that. So RPOW is in 2004, and it wasn’t until 2008 that Satoshi started e-mailing people and posting drafts of the Bitcoin white paper, and subsequently the Bitcoin source code in January 2009, where he had evidently solved that last problem by changing the problem’s definition, it seems, and just fixing the rate of supply of coins and let the market decide how it values them. And that turns out to be something that a computer network can verify and enforce across thousands of nodes. And then Bitcoin started its long bootstrap process. I wasn’t involved in Bitcoin actively until 2013, though I had heard about it by Satoshi and some early mailing list discussions in 2008–2009. But once Bitcoin was released, it seemed like it took a few years until there were exchanges where you could exchange it for dollars. And before that it seemed — at least from talking to people who were involved like Dustin Trammell and others — that it was a bit more hobbyist. People would just send money for fun or in exchange for a T-shirt or pizza at an arbitrary exchange rate, and just more of a hobbyist activity.
Cedric Youngelman: That was an amazing way to describe a lot of the incremental addition of ideas through time there — especially in the 90’s and early 2000’s. Were you following along a lot of these developments in real time? I don’t mean within hours, but were you excited when Hal Finney released RPOW, when Nick Szabo wrote a paper — were these exciting developments that you followed in real time? And did you ever go to meetups in person?
Adam Back [32:34]: I was certainly tracking and actively interested to read any new applied crypto papers or academic papers that might have applied use to try and solve the problem. And I think there were a number of people with that mindset: that it was really interesting and important to find a way to build a deployable electronic cash system. And so yeah, I was certainly interested in what Wei Dai and Nick Szabo had proposed. And actually I think when Satoshi sent me the draft white paper in 2008, I had read parts of it and then sent him Wei Dai’s B-Money paper, because it seemed related. Before I really digested it! It seemed like this was pretty similar, but actually fills in the pieces that didn’t work back then. And so I sent that to him and he actually contacted Wei Dai — because Wei Dai published the e-mails — and ended up citing B-Money in the paper as well. So for many years I was working on and off on electronic cash protocols and trying to figure out ways to make it work.
Cedric Youngelman: I’m curious: what was your Bitcoin aha moment? And I’m assuming you saw that he was using Hashcash and Proof of Work in the white paper? Or did you learn that later on?
Adam Back [34:56]: No, he said that in the e-mail, so I caught that right away. I thought it was immediately interesting for having found a creative way to solve the problems that were preventing the implementability of the earlier attempts that people had made. And it was a little bit curious that he didn’t seem to be aware of B-Money and things like that, so it was quite possible that he had redeveloped or reinvented some of the concepts there. And there had been an attempt to bootstrap Digicash’s eCash server, so they set up a demo server and they said that they’d run it for a long period of time, and that there would be a limited number of coins — like 1 million. As I recall, you could get some coins by e-mailing them and they’d send you a few, and then you could transact with them — you could send them to each other. And so some of the people on the cypherpunks list thought it’d be an interesting practical experiment to see if a few hundred of them could bootstrap a value by selling T-shirts and electronic books and just doing early experimental things. And maybe get a value to stick by doing that on something that had no production cost, but at least had centralized assurance of scarcity. So you can see that in a similar concept to playing cards of which not many are manufactured, or rare stamps where there’s only a certain number of them or something — so they can end up being a scarce collectible. There’s that kind of concept there. So there was some precedent there, and so seeing the Bitcoin software released and people starting to try it out, the obvious question is: would it [also hold value]? And there was something that went wrong with that bootstrap experiment, which is: Digicash went bankrupt — and that ended the experiment. So it was cut short, but it might have worked! There was a hope that maybe that would have worked. And people were interested in it — they might have grown disinterested after a while — but alternatively, it might have taken off. So there were these open questions swirling about what’s going to happen with Bitcoin — is it going to bootstrap? The scarcity is much better defined, because the scarcity in Digicash — you have to trust them because it’s an unauditable, whereas Bitcoin is auditable. And there’s a cost — so you don’t have to ask somebody to give you some of these scarce coins and then swap them for things. So I thought: Well that’s an interesting experiment! Let’s see if it bootstraps? And it seemed like it took a few years before much indication of that happened. It really stayed in that sending things for arbitrary exchange rates period for some years. And I was doing other stuff, working at startups and things, but just keeping an eye on the news, and occasionally you’d see something about Bitcoin pop up. I saw something on Slashdot that Bitcoin had reached a dollar — that was probably 2012 or something — and then a while later I saw $100. And of course Bitcoin has more coins — 21,000,000 — whereas the Digicash demo was 1 million, so less coins. So when it got to $100, I was thinking: Well I guess something’s happening there! It’s volatile, but it’s holding up value — there’s got to be a reasonable number of users for that to be the case. And by then there were one or two exchanges as well, so I thought: Well maybe it’s bootstrapped, so I decided I would spend more time trying to catch up with the details of how it worked.
Cedric Youngelman: I know you spent quite a bit of time trying to tear it apart and improve it. I’m curious what was your reaction to the way the code was written? How good of a coder do you think Satoshi was? I preface that with: coding is only one aspect of the project, but a really important one.
Adam Back [39:55]: Yeah, there wasn’t that much documentation at the time, and so in trying to work out or understand or catch up with how it worked, I read what I could find online. And one of the things I found was a walkthrough of the code: somebody had gone through the code and explained all the modules and processes and structures and main operations and functions. The code didn’t seem too bad to me — it seemed fairly systematic and relatively low bug rate, evidently, from the reliability of the network. Maybe coding has an aesthetic to it — different people use different comment styles and get very religious about how their comment style is best or something like that, or indentations.
Cedric Youngelman: I heard yours could be very brief and elegant!
Adam Back: Well, yeah I tend to use short variable names and not use the [Hungarian] Notation where you put the type of the variable at the beginning of it as a layer of encoding — so I think Satoshi did more of that which I don’t really like! So anyway, everybody’s got their style. But if you start contributing to a project, the normal thing to do is to fit in with the style of the project so that your code is readable to everybody else in the project. But as far as I think most people could see, the Bitcoin initial source code was all written by one person, most likely — just because it’s all the same style. The other thing I did was: I ran out of things to read and I had lots of questions left! So I figured: Well the way to find out more will be — clearly there are some people developing and maintaining it — to find out where they are hanging out online and talking amongst themselves about design questions and things. I went looking around and found #bitcoin-wizards IRC channel, and so I asked them many questions that would seem like stupid questions at the start and learn more of the system and ask more intelligent questions, and gradually catch up and then start trying to identify problems, ask if there was a solution, or suggest solutions. There was an already identified problem on malleability, so I proposed this general pattern of a solution which is similar to what SegWit does, but not exactly. So there were lots of known limitations, and many of those have been improved or fixed over time. And one of the things I proposed at that time was that the Schnorr signature was a better signature — that Bitcoin could benefit from using it. So I spent some time explaining the advantages of that and discussing it with people, and many years later that actually got implemented, and into Bitcoin more recently. But there’s a long time frame there!
Cedric Youngelman: Yeah that is a long time frame, and I think there’s some other new technologies that could be applied to Bitcoin, and I hope to touch on that a little bit. I’m curious what you thought of Satoshi’s disappearance — not from a leadership point of view or an economic point of view — but from a computer science, a privacy point of view, from having the foresight to be able to disappear after the fact?
Adam Back [44:10]: Yeah, I mean from somebody who was running remailer and worked on applied cryptography and security software, you do adopt a security mindset where you think about risks and what operational security practices you’d have to put in place to control those risks. And so if you see somebody act in a way over a period of time where they succeed at that, you would appreciate that that took some planning — that took some foresight. If Satoshi were to start Bitcoin and talk to people and decide afterwards to be private, it’d be too late! Because there’ll be IP addresses and breadcrumbs all over the place. So, evidently he must have thought about that beforehand and planned that. But at the same time, I think — particularly the cypherpunks on the mailing list — there were a decent number of people who were posting anonymously or pseudonymously. I went back and looked and maybe 5% of posts were anonymous.
Cedric Youngelman: What are we talking about — is that like 10–20 people? Or is that 100? I mean, it’s not a very big group.
Adam Back [45:30]: Yeah, part of the beauty is you wouldn’t know how many exactly, and you wouldn’t know it was the same person unless they were elaborating on something that they had just commented on. Some of them would use a pseudonym, but some would just be no name — just a comment standing on its own. But there are a few thousand people on the list, so 10–100 is plausible. And there were some anonymously published software systems posted on the cypherpunks list over time. There was a system called Magic Money — it’s another eCash system, actually. It was basically an implementation of a Chaum server where you could run your own Chaum server and it could create coins and you could give them to people and they could respend them. But it’s a little bit novel in the sense that everybody was their own coin issuer — everybody issues their own coins. It didn’t seem overly practical because there would be no exchange rate, but it was a piece of technology so it implemented some things and helped people gain an understanding — and that was published anonymously by a pseudonym called Pr0duct Cypher. And there was another one to do with steganography called PGP Stealth, which was a way to take a PGP-encrypted message and transform it so that it would not be recognizable as a PGP message — so it would look like unbiased random numbers, and then those unbiased random numbers could be encoded into a picture or something, and then decoded afterwards with a key. So it was a way to hide the presence of cryptography — which is what steganography means — and that was published by Henry Hastur. There were probably a couple others. So there was a little bit of a trend to publish anonymously or pseudonymously that was probably lacking in other areas of the Internet, so it’s interesting that Satoshi chose to do that. Now you might wonder: Why? Well, you could infer that if something became widely used but unpopular to the establishment, then having an identified author or original author could expose that person to political risk or what have you. Now, that wasn’t always the case, because PGP was written by identified people. Though I would say that Phil Zimmermann — who is the original creator of PGP — had some significant legal challenges for doing that, ostensibly to do with export regulations. And they were in place, probably, to deter private citizens from encrypting messages such that governments couldn’t decrypt them. The fact that he got in so much legal problems — eventually that got thrown out, but it was quite some years of legal headaches for him — the fact that that happened and that people saw that happening, if they were paying attention, would probably help them think: Well maybe there’s a way to prevent this, which is to be anonymous — and then they can’t create [a target on your back].
Cedric Youngelman: Do you think it’s possible that some state entity knows the identity of Satoshi? And we don’t know that the state knows? I’m just asking from a computer science, privacy perspective: Is it possible that Satoshi left breadcrumbs that could reveal his or her identity?
Adam Back [50:05]: It’s possible, I suppose, if they would be monitoring or logging more Internet transit data which perhaps individual researchers wouldn’t have access to. But he probably used some privacy tech like Tor and PGP and stuff like that — you’d guess. He seemed to be knowledgeable and careful from people not being able to find any breadcrumbs since. And those were the known tools to use and remain to be the case today. Edward Snowden, the whistleblower, has said that, in his opinion — which might be somewhat informed by having worked at a US agency — that Tor is secure and stuff like that. So he was just saying that the agencies don’t have the decryption or traffic monitoring correlation capability to decrypt some of that stuff. But of course: the longer somebody were to keep using a pseudonym, the more chance they would get identified. Because if the person is identified once — it’s game over! So, once they’ve done their job, it’s time for them, really, to reduce their risk and stop. Or pick a new name!
Cedric Youngelman: From 2013 to now, has Bitcoin opened up new doors? Because you were looking at a lot of these problems and this narrow design surface for a long time. But in terms of: did it provide any revelations or questions? I need to look at this subject matter or that subject matter to better understand Bitcoin! Were there any rabbit holes opened up for you?
Adam Back [52:25]: Yeah, so when I got actively interested in 2013 — more active and researching and so on — I spent some time looking at the limitations, because there are some limitations and you want to know: can you improve them without making other parts of the system worse? And some of the things that it uses are things that I had experience with, like distributed systems and consensus protocols and applied cryptography, peer-to-peer networks. So I spent three or four months in my spare time looking at all the different things that could potentially be improved. And to my surprise, basically you could change the system — so it would still work — but you’d usually make one or two things worse for everything you made better. And so it seemed like it’s not easily improvable. And of course: one problem is it’s not very private — like, unlinkably private — so that the coins are identified. There’s no enrollment to create a wallet to receive a coin, but there is some linkage because of the change of the coins. And so the privacy is not as good as the other electronic cash systems that came before like Digicash and so on. So I put some thought into whether that could be improved. I had implemented some of the previous electronic cash systems in a library called credlib: so I implemented David Chaum’s system and I implemented Stefan Brands’s system, which is a discrete log system, and it had some pretty interesting privacy features. So I thought whether I could use some of those ideas to improve Bitcoin’s privacy, and I remembered that there was a footnote in Stefan Brands’s PhD thesis book about his electronic cash system and financial system which included a range proof so that you could prove a number was within a range. And there’d been an another discussion on the cypherpunks list many years ago about encrypted auditable books, so you could have an accounting ledger — and the values in it were encrypted — but you could check that they add up even though you couldn’t decrypt them because the encryption would be additively homomorphic, i.e. the encryption of one plus the encryption of two would equal the encryption of three, and you could verify that without knowing the values. That was proposed by Eric Hughes one of the cypherpunks co-founders many years ago. And so those two things occurred to me that: if you do that encrypted thing, it might work for Bitcoin, but then practically if you do it, there’s an overflow problem. So I could make a massive number and the number -1 and that would still add up because it wraps around — and so it would create inflation, so you’d have to prevent that! And so the range proof is a way to prevent it, because you prove that the numbers are too small to wrap around. So in terms of going down rabbit holes, I spent quite a while trying to find a compact — like, not too many bytes — range proof to make that practical. And there’s a bunch of literature on cryptographic range proofs — like zero-knowledge range proofs, where you don’t reveal the value but you prove it’s in a range — and lots of different crypto systems. And eventually I decided that just optimizing the version cited in this footnote was probably the best approach, because it was reasonably compact and it was using the same cryptography as Bitcoin — like, discrete logs and things — so it would fit in. And so I wrote about it on the Bitcointalk forum, and that later became confidential transactions. So it’s a partial solution to privacy — it encrypts the amounts, but it doesn’t prevent the linkage between a sender and a recipient. It does make the change harder to distinguish because you can’t look at the values and figure out what’s the change as easily.
Cedric Youngelman: At this point in Bitcoin’s development and your career, what do you see as your life’s work? Is it working on Bitcoin? Is it working on privacy? Is it working on cryptography? Is Bitcoin bigger than cryptography? I know it’s such a nascent technology.
Adam Back [57:51]: Before I was getting interested in the cypherpunks topics I was interested in privacy technology, disk encryption, uncensorable publishing — all these kind of technologies — but electronic cash was the holy grail. The most important one, and a difficult one to solve. So I put some effort into trying to find a solution to that and didn’t succeed, but developed Hashcash along the way, and later some proposed improvements to Bitcoin. I think that Bitcoin has become bigger than the field of applied cryptography, because the programmers and system designers and crypto analysts working on applied cryptography is not that many people, because most programmers can use libraries and take some advice from somebody or use an established protocol — so there aren’t that many people doing that! There’s a niche for it, there’s a demand for it — it won’t go away, because it’s hard to secure computer systems. But Bitcoin is just far more exciting and bigger. And I think at this point Bitcoin is a far more societally impactful change. So we have encryption, we have encrypted voice, encrypted text messages, encrypted disks — there’s a lot of encryption technology around. So, while the usability could be improved and some of the forward secrecy could be improved — forward secrecy being that: if somebody records your encrypted communication, you shouldn’t be able to decrypt it afterwards. Like, somebody could come to you and say, Hey decrypt this! And you can’t, because the software has deleted the keys. So some of it could do with improving like that — some systems do that, some systems don’t. But generally speaking, communication and storage encryption has been reasonably well developed, whereas electronic cash is new and has a much wider scope. Maybe a pretty wide societal impact if it comes to reach its full potential!
Cedric Youngelman: How long do you think a young [future] Adam Back or Nick Szabo or Hal Finney or Wei Dai would be working on Bitcoin? Will Bitcoin ossify so much in the next 50 years [that it’s unnecessary]? Or is this a 300-year endeavor? In terms of the computer science, the cryptography, the privacy, working on the protocol? How much rich or fertile ground is there for a young person?
Adam Back [1:01:12]: Oh it is! It’s very rich in interesting things to learn about and work on, and they interact with game theory and economics and monetary policy and applied crypto and privacy and Proof of Work and the dynamic around that — new systems. I mean, there’s a lot of stuff to work out on the low level computer science part of it, and then there are applications being built and systems being built on top of it. And there are quite a few bleeding edge network systems and computer science problems around it, where it hits limits and it’s right at the forefront of what it’s known how to solve with cryptography or software. Such as: the privacy parts of it — it’s quite hard to do better. Scalability — that seems hard to do better. And there are some new things which are newer than Bitcoin like the snarks — the so-called signatures of execution — which are zero-knowledge proofs that prove a program was run on some data and returned True without revealing what the data was. So it’s a more elaborate zero-knowledge proof — Bulletproofs are one of those, and there’s SNARKS and STARKS and different versions. There’s a very new area of technology — and it’s very rapidly innovating. It’s an interesting phenomena, actually, that applied cryptography has achieved a boost in interest due to Bitcoin because, if you could achieve a breakthrough in an applied way, it could get used and have a positive use and actually be adopted. Whereas historically, a lot of the theoretical crypto would be proving that new mathematical things are possible but then largely not get used. So there’s a bit of a difference between applied and theory. Theory is just to prove it’s possible. Applied is to do it in such a way that it’s dependably secure and efficient and so on. But even for the applied uses, it’s giving a lot of reasons to be working on applied systems and trying to understand the missing features that Bitcoin would want to use.
Cedric Youngelman: Yeah, it’ll be interesting to see the general shifts over time with Bitcoin and how the endeavor grows. My final question for you is: if you could orange pill anyone in the world, who would it be?
Adam Back [1:04:40]: I think young people going through university or starting programming are interesting people to orange pill because they start out as natives. So I think people who have never known there not being an Internet just develop a different native understanding and may push forward the next innovations.
Cedric Youngelman: I think that’s a very cypherpunk and decentralized answer and I appreciate it a lot. I don’t think it really comes down to one person, and maybe getting the next generation on board and maybe the next inventor or discoverer is more important than someone we might already look up to or already know, or might have a lot of sway or persuasion. I can’t tell you how much I’ve enjoyed this conversation — this is incredible. It’s been really dope. I’ll leave it to you to let everyone know where they could find you and things that Blockstream are working on.
Adam Back: I’m on Twitter at @adam3us and Blockstream is blockstream.com.