Bitcoin's Decentralised Governance,

Hey guys, welcome to Stephan Livera podcast, and my guest today is Pierre. Thanks for coming on, Pierre. Thanks for having me on again, Stephan. Excellent, yeah, Pierre is one of my repeat guests. he's one of the best guys to follow in this space. He is, just for anyone who doesn't know him, he is a co-founder of the Nakamoto Institute and, and also a co-host of the Noted podcast, which is basically one of the top podcasts in this space. And he's also the founder of Bitcoin Advisory. And our theme for today is Bitcoin governance. So Pierre recently wrote some articles and has done some speeches and podcast appearances in relation to this, so obviously those will be in the show notes page. so I suppose let's start with Bitcoin governance. Why do we care, Pierre?

so I think that you've had some past guests on, like Murad and, Safedine, that have really laid out the monetary economics of Bitcoin and why they matter and why they are good for the future of humanity really, I mean, as a civilization, maximizing the, capital accumulation and, and wealth That we have, and, you know, at the end of the day, that, that as a species is what's going to allow us to survive and get into space and, escape this, this rock. But anyway, without getting too cosmic, so- Governance is important. Bitcoin's governance is important because Bitcoin is important. and Bitcoin didn't emerge from the mind of Satoshi as a, a perfect thing. and I think that, that's widely recognized that there are improvements that can be made to the Bitcoin protocol. And so we have to, examine how are those changes to the protocol made? what do they affect? And, what, how are they selected for, specifically?

Yep. Cool. And then, who are the relevant parties to think about? So,

I think that we could, we could really go in order of their involvement. so you've got researchers, and they are, you know, in academia or in industry or independent, and they're trying to think of ways to tweak the Bitcoin protocol to address either a problem that they've seen or to create a, a new feature that they're interested Interested in, seeing implemented on the Bitcoin protocol, and then after that, you, you have a process called the, Bitcoin Improvement Proposals, and so there's different people involved at, at that point that are, looking at Bitcoin Improvement Proposals, and then merging them into the, BIP repository where those improvement proposals are kind of canonified. and then you have people who- Implement these BIPs, they-- since Bitcoin generally is, you know, has one reference implementation, and we can get into that later, but, the, the implementers are C++ developers, and so that's another constituency of, what's called Bitcoin core contributors. and, and there's overlap over all these groups, right? and then you have, people who run a Bitcoin full node, and that ranges from someone who- Is running a Bitcoin full node without owning any bitcoins, which we can talk about why that might be a little useless, but there's also on the other end of the spectrum, large exchanges that are verifying, millions of dollars worth of bitcoins, coming in and out, using their Bitcoin full node. so Then finally, we have the, the miners. And the miners generally would be running a full node, but that's really actually only the mining pools, pool operators that run a full node currently. and the miners themselves are just, running SHA two fifty six squared calculations. so, they, they have a role to play in, in the governance as well, and, and we can debate about the extent of that role.

Yeah, great, great summary of the many moving pieces that are in play in the Bitcoin world. So one concept I've seen you talk about, and I think you do really well in explaining this, is you talk about this concept of network governance specifically as and not a miner democracy or not a kind of developer governance or benevolent dictator. What do you mean when you say network governance?

Yeah, so, I think that explaining network governance kind of, necessitates explaining what it is that we are governing, and what, what's being governed with Bitcoin's governance is the, block and transaction validation rules. And so this is a long set of different rules. some of them are minutia that aren't particularly Really, interesting to people. and others have, caused holy wars within Bitcoin. so, you know, I have in mind the, obviously the block size limit, which, which is now the block weight limit. and so that, that particular block validation rule, has caused a huge amount of controversy. but there's a lot of other, different validation rules, that are, much less contro- And so the, the definition of Bitcoin really is these, these rules, because if you are not following these rules and you are creating an invalid transaction or an invalid, block That invalid transaction and that invalid block will not be propagated, will not be communicated by other nodes that are following the rules. And so you immediately kind of get, sidelined by the network, and you're no longer part of the Bitcoin network if you're not following those rules. Now, I think that the issue with, with that explanation, so that's, that's network governance, which is basically that if you don't follow the rules, Of the nodes on the network, then you will get excluded from the network and you're, you're, you know, removed. but the, the, the controversy is which network, which set of validation rules do we call Bitcoin? And we saw last year, and we're contin-continuing to see it with Bitcoin Cash, where you have the, the BCH people who say, "Well, our set of validation rules is..." Bitcoin, and that is, their point of view. And then you have the BTC people who say, "Well, no, it's our set of validation rules, and thus our network that is Bitcoin." And last year we had the SegWit, well, you know, they, they, they called it SegWit 2x, but it's really just the 2x part, right? the, the 2x people, led by Jeff Garzik, who were saying that, "No, our set of validation rules is Bitcoin." Bitcoin. And so it's kind of a, it's an interesting, issue where there's no central authority that says, this, this set of validation rules is deemed to be Bitcoin and everyone has to follow that, and if anyone disagrees, they're wrong, and if they insist, then, you know, we'll, we'll throw them in jail or something. so there's, there's no like, there's no trademark, there's no, and in fact, there's- It's, it, it's very challenging to kind of think of a legal precedent, unless we kind of take a step back and think about it at a, a social level, and not just a, a technological level. And I think that at a social level, what Bitcoin is, which set of validation rules Bitcoin is, is kind of the same question of what, what technical properties of a computer Make a computer a laptop versus a desktop, and there's no-- there's no formal definition of it, right? and there, the-- ev-everyone can disagree, you know, you could say, "Well, an iPad is a laptop," or you could say that, "Hey,

