Core Developer Bryan Bishop on Building Bitcoin

Audio interview transcription — WBD057

Note: the following is a transcription of my interview with Bryan Bishop, a Bitcoin Core developer. I use Rev.com from translations and they remove ums, errs and half sentences. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.

You can subscribe to the podcast and listen to all episodes here.

In this episode, I talk with Bitcoin Core Developer, Bryan Bishop. We discuss how developers work on Bitcoin, how ideas go from concept to code, testing procedures, fungibility and the future of Bitcoin.

Connect with What Bitcoin Did:Listen: iTunes | Spotify | Stitcher | SoundCloud | YouTube | TuneInFollow: Website | Email | Blog | Twitter | Medium | Instagram | YouTube

Interview Transcription

Interview Date: Friday 14th Dec, 2018

“There are bugs in Bitcoin, some that we know about and some that we don’t. Of the ones that we know about, not all of them are public knowledge.”

— Bryan Bishop

Peter McCormack: Hi, there, Bryan. How are you?

Bryan Bishop: Hey, Peter. I’m doing great. How about you?

Peter McCormack: I’m very good, thank you. Thank you for coming on the podcast. This is the first time I’ve had someone technical who’s got a background in Bitcoin development, so I’m going to have a lot of questions for you. I’ve got a lot of interest, but just bear in mind I am probably the least technical person you know. I’ve never coded anything. I’m going to ask you probably some very simple questions, but I do kind of want to learn a lot about what goes on with Bitcoin in terms of development. Are you okay with that?

Bryan Bishop: Yeah. That sounds great. I’m very happy to provide that technical perspective. Bitcoin is very technical, and there’s a lot of nooks and crannies in there.

Peter McCormack: Right. Okay. I did actually make an attempt to start reading Mastering Bitcoin, and then I gave up very quickly. I realized it’s probably not for me, but we’ll work through this. I think there’s a lot of people involved in Bitcoin who probably want to understand a bit more what goes on behind the scenes. Before we do that, though, Bryan, could you just give us a bit about your background, how you discover Bitcoin, where your lightbulb moment was with it, and why you decided you wanted to become a Bitcoin developer?

Bryan Bishop: Sure. First, other than Mastering Bitcoin, there’s actually another good book. It’s called the Princeton Bitcoin book, and it’s freely available online. It’s very technical as well. It’s just another recommended book that you can take a look at. My name is Bryan Bishop. I am a software consultant primarily focused on Bitcoin and blockchain technologies right now. In the past, I was a web developer and application developer. Around, in specifically January 10th, 2009, I received an email from Satoshi Nakamoto through the Peer to Peer Foundation mailing list. This was how I heard about Bitcoin.

Bryan Bishop: I made a public comment on IRC in a channel that, and I quote, “yet another peer-to-peer piece of crap.” That was my take on Bitcoin at the time. To my credit, the reason why I said that was because I went to look at it, and Bitcoin only ran on Microsoft Windows at the time, and I figured, “You know what? This can’t be a very serious effort if it only runs on Windows. Who would do that? Who would make a new financial system that only ran on Window?” It wasn’t until 2013 that I took a much more serious look at Bitcoin and got more deeply involved.

Peter McCormack: Right. Okay, so you have an old relationship with Satoshi Nakamoto. That’s pretty cool. At which point did you decide you’re going to start programming and become a core developer?

Bryan Bishop: I don’t know if that was really a decision. It sort of just happened. When you get interested in Bitcoin on a really technical level, reading books and documentation doesn’t actually get you that far, because there’s actually a lot to Bitcoin under the hood that is simply undocumented, and so as a result, the only way to really figure it out is to get in there and read the source code, and actually play around with the software that is known as Bitcoin. Well, I suppose there is one other thing. When I was getting into Bitcoin development, I would say the primary way that I got into Bitcoin development was through IRC. All the Bitcoin developers go through IRC, and also the mailing list, which is now hosted by Linux Foundation. I should mention that I’m actually the moderator of the bitcoin-dev mailing list, for public disclosure.

Peter McCormack: That’s something that’s still being used today, right?

Bryan Bishop: Yes, that’s right. The mailing lists are still being used to this day.

Peter McCormack: How many people are on that now?

Bryan Bishop: I’ve actually never revealed that number, but I was quite surprised when I learned how many people there are subscribed to the bitcoin-dev mailing list. I believe that currently, it’s above 8,000 people, so you heard it here first.

Peter McCormack: Wow. Okay. An exclusive. Brilliant. Okay. In terms of becoming, or developing, becoming a Bitcoin Core developer, how is building something like Bitcoin similar and different from building traditional applications and websites and web development kind of work?

Bryan Bishop: There are two layers to how Bitcoin development is different from other software development. One is that Bitcoin is an open-source project, and for many people, because of Bitcoin’s popularity, Bitcoin ends up being the first open-source project that they’ve ever worked with. Then there is a second layer, which is that Bitcoin is a decentralized system, and there is no organization that develops Bitcoin. It is based on volunteer efforts of people that are contributing their time freely to the project. This is an even further layer that is rather unconventional. If you’re not familiar with open-source software development, that’s, open-source software’s a little weird, and then on top of that, consensus-based development is even stranger.

Peter McCormack: Okay. We’ll come to the consensus piece. Why do you think people feel, like why does this open-source community exist? It’s quite rare for people in… Say, for example, I work in, used to work in advertising. There was no open-source advertising community where people got together and worked together to work on like collaborative, non-fee-paying advertising work. Why do you think this exists in the world of software, and specifically, what is the incentive structure?

