SLP66 James O’Beirne – The truth about ‘power’ in Bitcoin

Posted in: bitcoin Posted on

James O’Beirne, Bitcoin Core Engineer at Chaincode Labs joins me in this episode to talk about the real nature of ‘power’ and control within Bitcoin. It’s not as simple as it might first seem! We talk about:

  • Differing conceptions of ‘power’ in Bitcoin
  • Peer to peer network governance
  • Bitcoin Core development
  • Assume utxo

James O’Beirne links:

Discussed in episode:

Podcast Transcript:

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 and one example, right? And the point is not to kind of go and bash Angela Walsh right, but that’s one example of perhaps a more kind of top down view of Bitcoin. And from some of her recent appearances, she’s made commentary around this idea that, okay, maybe Bitcoin is, or, and she’s speaking perhaps about cryptocurrencies in general. And she’s saying, Oh, well look, maybe they’re not as de-centralized 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. You know, I think it’s a good idea to, 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. And you know, 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’s, that word is very germane.

James O’Beirne: 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, you know, is maybe not the right word, but you know, even assuming, you know, 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, you know, affecting the participants. And I think that’s where things get get somewhat murky in these systems. So relative to you know, more conventional financial systems,

Stephan Livera: Right. And excellent point. I think around being able to essentially who is compelled to do something and even if they don’t necessarily want to do that thing. And one, I suppose one aspect that, you know, we can’t neglect as well. So looking at Angela’s recent appearance on Peter McCormack’s show, part of her message, there was this idea of, Oh, 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, you know, the cypherpunks would reply back. But perhaps even setting that aside, it’s just that question around is it an accurate view? And I mean, we can go into some examples.

Stephan Livera: So one example Angela brings up is the recent can’t remember exactly when, I think it was sort of September ish of 2018 so it was the CVE 2018-17144 inflation bug. And so Angela is pointing to 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 is an example of why Bitcoin is not that decentralized. How do you conceive of that?

James O’Beirne: Yeah. so to your first point about you know, libertarian cypherpunks not necessarily giving much consideration to sort of financialization of Bitcoin. I mean, I’m sympathetic to that in one sense, but I think in another sense that realistically to, to bring people into the fold and to, you know, if if say my mom wants to buy Bitcoins or something, you know, there, there needs to be some some integration there. And we will, I think see institutions build, you know, on the layer of abstraction of Bitcoin in the same way that you know, ISPs is built on TCP/IP and web services built on HTTP. And so I think, I think we have to expect that. And I think what sort of complicates things if, 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.

James O’Beirne: Then it’s a little bit more difficult because, because power, you know, or, or whatever you want to call it, and Bitcoin is so finely dispersed, but we can get a bit more into that. In terms of the inflation book I think that is a really interesting case study to look at because yeah, there were only, you know, five or maybe seven of us who kind of heard about that when it was reported to the mailing list. But I think, one interesting way to frame that is to think, okay, if, if let’s say that your operating system had some, you know, critical zero day reported to the developers, the operating system you know, how would you want those developers to act? And I think like a secrecy isn’t, isn’t really the right word here because all the fundamental elements of that situation were public.

James O’Beirne: Like the code is public. And so I don’t think it’s necessarily accurate to say that like we were keeping a secret. I mean, we weren’t going out and like broadcasting that there was this huge vulnerability, but anybody who, you know, could look at the code and do careful analysis could see that, you know, that narrow possibility of inflation was there. And indeed there was one guy, I think one commenter on hacker news who, who sort of pointed out that that particular vulnerability might extend beyond denial of service and into inflation. So, so this isn’t like a case where you’ve got a company and like, you know, they’ve got like some bad financial data you know, that they’re sort of keeping behind closed doors and not telling anybody. It may sound superficial, but I don’t think it is that this, this information is all public and anybody can see it. And so I don’t think we’re necessarily in a unique position other than the fact that, you know, we saw it and the developers of Bitcoin core wanted it to do their best to sort of respond accordingly.