A, the new iMac is a laptop because it's, it's so compact and self-contained. So, everyone can have these kinds of debates over, semantics. And at the end of the day, it's kind of what in, when you're actually, engaging in commerce with someone else, and you're actually exchanging value, you're, you're part of, you know, catalysis in, in Austrian terms. what is it that- You and your trading partner are agreeing on. And so if you sell a, a brick on eBay and you call it a laptop, and the person-- you're, you're breaking that the, the counterparty's expectations. They were expecting a laptop and you mailed them a brick. Now If, if you can just go in front of a judge and say, "Well, look, Your Honor, I, I call bricks laptops, and, it's not really my problem that this other person doesn't share that same definition as I do, because that's just my definition of, of what a laptop is. It's, it's a, it's a cement brick." and so obviously, a, a judge would say, "Well, let's look at like, what would a..." reasonable person, you know, consider a, a laptop to be. And that's kind of the legal standard of like, what would a reasonable person, think? And that's, that's grounded in a, a, a social reality of what's called like intersubjective reality, which is that we have all these words to talk about things, and we have to have some kind of bridge between those two, and otherwise, I mean, society completely falls apart if, if we don't have this, right? If we, if we- We com-completely lose the ability to communicate meaning with each other, then, not only is commerce impossible, but e-even just any kind of social interaction, it quickly devolves into being impossible. So, the, this, let's bring it back to Bitcoin, right? So, if you were to sell BCH to someone and you say, "Oh, you know, I'm, I'm selling you Bitcoin," then it's kind of a question of how many other people agree with you That you sold that person Bitcoin, before it, it becomes a preponderance and it, it becomes, you know, what the reasonable person would expect. and that's deliberately, I think, I think, I mean, it's not deliberately unanswerable, but it, it's inherently unanswerable, and that's a good thing, otherwise Bitcoin would be centralized, right? If, if there was one person who, who said, "Hey, this is Bitcoin and this isn't," then Bitcoin would be completely centralized and, and they could change the definition at a whim So it's good that Bitcoin is an emergent social consensus among people, but it's disorienting for folks who want to make changes to the validation rules of Bitcoin, but ultimately are, are stifled by the, difficulty of changing so many people's, people's minds about what Bitcoin is and shifting what, what I call, or, you know, what I think is called a, a shelling point, and we can talk about, Kind of what a shelling point is, if you'd like.

Yeah, that's a fantastic point. So I, I really like the point you're making that it's really-- and it's, there's parallels there with like Austrian economics and praxeology and this idea of intersubjective perception of value and what really, what is What is the social consensus around that? so yeah, maybe it'll be a good idea to then, go now into the process of governance, and then, as we go through that, then we can talk about how that will help, you know, at what point people start to move that showing point. so maybe, we'll start with that process of governance. So, in your article, you talk about, research. So, do you wanna outline a little bit around that?

Yeah, so, there's, there's a variety of, of people, and I, I actually think that there's not enough people doing research, on, on the Bitcoin protocol. but basically the idea is that you would, use your, your, your tacit and explicit knowledge about both Bitcoin, its properties, and your, your vision for where you think it should go, and Have all of that coalesce into your ability to do research and, run experiments, run simulations, and see, you know, what kind of changes do I wanna make to the Bitcoin protocol? so I think that there's, there's not enough people doing that. part of it might just be like a, it's, it's, you know, a public good. It's, there's, there's not enough- It's underprovided, huh? Yeah. But, I actually, I mean, it's not that big of a problem from an economic point of view that there's not a lot of research going on, because you kinda do want the protocol to, remain very stable and, and- Not, not changing willy-nilly. but, once, once that, yeah, we, we-- And so one of the questions is like, "Well, what if people are researching the wrong things or not researching enough?" and I think that those are, there are fair criticisms of, Bitcoin's governance at, at the research stage. especially because like, if it's self-directed researchers who are not, employed by industry or by- Large hodlers, like they're, they're just going to research what they're inherently, intrinsically interested in, and that might not necessarily align with what users are expecting to have researched.

Yeah, fair point. Okay. And then, so the next stage you outline after research is, proposal. So, as you mentioned earlier with the BIP, what are some of the forms that a Bitcoin proposal can take?

Yeah, so I, I, I think that every single change to the Bitcoin protocol has been in the form of a bit, you know After, after BIPs started, which, was pretty early in the game. but obviously, I mean, Satoshi was making changes willy-nilly without putting out a, a proposal. And I, I actually, I think that's an important thing to dig into, which is that, Bitcoin's governance has been formalizing in a sense and maturing as Bitcoin itself has been maturing and as the amount of value that is secured by the Bitcoin network has been increasing. So back in the day, like Satoshi could put out, a, a change to the Bitcoin protocol, and not really, you know, have much scrutiny made to it, and it would just get merged, and he would, release it out into the wild, and people would run it without really questioning it. now changes go through a lot of scrutiny, and, this-- that scrutiny starts with the proposal, and so when they send an email to the Bitcoin dev mailing- Lists, it might link to a BIP, eventually that, that BIP will have a number assigned to it, and that, that BIP number is kind of what it'll colloquially be known as, as shorthand, and you'll, you'll hear, you know, references to different BIP numbers, you know, one forty-four, one forty-two, or one forty or whatever, and, or BIP one forty-eight for UASF, so these, These bits have no-- they're, they're not binding in a sense, right? So, they're more about trying to solicit feedback from people and seeing, gauging what the level of interest is, within the developer community about different changes. And, and it's also that they're, they're written in, in plain English. Now, some of them have like more specification to them and, they may have some pseudocode in it, but generally it's, it's something that, a, the general- Well, public would be able to read and provide feedback if they're knowledgeable about Bitcoin's, protocol.

Yeah, great point. I think- You know, Satoshi, naughty boy, not putting in a bit for all those changes he did. yeah,

although, I mean, he didn't really have a lot of people to communicate it with, right? And so, yeah, no, exactly. I'm kidding,

I'm kidding.

Yeah, no, but he, he did, he did, put out like forum posts, in the Bitcoin Talk forum, but yeah, it's just, it's a completely different world.

Yeah, the process has just evolved and changed, and I think we've all been learning as we go in a sense of how, how, how, what is the quote-unquote correct way to make a change to Bitcoin, and then not just the small changes, but really the big consensus changes, which are the ones that get more contentious. okay, so then let's say you, you know, we've gone through research, we've gone through proposal, what's the next stage?

So the next stage would be to, to, to take that BIP and to actually write the code that would be, implementing that BIP essentially. And that implementation Would generally happen at a, a, as kind of a pull request on the, Bitcoin core repository on the reference implementation, written in C++. and if there's, so there's, there's a process of code review around the, implementation, both of BIPs, of changes to the protocol, but also of any, any kind of change to, Bitcoin's, reference implementation. But the change- Changes to the, protocol r-receive a much higher degree of scrutiny, than any of the other changes, because if there were to be a bug in a change to the protocol, then that bug essentially, I mean, either becomes part of the protocol or, could cause a loss of funds, could cause a chain split, could cause some- Real damage to Bitcoin if it were to slip by the reviewer's eyes. And so this is a very important, stage in the process where, at the end of the day, it's, it's what's in the code that matters. It, it, what's in the Bibb is, is irrelevant. People aren't running the Bibb, people are running the compiled code. and so having a, a level of quality assurance around that, of, of testing- Seeing of, people really tr-trying to, trying to break it essentially and, deploying it on a test net and, trying to figure out ways where this will have unexpected results or cause, side effects that were, you know, unanticipated. So it's really, it's really hard to anticipate the unanticipated, but that's, that's what has to happen at the implementation stage if, if we wanna minimize and mitigate The risk of, a consensus change?

