Episode 63: The Bitcoin Core development process

Aaron van Wirdum Live from Utrecht, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum I have an amazing gift for our listeners today.

Sjors Provoost Okay.

Aaron van Wirdum As you know, the Bitcoin Amsterdam conference is coming up. It's in October.

Sjors Provoost Yes.

Aaron van Wirdum And I can offer our dear listeners a discount code for 10% off of their tickets.

Sjors Provoost That sounds amazing.

Aaron van Wirdum Isn't that great? The discount code is Sjorsnado. I wanted to make sure we had a discount code that no one can pronounce or remember.

Sjors Provoost Or spell correctly unless they know what they're talking about. No, it's excellent.

Aaron van Wirdum Exactly. So now it's only for our one... I hope there... Let's see if there's even one person that will use the code. Like that will be our hardcore fan if there's one person that will use this code. I'm not sure if we can see if anyone uses the code. I think so. I hope there will be one person. And then if we meet you at the conference, we'll take a picture with you. Right, Sjors?

Sjors Provoost Maybe, maybe not.

Aaron van Wirdum Well... We've just promised it, so we can't really go back on it now. I've said it out loud. Sjors and I will take a picture with you at Bitcoin Amsterdam if you use the code Sjorsnado.

Sjors Provoost All right.

Aaron van Wirdum Sjors, what are we going to discuss today? We're going to discuss very sad news, actually, aren't we?

Sjors Provoost I don't know if it's sad.

Aaron van Wirdum It's not happy news.

Sjors Provoost No, but it was somewhat predictable news.

Aaron van Wirdum Yeah. Okay, so Wladimir van der Laan, the lead developer, lead maintainer of Bitcoin Core, he's going to quit, or he did quit.

Sjors Provoost Yeah, he's retiring.

Aaron van Wirdum He's retiring. He's done it since 2014. So that, is that right? Yeah.

Sjors Provoost No, I think much longer.

Aaron van Wirdum I think like officially, Gavin Andresen...

Sjors Provoost As a maintainer, yeah. He's been in the project for almost 10 years.

Aaron van Wirdum Probably at least 10 years, right?

Sjors Provoost Yeah.

Aaron van Wirdum But yeah, lead maintainer for, I guess, about eight, over eight years now. I think it was like March 2014 or something from top of my head.

Sjors Provoost Could be.

Aaron van Wirdum And he's stepping down. So we thought this was a good opportunity to maybe discuss... I guess, what a lead maintainer for Bitcoin Core does, what he is, and a little bit more broadly, the Bitcoin Core development process itself.

Sjors Provoost Yes.

Aaron van Wirdum So how is the Bitcoin Core software actually produced or who does this? It's not about individuals, but the different roles that are involved in that process. So, sure. First of all, What is Bitcoin Core?

Sjors Provoost Well, Bitcoin Core is many things to many people. I mean, primarily it's the name of a piece of software. The piece of software just used to be called Bitcoin and then it was rebranded to Bitcoin Core. And I guess the brand stuck around. It's basically the node that validates all the blocks. And you can also use it with a wallet. And it's got a nice user interface. And it used to be able to mine blocks, all that sort of cool stuff. Bitcoin Core is also the name of a unspecified group of people that contribute code. To the Bitcoin Core software. Basically, anybody who does that is called a Bitcoin Core contributor. Apparently, and I believe this concept was invented by Peter Todd, you can also be a former Bitcoin Core contributor. So apparently, even though your commits will always be in there, at some point, you're not presently a contributor. I don't think there's a very tight definition of that. And then, in addition to contributing, you can maintain... you can be a maintainer and I guess we'll have to explain a bit what that is and then there's such a thing as a lead maintainer

Aaron van Wirdum Yeah I want to I first I want to get a little bit more philosophical here if you'll allow me. Sure. So you just said Bitcoin Core is a piece of software, for example, that's one of the definitions you gave in short. So but but then, like if you— which piece of software is Bitcoin Core? How do you— how like— How is it defined? Is there a way to define which software actually is Bitcoin Core?