Bryan Bishop: In open-source software, including Bitcoin, people contribute to the software, in the beginning, as a hobby, so for many people, it’s just a hobby that then develops into, and then it turns into a career or something, but often, it’s not for monetary gain. People contribute for all sorts of reasons, such as they find the system to be interesting, they like the problems that they can go try to solve, and things like that.

Peter McCormack: If people are volunteering, does that mean if you’re working collaboratively on elements that you’ll, sometimes you maybe have to wait for somebody? How does that kind of … How do you kind of coordinate each other?

Bryan Bishop: Well, you’d absolutely have to wait for people to get done with their work, and sometimes that takes quite a while. It’s not just waiting on other people to finish your work. It’s also things like waiting for a number of people to review the work that has already been done, and whether that’s acceptable for release and things like that. It actually is a problem in some cases, but it’s not necessarily a bad problem.

Peter McCormack: Okay, and when you’ve decided to become, you’re going to start working on Bitcoin, what was the onboarding process to you? Do you just jump in and start writing code and submitting it, or do you have to speak to somebody first? How does that work? Remember, I don’t know anything about this.

Bryan Bishop: Well, there are many paths to doing development work on Bitcoin. Since it’s an open-source project, you can do whatever you want, of course, on your own. However, for new people that want to develop on Bitcoin, my recommendation would be to go find a Bitcoin Core developer, talk with them, and see if they would mentor you or take you under their wing. One interesting way of doing this now, and this has existed in the past, but Chaincode Labs, for example, has residency programs, and they basically train you up to be a Bitcoin Core developer. I think that’s actually a very reasonable way to go forward, and it’s a great way to get introduced into the community, but it’s really not a requirement. I mean, you can just show up and suggest code changes, and attend the IRC meetings, and just talk with people and figure out what they’re working on and where you can fit in.

Peter McCormack: I wouldn’t have thought somebody like myself, who’s never coded anything apart from some basic HTML, would be an ideal candidate, so what kind of work would you expect somebody, what kind of proficiency levels would you expect somebody to be at before they start considering Bitcoin?

Bryan Bishop: Well, there’s actually a wide range of skill sets that can be used for the Bitcoin Core software project. For example, there is a Bitcoin Core website, and there is also a bitcoin.org, which is an unrelated project, but that was originally the website that Satoshi Nakamoto used for releasing Bitcoin. In both cases, as an example, web developers can contribute to content on that site or to features on those sites. Another example is basic testing infrastructure for Bitcoin Core. It has long been noted that there is an inadequate number of tests over various components of the software system, and sometimes writing tests can be easier than other work, so that’s an interesting place to start.

Peter McCormack: Okay. You’ve talked, obviously, about the time when you were working on the project when Satoshi was involved, and we have kind of time pre and after. Did a lot of things change after he left the project, or did everything just kind of carry on as it was?

Bryan Bishop: I wasn’t specifically involved in Bitcoin Core development during that time. However, my observation was that things kind of carried along as they were … I would say there was no noticeable difference.

Peter McCormack: Do you remember your first contribution to the code?

Bryan Bishop: To the code, my first contribution was something called fund-raw-transaction. I was working on an RPC call where you give a transaction without the inputs or without the coins that you’re going to spend, and you ask your Bitcoin Core wallet, “Can you please find coins that would satisfy this transaction?”

Peter McCormack: Is that unspent txs?

Bryan Bishop: That’s right, so Bitcoin Core wallets keep track of your unspent transaction outputs. This is basically the money that you have, and Bitcoin uses something called UTXOs instead of an account model, which is that everything’s a coin instead of an account. You don’t have debits and credits. You actually, you can only destroy and create coins, so if you take a one-value Bitcoin, you can destroy it and create two that are valued at 0.5 Bitcoins, for example.

Peter McCormack: Ah, so that answers something I never understood. There’s a lot of embarrassing questions I would love to ask that I think people would assume you knew, but so I’ve seen it before where it talks about, say, if I wanted to send to you, Bryan, .784 of a Bitcoin, it would make that up from multiple unspent txs, but I was always thinking, “Well, what if there wasn’t multiple unspent txs that made up that value,” but it doesn’t require that. You can just break up other ones.

Bryan Bishop: Specifically, this problem is called coin selection. For the more mathematically inclined, it’s called a knapsack problem. If you have a certain number of coins and you want to spend a certain amount of money, the number of coins you have is actually unrelated to the amount of money you have, because each coin has a different face value, so the question is, what is the optimal way to pick a number of coins to create the amount that you’re spending? Maybe that means, like the most trivial way I could imagine is just sort the coins by their face value and pick the biggest coin, so if you have 100 Bitcoin in a single coin, and you’re spending $15, maybe you just pick the biggest one and make a small output for $15, and then the rest is 99.999 or whatever Bitcoin. Thus, you create a new unspent output, and the other one is, of course, the payment you made.

Peter McCormack: Right. Okay. I spoke to Yeastplume over at Grin recently, and the MimbleWimble implementation is quite different with unspent txs. Right? I think you’re aware of the MimbleWimble work.

Bryan Bishop: I’m aware of MimbleWimble work, but I’m actually not aware of their differences. I don’t know if they’re using a different strategy there.

Peter McCormack: All right. Okay. Okay, so let’s get into some of the things that I want to know a bit more about. Firstly, governance and then kind of what is consensus. We’ll start with kind of governance is. Who can actually make changes to Bitcoin? You’ve said anyone can submit changes of code. When that change gets submitted, how does it get reviewed? Who gets to choose whether it goes live or not? How does that process work?