Yeah, great point. and then are there-- this one, we're sort of leaning towards- This concept of can, can Bitcoiners try to implement a certain tech and route around, so to speak, what the developers actually wanted?

Yeah, absolutely. so I think that there's, you'll often hear people say that the Bitcoin core developers or core contributors are gatekeepers, because they, they are the ones who control the, what's, you know, the reference implementations, Git repository, and they're the ones who r-released the client, the node software that is widely seen as being the, Unofficial, official, you know, co- or, client or node software that should be run by everyone. and so there's an element of truth to that, obviously, in that, participants in the Bitcoin ecosystem are going to be very apprehensive about running other pieces of software. and part of the reason is that there's kind of a path dependency, in that this, this Git repository on GitHub You know, Bitcoin slash Bitcoin is, in a sense, the successor to Satoshi's code base and is kind of on, On this path where it, it is the, the descendant of Satoshi's codebase and thus realistically has the lowest risk, and, you know, as the more, most battle-tested, codebase. but I think that, that, that, that can be overstated. I think that it's more than just the fact that, this, this Git repository and set of contributors has been around for a while. I think that it, it has a lot to do with the, the Bitcoin Core project's philosophy as well, and their, their competence, frankly. that they have been very good steward Of this code base and have released very reliable software over the years, so there's been some hiccups along the ways, you know, for example, the zero point seven to zero point eight, and, you know, I don't wanna point fingers around that, but the people who were most directly responsible for that are, are no longer with the project, but at the end of the day, I mean, it's kind of, it's on everyone, to, everyone involved With the Bitcoin Core project to be releasing the highest quality software possible, and that's why I think that there's such a strong culture of code review, in Bitcoin Core where you can have six, eight, ten people reviewing every line of code for a particularly important pull request, and, that's the way it should be. And so I think that that's part of the reason why, the, the "quote unquote," reference implementation has so much- Much credibility behind it is that it, it has a very good engineering culture. Now, all that said, if someone wants to take all of that code, which is open source, right? It's, it's all available for free, as in beer and as in speech, and you can copy-paste all of that code, you can fork it, i-i-in, in the, in the Git sense, not in the, in the Bitcoin sense, but you, you can clone that repository and make your own little changes to the code or, or big changes, and compile it And release it out to the public, and try to persuade people to run your code. Now, to persuade people to run your code and to run your, your binaries, you're, you're going to have to demonstrate either that you have a, a track record that Gives you some credibility in this, or, you know, you, you put out some very well thought through media articles or, or, some very compelling tweets or wh- whatever it may be that, that persuades people that, hey, you know what? not only am I, and, and, you know, I'm going to run this code, and I'm, I'm going to rely on it, and I'm going to use it to verify payments that I receive when I'm expecting to receive bitcoins, and I expect other people to be running this code as well because it is obviously superior to, the previous code that we were running. so that process of persuasion, can be very challenging if you don't have a track record of, not only contributing to, the existing, reference implementation, but also of having ideas about changes to the protocol that are just widely recognized as being compelling, and also not being compelling to the reference implementation, to the Bitcoin core contributors, right? Because the premise of, of the question here is that The, someone has a change to Bitcoin which the developers, find to be lacking, but that the public would find to be compelling. And I just, I, I think that, that Scenario is, is kind of far-fetched, even though it's, it's theoretically possible and, and interesting. but the closest we got to it was with UASF last year, BIP 148, where essentially, Shawn Fry, who is a, pseudonymous, developer, created a change to the Bitcoin protocol rules where after a certain point, Blocks that didn't have SegWit enabled in them wouldn't be accepted, by the node as valid blocks. And so if you were sending a payment to someone who is signaling UASF and UASF has activated, that, that payment wouldn't go through if, if you were incapable of getting it included in a block that was mined by a UASF miner, by a- Not sorry, not by a UAS F miner, a SegWit miner, which is, it's subtly different, and so that was seen by the Bitcoin core contributors as, if, if, if that were included in the reference implementation, that it would be disruptive to the ecosystem, and I think that they were right in having this concern and Simultaneously, I think that the UASF, contingent were right in, in asserting the sovereignty of the nodes over what gets included, what is a valid block. because there's kind of this perception that, hey, it's the miners that get to decide what a valid block is, and I, I think that's actually, a profoundly wrong reading of, of how Bitcoin system works in practice. Granted, you know, maybe that's not what was written in the, in the white paper. We can, we can debate that because there's language there that's debatable as well. but, in practice, Bitcoin, Bitcoins, the validity of Bitcoin blocks and transaction is set by people running nodes and accepting payments with them. but anyway, I'm going kind of on a tangent here. yeah, so UASF was a situation where Shachal and Fry copied the Bitcoin core repository, made the changes that he wanted To see made to that code and then release the binaries and persuaded such a large contingent of the Bitcoin ecosystem to run his code that the miners ultimately capitulated and, you know, went along with SegWit. It was kind of a, a game of chicken of who, who would, who would, you know, turn the wheel first, but, ultimately the, the SegWit activation happened, and there's lots of controversy around that, but, we can save that for another podcast.

Okay, yeah, great points there around how there's a sense of path dependency, but also, a factor of competency of the team who are developing and coding into Bitcoin. the, the next thing that I thought would be good for you to outline for the listeners would just be around the forms of signaling that are available. How, how can people signal which side or what, what they want?

yeah, so I guess we could, we could first point out that, there, there is no good. And I'm, I'm, let's, well, let's be more specific. There's no perfect way of signaling. and thus, in a sense, Bitcoin's consensus is a shelling point, which is a, a focal point that, people agree on without ever communicating. And so the, the, the best example of it Is, this question of if you were meeting a complete stranger in New York City and you have to figure out where, where to meet them, where, where do you think that you would run into them and at what time? and so- I, I, I don't know if you know the answer already, Stephan, do you?

Yes, so I've, I've heard, the, the example, which normally is 12 noon at Central Station, which makes great sense to me.