Stephan Livera: Oh, agreed. I think it’s a great analogy that you draw there on even, 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. And you know, that 17144 inflation bug. And I suppose also, you know, 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. And I think one of the other things that she talks about is the potential of introducing some kind of like official fiduciary system, the development of Bitcoin in the sense that, you know, that that core developers would function as these fiduciaries and be somehow, you know, officially recognized and on the hook. And, well, I think it’s really important to realize that that morally we are, because we’re in the position of working on the software. Anybody who contributes code to Bitcoin, I think in, some sense morally as like a fiduciary. That doesn’t mean that introducing some kind of official position or hierarchy or credentialing makes any sense. And in fact, I think that would be really counterproductive because then you sort of solidify you do 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, and I think the other problem there from the kind of cypherpunk point of view here is that introducing, and this is kind of a point that say someone like Nick Szabo might make is that it introduces another whole attack service of this kind of a political argument surface that if, you know, developers were to become fiduciaries and there were additional legal kind of ramifications or obligations placed upon them that this could become another angle of centralization and attack onto Bitcoin.

James O’Beirne: Yeah, totally agree there. And I think it’s also worth emphasizing that like in a, in a situation like, like the the inflation bug, you know, she talks about how rapidly a change was deployed to Bitcoin and how, you know, Matt got on the phone to Slushpool and said, Hey, you know, here’s a fix. I think it’s really important to realize that there that you shouldn’t conflate a sort of rapid response with a command and control structure because just because the participants in the system responded really quickly and you know, 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, okay, now you must run this software. You know, 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 of it, it was a rapid realization of, you know, Oh, as soon as somebody kind of was, made aware of a bug, it’s like, okay, obviously we should, you know, upgrade.

James O’Beirne: So there is it’s sort of like a very fine you know, match of individuals saying yes or no to to be given change.

Stephan Livera: Right. So an example. Okay. So if I had to kind of explain that, in other words, I would say something like Bitcoin fundamentally is a peer to peer network consensus. So that’s kind of like, as you know, guys like Pierre Rochard have helped explain and others, many others have helped explained that it’s a network consensus and that we all voluntarily run the code. And so perhaps that’s one aspect that Angela is not quite conceiving of correctly because ultimately just because you core developers put out some code doesn’t mean everyone’s gonna run it, right?

James O’Beirne: Mm hmm. Yeah, absolutely. I think that’s a totally critical distinction. You know, if you sort of draw that maybe over-exaggerated analogue to say like 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, I’m sort of subject to that and that’s I would say a real exercise of power. Whereas if the core developers introduce some new rule, I can say yes or no to that. And 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. You know, as we’ve obviously seen with the the Bitcoin cash group so yeah, 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 as they like.

James O’Beirne: And 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 sort of disagree on what Bitcoin is, which system, which consensus rule set that represents then, I mean, 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, you know anyone’s really able to dictate what the, what the right Bitcoin is. So that, really, again, it sort of makes an analysis of control fairly difficult, but it keeps the system very resilient and fluid in terms of responding to takeovers like SegWit two X.

Stephan Livera: Yeah. And I think another point that you made that I just wanted to really highlight and make sure listeners don’t lose that point either is how you were mentioning the fact that people moved quickly on this does not necessarily mean they were forced into it. And I think kind of there, there are parallels in the way that some people view government regulation of markets. So they might say things like, Oh, look, all those four big competitors move their prices together at the same time that maybe that’s a cartel or maybe there’s some kind of hidden arrangement there, but 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, so to say there’s different supply and demand and whatever. They all individually wanted to change their prices. So in a similar sense, every, honest Bitcoin miner wanted to change to obviously run the code that was not vulnerable to the 17144 bug. Yeah,

James O’Beirne: That’s totally spot on. And you know, it’s, it’s oftentimes hard to disentangle correlation from causation.