Sjors Provoost Well I would say that once that becomes difficult there'll be probably be two names for two different things that's the easy way out right right because right now it's just you go to Bitcoin Core.org and the thing you see there is called Bitcoin Core and there's there's no controversy around that if you know unless you talk to some really crazy people.

Aaron van Wirdum I mean there was some controversy about it like a year ago if you remember around the Taproot activation discussion at some point Luke Dashjr was arguing that Bitcoin Core was no longer Bitcoin Core.

Sjors Provoost Okay, yeah, I guess in the eyes of some people that such a controversy can happen earlier, right? But I think in this case it was mostly his opinion. But you could have a situation where the people currently described as Bitcoin Core or some subset of it make changes that are considered controversial by other people, perhaps even also people who are part of Bitcoin Core. And so at that point, you might have a split in opinion where one group says, no, this is Bitcoin Core. And the other group says, this is Bitcoin Core. And there's nobody formally entitled to anything there. So then I guess you will have to start arguing about names and what's the real Bitcoin.

Aaron van Wirdum Yeah, you get similar discussions.

Sjors Provoost And it depends on the kind of change, right? So there could be two kinds of changes. One is a consensus change. And that's definitely what the situation with Luke Dashjr was about. So what are the actual rules of the Bitcoin blockchain? If you have a dispute about that, you get problems with ticker symbols and that sort of stuff. But you could also have a more benign conflict, for example, where some people say, well, Bitcoin Core should have a graphical client and it should be easy to use. And others would say, no, it should absolutely not be. And maybe that causes some sort of split where you have two pieces of software that follow the exact same rules, but they are really two different pieces of software. And maybe people fight over the name. I doubt it, but it could happen.

Aaron van Wirdum Well, I'd say the example that I gave with Luke Dashjr was somewhere in between these two. I don't want to dwell on this, but at the same time, I do think it's kind of relevant for the episode and I'll explain why. So I never really gave it too much thought or I never really thought that it could ever become a problem. But if you would have asked me what Bitcoin Core is, then my answer would have been Bitcoin Core is whatever the lead maintainer of Bitcoin Core says is Bitcoin Core.

Sjors Provoost Well, that won't work because if the lead maintainer says something crazy, then, you know. Then you could simply say, well, he's not the lead maintainer. And therefore, whatever the new lead maintainer says is Bitcoin Core. But then you might as well just directly say what it is.

Aaron van Wirdum No so in my definition that would still be Bitcoin Core it's just that users would then have to adopt a new software they would have to migrate to a new software but the lead maintainer does sort of define in my personal definition the way I was always thinking about it like that is who defines it and then who is the lead maintainer of Bitcoin Core you know before because it could get circular that is either whoever founded the project or whoever inherited the project from either the founder or their previous lead maintainer does that make sense? So that's how I used to think about it.

Sjors Provoost I guess it could make sense. I don't think that's— that's useful at the moment anyway right because in the beginning yes it was very clear that the founder was the lead maintainer but very quickly whether I mean Gavin I guess was the second lead maintainer before Wladimir but I and I think Gavin got it inherited in a way right I don't know if Wladimir got it inherited or…

Aaron van Wirdum Well that one for sure like Wladimir definitely inherited it from Gavin that was very explicit the less explicit one was arguably Gavin from Satoshi that one is a little bit more murky I think it's…

Sjors Provoost But right now it's just like Wladimir says okay I'm no longer the lead maintainer now there is no lead maintainer. And the next one is decided not necessarily by Wladimir. It could be somebody, you know, multiple people might say, oh, I would like the role. And then I guess a group of developers would sort of talk about it. My guess is that there will be zero or one volunteer for this role. And so there's not a problem of deciding who it is, but I wouldn't call it inheritance. I don't think. I mean maybe Wladimir's you know if he if he has a strong preference between two super equal candidates I could imagine people would say okay whatever his preference is but in the end…

Aaron van Wirdum Okay that that's interesting. I was gonna get on this point in the at the end of the episode but now that you mentioned it let's just finish this thought so what you're saying you you expected the next lead maintainer would not actually be someone that Wladimir will explicitly say okay you're— no and you're my successor it will just sort of… How so who's going to decide or how does that…