Yeah, so it would be cheating if I asked you in earnest, what time, but, or, or where, but so, yeah, that's exactly right. And the- The, the point there is that, like, it's not that everyone shows up at Grand Central at noon. In fact, I think that it's like sixty to eighty percent of people who do. But, it, it remains that that's kind of where the plurality of people show up, and that's based on kind of the topography of the map, right? Which is, you know, when you think about, okay, what's kind of the, the, the best transportation hub in New York, Grand Central? Okay, and then we think about, well, what, what, what, you know, what about the Statue of Liberty? Alright, that's wildly inconvenient to get to, you know, the, the person wouldn't be there. or what about like the Empire State Building? Well, that's kind of out of your way as well. And, so all, all these different options where you can kind of rule them out and you can determine, well, you know, Grand Central, if you really think about it, is probably the best geographic location. And then in terms of the time

You know, whether the person's a morning person or an evening person, we don't really know. everyone's awake at noon generally, unless they really had a hard night out. Yeah. and, you know, people are off for lunch, noon just kind of makes sense. and so- We can know these things without ever communicating with the other person, right? and without ever telling them, "Hey, look, what's your favorite place to meet in Manhattan?" or "What's your favorite time to meet?" and you just show up and there you are. So that's kind of a selling point. And I think that Bitcoin functions much in the same way. Now, a, a big part of it is back to this issue of path dependency, right? And so the, the default place for us to meet is where we met yesterday. and so that's kind of what the consensus rules were when Satoshi put them in place. So that's what we have today, is that the overwhelming majority of the existing block and transaction validation rules are what Satoshi made them on day zero, of Bitcoin. And we've kind of been on this path of, "All right, we've, we're five hundred thousand blocks in, what are the validation rules for what Bitcoin is today?" well, I mean, they're gonna be the same that they were ten minutes ago. And To, to change that shelling point is extremely difficult, and thank God, because if it wasn't, then we would have Keynesians, we would have inflationists, socialists, all, all sorts of people who wanna change Bitcoin's monetary policy, trying to shift that twenty-one million Bitcoin shelling point, you know, any way possible. So it's good that it's hard to shift, but it's, it's, it's bad in the sense that- So that if, if we're trying to make it so that Bitcoin, the base layer is improving and upgrading, then we've gotta kinda herd a bunch of cats, because people are gonna have all sorts of different ideas about how to change the, the protocol that might be pulling in different directions, Or are just, pulling against the status quo. So you gotta signal what changes to the Bitcoin protocol we wanna make and what, what shelling point are you gonna be showing up at? And you can't really-- So the way to do this is on social media, right? So you, you hashtag UASF or hashtag No2X. if No2X in, in that case was about, you know, staying Staying on the existing shelling point and, is, is keeping the status quo, but UASF was about moving to a new shelling point of refusing to accept, non-segwit blocks. and so these are, these are imperfect forms of signaling due to what's called a Sibyl attack, which is basically that someone could create a bunch of fake Twitter accounts or pay people on Twitter to, to signal these things. and the- The, the countermeasure to a Sybil attack like this is, ironically enough, is having a web of trust. That is, having people that you know in your life, you know that they're intelligent people, you know that they actually do use Bitcoin, they actually own Bitcoin, they actually care about Bitcoin, you actually respect their opinion on Bitcoin and what Bitcoin is and what it stands for and what its future is, what its philosophy and its past is. All these These really, soft, you know, social aspects of Bitcoin, of, of, of, of a Bitcoiner. You know, we, we each have our list of who we consider to be Bitcoiners and who we consider to be Shitcoiners and who we consider to be NoCoiners, right? And, and we have within those lists people we trust more or less, for lack of a better word. And, and it's, it's the, the paradox, the irony of it is that we talk about Bitcoin being- A trustless system, and wanting to maximize trustlessness. But I actually, I think that, Bitcoin is a, a way of compartmentalizing trust and of really, having trust Be limited to the things that you wanna trust people for, and then removing trust in a lot of other aspects of it. and in a sense, it actually kind of makes trust more important. it, it shifts trust, it doesn't, remove it entirely in, in my mind. but yeah, so if you have a web of trust and you know that, hey, I, I trust Stephan Livera, I know that he controls this Twitter account I've never met him in person, which is crazy to think about, but I've known you on Twitter since 2013. so if you had a hashtag on your account about what kind of consensus change you wanna see happen and what kind of software you're running and what kind of software you wanna see other people running, that's gonna have a lot more credibility than someone who just joined Twitter a month ago and has, you know, the default, you know- The Twitter bio and the Twitter image. Yeah, the egg. And, and they don't have any tweets, they don't even follow me. You know, it's like, okay, why would, why would this account have any credibility if--

I think the lesson there is, if you're not following Pierre Rochard, are you even a Bitcoiner?

Yeah, that's a valid question, at this point. But now that, that, you know, we'll give people the benefit of the doubt. There's, there's folks out there who, haven't gotten around to hitting that follow button. So if that's one of you, take a moment right now and, log on to Twitter and, and do that. and follow Stephan Livera, too, obviously. but yeah, so this, this web of trust is kind of a way to mitigate the issue of, s- being s Now, the, the other signaling mechanism that people will talk about is miner signaling, and I actually, I think miner signaling is even more problematic than Twitter hashtag signaling. and the problem with miner signaling is that miners really don't have a strong view on what should be going on with the Bitcoin protocol itself. what, what they care about is kind of the, the The fiat value of Bitcoin, right? Which is that if the fiat value of Bitcoin is going up, they're, they're paying their, their electricity costs out in fiat, and that creates a spread for them to, make a, a handsome profit on, until, you know, obviously the hash rate goes up and the difficulty adjusts. but the fiat value is completely disconnected from changes in Bitcoin's protocol. and I think that that's something- Something that is very hard for people, to wrap their minds around because we, we kind of have this instinct of, well, if the Bitcoin protocol improves, then Bitcoin's price is going to go up, right? and I think that's really misguided.

Yeah, it's not a one-to-one relationship, and it's, it, it's sometimes leading and sometimes lagging. So