Bryan Bishop: A very confusing subject. There are questions about Bitcoin Core specifically, but then there are questions about Bitcoin itself because Bitcoin isn’t just Bitcoin Core. As a consequence, there is a lot of confusion around this. Let’s say that someone makes a proposal, and they make a change to the consensus rules for Bitcoin, and they deploy it. If they just run that change on their own node and no one else is, is that change really deployed? Arguably, yes, because it’s running on a node on the network, but arguably no, because no one else recognizes it. In a certain sense, it’s a matter of popularity and adoption.

Bryan Bishop: Now, for Bitcoin Core specifically, there is a mechanical answer that I can speak to, which is that through the GitHub project on GitHub, there are people who have the ability to merge changes into the Bitcoin Core source tree, but these people view themselves more as, I would say, almost more like it’s like a janitorial task, or administrative, bureaucratic task, where after they observed that there’s consensus for a certain change, then they merge it.

Peter McCormack: Is that what’s known as commit access?

Bryan Bishop: Yes. It’s actually known as push access. Anyone can make a commit, but only a few people can push those commits into the GitHub repository.

Peter McCormack: How many people have that kind of access?

Bryan Bishop: I actually don’t know anymore. It used to be about five, but I think that number has grown quite a bit.

Peter McCormack: I was going to say, so is there ever like a rule in place that those five people can’t be in the same room at the same time in case some disaster scenario happens?

Bryan Bishop: No, but it’s actually not a big problem anyway. First of all, I mean, many of the Bitcoin Core developers should, of course, not be in the same room for that very reason, but it’s not for the reason of the GitHub repository, because in the event that there was an unfortunate accident like that, the GitHub repository is not actually a requirement for developing Bitcoin. Anyone can go and make their own Git repository and carry on just fine.

Peter McCormack: Right. Okay, so if that scenario happened, the code can be forked off, a new version of Core exists, and as required, the nodes and the miners would accept that scenario?

Bryan Bishop: Well, I mean, anyone can use any version of Bitcoin Core that they want. Just because it’s not released through GitHub or through bitcoincore.org does not mean that the new version is incompatible with the old one. It’s always a question of compatibility, and this actually gets into another topic that I’m sure you’ll ask about, which is forks and hard forks and soft forks.

Peter McCormack: Yeah. That’s definitely on my list. Okay, so let’s stick with consensus for now. When I was researching, and I’ve heard consensus spoken about a few times in that there are consensus rules for nodes, but there’s also social consensus. What are the different forms of consensus that we should be aware of?

Bryan Bishop: Well, I can talk about two forms of consensus, because these are often confused in the Bitcoin space. One is, there is a consensus algorithm for the Bitcoin blockchain regarding the next block, and there are rules for the nodes for how these are constructed, which is known as mining and proof of work, but then there’s another type of consensus that people like to talk about, which I would consider, or call, more like developer consensus, or community consensus, or something like that. These are two very different things. One is very algorithmic, and it’s specified in the rules of Bitcoin. The other is very much a social phenomenon.

Peter McCormack: Okay. Can you explain the social phenomena for me?

Bryan Bishop: Well, I wish I can understand social phenomena, but unfortunately, I’m a man of limited capacity. The social consensus process is that changes should only occur after they have a general amount of consensus. This can get into very deep weeds as a topic, and there is much question about how this really works, but if any of them … Let’s give a more specific example. If any of the people on GitHub who have push access were to push code that had not been vetted in general, they would very quickly lose their push access, because that’s not okay.

Peter McCormack: Okay. Right. I get that. Okay, so there’s verification rules within Bitcoin, and say somebody is proposing a rule change. What is the process they would go through? Say, Bryan, you think, “I want to make a change here. I think there’s something wrong here.” What’s the process you go from having an idea to it being something being developed? Is this what I’ve heard referred to as a BIP?

Bryan Bishop: There are a number of different types of changes that I can speak about. I’m going to start with the one you didn’t ask about, which is a much simpler change, so just something in the GUI or the wallet. When you change something in the wallet, it doesn’t require a network-wide consensus change, so it’s a much more local thing where Bitcoin Core wallet and the people developing that can talk amongst themselves and decided, “Does this wallet change make sense?” It doesn’t require the consensus of the whole Bitcoin community to make that change. In fact, for many wallet changes and the vast majority of them, no BIP is required. BIPs are Bitcoin Improvement Proposals. They were formally recommended through BIP 1 which was the first BIP, and then, which also describes a process for making BIPs, and that was superseded by BIP 2. The Bitcoin Improvement Proposal process is particularly used for consensus changes or for standards that multiple wallets across the network need to be aware of.

Bryan Bishop: In particular, the way that someone might go about making a Bitcoin Improvement Proposal is that they, in general, they are first, it’s first recommended that they socialize the idea even before they begin writing proposal with the mailing list, on IRC, talking with other developers, and see, is the idea that they’re proposing even conceivably possible in any way? Is there any chance that people are going to want this, or support this, or be in favour of this? If the answer is yes, then they can start to collect the feedback they’ve already received and written a document, a draft document, that describes their idea. Then that is then submitted to the mailing list.

Bryan Bishop: Once this has occurred, then they can send a message to someone who is named the Bitcoin Improvement Proposal process editor, and that’s currently Luke-Jr, to receive a BIP number. BIP numbers are not self-assigned. That’s actually been a big confusion in the community for a long time. The reason for this is because only the BIP editor knows which numbers have been assigned to which proposals. Some of them might not actually be published yet or pushed forward, and so you don’t want people allocating the same numbers for different proposals, which would get really confusing.

Peter McCormack: Okay, so at the point, they’ve circulated the idea, there’s broad agreement that it’s something that’s worth developing. A BIP has been assigned. What then happens? Do they go ahead and start working on it on their own? Do they recruit people to work on it with them? Do people just voluntarily contribute? How does that work?