Sjors Provoost The thing is Wladimir has said for years that you know he would like somebody else to start doing this at some point and he said like if people don't do this voluntarily I'm just going to do this python situation where their lead maintainer just leaves very suddenly and the thing is with with these kind of projects like it's not the nicest and most thankful work so It's not like people are fighting to become the next lead maintainer of Bitcoin Core. Nobody wants to be the next lead maintainer, including Wladimir.

Aaron van Wirdum Sure.

Sjors Provoost At some point, if Wladimir says, I'm not doing this anymore, somebody else will eventually start doing it. But it's more like that. It's like, somebody please be the lead maintainer.

Aaron van Wirdum Okay.

Sjors Provoost It's not like president of the US.

Aaron van Wirdum Someone will start doing it. And what it is, so that's sort of what we'll get into in the... the rest of the episode, but now we're really skipping it. So now I want to take a step back, I guess.

Sjors Provoost Because it is multiple things. So what I'm basically, well, we'll get into what these things are, right? But what I'll guess is what happens is there's certain tasks that Wladimir used to do and he's not doing them anymore, or at least that might be the case. Somebody else will do one or more of those tasks. And perhaps whoever is doing most of those tasks because nobody else is doing it, then suddenly gets crowned. You are the lead maintainer now. Have fun.

Aaron van Wirdum Okay, so at this point, we should get back in order of the episode. So yeah, the controversy at some point was, so my kind of loose definition of Bitcoin Core was always whatever the Bitcoin Core lead maintainer says is Bitcoin Core. And then what Luke Dashjr was kind of contending or arguing instead was that in his mind, Bitcoin Core is defined as a process. So there's a specific process. And if that process is being followed, then that is Bitcoin Core. That process has something to do with consensus. And if that process is broken, then whatever comes out of that process cannot be called Bitcoin Core. So he had a different way of defining Bitcoin Core, which is not something I've since then given much thought or have an opinion on. But I did think it was interesting that you can have different opinions or definitions of Bitcoin Core. So I just wanted to throw that out there. Now we've just kind of defined Bitcoin Core or we haven't or we've explained that there are different ways of looking at it so let's leave that aside next question or next point is so what are the roles within the Bitcoin Core project that there is a Bitcoin Core project let's just assume that and then there's roles within that project. And I think you've already mentioned one or two of them.

Sjors Provoost Yeah, I went into what contributors are, right? So people who contribute code, I guess, you know, there's also people who contribute review and that sort of thing or issues, et cetera.

Aaron van Wirdum Right and there's this is something anyone can do anyone can decide today or tomorrow or last year or next year, I'm gonna contribute to Bitcoin Core in some way or another can be code can be review can be maybe translations of text, or…

Sjors Provoost Yeah and there's in principle there's like no barrier to entry to that right so you just show up with your piece of code or with your comment and unless it's like absolute spam you know, you'll be fine.

Aaron van Wirdum Yeah.

Sjors Provoost Maybe nothing happens with your code, but you know, it's not…

Aaron van Wirdum Yeah. Nor does anything happen with you. You can start calling…

Sjors Provoost Yeah. But then the next role would be a maintainer.

Aaron van Wirdum Right.

Sjors Provoost And that one has a, I would say a higher barrier to entry. I don't think there's a really a formal process for it, but what the maintainer does is they essentially click the merge button. So at this point, I think we need to explain a little bit of GitHub workflow.

Aaron van Wirdum I think so. Yeah.

Sjors Provoost Right. So there's this thing called GitHub, which is a place where people keep Git repositories. Git itself is a decentralized system that has existed for a long time or distributed system, depending on your look. And so on GitHub, you can, you know, there's an organization on GitHub. I would say it's not really an organization, but it's called Bitcoin. And this organization owns a repository. So a repository is a piece of code. And that piece of code is also called Bitcoin. So that's why the URL is GitHub.com slash Bitcoin, the organization slash Bitcoin, the project, the source code.

Aaron van Wirdum Right.