I, I would question whether there's-- I, I would question whether there's a relationship at all, actually. I think that the, the relationship between Bitcoin's protocol and the price is the one, the monetary policy, right? The twenty-one million bitcoins, and so that, that has to do with the block header, verification rules, and so- The block header has the, you know, the mining in it, right? The, the, the nonce and, all of that, the, the difficulty and, how many, how, how, how many bitcoins are getting created in, in a block. but, So that monetary policy, I think, is kind of the, the first driver of Bitcoin's price. the second one is the credibility of that monetary policy, and so that has to do with what we're discussing today, right? The, the governance of, of Bitcoin. and so the, the harder it is to change that twenty-one million cap, the, the more credible Bitcoin's monetary policy is, and that lends a lot of, confidence to investors. and then the last- The last element of it, I think, is just how, how much time has elapsed since Bitcoin's inception, and I think those three combined Form the fundamental value of Bitcoin around which the price oscillates based on the animal spirits of these insane speculators that are on BitMEX going a hundred x leverage, right? and that are, piling in when the price is going up and really, momentum trading, and then freaking out and panic selling when, when the price is going down. and, you know, they're, they're trading on noise, on, on- News on, epiph phenomenon like that, but, really I think the, yeah, the, the monetary policy is what all of this oscillates around, and, and, and time, the, the Lindy effect, if every day the Bitcoin continues to exist, is another day that we can continue to expect it to exist. yeah, yeah. So all that to say that I think that adding, you know, a new opcode to Bitcoin's, Bitcoin's, consensus rules or, or in- Increasing the block weight limit or, you know, SegWit, like, I don't think those, those increase Bitcoin's price, and I don't think that they increase Bitcoin's value. so they're really, they're, the, the, they, they occur because people have an itch to scratch, and that might be that they, they want to use Bitcoin, i-as a, you know, settlement layer or as a payments layer, and- So that's why they're going in and making these changes to the consensus rules, but I don't think that it changes Bitcoin on, on a monetary level and on an investment level, it, it, you know, it, it helps on a payments level.

Yeah, agreed, agreed. Okay, well, I think that while we're on this topic of the shelling point, do you have any comments on what parts of Bitcoin would be very, very difficult to change or almost impossible, and what other parts of Bitcoin are more amenable to change?

Yeah, I mean, there's, I think there's a long list of entirely non-controversial changes that could happen, even in a hard fork, and really the controversy is about the hard fork itself, not the changes themselves. but, you know, the things like,

we can actually, we can look at past changes to, to Bitcoin's validation rules and see what, what shelling points are very easy to shift. And so I think that, transaction formats, you know, like SegWit, like that was probably the most controversial change that's happened in the history of Bitcoin, which was, you know, re-removing signatures, but also just changing signatures. So right now we're using ECDSA. there's a proposal or there's-- I don't know if it-- yes, so I think there's a bit now, yeah, that's right. There was recently a bit made for changing to Schnorr. Right now, it, it seems like a shoo-in, but I would really caution-- and I, I, I might start harping on this on Twitter soon. I, I think that there's needs to be more input from a wider range of people, especially cryptographers, on what, what Bitcoin's signature, You know, scheme should be. And, right now we have Peter, you know, who's associated with Blockstream, and, he's kind of the main driving force behind Schnorr, and, there's, there's a lot of other people who agree with him, and I, I think that there's no harm in having more people, vocalizing either their opposition or their support to Schnorr. what, what I would not want is that, Schnorr kind of gets decided on, by default, rather than by a strong process of deliberation and then rough consensus, so It seems that that's going to be uncontroversial, but I want there to be more controversy about it. And, and then you can-- on the other end of the spectrum, you have things like changing the, block reward, so increasing the block size limit beyond twenty-one million and having like a continuous inflation rate, like that Hugely, hugely controversial and in my mind, basically inconceivable at this point. I, I don't-- There, there are people who are debating the long-term security of Bitcoin without having, if there is no inflation and we're entirely reliant on transaction fees, I, I think that debate is worth having and it's interesting, but I, at the end of the day, I don't think that it actually will, lead to a, an increase in, in Bitcoin's, hard cap, and, I would be very disappointed if it did. And so the only reason that I think the twenty-one million hard cap would be changed is if there was a, a serious, serious security issue around it, and I, I don't think that even, even the, the, the people who are saying that there is a problem with the hard- I don't think that the, the, the arguments that they're coming up with are compelling enough to, to say that it's a security, a serious security, security issue. I think that what they're pointing out is kind of an inconvenience, not a security issue, which is that you, we're gonna have to wait for a lot of confirmations, in the future. so to have the same level of finality that we have with six confirmations today, maybe we'll need sixty or six hundred or six thousand confirmations in the future, but that's not I, I don't think that's, a reason to, to change the twenty-one million hard cap. now, so in between those two extremes, we have, changing the block weight limit, and I've seen people argue that we can do that with a soft fork, seen people argue that that's only doable with a hard fork. in either direction, it's controversial. The reason it's controversial is, is very similar to the reason that the block size limit debate was highly controversial before SegWit, which is that the full nodes maintain a full history of the Bitcoin blockchain, and in order to have a, a UTXO set that is kind of, fully validated in that they've looked at every single block since the genesis block, and that's what has formed this UTXO set that is the, the record of who owns what bitcoins. which, I mean, frankly is like the most important thing in Bitcoin, right? The UTXO set. you have to download every single block in the history of Bitcoin and then run it as, you know, a change to the UTXO set and validate everything associated with it, all the transactions, all the inputs and the outputs, and, you know, the, the block header and whatnot. So All of this, all of this overhead, is put onto nodes, and nodes aren't compensated for this. So essentially, it's kind of a negative externality. the reason that people run full nodes is so that they can verify payments that they personally are receiving, and to verify that essentially that their, their one bitcoin is one out of twenty-one million bitcoins and not one out of Twenty-six million or whatever, and so, you know, they can make sure that they're on the right consensus. And anyway, all this to say that it, a change to the block weight limit would be controversial because you're, you're increasing the negative externality, and you're also changing the economics of Bitcoin in the sense of, if we're concerned about the Bitcoin hash rate at equilibrium in the future, then we should be concerned about how do we maximize miner revenue? And the way to maximize miner revenue is to create artificial block, space scarcity, so that we can have a good competitive fee market, and increasing block supply, affects that, that market.

Yeah, yeah, agreed. Okay. so I think that sort of is a good, discussion around deployment. How about now enforcement? So I've seen, some, one good way I've heard of putting it is, one of the guys on Twitter, Stop and Decrypt, one of his articles, he talks about Bitcoin as an impenetrable fortress of validation. so Pierre, how are changes enforced in Bitcoin?