Stephan Livera: So it’s just another example of that, yeah, exactly. Okay. And I suppose while we’re on that topic of the inflation bug, do you believe, this is actually a similar question I asked at Jameson (Lopp) actually, and I’m wondering what your thoughts are. Let’s say the inflation book had been exploited on, you know, Bitcoin’s main net rather than just on the test net. Do you believe that would have been sufficiently strong consensus to roll back to a non-inflationary chain?

James O’Beirne: Yeah, it’s, I guess I would be surprised if that didn’t end up happening. I mean obviously this is like speculation on my part as an individual and not a reflection of the Bitcoin core repository or anything.

Stephan Livera: Yeah, yeah, yeah.

James O’Beirne: I think it would have been on the, on the one here that I think that we probably would have reorged. I mean, obviously we would have realized that pretty quickly because people were monitoring for that. But we, we probably would’ve done a reorg. And I think, you know, this is again, another situation where you have a collection of individuals coming together you know, presumably delegates from the major exchanges and so forth and you know, they would opt in on an individual basis to something like that. I have a hard time seeing that, like seeing a case where that that wouldn’t have happened. But at the same time you know, 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 that likely, you know there is this, this sort of interesting mechanism there in terms of these like sort of agreed upon roll backs for interpretation of sort of like the spirit of the law versus the letter of the law.

James O’Beirne: But obviously you want to be careful there because I think the DAO reversion was, was pretty objectionable in my opinion. And I certainly wouldn’t want to see Bitcoin ever go down a road like that. But I think if you had a sort of technical fault at, at at the level of the inflation bug or, you know, when we had the, the accidental fork back in 2013 due to a levelDB misconfiguration you know, that that was an example of a reorg that happened as a result of something deeply technical. So you know, it would surprise me if we didn’t resolve that with, with the reorg, the inflation bug. But on the other hand, I mean things 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. So it’s hard to say.

Stephan Livera: Yeah, good points. I mean, it’s kind of intuitively, I think most people who buy into Bitcoin do so because of the 21 million hard cap and therefore probably they 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 of this obviously. So the question then would just be what would be, what would be best for the overall system and would people actually do that? But I think another related question and just around, you know, Bitcoin forking and so on. Have you had any thoughts on, let’s say Bitcoin does integrate more deeply with financial services and so on and then there’s ETFs, do you have any thoughts on what might be inappropriate fork detection and fork, you know, policy for ETFs if they were to offer, you know, obviously Bitcoin investment?

James O’Beirne: Yeah, that’s, that’s really good question. I think that’s, that’s another tough one to codify. You know, I think 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 you know, which fork is the right one or you know, who should be a contributor and who shouldn’t be, I think you introduce these, these models that can be kind of gained and exploited. And so in general, I mean, I really like the fluidity of how Bitcoin as a system is organized. And I think, you know, going back to, to what you said earlier about about people being incentivized to sort of you know, protect their coins in the case of the inflation reorg. I think provided everyone is sort of properly incentivized then, you know, the system just kind of works like in the case of the inflation bug you know, if you’re a minor you’re incentivized not to exploit that bug because you know, obviously if you do that, then your significant capital costs are gonna go to waste.

James O’Beirne: And you know, so, so I think like having incentives set up the right ways, the really important thing and, and coming up with, you know, concrete metrics for things like forks and like, which, which fork is right one. I just, you know, I don’t have any great answers there for you. I mean in a technical sense for 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, I, I’m optimistic, you know, 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 like intolerance of the minority.

James O’Beirne: There are an intolerant minority in the Bitcoin consensus. In the sense that almost it’s, it’s easier to sort of 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 sort of go the other direction and make things that were previously valid, invalid. And so that’s the way that the Bitcoin ends up changing. And I think that makes a lot more likely that the attributes of Bitcoin that we all sort of rely on in terms of its identity, you know, the 21 million coin cap and you know, the fact that we validate signatures those things are going to stay intact and 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, you know, 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: Yeah. Excellent thoughts. I think you’re right to point out the many difficulties in this. In the second you start placing certain metrics, those metrics can be gamed. And so 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, you know, under its rules or its charter might be forced to decide “Oh this is the true Bitcoin”. And then we’re kind of entering back into this whole game of you know, political governance as opposed to, you know, the Bitcoin approach, which is more like peer to peer network governance.