Sjors Provoost We'll get into what that Bitcoin organization is in a bit. But to explain the workflow, when you want to propose a change to Bitcoin, you make a pull request. And what that does is you take the code, the original code, and you clone it on your own computer. And then you change something. And you push that change to GitHub. So now GitHub has the original code plus your changes. And then you do something that's called a pull request, which basically sends a message, I guess, to the repository that shows the difference between your stuff and the original code. And then you can explain why you're doing it. And so other people will see, okay, they'll see this person wants to propose the following changes and this is their reasoning why. And then people will start looking at it. They'll review the differences. And if enough people agree with it, then somebody has to click a button, essentially, that now includes your changes into this Bitcoin slash Bitcoin repository so that everybody else can build on top of it.

Aaron van Wirdum Right. So everything you mentioned so far... Up until the button clicking, that's what Bitcoin Core contributors do.

Sjors Provoost Yeah, the contributors review your code. They suggest improvements. And at some point, if enough contributors and if enough contributors that have the correct skill set to actually judge that, say, okay, this code is fine. Then the maintainer more or less just presses the button.

Aaron van Wirdum Yes. And what happens when they press the button?

Sjors Provoost Then the code is included inside the master branch, which means then everybody else who wants to make a change has to build on top of what you just did. At least, you know, the way Git works is kind of a tree. So you don't actually have to build on top of the very latest thing that is on the master branch if you're not touching the same thing. So if there's like two different files, I don't have to build on top of the latest commit on master if I'm working on a different file. But there's something called the merge conflict where if the master branch contains a file that's been changed and you are also changing that file, you actually have to build on top of the latest version. Otherwise, we don't know what the truth is. But that's maybe for another episode.

Aaron van Wirdum Okay, so someone needs to click that button. That person is a Bitcoin Core maintainer?

Sjors Provoost Yes.

Aaron van Wirdum How many Bitcoin Core maintainers are there right now or are there usually?

Sjors Provoost There's six and it's always been sort of roughly around that number.

Aaron van Wirdum Do you know from the top of your head, do you remember who these six are currently?

Sjors Provoost Well, Wladimir is still technically. fanquake.

Aaron van Wirdum Yeah, Michael Ford.

Sjors Provoost right. And Marco Falke.

Aaron van Wirdum Gloria Zhao.

Sjors Provoost Gloria Zhao.

Aaron van Wirdum Oh, right.

Sjors Provoost I don't know what his real name is. And Andrew Chow.

Aaron van Wirdum There you go. You made it to all six. We didn't insult anyone thanks to your great memory, Sjors. Thank you. So there are six currently, and I think that's usually around six, right? That's been around six for a long time.

Sjors Provoost At least many years, yeah. Some people come, some people go.

Aaron van Wirdum Right. So then how do you become a Bitcoin Core maintainer? How do you get the access to this button?

Sjors Provoost Yeah, so there's not a super formal process for it, but basically the idea would be that you have been around for a while, you have a reputation of not doing absolutely insane things, and you understand when something is safe to include, right? So for the most part, what a maintainer does is they rely on other people who have done the reviewing and who've publicly said that it's okay. But you do need to know whose review is typically good and whose review may not be very good, right? So you need some experience in the project to know that. And so that's sort of so. So basically, then there's a meeting on the IRC chat where somebody might say, hey, you know, I'd like to become a maintainer. Or, hey, we'd like you to become a maintainer. And then others would say, yeah, sounds good, sounds good, sounds good. And maybe there's some discussion, maybe not. And then a little bit later. The one of the existing maintainers adds that new maintainer

Aaron van Wirdum Right so maintainers are added by other maintainers essentially.

Sjors Provoost Yeah but the approval process is a community thing. Yeah but the actual physical ad— act of making somebody a maintainer can only be done by maintainers or somebody with backdoor access.

Aaron van Wirdum Right, like a GitHub employee could do it as well, essentially.

Sjors Provoost Yeah, but then I guess we can get there later. I don't know if you want to get into that now, but there's basically two ways that people track who the maintainers is. So there is the...

Aaron van Wirdum Let's get into it now.