I hope you have Stop and Decrypt on your podcast, soon, because he is, quite prolific on, on Medium. He's, written some really good articles. so I think that I, I, I did touch upon it earlier in the episode of essentially if someone is transmitting an invalid, transaction or block, then they get disconnected from the network, and that's what, that's what makes it an inpen- impenetrable. Fortress of validation. but in terms of, I mean, with the deployment, you know, you gotta make sure that everyone's running the, the same consensus code that you're expecting them to run, and with the enforcement part, what it comes down to is If you are, if you are selling a good or a service, or let's say you're selling your fiat for bitcoins, and you wanna receive bitcoins, you, you have to choose what is my definition of bitcoin? So if you're a BCH user, your definition of Bitcoin, BCH, you know, you're gonna go download that, that node software, but, if you're thinking that you wanna, you wanna stick to the current shelling point of Bitcoin BTC, then you gotta go download the reference implementation or other implementations that are currently compatible with the reference implementation. Now, with the caveat that maybe, maybe run both the reference implementation and an alternative implementation. Just to make sure that you're, you're in consensus. and then the, that person is going to create, the person that is selling bitcoins to you is going to create a bitcoin transaction for you, and they're going to, broadcast it to the bitcoin network, and your node, as part of the bitcoin network, is going to eventually receive that transaction that's being broadcast. and if, if you determine it to- To be valid, then it'll be added to your mempool, and it will appear in your wallet as having been seen as an unconfirmed transaction. So at that point, that's how you have enforced a definition of Bitcoin, which is that if that person had sent you an invalid transaction, you would never see it in your mempool, and you would never see it in your wallet, which is attached to your full node. and thus you would never recognize that that person had sent you bitcoins, and you would be on the phone with them asking them, "Where are my bitcoins?" Right? So yeah, yeah. You have, you have enforced the Bitcoin protocol, by, by, by your actions and by delegating your actions to your node and automating them with your node. Now Eventually, you would wanna make sure that, that transaction gets included in a valid block. So, a miner, if they are running the same consensus rules of Bitcoin, a Bitcoin miner, now, granted, I say, you know, a Bitcoin miner, but if they're mining SHA two fifty six squared, they don't really care like what consensus rules they're mining, is, you know, they, they wanna get paid and whatever is profitable to mine at that point in time is what they'll mine. but setting aside That, they, they will include that, transaction in a, a block, that then, that block will get broadcasted to the Bitcoin network, and your node, as part of the Bitcoin network, will eventually receive that block, and your node will verify that that block, the block header, has the correct proof of work in it, and the, contents of the block, are all valid as well, all the transactions in it are valid, and the The, you know, the, the Merkle tree is, is all valid and all that, and, and that your transaction is one of those block, or, or one of those transactions in the block. and at that point, you can say with some confidence that not only do I own bitcoins, but, there is some finality to the transaction that was, broadcasted to me. and the your confidence in that finality, only increases as new blocks come in, you validate them, they're b- Bitcoin blocks, you add them, and the depth, at which your transaction is in the blockchain, continues to increase. And, you know, people have different rules of thumbs of what depth they consider to be safe, but, you know, it can be from two to six.

Yeah, yeah. Yeah, I like that, and that's a good articulation as well of, let's say I liked one particular side of a fork and I didn't want the other, well, that is how, you know, running that node is how I can ensure that I stay on the chain or the side that I want to stay on. So yeah, that's a good point. I think now, now that we've sort of run through the process of, you know, Bitcoin governance, with the full benefit of hindsight, let's, you know, just- I, I'm curious to get your comment or, you know, sort of post-mortem on some of the failed changes in Bitcoin's history. So, you know, what did they do wrong? And one example that might be-- it could be that they didn't build consensus before attempting to fork. Do you have any comments?

Yeah, although, I mean, I think that, you know, if you, if you try to build consensus before you fork and you fail, but you really want to fork and you think that after you fork that- People will eventually recognize the superiority of your consensus. then you really have no choice but to just go ahead and do it. now, as I was saying, like, I don't think that Bitcoin's value comes from, You know, making changes to the protocol itself, so I don't think that, that would ultimately result in success. And as we see with the, the Bitcoin Cash hard fork, where it, it's, it's really-- it hasn't, its trading hasn't broken out any higher than it, you know, what it was at at the beginning, and it reflects the, you know, ten percent of Bitcoiners ended up, and that's, that's being very generous, ten percent. Probably wasn't that. yeah. Ended up going to, the Bitcoin Cash side of the hard fork, but I think there, in terms of like, okay, you know, this person, you know, Gavin Andresen and Mike Hearn and, and Jeff Garzik, they all failed to gather consensus on their changes, and, and you know, let's- Let's not take that as a given. Let's look at why, why is it that they failed? is it because of the changes themselves, right? The, the substance of the consensus changes? I think that's certainly a, an element of it. I think that it, it would have, Gone perhaps a lot more smoothly if the increases to the block size limit and, in, in Jeff Garzik's instance, the block weight limit, if, if those changes had been, at the margin rather than, doubling, then or, quadrupling or, you know, like I think that, that, Gavin wanted to go to thirty-two megabyte blocks, like. Crazy stuff, but anyway, those changes are just much too radical. Like, I, I don't think that they had a chance on their merits, from the beginning. so I think that if they had, done a marginal thing where it's like, "We're going to increase the block size limit or the block weight limit by, let's say, fifty kilobytes a month or a quarter." Then, you know, that's, that's something that maybe would have gathered a lot more consensus, around. so setting aside the substance of it, then we can kinda get into the, the communications strategy of it. so basically they were, they weren't, they didn't get a lot of traction with the Bitcoin core developers, and so they took it to the public, and Gavin wrote some blog posts, About increasing the block size limit at the time. And, you know, they, they circulated around, they were, posted on Reddit, and they, they were widely read, they were widely discussed, and ultimately they were unpersuasive. I think that, that Gavin didn't not, engage in the rebuttals to his arguments. the, Gavin was, either out of just- Incompetence on his part or maliciousness, creating, straw man arguments and not steel manning his opponents. And so I think that that, reduces your credibility, and reduces the credibility of, of the consensus change that you're advocating for, which is unfair. Like I think that the in- the arguments for increasing the block size limit, pre SegWit, and then increasing the block si-block weight limit post SegWit and to this day There are very good arguments for doing it, and they, in my view, have not had, justice done to them by their proponents, and it's kind of a shame because, you know, the, the strongest argument Against, increasing the block size limit and the block weight limit is that we need to break this expectation that transactions on Bitcoin are free or c- or, or of a negligible cost. and start attaching a, a cost to them because eventually we're going to hit a, a block weight limit or a block-- or, well, yeah, let's call it a block weight limit at this point, that does reduce, decentralization and does so dramatically increase the run, the cost of running a full node, the decentralization is impaired. and, you know, that, that might not be at the, the limit limit that we're currently at of eight million weight units, but we're not that far from it, and so why not break that expectation now and once people have it firmly in mind that, no, look, transaction on chain with Bitcoin, has has consequences to it, and has a cost attached to it, and, as the transactor, you will, bear a significant amount of that cost, you know, as, as kind of a proxy, to, to, you know, it's, it's not like the transaction fees go to the nodes, but it certainly, it works as a deterrent for, you know, mindless consumption of block space. so I think that Gavin and, and Mike Kearn and, and Jeff Garzik could have put forth a, a really good, solid case of, look, we agree that we cannot continue to increase block space consumption indefinitely. but, and we agree that we're going to have to break user expectations eventually, and that every business can't be, you know, validating or, or sorry, every business can't be, you know, Visa on the blockchain, and, you know, we're not, we're not going to scale up to Visa, and, and that's okay. But at this point in time, it is sensible that we would bump the block size limit a little- A little bit, and, kind of, yeah, it's kicking down the candidate, down the road. but it's, it's the prudent thing to do, and, and we'll, we'll develop layer two over time, and it's already in the works, and, that'll be great when it happens. But in the meantime, like, let's, let's buy ourselves a little breathing room. and I don't think that they made that argument particularly well.