Bryan Bishop: Well, in general, it’s recommended that someone comes with a small prototype at the time that they’re writing their draft proposal so that people can look over what that is. Often, it is up to the BIP author to make an implementation. In the event that someone really strongly supports the idea, perhaps he’ll find someone who will volunteer to help you with development, but largely, it’s up to the proposer to also do the work.

Peter McCormack: Right. Okay, and once the work’s complete, they make everyone aware this is ready, and it goes into testing. Do you have some form of … I remember when I worked in web dev, I wasn’t a developer myself, but we had something called unit testing. Is that something similar you have here?

Bryan Bishop: Yeah, it’s a really interesting question. You can even get all Yoda on this and ask, “Well, what is ready? What do you know about ready?” It’s a question, because you might consider it ready, but does everyone else consider it ready? Is it ready when it’s been thoroughly tested? Is it ready when it’s ready to be deployed? Is it ready when it’s ready for unit tests? All sorts of stuff, but yes, unit testing is very important. Also, integration testing and functional testing, which are other ways of testing out software on local networks and things like that. Eventually, what will occur for Bitcoin Core specifically, if someone wanted a consensus rule change in Bitcoin Core, eventually after the BIP has been written, they would make a pull request to the Bitcoin Core repository with the change and a link to the BIP and so on.

Peter McCormack: Okay, so at the point where it’s been tested, it’s agreed that it’s fine, it’s ready to be pushed into the Core, what is the process for integrating a completed piece of work into the live code?

Bryan Bishop: Well, look, I mean, if everyone agrees that it’s ready and that it should be deployed, and it’s generally good, and there are no flaming problems, then look, it’s going to get merged into the source code.

Peter McCormack: Okay, and is there a hierarchy amongst developers?

Bryan Bishop: I would say no, but on the other hand, there are definitely people who have more experience than others, and so seeking their opinions and advice is a good idea, but there’s certainly no hierarchy.

Peter McCormack: Okay, and I’ve read about a couple of things. I’ve read about reference implementations and maintainers, and then I read something that potentially a developer can circumvent a reference implementation, maintain, make consensus changes regardless, and that was seen with BIP 148. I’m totally out of my depth here, but can you tell me anything about that?

Bryan Bishop: BIP 148 is an example of … Well, it was calling itself a user activated soft fork, and in particular, this was not merged into Bitcoin Core, because there was no consensus for it as far as the Bitcoin Core developers could tell. What happened was that someone released software that implemented BIP 148 anyway, so the fact that someone went around and implemented BIP 148 in software anyway is kind of interesting, but not that interesting. What’s more interesting is that users adopted that software and ran it, or at least so we think. There is actually no … There’s no really good way to actually measure, “Are people actually using BIP 148,” for example. I think that that was primarily the potential threat of BIP 148 was being used as an argument, and software was really written, and some users made a lot of noise about it, and so on.

Peter McCormack: I guess there was significant worry amongst the miners, then, for the hard fork, right, because this was SegWit2x. How did you feel about all of that, by the way?

Bryan Bishop: Oh, I think that SegWit2x was a huge mistake. It had nothing to do with SegWit, really, and it was produced by a closed-door meeting of companies. It was just totally foreign process that was inappropriate and just morally wrong. We should never do that, ever.

Peter McCormack: A great part of the history of Bitcoin, though, right?

Bryan Bishop: Yeah. It’s very interesting. It will be forever known as a warning of what we should not allow to happen. Around the time of the NO2X event, and then we had SegWit activate, there was also the Bitcoin Cash hard fork that actually used one of the same dates that were planned for activation of SegWit, I think. I should double-check that, but they made a bunch of confusion by choosing the same calendar date. That was really unfortunate because people have a hard time understanding what any of this is. We don’t need like third-party projects coming along and trying to hijack the attention.

Peter McCormack: In terms of, therefore, let’s talk about forks. Let’s talk about, well, what is the difference between a soft fork and a hard fork? I mean, I kind of know, but it would be good to hear you explain it.

Bryan Bishop: A hard fork, in general, is an incompatible change in the rules. A soft fork is a compatible change in the rules. Another way to say that is that a soft fork is a further restriction of rules, so something that was originally valid by the rules becomes invalid. That’s a soft fork. A hard fork is when something that was originally invalid becomes valid, so by definition of a hard fork, the new rule or the new data that uses this new rule is incompatible with the old version.

Peter McCormack: Right, so essentially, if you’re going to have a hard fork, you really want to have one that you know everyone is going to upgrade the software to.

Bryan Bishop: Yes, that’s right. It’s actually very hard to know, “Is everyone going to upgrade?” It’s maybe even impossible to know.

Peter McCormack: How many hard forks have there been in the history of Bitcoin itself, which don’t include those which have hard forked off to become new codes?

Bryan Bishop: Well, I believe that number is zero. There’s some dispute about this, like people pointing to old changes very early on in Bitcoin where something could have been a hard fork, but it wasn’t, and it just didn’t occur, but yes, I believe the number is zero.

Peter McCormack: Wow. Do you think, are there any hard forks that are almost certainly on the horizon? Is there any particular work that you think is required in Bitcoin that will require a hard fork?

Bryan Bishop: For Bitcoin specifically, I don’t believe any hard forks are on the short-term horizon. As far as I know, all of the developers that I know about that are working on changes are working on changes that could be deployed as soft forks, which is actually really good news, which means that for these changes and improvements to Bitcoin to occur, there doesn’t need to be protocol-breaking changes where everyone needs to jump up and down all at the same time. It’s like that thought experiment, like what would happen if everyone on the planet stood outside, and they all jumped at the very same moment? What would happen? That’s what a hard fork is.