James O’Beirne: Absolutely right.

Stephan Livera: And I think, yeah, sure. And I think another interesting question that I can throw at you here is, as compared to the idea of, you know, quote unquote power or control, how about the concept of influence? What are the legitimate ways a person who 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. And 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, you know being good speaker or hosting a good podcast or filing a good pull request or you know, say in the case of David Harding doing excellent technical writing you know, there are all kinds of ways you can contribute. And I think your recognition in the community, much like other open source communities is really predicated on exemplifying good work. And I haven’t really seen counterexamples of that. I mean, I think what’s important is I’ve seen examples of people who were in you know, official positions.

James O’Beirne: I don’t necessarily want to name any names, but you know, maybe some of the former key holders of the Bitcoin core repository who you know, were in these, these officially recognized positions to, the extent that there is in the Bitcoin ecosystem. And they, you know, sort of didn’t, didn’t just kind of hang on to that position just just because they were there. You know, as soon as they start stopped contributing materially or as soon as the quality of their contributions, wasn’t really sort of recognized by the community at large than you know, their tenure there ended. So I think that’s a really important demonstration of just how meritocratic Bitcoin actually is.

Stephan Livera: Right. And I think the other, well perhaps just to paraphrase that, that’s sort of saying there are certain positions that might 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, it doesn’t mean people will at the end of the day, will they run your code? And ultimately if so long as there are enough people who perhaps monitor code and sort of advise kind of less technical people are, Hey, don’t run this code because it’s got a bug or this bar, this code has 22 million cap instead of 21 million cap. Then people can choose which code they, which they wish to run.

James O’Beirne: Right, exactly. Yeah. And I was actually I was 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 kind of brush up and I kinda did as I was reading, I thought of an interesting thought experiment, which is let’s say that you had a sort of team of like shadow core devs who, hadn’t made anything at all public. You know, were basically just schooling up on Bitcoin behind the scenes without telling anybody and just like kind of diligently working. And, then you had us kind of 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 and above, you know what, what we’re doing today. And they went and you sort of individually convinced, you know, the community and you know, the various businesses involved with their coin that, that they were better stewards of the protocol then, you know, the current core contributors. You could see an immediate switch, right. 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] Like please but 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 kind of undermines this idea of, of like a power structure.

Stephan Livera: Right? Yeah. It sort of reminds me of those movies where you’ve got the clone of you but it’s like you with like slightly more intelligence or certain other capabilities and there’d be like the shadow Pieter Wuille and the shadow Greg Maxwell and

James O’Beirne: Yeah, exactly. 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. You know, it’d be like the maximum stats version and then you’ve got to like try and compete against your shadow self too. Who can, you know, code better.

James O’Beirne: Make for a good movie.

Stephan Livera: Yeah. I think, Bitcoin Core: the movie, yeah. Okay. So what about this one? So to what extent, and I think you were touching on this around this idea of conservatism within Bitcoin. So to what extent is inertia keeping Bitcoin the way it is? And one concept there might be, and this is like a very famous kind of philosophical experiment or thought experiment, is this idea of the ship of Theseus. So 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 a really interesting topic. And I love the ship of Theseus. That comes up a lot in my personal life. But yeah, I, you know, I’m, I’m really hoping that basically Bitcoin will eventually ossify. And you know, if you think of like say the HTTP protocol in their early days somebody introduced a status code 418, I’m a teapot you know, on top of your, more familiar status codes like 200 success and all that. And they were able to do that I think in the early days because it was a young protocol it was very malleable. And someone could come along and suggest, you know, 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 know, you’re not able to change it as much.