Sjors Provoost So on GitHub, there's basically GitHub itself as a platform, but it's a trusted platform. They have mechanisms to make sure that some people can push the button and other people cannot. So the list of current maintainers is updated inside of GitHub so that GitHub, you know, at least make sure that no random other person can press a button because that would create a mess. Wouldn't be the end of the world, but it would definitely create a mess. But there's a second thing because GitHub is a trusted platform. We don't really want to rely on that. Right. So, well, one thing you can do is you can just look at all the recent commits on the Bitcoin Core repository and you can look like who was hitting the merge button because the merge button, well, they're not technically not using the button, but I won't bore you with that. But you can see who made the merge commits. So you can check that it's actually one of those six people that you know to be the maintainers. But there's also an automated way to check that. And that's because there is a file inside the repository. And that file says these are the six maintainers. This is their PGP key. And so there's a script that will start with that file sometime in the past. Whatever the maintainers were then. It looks at all the merges and it will say, okay, this merge was done by somebody who was on the list at the time of the merge. And then at some point, the list itself has changed. It checks that the list was changed by somebody on that list and not by somebody else. And then it will check for the next commits that they were done by somebody who had permission to press the merge button.

Aaron van Wirdum And that's because these commits are cryptographically signed?

Sjors Provoost Yes, exactly. So GitHub has a really nice feature that not everybody uses and you don't have to use it. But when you make a commit, which is one piece of a change, you can sign it with your PGP key. You can do it automatically or you can do it manually. And maintainers always do this when they make a merge. So that means that you cryptographically sign using your PGP key that you are the one doing the merge.

Aaron van Wirdum Right.

Sjors Provoost Unless your key is compromised, of course.

Aaron van Wirdum Sure. Right okay that's clear to me is that what you wanted to say about that part

Sjors Provoost Yep

Aaron van Wirdum Okay great so then so now we've discussed contributors which can essentially be anyone that contributes and then we've discussed maintainers which are about six and they get access to this merge button and then we have the lead maintainers so what differentiates the lead maintainer from regular maintainers or what are the roles of a lead maintainer?

Sjors Provoost I think over time we could say that the lead maintainer is doing less and less or at least less and less very visible things but I mean the lead maintainer basically evolved from what would be the benevolent dictator in a project like Linux So it is the person, especially in the beginning, is the person who makes a release, who decides when it's, well, it doesn't really decide when it's time to make a release. I mean, in the original benevolent dictator thing, they would decide when to make a release. They would decide what would go into the release. They would put it on the website, et cetera.

Aaron van Wirdum I mean, that was certainly true for Bitcoin in the early years as well.

Sjors Provoost Yeah, and it's evolved a little bit where a lot of these subtasks have been more distributed, where there are still several buttons that Wladimir or the new maintainer has to push. But there are a lot of buttons that really anyone can push as long as somebody pushes them.

Aaron van Wirdum Okay, so what are some of these buttons?

Sjors Provoost But I would say one of the ones that's still probably critical is the release itself. Just to decide that this is a release and not some other commit.

Aaron van Wirdum Hey, that kind of gets back to my definition of Bitcoin Core then, doesn't it?

Sjors Provoost Yeah, but it's not that essential either. In principle, any maintainer, I guess, could also make a release. I don't know if that's still actually constrained or not.

Aaron van Wirdum Well, isn't that the case now? Isn't Bitcoin Core released by, or different people sign off to it?

Sjors Provoost Okay, so there's multiple aspects to the release. One aspect is which commit, which specific piece of code actually represents the release. That's done with a tag on GitHub.

Aaron van Wirdum Right.

Sjors Provoost Or even in Git, Git has tags. Tags are signed too. So the question is, who gets [unclear] tags? And the answer to that question is, well, if you have a script that checks the tags, you know, what does the script want? Maybe the script wants the lead maintainer to do it. Maybe the script is fine if any of the maintainers do it. But I would say it's the same kind of thing as a [unclear]. So maybe the lead maintainer doesn't even do that maybe he does but he doesn't have to maybe anybody could do it but in practice maybe only one person does it so that's one.

Aaron van Wirdum So in short that's one person that says this is a new Bitcoin release.

Sjors Provoost Yeah exactly.

Aaron van Wirdum Okay and then currently in Bitcoin or so far in Bitcoin was this still Wladimir always?