Peter McCormack: So we kind of have ideas, but nobody really knows.

Bryan Bishop: Well, they do know, and in some cases, they know how to make them into a soft fork. In fact, Luke-Jr was a big part of that for SegWit. He realized that there was a way to get the improvements of Segregated Witness into Bitcoin using a soft fork, because, before his idea, the Bitcoin Core developers assumed that it could only be done through a hard fork.

Peter McCormack: What do you make of all the other hard forks, then? Do you believe any of them have any value and have you taken interest in any of them, the ones that have become other coins?

Bryan Bishop: I have not taken an interest in them. I don’t really want to talk about them that much, but what I found particularly interesting from a market perspective, and I very rarely comment about market price, but for quite a while, Bitcoin Cash had a market price that was relatively high, above $1,000 even. I was actually using that as an indicator of the market conditions because I said that as long as Bitcoin Cash is above, I don’t know, $500, I know something is very wrong. Sure enough, now it’s down to like $50 or whatever today.

Peter McCormack: Okay, so back to the code, so I’ve recently spoke with Jimmy Song about the CVE bug, and that was something that, obviously, it kind of raised some interest and potentials that exist within Bitcoin that code has bugs, right, and this is a multibillion-dollar protocol that could one day hold trillions in value. How much do you worry about things like bugs?

Bryan Bishop: Well, first, CVE stands for Common Vulnerabilities and Exposures. The bug that you’re talking about is CVE-2018–17144, otherwise known as the inflation bug, which was that there was a potential vulnerability in the source code that, in certain circumstances, could have been used to cause inflation. Thankfully, it was not used that way. Everyone does their very best work on Bitcoin. Everyone tries to do their best. Unfortunately, bugs will happen, and this gets into something known as security disclosure or sometimes responsible disclosure. There are bugs in Bitcoin, some that we know about, some that we don’t. Of the ones that we know about, some of them are actually not all public knowledge.

Bryan Bishop: This is an interesting problem itself because Bitcoin Core has been forked many tens of thousands of times into separate projects, many altcoins, for example. If every vulnerability was to be reported immediately to the general public, the consequences would be that many downstream projects wouldn’t have time to update. In fact, when Bitcoin fixes security vulnerabilities, sometimes, the fix has to be released, and deployed, and put into a new, updated version of Bitcoin Core before anyone is made aware that those problems existed, because if they’re made aware that those problems existed, then bad people could try to exploit those problems by attacking people who haven’t upgraded yet, so as a result, there’s actually a lot of problems and concerns about vulnerabilities beyond just, “Is the code secure itself?” There’s also, “How do you manage all these problems,” as well.

Peter McCormack: Is there like a secret group of kind of conversations, or discussions, or forums where these bugs are logged, and there’s like a secret way of working on them? How does that work?

Bryan Bishop: I can’t speak too much to the security process, but there is an email address where you can send bug reports that are of a more security-related nature that I do recommend people to use. Generally, what I’ve found is that when there is a security issue, what happens is that someone will ping me, or usually someone else, and not actually say, “Hey, there’s a problem here,” but they’ll say, “Hey, could you look at this chunk of code and try to attack it? Can you think of anything here that could cause a problem?” Then someone will grind away and try to figure it out, and sometimes this person will find like five other issues, and those will end up being really important to fix, too. Long-term, I think everyone knows what they have to do to make Bitcoin more secure. Something that we would all like to see happens is something called formal verification.

Bryan Bishop: Another thing that we’d all like to see happen in addition to formal verification is the separation of code into separate modules, which is just a general thing for good sanity and hygiene of software. Formal verification is a mathematical way of guaranteeing that the software does what it says it’s doing. Right now, there is no way to actually formally verify the complete source code of Bitcoin Core. It’s just enormous. It would be the largest formal verification project ever by a factor of 1,000. Formal verification usually only works on small, isolated systems. Code separation into separate modules definitely helps with security, because you have separation of concerns, which makes it much easier to think about the security implications of different changes, or certain interfaces and architecture.

Peter McCormack: Do you have any kind of feeling that, because of the way it’s been developed and built over the years, has it kind of gotten unwieldy? Is there … Again, I’m out of my depth, but do you have different bits of code here talking to other bits of code here and it’s just almost like, would it be great to restart, and refresh, and build it all again, if it … For example, you have software upgrades at companies or website upgrades, and sometimes, you just start fresh. Obviously, doing that with Bitcoin would be very difficult because of the way Bitcoin is but is there almost that desire to start again?

Bryan Bishop: Well, I wouldn’t say there’s a desire to start again, but there’s definitely a problem from early on in Bitcoin, because of the way that the software was written, everything was put into a file called “main.” Everything that Bitcoin did was in a file called “main,” and over time, the developers have separated out all of that code into separate files. “Main” still remains, but it’s certainly not the monster it once was.

Bryan Bishop: This actually causes a lot of development headaches, though, because if you have 100 open pull requests, each doing different things, affecting different parts of the system, and you move any out of main and in another pull request, well, everyone else has to update their work as well to accommodate for your changes, and so you get into this gridlock situation where the resources and planning required to accommodate that sort of massive change all at once is just enormous. As a result, the only way forward that people have figured is to chip away at it little bits at a time.

Peter McCormack: Right, okay, so … Okay, that makes sense. I’ve once, I think it was Nic Carter I interviewed, and he said it would be great in the future, at some point, for the Bitcoin Core base code to calcify and hardly have any changes, the only changes are absolutely necessary fundamental ones. Do you have any thoughts on that, and is that something Core developers think about?