James O’Beirne: And I’m really hoping that Bitcoin rather shortly gets to the point where it’s just so, so solidified and so consistent that changes are, really rare. But I think you have to realize that there’s basically this continuum between you know, decentralization in say it’s perfect sense and the ability to change, right? So if you’re perfectly decentralized and everybody’s you know, 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, you know, Bitcoin CEO, then tomorrow an edict can come down that we’re going to you know, go in a particular direction and change can happen very rapidly. So I think, you know, 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 by other people and you know, 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.

James O’Beirne: And so I think as we slide further and further that way, then it becomes becomes harder and harder to make to make a big changes. And ultimately one day we’ll end up with a very cemented idea of what Bitcoin is and, and all the innovation and change will happen on the second layers. And you know, we’ll be we’ll have the good fortune of having a very steady unchanging protocol to sit on top of.

Stephan Livera: Right. Fantastic points. And I think another interesting question to bring up related to that is, okay, so it’s true right now to say that if you download and ran Bitcoin from the early days, and my understanding is 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: Now the question is that may not always be true in the future though, as I understand, there may be hard folks coming in the future. So for example, this Y-2038 bug though obviously not obviously, but that one won’t be kind of mandatory for another 80 years or so. Or perhaps there’s some kind of hard fork required to someday bring in quantum resistant cryptography. So we sort of we have that right now that we can say, yes, Bitcoin, you know, 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 that we can do with soft works is pretty significant. But to be honest with you, I’m not 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. But it’s really hard to say ahead of time, you know exactly what those will be. And I mean, certainly you point out the the Y-2083 (2038) bug but you know, we have, we have a good amount of time to figure that out. And I think maintaining backwards compatibility is an absolutely huge consideration and it would really take something exceptional. Something that, you know, was, was mandatory or kind of threatened the network in a very profound way to abandon that, backwards compatibility. So yeah, I can’t say with certainty when or if, that day will come.

Stephan Livera: Yeah, fair points to make there. James. look, I think we’ve done enough on this whole idea of con, this concept of, you know, power and change in Bitcoin. Let’s talk a little bit about you had a mailing list suggestion that you came up with and 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 set up a Bitcoind node in the past well I guess 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. And that, 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 them. And 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, you know, 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.

James O’Beirne: But unfortunately, if you know you’re on a sort of lower power device like raspberry PI and maybe have spotty internet, it could take upwards of three, four days. So as a result, you know, people who want to transact on the Bitcoin network are kind of incentivized to using solutions that don’t provide the full degree of security that a full node does. So you can download a light client, say like Electrum or many of the other wallets available. And those programs operate under a mode called simple payment verification or SPV. And 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 sort of request it from other nodes on the network and, and just sort of trust, you know, based on the headers chain that it’s accurate.

James O’Beirne: So that’s, that’s not great. And obviously anybody who’s using one of these light clients isn’t doing consensus validation 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, to, to participate you know, in that kind of complete way. So this idea of assume UTXO is one way of kind 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 and you’re stable and still able to, transact freely, immediately. So the, the general idea of it is is that as we’re building up the blockchain, we maintain this, this data structure called the a UTXO set.

James O’Beirne: And the UTXO set is basically the spent of the set of unspent transaction outputs that we have. So we keep that and in kind of a map for easy to look up. And the idea of assuming UTXO is if you can take a snapshot of this data structure and hash its contents, then you could say, Hey, you know, at height 500,000 I expect a UTXO set whose contents hash to this value. And if you can then build that into the software then basically what you can do is load what I call a UTXO snapshot, which is a serialized version of the UTXO set, which 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 and then do a sync from the network to get to what we call the tip or the latest block that the network has seen.

James O’Beirne: And that takes you know, on the order of a constant amount of time relative to you know, linear amount of time with respect to the length of the blockchain. So after you’ve sort of loaded your chain relatively quickly, then in the background you can start to do an initial block download from scratch. And 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, of how this all works, but that’s the general point,