Sjors Provoost I haven't checked, probably.

Aaron van Wirdum Okay, and the way he would do that is he would...

Sjors Provoost He would open his computer, he would type the words Git tag and then v0.23.1.

Aaron van Wirdum Sure, but my question is more, he would probably... need a reason to do that for himself, at least. He wouldn't just do that because he felt like it. He would probably have some kind of checklist.

Sjors Provoost There are a bunch of checklists out there that you can see in the repository. A whole lot of things have to happen. I think, I forgot the name of the file, but there is basically a list, a release-process.md that has a lot of tedious things that have to happen. Like somebody has to upload the latest translations. Again, that could be any contributor, but somebody has to... at the translations. Somebody has to change the version number in the source code so that it displays the correct version number. Doesn't matter who does that. Somebody has to do it. There's a whole bunch of these things. Somebody has to make release notes. And then the more subjective part is to say, okay, are there still any bugs left that have to be fixed before it's good to make a release? And usually there's release candidates. Those are things that are released to the public that people can test. Then I guess it doesn't really matter when you do that. And then there's the actual release. And for the actual release, usually on the IRC chat, there's a meeting where people say, should we do the release? And then a lot of people say, yeah, let's do the release. Then the maintainer again just presses the button and makes the release.

Aaron van Wirdum Okay so as far as we know or think or suspect so far it was still Wladimir who kind of went through this checklist and said all right everything is done this is the new Bitcoin Core release

Sjors Provoost Yeah, I think so. But again, that sounds like something that can trivially be done by anyone, by any of the maintainers anyway.

Aaron van Wirdum And then I think the second part you were going to get at is signing the release.

Sjors Provoost Yeah. So once you have decided what source code belongs to release, now you need to actually make a binary that belongs to release. And there is a, we talked about this, deterministic builds many episodes ago about Guix, for example, how it's done now. Anybody can do that. And many different people should do that. And the results should be identical, whoever does it. So for the same code, for any given code, you should get the exact same binary. And not just one binary, but one for Windows, one for Mac, one for Linux, etc. And these binaries have checksums. And so what you want to sign is the checksums. And yeah, it used to be, and that's usually the case with a lot of open source projects, that the lead maintainer signs the binary and says this is the signature or this is the checksum of the binary and I'm here signing this binary with my PGP key so that people who download it know that they don't have malware. At least they know that if there's malware, then the malware is made by the lead maintainer. And so that has been changed recently. There are a lot of people signing off on these binaries. So the process has been changed so that multiple people can sign for a release. I think it's not just the maintainers. I think anybody can sign for a release. And that means that when you download the release, there's a whole bunch of signatures on it. And then you can decide, I guess, which signature you care about. So maybe you know somebody and you trust them. Maybe that's Wladimir, maybe that's somebody else. But yeah, so that removes again, removes the lead maintainer from a critical, from a somewhat, you know, centralizing point, I guess. Then there's another task, which is to put the binary on a website and point the website to it, basically, and update the website so it has a nice little blog post.

Aaron van Wirdum Okay, you're now getting to a third task that a lead maintainer... Typically does. So the first one was signing off the release or deciding when a release is a release. And then the second one was signing the release, which we separated into two tasks or are separated into two tasks. And then the third one you're now going to get into is publishing the code, the new release on the website. So in this case, it would be the BitcoinCore.org website.

Sjors Provoost That's right. And so that process has also been somewhat split up, again, with checklists. So anybody, I think, can make the web page that announces the next release, and then it's merged again by some maintainer.

Aaron van Wirdum Right, so this third task is also already kind of more distributed. It's not necessarily...

Sjors Provoost Yeah, and I think it's semi-automated. So there's basically a repository on GitHub again that represents that web page and you can add things to the repository. But there might be some little aspect of like actually putting the file on the server. That might still be somebody doing that.

Aaron van Wirdum Right.

Sjors Provoost But it doesn't really matter who that is as long as the file that's there is not malware. So it probably shouldn't be a completely random person because not everybody actually checks if there's malware. But if there is malware, somebody will find out very quickly.