Bryan Bishop: Yes, people definitely think about this. In fact, I can take that a bit further and say that some people believe that everything should be moved into a library called “libconsensus” which would only be the consensus code, and all the wallet code, as an example, would be moved into another project that would use libconsensus. In fact, an even more extreme view that some developers have, although certainly not all of them, is that there should never be any hard forks, and that’s the calcification that they’re looking for, is that the projects should always be just that version, and you might be able to do soft forks, but definitely no hard forks.

Peter McCormack: Is this one of the reasons why development for, like appears to be slow? I mean, I have it down for two reasons, careful consideration about what work is important, what changes are important, but also, it just seems like there’s, it takes time to make upgrades which are going to work without issues on Bitcoin, and it almost feels like those who are complaining that it’s too slow are really just being impatient.

Bryan Bishop: I would argue that Bitcoin Core development is actually quite fast. The reason why it may appear slow at times is because the type of work that Bitcoin Core developers are doing is basically inscrutable. If you’re not a software developer, sometimes, you don’t know anything about what’s going on here, but it is actually quite fast. In particular, one example that I can point out is that many of the changes are related to scalability and improvement, where without those changes, the Bitcoin Core software would not be able to keep up with the amount of data in the blockchain, you wouldn’t be able to sync your nodes, purely because of a speed issue or a processing issue, and many of the improvements that go on are related to that scalability, but you don’t really think about that when you run Bitcoin Core. You see it syncing, and you’re like, “Okay, great, what else can it do,” but there’s actually a tremendous amount of work that has gone into Bitcoin Core to make that happen.

Peter McCormack: For you, are there any specific areas of development or the development procedure that you think need vastly improving? Is there anything where you think that it needs a significant restructuring in the way things are done?

Bryan Bishop: No, I would say there are no particular areas where there needs to be a massive change. Sometimes, it feels like there needs to be more brainstorming about possible solutions because it’s not always clear that the best ideas are actually around in the list of potential solutions, but that’s just me, though. I mean, I don’t know if that’s shared among other developers.

Peter McCormack: In terms of layer 2 and Lightning, how involved are you with that?

Bryan Bishop: Oh, I watch what’s happening with Lightning, but I haven’t been developing on any of the Lighting nodes or anything like that.

Peter McCormack: But are you excited by Lightning? Do you like the work being done there?

Bryan Bishop: I think Lightning is a great idea. I think that it’s really important, and all payments in Bitcoin should really be using Lightning.

Peter McCormack: Oh, really? Okay, interesting, so if-

Bryan Bishop: Well, okay, hold on. No, hold on. That’s probably not true. Hold on. Payments in Lightning are much faster. You can use Bitcoin for payments, but if you need that speed, that’s where Lightning comes in.

Peter McCormack: Okay, so what’s the current status of Lightning? Because for me, like I use Bitcoin. I send Bitcoin. I’ve had an attempt at mining, and I’ve received my Bitcoin, and I’ve paid for it using Bitcoin, and it’s great. I still don’t find that, Lightning, as accessible yet as, say, transactions with Bitcoin.

Bryan Bishop: Yeah, I would agree with that. I would say that right now, if you’re using Lightning, you’re an early adopter. Onboarding for Lightning is probably the biggest pain right now. There are apps and wallets that help you get onto Lightning, and they improve the process, but there might be more work that could be done there. I would say that once you’re already set up with the Lightning channel, I think that the general experience is basically right, and there are wallets out there that you can use to use Lightning.

Peter McCormack: But is Lightning still at that point now where it’s considered in beta? I’ve read about it, and it said, “Don’t send any significant amounts on Lightning. You still may lose it,” so what’s the status there?

Bryan Bishop: Well, I mean, Bitcoin is also considered somewhat beta.

Peter McCormack: Yeah.

Bryan Bishop: Yeah, Lightning is definitely beta, but on the other hand, we also see the #reckless, where people are doing reckless things with Lightning. Yeah, I mean, look, I mean, if you’re an early adopter and you understand some of these risks, go ahead and try to use Lightning. Don’t put your life savings into it. Try it out, and give feedback to the Lightning developers.

Peter McCormack: So there’s no real hard and fast state where people are going to say, “Right, we’re ready.” It’s going to just, over time, confidence build in Lightning.

Bryan Bishop: Oh, yes. I would argue that there would, their adoption will occur over time and just ramp up. I would not say there’s going to be a moment where the Lightning developers will say, in unison, “All right, everyone needs to start using Lightning right now.”

Peter McCormack: Would you feel confident sending 50 Bitcoin on Lightning at the moment?

Bryan Bishop: I personally wouldn’t put 50 Bitcoin on Lightning. I would put maybe, I don’t know, at most, maybe … Oh, gosh, I mean, half a Bitcoin, maybe, at most.

Peter McCormack: Oh, yeah, okay. Well, I’ve got my node coming. I’ve got a Casa Node coming in the next two weeks, so that’s going to be my first experience in playing with it, and I’m going to have a go.

Bryan Bishop: Oh, you mean the hardware node.

Peter McCormack: Because that comes with a wallet, right?

Bryan Bishop: I actually, I don’t have one, but sounds really interesting.

Peter McCormack: Yeah, no, I find Lightning super interesting, and I’m really looking forward to being able to start to play with it. I found some of the works that Alex Bosworth, is it Alex Bosworth-

Bryan Bishop: Yes, that’s right.

Peter McCormack: … is doing? Yeah, I find that super interesting, so I think that’s pretty cool. Okay, so how much are you involved in Bitcoin at the moment, or have you started to work on other things?