Stephan Livera: Right? And I suppose just to re say that 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 take on, download the full blockchain data and do their own verification. But at the start, sort of put place trust into certain trusted individuals. And I suppose depending on how it’s set up, you know, there might be certain core developers who 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, so right now there is a parameter in Bitcoin core called assume valid and this is the hash of a block at a certain height before which 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 basically there’s so much work on top of this point that it’s sort of ridiculous to think that that those signatures would not be valid assuming the block hashes match. So the way that 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 and dissent or disagree with or spot-check. And so this, would be an analogous process and, and I can, I can see someone kind of having a gut reaction that’s like, Whoa, you know, trust in the developers, what’s going on here?

James O’Beirne: But really these parameters, if nothing else, are sort of a clearer indication of where you are trusting other people because for every change that’s merged into Bitcoin, you know, unless you’re scrutinizing the code changes then then you really can’t be certain that that’s not doing something kind of nefarious. Whereas with these parameters, it’s a very clear indication that Hey look, you should try and validate what’s going on here. You should during this review process, try and reproduce, get the same hash and make sure that this is actually the thing that you want. So anyway, in the case of assume UTXO, it’s really just a continuation of the same assuming valid model that’s currently in Bitcoin.

Stephan Livera: Yep. And what’s the response been? So I noticed there was some discussion of other ideas such as a fastsync by Nicholas Dorier for BTC pay server. And I suppose as, you know, 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 that well, maybe it’s time to now try and pull this or 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, you know, whether or not Bitcoin core facilitates it. And I think it’s really important to do it the right way because this, this would be an easy thing to screw up. If you were to try and build something on your own. For example, with fastsync I think it’s, cool that Nicholas has experimented with this stuff and you know, 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 really be a great outcome because now, you know, instead of really scrutinizing the Bitcoin core repo and following changes there and now you basically have two sources that you really have to scrutinize.

James O’Beirne: And so you have to scrutinize Bitcoin core and you have to go and make sure that you’re like checking out all the stuff. And Nicholas’s private repo and, kind of implicitly trusting Nicholas there. And furthermore Nicholas’ fast sync kind of relies on being signed, doing GPG signing by him and other people who check this thing out. And it’s, it’s 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 sort of, you know download your Bitcoind program and then go somewhere else and download the UTXO snapshot and like verify the signatures. Because I just, I just don’t think, you know, many people will actually do that and that introduces a profound security risk.

James O’Beirne: 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, that really works. And, has a high degree of security. So, so far the reception has been pretty positive. I mean it’s, it’s, 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 kind of gather feedback and if anybody has any thoughts on this stuff, then I encourage them to reach out to me. But you know, I think this is a really good demonstration of the sort of the process that maybe we were alluding to earlier. When we were talking about the, you know, the, the influence structure of, of Bitcoin or the, you know, the quote unquote power dynamics is like this is super early in the pipeline. And almost anybody can get involved and express their their outlook here. So I encourage you to do so.

Stephan Livera: Fantastic. And look, James, while we’ve got you here, let’s talk a little bit about just the process of core development. So I think some of my listeners might like to hear some insights that you might have around how if they would like to contribute code, if you have any wisdom to share with them.

James O’Beirne: Yeah, definitely. I think you know, the prospect of working on Bitcoin cores is a really exciting one. And it’s something that I encourage you know, anybody interested in software engineering to take a look at, but it’s really, really hard. There’s just, you know it’s just a really hard thing to sort of get involved with because there’s a ton of context. You know, the subject domain is inherently complicated. And it’s an environment where everybody is sort of rightfully suspicious of everybody else because because of the critical nature of of the software. So I guess my advice to people who are really interested in becoming contributors is one of the things that that we sometimes see new contributors do is come along and like jump into the code base and you know, they think, okay, well I wanna make a change.