Aaron van Wirdum Right. Okay, so that's three tasks of which at least two are already more decentralized, namely signing and publishing it on the website. And then the first one deciding when a release is a release we weren't exactly sure about.

Sjors Provoost It's definitely decentralizable to it.

Aaron van Wirdum Anything else?

Sjors Provoost I mean, yeah, there's things like starting the IRC meetings. Again, that's been pretty automated. The main thing that Wladimir does is to type on IRC the word start meeting. And then there's a bot that starts the meeting and then he types end meeting. And I think other people can do that as well.

Aaron van Wirdum Right I guess he does sort of manage the meeting right he kind of…

Sjors Provoost Yeah exactly but in principle again anybody can do that.

Aaron van Wirdum Which topics are being discussed and stuff like that. Sure yeah anyone can do it but so far it was mostly Wladimir that was still doing that.

Sjors Provoost Yeah and this really you know comes back to the um point I brought up in the beginning of our chat like somebody has to do it and as long as Wladimir does it nobody else will do it as soon as he stops doing it Well, either it doesn't happen and then people are like, why is there no meeting? And then somebody types start meeting and then there's a meeting. But my guess is, and we've now listed a couple of tasks that are very clearly the kind of thing a lead maintainer typically does, but there are probably a lot of very small things. You know, this happens with any company or any organization or voluntary organization. There's always this one person that just does a lot of different things. And when they leave, you find out what they were actually doing. And that means that things are just going to break. Not so much things inside Bitcoin Core because that software, the software itself is not really affected by who is the maintainer. But I could imagine that the next release takes a bit longer because there was some step that nobody thought about or that just nobody takes the initiative on, right? It's like if somebody should click this button, but nobody's clicking the button and everybody's staring at each other, wait, who should click the button?

Aaron van Wirdum Right. Okay so so you've now we've now mentioned how many four tasks I guess and then maybe there are sort of smaller tasks that we're not thinking of yeah, but to get back to one of the things you said earlier in this episode or at the start of the episode is what Bitcoin Core currently is a repository on— under the— it calls Bitcoin under the Bitcoin handle.

Sjors Provoost Yeah. So on GitHub, usually when you see a URL on GitHub, it's GitHub.com slash name of person slash name of company slash the name of the repository.

Aaron van Wirdum Okay.

Sjors Provoost So Bitcoin slash Bitcoin. The first Bitcoin is the name of either a person or a company or like a name. And second is the name of the repository.

Aaron van Wirdum Right.

Sjors Provoost So then the question is, I guess that you were going to ask is what's Bitcoin? What's the organization?

Aaron van Wirdum Who's that? Or what? Is that Wladimir?

Sjors Provoost I don't know. That is somebody who has the password to, you know, add people as maintainers, to remove people as maintainers, etc. That could be Wladimir. That could be some super shady person that we don't even know about who, you know.

Aaron van Wirdum Right, yeah, because earlier you mentioned that maintainers are added by maintainers, but someone still has to, again, press a button on GitHub, I guess.

Sjors Provoost Yes.

Aaron van Wirdum And that button would be pressed by the Bitcoin account?

Sjors Provoost Probably, but I mean, you can delegate something. So whoever owns the Bitcoin account on GitHub can then, on GitHub itself, say, okay, I'm giving permission to this account or to this user or to this other user to do these things. So a lot of tasks you can basically... Anybody can do it. There's people who can add tags to or add labels to certain issues to say this is a P2P feature or whatever. There's people who can delete spam. So there's a lot of permissions that you can grant if you own that GitHub account.

Aaron van Wirdum But still someone owns the Bitcoin account. Like that person, there must be something that that account can do.

Sjors Provoost Well yeah and then there's a question somebody owns the GitHub account and somebody controls the GitHub account that might be different I mean to to control it you just need to log in and the password and whatever 2fa is out there to own it that's more of a legal thing maybe nobody owns it maybe GitHub has just said you know what we'll just keep this thing around and whoever you know and if there's ever dispute then we'll we'll look at the list of site maintainers and ask them who is the owner Maybe. I don't know what the procedure is. And it's probably best that we don't know what the procedure is.