Bryan Bishop: Well, at the moment, what I mostly do for Bitcoin Core, specifically, is I sometimes do code review. I moderate the mailing list, and I keep track of discussions and things like that. I would say, oddly enough, another thing that I do for Bitcoin are my transcripts, which is what most people know me for, which I find a little bit odd, but nonetheless, they are very helpful transcripts. I go to conferences, and I happen to be able to type very quickly, and so, usually, before the talk is done, I’ve posted a complete word-for-word transcript on Twitter, at twitter.com/kanzure. People find that very helpful, and now I have like multiple years of hundreds of different talks and transcripts available. A lot of it is from Bitcoin Core developers, so it’s chronicling development ideas and things like that.

Peter McCormack: What would you say right now, in terms of Bitcoin, what are the most important things that are going to be coming in the future?

Bryan Bishop: Well, some of the interesting things that I’ve like to think about include confidential transactions, Schnorr signatures, signature aggregation, and MimbleWimble. Confidential transactions are pretty interesting, but unfortunately, they have a large cost in the size of the transactions, but basically, the idea is that confidentiality over the amounts is very important, because it improves the fungibility of Bitcoin. Fungibility is a very important concept for money, because if money is tainted, then it sort of loses its property that it is exchangeable for any other unit of value in the same system. It remains to be seen whether confidential transactions can get into Bitcoin. I think it might require one more push from someone to try to really reduce the size of those, of the technique.

Peter McCormack: Tight, so is that where MimbleWimble’s interesting, then?

Bryan Bishop: MimbleWimble is interesting because I think it could eventually be used as a side chain to Bitcoin to improve fungibility, yeah.

Peter McCormack: Right, but to get fungibility on the main chain, like I’ve heard various people … There are some people who want it, and there’s also some people who don’t actually want it, right, and I’ve heard that’s maybe the next potential civil war within Bitcoin, is around fungibility. Is that a potential?

Bryan Bishop: I don’t know about civil wars. I think that in general, fungibility cannot be argued against, because while there might be people who disagree with the value of privacy, the benefit of fungibility is also that it tends to cause less space to be used, which is a scalability improvement which people seem to like. If you argue against fungibility, you’re arguing against scalability, although some fungibility techniques, or privacy techniques, do actually cost more in size, but, I mean, ultimately, when you think about it, if you don’t have the data in the blockchain, then it’s taking less space.

Peter McCormack: Right, so if fungibility is so important, why is it not a kind of Core thing that lots of people are focused on building into Bitcoin now?

Bryan Bishop: Oh, it absolutely is something that a lot of people-

Peter McCormack: Oh.

Bryan Bishop: … are focused on building. The real trick, though, is finding the right proposal that can get consensus and picking a technique that will actually stand the test of time. It’s a hard problem.

Peter McCormack: Are there lots of different competing ideas for this at the moment that are being worked on?

Bryan Bishop: Oh, yes. There are many different ways to try to improve fungibility and privacy in Bitcoin. I’m pretty sure there’ll be an upcoming BIP for something called Taproot. That’s just one example, and that’s partly competing with other proposals, such as Merkelized Abstract Syntax Trees where you don’t have to reveal your whole script, which could be like other multisig scenarios that you don’t want to reveal exist in the event that you need multiple signers in a Bitcoin script.

Peter McCormack: But thinking of user experience, somebody like myself who isn’t technical, doesn’t understand a lot, if I use something like Monero, I know I’m sending something which is anonymous. Is the ultimate goal for Bitcoin to have almost the same?

Bryan Bishop: I don’t know that’s the ultimate goal of Bitcoin. I think that a lot of developers are very interested in that, and they are hoping that eventually, they’ll be able to release a way that you could choose to do that. I doubt that it’ll ever be the case that we can force everyone to be fully anonymous. There’s no way to force people to be anonymous. People can just choose to be more private.

Peter McCormack: Right, okay, so if it’s optional, would that be something like with Zcash?

Bryan Bishop: That’s one way to think about it. I mean, like right now, you have the option of using CoinJoin. You could use JoinMarket, for example, and join CoinJoins to increase the privacy of your own personal wealth. A lot of those techniques, the privacy of those techniques depends on the size of what’s called the anonymity set, or the number of people that are participating in this project.

Peter McCormack: Right. Okay. To someone like me, this sounds a bit complicated and not user-friendly enough to be something I would just go and use as a regular everyday user.

Bryan Bishop: Yeah. A lot of the developments in Bitcoin, there’s certainly a gap between what’s happening, deep research side of Bitcoin, and what people know about. It’s sort of an interesting question. How much of that needs to be communicated to the general public? I think actually more of it probably needs to be communicated because the people don’t know what the research possibilities are and what Bitcoin Core developers are thinking. Then by the time that the software actually gets written and ready for deployment, people won’t know what any of this is.

Peter McCormack: What do you make of fungibility and the impact on things like KYC/AML? Do you think there’s a risk, therefore? For example, imagine it was for base chain privacy with Bitcoin, that something like Coinbase would have to remove Bitcoin because of KYC/AML restrictions?

Bryan Bishop: Oh, I strongly disagree with that. I actually believe that if Bitcoin had a tremendous amount of privacy, even in that case, someone like Coinbase, I don’t mean to pick on them, but some company could choose to add KYC and AML on top of that. Even with confidential transactions, as implemented in, for example, Blockstream’s Elements product or Liquid product, users who use their confidential transaction technology have the option of sharing their blinding key with an auditor or with the recipient of their transaction, so it’s actual privacy where you can opt-in to share the information with other people. In the case of a company that needs to do KYC or AML, that would be another situation where the company would simply require the user to share that information with the company for the company to continue to process the transaction.

Peter McCormack: Right. Okay, and then there, outside of fungibility, what other key things are going on with Bitcoin?

