{ "episodeId": "SLP696", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "the_charlatan": { "name": "The Charlatan", "role": "guest", "tag": "THE" }, "guest_2": { "name": "Guest 2", "role": "guest", "tag": "GUEST" }, "guest_3": { "name": "Guest 3", "role": "guest", "tag": "GUEST" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.16, "text": "Not wanting to give scammers a quarter in Bitcoin, and I think that's obviously a desirable thing. We don't want scam projects using Bitcoin and tarnishing its reputation. But at the same time, policing this kind of activity aggressively does have big impacts on both the performance of the network and its long-term viability, right? If you wanna build the world's largest money, you can't require the entire network to update once a year to the newest anti-spam filters, and I think those two goals are kind of at odds, and reconciling both of these perspectives with each other is difficult." }, { "speaker": "the_charlatan", "time": "00:46", "start": 46.35, "text": "Hi everyone, welcome back to Stephan Livera podcast. Today we're going to be discussing a range of things on Bitcoin Core development. Of course, we'll be handling some of the core and not stuff, as well as what's coming new that's in Bitcoin Core version thirty, as well as some of the discussions around libbitcoin kernel. So joining me today is The Charlatan. The Charlatan, as I understand, I mean, maybe you can correct me, but as I understand, you sort of had a background in the Bitcoin industry, working in like hardware wallets and Nowadays, obviously, you're more focused on Bitcoin core developments. First off, welcome to the show." }, { "speaker": "stephan", "time": "01:21", "start": 81.42, "text": "Yeah, hi. And I think that sounded about right on how I got into Bitcoin development. Yeah." }, { "speaker": "the_charlatan", "time": "01:30", "start": 89.8, "text": "Fantastic. So, look, let's start with some of the big updates, from your perspective. What are some of the big, important or interesting updates on Bitcoin Core version thirty?" }, { "speaker": "stephan", "time": "01:40", "start": 99.57, "text": "Yeah, so I guess outside of the controversy around the- Policy changes, there are a few pretty big updates in Bitcoin Core 30 that are pretty major change to how we plan to ship features in the future and how we plan to structure the project in the future. And the biggest one among those is the new mining IPC interface. So this is a new interface that users not other developers can interact with, and it is designed specifically to be useful for, for Stratum v2 mining clients. And This has been developed now over the past year or so and then released a couple of weeks ago. And the Stratum v2 software can now interface with Bitcoin Core directly through This mining interface, and I'm currently even running my own little home miner through this new interface with Core 30." }, { "speaker": "the_charlatan", "time": "02:55", "start": 175.3, "text": "Right, and so that then means, I guess, the pools that support SV2, so I presume then mainly Demand Pool has full SV2 support, and I believe the Brians Pool also has it as well. So, I guess that's the implication of this, right? What are the main implications that it's making it easier for people to do Stratum v2 mining? Mining with Bitcoin Core v30." }, { "speaker": "stephan", "time": "03:16", "start": 196.5, "text": "Yeah, exactly. Or it's, it's even making it possible in like the same way. So can" }, { "speaker": "the_charlatan", "time": "03:24", "start": 204.35, "text": "you, can you elaborate a bit on that? Like, why would it have been harder without this?" }, { "speaker": "stephan", "time": "03:28", "start": 207.89, "text": "Yeah, so we had some limitations in the way that Well, these proof of work jobs or block templates are retrieved through Bitcoin Core, and the way that Stratum v2 would have required it You would have had to restart your Bitcoin Core node in order to reconfigure some of the template parameters every time. And this new interface which allows, yeah, this kind of bi-directional Communication allows you to set these settings like on the fly however you want to. Yeah." }, { "speaker": "the_charlatan", "time": "04:10", "start": 249.65, "text": "Okay. And can you just explain for us a little bit how this interfaces with mining software that you may run? Like so the user is gonna run Bitcoin Core v30 plus Some other kind of mining software, right?" }, { "speaker": "stephan", "time": "04:22", "start": 261.54, "text": "Yeah, exactly. That's how it's gonna look like. I mean, in, in the end, it's gonna be similar to running a-- I'm not sure what exactly they call it, but the datum. job decorator, and I think in the future it's just gonna be, you run Bitcoin Core and you run the extra mining software that you need, and you can just point that to your Yeah, either mining farm or home miner, whatever the setup is that you have." }, { "speaker": "the_charlatan", "time": "04:51", "start": 290.83, "text": "Great. And then also some other updates in the core thirty, I think there's, some discussion there about removing the legacy wallet. So can you just explain what was the legacy wallet, why is it being removed?" }, { "speaker": "stephan", "time": "05:03", "start": 303.0, "text": "Yeah, so the legacy wallet is the original wallet that was shipped. Since the earliest version of Bitcoin Core. And the big downsides of it was that it was basically just a bag of keys. So there wasn't any hierarchy with, within it, no bit 32 derivation or anything like that. And it was over time a major pain to maintain. So because we adapted things like descriptors and bit 32 Well, in the future probably also even better support for miniscript descriptors and, things like that. It's been really difficult to port those features back to This original wallet architecture, and so it was decided like five, six years ago already to eventually remove This legacy wallet code and instead provide a way to upgrade these legacy wallets to the full modern descriptor wallet format. And this upgrade has now finally been shipped. In the 30 and it should be pretty seamless for any users of the legacy wallet, so you can," }, { "speaker": "stephan", "time": "06:39", "start": 398.6, "text": "With either a tool or some commands in the GUI, upgrade from the legacy wallets to the new descriptor format." }, { "speaker": "the_charlatan", "time": "06:49", "start": 408.77, "text": "And so, what would you say the main rationale here is? Is it just to simplify the codebase or reduce the technical debt from the developers' standpoint? is it just seen as like, \"That's a really old-school wallet, we need everyone to upgrade to the new stuff\"? What's the thinking there?" }, { "speaker": "stephan", "time": "07:05", "start": 424.86, "text": "Yeah, this is all about reducing the technical debt. So if you look at our issue tracker on GitHub and you search for the term \"legacy wallets,\" there's just an endless stream of issues that affected it. And most of these issues were fixed in the modern wallet, but were really difficult to address properly inside of the legacy wallet architecture. So, yeah, the, the rational decision was just to deprecate it and focus on the new architecture instead of just trying to continuously patch. Mistakes over and over again," }, { "speaker": "the_charlatan", "time": "07:48", "start": 468.28, "text": "yeah. I see. And I guess a common discussion that I see, and obviously I'm sure you see this all the time, is, when people are discussing proposals for things, they're sort of saying, \"Oh, no, that's a bad idea, because that idea might be confiscatory, right? That it might lock someone out from coins that they held from years ago, or they had it in some specific use case.\" and so I guess in this case, it's not confiscatory because you're providing this upgrade pathway for people who are Is that, have I understood it correctly there?" }, { "speaker": "stephan", "time": "08:19", "start": 498.76, "text": "Yeah. And we spend a lot of time going through all the possible Like wallet topologies, let's call them, that people might have had in the legacy wallets, and we ended up finding even more bugs in the legacy wallets. Through this process. So we're fairly confident that the migration will cover all past use cases of the legacy wallet." }, { "speaker": "the_charlatan", "time": "08:52", "start": 531.69, "text": "I see, and I guess worst case, people can still use old versions, but then you're running into the issue of maybe not having all the latest security updates and things. Okay, so, I noticed you, you were also tell-telling me about, just offline about, preparation for the great consensus cleanup. So So, what's going on with that?" }, { "speaker": "stephan", "time": "09:11", "start": 550.91, "text": "So we started with that in version twenty-nine already. the idea behind that is We adapt our software outside of the consensus rules already in a way that mimics as if the consensus cleanup would already be deployed. So one of the things that was done in version twenty nine was we make it impossible to generate a block template that exploits the time warp bug Through our software. And now in version 30, we added a policy rule that already enforces Some stricter limits for the amount of operations that are allowed during transaction validation. And these stricter limits are part of the currently proposed consensus cleanup features and I think in terms of how important these pre cleanups are, I'd say they are, they are both key to getting The great consensus cleanup, deployed at some point in the future." }, { "speaker": "the_charlatan", "time": "10:37", "start": 636.82, "text": "Okay. And I guess just for listeners who are coming new and don't really know what that is, I have an earlier episode with Antoine Ponceau, not the recent one, the, the one, back before, where we talked in more detail about the great consensus cleanup. The simple, I guess, just for, you know, simple people, just explained in simple terms for people who aren't deep into it, is that there are these long-standing bugs. One is known as the time warp bug," }, { "speaker": "the_charlatan", "time": "11:01", "start": 660.82, "text": "OSing the node like DOS transactions or blocks that can like take it down, and the idea is this great consensus cleanup is a soft fork idea that would patch some of these things, and it's seen as like these are, I would say, as my understanding is, these are relatively uncontroversial, in terms of developer circles, peop-- most people accept that, yeah, it would be a good thing to do this to kind of patch these bugs, but it's sort of a question of when will there be kind of You know, all the work done, ready to actually do it. And" }, { "speaker": "stephan", "time": "11:32", "start": 691.54, "text": "obviously there's also always the timeline question in terms of getting the soft fork deployed." }, { "speaker": "the_charlatan", "time": "11:37", "start": 697.44, "text": "I see. And so then what you're saying is some of this prep work is there to, I guess, make the nodes- Maybe a little bit more protected against some of the, the fi-the failure cases in the consensus cleanup. And as I understand, some of these details are, let's say, private because you obviously don't wanna broadcast out, \"Hey, here's how you can, like, take down a bunch of nodes.\" but at the same time, you have to still work in public, right?" }, { "speaker": "stephan", "time": "12:06", "start": 725.92, "text": "Yeah, exactly. So some of them are to protect nodes against some of the exploits that we've identified and tried to patch in the cleanup, and some of them are also to ensure that If miners apply the rules in the future, that they won't end up generating invalid block templates for themselves." }, { "speaker": "the_charlatan", "time": "12:32", "start": 751.68, "text": "Gotcha. And so with that also, I guess what you're saying there is it also helps Stop like an accidental chain fork because if, you know, they don't-- or is it more just that they would generate just an invalid block?" }, { "speaker": "stephan", "time": "12:46", "start": 766.41, "text": "I mean, I don't think that the danger here would be a chain fork, like that would probably require a bit more work on the bad side, but it would mean that, that mining operation would lose the subsidy for that invalid block." }, { "speaker": "the_charlatan", "time": "13:03", "start": 783.46, "text": "I see, yeah, yeah. And I think there's like maybe one or two famous cases where I think a miner put out like they won the block, but then it was invalid because of some other thing, and they, they lost the, the, the reward basically. So, okay." }, { "speaker": "the_charlatan", "time": "13:19", "start": 799.37, "text": "so, yeah, let's talk a little bit about, this, libbitcoin kernel project, because I think that's like a big, as I understand, you're the leader for that, or you're the, you're the captain of that one. can you give us a bit of an overview there? And I guess first just disamb- what's the word? Disambiguate, because there's libbitcoin, which is a- Like an alternate Bitcoin implementation by like Eric Voskuil and stuff like that, but this is a separate project, it's called libbitcoin kernel. So can you just explain that for the listeners?" }, { "speaker": "stephan", "time": "13:53", "start": 832.57, "text": "Yeah, so I'm, as you said, like the project captain for the Bitcoin kernel, and I try to call it the Bitcoin kernel now or the Bitcoin Core kernel just to disambiguate it a bit. there is no relation between the two projects, and I'm also not responsible for the naming collision, so I'm not sure how that exactly happens." }, { "speaker": "the_charlatan", "time": "14:22", "start": 862.23, "text": "Yeah. Okay, so can you just give us an idea what is this? Like, as my, my simple understanding is, the idea is to sort of separate consensus code away from some of these other things so that those other things can be developed separately." }, { "speaker": "stephan", "time": "14:38", "start": 877.82, "text": "Yeah, so I guess there's two big ideas behind the project. One is that we internally isolate the consensus rules within Bitcoin Core from all the rest of the project. And This has been a long standing goal for the project since more than a decade now. So Satoshi's code started as this big Massive blob of logic where it's like, not clear what exactly belongs to the wallet, what is consensus code, which code is used for powering the coins Over the past decade, we've done a lot of work to isolate that properly, and I think we're at the point now where the consensus code itself is fairly isolated and We've now moved more towards what I would call stage two of the project, which is exposing the consensus logic as a reusable piece of code for other projects. That want to do something with consensus, be it validate transactions or blocks, or even use it to read Bitcoin cores. internal data structures." }, { "speaker": "the_charlatan", "time": "16:06", "start": 966.32, "text": "Okay, so can you help me understand what that would mean? Is that like a Lightning implementation could call that to understand, is this valid by Bitcoin's rules or like how would that work?" }, { "speaker": "stephan", "time": "16:17", "start": 977.46, "text": "Yeah, exactly. So a Lightning implementation, for example, can pass its transaction and the outputs that that transaction consumes Pass it to a function in the library, let's call it transaction verify or something, and then get the full confidence that the transaction is validated against the exact same rules that the rest of the network runs on." }, { "speaker": "the_charlatan", "time": "16:45", "start": 1004.98, "text": "Maybe, maybe more controversial or whatever, but I'm sure you remember there was that famous incident or maybe two incidents with, I believe, BTCd where there was like a lightning, it was like some of the lightning nodes were using BTCd, and then someone had sent, I think Barak had sent like a nine hundred ninety-eight of nine hundred ninety-nine multisig or something ridiculous and like kind of false, Like, basically, you get what I'm asking? Like, this kind of thing would help stop that example, is that what you're saying?" }, { "speaker": "the_charlatan", "time": "17:20", "start": 1039.91, "text": "Okay, so, tell us a little bit more about, you know, what else, like, so we said Lightning is one example, but what else, what other pieces of software might make use of this?" }, { "speaker": "stephan", "time": "17:33", "start": 1053.44, "text": "Yeah, so the other big one is alternative node implementations. Okay. So you can reuse this kernel library now and write your own full node implementation with whatever features you need. One to, and so far based on the experimental interface that I've authored over the past year," }, { "speaker": "stephan", "time": "18:01", "start": 1081.42, "text": "I've developed my own Rust toy node against it, so I'm also a full node developer, I guess, next to a kernel library developer. But it's also been tested out by Floresta, which is a UTXO implementation." }, { "speaker": "the_charlatan", "time": "18:21", "start": 1100.58, "text": "And aren't they also based on BTC, do?" }, { "speaker": "stephan", "time": "18:23", "start": 1103.24, "text": "no, that's another UTXO implementation. So there's two. Big UTXO or like fully fleshed out UTXO implementations. One is Floresta, which they plan to base on the kernel library, and the other one is, I think UTXO-D, they call it, and that's gonna be based on the kernel library. Okay, gotcha," }, { "speaker": "the_charlatan", "time": "18:44", "start": 1123.59, "text": "gotcha. Yeah, sorry, I, I had confused that. Okay, gotcha. and Floresta is an interesting one as well. I know I've met the developer briefly, but okay, so, so basically the point is You're getting at this idea that it's easier now for an alternate," }, { "speaker": "the_charlatan", "time": "19:02", "start": 1142.24, "text": "it's easier now to, create an alternate Bitcoin implementation and then for that implementation to have, let's say, quote-unquote, confidence that I'm still in con- I'm still in consensus with Bitcoin Core." }, { "speaker": "stephan", "time": "19:13", "start": 1153.43, "text": "Yeah, that's, that's the big goal here. Exactly." }, { "speaker": "the_charlatan", "time": "19:18", "start": 1157.9, "text": "Okay, and so then it makes it more viable then to have what some people are asking for, which is multiple implementations in Bitcoin. Now, yes, there already are some. Obviously, there's Bitcoin Core, Bitcoin Knots, LibeRelay, BTC-D, maybe a few other ones, but, I guess the point is making it viable for more to exist." }, { "speaker": "stephan", "time": "19:38", "start": 1177.53, "text": "Yeah. And beyond just making it viable, one of the goals I personally have is also removing the Bitcoin core specific idiosyncrasies Out of the library. So you really get only the consensus rules, and you can choose to have your own data model, like you can run it with UTXO, for example, or you can do some crazy indexing logic similar to what libbitcoin is trying to do, or And this is another project that has recently been tested out on it," }, { "speaker": "stephan", "time": "20:23", "start": 1222.99, "text": "you come up with alternative ways to sync up a node faster And this has been attempted in the SwiftSync project, and they've also developed a prototype node now based on the library." }, { "speaker": "the_charlatan", "time": "20:41", "start": 1240.65, "text": "Okay. now I'm curious because from different people I've spoken to and just, I guess, things I've heard, some people have said this kind of project It might be really hard to do, right, to actually separate it out because, there, there might be very, very subtle ways in which Bitcoin Core effectively, you know, that there is no standard or there is no spec for Bitcoin per se, and that people-- that's why so many people just run Bitcoin Core. So a, are you kind of going against that in a way, like you're trying to do something that a lot of people are saying is really hard to do, or, or how are you viewing it? Can you explain for us?" }, { "speaker": "stephan", "time": "21:17", "start": 1276.57, "text": "Yeah, so that's obviously something that I really take-- need to take into consideration when working on the library. And the way I've been dealing with that problem so far is that I'm trying to let any change that is required to make the library viable Flow into the Bitcoin Core code base itself in order to ensure that whatever's in the library doesn't deviate from how Core does the" }, { "speaker": "guest_2", "time": "21:52", "start": 1311.63, "text": "same logic." }, { "speaker": "stephan", "time": "21:54", "start": 1314.01, "text": "And if we keep on doing that and really sticking to that approach, I think we can mitigate That concern as best as possible." }, { "speaker": "the_charlatan", "time": "22:07", "start": 1326.92, "text": "I see. Now, I guess the other side of that could just be, well, now are you kind of expecting other implementations to run them plus Bitcoin Core at the same time? Is that effectively what it ends up being?" }, { "speaker": "stephan", "time": "22:17", "start": 1336.82, "text": "I mean, I don't expect anybody to do anything, yeah, right. This is just about, we shouldn't You know, keep this logic just to ourselves. We should allow other clients to build on it as far as possible. And it might even be useful, right? If you can integrate the kernel library alongside your own consensus reimplementation, test it and find bugs with your own implementation." }, { "speaker": "stephan", "time": "22:52", "start": 1371.68, "text": "I think that's an angle that can be sold to, yeah, pretty much every other implementation out there 'cause it just strictly improves their robustness." }, { "speaker": "the_charlatan", "time": "23:02", "start": 1382.46, "text": "I see. So I guess, again, I'm not a, I'm not a developer, I'm just an ADIQ podcaster, but, maybe it's like, it might also help them improve their own testing suite and their own- Kind of ways of making sure they're still in, let's say, meeting, meeting with Bitcoin Core in terms of how things work. and so just to be clear, this isn't, I think I saw in your blog post you mentioned you're not doing P2P, so like this is just consensus, it's not relating to how the nodes actually talk to each other?" }, { "speaker": "stephan", "time": "23:35", "start": 1415.1, "text": "No, and at least in the interface of the library, it doesn't include the mempool or policy either." }, { "speaker": "the_charlatan", "time": "23:45", "start": 1424.91, "text": "This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q. Now, some people think self-custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self-custody gives you a true feeling of liberty. The Coldcard Q has a full keyboard and big screen, it's got two secure elements and a true air gap, allowing you to go fully air-gapped. Using QR codes from seed generation to transaction signing, you can power the device using three triple A batteries, so you don't even have to plug it into the wall for power. You can easily use it with Sparrow Wallet for PC or Nunchok on mobile, and you can dial it into the right level of security and complexity that you choose. If you want a simple setup, just use twelve words and single signature. If you want passphrases, easy. If you want to add multisig or co-signing features, you've got those too. So go to coinkite dot com, use code Or self custody today. Okay, yeah. And so I guess, yeah, like a, a lot of the kind of, even a lot of the arguments about, you know, policy and consensus and so on I guess it's, it's very focused on, you know, what, what is Bitcoin Core doing because Bitcoin Core is the default, in a world where there are lots of different implementations and Bitcoin Core doesn't have like such high dominance" }, { "speaker": "the_charlatan", "time": "25:01", "start": 1501.16, "text": "how do you, how do you make sure all the peer-to-peer, all the different nodes like still talk to each other correctly? Like, what, it, it, it is Is there a standard way for that to happen?" }, { "speaker": "stephan", "time": "25:11", "start": 1510.56, "text": "I" }, { "speaker": "guest_3", "time": "25:11", "start": 1510.66, "text": "mean," }, { "speaker": "stephan", "time": "25:11", "start": 1511.04, "text": "I guess down the road we could do the same with our peer-to-peer codes." }, { "speaker": "stephan", "time": "25:21", "start": 1520.9, "text": "a Bitcoin core peer-to-peer library that does something similar. But, yeah, we're still far away from that. Like, I think we've done a decent job at isolating the consensus code, but the peer-to-peer code is a different story still." }, { "speaker": "the_charlatan", "time": "25:39", "start": 1539.08, "text": "Okay, yeah. And so, where is this project at so far? And like, what's your kind of-- Do you have like an idea of like how long it's gonna take?" }, { "speaker": "stephan", "time": "25:48", "start": 1548.13, "text": "Yeah, so we are trying to ship the interface or the library in the next version, so in v31, and it won't include all the bells and whistles. That you might expect from a fully featured consensus library, but the idea is to get something in and then incrementally improve it over time. Just doing everything all at once is a recipe for failure if you're trying to get a project done in Bitcoin Core. The review cycle is brutal in that respect. You have to- Chunk things up and take them in small pieces, which is also good, right? 'Cause we want the library to be mature, well-thought, well-thought through. And yeah, well designed." }, { "speaker": "the_charlatan", "time": "26:44", "start": 1604.26, "text": "Okay, and so then, as you're saying, the hope then is that, I mean, people say you want lots of eyes on the code, you ideally want other people building on top of it, you ideally want, as, as we spoke about, like examples like maybe Lightning implementations or, I don't know, maybe Ark or Spark or some other L2, like maybe some of them would start actually using this? To check on the Bitcoin side, are their transactions, you know, aligned with Bitcoin Core? Is that how you're seeing it?" }, { "speaker": "stephan", "time": "27:12", "start": 1632.1, "text": "Yeah, that's pretty much exactly it. one other feature that I briefly wanted to touch on is if we manage to isolate the logic in a way where it doesn't Require any system specific, resources, so stuff like database management, file management. having to switch between different CPU threads. If we get it to that point where all that stuff isn't no longer required Then we can start doing some pretty interesting stuff. So at that point, you could start validating blocks Just purely in memory without any system requirements, so you could do it on embedded devices or very restricted environments like In secure enclaves or, and stuff like Intel SGX environments. And the other interesting thing That I'm also looking at there is enabling its usage within" }, { "speaker": "guest_2", "time": "28:29", "start": 1709.03, "text": "proof generating" }, { "speaker": "stephan", "time": "28:32", "start": 1711.56, "text": "virtual machines. So there are these techniques now to do zero-knowledge proofs of arbitrary programs. But These proofs obviously require that the program is fairly restricted in itself, so we needed to be, we needed to not use any, system resources in order to get there. And The reason this is interesting is because you can then do proofs of the entire chain's validity inside the zero-knowledge proof generator and then publish a small proof that Some specific chain state is valid up to height, I don't know, a million or something, because it's gonna be in the future. And this might allow A different type of node where you wouldn't have to be downloading the entire history anymore, right? You can just take this proof and apply it, validate it, and then get Assurances that up to that height, the chain is valid." }, { "speaker": "the_charlatan", "time": "29:51", "start": 1790.54, "text": "Alright, this is like, like zero sync with Robin Linus and this, this kind of idea or, or related?" }, { "speaker": "stephan", "time": "29:56", "start": 1795.68, "text": "Yeah, it's kind of related to that." }, { "speaker": "the_charlatan", "time": "29:58", "start": 1797.76, "text": "okay, yeah. And so, is it just you working on this, or are there other people kind of also, you know, chipping away at this?" }, { "speaker": "stephan", "time": "30:05", "start": 1804.95, "text": "Yeah, so I guess it's been, it's been mostly me over the past two years or something, but then has changed a lot over the past- Last few months. So there's been a big influx of additional developers working on the project, and as far as I can tell, this happened pretty organically, like I didn't- Do a lot of publicity or anything. So it seems like other people think that this project is a good idea and are investing their time into it." }, { "speaker": "the_charlatan", "time": "30:40", "start": 1839.53, "text": "Yeah, and actually, I mean, we should probably talk about that as well. Like, why, like, if we zoom out a bit, why is it important that this is done from your perspective?" }, { "speaker": "stephan", "time": "30:47", "start": 1846.91, "text": "So I kind of like the future where we have different competing clients that run on this shared consensus code or this kernel. And I really do think that we should have competition between nodes, right? If a node implementation doesn't serve your interests for how you wanna use Bitcoin Then you should be able to either code up a decent alternative or run another alternative that serves your interests better. Yeah," }, { "speaker": "the_charlatan", "time": "31:25", "start": 1884.61, "text": "okay. I think that's, probably, that's probably gonna be a popular statement in today's, in today's climate. so I guess one other thing with like running, with, yeah, I guess how I'm understanding it then is what you're-- the work you're doing helps make it so that someone else can create a competing im-implementation, like in the future, like once this is done, Now, when it comes to, I guess, the current controversy around all this, you know, data carrier size and things, well, m-maybe you wanna just give us a bit of an overview there. Can you just give us like your sort of high-level- Analysis or view of what's going on with this data carrier size thing and the controversy that's going on nowadays?" }, { "speaker": "stephan", "time": "32:11", "start": 1931.18, "text": "Yeah, that's gonna be tough to do in a few minutes, I guess, 'cause of all the history that Yeah, has been discussed at length by a lot of people over the past few months. But to me, it comes down to not wanting to give scammers a quarter in Bitcoin. And I think that's obviously a desirable thing, right? We don't want scam projects using Bitcoin and tarnishing its reputation. But at the same time, policing this kind of activity aggressively does have big impacts on both the performance of the network And its long term viability, right? If you wanna build the world's largest money, you can't require the entire network to update once a year. To the numerous anti-spam filters. And I think those two goals are kind of at odds and reconciling Both of these perspectives with each other is, yeah, difficult." }, { "speaker": "the_charlatan", "time": "33:33", "start": 2012.71, "text": "So now, what about in the case-- Okay, so what would that look like if, you know, you were to just hypothetically to walk down that filter pathway of more very rapid, let's say, spam filtering? Do you think that there's a, a deterrent effect of implementing more filters, against spam? I" }, { "speaker": "stephan", "time": "33:58", "start": 2037.73, "text": "think there might be a small deterrent But if we look back at the history of the Bitcoin project, we can also see that these kind of projects will just move To new ways of embedding their data if we pre-empt them with some other mechanism. So when the operator policy was initially loosened, well, from terabytes to, I think, forty bytes it was," }, { "speaker": "the_charlatan", "time": "34:33", "start": 2072.9, "text": "back in like twenty fourteen for zero point nine of Bitcoin. Yeah," }, { "speaker": "stephan", "time": "34:36", "start": 2075.61, "text": "very long ago. it was hoped that some of the meta protocols which were being discussed back then, so stuff like Mastercoin and Counterparty, would move to these operational outputs But they weren't permissioned enough for the use cases, the use cases that they wanted to use them for. So instead, those projects launched their protocols on What is commonly called fake key outputs. And what that does is it embeds the data that they need in order to build" }, { "speaker": "guest_2", "time": "35:18", "start": 2117.95, "text": "their, let's say asset overlay. Into these fake outputs." }, { "speaker": "stephan", "time": "35:27", "start": 2127.3, "text": "And by that example, it seems clear to me that if these kind of projects Don't have the option to embed their data in, let's say, a harm minimizing way. They will do so in a harmful way instead," }, { "speaker": "guest_2", "time": "35:48", "start": 2148.37, "text": "and it's not gonna deter them. At all, or like minimally deter them. So in 2015" }, { "speaker": "stephan", "time": "36:02", "start": 2161.55, "text": "People who were around back then might remember, we had a brief," }, { "speaker": "stephan", "time": "36:08", "start": 2168.36, "text": "like counterparty bull run, I would call it, or counterparty hype cycle is probably the correct term for it, where similarly to the BRC twenty minutes, last year, there was a big hype around launching. New kinds of token projects and whatever on the counterparty. And yeah, those outputs are now around forever, and yeah, to lock them around in our UTXI set forever. And we probably could have not have those outputs around forever if the operator's carry size was relaxed a bit earlier." }, { "speaker": "the_charlatan", "time": "36:55", "start": 2214.59, "text": "And as I understand, OP_RETURN has actually, I mean, you correct me if I'm wrong, but my understanding is OP_RETURN has actually existed since like the early days of Bitcoin, but it wasn't standard. And then so what happened in 2014 is that it got made standard and it was seen as like, okay, well, this is the way that you can, we can have a kind of a garbage ban, a garbage bin for, you know, data kind of as in the harm-minimizing context. But my understanding is it was consensus-valued like from day one. Yes Okay, and then, so there's been a lot of arguments in, in and out and back and forth around this issue. I, I guess we should address or explore some of those? I guess walking back to, Antoine's, you know, email and rationale, which was, you know, the, now the, the boogeyman, which is Satria, right? The-- I think a lot of people in the community are seeing this as like, \"Oh, Bitcoin Core is just bending over for either spammers or is sort of serving this, the interest of this particular, Company or I think the company is called, is it called Janeway? Anyway, Citra and the company behind it, that Bitcoin Core is serving just only them. Can you explain your perspective on this, whether it's serving- You know, just one company or one, you know, particular niche case, and, you know, quote unquote, opening the door for more spam." }, { "speaker": "stephan", "time": "38:24", "start": 2304.26, "text": "Anything about that is true in the remotest, so I have zero indication that Bitcoin Core changes policy to accommodate for the project of a certain startup or VC funded company. so Charlatan's going to do their thing no matter what. I think the protocol that I'm not even sure if they launched or not. at the current moment, I think they had like a pre-launch thing, but the protocol that they're rolling out isn't even using Opera, right? So They're doing their thing no matter what, which, yeah, to me echoes past behavior of these overlay protocols that wanna embed data. They're gonna do it anyway. They're gonna embed data in these fake outputs, and it's really hard to stop data in fake outputs. But then to, so to, to roll back to the the data carrier size, that's a proposal that Antoine made back in April. Citra was mentioned there because it was yet another example of a protocol embedding data In outputs, and that's all the relation there was to Satreya throughout this entire thing. So it's just an example of another protocol or another party. Doing the thing that is, yeah, just more harmful than any kind of other data embedding that you could do." }, { "speaker": "the_charlatan", "time": "40:16", "start": 2415.62, "text": "Yeah. And now my understanding in this case is Citreo, as the, I think it's called the Clementine or Clementine, I don't know how to pronounce it. I think it's a BitVM bridge, and the idea is it's a one of n honesty trust assumption, and my understanding, someone correct me if I'm getting it wrong, but my understanding is they will be doing basically inscriptions to put some data into the chain, and then what we're talking about here is Like they're kind of a fraud challenge case, or it's kind of loosely analogous to a Lightning Justice transaction, and then the idea is they would-- they have this theoretical challenge case that without the up-returned, limit increase, they would have done fake pub keys, which go into U-T, in the UTXO set and aren't relayed anyway, and hypothetically with the up-returned change, if they do change their own protocol, they could use up-returned instead. Now, I think one other criticism I've heard here is this idea that, well, actually, the, the real specific thing that they're getting is the relay network of Bitcoin. And I think this is another area where people felt like, \"Oh, it's, it's my node, I shouldn't have to relay, other people's stuff if I don't want to.\" and, you know, that, that was the concern that I heard, that I've seen from some people. and so do you wanna answer that or speak to that?" }, { "speaker": "stephan", "time": "41:36", "start": 2495.95, "text": "Yeah, so that's why The data carrier size option in Bitcoin Core, you can set it to zero. I set policy options on my nodes too. I set permit bare multisig equals zero because I don't wanna do that either, and I don't wanna give it any credence. But we also have to be realistic to ourselves that this is, yeah, mostly signal to the network, I guess, that some participants inside the peer-to-peer network, don't like this type of usage, but it doesn't really do much in terms of prohibiting the actual usage if That policy rule isn't adopted by everyone participating." }, { "speaker": "the_charlatan", "time": "42:28", "start": 2547.96, "text": "Yeah, I see. And so then there's been a lot of talk about, I guess, I think," }, { "speaker": "the_charlatan", "time": "42:37", "start": 2556.53, "text": "I'm just trying to think of the right way to explain this. So I think, at least my interpretation of this is that it's kind of like There's been some changes kind of on the network, in the, you know, the network conditions, and in some sense, it's like just attempting to match, that so that individual users can still do the right-- they can have their fee estimation, compact blocks, you know, are still being able to have a high rate for compact, compact block reconstruction. And the other argument I've heard is also around not encouraging direct to miner submission, like the Mara slipstreams of the world. and so my interpretation Now, I understand for some listeners that's controversial or whatever, they see that as like you're, you're opening up for spam, whatever. but I, I guess my interpretation, at least that's my You know, my ADIQ podcaster reading of the situation. Can you explain, like, if we're zooming out, what's going on? Do you think those other things-- So I guess let me put the question to you this way. I think there are some of these social and economic and technical phenomena that have been occurring, so things like the ordinals phenomenon, Libra Relay, BitVM, like the fact that BitVM bridging is a thing now. I, I think these are things that have shifted over time, and I guess zooming out the way I'm interpreting it is Bitcoin Core is sort of trying to respond to some of those things. How are you, how are you seeing that? Would you agree or disagree or how are you viewing it?" }, { "speaker": "stephan", "time": "44:05", "start": 2645.16, "text": "I wouldn't say that Bitcoin Core is responding to, let's say, bitVM exactly or similar projects doing similar things. But what we try to do in the project is ship a node that, with performance, gives miners decent block templates out of the box and gives Lightning Network nodes good fee estimations. So That they can do," }, { "speaker": "guest_2", "time": "44:40", "start": 2680.12, "text": "either penalty transactions or their force close in a reasonable amount of time. And both of these are really important things to" }, { "speaker": "stephan", "time": "44:55", "start": 2694.61, "text": "keep Bitcoin and its Altough Lightning running in a stable way And compromising on these two things to, yeah, try to combat certain user of the chain is dangerous and I think about precedent to set, like, we don't wanna compromise the performance of, yeah, protocols and users that are mining depending on" }, { "speaker": "guest_2", "time": "45:26", "start": 2725.95, "text": "us. To send," }, { "speaker": "stephan", "time": "45:30", "start": 2730.15, "text": "a message to other people transacting on the" }, { "speaker": "the_charlatan", "time": "45:34", "start": 2733.98, "text": "chain. Okay. And so I think there have been a lot of arguments back and forth on Let's say the, the amount to which those things are true, right? So for example, they may say, the impact on fee estimation, maybe it's not that big a deal for them, or, maybe there are disagreements on exactly how much mining centralization is being driven by this, and is this specific operator change really gonna result in saving a lot of these UTXOs that would have otherwise been created." }, { "speaker": "stephan", "time": "46:07", "start": 2766.78, "text": "Yeah, so we're trying to mitigate the bad effects that come, or the bad side effects that come from applying these policy rules. So we're working on ways to get good fee estimation and get decent block relay even if you apply aggressive filtering." }, { "speaker": "guest_2", "time": "46:33", "start": 2792.7, "text": "And I think if we" }, { "speaker": "stephan", "time": "46:37", "start": 2797.06, "text": "can come up with neat ways to do that, then it might be time again to revisit this conversation again because we don't have these technical downsides that might jeopardize some of the operations of our users." }, { "speaker": "the_charlatan", "time": "46:54", "start": 2814.11, "text": "I see. So you see it like it could actually make sense to lower the default, back down, let's say, hypothetically if the, compact blocks, something could be done to improve that. That you, you, it might make sense to actually lower the data carrier size default that Core comes out with." }, { "speaker": "guest_3", "time": "47:16", "start": 2835.95, "text": "yeah, I'm not sure about the data carrier size itself." }, { "speaker": "the_charlatan", "time": "47:19", "start": 2839.13, "text": "You're thinking more about the fee rate policies." }, { "speaker": "stephan", "time": "47:22", "start": 2841.83, "text": "It would definitely make it more feasible for people to run their own policy and have all the policy knobs that they want to, and not get jeopardized by bad fees and bad relay performance. Okay." }, { "speaker": "the_charlatan", "time": "47:38", "start": 2858.1, "text": "and so let's talk a little bit about the fee rate aspects of it as well, because I think there's been some movement there on, is it min fee rate policies? can you tell us a little bit about that? What it-- Well, first of all, just for listeners that don't know, what is that, and then explain a little bit about the change there?" }, { "speaker": "stephan", "time": "47:53", "start": 2873.43, "text": "Yeah, so there is something called a min fee rate option. And this basically dictates what the minimum fee that a transaction has to pay to a miner in order for the transaction to be accepted into a noisemen pool. And this has been set to one Satoshi per virtual byte for a long time, and that has been lowered now in version 30 of Bitcoin Core, in reaction to a majority of miners starting to include sub one Satoshi per byte," }, { "speaker": "the_charlatan", "time": "48:38", "start": 2917.8, "text": "colloquially known as SubSat Summer, which I would argue is kind of one of those social phenomena that has kind of happened, and I think maybe this is an example of reacting to what's happening on the network." }, { "speaker": "stephan", "time": "48:49", "start": 2929.17, "text": "Yeah, it certainly is, 'cause before, or the block relay performance of nodes degraded in A serious way because they weren't relaying these, subset fee rate transactions and had to then request them from peers when they arrived within a compact block. And yeah, this has also been a controversial change, though I don't really follow along the reasoning for why this is controversial. I'm just happy that I can stack even harder and not pay more fees for my Lightning channel opens." }, { "speaker": "the_charlatan", "time": "49:35", "start": 2974.72, "text": "Right, yeah. So I guess previously it was kind of, I guess loosely speaking, it was kind of understood, oh, just one sat per vByte is basically the minimum, and then all of a sudden, I think it kind of got memed into existence. As a bit of a social phenomena, oh hey, what if you went below that? And I think Monero might have something to do with this, but anyway, a few things went on there, and then, as you said, some of the mining pools lowered the rate at which they would accept. Now, I think some of them lowered it, then brought it back up again, then brought it back down, and maybe there was a little bit of trying to find the right level or the right, the sweet spot per se, but now it seems like, yes, people are" }, { "speaker": "the_charlatan", "time": "50:16", "start": 3016.05, "text": "Do, do you, do you agree or disagree with that aspect of it, and maybe you could just touch on like how low should it go?" }, { "speaker": "stephan", "time": "50:24", "start": 3024.29, "text": "So there definitely should be a floor somewhere, right? Don't wanna relay transactions That don't pay anything, 'cause then" }, { "speaker": "the_charlatan", "time": "50:36", "start": 3036.02, "text": "the network" }, { "speaker": "stephan", "time": "50:36", "start": 3036.46, "text": "would just be- Because then it's like trivially" }, { "speaker": "the_charlatan", "time": "50:38", "start": 3038.24, "text": "doccable, right?" }, { "speaker": "stephan", "time": "50:39", "start": 3039.2, "text": "Exactly, the network would just be trivially doccable, 'cause anybody can just create a- let's say point 0001 zappy buy transaction. So we don't wanna go much lower from here, I feel. The flaw was put in place in the first, in the first point as a DOS protection mechanism, but this, as far as I remember, was back when the price was around a thousand dollars. So, yeah, maybe we are" }, { "speaker": "the_charlatan", "time": "51:16", "start": 3076.4, "text": "now, as we speak, it's $108,000. So obviously, you know, in Bitcoin terms, it's, it's kinda, it's come, actually, the fees people are paying now has come down a lot, but the fiat value has come up like a hundred x, right? From like that, those days." }, { "speaker": "stephan", "time": "51:33", "start": 3092.55, "text": "Yes, exactly. So the, the costs- In fiat terms, it's still higher now to submit a transaction at the very floor fee rate than was when, this floor fee rate was put into place in the first place. Yeah. I see." }, { "speaker": "the_charlatan", "time": "51:53", "start": 3112.72, "text": "and so I guess, yeah, there's, I guess there's some, I guess periodically this has to be updated, just like as if we expect number go up, right? Bitcoin's gonna keep going up, then, it'll have to periodically be adjusted, right? Like to go down, I guess. Theoretically," }, { "speaker": "stephan", "time": "52:07", "start": 3127.01, "text": "I think we'll probably see a similar thing if the price, yeah. I, I don't know if we'll ever get to those kind of price levels, but-" }, { "speaker": "the_charlatan", "time": "52:16", "start": 3136.44, "text": "Right. It would have to be like, like a million dollars a coin or ten million dollars a coin or something higher." }, { "speaker": "stephan", "time": "52:21", "start": 3141.06, "text": "Yeah, I, I, I would expect it to play out very similarly. As it now, where like one miner just starts accepting them, a bunch of people start broadcasting transactions with even lower fees. Then a bunch of other miners, are forced to do the same thing in order not to lose more fees, 'cause the blocks that they are producing will end up empty otherwise. So I think we would see a very similar dynamic play out again." }, { "speaker": "the_charlatan", "time": "52:53", "start": 3173.41, "text": "Now, that's what we're talk- what we've been talking about so far is min fee rates policies. What about other things that are, let's say, related, so things like dust limit or You know, other things like kind of in the same area." }, { "speaker": "stephan", "time": "53:08", "start": 3187.95, "text": "Yeah, we've started discussing that over the past few weeks within Bitcoin Core of, let's say, if miners suddenly start including even dustier transactions What we should be doing, and there's no consensus within the project at all yet on what to do there. 'Cause unlike just lowering the fee rate, this has an actual impact on the long term system resources because it's gonna make it easier for people to create these dusty" }, { "speaker": "the_charlatan", "time": "53:48", "start": 3228.38, "text": "And I guess that can also be seen as a dosable thing, right? Like if you lower that too low, then again, there's like a DOS concern, right? Yeah, exactly. So I guess there's kind of a sweet spot, let's say, of based on the fiat price? over time, that maybe the dust limit also has to shift, if, you know, if Bitcoin goes to like a million dollars a coin or ten million dollars a coin, then maybe the dust limits will change too." }, { "speaker": "stephan", "time": "54:13", "start": 3253.1, "text": "Yeah, I would expect it to change too eventually. I'm not sure if We're at the price level" }, { "speaker": "guest_2", "time": "54:22", "start": 3261.91, "text": "to not supply" }, { "speaker": "stephan", "time": "54:23", "start": 3263.19, "text": "such a change, yeah. Yeah, yeah. But I'm, I'm, I'm honestly also not too keen to lower that 'cause, yeah. It might be dangerous." }, { "speaker": "the_charlatan", "time": "54:32", "start": 3271.89, "text": "Yeah, I mean, the reason I'm asking is just out of curiosity and just because it's kind of a related area, and then I guess there are some other things that have sort of shifted around, like at a peer-to-peer level, I'm not sure how deep into this you are, around things like, what is it, truck transactions and one P one C and things like this. can you talk to us a little bit about that and how the aim is to improve L2 performance?" }, { "speaker": "stephan", "time": "54:59", "start": 3299.21, "text": "Yeah, so this is something that was already shipped in Yeah. Yeah, I think so. And for Lightning specifically, it allows you to attach a so-called anchor outputs. To your transaction, and this anchor output has a zero amount attached to it, so it doesn't have any coins on it. And the idea behind that is when you broadcast that when you broadcast your transaction to the wider network, you can attach the fee that is associated with that transaction to that anchor or zero value anchor output. And this means that we don't have to commit to the fee for that transaction in a Lightning channel upfront, and we can do The fee calculation dynamically when we actually need it, based on what the current state of the mempool and the network is." }, { "speaker": "the_charlatan", "time": "56:19", "start": 3379.4, "text": "Yeah, I see. And so then, the idea is that it allows, it helps, I guess, L2s like Lightning, because then people can just like not have to- I guess estimate what the fee is gonna be when they close the channel, and now they can put it in at a really low fee and then, amend later when they actually need to close, the channel as an example. Is my understanding there? Is that right?" }, { "speaker": "stephan", "time": "56:43", "start": 3402.69, "text": "Yeah. Yeah. Yeah. Okay. And it, it just makes everything much easier." }, { "speaker": "the_charlatan", "time": "56:49", "start": 3409.23, "text": "I see. And then, as I understand, there was also in recent versions, maybe not this version, but I think there was recent work done to help stop, like, some of the forced closing in Lightning?" }, { "speaker": "guest_3", "time": "56:58", "start": 3418.11, "text": "Oh, I'm not familiar with" }, { "speaker": "the_charlatan", "time": "56:59", "start": 3419.2, "text": "that. Okay." }, { "speaker": "guest_3", "time": "57:00", "start": 3419.86, "text": "Yeah. Okay." }, { "speaker": "the_charlatan", "time": "57:02", "start": 3421.6, "text": "so I guess, yeah, I g- I think the other kind of back to the broader sort of not core kind of, drama stuff, I'm curious to get your take on the, the mining centralization side of it, like how, how bad do you think it would be if, if left unchecked, if, as an example, compact block, reconstruction rates were Not, fixed. What exactly is the downside? What's the bad outcome for us here?" }, { "speaker": "stephan", "time": "57:32", "start": 3452.38, "text": "Yeah, so we do want to have An open relay network that has good performance for everybody to make it easier for new players to enter the market, right? We don't want a cartel of miners to form that have their own relay rules, with each other. So the idea is that we don't want to entrench the monopoly that might be caused by this even further by degrading performance for new entrants into the market." }, { "speaker": "the_charlatan", "time": "58:07", "start": 3487.13, "text": "Okay. And do you know if there's any like kind of- I guess, yeah, there's maybe it's hard to quantify, but is it possible to quantify like what is the impact of, slightly reduced block prop-- compact block, Reconstruction." }, { "speaker": "stephan", "time": "58:24", "start": 3504.36, "text": "It's not clear, and I'm of the opinion that it is probably lower than most people would attribute to it. And the one thing I like to point to in that case is, a study that one of the Mempool dot space guys did, Oren Sif. You looked at the amount of orphan blocks that happens during this initial phase of subset fee rate transaction rollout. And what he noticed was that even though the blocks containing these subsets fee rate transactions relay slower across the network. There wasn't a single orphan block, that those miners, including the self-safedera transactions produced" }, { "speaker": "guest_2", "time": "59:23", "start": 3562.84, "text": "So it" }, { "speaker": "stephan", "time": "59:23", "start": 3563.04, "text": "didn't have an impact on" }, { "speaker": "guest_2", "time": "59:25", "start": 3565.38, "text": "them at all," }, { "speaker": "stephan", "time": "59:28", "start": 3567.55, "text": "apparently. And just going by the math of it, we would have expected between one and two such orphans in the time frame he looked at. So it is, yeah, a small indication that the effect is probably lower than some people think it is." }, { "speaker": "guest_2", "time": "59:49", "start": 3588.76, "text": "Okay." }, { "speaker": "stephan", "time": "59:49", "start": 3589.27, "text": "But there, there's also a whole bunch, yeah, of other effects that we can't really account for, 'cause the miners might preferentially peer with each other. Or they could even have their own network with each other just to relay the blocks. So, yeah, it's hard to estimate what the actual effect is gonna be." }, { "speaker": "the_charlatan", "time": "01:00:12", "start": 3612.16, "text": "I see. And I guess there are things like, like Libra Relay, which of course, for some people is controversial, for others they see it as a censorship resistant thing. can you comment on that? Like, what do you-- what's your view on Libra Relay? Do you think it should exist or shouldn't exist, or is it helping or hurting?" }, { "speaker": "stephan", "time": "01:00:31", "start": 3631.28, "text": "I don't think I really have an opinion on it. yeah, I guess it's just a thing that happens if you have an open adversarial peer-to-peer network. Where people can just do things. So, yeah." }, { "speaker": "the_charlatan", "time": "01:00:48", "start": 3648.1, "text": "Yeah. Any comment on this, so-called tolerant minority effect with, the filters in a policy context that a small number of nodes who are relaying, a broader set of transactions, they can more easily get those transactions through to a miner somewhere somehow than," }, { "speaker": "the_charlatan", "time": "01:01:09", "start": 3669.4, "text": "You know, than, than the, filter side of that equation, let's say." }, { "speaker": "stephan", "time": "01:01:13", "start": 3673.74, "text": "Yeah, so this was observable over the past few months. So even though there weren't, I think Any released or Bitcoin Core release notes yet on the network? that lowered the fee rates by default. It was already possible to just broadcast a transaction from my node and have it show up in a block. I think it was twenty minutes later, even or something. So it is enough for transactions to propagate to miners. If we just have a few of the nodes running these lower fee filters." }, { "speaker": "the_charlatan", "time": "01:02:00", "start": 3720.82, "text": "And as I understand, even during that time period, Libra Relay wasn't even going below one sat per vbyte, so it's not that these people were all running Libra Relay to do it. So it's like, it's even more of an example about this tolerant minority case in a specific context, sure, but people were getting sub one sat transactions relayed and mined without using Libra Relay, just Yeah. Yeah," }, { "speaker": "stephan", "time": "01:02:24", "start": 3744.16, "text": "exactly. So people had to go into their Bitcoin Core configuration files, lower the min fee rate options, and then run their nodes with it." }, { "speaker": "the_charlatan", "time": "01:02:33", "start": 3753.26, "text": "Yeah. Yeah. And presumably enough people did that, like just went to manually set their, fee rate or their, their setting lower, that they would accept that and relay that, and it happened. Yes. Yeah, okay." }, { "speaker": "the_charlatan", "time": "01:02:49", "start": 3769.16, "text": "I guess on the whole, I don't wanna get, banned off, you know, whatever, but let's talk, let's say illegal content. and I hope everyone understands, like we're obviously no one here is in favor of, you know, illegal content on, in Bitcoin. But what was your, I guess, do you have any comment on that about that raising the- The operator relay limit, is that encouraging or discouraging, or is it the same? Do you see it as increased risk of illegal content going on Bitcoin or less or the same? How do you see that?" }, { "speaker": "stephan", "time": "01:03:24", "start": 3804.27, "text": "I think it's the same because it's already trivial. Like there are already websites that offer you to upload media into an inscription. And, yeah, the operator and change doesn't make that easier. Yeah." }, { "speaker": "the_charlatan", "time": "01:03:41", "start": 3821.18, "text": "Although I think one counter argument would be that if you went to, let's say, Mara's Lipstream, that they might filter on their side, right? Like, because they've got a website, obviously they're a public listed company, they very likely run some kind of filter on their side to stop You know, mining illegal content into the chain. So, do you think that changes it, or do you think it's more like, do you think there's something else here?" }, { "speaker": "stephan", "time": "01:04:03", "start": 3843.89, "text": "I mean, the same would apply to an operator and transaction with illegal content inside, right? But Yeah, the, these websites offering these media embedding services already now, like you can just get the transaction from them, broadcast it normally on the peer-to-peer network, and then- Yeah, it just takes one miner to include it anyway, so yeah." }, { "speaker": "the_charlatan", "time": "01:04:32", "start": 3872.72, "text": "Was there any discussion inside of your phone call that this would increase the risk about illegal content or, you know, was there a back and forth on this or was it more just everyone thought, \"Well, it's, you can already do this with inscriptions or this kind of thing.\" Okay, so it was kind of seen as like the, it's kind of, it's just the same risk. Okay, yeah." }, { "speaker": "the_charlatan", "time": "01:04:51", "start": 3891.52, "text": "Yeah, I think that's probably one of the areas where there's been a lot of, you know, a lot of anger or emotion and engagement about this, that it's raising the risk, Different lawyers in the space, I think six of seven polled, have said they didn't believe this increases the risk, but I, I think that they said it's, it's likely an overblown risk, but I guess if people have that concern and, it's worthwhile people at least discussing and talking about how they're thinking about it." }, { "speaker": "guest_3", "time": "01:05:23", "start": 3923.41, "text": "Yeah, I'm, I'm not sure what to comment on that still." }, { "speaker": "the_charlatan", "time": "01:05:26", "start": 3926.11, "text": "Yeah. Like, yeah," }, { "speaker": "guest_3", "time": "01:05:27", "start": 3927.13, "text": "I feel it's completely blown out of proportion." }, { "speaker": "the_charlatan", "time": "01:05:29", "start": 3929.53, "text": "So in terms of where things are going from here? do you have any other comments on, things people should know about Bitcoin Core or, I guess, let me ask you this, what do you think is an un-unknown or underappreciated thing, about Bitcoin development?" }, { "speaker": "stephan", "time": "01:05:48", "start": 3948.44, "text": "Yeah, this is probably my favorite thing to talk about, Bitcoin Core specifically. One of the reasons I became fascinated with the project, From a very early stage on, and this is Bitcoin Core's obsession with ensuring that the binaries that are published are as pristine as possible. So We not only, audit our own dependencies, we also audit some of the toolchains that we use. And we use reproducible builds, and even a step further than just reproducible builds, we use" }, { "speaker": "stephan", "time": "01:06:36", "start": 3996.98, "text": "a system called Geeks to produce our binaries, and this system ensures that the compiler that I use The compiler that you are using to compile the code is bootstrapped from a chain of source code and not from" }, { "speaker": "guest_2", "time": "01:06:58", "start": 4018.14, "text": "some Boostrapping compiler." }, { "speaker": "stephan", "time": "01:07:02", "start": 4022.26, "text": "And this, I think, is really key. So basically, this goes into something called trust in trust, where One component in your tool chain eventually is just a binary that you need to trust, you can't inspect its source code. And you have to trust the binary not to insert a backdoor into the rest of your bootstrapping process. So you might have reproducible builds and everything set up But somewhere down your bootstrap, you have this weird version of, let's say, a C compiler that is backdoored. And I think for Bitcoin specifically, it is really important to get this right and to solve this problem. Because we want Bitcoin to be stable for decades, an attacker can create backdoor inside such a bootstrapping chain now. And sit on it for the next few decades, and we won't learn about it until the attack is actually deployed. And the system that we use in Bitcoin Core solves this by having this kind of bootstrap chain that goes all the way back to A couple hundred of bytes of machine code that can actually be read and understood by a software engineer." }, { "speaker": "the_charlatan", "time": "01:08:34", "start": 4114.92, "text": "I see. And so I guess what you're talking about there is this idea that having stronger confidence that people haven't inserted Bugs or, vulnerabilities into the code with us unknowing, because, again, so is my understanding of it that there's, you know- Code is being, you know, people are making pull requests, it's getting merged into the master, that code is getting, that branch is getting, compiled and create, and because you have to create, I guess, the actual binaries, which is like, you know, whatever, the dot exe or the dot tar.gz or whatever, these files that we, the end users, right, whether it's Windows, Mac, and Linux, we actually run and install on our PCs. But I guess what you're talking about is that process of how is it, Built and made ready for the user to make sure that it actually is, correctly what the code was written as is what is running on your machine. Have I, have I got you there?" }, { "speaker": "stephan", "time": "01:09:33", "start": 4173.1, "text": "Yeah, exactly. And the key beyond that is that you can also fully inspect all the tools used to generate that binary or" }, { "speaker": "guest_2", "time": "01:09:46", "start": 4186.03, "text": "that blob of- Machine code instructions, yes. I see." }, { "speaker": "the_charlatan", "time": "01:09:52", "start": 4192.07, "text": "Yeah, and so it is also possible, of course, that if you're like maybe a power user or a developer or an advanced person, you can actually just like manually kind of pull the code together and build it, just compile it and build it yourself, but- Like a typical users might not do that, they might just download and install, or they might be using like the typical, like Umbrel and, Startnine and these node and, my node and the node in a box, packages, who are in turn relying on the binaries that the Bitcoin Core team are creating." }, { "speaker": "stephan", "time": "01:10:25", "start": 4225.56, "text": "Yeah, but So the, the thing to understand here is even if you use your own toolchain as a developer and you, you compile it yourself, the toolchain that you're using might still have" }, { "speaker": "the_charlatan", "time": "01:10:39", "start": 4239.83, "text": "Right, because then you could have, you could yourself have been pwned somewhere along the line." }, { "speaker": "guest_3", "time": "01:10:44", "start": 4244.93, "text": "No, not even you yourself, but the compiler that you are downloading at some point from the internet. Might be, yeah, compromised in some way. Okay," }, { "speaker": "the_charlatan", "time": "01:10:56", "start": 4256.44, "text": "yeah. And then, so that's, I guess, this is kind of getting-- That's like really, I guess, deep into the, let's say, the reproducible builds part of this. Now, you also spoke a bit about dependencies, and so as I understand, the general idea is you want-- Obviously, you might have some dependencies on other software projects, but the idea is you're trying to remove unnecessary dependencies over time. And I understand this is something that Bitcoin Core generally has been doing. Do you want to just" }, { "speaker": "stephan", "time": "01:11:24", "start": 4284.74, "text": "Yeah, so that was actually another reason to deprecate, oh, sorry, not that, remove the, remove the legacy wallet, 'cause it used Berkeley DB." }, { "speaker": "the_charlatan", "time": "01:11:37", "start": 4297.39, "text": "right, this is the famous 2013 fork, but yeah, go on." }, { "speaker": "stephan", "time": "01:11:40", "start": 4300.65, "text": "Yeah, that database has been unmaintained for a long time and Yeah, writing code against it has been really painful. So the switch was made for the descriptor wallets to SQLite, I think, four or five years ago now, but we still have to keep Berkeley DB as part of our dependency tree and still build it. So that, removing the legacy wallet allowed us to get rid of Berkeley DB as a dependency. Yeah." }, { "speaker": "the_charlatan", "time": "01:12:17", "start": 4337.45, "text": "I see. And yeah, the infamous, 2013, chain fork, I remember at that time, you know, I was new to Bitcoin then, and I remember there was like a big chain fork, and it was a big deal, and I think Gavin sort of had to come out and, had to get-- But I think that was caused by this Berkeley DB thing, and I think it was like- From then, I believe Bitcoin moved to what's called," }, { "speaker": "the_charlatan", "time": "01:12:41", "start": 4361.39, "text": "LevelDB, right? Is it LevelDB?" }, { "speaker": "stephan", "time": "01:12:43", "start": 4363.69, "text": "Yeah, exactly. The, this was also like one of the first, Bitcoin incidents that I witnessed, so it's Part of my memory too. Let's" }, { "speaker": "guest_2", "time": "01:12:55", "start": 4375.38, "text": "put it up." }, { "speaker": "the_charlatan", "time": "01:12:57", "start": 4377.06, "text": "And my, and I recall, kind of even coming back to what we were saying at the start or earlier around consensus rules, I remember listening to a podcast, Sipa, Peter Vuller, on, I think it was Chaincode Labs, maybe three, four years ago, I can't remember now exactly, where he was commenting that it was like the effect without knowing it This Berkeley DB thing had effectively become part of the consensus rules of Bitcoin without us knowing. And so, I guess that's like another example of how difficult it can be to actually- separate consensus from the other elements of Bitcoin." }, { "speaker": "stephan", "time": "01:13:35", "start": 4415.4, "text": "Yeah, exactly. That's like the one case we continuously remind ourselves of. That was just a big mistake and a mistake we try not to repeat for the kernel work." }, { "speaker": "the_charlatan", "time": "01:13:50", "start": 4430.93, "text": "Yeah. Okay. So, looking out ahead, what do you, what are some of the things that people should look forward to seeing in Bitcoin Core, just generally?" }, { "speaker": "stephan", "time": "01:14:02", "start": 4442.22, "text": "Yeah, so one of the things I didn't get into with the mining interface for Stratum v2" }, { "speaker": "guest_2", "time": "01:14:11", "start": 4451.42, "text": "is That we built it in" }, { "speaker": "stephan", "time": "01:14:17", "start": 4457.51, "text": "a way that uses this new Cap'n Proto interface. And that's a new way to communicate with the Bitcoin Core node, but it is also a way for different parts of a Bitcoin Core node to be split into separate binaries and then communicate with each other. Through this Cap'n Proto interface and, serialization format. So with this change, we now have the possibility of splitting Some of our components into separate binaries, and this has a bunch of downstream effects. So having separate binaries that can communicate with each other. So let's say you have a binary that runs the core node logic, so the peer-to-peer stuff, the mempool, and the consensus rules, and then you have another binary that has the wallets. Another binary for the GUI, another one for databases or more indexes or whatever, and this allows us to have much better isolation between components in our code. So it gives us more incentives to precise our architecture, but it also has the effect that if you just wanna change something In let's say the database, you can now just program against this interface and don't have to change any logic in the node part. Or similarly for the wallet, if you just wanna change something in the wallet, you can now just do it against that interface." }, { "speaker": "guest_2", "time": "01:16:17", "start": 4577.65, "text": "And, yeah, that's important. Because we can probably relax our" }, { "speaker": "stephan", "time": "01:16:27", "start": 4587.0, "text": "review standards a tiny bit for changes" }, { "speaker": "guest_2", "time": "01:16:29", "start": 4589.95, "text": "that just affect, yeah. A small, indexing feature as opposed to a change" }, { "speaker": "stephan", "time": "01:16:39", "start": 4599.16, "text": "that affects consensus or the peer-to-peer stack. And it also allows us to get out of each other's way a bit, so we can now focus on the stuff that we actually like to do, like to work on. And I won't require to," }, { "speaker": "guest_2", "time": "01:16:58", "start": 4618.68, "text": "yeah, have to manage all" }, { "speaker": "stephan", "time": "01:17:03", "start": 4623.03, "text": "the other changes" }, { "speaker": "guest_2", "time": "01:17:03", "start": 4623.85, "text": "going" }, { "speaker": "stephan", "time": "01:17:04", "start": 4624.21, "text": "on in the rest of the codebase." }, { "speaker": "the_charlatan", "time": "01:17:07", "start": 4627.42, "text": "I see. So the idea is when you are making, you know, you're trying to create a pull request to do some code, your concern might be, \"I'm working in this one particular area, but actually this code also touches some other area,\" and so what you're saying is the idea is to try to separate them so that you can Each person can just focus on his own knitting per se." }, { "speaker": "stephan", "time": "01:17:24", "start": 4644.16, "text": "Yeah. So the, this has already gotten much better over the past few years. So these interfaces are already mostly in place. When we're not constantly interfering with each other anymore. But doing the splits into separate binaries will entrench this" }, { "speaker": "guest_2", "time": "01:17:43", "start": 4663.83, "text": "and Yeah, ensure that the architecture will hold for the future too. Yes. And the last thing that" }, { "speaker": "stephan", "time": "01:17:57", "start": 4677.1, "text": "This also means is that if there's a bug in, let's say, the indexing code or the wallet code, and it makes That part of the code crash, the crash doesn't affect the consensus rules anymore, so you can still keep on going with your transaction validation. relaying blocks to the network," }, { "speaker": "guest_2", "time": "01:18:21", "start": 4701.96, "text": "even though some other part of the stack might be," }, { "speaker": "guest_2", "time": "01:18:27", "start": 4707.49, "text": "in Yeah," }, { "speaker": "stephan", "time": "01:18:29", "start": 4709.09, "text": "about to see." }, { "speaker": "the_charlatan", "time": "01:18:29", "start": 4709.83, "text": "Yeah. actually, I'm curious if you are familiar, 'cause I know there's some other aspects of Core v30. I don't know how closely, how closely you follow or you're into those aspects of it, but I heard something about, like better NAT traversal in Bitcoin Core v30. Is that true also? Oh, yeah." }, { "speaker": "stephan", "time": "01:18:47", "start": 4727.08, "text": "So," }, { "speaker": "stephan", "time": "01:18:50", "start": 4730.04, "text": "One of the probably longest term contributors to Bitcoin Core and previous maintainer, Lon WJ. wrote a replacement for, many UPnP and the many UPnP library. So we're back at re-reducing dependencies again, 'cause this allowed us to Remove our dependence on this external UPnP library, which had produced past bugs for us, and some of them were really bad, where you could remotely crash the node. And this new library gave us Yeah, some better natraversal features, and we now decided to switch these on by default in the newest core version. So" }, { "speaker": "the_charlatan", "time": "01:19:46", "start": 4786.57, "text": "my understanding, I guess just quickly for listeners, NAT traversal, as I understand, you correct me if I'm wrong, I think it's network address traversal, and the idea is when we're in our home network, we've got our own, like our own router and our own, you know, one nine two dot one six eight dot one dot whatever, and But that's different to the network from the outside world. And, then my understanding then is, unless you do port forwarding, your Bitcoin node may not be reachable. But now, as I understand then-- you tell me if I'm getting this wrong, but my understanding then is this makes it easier for your node to just kind of default be able to be reachable to other Bitcoin nodes. Have I understood it correctly?" }, { "speaker": "stephan", "time": "01:20:24", "start": 4824.27, "text": "Yeah, exactly. So you, you still need to configure it or- Switch it on on your router. I think most don't switch it on by default, but you don't have to. And many" }, { "speaker": "the_charlatan", "time": "01:20:36", "start": 4836.62, "text": "UPnP is a setting that you have to do at your router level. But then once you have that, then your Bitcoin node is more easily connectable or reachable." }, { "speaker": "stephan", "time": "01:20:45", "start": 4845.75, "text": "So, well, we don't, we don't support that particular protocol anymore. But many, many routers, when you switch on MiniUPnP, they will also- enable some other natively reversible protocols, and these are what we currently support," }, { "speaker": "guest_2", "time": "01:21:07", "start": 4867.23, "text": "like so, nPMP. Is like the, the way we intend to support this at the moment." }, { "speaker": "the_charlatan", "time": "01:21:16", "start": 4876.86, "text": "Okay, so what, what was the name of it? I missed it. Natpnp. Natpnp. Okay, gotcha. Sorry, I missed-- I, I must have, misheard you before. Okay, And then, as I understand, there have also been some IBD, initial block download improvements in V30. Can you maybe elaborate on that if you are familiar?" }, { "speaker": "stephan", "time": "01:21:35", "start": 4895.68, "text": "Yes. So these have been building on some Prior improvements that have been done over the past four or five releases now. So I think since version twenty-five, we managed to cut the IBD time in half again. Which is pretty cool to, still see happening, all these releases later with continuous performance improvements." }, { "speaker": "stephan", "time": "01:22:04", "start": 4924.71, "text": "in this release There were a bunch of smaller improvements made, but the incremental improvement, as far as I recollect, isn't that big over version 29. I think it's around Ten or twenty percent, but I'm, I'm, yeah, I'm not sure anymore about those stats. Okay," }, { "speaker": "the_charlatan", "time": "01:22:25", "start": 4945.06, "text": "gotcha. And I guess just zooming out a little on- Bitcoin Core contrasted with other implementations or even earlier versions. Do you have any thought on what the world might look like if, you know, there's different implementations? And I guess, I presume from what you were saying earlier, you're comfortable with that, like you're okay with that idea that there's different Bitcoin implementations and Bitcoin Core is one of multiple?" }, { "speaker": "stephan", "time": "01:22:49", "start": 4969.15, "text": "Yeah, I, I think competition is definitely healthy here. I really like Bitcoin Core and I really like the Bitcoin Core project. So I don't intend to work on another implementation in the near future at least. And I think it's good if Bitcoin Core gets a bit of competition. Yeah. Maybe that can help us come up with even better ways to optimize things, to be even more pedantic on security features and review and whatever. Yeah. Yeah." }, { "speaker": "the_charlatan", "time": "01:23:27", "start": 5007.65, "text": "I think one other concern I've seen from some people in the community or online, whatever we wanna call it, Bitcoin, online, screenfests, people saying that, Bitcoin Core is kind of controlling the default, right? Because it's such a dominant implementation, although of course, the Nots, fans have been really talking a lot about how the Nots, percent has risen to, I don't know, twenty-something percent, as we speak. I guess What my point I'm asking here is, is it, is it effectively changing Bitcoin if the default implementation changes certain, you know, relay settings or things like that? So, 'cause I understand on one side you, you could say, well, you don't have to upgrade, right? Bitcoin Core has this long no auto upgrade process, like that's a long standing thing, but at the same time, there's kind of security updates, and you, if you go more than, let's say, two or three releases out of date, now you're kind of end of life. So is Pressure there that it's kind of like Bitcoin Core being the default can sort of push through certain things, because it is the dominant implementation." }, { "speaker": "stephan", "time": "01:24:34", "start": 5074.53, "text": "I think there is a bit of merit to it. Many people do run it, and I guess there is a legit effect to it. But at the same time, we've also seen that people are perfectly capable of changing the defaults themselves. Publishing slightly tweaked versions of Core, or publishing heavily tweaked versions of Core like Knots." }, { "speaker": "guest_2", "time": "01:24:58", "start": 5098.85, "text": "And as long as we don't prohibit that, then Yeah, that's just-" }, { "speaker": "the_charlatan", "time": "01:25:05", "start": 5105.98, "text": "Yeah, just so be it, okay." }, { "speaker": "stephan", "time": "01:25:07", "start": 5107.34, "text": "Gives people the freedom to choose and run whatever they want to." }, { "speaker": "the_charlatan", "time": "01:25:11", "start": 5111.86, "text": "Yeah. Okay, and then, so I guess software-wise, you're mainly, you're, you're mainly focused on the great consensus cleanup at this point, is that the main one that's kind of on your-" }, { "speaker": "stephan", "time": "01:25:21", "start": 5121.37, "text": "Yeah, I'm honestly not too interested in the soft forks trying to deploy new features for, yeah," }, { "speaker": "guest_2", "time": "01:25:31", "start": 5131.71, "text": "Lightning" }, { "speaker": "stephan", "time": "01:25:32", "start": 5132.39, "text": "or Some more crazy, Taproot transaction constructions. So, I, I try to focus on making The core protocol just more robust." }, { "speaker": "the_charlatan", "time": "01:25:46", "start": 5146.36, "text": "Yeah. Okay. I think those are the kind of the key, oh, sorry, one other one." }, { "speaker": "the_charlatan", "time": "01:25:53", "start": 5153.43, "text": "I know this has been kind of discussed and thrown, batted back and forth a few times over the years. But I'm curious if there's been thought about having like certain things built in with Core, so as an example, like an Electrum, address index kind of thing, right? Because what a lot of users are doing today is they are basically running, you know, Bitcoin Core plus, you know, some form of Electrum server, whether it's Electras or, I forgot the, some of the other Fulcrum and some of these other, or Electrum, you know, these different Electrum servers, and then they might be running, let's say, Sparrow You know, coordinator software on top of that. Is-- Has there been any talk about doing an address index inside of Bitcoin Core so people could just run Bitcoin Core and, you know, Sparrow or whatever?" }, { "speaker": "stephan", "time": "01:26:42", "start": 5202.62, "text": "Yeah, I love this question because I'm in favor of us eventually having some kind of re-indexing or maybe even a better protocol to retrieve. address specific information from Bitcoin Core. I think we are kind of moving into that direction with some of the Changes we're currently trying to get through review in Bitcoin Core, stuff that just makes our indexing code more robust. Easier to code against. And, yeah, again, the whole approach with using IPC and Cap'n Proto could really help there too, 'cause once we have an interface That you can just connect any other program to it directly. To do this indexing stuff, it might also be easier to code up And then integrate it into our project eventually." }, { "speaker": "the_charlatan", "time": "01:27:45", "start": 5265.45, "text": "I see. So yeah, it sounds like, maybe, yeah, I, I guess of course, Bitcoin Core is not a monolith. There'll be some people in favor and some against, but it sounds like you're in favor of that idea, because I think that's maybe another criticism I've heard is some people think, \"Oh, Bitcoin Core is sort of...\" Not, focusing on what the hodlers want, and some of the hodlers, they really want to be able to just kind of easily use their hardware wallet, this kind of thing, and of course, there's also been discussion about like the wallet GUI and things like that, because The, as I understand, very few people directly use Bitcoin Core's wallet itself, or at least the GUI, to be clear. many of them are just using some other wallet that's connecting to Bitcoin Core or to an Electrum server. so do you have any comments on the wallet and the GUI?" }, { "speaker": "stephan", "time": "01:28:30", "start": 5310.16, "text": "There is a group of people working on a new Bitcoin core GUI. There's some mock-ups and some first versions running off that, and people want to take a look at that. They'll probably find it if they-" }, { "speaker": "the_charlatan", "time": "01:28:45", "start": 5325.15, "text": "Yeah, I think I've seen some of those floating around. But go" }, { "speaker": "stephan", "time": "01:28:47", "start": 5327.24, "text": "on, yeah. So, yeah, I think that looks nice for the wallet feature specifically. I think Yeah, the wallet has been a bit underdeveloped the past few years and especially when it comes to features that people really want like better hardware wallets, support, maybe newer Taproot features. It's taken a bit of time, but I'm also feeling some new momentum in that corner of the code at the moment, so we've finally got the Legacy wallet removed, music to support was merged, I think, last week, which is a pretty big step in allowing, More efficient multisig setup. So, yeah, I think the project obviously can't do everything super well, but we should also have These kind of utilities for people to use in order to remain relevant and useful. Okay." }, { "speaker": "the_charlatan", "time": "01:30:00", "start": 5400.25, "text": "So, any closing thoughts? Any last, things you wanna get out there before we close up?" }, { "speaker": "guest_3", "time": "01:30:04", "start": 5404.96, "text": "Cash on the internet, no auto updates." }, { "speaker": "the_charlatan", "time": "01:30:07", "start": 5407.96, "text": "Okay. Yeah, this is like a saying I've seen some people say, so, alright, cash on the internet, no auto updates. Yeah, thank you for joining me, Charlatan. And I guess, just before we let you go, where can people find you or follow your work online?" }, { "speaker": "stephan", "time": "01:30:20", "start": 5420.59, "text": "Yeah, if people wanna follow me on GitHub, they can do that. It's just the charlatan." }, { "speaker": "the_charlatan", "time": "01:30:24", "start": 5424.53, "text": "Great. Okay. Well, thank you." } ] }