James O’Beirne: You know, I wanna I want to make a productive contribution. I’m going to go through and do a bunch of like refactoring or I’m going to like bring the codebase up to you know, C ++ 14 or C++ 11 standards. And you know, like someone will file this, this giant PR that, you know, changes a few keywords or shuffles a few functions around. And what they may not necessarily realize is that refactoring in Bitcoin core is a really kind of dicey prospect because it’s really, it’s a project that’s unlike many others in the sense that you know, any marginal change to Bitcoin has to be really thoroughly scrutinized. And so, you know, sometimes shuffling stuff around because it’s a better design or because it’s kind of, marginally more easily comprehensible isn’t always the right move because it’s a, it’s a huge vulnerability or it’s a huge opportunity for things to go wrong.

James O’Beirne: 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, you know, so maybe pick an area or two of the code base where you feel like you’re really interested and have the capacity to understand, read through yourself you know, maybe pick, a few high level operations, like, you know, how does initial block download work or what happens when the software receives the new blocks from the network and, you know, step through the code, figure out what’s happening and then try and participate in the review process. And eventually, you know maybe 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, you know, maybe eventually you know, 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, it’s just a really, it’s a really strange project. It’s, unlike for sure any other software project I’ve worked on just, just because of the level of you know, scrutiny and and the level of care that, that the developers involved have to take.

Stephan Livera: Right. And I’ve seen examples where someone tried to, I think, refactor a certain code and it took like a year to basically deal with all the different pieces of feedback that came up and all the constant other changes that were happening. As are there any insights you can share around that?

James O’Beirne: Totally yeah, Russ Yanofsky who’s another another employee here at chaincode has been working on separating the wallet from the node. In an effort to basically make development easier in the sense that there are certain changes we could rule out as not being, you know, consensus critical because they’re in a separate process. But he, started he came up with his draft for this, I think more than two years ago, and he had a functioning prototype two years ago and had a bunch of changes proposed and you know, and say like if you were at a software company, you know, working on, on some closed source piece of software, you might expect his change to be, you know, fairly substantial, but it, but it might be merged, you know, within a month or two. But it’s two years later and, he’s done a really great job of making this change as granular and really having a lot of patience and persistence in getting him through. But you know, 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 kind of unpack there. How about any areas where Bitcoin core development differs from other software projects?

James O’Beirne: Yeah. So yeah, we’re working on Bitcoin core is kind of counterintuitive to a lot of conventional software wisdom. For example one of the things that that is thought a lot about is how to reduce dependencies. So typically, you know, 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 know, you might go out and find an object relational mapper or if you want to deal with database and pull that in or, or you know, some kind of a web framework. But in Bitcoin any additional dependency that we take on is, is sort of a vulnerability because it’s a code base that’s you know, that’s changing kind of outside of the life cycle of Bitcoin.

James O’Beirne: 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 just does a bunch of different things. We’re trying. I think we’re close if not done with stripping out open SSL. Because at this point we’ve, we’ve implemented a lot of the crypto that we need. So that’s definitely a departure from kind of conventional software engineering. Yeah, like I mentioned earlier refactoring for the sake of refactoring is sort of discouraged. So refactoring only happens when it’s, when there’s a really, really practical reason for it.

James O’Beirne: And in general, the iteration cycles are just 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, it’s, I think, beneficial to sort of take things a bit slower. And just to make sure that we’ve thought through all the changes that eventually do go in.

Stephan Livera: Fantastic. Well, look, 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 yeah, maybe you feel free to give them that now. And also lastly, just tell them where they can find you and follow you.

James O’Beirne: Sure. Yeah, keep using Bitcoin I guess is my only thought. Yeah, the the federal reserve is, is doing some pretty interesting stuff. So I’m at least, I sleep a lot better at night knowing that Bitcoin is alive and well. So 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. Well look, thanks James. It’s been an excellent discussion. Thank you so much for coming on.

James O’Beirne: Thanks a lot Stephan. It was a pleasure.

Leave a Reply