Bryan Bishop: Well, in terms of the overall state of Bitcoin, obviously some people are a little upset about the current market price. I think that there’s actually a lot to look forward to. There are three things I can highlight. One is that, at some point, there will be a Bitcoin ETF. I think that’s going to be very exciting. Second is that there’s going to be the halvening again in 2020, mid-2020. Third, there are a lot of changes coming up that could be soft forks to Bitcoin that will improve all sorts of aspects of Bitcoin, both on privacy and scalability. I think those are very interesting and worth looking forward to. One further thing that I could mention is sidechains. I think that side chains have finally gotten good steam behind them, and they’re going. These are very interesting ways of experimenting with Bitcoin without impacting the whole Bitcoin network.

Peter McCormack: Right. I mean, I agree on the ETF. I’ve met with Hester Peirce at the SEC, and I’ve also interviewed Gabor over at VanEck. I believe one will come at some point. I think that will be very interesting, but I don’t know if this is something that just comes with time. I’m becoming less and less interested in price, caring less about price. The only reason I … If you get over your own personal bias and potential financial gain, the only reason to care about price, because price usually sometimes is a reflection of growing adoption, but I’m trying to get away from the bias of that and just focus on what I would like to see happen with Bitcoin. I don’t … Is that something you’ve found that over time you just start to care less about price?

Bryan Bishop: Oh, absolutely. In fact, many people are surprised to learn that many Bitcoin Core developers also don’t care about the market price of Bitcoin. It’s literally not a thought in their mind. They do not wake up thinking, “How do my actions impact the Bitcoin market price?” That is such an alien thought to many of the Bitcoin Core developers. A lot of people find this odd, but, I mean, it sort of makes sense. A lot of people learn about Bitcoin in the news, and what’s in the news about Bitcoin more than anything is its price, so that’s what most people think about, but there is a whole universe to Bitcoin in its development, and developers, and its community around it that is just completely unrelated to the price, and it’s just based off of building good technology that people will want to use.

Peter McCormack: Then the last couple of questions, and by the way, this is really great. I know these are probably questions seem super basic, but actually, I know from the work I do there are many people who have an interest, but they’re just a bit nervous to ask, so this stuff’s really helpful to hear about, but are there any controversial opinions that you have with regards to Bitcoin, things that should happen, or things that should be done in a different way that isn’t really shared by others?

Bryan Bishop: That’s a very good question. I don’t actually have anything to give you, though.

Peter McCormack: So they maybe exist, but you just don’t want to share it with me.

Bryan Bishop: No, it’s more that they aren’t occurring to me.

Peter McCormack: All right. Okay. Okay. Fair enough. Are there enough developers in the world of Bitcoin at the moment?

Bryan Bishop: Well, that’s an interesting question. Are there enough developers in Bitcoin? I would say that the answer is both yes and no. There could always be more developers. We need more code review. We need more testing, but on the other hand, Bitcoin still has been, is being improved, so one aspect, that’s fine enough.

Peter McCormack: As somebody who’s been involved in the project, pretty much you’ve been aware of it since the very start, one of the few people who have, what do you kind of make of it all now, 10 years in? Are you blown away by what’s been achieved? How do you kind of make sense of it all?

Bryan Bishop: Oh, I don’t know if that’s possible. Bitcoin is just very cool technology. I often use an analogy, too, and this is sort of geeky, but I use an analogy to Star Trek where they have something called the Prime Directive, which is that as an advanced society, they have this rule that they cannot share their technology with primitive societies. I make an analogy to that because this is what happens when that occurs. Bitcoin is what happens. Some of the drama we see in the news just gets entirely off the charts because society isn’t really ready for Bitcoin yet. I think that’s part of the problem, is that hard money is just such a foreign, alien concept that people will just freak out so much about it. I mean, money is a very personal issue for a lot of people. What is money? When you really think about it, when you get really philosophical about it, money is such a weird phenomenon, and then we have Bitcoin come in, which is software money. The software is weird enough as it is, but now you have to marry the two together, and that’s just another level of weird.

Peter McCormack: Right. Okay. All right. Last two questions. What do you think is required to increase the adoption of Bitcoin outside of the geeks and the early adopters to see wider spread adoption? What do you think is most important?

Bryan Bishop: I think that Bitcoin needs to get over the idea that it will never be regulated. There will be companies that work with regulatory authorities to introduce Bitcoin to more consumers. I think this is actually an important step, and we must be careful to talk with regulators and explain what this technology is and what the options are, because otherwise, they’re going to get scared, or they’re not going to understand it, and they’re just going to make up some stupid stuff. I think that everyone, even the regulators, actually want what’s in the best interest for both the technology, the users, and the general public. I do actually think that listening to regulators or working with them will be important for achieving that.

Peter McCormack: Okay. That’s a very good point. Okay. Last question, how can people help and support the Bitcoin project who aren’t technical, people like me? How can someone like me help Bitcoin?

Bryan Bishop: Well, there are a few interesting ways. One is that you can help share educational materials and developer materials and things like that. Just general education is very important.

Peter McCormack: Bryan, how can people stay in touch with you? Who do you want to hear from? Do you want to hear from anyone?

Bryan Bishop: Yeah. If you want to keep in touch, follow me on Twitter. Twitter.com/kanzure. Thank you.

Peter McCormack: Fantastic. That was great, Bryan. Thank you so much for your time.

Bryan Bishop: Yeah. Thank you.

Connect with What Bitcoin Did:Listen: iTunes | Spotify | Stitcher | SoundCloud | YouTube | TuneInFollow: Website | Email| Blog | Twitter | Medium | Instagram | YouTube

Core Developer Bryan Bishop on Building Bitcoin was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.