The Truth About 'Power' in Bitcoin
Speakers: James O’Beirne
Date: April 11, 2019
Transcript By: Michael Folkson
Media: https://stephanlivera.com/episode/66/
https://twitter.com/kanzure/status/1198289594069983237
Stephan Livera: Hello and welcome to the Stephan Livera podcast focused on Bitcoin and Austrian economics. Today my guest is James O’Beirne, Bitcoin Core engineer working at Chaincode Labs. Here’s the interview. James, I’m a fan of what you are working on over at Chaincode Labs and welcome to the show.
James O’Beirne: Thanks Stephan. It’s good to be here. I’m a fan of your podcast, so it’s my pleasure.
Stephan Livera: Thank you. Yeah so look,I thought it would be great to get you on just to talk about a few different things. One of them is this concept, perhaps it’s a little bit elusive for some people, but essentially it’s what is the true nature of quote unquote power or control within Bitcoin? And there are obviously differing conceptions of this. The point is not to kind of go and bash Angela Walsh right, but that’s one example of perhaps a more top down view of Bitcoin. And from some of her recent appearances, she’s made commentary around this idea that maybe Bitcoin is, and she’s speaking perhaps about cryptocurrencies in general, she’s saying “Maybe they’re not as decentralized as they first appear to be.” Do you have any thoughts on why that might not be a complete view?
James O’Beirne: Yeah, well, first of all I think Angela is a really well-spoken and pretty well thought out thinker in terms of this stuff. And I think it’s only reasonable to be decently skeptical. Especially if you’re not someone who’s necessarily a programmer or has an intuition for how a system like Bitcoin might work. I think it’s a good idea to ask these questions about who’s really in control of these sorts of systems. But yeah, I think power is an interesting word and, not to get too deep into semantics here, but I think power to me is kind of predicated on forcing someone to do something in systems of government where governments basically have a monopoly on power and society. Or I’m sorry, a monopoly on physical force. I think that word is very germane. But in a system like Bitcoin where the participants are all voluntary and the code is all freely available and open and can be forked and modified, power is maybe not the right word. Even assuming, let’s, sort of charitably assume some kind of figurative notion of power in the sense of, who is really controlling the system, who’s deciding what the rules are and who’s affecting the participants. I think that’s where things get somewhat murky in these system relative to more conventional financial systems.
Stephan Livera: An excellent point. I think being able to essentially know who is compelled to do something and even if they don’t necessarily want to do that thing. I suppose one aspect that we can’t neglect as well, looking at Angela’s recent appearance on Peter McCormack’s show, part of her message, there was this idea of we need to slow down the integration of Bitcoin into financial institutions, so to speak. Now I’d suggest at a more fundamental level, the anarcho-capitalist, libertarian cypherpunk does not seek the existing state’s approval for Bitcoin but seeks to create a parallel system. So that’s one very fundamental challenge that the cypherpunks would reply back. But perhaps even setting that aside, it’s just that question around is it an accurate view? We can go into some examples. So one example Angela brings up is the recent, I think it was September ish of 2018, it was the CVE 2018-17144 inflation bug. And so Angela is pointing out how that incorporated some coordination from known core developers such as Matt Corallo. So she was seeing that supposedly the fact that there were some things only known to a small group of core developers and not the broader set of Bitcoin users as an example of why Bitcoin is not that decentralized. How do you conceive of that?
James O’Beirne: So to your first point about libertarian cypherpunks not necessarily giving much consideration to the sort of financialization of Bitcoin. I’m sympathetic to that in one sense but I think in another sense that realistically to bring people into the fold… If say my mom wants to buy Bitcoins or something, you know there needs to be some integration there. And we will I think see institutions build on the layer of abstraction of Bitcoin in the same way that ISPs are built on TCP/IP and web services built on HTTP. I think we have to expect that. I think what sort of complicates things is if you’re in a position like Angela’s and you’re trying to analyze how these things work and make sure that the base of your sort of abstraction pyramid is solid. Then it’s a little bit more difficult because power or whatever you want to call it, and Bitcoin are so finely dispersed, but we can get a bit more into that. In terms of the inflation bug I think that is a really interesting case study to look at because yeah there were only five or maybe seven of us who heard about that when it was reported to the mailing list. But I think one interesting way to frame that is to think, let’s say that your operating system had some critical zero day reported to the developers how would you want those developers to act? I think secrecy isn’t really the right word here because all the fundamental elements of that situation were public. The code is public. And so I don’t think it’s necessarily accurate to say that we were keeping a secret. We weren’t going out and broadcasting that there was this huge vulnerability, but anybody who could look at the code and do careful analysis could see that narrow possibility of inflation was there. And indeed there was one guy, I think one commenter on Hacker News who pointed out that particular vulnerability might extend beyond denial of service and into inflation. So this isn’t a case where you’ve got a company and they’ve got some bad financial data hat they’re keeping behind closed doors and not telling anybody. It may sound superficial but I don’t think it is that this information is all public and anybody can see it. I don’t think we’re necessarily in a unique position other than the fact that we saw it and the developers of Bitcoin Core wanted to do their best to respond accordingly.
Stephan Livera: Agreed. I think it’s a great analogy that you draw there on. Let’s say this was an open source operating system and that there was a small group of developers who knew of a massive vulnerability there. You wouldn’t necessarily want them to go out and publicize that. So in fairness to Angela, I didn’t think she was faulting the treatment of that 17144 inflation bug. I suppose also, although I agree with you, it may also be fair to say that right now, not everyone can read the code and that’s just a fundamental reality we have to face.
James O’Beirne: Yeah, absolutely. I think one of the other things that she talks about is the potential of introducing some kind of official fiduciary system to the development of Bitcoin in the sense that core developers would function as these fiduciaries and be somehow officially recognized and on the hook. I think it’s really important to realize that morally we are, because we’re in the position of working on the software. Anybody who contributes code to Bitcoin, I think is in some sense morally like a fiduciary. That doesn’t mean that introducing some kind of official position or hierarchy or credentialing makes any sense. In fact, I think that would be really counterproductive because then you sort of solidify a real power structure in Bitcoin instead of having this sort of fluid voluntary arrangement where contributors can come and go. So yeah I think I can understand the impulse to want to assign responsibility. But I just don’t think doing it in some formalized way makes a lot of sense.
Stephan Livera: Right. I think the other problem there from the kind of cypherpunk point of view, this is kind of a point that someone like Nick Szabo might make, is that it introduces another whole political argument attack surface that if developers were to become fiduciaries and there were additional legal ramifications or obligations placed upon them that this could become another angle of centralization and attack on Bitcoin.
James O’Beirne: Yeah, totally agree there. I think it’s also worth emphasizing that in a situation like the inflation bug, she talks about how rapidly a change was deployed to Bitcoin and how Matt got on the phone to Slushpool and said “Hey here’s a fix.” I think it’s really important to realize that you shouldn’t conflate a rapid response with a command and control structure just because the participants in the system responded really quickly and at each individual step voluntarily elected to upgrade the software based on the information they were given. That isn’t the same as the core developers saying “Ok, now you must run this software or else you’re kicked off of Bitcoin.” It’s really easy I think for it to look like it was some kind of power structure when instead it was a rapid realization as soon as somebody was made aware of a bug. It’s like obviously we should upgrade. So there is a match of individuals saying yes or no to to be given change.
Stephan Livera: Right. So an example. If I had to explain that, I would say something like Bitcoin fundamentally is peer to peer network consensus. Guys like Pierre Rochard and many others have helped explain that it’s network consensus and that we all voluntarily run the code. Perhaps that’s one aspect that Angela is not quite conceiving of correctly because ultimately just because core developers put out some code doesn’t mean everyone’s going to run it, right?
James O’Beirne: Yeah, absolutely. I think that’s a totally critical distinction. If you draw that maybe over-exaggerated analogue to say at the Federal Reserve, if some rules are changed at the FOMC I can’t opt out of that. As a user of the US dollar I’m subject to that and that’s what I would say is a real exercise of power. Whereas if the core developers introduce some new rule, I can say yes or no to that. It’s definitely tractable to sort of bootstrap a separate system that, either says no to a given change or makes a change that the original code didn’t make. As we’ve obviously seen with the the Bitcoin Cash group. So I think it’s a really subtle distinction, but I think the key thing to keep in mind is that everyone transacting on Bitcoin, if they’re doing so with a full node, they’re opting into their rule set and they can modify that rule set as they like. I think that’s a really critical distinction. Now, I mean to not be simplistic. I think what gets complicated is you have institutions that build on top of certain systems and you have a plurality of large organizations that recognize a certain Bitcoin, right? So if you know, Bitfinex and Coinbase disagree on what Bitcoin is, which system, which consensus rule set that represents them that can get kind of hairy. But I think it’s critical to recognize that each of those institutions has agency to pick one or the other. It’s not like anyone’s really able to dictate what the right Bitcoin is which makes an analysis of control fairly difficult but it keeps the system very resilient and fluid in terms of responding to takeovers like SegWit2x.
Stephan Livera: I think another point that you made that I just wanted to really highlight and make sure listeners don’t lose is the fact that people moved quickly on this does not necessarily mean they were forced into it. I think there are parallels in the way that some people view government regulation of markets. They might say things like “Oh, look, all those four big competitors move their prices together at the same time. Maybe that’s a cartel or maybe there’s some kind of hidden arrangement there.” At the same time, that could also be each of those four competitors in the market actually just shifting to adjust and recognize the changing conditions in the market. There’s different supply and demand. They all individually wanted to change their prices. So in a similar sense, every honest Bitcoin miner wanted to change to run the code that was not vulnerable to the 17144 bug.
James O’Beirne: That’s totally spot on. It’s often hard to disentangle correlation from causation.
Stephan Livera: So it’s just another example of that. I suppose while we’re on that topic of the inflation bug, this is actually a similar question I asked Jameson (Lopp) and I’m wondering what your thoughts are. Let’s say the inflation bug had been exploited on Bitcoin’s mainnet rather than just on testnet. Do you believe there would have been sufficiently strong consensus to roll back to a non-inflationary chain?
James O’Beirne: I would be surprised if that didn’t end up happening. Obviously this is speculation on my part as an individual and not a reflection of the Bitcoin Core repository or anything. I think on the one here we probably would have reorged. Obviously we would have realized that pretty quickly because people were monitoring for that. But we probably would’ve done a reorg. This is again another situation where you have a collection of individuals coming together, presumably delegates from the major exchanges and so forth and they would opt in on an individual basis or something like that. I have a hard time seeing a case where that wouldn’t have happened. But at the same time I think it would’ve been a huge setback for the system in terms of general trust in the technology. But it’s hard to say. Yeah, I’m not really confident one way or another there but I do think that likely. There is this sort of interesting mechanism there in terms of these sort of agreed upon roll backs for interpretation or like the spirit of the law versus the letter of the law. But obviously you want to be careful there because I think the DAO reversion was pretty objectionable in my opinion. I certainly wouldn’t want to see Bitcoin ever go down a road like that. But I think if you had a technical fault at the level of the inflation bug or when we had the accidental fork back in 2013 due to a LevelDB misconfiguration, that was an example of a reorg that happened as a result of something deeply technical. So it would surprise me if we didn’t resolve that with a reorg, the inflation bug. But on the other hand things have been pretty contentious in terms of the whole SegWit activation thing. So I almost wouldn’t be surprised if that turned into a snafu itself. It’s hard to say.
Stephan Livera: Yeah, good points. Intuitively I think most people who buy into Bitcoin do so because of the 21 million hard cap and therefore they probably would support this kind of action. But obviously you do have to consider that if it took time to realize and then do the correction, those people who did a transaction in the period before getting rolled back and their transactions got reorged out, they would lose out in this. So the question then would be what would be best for the overall system and would people actually do that? Another related question around Bitcoin forking. Let’s say Bitcoin does integrate more deeply with financial services and then there’s ETFs. Do you have any thoughts on what might be appropriate fork detection and fork policy for ETFs if they were to offer Bitcoin investment?
James O’Beirne: Yeah, that’s a really good question. I think that’s another tough one to codify. In general one of my broad responses to Angela’s critiques was that as soon as you start to really put structure around metrics like decentralization or which fork is the right one or who should be a contributor and who shouldn’t be, I think you introduce these models that can be gained and exploited. And so in general, I really like the fluidity of how Bitcoin as a system is organized. Going back to what you said earlier about people being incentivized to protect their coins in the case of the inflation reorg. I think provided everyone is properly incentivized then the system just kind of works like in the case of the inflation bug. If you’re a miner you’re incentivized not to exploit that bug because obviously if you do that then your significant capital costs are gonna go to waste. And so I think having incentives set up in the right ways is the really important thing. Coming up with concrete metrics for things like forks and which fork is right one, I don’t have any great answers there for you. In a technical sense detection is pretty easy. But in terms of having some kind of automatic guidance for an ETF that’s a bigger question that I didn’t think about. But generally I’m optimistic even in light of a lot of my uncertainties about Bitcoin and maybe my inability to articulate the way these dynamics work. I’m very encouraged because I think that in general there’s a sort of intolerance of the minority in Bitcoin consensus in the sense that it’s easier to constrict the protocol. Like a soft fork versus a hard fork is really just a constriction of the rule set whereas a hard fork is an expansion of the rule set. So when you do a hard fork you’re basically allowing things that were previously invalid to be valid. So it’s a lot easier to go in the other direction and make things that were previously valid, invalid. And so that’s the way that the Bitcoin ends up changing. I think that makes it a lot more likely that the attributes of Bitcoin that we all rely on in terms of its identity, the 21 million coin cap and the fact that we validate signatures, those things are going to stay intact. We’re just going to keep layering rules on instead of having these sort of cataclysmic changes to Bitcoin’s identity. So in terms of which forks will win out if there are forks, I can’t tell you that, but I can tell you that there’s a very promising streak of conservatism in Bitcoin’s culture and rule set.
Stephan Livera: Excellent thoughts. I think you’re right to point out the many difficulties in this. The second you start placing certain metrics, those metrics can be gamed. Then a person who’s trying to maliciously fork Bitcoin could try to perhaps influence the fork in such a way as to influence the way an ETF might under its rules or its charter be forced to decide “This is the true Bitcoin”. Then we’re entering back into this whole game of political governance as opposed to the Bitcoin approach which is more like peer to peer network governance.
James O’Beirne: Absolutely right.
Stephan Livera: I think another interesting question that I can throw at you here is compared to the idea of quote unquote power or control, how about the concept of influence? What are the legitimate ways a person, perhaps they’re a developer or not, how do they gain influence in Bitcoin? Is it skillful contributions? Is it leadership? Is it education?
James O’Beirne: Yeah, I think it’s all the above. At the risk of sounding trite I think it’s one of the closest examples of a meritocracy that I’ve ever participated in. Becoming influential in Bitcoin is really predicated on doing good work. And whether that’s being a good speaker or hosting a good podcast or filing a good pull request or in the case of David Harding doing excellent technical writing, there are all kinds of ways you can contribute. I think your recognition in the community, much like other open source communities is really predicated on exemplifying good work. I haven’t really seen counterexamples of that. I think what’s important is I’ve seen examples of people who were in official positions. I don’t necessarily want to name any names, but maybe some of the former key holders of the Bitcoin Core repository who were in these officially recognized positions to the extent that there are in the Bitcoin ecosystem. They didn’t just hang on to that position just because they were there. As soon as they stopped contributing materially or as soon as the quality of their contributions wasn’t recognized by the community at large then their tenure there ended. So I think that’s a really important demonstration of just how meritocratic Bitcoin actually is.
Stephan Livera: Just to paraphrase that, that’s sort of saying there are certain positions that to an outsider might look like they hold a certain level of power. But in reality, whether you’re a Bitcoin Core maintainer or whether you have the Bitcoin alert keys or whatever, it doesn’t necessarily mean people will at the end of the day run your code. And ultimately so long as there are enough people who monitor code and advise less technical people. “Hey, don’t run this code because it’s got a bug or this code has 22 million cap instead of 21 million cap.” Then people can choose which code they wish to run.
James O’Beirne: Right, exactly. I was actually reading Angela’s paper which is called “Deconstructing the decentralization: exploring the core claim of crypto systems”. I was reading that earlier today just to brush up and as I was reading I thought of an interesting thought experiment, which is let’s say you had a team of shadow core devs who hadn’t made anything at all public. Basically just schooling up on Bitcoin behind the scenes without telling anybody and just diligently working. And then you had us doing what we’re doing today. If this shadow team of core devs came out of the woodwork and came up with all these awesome improvements and demonstrated competence that was well above what we’re doing today. They went and individually convinced the community and the various businesses involved with their coin that they were better stewards of the protocol than the current Core contributors. You could see an immediate switch like they could immediately displace us. There’s no sort of incumbency.
Stephan Livera: Fire the Core Devs James! [Laughing]
James O’Beirne: Exactly. Yeah. [Laughing]. That can’t happen in, say, a publicly owned company. I guess in the market place it can happen. But yeah, I think that the very fact that that is a possibility undermines this idea of a power structure.
Stephan Livera: It reminds me of those movies where you’ve got the clone of you but it’s like you with slightly more intelligence or certain other capabilities and there’d be like the shadow Pieter Wuille and the shadow Greg Maxwell.
James O’Beirne: Yeah, exactly. They all have beards if the original doesn’t have a beard and is clean shaven if the original has a beard.
Stephan Livera: That’s right. It’d be like the maximum stats version and then you’ve got to try to compete against your shadow self who can code better.
James O’Beirne: Make for a good movie.
Stephan Livera: Yeah. Bitcoin Core: the movie. So what about this one? I think you were touching on this idea of conservatism within Bitcoin. To what extent is inertia keeping Bitcoin the way it is? There is a very famous philosophical experiment or thought experiment, the idea of the ship of Theseus. Could we ever see a scenario where every piece of Bitcoin has been changed? But slowly, step-by-step over time but it’s still recognized as Bitcoin in the eyes of the HODLer.
James O’Beirne: Yeah. I think this is a really interesting topic. I love the ship of Theseus. That comes up a lot in my personal life. I’m really hoping that Bitcoin will eventually ossify. If you think of the HTTP protocol, in their early days somebody introduced a status code 418, I’m a teapot, on top of your more familiar status codes like 200 success and all that. They were able to do that I think in the early days because it was a young protocol, it was very malleable. Someone could come along and suggest a status code they had for April Fool’s day and that could happen. But as the years went on and as HTTP was deployed widely you’re not able to change it as much. I’m really hoping that Bitcoin shortly gets to the point where it’s just so solidified and so consistent that changes are really rare. But I think you have to realize that there’s basically this continuum between decentralization in it’s perfect sense and the ability to change. So if you’re perfectly decentralized and no one person has sway or influence greater than anyone else, you can’t make changes to the system. Whereas on the complete opposite end of the spectrum, if there’s a Bitcoin CEO then tomorrow an edict can come down that we’re going to go in a particular direction and change can happen very rapidly. So when Satoshi was initially writing this code that was obviously on one end of the spectrum and he was in complete control but as it was deployed and adopted by other people and had institutional growth around it and a big community of developers come up and a huge user base, then we started to slide down that continuum towards, towards decentralization. So I think as we slide further and further that way then it becomes harder and harder to make big changes. Ultimately one day we’ll end up with a very cemented idea of what Bitcoin is and all the innovation and change will happen on the second layers. We’ll have the good fortune of having a very steady unchanging protocol to sit on top of.
Stephan Livera: Fantastic points. Another interesting question to bring up related to that. It’s true right now to say that if you download and ran Bitcoin from the early days, assume you did some minor fixes, for example that Berkeley Level DB fix back from 2013 that Bitcoin code would still sync to Bitcoin as it is today. That’s right?
James O’Beirne: Yep.
Stephan Livera: That may not always be true in the future though as I understand. There may be hard forks coming in the future. So for example, this Y-2038 bug, that one won’t be mandatory for another 80 years or so. Or perhaps there’s some kind of hard fork required to someday bring in quantum resistant cryptography. We have that right now that we can say, “you download the early client from the early days and it’ll sync up to Bitcoin as it is today” but perhaps that won’t always be true in the future?
James O’Beirne: Yeah, I think you’re right about that. I know that the amount we can do with soft forks is pretty significant. But to be honest with you, I’m not a consensus expert. And so while I know that we can do some pretty impressive things, I think that there is a certain class of things that we may need to do with hard forks. It’s really hard to say ahead of time exactly what those will be. Certainly you point out the Y-2038 bug but we have a good amount of time to figure that out. think maintaining backwards compatibility is an absolutely huge consideration and it would take something exceptional. Something that was mandatory or threatened the network in a very profound way to abandon that backwards compatibility. I can’t say with certainty when or if that day will come.
Stephan Livera: Yeah, fair points to make there. I think we’ve done enough on this whole idea, this concept of power and change in Bitcoin. Let’s talk a little bit about the mailing list suggestion that you came up with. I think it’s called assume UTXO. Do you want to tell us a little bit about what spurred this idea and what’s the background on it?
James O’Beirne: Yeah, sure thing. So anybody who’s ever set up a bitcoind node is familiar with the idea that you have to do a pretty lengthy process called the initial block download when you first start up your Bitcoin node. That process is sort of key to what Bitcoin is because it entails getting data about the blockchain from the peer to peer network i.e. other people running the same software that you are downloading those blocks from. Then connecting the blocks to form the full blockchain and in the meantime verifying everything. So that process is totally critical to Bitcoin. But it takes a long time so now if you go and set up a Bitcoin node if you have a really, really fast computer with a really great internet connection, it should take on the order of like four hours. But unfortunately, if you’re on a lower power device like a Raspberry Pi and maybe have spotty internet, it could take upwards of three, four days. So as a result, people who want to transact on the Bitcoin network are incentivized to use solutions that don’t provide the full degree of security that a full node does. You can download a light client like Electrum or many of the other wallets available. Those programs operate under a mode called simple payment verification or SPV. Basically those programs don’t do any kind of full verification of blocks. They retrieve the headers chain, which is given by miners. But if they want detailed information they have to go out and request it from other nodes on the network and trust based on the headers chain that it’s accurate. So that’s not great. Obviously anybody who’s using one of these light clients isn’t doing consensus validation and isn’t helping the network by serving blocks. And so we want to do everything that we can to make it easy for people to participate in that kind of complete way. So this idea of assume UTXO is one way of expediting that initial set up process so that you can start to use Bitcoin with a slightly modified security model but you’re still able to fully validate blocks as they come in. You’re stable and still able to transact freely, immediately. So the general idea of it is that as we’re building up the blockchain we maintain this data structure called the UTXO set. The UTXO set is basically the set of unspent transaction outputs that we have. So we keep that in a kind of map for easy look up. The idea of assume UTXO is if you can take a snapshot of this data structure and hash its contents, then you could say “Hey, at height 500,000 I expect a UTXO set whose contents hash to this value.” If you can then build that into the software then what you can do is load what I call a UTXO snapshot, which is a serialized version of the UTXO set. It is only about three gigabytes relative to the 200 gigabytes that a full blockchain is. So you can load that in and you can kind of fast forward your blockchain up to that point, then do a sync from the network to get to what we call the tip or the latest block that the network has seen. That takes on the order of a constant amount of time relative to the linear amount of time with respect to the length of the blockchain. So after you’ve loaded your chain relatively quickly, then in the background you can start to do an initial block download from scratch. The point of doing this is to fully validate the point up to where you started the snapshot. So if you’d like, we can talk a little bit about the details of how this all works but that’s the general point.
Stephan Livera: I suppose what it’s doing then is essentially setting up Bitcoin Core in such a way that a newbie can download it and just use it much faster. While in the background they could still download the full blockchain data and do their own verification. But at the start, place trust into certain trusted individuals. I suppose depending on how it’s set up, there might be certain Core developers who they are trusting implicitly to give the correct hash of the UTXO set. Is that correct?
James O’Beirne: Yeah, I might phrase it a little bit differently. So right now there is a parameter in Bitcoin Core called assumevalid and this is the hash of a block at a certain height. When we’re doing this initial block download we just assume that all previous blocks have had valid signatures up until that point. The idea being that there’s so much work on top of this point that it’s sort of ridiculous to think that those signatures would not be valid assuming the block hashes match. So the way that parameter is established is an open review process that is just another pull request against the Bitcoin Core repository that anybody can comment on, dissent, disagree with or spot-check. And so this would be an analogous process and I can see someone having a gut reaction that’s like, “Whoa, you know, trust in the developers, what’s going on here?” But really these parameters, if nothing else, are sort of a clearer indication of where you are trusting other people. For every change that’s merged into Bitcoin, unless you’re scrutinizing the code changes then you really can’t be certain that that’s not doing something nefarious. Whereas with these parameters, it’s a very clear indication that you should try to validate what’s going on here. You should during this review process, try to reproduce, get the same hash and make sure that this is actually the thing that you want. So in the case of assume UTXO, it’s really just a continuation of the same assume valid model that’s currently in Bitcoin.
Stephan Livera: What’s the response been? I noticed there was some discussion of other ideas such as a FastSync by Nicolas Dorier for BTCPay Server. I suppose that is essentially an indicator that people are already trying to do this kind of thing. So was that part of your thinking as well, maybe it’s time to have something similar in Bitcoin Core directly?
James O’Beirne: Yeah, exactly. I think it’s pretty clear to me that people are going to start doing something resembling this process, whether or not Bitcoin Core facilitates it. I think it’s really important to do it the right way because this would be an easy thing to screw up if you were to try to build something on your own. For example, with FastSync I think it’s cool that Nicolas has experimented with this stuff and gotten something that works for his use case. But I think if you were to really industrialize that or recommend that a lot of people use it, it wouldn’t be a great outcome. Now instead of really scrutinizing the Bitcoin Core repo and following changes there, you basically have two sources that you really have to scrutinize. So you have to scrutinize Bitcoin Core and you have to make sure that you’re checking out all this other stuff: Nicolas’s private repo and implicitly trusting Nicolas there. Furthermore Nicolas’ FastSync relies on being signed, doing GPG signing by him and other people check this thing out. This kind of signature verification is a notoriously under attended process by users. So we want to build something into Bitcoin ultimately that is secure without you having to download your bitcoind program and then go somewhere else and download the UTXO snapshot and verify the signatures. I just don’t think many people will actually do that and that introduces a profound security risk. So we really want to do this the right way. We really want to think it through and take our time to roll something out that really works and has a high degree of security. So far the reception has been pretty positive. It’s still kind of early, the mailing list post went up last week so I think we’re going to take a decent amount of time to gather feedback. If anybody has any thoughts on this stuff then I encourage them to reach out to me. I think this is a really good demonstration of the sort of process that we were alluding to earlier when we were talking about the influence structure of Bitcoin or the “power dynamics”. This is super early in the pipeline and almost anybody can get involved and express their outlook here. So I encourage you to do so.
Stephan Livera: Fantastic. James, while we’ve got you here, let’s talk a little bit about the process of Core development. I think some of my listeners might like to hear some insights that you might have if they would like to contribute code, if you have any wisdom to share with them.
James O’Beirne: Yeah, definitely. I think the prospect of working on Bitcoin Core is a really exciting one. It’s something that I encourage anybody interested in software engineering to take a look at, but it’s really, really hard. It’s a really hard thing to get involved with because there’s a tonne of context. The subject domain is inherently complicated and it’s an environment where everybody is rightfully suspicious of everybody else because of the critical nature of the software. I guess my advice to people who are really interested in becoming contributors is that we sometimes see new contributors come along and jump into the codebase and they think “OK I want to make a change. I want to make a productive contribution. I’m going to go through and do a bunch of refactoring or I’m going to bring the codebase up to C ++ 14 or C++ 11 standards.” Someone will file this, this giant PR that changes a few keywords or shuffles a few functions around. What they may not necessarily realize is that refactoring in Bitcoin Core is a really kind of dicey prospect because it’s a project that’s unlike many others in the sense that any marginal change to Bitcoin has to be really thoroughly scrutinized. And so sometimes shuffling stuff around because it’s a better design or because it’s marginally more easily comprehensible isn’t always the right move because it’s a huge vulnerability or it’s a huge opportunity for things to go wrong. So as a result I think my advice is if you really want to get involved, then start to participate in the review process and watch changes. Maybe pick an area or two of the codebase where you feel like you’re really interested and have the capacity to understand, read through yourself. Maybe pick a few high level operations, like how does initial block download work or what happens when the software receives new blocks from the network and step through the code, figure out what’s happening. Then try to participate in the review process. After you browse some of the issues in the issue queue, there’s a tag called the good first issue which I recommend checking out. Maybe eventually you come up with a useful change and submit it and it gets accepted. So that’s generally my advice for people who want to get involved. I know it’s just a really strange project. It’s, unlike for sure any other software project I’ve worked on just because of the level of scrutiny and the level of care that the developers involved have to take.
Stephan Livera: I’ve seen examples where someone tried to refactor certain code and it took like a year to deal with all the different pieces of feedback that came up and all the constant other changes that were happening. Are there any insights you can share around that?
James O’Beirne: Totally. Russ Yanofsky who’s another employee here at Chaincode has been working on separating the wallet from the node in an effort to make development easier. There are certain changes we could then rule out as not being consensus critical because they’re in a separate process. He came up with his draft for this more than two years ago. He had a functioning prototype and a bunch of changes proposed. If you were at a software company working on some closed source piece of software, you might expect his change to be fairly substantial but it might be merged within a month or two. But it’s two years later and, he’s done a really great job of making this change granular and having a lot of patience and persistence in getting it through. But we’re still in the middle of that project and there’s still a lot of review to be done. So it’s just a completely different ball game in terms of the level of detail and scrutiny involved.
Stephan Livera: Yeah, there’s a lot there, a lot to unpack there. How about any areas where Bitcoin core development differs from other software projects?
James O’Beirne: Working on Bitcoin Core is counterintuitive to a lot of conventional software wisdom. For example, one of the things that is thought a lot about is how to reduce dependencies. So typically in a software project when you’re working on accomplishing something you want to go out and find preexisting libraries that can help you do whatever it is you want to get done. So you might go out and find an object relational mapper or if you want to deal with a database, pull that in or some kind of a web framework. But in Bitcoin any additional dependency that we take on is a vulnerability because it’s a codebase that’s changing outside of the life cycle of Bitcoin. It might have a lot of extraneous code that we don’t necessarily need. And so as a result, we really want to avoid inclusion of dependencies. We’re trying right now to strip out Boost which is a C++ library that does a bunch of different things. We’re trying. I think we’re close if not done with stripping out OpenSSL. At this point we’ve implemented a lot of the crypto that we need so that’s definitely a departure from conventional software engineering. Like I mentioned earlier refactoring for the sake of refactoring is sort of discouraged. So refactoring only happens when there’s a really, really practical reason for it. In general, the iteration cycles are much longer. The burden of review is a bit higher. So you might need multiple contributors to approve your changes before they go in. And in general it’s beneficial to take things a bit slower and to make sure that we’ve thought through all the changes that eventually do go in.
Stephan Livera: Fantastic. I think we’re pretty much coming to time. So James, if you’ve got any closing thoughts or parting thoughts you want to leave for the listeners feel free to give them that now. And also lastly tell them where they can find you and follow you.
James O’Beirne: Sure. Yeah keep using Bitcoin is my only thought. The Federal Reserve is doing some pretty interesting stuff. So I sleep a lot better at night knowing that Bitcoin is alive and well. I hope that continues to be the case. And it can’t happen without users. So keep using Bitcoin. In general, I’m on the internet at @jamesob on Twitter and the same on Github and you can email me at james@chaincode.com.
Stephan Livera: Fantastic. Thanks James. It has been an excellent discussion. Thank you so much for coming on.
James O’Beirne: Thanks a lot Stephan. It was a pleasure.