Yeah, I see. Yeah, no, that's a good point as well. Okay, let's now contrast Bitcoin's network governance versus other, blockchain governance. there was an interesting statement I saw by Nick Szabo, and he was saying blockchain governance generally comes in three varieties: one, "Lord of the Flies," two, "Lawyers," or three, "Ruthlessly Minimized." how would you, fit Bitcoin into that category and maybe compare it against some of the other alternatives?

Yeah. so I, I think that in, in, in this framework, it definitely fits under number three of ruthlessly minimized. And basically, in terms of, minimizing the, and I, I would, I would a, almost characterize it as a, a tax surface, which is that people can use governance decisions to attack Bitcoin's consensus, and I would argue that's what happened with the block size limit, but how you minimize that attack surface, how you, how you minimize the scope that governance has to deal with, is that you minimize the, set of validation rules that form the consensus, right? The, the, the set of opcodes, the set of Of different, denial of service, countermeasures, whether it's SigOps or the, block size limit, this, this set of block header, verification rules. And so there you could say like Like the biggest can of worms you could open, and the biggest maximization of, governance that you could do would be to say, "Oh, you know what? We're gonna have on-chain miner signaling for how many bitcoins get created with each block." Right? Like, "Alright, now, now we have the FOMC. We've got, we've got a central- Banking, monetary policy, Lord of the Flies situation with, with Bitcoin's monetary policy, like that would be the, the, the ruthlessly maximizing the attack surface of governance. so I'm using that kind of as a, as a reductio ad absurdum of, And so I think Bitcoin does a really good job of, ruthlessly minimizing the, validation rules that, are being governed. and you can put Ethereum on the opposite end of the spectrum of We are running a, what was a, I don't know if it's still a turn complete world computer, where there's basically an unbounded number of, verification rules of governance, you know, attack surface and Not only that, but it, that's kind of on a technical level, on a social level, we have an unbounded set of expectations from users, of, Yeah, people want to have health records on the Ethereum blockchain, but they also wanna do, decentralized betting on Augur, they wanna do, you know, ICOs, they wanna do DAOs, and what we saw with the DAO hack Was that there are negative externalities from all of these different, user expectations that spill over onto the consensus rules, where essentially you're having to, adjudicate disputes that emanate from people using your blockchain for Non-payment, non-monetary use cases. and the, what, you know, now, so, you know, I was talking about Bitcoin improvement proposals. There's Ethereum improvement proposals. And so you have Ethereum improvement proposals relating to the monetary policy. You have them relating to fixing, people who have created smart con- well, I call them smart contracts, but, you know, they're pretty stupid. stupid. Contracts, that caused their funds to get stuck, and the only way to unstuck them is with hard fork. and now you, you have developers that are, you know, the judge, jury, prosecution, and defense. Of all these, these issues that are really, are, are, are, are, are-- Oh, and you know what? I-- It's really unfair that I put Ethereum as the, The opposite of Bitcoin, because there are worse than Ethereum. There's EOS and there's Ripple. and, you know, Ripple like has the ability to freeze XRP, because Ripple is like a centralized system, and they have to conform with, anti-money laundering, statutes here in the United States. And so if XRP needs to get frozen, then Ripple needs to comply with that, and, and then with EOS They, they wrote a constitution, like in a word document. So there it's like, they're, they're, they're trying to LARP, you know, they're, they're role-playing as lawyers, as the founding fathers of, of this governance system, and, and then you have people saying, "Well, you know what?" People are creating Ponzi schemes on EOS and it's giving us a bad name. We should ban Ponzi schemes and we should seize their funds and give them back to the people who entered the Ponzi scheme. So at that point, you've basically recreated, you know, the, the existing financial system, in a ad hoc, Lord of the Flies slash, fake lawyers, scenario.

Excellent answer, Pierre, I loved it. Excellent. yeah, just a great summary of, the distinction between how Bitcoin works and how every other coin basically works. okay, so Bitcoin has changed and it's morphed over time. The, you know, there are things that we have-- there are, there are developments that happened that were, that were just not described in the white paper. Do, do you have any examples of that?

