The Power of Bitcoin with Gloria Zhao - WBD810

(upbeat music) - There's just so much to do, just in terms of understanding the code better and fortifying it. Sometimes you need to invasively change something in order to make it more scalable. So it's not don't ever change the code, you know, be conservative and not try to move fast and break things. - Hello there. How you doing? Happy Wednesday. Welcome to the What Bitcoin did podcast. We'll keep you by the massive legends of Iron, formerly known as Iris Energy. Iron is using their next generation data centers to power the future Bitcoin mining and AI using 100 ever renewable energy. Iron remains the same business, but the same goals now were just a different name. I'm Hosepit and we'll call Mark. And as they we have the amazing Glorious Owl on the show. Now at the end of last year, I was lucky enough to spend some time with Glorious Owl to Africa. And since then we've been trying to get on the show. Now Glorious is a Bitcoin core maintainer and developer. And this interview, we get into the importance of continually upgrading the protocol as opposed to ossification, ditching Google to welcome Bitcoin ordinals and memples spam and the power of Bitcoin core maintainers. I really enjoy sent out with Glorious. She's amazing. Enjoy getting into this. Hope you liked it as well. As ever, if you have any questions or feedback, hit me up as hello at whatbitcoindid.com. 1, 2, 3. What? Oh, do I say 4, 5, 6? Yeah. [LAUGHTER] That's the start of the show now. I was counting. Yeah. I know numbers. I know a lot of numbers. You should do. Here, you're one of the most important nerds in Bitcoin. My argument is that I'm not actually that important. Really? The thing that I always push back on is the idea that I have some kind of power. Like, I have some ability to influence Bitcoin. Wow. We've gotten started already, haven't we? Yeah. We went royal for the decade. OK. You don't have the individual power because of the checks and balances. Well, because there's nothing that I can't do-- there's nothing I can do that isn't fully public. That everybody can see. And there's nothing I can do other than create code that may or may not be run by somebody after some amount of time, after which we make a release. Anyway, we'll get into this. So let's explain to people listening what you do. OK. Or what you are. OK. Should I just intro? Have we started? Yes. We started five minutes ago. OK. OK. So hi, I'm Gloria. I work on Bitcoin Core. I've been doing that for a bit more than four years. And I've been what's called a maintainer for almost two now. And that just means nothing other than I'm able to push code to the repository in which Bitcoin Core is hosted. The live repository? Yes. Yes. We have a GitHub where we have a repository of all the source code in Bitcoin Core. And it's developed much like many other open source projects. And typically open source projects have a small number of people who are able to have right access so they can push code to it. And we have, in addition to the GitHub permissions, we have a script that checks that there is a PGP signature on all the commits that are pushed, all the diff that is pushed. And so I remember when I said this to you, you're like, oh, how do I find out? There is a public file called Trusted Keys. And it lists PGP keys of the five people who's signatures are accepted for these commits that are pushed to the repository. You wanted the five? Yes. However, another thing that I say is-- we have all these dependencies. So people-- they often focus on the Bitcoin Core repository, but they don't talk about the LibSecP maintainers, so the people who can push code to the cryptography library, which is a very, very important part of how signatures are created and verified within Bitcoin validation. But I think all this is moot because my argument is, yes, I recognize that there is an amount of, I guess, privileges with being able to push code, of course. But there is nothing we can do that isn't fully publicly verifiable. And there are so many steps between us pushing code and it being eventually run on the network by a node operator and maybe becoming a widely used thing on the network. So that's my argument. Have you-- you know the new Star Wars where the Council of Gedi's? Have you ever seen that? No. We were so around. That's what I'm going to show you a photo address. I think of you in the maintainers as like the Council of Gedi's sat there rauding over our Bitcoin network. OK, so I think we understand the code very well. And we are maybe-- we've spent a lot of time thinking about the security issues. And maybe we know things about what bugs have been found and how they've been patched. But all of this is public. OK. But can you push something live on your own or do all five of you have to agree? So we don't do it as a committee style. So yes, I can push without asking the other ones for permission. However, we can play out the scenario in which I've pushed something that everybody disagrees with. What would happen is it would be reverted pretty much immediately. And I mean, depending on how crazy it was, they can also remove my key. And this would all happen usually a very long time before the software is actually released and put out in the public for people to download. Of course, it's there and if someone wants to download it, they can. But what has happened in the past is we've had situations where a maintainer has done something very crazy. And they were this Gavin a long time ago, right? Yes, of course. And so people are always worried about like, oh, what happens if a maintainer unilaterally merges like a consensus change or something? That doesn't mean that the software has gone live on the network immediately. There are so many steps between code being pushed, code being released, code being downloaded by individual network, then becoming active. And yeah, so to answer your question, yes, I can. But like you said, checks and balances or many reasons why that doesn't mean that I have any kind of lateral power or anything. So if you were being sneaky, and the rest of the council of Jedi is we're all asleep and you push something crazy live, there's plenty of other people out there who'll be checking the code and verifying it. And then typically this would just be, this would become some kind of drama on social media. Gora's gone crazy, she's done this crazy shit. Yeah. And then people wouldn't download it that I would done that later. Yeah. And this has happened in the past, right? So like I'm not just like theorizing like this fantasy world. Like, you know, we have this very robust open source kind of community that verifies everything. So that's that's my point. Did you study computer science? I did. Yeah. I went to school for computer science in Berkeley. And it was great. I loved it there. And I think it was a great foundation. And that's where I found Bitcoin. So I don't know. What are you talking about this when we were in-- Malawi. Yeah, you told me about a conversation with your parents. Oh, yeah. Yeah, I think-- so I've been doing this. It was this. This was in like 2020 or so, where I think kind of the grant programs were kind of new, brink didn't exist yet. So I was the first grantee at Brink, which is a nonprofit that collects donations from the Bitcoin community and gives them to Bitcoin core developers. That was founded basically that year. And I think you interviewed John for that. But basically, when I first got started, it was kind of more status quo, what tends to happen with open source. So a lot of the internet and a lot of the things that we use on a day to day basis are built on open source software, which someone wrote for free and then put it on the internet under some open source license. They're like, yeah, you're free to use it, whatever. And often there's huge things built on open source software that the person who wrote the code is not paid for. And they may or may not still be maintaining it. A lot of times, they are still maintaining it. They're doing all this work to support the features that users have asked for, to push in security fixes, to update for their dependencies, with operating system changes or compiler changes, or library updates. You also have to keep up with those updates as a downstream project. And oftentimes, that just nobody pays for, because I guess our culture is not really about it. We usually-- I guess this is a social commentary thing. We usually wait for an intermediary to step in and exploit the producer and extract rent from the consumer. And sorry to just say that. But typically, the donation model hasn't been very sustainable in the past. But that's the only way to do it with Bitcoin Core, like Bitcoin open source protocol stuff. You could have gone to Google, got a half million dollar salary, share of shoes, had a brand new Tesla. Yeah, so around the same time I found Bitcoin, I was applying to internships. So yeah, I ended up doing an internship with Google, and I was going to do one with Facebook. But I reneged on that, and I thought I was so cool. But yeah, I had a fantastic time at Google to be clear. I learned a lot. I learned about cloud microservices, architecture, Kubernetes, Terraform, whatever. And it was a great time. But Bitcoin was this perfect balance between something that was trying to solve a problem in the world that I cared about, and also very, very technologically interesting. So I think within the first few weeks that I was looking at, like Bitcoin Core, I don't know, it was like, oh, there's this, we were thinking about thread safety because there's a multi-threaded thing. And I was like, oh, I learned about that in class. Or I think around that time, Peter Willett had written this mini-schedule library, which is this fancy math. And I was like, oh, my abstract algebra class textbook comes in handy. It's like the first time I opened it since I took the class. And there's really cool cryptography, distributed systems, all these things. And Peter Will is a great example, and a lot of other people that I work with who have been coding for as long as I've been alive, or these amazing computer scientists and engineers, at least the highest level of this craft that I've seen, working on this cool open source, censorship-resistant money thing that is solving a real problem for the world. I personally think that it is a super underrated project for software engineers that more people should consider it something more attractive to work on than Google. I mean, that was a personal decision of mine. And my parents were like, why would you do this? What do you mean you're going to work on this? You're getting a grant from human rights foundation? What does that have to do with? A registration cost is much. Yeah. But I'm-- that's another angle to it is I'm so privileged that I got this amazing computer science education. I have parents that were supportive of this decision. And now I get to work on this really cool piece of software. And I feel really, really lucky to be able to do that. Did they understand it now? I've done the flip chart. Sometimes when I go home and I see the flip charts that I was in the garage, it was like-- and try to Bitcoin. Yeah, they get it a bit more now. My mom who trades their retirement account is buying Bitcoin EGT. Cool stuff. I mean, it's a stuff. But mom, you know how did natural asset-- you could be rog'd. Yeah. I mean, so I have some opinions about this where I think-- yeah, I think like ideologically-- why why? We're getting into this. Ideology as self-custody is-- like that's the point, right? I think the average person, though, is probably less good at self-custody. So then-- And you met my dad. My dad's got so much interest in Bitcoin because of me. But all he does is check the price every day. And he's like, "B is up. B is down." If he tried to buy in self-custody, Bitcoin he'd lose that. Yeah. No chance. Yeah. So I'm really-- I'm really hesitant to make recommendations to people that require quite a bit of technological literacy and paranoia. You know? So this is not to say that I'm endorsing-- using these exchanges that may or may not be reliable. But I'd be fair. I'm not-- Yeah, I'm not-- I'm not trying to advise people to do things that are risky, especially my mom. How unique is Bitcoin in terms of computer engineering? Oh, yeah. I mean, so I was just explaining this the other day to a lot of software engineers, I guess, outwarded differently. But there's this crazy security model. So Bitcoin is kind of designed to work in the presence of adversaries, right? Like Twitter has their own lingo to describe this. Nation, you know, it's hard. And it's supposed to be able to continue to produce blocks, continue to process payments, et cetera, even if people are attacking it. And the software that we write is supposed to be-- we're trying to go for decentralization, right? That's like a ideological-- that's how the network brings the value that it has is that it's a decentralized network that is run by lots of different entities and organizations, right? But what that looks like in practice from a code writing standpoint means that I write code that is hopefully usable by anybody, right? So we support so many platforms, Windows, Mac, Linux, whatever. We, in terms of computational complexity, we don't want to only write code that could be run on AWS servers or huge B-Fee thing. It should be runnable as a background task on your laptop. A lot of people run their full nodes that way. It should work on a Raspberry Pi. I think that's a very good benchmark where you can run a full node that relays transactions, can do Fee estimation, can do all these things for you on this tiny little Raspberry Pi box, which a lot of people who are Bitcoin users do. But those two things are really difficult to balance. And so we're in this very narrow space of operation where anyone should be able to run this. But then when you turn on Bitcoin D on your laptop or whatever, what it's doing is it's connecting to RANDOS on the network. We don't know what their identity is by design. We want it to be an anonymous or pseudonymous network. And it tries to download data. It tries to find the main chain. It tries to download blocks or find out about new transactions or addresses of nodes to connect to, et cetera. And that's what that means is we have to plan for a random attacker connecting to nodes and sending you like garbage data. That like, for example, can crash your node or cause your node to stall or cause your nodes to run out of memory. And these are all attacks that we would consider like one of the highest severity. And I bring this up because basically people always ask me, like, what is there still to do? Or like, what do you work on? Like isn't the code finished? Just also follow. Yeah, yeah. And I try to give this message of like, there's a lot of things that can go wrong. Right? People are like, but 51% attacks are not economically viable. And it's impossible to get a private key from a public key. Like, Gloria, you didn't watch this Andrea Centinopolis video where he explained why Bitcoin is secure. I was like, yes, I agree. I agree. Like, I'm talking about like, there are a lot of, there's like a million ways that, like we all envision like this future for Bitcoin where we want it to be used by like millions of people and all these things. There are a lot of things that can undermine that, including, for example, the networking attacks that I was talking about. So if somebody is able to crash nodes or like, for a minor, for example, is able to crash the other miners and they get head start on like the next few blocks or let's say we would care a lot about block censorship attacks. So like, you produce a block. If somebody can prevent everybody else from hearing about that block or downloading up that block from you, that is a really serious problem. Or if you've heard of eclipse attacks where, you know, again, like the whole point is we have this peer-to-peer structure where everyone can talk to whoever and like, hopefully find a good set of peers that is able to tell them about the main chain. If that is compromised and like, somebody is able to eclipse you as in like, be everyone that you're connected to. And you don't hear about the main chain or you don't hear about the competing miners like blocks. These are all really like, I mean, they're not the same thing as, well, I mean, if a miner is able to do this, that's like, you don't need 51% hash rate in order to attack these people, right? Like, you just block them from hearing about all the other hash rates. - Are there these theoretical attacks? - These are theoretical attacks, just to be clear. - So, and so if it's a theoretical attack, do you try and attempt to do the attack so you know how to defend against it? - Well, in practice, what we're often doing is we're like, analyzing the code and we're writing tests. We're trying to isolate the block download logic to just throw random stuff, like just like test as much as possible, like all the scenarios that we can possibly happen. And we have lots of monitoring nodes where we're seeing, like, if we observe, oh wow, there is actually someone trying to send us mutated blocks or there is someone trying to stall block download by like, being the first guy and then like sending us garbage. And then like, when we ask them for the correct information, they just like, you know, stall. Like, there are like theoretical attacks and then there's also like, we'll observe people doing weird stuff and that will sometimes lead us to go and tweak those parameters or be like, oh yeah, maybe we should, you know, we should redesign this a little bit so that we're making a better trade off. So for like, sorry if I'm rambling, by the way. - Good. - So with, I think a lot about transaction relay, there was one a couple of years ago, that was transactions stalling, where let's say, you know, there's a transaction being broadcast. Most people know about it. I don't want to download that transaction multiple times. I only need to download it once, right? So we have these kind of bandwidth saving things. Again, bandwidth saving is important because not everybody has extremely high Wi-Fi speeds where we want it to be accessible to run a node. So we're trying to save bandwidth by only downloading once. So we're only gonna ask one period of time to send us that transaction. However, if we try the first person, the first peer, I mean, and they don't send it to us, we should try again, right? Or we should, like, and we shouldn't only try two times, for example, because we don't want there to be a, a censorship vector where, you know, appears like, okay, I'll be the first three people that you ask for this transaction from. And then all of a sudden, you're not going to hear about this transaction. That would be a transaction relay censorship problem. And so, yeah, there was basically, there was kind of a TX request kind of reconsideration, kind of, there was like, modularization plus fixing up some of those things to make it more robust and make it really easy to reason about and then added a bunch of tests to kind of check our understanding of like, oh, all these, in all these scenarios, yes, we would end up downloading that transaction. And then we have what are, we've been using fuzzing a lot. I don't know if you've heard of fuzzing. Should I ram will more? - Ram will more tell me about fuzzing. - So, okay. So typically the way that a software engineer might write tests is, for example, you'll write the test scenario that I just described, right? Where you're like, okay, let's spin up a note, like a fake node, and then we'll spin up a few extra fake nodes to connect to it and then we'll simulate the attack and we'll assert that like the correct behavior is happening. And so you have to provide exactly what the test is. Fuzzing automatically generates tests. So what you'll do is you'll write kind of more of a skeleton and like, you know, it'll check invariance like, you know, after each state trend, like after each period of time, you check that all the invariance are still true, whatever those may be. And then a fuzzing engine will kind of intelligently just like, it'll start by sending random stuff, right? And then it'll figure out based on, for example, coverage of the code, like it'll look at what lines of code you've hit. And if they're like, oh, these inputs like hit like a further, a line of code deeper into the module, okay, like we're gonna create more inputs that look like that. And so it basically, it's similar to like creating random inputs, but it is somewhat intelligent and it'll like, over time, just like find the paths that you maybe wouldn't have thought of if you were just manually writing the test. So we use this all the time. Now like we're like fuz everything. (laughs) Fuz everything. And like the amount of fuz coverage over the source code has increased like dramatically over the past few years. And it's found like pretty severe bugs. It's helped design certain things as well. When you're like trying to test the computational complexity and you're like, okay, like let's like fuzz it and see kind of what the average runtime of it is. Or we'll fuzz it and we'll see if the fuzz can come up with an input that causes it to spin like for a really, really long time and we're like, okay, like instead of just theoretically analyzing what's the worst case runtime of this algorithm? Like maybe have we missed something or like, what does that actually look like? Or like can we add an extra piece of logic in there that catches these really worst case behaviors? Or it helps design things, it helps test things. It's fuzzing, it's great. (laughs) - I think most people, especially like me, when we think about Bitcoin development, we tend to think it's just scaling. How you gonna scale? What's the new, what are the new features come in? I don't think many of us tend to think about how much work's done planning for adversarial attacks or efficiency. And how is that kind of work split up amongst core developers? Is it someone specifically is working on attacks, someone's on efficiencies? Do you tend to have like specialists in each area? - So there's no kind of coordination or advantage? - Of course, yeah. - Of course, but there are people who specialize. So I'm just going to show my colleague, Nicholas, who works with me at Brink. He's the fuzzing guy and he's kind of become our security engineer as well because naturally, he becomes the guy that finds all the bugs. (laughs) And he's great. My other colleague, Michael Ford, who I think you've met, or fanquake, he specialized in build system stuff and that also naturally leads him to do a lot of the release process stuff. And we can talk about the release process as well 'cause I find it very interesting. And then people will call me like the mempool person. I'm not the only person that works in mempool, definitely. But I spent a lot of time in this area. And typically if somebody opens a mempool PR and you ask me to review it, I will. Eva Chao, she works on wallet. But I mean, everyone does a bit of everything, I think. And it would be very boring to spend all of your time doing one thing. But I think there are, we've naturally been like, okay, this person is really good at this. And has the most expertise. And I think part of our job is to just know how stuff works. I think it's really important because everything is so complex and it's so security oriented. - But it's so interesting that without coordination, everything just kind of gets done. - You know what I'm saying is Bitcoin works. There are people constantly upgrading, fixing things, patching things, working on new ideas. The fact that it happens because in a decentralized, uncoordinated way, because if you think of, yes, I'm working on software business. But I'm pretty sure Google wouldn't have it. You just pick what you want to work on. And when you're ready, you just upload it. And we'll check in. They would be entirely coordinated. - Yeah, yeah, I think I would just say that a lot of the people that work on Bitcoin core are so altruistic and want to be useful. I agree, there is a little bit of like, oh, you do whatever you want. And therefore, nobody wants to review back, like nobody wants to do the boring stuff. - Post the boring stuff. - Like release process. - So I guess one, I said back port, so I might as well get into it. So as part of maintenance, right, we'll release something and then that has like two years before we stop maintaining it. So every, sorry, every six months more or less we'll release a new major version of the software. And that'll have new features like V2 transport or you know, package relay or whatever. And then six months later, we'll release a new one, right? But the one that we released before we're still pushing security updates to. So we'll push out minor releases. And so basically anything that like, usually a bug fix will get merged into master or development branch and then we'll back port that to the branch that contains a release that's currently out. And then we'll cut another minor release. Anyway, this thing where you're just reviewing the same shit, but on like a different branch is incredibly boring and most people don't do it. And the process of picking that, the process of choosing which bug fixes to back port as well is like something that takes a lot of work because you basically have to have a bird's eye view of every single thing that's happening like in, that's being merged, like, like these hundreds of PRs you have to decide, oh yeah, that's something that would affect like a previous release. And then all you do is like you cherry pick it onto the older branch and like nobody wants to do this. And the end effect is like, yeah, that thing that we release before it's still working. - So is this part of version? - Yes, yeah. - And so if you're not updating your node software, you eventually have things that aren't supported. - Yes, yeah. - Because what is that crazy remaining dude who refused to go anything beyond the original version one of Bitcoin? - So I think I heard something like, and I think there's people who run like 0.16 or whatever and like people who say like, well, let's say theoretically, right? Like it's a soft fork. So I don't need to update to the new rules and I should still be able to use, but you know, that's a very, that's an ideologically a very important thing to us. And unfortunately, unfortunately, the consensus engine is intertwined with all the other pieces of Bitcoin core, like what it does. And so you aren't really able to be like, I want the modern version with the modern wallet UI and all those things, but I don't want to upgrade my consensus engine. I think it is not good that these are kind of intertwined and we have a project that we've been working on for years and years to kind of modularize the what we call the kernel or the consensus engine. So that like, for example, you could get the new GUI features, or the new wallet features, or the new kind of more front facing, like not consensus, you know, not protocol changes without, you know, changing kernel. So my point is don't run un-maintained software. It contains bugs that we do know about and have, may or may not have been disclosed already. So, you know, there are like, it's public knowledge that they're like someone can send you X and then you might run out of memory or someone might crash your note or something. I very much do not recommend running un-maintained software. (laughs) And so does the entirety of Bitcoin work from in core or if you were a Bitcoin user, you download core? Is it reference in other software or things that exist outside of core? - Yeah, so we, this came up a lot with the recent like, XC, you tools like Counter-Strophic Bug. So yeah, we do have a few dependencies and we have, we're like very, very, very conservative about it and one of the things, again, like, that Michael does as part of build system. He's also very about like reducing the amount of dependencies and so like what, for example, Michael has found over the time is like, "Oh, we have a dependency and nobody's maintaining it." Or like, they're just like, yeah, they're not maintaining it, basically, or like it's not reviewed to the same standard that we would expect Bitcoin Core code to be reviewed to. And all that code is like, you should treat it as the equivalent of your code. - Where would that dependency sit? - It would be another open source library on your hub. - Would that be a centralizing force? - So like, when I say it's an open, like centralizing force as if they deleted it or something. So we just have a copy of it, right? - Yeah. - And we would just use our own. - And we have got that. - Would you want everything just in core? So there's no external dependencies, or is that not possible? - Sorry, I just, I get it. So dependencies wise, first of all, I was talking about like other code that gets pulled in when you build Bitcoin. - No, I'm out of, yeah. - But of course, when it's operating. - It like operating systems, like you have, you need an operating system. - No, I mean, once you've downloaded Core, does it, to what? Does it ever have to refer live to other systems or does it work completely on its own? - No, I did, like you load like a C library when you run it. But I guess it's hard to, what are we talking about here? Like, is the, what do you mean by refer to other systems? - Like, are there other software protocols that it relies on or is everything within core? - Well, it needs to, it needs internet. - Yeah. - Some like that. - I'm not a ball like, oh, sorry. - I'm probably like, it's made of myself well. I'm on about, do you have to maintain like another protocol that's held on a server, AWS somewhere that has to refer to for things? - Oh, I'd say there is an example of that in the DNS seeds. So when you start up your node, how do you know who to connect to? How do you know addresses? We can't put that directly, well, we have a little bit of that directly in source code, but usually that changes day to day, right? So you will talk to some DNS seeders, or I wanna say between five, I think there's eight of them, five to 10 of them that are run by various people. And they'll be like, oh yeah, I've been scraping the Bitcoin network for addresses and here's a list of addresses that are very diverse. They represent various networks in the world or whatever. And then, you know, here's 50 of them or whatever. And you'll talk to eight of these and then, you know, you'll start connecting. So that is an example of a live thing that you're connecting to. But I would say there's very little of that compared to most things that you might think of. - All right, let's talk about Iron, who are our next generation of data and business powering the future Bitcoin mining and AI using 100% renewable energy. Love these guys. Now, Danny and I have been working with the founders, Dan and Wolf quite some time over a year now. We've been super impressed with their values, especially their commitment to local communities and sustainable computing power. And we've collaborated with them on everything. We've made films, we've done podcasts, they even sponsor my Fubble Team Rail Bedford and they're the least sponsor for our conference cheat code. Now, Iron is the responsible way to power Bitcoin mining, AI and beyond. And if you wanna find out more about them, please do head over to Iron, which is iren.com. Let's talk about Bikicino, Pine is in Bitcoin gaming. Now, they were established in 2013. And Bikicino at that point became the beacon of innovation in gaming and have been ever since. They have trusted by tens of thousands worldwide. And Bikicino offers cutting edge security. And of course, they support the best money in the world. They support Bitcoin. Now, with Bikicino, you get lightning, fast withdrawals, VIP experience and they have over 4,000 games. But they also believe in a fair gaming environment, offering no transaction fees. They promote responsible gambling and they're in power players with their live RTP feature to identify bullish and bearish games. Right, if you wanna find out more on Join Bikicino, please head over to Bikicino.io where top-notch gaming meets unequal service. That is Bikicino.io, which is BIT, C-A-S-I-N-O, dot IO. And also please remember to gamble responsibly. When you spin up your node for your first time and it's trying to find other nodes to talk to, is there a limit? It's like you only need to be connected to five or six and once you've, is that enough to create the network effect or can it connect to all of them? How does that kind of stuff work? I don't know any of this. (laughs) - So there's a couple of design goals here. One is like bandwidth, right? You can't connect to every single person. That just, first of all, you'll probably, like your computer probably can't handle it. And also this, yeah, it's just not feasible. - Because it means it's in a constant communication. - Well, there's like tens of thousands, right? - Yeah. - I'm pretty sure you just, like, you have a limited number of slots essentially that you could, connections, that your computer could be making. Or sorry, I'm trying to, I'm trying to, like, make it easy to understand. Like, it's just not, like, it's not gonna be feasible to connect to, like, let's say, 30,000, like, nodes, right? But the other design goal is like, you definitely really, really want to find, first of all, honest peers, as in peers that are gonna tell you about the main chain as soon as they know about it, so that you can find the most proof of work chain, right? So, like, we understand proof of work consensus, right? Like, you find the chain that has the most proof of work on it. And that's your idea of what the chain is, but you have to hear about it. So yeah, what, what, what nodes will typically try to do is maintain, like, eight to 10, yeah, let's just say, eight to 10, like, outbound peers that you connected to and are hopefully diverse and hopefully very responsive and telling you about main chain. So we'll collect statistics about everyone that we're connected to. We like, ones the last time they sent me a block, ones the last time they sent me a transaction, that was valid, ones like, how fast do they pong when I send them a ping? Like, all of these metrics we use to assess like how good our peers are. And then when, you know, when we're managing all of the addresses of the nodes that we know about, we'll also try to go for diversity, right? So it's very easy, for example, it's for someone to spin up a bunch of IP addresses from like one, ISP, whatever, but it's much harder to do that across, like a lot of different ISPs. So that's why, you know, like, we have all these ways of managing, managing ways for us to make sure that we are connected to a healthy set of peers. And so yeah, we'll like regularly monitor, like we'll regularly try, like, okay, let's just like pick a random one from our address book and like see if that peer is gonna respond to us. And like, if we have like one of our peers has not sent us anything for, you know, days, hopefully not at that point. Like, you know, is a shitty peer, like we'll evict them and we'll try a new one. And so yeah, there's so much that goes into the software that is not just, you know, what's the most proof of work chain or like, is the signature valid. And it's very complex and it's very interesting. It's very, very interesting, I think. Like, I didn't know about this when I was taking a networking class in college and uni. And yeah, it's very, it's cool. - And what do they share with each other? Is the primary information being shared to make the network work transactions and blocks? - Well, I would say it's like primarily transactions blocks and addresses of nodes. - Okay. - Well, there's, there. - 'Cause I think there's not a people, most people probably have no idea how Bitcoin works. Yeah, 'cause a lot of people don't even download a node. It's very small percentage of people will pray to know. - Everybody run a node. You'll learn so much about Bitcoin and it's so fun and it's so easy. It is so, so easy to run a node. - We'll make a brand like you. - Yeah, you don't need like, you don't even need like 600 gigabytes. Everybody like, this is a myth. 'Cause like a very common myth that people think you need 600 gigabytes to store the blockchain. You only need to store the jigsaw. Like you don't need that much. You can run it on your laptop. - But the primary thing is addresses transactions and blocks. - Yeah. - And so when a transaction is created, that is relayed across the whole network. - Yes. - It's, can there ever be a time where, when my node just doesn't pick up that transaction, or will it eventually get that transaction? - So we're talking about transactions that haven't been mined in a block yet, correct? Yeah, so yeah, this is like what I love talking about the most. - Emple. - Yeah. So the question was, are you guaranteed to hear about transaction? Absolutely not. And some things that I basically, the projects that I work on, a lot of them kind of censor around transaction censorship on various different levels. So I kind of described a Pew-Depuere example, but there's also a memple examples. And there's also like, don't design your things in a way that it can get sniped or whatever. And sorry, it can happen in memples as well. But the goal is like, we're trying to build a censorship resistant payment network where anyone can pay each other and nobody can block that. I think this is like top three best things about Bitcoin and things that we should strive for in Bitcoin. And so yeah, you aren't guaranteed. So should I talk about like, memple stuff at all? - Yeah, and so look, if I don't pick it up, it's not so important. But it's important obviously every minor who's constructing blocks sees every transaction, but are there chances that a minor minor see a transaction? It's the, or should the member be the same? Should everybody have the same member? - Thank you for asking that question. This has been a topic that a lot of people talk about. Obviously Bitcoin could function if, okay, so there was a lot that was said to kind of teach everyone that not everybody might have the same memple. There's no such thing as the memple, right? There's each node on the network has their own memple and they may or may not be the same. I think when things are working really well, hopefully everyone like does, and I'll explain why. So like we have this decentralized transaction really network, each node has a memple. - Sure, yeah, should we explain what the memple is? - Okay, sure. - Yeah, 'cause we've got new listens coming in, just like what the fuck you want to do. They've probably actually, if they've got this far well done, they're working on what are you two talking about? What's Gloria talking about? - Okay, yeah, sorry. - Okay, so let's start from the beginning. We want censorship resistant payments. The way that we achieve that is through the decentralized structure of the network, right? We don't just have, you know, the miner has like a website that you submit payments to, that would not be sense, or the government has a website or a bank, right? That's, that's obviously that doesn't, hopefully everybody understands that, that's not how that works. So what we have is decentralized network instead, you connect to one of the tens of thousands or hundreds of thousands of nodes, you send your peers, your transaction, and they gossip it, and eventually it gets to everybody. That's how it's supposed to work. How we implement that in practice is each node, first of all, is down to hear about transactions and validate them, and we'll put them into their memory pool or memple, and that's just a cache of unconfirmed transaction, it's just a cache. - Can you spam that cache, and therefore, there you go. Good question. And okay, yeah, so you as a node operator, why do you do this? One is so that you can cache everything for when blocks come. Like one of the reasons is so that block really works. So when you receive a block, what you, what might happen if you didn't see any transaction before, is you have this huge networks, like bandwidth spike, where you're downloading the full block, and then you're like spinning, spinning, you're like loading UTXOs from disk, and you're like doing the computationally heavy thing of verifying all the signatures, etc. It's very computationally expensive, and it might take you a while to do this. So that's one possible reality, and the other possible reality is like, yep, I already downloaded all these transactions, already verified them, I have a cache, where I like cached all the signatures that I checked, I already loaded all the UTXOs into memory, and like I'm done, and I store it onto the next block, right? And that is a much, much healthier, first of all, situation for you as the node operator, but also for the network, because every single hop is so much faster, so sorry. So block latency goes from like this to this, because each hop, it like multiplies at each hop, right? And so the healthiest network, the ones with the least reorgs, where like reorgs are bad, because so for example, you want block latency to be very, very fast, because if two people find the next block at around the same time, hopefully everybody hears about one like quickly. Otherwise, you might end up with half the network knows about this block, and the other half knows about this block, and then at some point you have to resolve that reorg. The fewer of those you have, the better, right? - How often do they happen? - I think like once a week or something? - So it's still quite regular. I don't know if that, yeah, every thousand blocks or something, yeah, but it used to be more frequent, and every time that happens, like every time there's a reorg, like it's messy, it means your confirmed payment, may or may not still be confirmed, like it's a UI issue, it's like a usability issue, yeah, right? So it's a security issue, it can be at least, and so we really want to minimize that as much as possible. So anyway, we were talking about why memples and transactions really are useful for block relay, and the other use is obviously so that we can have a nice censorship resistant payment system. And when we are participating in transaction relay, this is, we don't just like validate whether the transaction is consensus valid, chukin and mempul and continue. So your question, which you asked, which was like, can you spam the mempul? Yeah, there are consensus valid transactions that can take you several minutes to validate, right? And they may or may not be a valid transaction, right? Like there's this really great post, I think, by Rusty Russell, which is from a long time ago, a non-segwit transaction with like a bunch of inputs due to like quadratic saccaushing, it took like several minutes to validate, but you can imagine that being like a fake transaction, right? That came in a block, which had proof of work on it, and proof of work is this like really easy way to avoid spam, because it's so much harder to produce a proof of work valid block than it is to like download it and validate it. Whereas transactions, you don't have a proof of work requirement. So it's much more like people that just send you this transaction, maybe you spend minutes validating it, and then it turns out to be invalid, completely useless. It's not even gonna be confirmed, right? - Yes, thanks. - Thanks, right? And so we have rules where we're like, okay, we don't take really large transactions. Like that's a very simple rule. So consensus rule, you could have like a 400, 400,000 like way unit like transaction, but we make that 100,000 in transaction relay. Another really good example is we use, like we want our memple, it's a cache, right? We want it to be useful. And so we use a lot of incentive compatibility metrics to assess whether or not this transaction is useful. So the best example is if you get two transactions that conflict with each other, they spend the same UTXO, they're double spends, you should probably pick the one that's higher fee rate, because that is more incentive compatible for a minor to mine. Even if you're not a minor, like you're expecting to use this for when you're validating blocks, you're like, okay, this is more likely to be mined and therefore I'm gonna take it. So that's another example of what we do in transaction validation. And that's what leads to being able to RBF to replace by fee, right, to fee bump that way. Sorry, I'm getting to your question about should everybody have the same memple? Like hopefully-- - You have an ideal world. - Yeah, and an ideal world, things work best if everybody has the same memple. Of course, like all these rules that I described, they're not consensus, so you can have whatever you want, right? Let's say you're like, my mem, like, I mean, the example is like, I hate inscriptions. Or like, my memple, like doesn't allow spending on confirmed UTXOs, or my mem, like you can do whatever you want. And that, yes, like, that's allowed. But is that, but like, people are like, therefore everybody should have different memples. It's like, well, no. That's not where we were going. But I think it was like kind of this over correction of like people used to think there was the memple that you would submit transactions to. And then now everybody is like, oh, actually everybody has their own memple. All the memples should be different. - I used to think that. Did. I used to think there was just like one memple. That's why I asked the question, are there outside dependencies? 'Cause I imagine there was this memple of transactions. I mean, realized the transactions itself were getting relayed and stored. So when we go to the memple website, is that just their own? - Yeah, yeah, yeah. That's a memple space and memple are different. - Yeah. - There's like memple, the memory pool that each node has. - Yeah, and then memple space happens. - And so that's just theoretical. That's just what it should be. - I think not necessarily. - Where do they take theirs from? - So they, why don't, so I mean, they run their own Bitcoin nodes. - Yeah, that's what my assumption is. But therefore, there could theoretically be different from our. - Yes, yes, absolutely. So I think they run a few different nodes, first of all. And so they have like a huge node that has like all the transactions. And then they have like the default node, right, which is 300 megabytes. And so like when fee rates are really, there's like a ton of transactions. Like the huge memple will have all of them. But for example, your 300 megabyte memple is going to start purging the lower fee rate stuff. That is less likely to get mine. We're using incentive compatibility to assess what they're going to. - So when they get purged, where do they go to? - You just throw them away. They're gone. - From my node. - For your node, we'll just throw them away. - But a miner would never throw any away, 'cause at some point they might mine them. - I would imagine that they do something very similar to what memple space does, which is they have a huge node that just keeps track of all of them. But they have like a default node. Because the larger your memple, the more computationally expensive everything gets. Like building a new block template, for example. You want to do that on a smaller memple. - So the huge one is just for storing all the stuff later, it's like, okay, if we go through a very intensive period where there's lots of low value transactions, they park them for later and then fee rate dropped, then they'll bring those in. - Yeah, exactly. - So much today. - Yeah, yeah, exactly. And so I think part of memple space has this cool audit feature where they build their own block template and they compare it to what got mined and you can see, like, oh, are these, you know, it's not always censorship. There's many reasons why the transactions might be different. But you can kind of see what it would be or what the difference was. But of course, your node might be different from memple spaces node and that might be different from the minor node or whatever. And so it's like very difficult to, it's very difficult to prescribe a reason why transaction might be different. - Could I have a poster transaction where the fees too low and it never get mined and it just sits there and lost forever? - Well, if everybody's bidding higher than you for block space, then sorry you got, you got. - Does that transaction eventually just get canceled? Can I have to somehow cancel it myself? Do I bring it back? Like how does that work? - So I don't think you can cancel it. I think once you've signed that transaction, so for example, minor could just be logging every single transaction that they see. And then like six months later, you thought it was canceled and maybe you were like paying your friend or a merchant or something and you're like, okay, I'll just send you a new transaction that one's canceled. Like you might get mined. (laughing) - Sorry. - How do you bring it back? Is there any way you can bring it back? - No, no, sorry. - Sure. - So there isn't. Well, you could double spend it, right? - Okay. - It's still not guaranteed that someone might not mind it. Right, it's a consensus valid transaction. You've already broadcast it. - Can I increase the fee? - Yeah, yeah. Like, so yeah, so you could like, like I described before, you could create an RBIF where you double spend it in a higher fee rate transaction and theoretically a miner should mind the higher fee rate one. But again, they could decide if they wanted to, if they're being weird, like they didn't hear about, like, you know, for some reason they didn't hear about the fee bump or by the time you fee bumped it, they had already started working on a block without transaction in it. For example, these are all potential reasons why, like your RBIF may or may not get in, may or may not happen. There's a lot of reasons why the replaced by fee transaction may or may not work. One of those, like some of those reasons, 'cause I've spent a lot of time looking at kind of the limitations of RBIF is just like our policy rules are not very smart. So we make a trade off again between, like, being resistant to denial of service, like trying to be computationally not complex, as well as incentive compatibility, right? So sometimes we make a trade off where we take a shortcut or we have an imperfect heuristic for assessing incentive compatibility because the actual thing would be too computationally complex to do. And so we might, let's look at two transactions and we'll be like, oh, this one's better to mine, but actually this one is. And so we might reject a replacement, that's actually better, or we might accept a replacement, that's not better. And like, this is, I consider a bug. It's a very complicated bug because it's the result of kind of a lot of engineering and these are very like kind of edgy edge cases. But yeah, there are, I've spent a lot of time essentially working on these kinds of replaced by fee policy limitations and we have a few proposals, I have some proposals as well as other people have, don't speak on behalf of anyone, other of myself. There are a lot of really exciting projects that people are working on to try to fix these things in Mimple. - So how has inscriptions changed the Mimple game because clearly it has? - So I remember we had like a three round trip debate where I think it was around, like people were really upset that the fees were so high because of all the, I think, BRC 20 stuff. - Yes. - And they were like, can you fix this? And I was like, you're kind of like somebody who's driving down the highway and there's traffic and you're like road workers. Why did you allow all these people? Like it's like, yeah, other people are allowed to send Bitcoin transactions and the way that they're chosen for confirmation is based on fee rate because miners are economically incentivized to include those transactions. - And they can send us that. - Yeah, yeah, I mean, they use the scarce block space to a demand that's very high and it's using economic, right? Like the price goes up for a unit of block space, which is the resource that you're trying to consume. - But this stuff is political. - Yeah, it's, and do you feel like as a developer or a maintainer, either or do you feel like you have a duty to not be political, not have an opinion as long as your job is just to make sure the software works? - Yeah, so the issue that I had when we were talking about this was that people are like, can you stop the spam? And spam has a very specific, like we've just been talking about the definition of spam when we're talking about mempool code and transaction relay code, where it's using a resource, for example, your computer's computation or memory that it shouldn't be. And we have all kinds of ways of preventing that. And so I have a definition of spam that I use when I'm thinking about this kind of code and people are asking me to apply that definition based on use case. And I don't think it's the protocol developer, the transaction relay codes place to decide what use case is legitimate or not. Like it, like, you know what I'm saying? - Can I put it in a node or even my level like ocean of that? You can, that's where you can make that decision because in the decentralized network, you get to decide yourself. - Yeah, like if you don't like half photos, you don't like wizards or whatever, that's like your choice, right? But I don't think this is not a legitimate transaction or this is a waste of blocks because NFTs are bad or whatever. I don't think that language has a play, well, I don't think that should be considered when you are talking about writing policy code. - Yeah, as a developer. - Yeah, as a developer, as a protocol maintainer. Like, it's been such a tricky subject to navigate. And honestly, I've gone back and forth on this. I've ultimately come to the point that my preference would be Bitcoin was just used for financial transactions. - Sure. - I've Bitcoin being money. And I know someone said, "Well, these still are." But I've also, I don't like the idea of censorship, but I had a very long conversation with Bitcoin Mechanic. Obviously he's very much involved in ocean. I agree with him. Like the thing I care about, the thing I'm here for is the improvement of money, especially with the kind of things we saw out in Malawi and Kenya and Ghana. - Yeah. - I have zero interest in quantum cats. I feel like some of this stuff's an attack on Bitcoin. But I've come to really appreciate that. It puts you in a difficult position because people want you to have a political view. Is that, do you feel that as a pressure? - Yes. (laughing) - Well, I don't know if people are asking me to have a view so much as they're demanding that we change the software. - Yeah. - Right. And I think to be kind of fair to this argument, we've identified a couple of reasons why you would have policy. But policy is in the validation rules and mempool that aren't consensus. And historically, there have been kind of things put in place to discourage things that are bad for network resources. So for example, we have standard output types and we have a dust limit. And that's to try to protect or try to discourage creating a lot of, and even the witness discount as well is kind of to try to discourage bloating of the UTXO set. - What is a witness discount? (laughing) - Oh no, we're getting into it. Okay, so let me just finish that idea first. So I talked about how you can run a fully validating Bitcoin and you don't need to store the entire blockchain. You just need to store the UTXO set, all of the UTXOs and that is enough for you to validate whether each transaction and each block is valid. Well, you also need the headers chain. - Yeah, yeah. - You don't need all, you can prune most of it. And so the size of UTXO set is kind of very important to scaling and to the accessibility of running a node and all those things. And so we're saying, oh, witness discount. So when we are looking at the size of a transaction, certain parts of the transaction are weighted differently from others. And so the witness data, which is like the signatures or the scripts that make this transaction valid, which can be discarded, like that is weighted less, that that's all the witness discount is. And so that means that if you make a large witness, that does not cost, that won't cost you as much in fees, for example, as if you like made a lot of outputs and outputs are what go into the UTXO set. And similarly, like we have a list of like standard output types. So that's pay to witness pub key hash or pay to tap root or pay to witness script hash or, you know, those like standard types, and you know, they're very small and they have a standard format. And say, okay, we don't have to get into the dust limit. But these are like various policies. - What is the dust limit? - Okay, what's the actual value? - Sure. Oh, it depends on the output type. So I just described the different types. So I don't know if I should explain what they are. But if you create an output that has like one Satoshi in it, well, you're not, like if you are to spend that, it's going to cost you more in fees to spend that UTXO than it's worth. You understand? - Unless you've got a special Satoshi. The first Satoshi I would call. - Oh sure, sure, sure. (laughing) - That's, that's what you're right. You can't identify individual Satoshi's. Well, that's what Ordinals is, right? Like you have an external, like-- - But they've just basically made up their own number and system, but these Satoshi's don't exist individually. Because a UTXO is essentially, like if I put a 20 pound note on the table, there aren't individual pennies in there. It's just a 20 pound note. You can't identify the individual pennies in the note. - Sure, sure. I guess we can kind of-- - No, you don't need to do that. - I think, yeah, like you can do anything to derive meaning that isn't kind of baked into the protocol. - But the ordinal theory is something that says an external protocol outside of Bitcoin. - Yeah, that has nothing to do. Like when people tell me that stop doing ordinals, we don't have ordinals. - Good fucking, sir. - Yeah. - So the dust limit, does that have to be kind of a move in beast as Bitcoin value changes? Or is it a relevant? - Because it's priced in Satoshi. - It's priced, it's determined based on Satoshi units. So if you assume that you, let's say, you're always gonna have to have at least one set per V by eight. The dust limit is actually three. But once that per V by any transaction or to spend it, then you can't be making, if you make a five-sat output, then it's uneconomical to create that output. Because it's worth less than what it would cost to use it. - All right, let's talk about ledger. My favorite hardware wallet in the world. The people I've been using since 2017. Now ledger is a world leader in Bitcoin security. And it's one of the best ways for you to own and secure your private keys. Now listen, if you are still holding your Bitcoin on an exchange with a custodian, what are you doing? I've been telling you for years to stop doing this. It is time to take your security more seriously. Remember, if it's not your keys, it ain't your Bitcoin. Now with ledger hardware, while it's paired with the ledger live app, you have the easiest way to start managing your own private keys and taking control of your Bitcoin. And with the price booming, you don't want to be leaving that on exchange. We've seen what happens with exchanges, right? Now you can send and sign Bitcoin transactions with full transparency in the ledger live app. And honestly, it can be easier. I've told you a million times, I'm still using the same wallet. I bought back in 2017. I've still got that same ledger and nano-s. Also, ledger has recently released their Bitcoin Orange Nannos and they got a very cool initiative going with it. They are giving five dollars from every purchase to the Bitcoin developer community. And the start-up would bring, which I'd love to see. So if you want to find out more, if you want to get yourself a hardware wallet, please head over to ledger. That is shop.ledger.com, which is hop.ledgr.com. All right, let's talk about Swan and their mission to help millions of people get into Bitcoin and they've built the fastest and easiest way to get that started. It takes just a matter of minutes to sign up and start buying Bitcoin with the Swan app. So introducing friends and family to Bitcoin has never been easier. And Swan now has zero fees on the first $10,000 of Bitcoin buys. So it is free to get started. Don't worry. If you are already a Swan client, your next $10,000 of buys are also free. If you love to recommend Bitcoin, and I know you do, Swan is an absolute no-brainer. You can take a friend from zero to Bitcoin in just one quick conversation. Just tell them to search for Swan Bitcoin in the App Store. It really takes no time and it's completely free for them to get started. Again, search for Swan Bitcoin, which is SWAN, B-I-T-C-O-I-N, to download the app. - Okay, let's talk about Carta. Let's talk about Cold Storage. Now listen, look, Bitcoin price has been booming this last year. And I know some of you will have seen your net worth in Bitcoin flying up. You may not have considered multi-six storage. You may not have considered Cold Storage, but you need to get onto this. I have been using Carta for about four years now. Absolutely love it. Feel a lot more comfortable. Know, my Bitcoin is locked up in a multi-six solution. And Carta is the very best, but I also want to tell you about something else. They have brought a product to the market that changes everything. Something I've needed, something I've been worried about for a long time, which is inheritance. I know some of you plan your inheritance with your Bitcoin by creating some kind of puzzle or sharing keys with other people, but Carta have nailed it. They have built this natively into their app so you can handle custody and you can handle inheritance directly in the app, ensuring there's no mistakes, ensuring that the people you love will inherit your Bitcoin, it's just something happened to you. All you have to do is choose a recipient and when you snuff it, when you're gone, the person you have been charged wait six months and they take control of your Bitcoin. Carta also provides you with the help in hand to make sure your Bitcoin stays safe during this transition. So if you want to find out more, if you've realized it is time to get yourself a good, cold storage solution, please do go and check out Carta at carta.io, which is casa.io. - So a bit like how in Canada, they don't make the penny anymore 'cause it costs more than a penny to make them penny. - Yeah, yeah, yeah, yeah. And so we started talking about, yeah. So we were talking about this because this has been like a very, very long standing rule as we had these like standardness checks in policy where you can't do that. Or like if I, I'm running my mem, I have my mem pool and I'm running my node and I receive a transaction that creates a dust output, I'm gonna go ahead and reject it even if it's consensus valid. And that was kind of there as, I guess the idea is to protect network resources to encourage people not to do things that are gonna hurt the scalability and whatnot. And people are like, why can't you do that for inscriptions? Because like policy can ban or like can prevent things. And so people are like, why don't we have a policy rule where if we see an inscription in a transaction, like the NFT thing, then we also ban that in policy. And this idea has been dressed up in like many different trench coats as different pull requests to the Bitcoin Core repository. Oh, do you know about this? And like they've become like flame wars on GitHub, which is not Twitter, it's a place where you discuss code. It's, you know, as maintain as maintainers, has there been something that's been debated or is it very obvious that you just don't can evolve in this censorship team? So we've talked about this because I think people take pull requests seriously, right? Like anyone can contribute. It's not like we're like, you know, like we'll take every pull requests seriously. I'm when I say we, I speak on behalf of myself and not anyone else of course. But yeah, like you know, you think about it. And actually I published a, a like really long document kind of summarizing one of the iterations of this kind of proposal because it had like hundreds of comments from various people being, you know, to various degrees of professionalism. Yeah, so I like tried very, very seriously to like index every single comment I could find on it, like summarize the arguments and weigh kind of the merits of the technical arguments against each other. So I, yes, I did very seriously like review that PR and I can send you the, the doc if you want. But like what we were talking, oh, so the idea was like, oh, why can't you do this for inscriptions, right? And like I think there's, there's two things. One is like you can do this on your node, right? But like when you're asking, like there's a difference between like I wanna do this on my node and I want Bitcoin Core to ship this as the default, right? And so there's two things that I really just wanna put out there. One is like Bitcoin Core doesn't have the ability to just censor things, right? We can only, like I said, we try to publish software that is accessible to run, but also incentive compatible to run. If I publish like, sorry, not I, but like if we create a piece of software and we're like, hey, miners, can you please run this? You'll lose like 30 Bitcoins and fees, but like please run this, they'd be like, no. (laughs) - By the way, did you see those fees in the first few months of the office? - Yeah, that's what I mean. - Was it like 35 Bitcoins? - Yeah, yeah, like, like again, like we just, we just publish code, we don't push, like we don't force people to run it, we can't ask people to run it. People voluntarily download the software and then decide whether or not they want to do that. So if you publish software and you're like, well, if you run this, you lose 30 Bitcoins and fees, but like please, that's not how that works. And we just finished talking about how everyone has optionality and what kind of mempool rules that they're gonna use, 'cause it's not consensus again. And like we have so many clear examples of like marathon or F2 pool mining things that would have been rejected by the Bitcoin Core defaults, aren't it, rules? - This is the out of band stuff. - Yeah, yeah. - What is that all about? Are they constructing transactions but that don't go into the mempool? They're not broadcasting them. They're just putting them as part of a block. - So it would be, it would be in their mempool and then they just don't send that to anybody else or like a lot of times they do it because they, they're running some patch that is different from the Bitcoin Core, like rules. - Is there any danger to out of band transactions? - So let's go back to the block RelayLayTonsC thing that we were talking about where anytime you create, okay, so this, I think when things are working right, best I mean, like everybody already knows all the transactions by the time you broadcast the block and then like it propagates like immediately, right? - Right, and if they construct, so if they a single out of band transactions find, if they did a whole block of them, and then broadcast that, we have a potential latency issue. - So actually a single one makes a difference as well. - Okay. - So kind of the way that block Relay usually happens nowadays is with compact blocks and we have like, like kind of direct high bandwidth like first round, like no round trip ones as well, where basically I just send you like a skeleton of the transactions and I have like short IDs talking about all the transactions in the block. And if you already have that in your mouth, pull your like cool, I've got it. But if you're missing something, you have to be like, "Hey Gloria, can I get one of those transactions?" And then I'll be like, "Yeah, sure, here you go." And that's an extra round trip. And so yeah, like a single transaction can make a difference and of course a whole block of transactions and it's like, "Oh, I just download all these and I'm gonna validate all of them." And then, you know, and so yeah, it does make a difference. - Is that a point of debate that should the network allow out of band transactions and could they be stopped? - Well, no, no. - They could not be stopped. - No, because I guess in, it's some, like I mean, we can, like we know about marathon because they offer like a service to do this, right? But there's no way for you to enforce like, you can only give me transactions that I already heard about. It's like, like, that's why we have blocks. (laughing) It's, you know, it just doesn't work that way. And so yeah, there wouldn't be a way to, like, and like, because that's why we have consensus in blocks is we have conditions in blocks and then we're like, "Okay, these are the orders of the transactions." If we had a way to do that without, if we had a way to be like, you know, this is the order in which transactions are received and created and whatnot, then this wouldn't, like, we wouldn't have, we wouldn't be doing all this, right? - So have inscriptions presented, right? Like, we'll agree that you shouldn't censor them, we'll agree that, you know, that's not your job at a policy level. You wanna say something like that? - Yeah, we can't, like, sense, I don't like the word censor because we don't have the abilities to do that. Like, I just, like, I just said, we, like, you know what I mean? Like, we can, we can create, no, we don't. - That's why I started this episode. Like, and that's why I started, like, right off the bat, I don't have the power to decide what other people's memple policies are. - Yeah, so much power. (laughing) - We can't do that. And, and, and like, my other point was that, like, it doesn't make sense. Like, you can't, we can't write software. That's just like, yeah, like, just throw away, that's not incentive compatible. - But I have inscriptions changed, changed the work you do in that. Has it presented new attack vectors? Do you have to think about? - Like, the inscription transactions as well. - I don't know, it's just the fact that they exist at these BRC 20, like, has that changed the way you have to work? Or do you just see transactions and therefore it doesn't matter? - Hmm. I would say, I think there's two things we can talk about. One is a bug related to just what happened with really high transaction volume. And the other one is kind of more attention to, I think, mononaut calls it mempulse-miping. So I'll talk about the first one. And this is not the neat, like, this is not the structure of inscriptions. This is nothing to do with ornals. It's just the high volume of transactions. This is just kind of like an anecdote is, like, we discovered that there were a couple transaction relay data structures that were not as efficient as they could have been, you know, probably would have worked for, you know, hundreds per minute, but it doesn't work for tens of thousands per minute. - It's a good thing to find that out. And I'm not saying, like, this is great, you know. But like, a lot of people are like, has anything happened? And I think this is a positive thing that came out of that. And then the other one was I gonna talk, it was the mempool sniping stuff. I really wanted to talk about the Son of Park has. - Yeah, it's good. - It is what I have been talking about for ages. It's, I was always like, okay, like, so pinning is like the thing that we're gonna talk about. I was always like, this is really bad. This is especially bad for like, L2s and like, lightning network kind of stuff where I'll just do a shorthand one. Basically, you have the same security model because you can always settle on chain, right? You have like all these off-chain transactions that you're not gonna broadcast. And through that, you get the scalability and the privacy and the cool features. But the security is the same because you can always settle on chain. You've already enumerated all the spending paths. And they include like, hey, if you're gonna do this, I have two days to respond. Or, you know, and I respond by broadcasting this transaction that spends from it. And I have two days to do that until the other spending path opens where you get to redeem the money, right? That's usually how those L2s are kind of set up is you have this critical period within which you need to broadcast your transactions. And so my argument was always like, okay, but what if, like, what about the games you can play in Mumpule where like, I can try to censor your transaction through various means. So one of the things I was talking about was with like, replaced by VRBF. Sometimes you might broadcast a replacement or you might broadcast a transaction that makes perfect sense. But because of the limitations in how the validation like code works, like it'll just be like dumb and like, not realize this. Anyway, oh, so with kind of all this like, NFT stuff, like basically I would say this and people like, but does this ever happen? I'll be like, well, no, but like theoretically it could and you could lose money. But we actually like saw what people call like pinning. - So having a wall. - Yeah, yeah, yeah, having the wall because was it like a, you guys see how these like, like anyone can mint, anyone can like, mint the coin or whatever. And then so it was like basically a race to like, who can get, who can do it first, right? Or like, I think there was one where they exploited like, like the descendant limit thing where actually it probably doesn't make sense for me to talk about the technical details. But like they basically exploited this limitation where we're like, oh, we're only gonna consider the first this many. And then after that, like it'll just like, we'll limit the topology of the transactions that you're broadcasting because we can't handle more than this much. And then so they're like, okay, I'm like, you know, I took up all these slots and now you can't, you can't add a transaction to this. And then there was another, oh, this is the other thing is like these like swapping things that are using anyone can pay. Have you heard of Sikhash? Anyone can pay. - Yes. - Yeah. So you can sign your transaction. So that other people can change it. They can add inputs and or outputs to it. And so what that meant was like in mempool, people could replace it with their own version of the transaction where like they got to buy the NFT instead of the original person who broadcasts the transaction. And that's that one is not a limitation in mempool policy. That one was used anyone can pay. And that's how anyone can pay works. And so there's the kind of all these like people are kind of discovering this like, I think censorship is the wrong word, but like things that can go wrong between the time when you broadcast your transaction and it may or may not getting confirmed. And I think that's great that people, like I think it's, I'm so annoyed when people are like, oh, mempool should fix this. And I'm like, you know what's happening here? Is people are buying stupid sports cars that don't have locks on them and people are getting their car stolen and they're like, what's wrong with these roads? Like, why are these roads so unscrupulous? Like stop designing your thing in a way that it can be stolen. So yeah. Did I answer your questions? - Somehow, we've me and it's been so much. I do wanna ask about classification 'cause it comes up to me in my very simple technical mind it always sounds dumb. It's like how can you possibly ossify? I don't even know what it means to ossify. What we just lock the code and it can't be touched. That sounds psycho because what if there's a critical bug? Like my basic logic says, that doesn't make any fucking sense why are we talking about it? - I think probably ossification means something different to many people. I agree that the one where it's like, just stop touching the code that doesn't make any sense. - Yeah, the only ossification that makes sense to me is like a stalemate of things just don't get dumb because we can't get agreement to get things done. - That's also scary. - I'm talking about big significant-- - Like consensus changes. Well, so there are a couple consensus changes that are kind of needed, right? - Really? - Somebody said, was it John? John Carvello said, there were no hard faults. He said, there won't ever be a hard fork. It is just a copy, it's just like a copy of Bitcoin. Some of them will always run the original Bitcoin. - Right, yeah. - What do we need? What consensus changes? You talk about the one that we need for like, when we're all dead in like 21, 40 or whatever. (laughing) - There's a bug isn't there? - Yeah, and running out of time for the timestamp. - Yeah. - Yeah, and there's, I think there's a couple bug fixes that would be not, if you've heard of the consensus cleanup, oh, we probably shouldn't talk about that. - Oh, why? Because why shouldn't we talk about that? - I just, I don't-- - The people are all aware of it now, shouldn't they say? - I'm very, I try not to say things on podcasts that can be taken out of context. Like if I say like, we need X software, right? - Bitcoin's broken. - Yeah, yeah, yeah. And sometimes things that I've said have landed really poorly on Twitter and that, you know, like people will think like, I'm trying to say Bitcoin's broken. It's like, well, no, I wouldn't be working on Bitcoin if I didn't believe in it. - No, you can just fix it. - I don't have that power. (laughing) - So how is Bitcoin broken? - Okay, that's never what I'm trying to say. What I'm always trying to say is there are, like I said, all these network level attacks, all these like scalability, like all these like ideas we have of scalability of censorship resistance, privacy, et cetera, these are not like single lines of code that Satoshi wrote in the original client and then like Bitcoin has that, right? There are design goals and like we have to fortify them over time. And like I said with the example with the transaction traffic being really high, the requirements change at each time you go from like one level to the next. And nobody ever designs our software for a million people in the first iteration. You can build a POC and I'm never trying to dig. I got, I've people thought I was hating on Satoshi once too. Satoshi's great. I'm not saying that like the POC is bad. I'm just saying like over time, like the requirements get more stringent. - You literally come on my show and say Bitcoin is broken. It's a Satoshi is a dick. (laughing) - First of all, I named my dog Satoshi. - 'Cause you love Satoshi. (laughing) - Charlie Trin making named his boat Satoshi. - Yeah, well, I think I have you on that one. - You're the dog. Okay, but there are some things at some point the need doing. Ultimately though, that hundreds and definitely require a hard fork. - I wouldn't, I'm not convinced. Yeah, I think it's like there are things where it's like, "Oh, we probably need a hard fork, but we can probably figure out a way to do it using a soft fork." (laughing) - Yeah, so. - 'Cause we haven't really ever had a hard fork. Did we have one like, that was a bug fix, the inflation bug or something? - I feel like I had that one. But like, we're not like Ethereum that has one every like couple of weeks or. - No, I don't think we've had like a, well, I think maybe in the very very early prehistoric Bitcoin days, but no, we hadn't had like a purposeful way. - And people are full to a way, but yeah, yeah, yeah, yeah, and people have worked away. - But also, occasions just, it is, just can't really happen, right? - I think it's, again, it's like, what's the definition of that? - I can speak to kind of my personal thing, but has some things in common with what people say when they ask for ossification, which is like, I think we're at the point where it's best to seek to like understand and formalize and test and document and like, isolate and test the code that we have as much as possible. And I'm not really saying like, we should add a bunch of features and whatnot, at least to Bitcoin core. I think there's, sorry, to Bitcoin core, to like all the people who are experimenting with, well, UI and like trying out new, like, like, I'm not talking about that. Like, there's so many things I need to be built, so many, you know, more layers to scale. But in terms of like the protocol, I would say that I'm, I'm, I lean towards a conservative side, because there's just so much to do that just in terms of like, understanding the code better and fortifying it as I would say. And sometimes that involves a protocol change, right? Like, sometimes you need to kind of, like, invasively change something in order to make it more scalable or better or for whatever reason. So it's not, don't ever change the code. It's like, you know, be conservative and, and like, you know, not try to move fast and break things. I'd say that that's something I haven't common with, with the people who are like, ossify. But like, don't touch the code, I think is, is quite absurd. What do you think of this privacy stuff that's happened this week with Samurai and Zabi? I mean, it's obviously depressing. Has that spiked any interest or discussion about bringing privacy to Bitcoin at the protocol level? I know that comes with all the different complications, but is it a discussion point now? - There, there's a lot of privacy built in to the protocol level. Do you mean, - I mean, like, an arrow level, privacy or transactions. So I haven't personally had a conversation about this with the other, with other people who were coming to Quencort. We did talk about it and how terrifying it is. - It was a tweet. Let me find this one for you. 'Cause this is where I actually think it's particularly depressing. 'Cause I didn't think it was depressing at a personal level because I'm a bit lazy with a lot of my privacy. But this one, Peter van Volkenberg, she retweeted Anna checking of it. Check of it, I can't pronounce her name, but she said at the ACF, which is anti-corruption, here you go, the anti-corruption foundation, we relied on Wasabi when protecting our donors from Russian government surveillance and risk of imprisonment. That was not taken into consideration by the US authorities when they began attacking privacy talks. I mean, that's particularly depressing. I think that kind of goes, I'm not an expert in regulation and the history of what money transmitters or how they're classified or whatever. Yeah, I think that's, it is really serious that, like I said, there are so many roadblocks that are on the technical level, on the regulatory level, on the marketing level. It's like whenever I think about a network crash bug, I feel like a lot of it is, it'll be a PR disaster or it'll be really difficult to convince people that to quite save if nodes crash and also that it would be pretty bad. But yeah, I mean, so the question on how we think about privacy and I think there's a lot of, a lot of that. So with the release that just came out, like V2 transport, which is encrypted connections between peers, that's default now. And yeah, there's, we support running nodes on tour and stuff. So yeah, like privacy is often a consideration when adding new feet, oh, and Basel's working on broadcasting your own transactions on tour connections and to try to improve transaction relay privacy that way. There was so much to Bitcoin. Yeah, so much. Yeah. Do you feel like there's like large parts of Bitcoin you don't even know understand yourself? Oh, yeah, yeah, definitely. Like even within Bitcoin core, there's like all this cryptography stuff that like, you know, it's like magic. And you know, it's like all the time, I'm like, oh, I want to go explore this because this is really interesting and like, yeah, but so much of Bitcoin is so cool. And that's kind of, I think, how a bunch of people end up working on core is like, you know, don't trust verify. How many people who like scream that have actually like verified the code works the way that they think it does? But that was like what I was doing. Where like now when I'm around like, how does this work in Bitcoin? I'll be like trying to look at the code to like see how it works. Like that's a great feeling. But like obviously like nobody knows everything. Yeah, there's so much of it. And it's so interesting, so many interesting problems. Is there enough developers? No. (laughs) And is that a funding problem or is that a whatever number you had, you still say no? Oh, no, I think I think I can imagine like a scenario in which I'll be like, yeah, I'm feeling good about this. But the reason why a reason why I come on podcasts is like ultimately Bitcoin is like, we're trying this experiment of like completely decentralized organization or governance or whatever. And at the end of the day, like you or me or any other Bitcoiner has like the same level of responsibility to, you know, like if there was a really big bug or if you know Bitcoin didn't succeed the way that we wanted to, it wouldn't be because like the CTO like didn't do his job or whatever. It would be because all of us who have this responsibility didn't, you know, do it properly. And if Bitcoin fails because everybody thinks it just, you know, boils the oceans and has no, it has no value and you know, helps criminals or whatever. Like that would be like everybody's fault. And, and you know, you do amazing work in an evangelizing Bitcoin, but that's not your job. Or like that's not like, it's not inherently like Bitcoin said, you know, Peter's RCMO, right? It was like you went and did that. And just like all the people who worked on core, it's like, you know, maybe they held Bitcoin or maybe they got nerfed snifed in college. And they're like, well, I'm gonna work on Bitcoin core. It's not because like the Bitcoin core company hired you to be the CMO and, you know, this gotta be the CTO and like Michael sailors the C or whatever. It's like we're all equal peers in this decentralized community of Bitcoin. And so of course, naturally, like we don't have any HR department. We don't have like a, you know, a thing that is responsible for making sure there's people working on the infrastructure, right? Like, and so basically what we have to do is we have to try to like find people. And so, you know, like Jonas at Chanco does a lot of educational programs. There's Beatrust, there's Summer of Bitcoin, there's Kala, like the Brink has a fellowship program where we try to train people. And you know, I'll go to, like this is why I go to conferences so that I can meet people who have, you know, only seen pop up a couple times on GitHub or on IRC. And I'm like, hey, like let's review a PR together, right? Because if I don't, like there's no HR department, right? We're all trying to figure this out together. We all have an equal responsibility. - Do you not pop? - You listening to this podcast. (laughs) - You are all, yeah. (laughs) Yeah, you can also just contribute by, you know, if you hold a certain amount of stats, like nobody's charging you to do that, but there is a cost for it to-- - Right, tell you voluntary tax. - Yeah. (laughs) Like don't wait for somebody to charge rent, don't wait for, you know, like we all have like an equal part to play in this. And like I said, I started this podcast, I don't have any extra power. - She does. - Like you can come to GitHub and open a pull request and contribute to Bitcoin Core. It's free for anybody to do so. And I would encourage you to do that. - I'm gonna call this episode. Laura says Bitcoin is broken, it's a Toshia's a dick. (laughs) - Yeah. - It was brilliant. - Okay. - And that's so much today. I always do, but I'll forget that. - Man, I feel like I'm meandered so much. - I'm worried about it. Do you want to pimp, brink? - Oh, absolutely. - Come on. - So, brinks a nonprofit. You can make a tax deductible donation to it. At least as a US tax payer and brink uses that money to fund Bitcoin Core development. We have a special focus on security. So we have maintainers like Michael Ford and me. We have Nicholas who works on the fuzzing, if you found that very interesting. We also pay for the infrastructure costs to run the machines that do the fuzzing and the testing. And we have this wonderful office where people come and work together. And we also produce the Optek Newsletter and the Optek recap. A lot of people don't know that that's part of brink. That money goes there too. And yeah, it's a great way to contribute. If you do not write code, you can donate to brink instead. - Amazing. Rich Bitcoiners, Peehan and Epochett support brink. Goro, this is amazing. I know it will be. - Thank you for having me. - No, anytime we will definitely do this again. Yeah, keep going. Thank you. Amazing. (upbeat music) All right, come on. How F in court is Gloria? Absolutely loved this love hanging out with her in Africa. I knew she was smashed on the podcast. So very glad to have her in our corner, rather than in San Fran working at Google. As it was great digging into the weeds of mempools and Bitcoin court with her. Now we will finally be dropping the date for cheat code Australia this week. So keep your eyes out for that. I hope to see a bunch of you down Sydney later this year. All right, thanks for listening. You've got any questions about this or anything else. Please do hit me up as [email protected]. (upbeat music) [BLANK_AUDIO]