Aaron van Wirdum In this case, I'm just referring to owner, not in a legal sense, but more in control. Yeah, the Bitcoin account that has the Bitcoin repository on the website, at least.

Sjors Provoost Yeah, and the most obvious interpretation would be that Wladimir controls that account. That makes sense. But it could be that he doesn't.

Aaron van Wirdum Right. And we don't, does no one know this?

Sjors Provoost I don't know. Maybe somebody does know. And I didn't look it up.

Aaron van Wirdum But you don't know. And I don't know.

Sjors Provoost Yeah.

Aaron van Wirdum Okay.

Sjors Provoost Makes sense to have that. I mean, it could make sense to have that a little bit vague. You know, you have all these crazy people suing lots of people for crazy reasons. And it's nice if you can, you know, if you somehow lose a lawsuit like that, you can say, well, I have no control over this thing. As soon as I push this button, the real person in control will just pull me away.

Aaron van Wirdum Yeah, it does sound like this would be something. I mean, I liked transparency. It would be better if somehow whatever solution you have in mind with the button and you're not in control would be implemented somehow, I guess.

Sjors Provoost The transparency is in the code itself.

Aaron van Wirdum Sure. No, I understand that. It doesn't sound ideal to have this vague.

Sjors Provoost No, I mean, the ideal thing, I think where we want to go is to not have a lead maintainer at all. And basically have all these things automated. But eventually, you know, websites are in one place. So there's always somebody on top of the website.

Aaron van Wirdum Right. Okay well so we've we've defined how many things now four and then maybe five so we we mentioned that the lead maintainer typically decides when a release is a release typically and that is very much decentralizable

Sjors Provoost Yeah and it's also mostly procedure right? So the process in general is every six months or so there's a new release So you wait for those six months and you can ask around an IRC, okay, is this a good time to start working on the release or not?

Aaron van Wirdum Sure. No, I'm just summing it up. So the first one is deciding when a release is a release. And that seems like something that's decentralizable if it wasn't already more decentralized than having one lead maintainer do it. And then there was signing the release, which was already more decentralized because more lead maintainers or contributors are now signing. There was updating the website. So that's definitely something that other people can do. They're starting the IRC meetings. Definitely something someone else can do. Probably controlling the Bitcoin handle on GitHub which might not be decentralizable but we also not sure what's going on there right okay so if Wladimir is going to step down Or now that he did stop down, depending on who knows what the exact situation is now, other people are just going to have to start filling these roles. And as we mentioned earlier in the episode, this was where I wanted to end originally. We don't really know who's going to do that.

Sjors Provoost No, and so one possibility is nobody. And that has its benefits because that means you no longer get any of this narrative of like this control, this person is the boss of Bitcoin, which, you know, Wladimir clearly was not, but he was accused of being. Of being that. So it could be nice to not have anybody, but my guess is there's certain situations where you want somebody to, to like throw it, throw a coin one way or the other, something like that. So we'll see.

Aaron van Wirdum Okay.

Sjors Provoost And we'll, I guess we'll see in the next couple of releases, what steps there are that, where we find out, Oh, I guess that was something Wladimir was doing and we didn't think about.

Aaron van Wirdum Yeah, and the next release is kind of coming up-ish.

Sjors Provoost Yeah, I think we stop adding features now. And then in a few weeks, the idea is just to basically split it off into a separate branch where that branch that's designed for the releases, only important changes happen on it. And there's a master branch where all the new stuff goes into, but that new stuff won't go into that release that's coming up. So basically the project forks in a way. That's something we can explain another time.

Aaron van Wirdum So what's the ETA for the next release? Do you know?

Sjors Provoost I don't know. It could take a month or two.

Aaron van Wirdum Right.

Sjors Provoost I think it's usually like after you split up, then it takes a few weeks to fix bugs and then you get a release candidate. Then it takes two weeks to find bugs in that. And then you do another release candidate. It takes another two weeks to find bugs in that. So it can take a few months.

Aaron van Wirdum Okay.

Sjors Provoost Yep.

Aaron van Wirdum Clear to me.

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

Aaron van Wirdum Explained.