yeah, I think that, actually, I would go check out David Harding. He has like a irata page on the white paper, basically detailing a lot of things that were either, inaccurate in the white paper or have changed since the white paper, or, we've, we've learned more things since the white paper. I think that what-- something to keep in mind, i-my first point on this issue is that, Satoshi- She wrote the code before writing the white paper, and this is kind of like a little known fact, and so we can kind of glean from that that the white paper Is just a description of the software he wrote, high level, very high level, and not entirely accurate and not fully specified. Like, he doesn't say in the white paper or others, only twenty-one million bitcoins. And in fact, the, the, the first- you know, release of Bitcoin, while, while Satoshi intended for there to only be twenty-one million bitcoins, the code that he implemented that, in was Was not that, it's, at the end of the creation of new bitcoins, it resets. And, Peter Walle had to create a BIP that addressed this bug as a soft fork, to change Bitcoin's validation, block validation rules so that we don't have more than twenty-one million bitcoins getting created. So already we can see that, first of all, the white paper is not A specification and is just a, a communication tool really of, him trying to, because it's, it's very hard to put on a mailing list, "Here's all this code I wrote, you guys have to go read through it now to understand what I did." You know, like that's kind of putting the burden on the reader. but Satoshi wrote a high level description of his solving the double spending problem with proof of work. and that's, that's kind of What our expectation of the white paper should be. We shouldn't try to expect more from the white paper than that. what we should expect, what, what we should expect from, is, is the source code. And, and then the second point is that, that source code has evolved a lot and the network has evolved a lot. And the reason that the network has evolved beyond what Satoshi described is that it's decentralized. So if Bitcoin was centralized, then, yeah, it would be easy to set it in stone and make sure it never changes. But because Bitcoin is decentralized, there's nothing stopping Bitcoiners from having Bitcoin evolve into something other than what Satoshi envisioned. And that's okay. Like, I don't think that we should manacle and shackle ourselves to what we think Satoshi's vision was, right? because he's, he's not around to- To tell us whether we're correct about, our, reading into what he wrote, and we don't know that Satoshi wouldn't have changed his mind about things as they evolved. So, it's, it's, it's wild to suggest that Satoshi had a, Foresight and he's a soothsayer, and he can predict the future, and, and Satoshi said that this will be Bitcoin, and thus, you know, he, he would never have changed his mind, and he would never have, updated the, the code or something like that. It's like, it's bizarre to see people saying this, and it's, it's, it's the craziest form of worship in my mind, the, the kind of uncritical, assumption. And, and then it's, it's al-also Utter pure hypocrisy, in the sense that a lot of the people promoting this point of view of Satoshi as a, a soothsayer and a, a visionary is that they, they, they are, they are in the Bitcoin Cash camp. And Bitcoin Cash has not only hard forked to increase the block size limit back to where it was before Satoshi implemented the one megabyte limit, but they've also, you know, made other changes to the validation rules that Satoshi didn't envision either, and have added back opcodes that Satoshi had removed and want, and new opcodes that Satoshi- Satoshi didn't, predict what happened. So, it's kind of, I don't, I don't think that there is, well, so the only implementation that truly follows Satoshi's vision is the one that he released back in two thousand nine, and no one runs that anymore. So, I think that we should kind of accept that, things have moved on since.

Yeah, agreed, agreed. And, I mean, there's obviously I will link that, David Harding page. It's a great page, I think it's called Bitcoin E-Rata. I'll, I'll definitely link that. And, there's definitely a lot of, a lot of things that have changed. So there are many things that weren't described in the white paper, so multi-sig, mining coins, the twenty-one million coin cap, ASIC mining, ten minute block times, HD address generation, a bunch of things. And then I was explaining what the white paper actually got wrong. So the security model, Moore's Law isn't reliable, the longest chain isn't secure, the SPV, aka, the fraud proofs or alerts, this concept of one CPU, one vote. So, yeah, I think you've outlined a lot of great points around why Bitcoin has changed and it- It, it necessarily must change because it is decentralized. I think the- Okay, well, I think, yeah, go on.

Yeah, the, the most important one in, in my mind, at least politically that you listed there is, is the SPV security, which is that, SPV currently in Bitcoin is like profoundly broken, from both a security and privacy perspective, and, I think that right now the, the, the only trustless way to use Bitcoin is to run a fully validating node. and so I think that if, if Satoshi were around, he would probably agree with that assertion. And there's a lot more work that needs to go into SPV, before we can say that it is, as secure or as trustless as running a full node. I mean, not that I, I don't think that it will ever be as trustless, but at least approaching that.

Yeah, yeah. Well, yeah, that, that, that's a good point as well. okay, so I think, have you got any other points that you wanted to make at this point, Pierre? We might start wrapping up. So just any final comments on Bitcoin governance?

yeah, I, I, I wanna see, I wanna see more Bitcoin core contributors. and I wanna see more, players in the ecosystem, forming their own teams of Bitcoin core contributors. So like, you've got like the Chaincode Labs guys who are doing a fantastic job. You've got Blockstream guys who are doing a fantastic job. You've got independent contributors here and there, you know, Jim Posson at Coinbase, done a fantastic job you got Schwartz Provost at, blockchain, dot com. Excellent. I wanna see more. I, I, I, I think that, there is definitely room for a, a huge increase of Bitcoin core contributors, both from people who are looking at the Bitcoin protocol itself, and who are making improvements to the reference implementation, modernizing the code, refactoring it Reviewing pull requests with a very close eye, improving the test framework for Bitcoin Core, improving the tooling around it, indexing, you know, addresses, you know, all, all these different, things that it, I, i-it's fantastic what, what the current set of contributors is doing, and we're getting lots of new contributors all the time, but I really think that it's not like- We're at a saturation point. I, I don't think that there's too many cooks in the kitchen at all. and if you look at the Linux kernel, there, there's kind of, you know, it started out with just Linus Torvalds in the nineties, or I think it might have been the late eighties, early nineties, but, it, it grew and grew and grew, and now you have hyper-specialized kernel developers who are very focused on one specific part of the kernel, and because the code base is highly modular, they, they Actually have to, you know, worry about the rest of the code base. And I, I'd like to see the same with, the reference implementation where we can have dozens of regular contributors, that are, working on their own parts of the code base, and there's, all, all of these changes roll up the, the, the, the, the chain of maintainers, so that there's kind of a, a coherent, you know, code style and all of this. But, yeah I, there's, there's just more resources that can go into Bitcoin Core development, and I'm, I'm disappointed when I hear people, complain about the direction of Bitcoin Core or, complain about the, perceived power of, certain Bitcoin Core contributors, because I really think it's just a matter of stepping up and, the sooner you step up and start contributing, the better because you start building a reputation and that reputation- And then will allow you to make more and more substantive changes to the code base until finally, you know, you're, you're the one proposing a soft fork or, god forbid the day happens, a, a hard fork, and, you, you have the clout and the reputation and the credibility to actually be taken seriously. And so, yeah, I, I just wanna see more Bitcoin core contributors. I think that's, that's the, the, the most, the healthiest thing we could see for Bitcoin's governance today.

Yeah, fantastic. Agreed with that. Okay, guys, so you can find Pierre on Twitter at pierre underscore rochard. Definitely, if you're not already subscribed, look up his podcast that he co-hosts with Michael Goldstein, look up Noted Podcast, and you can find the website for that, I think it's noted dot org, right?

That's correct. Yes, N O D E D.

Yeah,

and

also check out his, site and company, Bitcoin Advisory. yeah, so, so, thanks very much, Pierre, and, appreciate your coming on the show today.

Thanks for having me on, I really enjoyed it.

Okay guys, so that was the episode with Pierre, and that is SLP11. So if you go on my website, stephanlivera.com, you can find the show notes for that. if you wanna, just, if you got value out of this, remember to subscribe to the podcast, Stephan Livera Podcast, on Apple, iTunes, Stitcher, or Spotify. just, yeah, subscribe to the show and share it with your friends. Any feedback, come and find me on Twitter at stephanl For me, guys, and I'll speak to you next time.