Chat_112 - Consensus Problems with ReardenCode

[00:00:00] Speaker A: If we leave bitcoin as it is, it's a new money for the 1%. The 1% can absolutely hold their own coins in a way that they really couldn't with gold in the same way. So there's. But the question is, are we building bitcoin to be a new money for the 1% or the 0.1%? Or are we building bitcoin to be a new money for the world that fundamentally decentralizes people's ability to control their own finance? And certainly I'd much rather be building the latter thing, fundamentally decentralizing finance, not new money for the wealth. [00:00:42] Speaker B: What is up, guys? Welcome back to the show. I am guy Swan, the guy who has read more about bitcoin than anybody else you know. And this is bitcoin audible. And we have got a fantastic interview today on a chat, which I surprised. I have not had Reardon code on the show before, but long overdue. And I thought this was fantastic discussion and a really good time to have the discussion since we've been talking about covenants and we just recently read Peter Todd's piece, and that's going to kind of be framed as the underlying context for this conversation, even though we don't talk about it specifically a lot. But I do bring it up just because I think it's really continuing that thread. And I thought he had a lot of really great points. And so much of this ends up being like, we end up having emotional reactions and we rush to judgment for a lot of these different technologies. And also there's kind of like fundamental arguments and disagreements about what even the course of action is and what we should be doing and what should even be on the table. And is anything an emergency? Do we need to actually make any modifications at all? And I wanted to really kind of hit all of this because there's such a huge consensus problem around making changes or making any sort of upgrade or shift to bitcoin or the clients or how any of this works. And he has, I think, a really, really informed perspective on a lot of this stuff and on how big that challenge is and kind of what we have as options moving forward, what may or may not be realistic. So I don't want to lead too much, but I think this is a really, really awesome conversation and I think it'll be really useful. And I hope you guys enjoy it because this one is all about consensus and our consensus problems and about moving forward about the path ahead for bitcoin and what does that look like and what is even on the table, a shout out to coinkite and the cold card hardware wallet for supporting this show and making this possible. Don't forget to get your cold card. Don't forget you can get a discount code which is right there in the show notes. And a shout out to everybody on fountain who boosts and does value for value. Thank you guys so much. I see the stats. I see the comments. This is also a really great way to get in touch with me. So if you want to leave a comment or something, and it's also easy way to earn stats. By the way, you can listen to the show and get paid. You should check that out if you haven't link and details in the show notes. And with that, let's go ahead and get into our conversation with reardencode on bitcoin audible dude, welcome to the show officially, and we have, I know, quite a bit I feel like we could talk about. So we'll see kind of which direction it goes as the conversation unfolds. But for anybody who doesn't really have a strong background on you, can you kind of give just a brief introduction? I mean, aside, you know, maybe I'll, maybe I'll leave in the stuff about Casa. So you have background with Casa, but what's your frame of reference for reordering code here? [00:04:09] Speaker A: Yeah, sure. I mean, my name, my handle gives a hint about it. Obviously, I'm an old school randroid or rand fan. I grew up as an anarchist and I've been a software engineer for good God, a long time now, professionally for over 20 years. Did a lot of open source stuff in college, so I was kind of connected to the open source world. And so between being an AdO case and being a software developer connected to open source, it was pretty obvious to me when bitcoin came out that this could be something. Of course, as with most people, when you first see it, everyone, including me, I'd seen liberty reserve, I'd seen e gold. I was like, it's not going to go anywhere. These things don't work. Yeah. So that's kind of the background on me and how I got into bitcoin a little bit. It took a little bit of time. On the third touch, I finally realized bitcoin wasnt just going to go away right away. And ive been kind of down the rabbit hole since after Gox. I kind of took a break from paying close attention to bitcoin for a couple of years. And then it was when bitcoin first crossed $5,000 a coin that I really started paying attention. And not long after that, I got my job at Casa. [00:05:24] Speaker B: Gotcha. Gotcha. I'm curious, as a, as someone who codes, I've found I talked to kind of the developers and stuff that I've been working with, and I seem, it seems to be that everybody kind of has their, their language that they use or that everything should be done this way. Do you have like, do you have like a. This is the framework. Like, everybody should be using rust. Do you have your favorite thing that you use? [00:05:56] Speaker A: I'm probably less strongly opinionated now. Like I said, I've been a software engineer for 20 years. I started out in Java. I've done typescript, I've done a little bit of rust. I've done c, I've done python, I've done firmware, I've done web apps. I've done all kinds of stuff. There's lots of ways to. Not going to say that there's lots of ways to do this. And I would say right now, rust seems like the best language for a lot of bitcoin stuff. I think a lot of folks are kind of right on that opinion, if you will, because of its safety around things. However, c is a great language still, and I use typescript for the swan vault that I work on these days in typescript. Typescript is also a great language, and people sometimes discount the benefits of developer productivity. You probably know this about bitcoiners. We tend to be a bit of an autistic bunch, and so people look at the, that's strange, the raw specifications of a language like, well, that's best. Well, rust is the best, right. But there are human factors involved in how languages go together and how an ecosystem for developing in a language works. And I think typescript really hits a lot of the right notes in terms of that combination of the way working in typescript feels to a person working in it. So I find it to be a very productive language, even if it's not, even has all kinds of ugly warts. Objectively, it's kind of terrible, but it works really well. [00:07:26] Speaker B: Gotcha. Gotcha. Now, I've actually heard kind of the same thing, and typescript in particular, I've heard, is extremely popular with newer coders, as I understand it. [00:07:37] Speaker A: But, yeah, it's a good place to start. Typescript and python are the starting points for a lot of people. [00:07:42] Speaker B: Yeah. But I was actually meaning about coding in general. [00:07:46] Speaker A: Oh, okay. [00:07:47] Speaker B: Why did you do it? I guess. [00:07:49] Speaker A: Yeah. Typescript, the syntactic added over the years, just makes expressing what I want the computer to do as close to what I'm thinking as possible. I'm having a thought about how I want the code to end up and it ends up that way. With a lot of other languages you're forced in c you're forced to deconstruct things into smaller thoughts, and in rust you're forced to twist yourself around to make sure the compiler is going to be happier. And in typescript you can pretty much just do it the way you're thinking it. And that's a nice thing. [00:08:21] Speaker B: Okay. [00:08:23] Speaker A: In terms of what I like about coding, man, I've been coding for such a long time now. I learned to code on a Commodore 64 when I was a little kid, when I first learned to read. [00:08:34] Speaker B: Oh, name drop. Oh my God. I'm not an OG or anything, whatever. [00:08:43] Speaker A: Yeah, I don't have the gray beard to show that. I've been doing this for a long time, so I have to kind of drop a little bit sometimes. So yeah, I've been coding for a very long time and I think it ties into freedom. Same reason I run Linux. It's terrible in many ways, but you can actually change the world that you're living in by modifying computer code. And that's something that when I wrote, I was working on the nipples game and I made the nipple game into a quiz show where every time you got one of the little dots in the nibbles game it asked you a quiz question. And I was like, I did that. I changed that game. And that kind of stuff just has had me hooked since, you know, many many years ago. [00:09:27] Speaker B: Nice, nice. No, I've, oh God. The amount of identification with, oh my God. I hate Linux, but it's the only thing I love. [00:09:40] Speaker A: I can't screen share properly, but I'm not going to change using it, right? [00:09:44] Speaker B: I can't use, I have to be on my Mac right now because this camera refuses to work with my Linux machine. But I still have like 80% of my main services running on Linux. Oh shit. Well, I'm curious. So in like for the audience's context, here is a lot of what kind of encouraged me to reach out to you was really in reference to Peter Todd's piece on the Covenant proposals and the review of all of the kind of like l two systems and designs and what's needed to kind of like flesh them out. But since then I've had a number of conversations with different groups in different places. And it's funny how broad everybody else's take on it is or just in general, like, the number of opinions on it all, which is funny, because you specifically mentioned consensus in general as like, well, how the hell do you do that? And ironically, that's been my issue, is the consensus. And the conversations are all over the place. Some people, like CTV plus CFSS CSFs. And then I had this pretty serious, and I would say well thought out rather than kind of the normal reactionary arguments about why we don't need to change anything and we shouldn't be thinking about changing anything if there's no, there's no emergent, like, what's the emergency? You know, we're passing two sets per byte right now. So maybe give me your big picture view before we start to nail down into specifics on this one. [00:11:36] Speaker A: Yeah, big picture. A couple thoughts come to mind, and one is something that I've said on x before, but I don't think I've said it enough. So I'm glad to have the opportunity. And that is that in a lot of things in the human world, by the time something becomes a critical need, whether that's scaling solutions for bitcoin, whether that's getting off the planet because there's an asteroid coming, whatever the thing might be, it's kind of too late by the time it's a critical need. And I think that's something that people who are kind of, oh, everything's fine. It's two sats per byte. They're not attentive to that reality that if we are in a situation where fees are already 1000 sat per v byte persistently, and we haven't done anything more than lightning, we're in a world of hurt and people are going to be stuck in custodial systems. And I'm not positive, I don't know that we can go back from that once everyone is forced into custodians because they couldn't use bitcoin with lightning. So I think that's what my response at high level of why are we having this conversation? Why is it worth having this conversation now versus waiting some years to continue this consensus building conversation? And then the other thing, I agree with you exactly what you've seen, the many different opinions. It's so fragmented in the ecosystem, in different thoughts around the topic of consensus and what the right way to go forward is. And one of the things that I've been realizing is we each live in our own little bubbles of it. And so within my bubble, certain details of this are obvious. Within your bubble, maybe some other details are obvious, and we have overlap of course. But there's so many separate bubbles with very little overlap, and the things that are obvious to each bubble are not obvious to others. I don't know what to do about that. It's been something I've been really thinking about, especially very recently with Peter Todd's post and other things. How do we start to bring together these different bubbles and get everyone at least on the same page of which things are obvious? Because if we can't even agree about which things are obvious, I don't know how we're going to build the rest of a consensus around how bitcoin moves forward. [00:13:54] Speaker B: No, I completely agree. And I'm actually curious what? Because that was one thing that I found interesting and one of the conversations that I had is that one of the things that I was taking as a kind of a primitive into the conversation was actually something that we disagreed with. And I didn't realize it until pretty far into the conversation. And I was like, oh, Jesus. So we're not even, we're not even starting from the same baseline of what ought to be done, you know? And so I'm curious from, let's say, just for, for the sake of subjectivity that in your bubble, what are the obvious things to you that I guess should be done? Not necessarily like, oh, we should do ctV. I mean, like, what are the obvious things for how we should think about designing this to act, to work for all of the kind of proposals or concepts for how to actually achieve the goal that we're trying to achieve. And I guess, I guess also mention what is the goal? You know, like, because sometimes we don't agree on that either. [00:15:02] Speaker A: Yeah, no, thank you. I think that for me, the obvious things are one bitcoin as it is right now, is not sufficiently better than gold to be money for the next thousand years. I love when Michael Saylor says changes you make. Bitcoin must be thinking about the next thousand years. But that presumes that bitcoin will even last that long as a good money. And given recent history of monetary things, gold was co opted in the last 200, 5300 years, let's say, and that will happen faster to bitcoin. The playbook's already been run unless bitcoin is sufficiently different from gold. And so some would say, well, bitcoin can be moved without a cargo ship. So the thing that happened to the French trying to get their gold out of the us reserves won't happen. I think that was a French whatever. Correct me if I'm wrong. [00:16:02] Speaker B: No, I think that it was a french battleship. It wasn't actually a battleship. There was some specific designation or whatever that I remember. I looked it up and it was, like, fact checked. But it was a french military ship brought into the bay in New York. [00:16:18] Speaker A: Yeah. To try and get their gold. And so. Well, is that going to be any different with bitcoin? Well, if all the bitcoin is held at Coinbase like it is kind of right now, Coinbase custody holds a huge swath of bitcoin. Will it be indifferent? No, it won't be any different. What makes bitcoin special is the ability to hold your own keys. And that's something that right now, we're seeing play out in real time, that it's not different enough from gold. And so the goal is to make bitcoin different enough from gold that it can last that thousand years and be a better money for people who need it, for countries who need it. You know, I'm an anarchist. I don't think countries should exist. But I also do think that people have a right to self determination. So if they've formed a country, well, they should be able to get their gold right? Their bitcoin. Yeah. So that's the goal. Part of this is making bitcoin a useful enough, materially better enough money system than gold, that it lasts for those thousand years. I think that's a really worthwhile goal. It's something that I think most of us are kind of trying to make real. Even the folks, and that's the place where we can agree. Even the folks that are kind of against changing bitcoin, they actually have that same goal. They think it's different enough already than gold. I don't. But at least we have the same goal of making bitcoin a money that's going to last for 1000 years. Something I talked to Vijay Boyapati about whenever we chat. And then the other thing that I think is, to me and to my group of bitcoiners, obvious, is that in order to make that last and to make it good enough, people can hold their own keys, etcetera, we need some degree of more freedom in how we lock bitcoin. There's this joke that I only heard recently, and I really enjoy it, that in bitcoin we have a bunch of script stuff, and then we have op Chexig, otherwise known as op do bitcoin. Because most of what bitcoin script has is some really, really basic script operations. And then there's op checksig, which is the one thing that was kind of bolted on by Satoshi when he was developing the script language that's specific to bitcoin as opposed to some really, really basic stuff. And op Jexig is basically opdubitcoin because that's how we lock bitcoin. And we know even more this is the case with Taproot, because before Taproot, every time you spent some bitcoin, actually, sorry, before native Segwit. And there's a little nuance there. I'll get to it in a second. We always had a script somewhere, whether it was a p two sh script or a p two wsh script. But in native Segwit, Paytowitnesspubkey hash, the script is much more hidden, but it technically is still represented by a script. And then in Taproot, the script is completely gone. If you're doing a single sig taproot address, there's no script behind it at all. Internally, the system just takes the, the key and the signature and runs a checksuit against it automatically. So with taproot, we actually really made it that opt equals do bitcoin. And then sure, we also have the scripting system, but basically there's just do bitcoin code. And so my point there is merely that we need some additional operations beyond just Opdo, bitcoin and op if, which is most of what we really have in order to. To continue developing this system and to build for more people to be able to hold their own keys. So, yeah, the details of exactly what things we might need in order to expand that do bitcoin functionality beyond that one operation, or there's like two or three of them. But whatever. The point is those basic objects you got are kind of to be discussed. But we definitely need more than that to get bitcoin to be better than gold enough, in my opinion. That's where it gets to. Opinion is like. But there's some obvious parts of we need to do something and we want it to be, for the next thousand years, a better money. [00:20:17] Speaker B: Yeah. No, and I'd certainly agree on that in framing, but I actually want to disagree with something specific because this is something that I feel like a lot of people miss about the degree. And if bitcoin gets captured, I actually don't think it gets captured in exactly the same way that gold did. And there's a specific reason why. Like, when we think about trying to make this thing last a thousand years, and we think about the scale at which we want people to be able to take their sovereignty and to basically contest a corrupt bank or a jurisdictional system that's going to try to say they can or cannot do, or you're going to work in paper bitcoin and not real bitcoin, you know, whatever that situation is, which obviously we have an unlimited number of examples of, is there's something interesting about how bitcoin, as something digital scales that is inverse to gold, because it's actually easy to protect yourself individually with gold, even though it's not easy to transact, because you obviously can't send gold over a communications line, but you can keep one gold coin. There's a lot of people out there with one gold coin or one gold bar or something who just has it locked away in their safe. But it's almost impossible when you're talking about a billion dollars worth, then it scales in reverse. The larger the capital pool becomes, the more difficult it is to not have it under the control of a bank or a government. Whereas the opposite is actually true with bitcoin. When you're dealing with small amounts, it's really difficult to. Not to use a custodian for $100, for $50, quote unquote, worth of value in bitcoin because of transaction fees, because of the fact that you have a bidding war every time you broadcast. And lightning is still just. From a technological standpoint, there's still just a lot of difficulty in doing it yourself, you know? But when you're talking about a million dollars or a billion dollars, it's extremely easy. When we're talking about a $20 trillion market, the ability to just kind of withdraw a trillion dollars out of a jurisdiction to just be like, eh, I don't want to be here anymore, can literally happen in ten minutes. And that is such a fundamental shift on a historical timeline. Like capital controls would go in for years. And the degree of, like, fine tuning and people at the border and searching and making. Pulling shit out of people's hair that would go through just to prevent a billion dollars from crossing the borders in history, I think. And it's not a complete caveat. It's not something that just totally makes the point moot without even slightly. You're still looking at everybody under $2,000 potentially being stuck. But the fact that large pools of capital can move, I think, means that at the kind of business, the small institution, the family trust, the country level, you have a completely new power dynamic. A huge shift in the power dynamic, where El Salvador can literally hold El Salvador's treasury, El Salvador can literally communicate and trade with any country on earth. And there's nothing the american banking system can do about it. So the playing field is still drastically different. But you are right that on a thousand year timeline 200 years out, we get to the point where that decentralization literally only got us one step up in the plateau. And what we wanted to do was to be able to continue to cascade that to everybody in the world. Right. So just an interesting point that I feel like is not to dismiss it, because I do completely agree with the framing, and on a long enough timeline, it's 100% true, in my opinion. [00:24:25] Speaker A: Yeah, I love that. And it's a great point. I said something like that when I was on Levera with Vijay, that if we leave bitcoin as it is, it's a new money for the 1%, because, yeah, as you said, the 1% can absolutely hold their own coins in a way that they really couldn't with gold in the same way. So there's, um. But the question is, are we. Are we building bitcoin to be a new money for the 1% or the 0.1%? Or are we building bitcoin to be a new money for the world that fundamentally decentralizes people's ability to control their own finance? And certainly I'd much rather be building the latter thing. Fundamentally decentralizing finance, not new money for the wealthy. [00:25:02] Speaker B: 100%. 100%. On that note, from a design philosophy perspective, you mentioned specifically the ability to lock up coins in a different way or in a new way. And what's interesting to me about just the idea of covenants, it's so funny. Covenants seem really obvious to me, and it's why I've had ended up coming in support of CTV specifically because it's such a. Just the idea of it locking to a hash just kind of saves you a lot of complication or kind of like, well, what happens next? It's like, well, it's just a hash. You already know what comes next, period. It's underneath that. Like, somebody had to plan it out. But it seems intuitive to me that the idea is to separate one utxo into a bunch of different ownership, individual ownership, you know? And is that the same kind of, like, easy target or obvious step in your mind? Is that that's the goal? Is that that's the granularity we don't have? Is that one Utxo is still one person in a sense, you know, I think so. [00:26:20] Speaker A: I've been talking to lots of different people over the. About a year that I've been kind of publicly active in the, in the bitcoin conversation, I've talked to lots of people about this. And when you boil down pretty much every proposal for bitcoin layers, whatever, whatever that means they're all, in some way or another, sharing utxos, even lightning, is two people sharing a UtxO. And that's why it works, because within that shared Utxo, they can push money back and forth, and then you can connect to other people pushing money back and forth within a shared Utxo. And now you have a network. So I think, yes, that's the fundamental building block. And then the details do matter though, right? So there's, right now, in the broader scope of different ways to share Utxos, you can have a pegged Utxo sharing like liquid with liquid. They have a bunch of separate Utxos, and people deposit into those Utxos at different times, the functionaries do, and they kind of generate liquid bitcoin by depositing into different shared Utxos. There's a pool of Utxos shared by everyone in liquid network. So that's one way of doing it. You could have something like an arc where there's a series of shared Utxos, where every whatever the period is for a particular arc, there's a new Utxo shared by a bunch of people, and then those can hop to a new shared Utxo. So they kind of chain or have a series of shared Utxos, or you could have something more like a roll up, where in a roll up, the general design space of a roll up is going to be one big shared Utxo that progresses along with the alternate chain. So there's a few different designs for it, but they kind of all boil down to sharing Utxo so that more people can use bitcoin. [00:28:11] Speaker B: The most important thing that you can do in order to secure your bitcoin is to use a secure, trusted, long running hardware wallet in the bitcoin space and do one that is bitcoin only like the cold card. Not only do they have the cold card mark four, which is the cypherpunk calculator, but they also now have the cold card. Q, which has the large screen, has a full QWERTY keyboard, has a flashlight and a QR code scanner, it is the cypherpunk BlackBerry of the Cold Cardinal series. And if you are looking to keep your bitcoin safe and you want all of those advanced features, you want to do some custom setup with Multisig, you want security features for those edge case scenarios where you need a brickme pin or a dummy pin that opens up to a fake wallet. The cold card has it all. And if you don't want to complicate your setup or you don't need any of those advanced features, you can use it simply as a secure default bitcoin signing device. Keep your seed, keep your keys off of your desktop computer, off of your phone, and securely and easily use your bitcoin. If you do not have a cold card or you haven't even checked it out yet, go to coinkite.com dot. The link will be right in the show notes. And don't forget that when you are at your checkout, the code bitcoinaudible, all one word will get you a discount. That will also be right in the show notes in case you forget about it. Keep your keys safe and get yourself a cold card. You know, the one thing that I've found out about roll ups that I hadn't even realized is that they are the literal opposite of privacy in every way. And I hadn't put that together. I had intuitively just think that, okay, well, you have a lot more options for privacy and a lot more availability or just kind of. Yeah, optionality. Optionality is really the word for privacy if you're going off chain, and I was a bit shocked when I talked to Burak about exactly the degree that or at least roll ups on bitcoin are literal, just a privacy nightmare. Worse than bitcoin, really, in almost every way, because you take the one decent thing about bitcoin is that the Utxo model, you still don't know exactly what's what. Somebody can have 20 utxos, and if you're not cross signing, you don't. There's no obvious way to tell. You can still, you can still coin manage and nunchuck or whatever and make sure that stuff doesn't cross, whereas in rollups you don't use purely an account system, you know. But anyway, that's just a thing that I found out very recently that I didn't know about. [00:30:56] Speaker A: It can vary with rollups. There can be other internal designs that provide some level of privacy. And truthfully, pretty much all of these layer two proposals, they do trade some degree of privacy to the participants directly in your UTXO sharing. And that's true of lightning, too. Of course, when you have a channel with someone, that channel partner knows exactly what goes through the channel. There's always some kind of a trade off there. And you mentioned Barak. So in the original design for Arkansas he proposed having a blind signing e cache scheme along with the vtxos, and also coin joining at equal values across each ark pool transaction. There are ways to get more and less privacy. They're always making some level of trade off with either a coordinator or the other participants in the second layer. But it doesn't have to be all bad, essentially, even with roll ups, there can be different role designs. And I actually, I just learned from Eric Wall on one of my spaces recently that most of what we're calling rollups on bitcoin don't meet the definition of rollups on Ethereum. In Ethereum, roll ups were built because computation is costly and is the main thing you're paying gas for. And so the roll ups would backfill all of the data about the state of the roll up onto the Ethereum chain. The full status of the roll up account would be put on the Ethereum chain. And so there wasn't this data availability problem that people are having when they're trying to build for bitcoin, because bitcoin has a different problem. On bitcoin, there's not this computational gas cost you have to pay to transact. And so you're not trying to roll up and kind of just get the gas out, you're actually trying to get the data off on bitcoin, because on bitcoin, you pay for data stored to the chain. And so that's a different fundamental problem. So when we look at roll ups on Ethereum and roll ups on bitcoin, we almost need a separate word, because on bitcoin, we're kind of trying to push the data off to a different layer, as opposed to the computation off to a different layer. Anyway, there's words are hard, which comes back to that consensus problem that we don't even have words that we all know the same definitions of, because people are saying roll ups on bitcoin, and they mean a fundamentally different thing to what roll ups on Ethereum mean. So welcome to the world. [00:33:14] Speaker B: Because it's a vague, big, giant question. I wanna see what first comes to your mind when you think about it. In the problem of consensus, what's the thing that you're like, this is just hard. This particular piece of it is what always runs into a problem to me. [00:33:34] Speaker A: It seems to be, I'm gonna call it emotional baggage. I think all of us came away from the various pieces of our history in bitcoin, whether it was the block size war itself, or whether it was fighting with Roger Verd directly, or whether it was some other piece of the history of bitcoin. And I'm including myself in this, right? I'm not trying to exclude myself. We each came away with certain emotional hangups. And so you'll see when various people, myself included, make posts, whether it's on the mailing list or on delving or on XDev about certain topics, we get not a reasoned response, but some level of just gut emotional response that says someone has trauma around this topic and they can't think rationally around it. And this happened with Jeremy Rubin when he first tried to talk about an activation client for CTV. And there was just hysterical responses from some people at the idea that he would publish an activation client for something outside of core on his own time, he would build and publish some software. And the fact that people had such a deep emotional reaction to the idea of one intelligent developer publishing a client that some people might run to activate some code on bitcoin that was well reviewed and was not dangerous. And we've seen various versions of that. That's just an example. And that makes. The process of consensus building is frequently just derailed by emotional responses. And again, I'm not immune to this. When I first started into this conversation, I had an emotional response to Kat because I had misread Andrew Polster's blog post. And I had put into my brain that if we make bitcoin too general, we're going to have these problems. And then I'd misread Andrew Polstra's blog post about OpCaT and thought that it could do everything. And so I was like, well, Kat is obviously not. It's the monster. It's evil. I had all this, and again, this kind of trauma based enemy imagery about it, and it took, I don't know, six, seven months of really kind of focusing on this stuff before I started to kind of calm down that emotional response. And I'm not sure how to do that on a broad scale for bitcoiners to let people start thinking about things with the part of their brain that can think. But I think that's the biggest hangup. [00:36:00] Speaker B: Yeah, there's a great quote. It's a quote that goes something like, we go insane all at once in a big group and in a giant groupthink, and we only gain back our sanity very, very slowly, one at a time. No, I had kind of had the exact reaction that you mentioned here with CTV, and I had a bunch of different episodes about it because I was like, all right, I got to understand how this works. My issue is funny. So many people were so aggressively against him releasing a separate client. But at least quickly throughout that process, my issue was less that it wasn't through bitcoin core. I've always had an affinity for the idea of, and I think this is just because I ran UASF, is that. No, I think it's good to have some other client try to do stuff, and maybe we should consider running that one instead, especially if it just forces core to support something without, like, I don't like the fact that we are always just leaning on this, which is really just kind of like amalgama, like an ephemeral group of people. It's not like, you know, it's not like a solid organization with some strict thing. Like, it just people kind of come in and out, you know? And so that reliance has always been a vulnerability, in my opinion. But even, I think, while I was still against CTV, I tried to make note that I felt what Rubin did, even though it ended up being so controversial from a political perspective, and especially because it also felt rushed in the fact that it was like, we're just going to do this now. But so many in the public, like so many of the general bitcoiners, did not know anything about CTV, myself included. I really was, what the, what is this? You know? And so I started taking in all of the general Fud about it and being like, you know, the idea of a recursive covenant is an extremely easy thing to be scared about, to be concerned about. And it really wasn't until I just understood. It's like, no, dude, it's a hash. You can't, you can't have a hash of a hash inside of the hash. You know, like, that's not, that's not, you're not going to be able to spin that circle and just keep that going forever, so. But, you know, it took me, I don't know, probably, probably similar amount of time, three to six months of talking to people and going back and reading another article about it and having somebody be patient with me and be like, dude, please, just for a second, let me. This is how it actually works. And then I was like, oh, shit. This is not, this is not nearly, nearly like every major thing that I was emotional and bothered about was not true, was essentially just not how it worked. And it's hard to overcome that. It's very, it's very hard to go through that process. And I'll admit that's kind of my position right now on Opcat. It seems obscure. It seems overly convoluted. With how constructions are for apparent simple things and that just alone, without having any foundation of how it works, really. Like, I could, I couldn't write a thing in Opcat, you know, without that. It just seems crazy to me to have a thing that where if you did it a little bit wrong and you have to do something with like, 50 pieces as opposed to just CTV to this thing that seems like a kind of, kind of going back to your typescript versus c mentality, it's like, well, you know, simple is also just better for building tools. Also, you know, a brick is not a complicated thing, and you could do a lot with a lot of bricks. So anyway, maybe convince me, do your, do that little piece of the puzzle of, you know, patience, shoosh for a second. Why am I wrong about OpcaT? Or what am I missing about Opcat? That maybe I'm taking the same perspective as I did with CTV? [00:40:27] Speaker A: Well, I would say in some ways I agree with you. Upcat is, on its own, a kind of a bad idea because of exactly what you said right now. I've had some conversations with Andrew Polstra and with Reindahl about it, where they've at least partially softened my view on that, and I'll try to do the same, pass that along. Essentially, it's true that constructions with OpCAT for covenants or for even recursive covenants or carrying data, but from one transaction to the other, for things like the perfect vault that Reimdahl built, those are complicated, and I think perfect vault, the overall perfect vault script has like, 200 cats in it or something. Ridiculous. [00:41:10] Speaker B: Holy crap. [00:41:13] Speaker A: But it's okay, is what they would say. And I think I've at least partially come around to that view because this is something that wallet builders already do. We have tools like miniscript that build scripts we would never come up with on our own. The fact that you or I can't necessarily write those scripts doesn't mean we can't use them. And so someone, whether it be Andrew or Randall or someone else, can write tools that compile covenants for us using OpCAT. We can audit those tools. We can have many people audit those tools, and then we can start using those tools at the higher level, the same way we already do with mini script. And so when I look at, for example, the anchor watch compiled descriptor, I wouldn't have written it the way if I was trying to build the anchor watch policy. I would have made mistakes. I would have gotten that policy wrong. But because they used miniscript, they can look at the miniscript, they can confirm that the policy is what they want in the end, but someone else helped them by auditing mini script first. The same can be true for an Opcat based construction. So that's the argument that at least from the perspective of do we need to have something that's developer friendly at this low level script language? We don't need to. We can have a compiler for that that says, okay, you want a covenant that restricts the, whatever the first inputs script pub key to be the same as the second output script pub key. Let me compile that into OpCAt for you. And that's, that's totally doable. We do that with assembly. That's how, you know, we do that all the time with computers. That's what computers are good at. We can write the code that does that correctly and then we can use that code. So that's the argument there. The other thing with OpCAT that I think I also kind of remain uncomfortable with a little bit, so I'll pass along my reality filter there a little bit, is there is this concern that is very hard to fully put to bed about whether we're going to introduce incentive distortions in terms of how miners get paid. And the simplest form of how to understand this is right now with bitcoin. The way that it is, each transaction is attached to at least one Utxo. So a specific bit of bitcoin must be spent with this next transaction. And one of the challenges of pretty much everything that we're talking about in covenant space, including OpCAT, is that we are going to probably break that strict connection. Even this kind of the two simplest ways of doing covenants that are kind of out there in terms of the simplest, in terms of reasoning about the consensus or the incentives of them are any prev out and CTV. So Sikh, any prevot and CTV, those are a big part of why they're useful is because they allow the same transaction to be attached to this Utxo or this one. [00:44:15] Speaker B: Right. [00:44:15] Speaker A: We have the same transaction go here or here. And if we've done that, we have fundamentally introduced the opportunity for miners or other parties on the network to reorder transactions in a way that wasn't possible before because each transaction specifically chained off of some previous Utxo. And so when talking through these things over the year or so, again, that I've been active in this, that's the thing that's hard to fully put to bed about any of these proposals. And the challenge is that that's the most useful thing that they do. So the most useful thing that these things do is also the thing that's hardest to fully put to bed. Whether that causes a challenge where miners can now insert transactions and reorder transactions in ways that might be beneficial to miners, but therefore might be harmful to users of the protocol and also might break miner incentives in a way where miners that have complex reordering software might have an advantage or miners that don't. Interesting, but that applies to CTV, to APO, to all of these things. [00:45:18] Speaker B: When you mean reorder. So, like, let's say there are, you know, two inputs that have a kind of any prev out situation and something gets confirmed. Are you meaning that there's like risk of Reorg in which there is a completely different order and a completely different Utxo actually being spent? Or are you meaning maybe? Give me a concrete example in kind of like what the negative looks like in practice as opposed to in theory, if you got one off the top of your head? [00:45:53] Speaker A: Actually, yeah. So here's a really simple example with lightning symmetry. The fundamental way lightning symmetry works is that any given update transaction to the channel can be spent by any later update transaction. When you want to force close a lightning symmetry channel, the first person who wants to close it takes their latest update and publishes it. There's then a delay where the other party could publish a later update to correct the state of the channel. If those both get published at the same time, let's say both parties realize that the channel's offline. And this one has state nine, this one has state eleven. They both publish those states. The best situation would be that only eleven confirms. So they both published these transactions, spending from the commitment transaction, because you can spend either the commitment or any update. So they both spend from the commitment transaction. What the miners can do is they can include both. They can change the state eleven one to, instead of spending the commitment transaction, to spend the update nine transaction, so they get both fees. So is this a major deal? Well, no, but the miners do get more fees because they observed these two transactions and they reconnected eleven to nine instead of eleven to commitment. And so the miners get more fees. Thank you. [00:47:17] Speaker B: Rebuilt the transaction as opposed to. As opposed to the user having control over what that transaction looks like. [00:47:25] Speaker A: Yep. [00:47:26] Speaker B: Interesting. [00:47:27] Speaker A: Because that transaction didn't restrict exactly which Utxo was being spent, the miners signature. [00:47:32] Speaker B: Is valid for either one of them. [00:47:34] Speaker A: Yep. [00:47:35] Speaker B: Interesting. [00:47:36] Speaker A: So again, it's not a huge deal in that case, but it does give the miners an opportunity. If the channel closes simultaneously, with two different states to get more fees than what the users intended. [00:47:45] Speaker B: Mm hmm. Now, in the end, that's still the valid person getting the coins. And it's still, it's just that it's no longer what, what is fundamentally supposed to be a competition between what is valid is now a. How much can I include? Can I get everybody to pay a fee here even though only one person is getting coins? Interesting. [00:48:15] Speaker A: Yeah. And that's like, a simple example. These things can get very convoluted the more when designing a protocol based on rebindable transactions, if you're not very careful, you can end up in situations that can be pretty bad for users. This one's not a huge deal. Two people paid a fee. They both were trying to close the channel. It's actually kind of fine because one of them did publish an out of date transaction. One valid thing would have been for the other party to wait, see that transaction, and then publish the correct transaction, which would have spent off of that one anyway. So it's not like there's a big problem in this particular scenario, but it's just a kind of small example. Because they're rebindable, the miners get this opportunity to do their own specialized reordering or rebuilding of transactions to gain more fees. [00:49:00] Speaker B: How does CTV, or just the covenant concept in general, essentially enable this? [00:49:08] Speaker A: The short version is because with covenants, part of the point of what we're doing is making transactions where we don't need a fresh signature. A CTV is basically a pre signed transaction without the signature because as you said, all it does is a hash of the next transaction. So it has to be this next transaction. And this is one of the things that Jeremy Rubin addressed in the CTV BIPD. If you have two utxos of the same script, pub key, the same locking script, either Utxo can be spent with the same CTV. So you have to be very careful in building these things that you never have simultaneously existing two different utxos with the same locking CTV because they could both be spent by the same one. So if a miner sees one, they could actually take that one, pull that. [00:49:59] Speaker B: Piece out of it, stick it on the other one, and be like, well, I'm going to publish this instead. Interesting. [00:50:05] Speaker A: So CTV is less likely on its own to be used in this way due, frankly, to the lack of a rebindable signature. And EPRV out is more likely to be used in this way because you have a rebindable signature where parties can agree to a signature and then that signature is valid. Yeah, quite different. You take those, it does exactly this thing. CTV people who build CCP tools would be less likely to build a situation where the same CTV is going to be spending two different utxos. And the way to do that is not to reuse Utxo addresses. Essentially, if you never use an address, you don't have this problem. [00:50:41] Speaker B: It's similar, it's different outcome, but it's a similar risk of being just having a wallet policy of let's not reuse the same utxos. Every time you go. The wallet just automatically gives you a new Utxo. So it would probably be like a client side. This is the standard for how we operate in this new world, so to speak. Interesting, interesting. I hadn't thought about that from the context of CTV specifically because my thinking was just like as a hash. That does make sense there. Well, how could they present themselves in the network to cause a problem? And also in the context of recursive covenants. Let's use Opcat as an example. And maybe you don't know this off the top of your head, but is, or maybe this is much more obvious than I think. If I give you an address to spend to me, is there any way that you can burden that with something I had not intended, that I have not pre suggested as, okay, there is, here's this script underneath it, or here's it's just my key, et cetera, et cetera. Or if I give you my pub key, is there some sort of relationship there where you can burden it with something that I had not intended, even though I just gave you something to pay me? [00:52:14] Speaker A: Not, I mean, not in any way that would be new with CTV or cat or anything. The thing to realize is if someone can modify in any way your address right now, they could add an additional op checksig operator onto it and be like, you have to have my signature and yours. If we assume that the sender can modify the destination before sending, then yes, they can do whatever. They can add additional tech sig for their own key. They could also add a recursive cat covenant. They can also add a CTV covenant. They could do whatever if they can modify the destination before sending. The pattern of how we use bitcoin. And frankly, also, ive mentioned this, the way the legal system works. When you agree to a contract for payment, you specify what valid ways you are willing to accept that payment, whether that be a bitcoin address or a physical mailing address or gold cash, whatever. You specify the ways. And if someone doesn't pay you in the ways that you've specified in the agreement. They haven't paid you. [00:53:19] Speaker B: Yeah, yeah. [00:53:20] Speaker A: And so that's fundamental. And that applies whether there's cat or CTV or just objectsig. If the sender is modifying the address by adding additional condition to it. They are not actually paying you. They're paying somebody, but they're not paying you. [00:53:33] Speaker B: Gotcha. Okay, then going back to the general, and I actually want to talk about a couple specifics in the review if you want in just a bit here. [00:53:42] Speaker A: But Peter Todd's review of coming to chat. [00:53:44] Speaker B: Yeah. In the general sense of consensus, you mentioned, actually, I'll read the line or the examples you gave, just because I thought this was the difference between, or the trade offs between salesmanship, earnestness, and pot stirring. And I thought that was funny. Cause I went away and that stuck in my head for, like, the next 30 minutes. So I was like, oh, shit, that's a great. Like, to kind of unpack that. Like. Cause to me, what Reuben did kind of felt like pot stirring, and, or at least that was the result, even if it wasn't intended. And part of me was like, well, that got the conversation rolling, and people were refusing to talk about it before that, really. So I'm curious, like, what are those trade offs? What is, you know, and there's another good point about, like, being earnest is more. You're going to tell more about negatives, and that's going to lead fuel to. Because everything is a trade off. Everything is a trade off. And I think people who reject the idea that not doing anything as a trade off is foolish, and then the people who say that, no, CTV is totally safe and there's no risk whatsoever. I'm like, dude, a soft work is a risk. Like, as soon as you're talking about changing something, that itself is a risk. You know, like, I don't even care about what change you're making. You could just be fixing the thing where. What's the little weird thing about the time code? We could just be fixing that, but it's a trade off because we're fucking changing something, you know? Um, so, uh, maybe kind of walk me through your thinking on that. And do you have a strategy? Do you have a background in sociology? Do you? [00:55:35] Speaker A: Yeah, man. It is. It's been. It's been a ride. The last year, I came into kind of the more public bitcoin discourse, very much on the earnestness camp. So I was. I was, I'm going to do very earnest education. I'm going to be as honest as I possibly can be about the benefits and trade offs of everything that I'm talking about. And I'm really going to just try to get out there and be as genuine and clear in my communication as I possibly can. [00:56:00] Speaker B: How's that working out for you? [00:56:05] Speaker A: Mostly really well, I think I've had some impact in doing that. My background is more in engineering management, and so I've seen how to work with people and how to motivate people. And the ways I've done that have been mostly through being as honest as possible. While carefully choosing language. You can be honest about things while using specific words. I don't know if you've studied or read about neuro linguistic programming at all. The specific word choices you use while being very earnest and honest can affect how a message is received. And so that was kind of the place where I came from originally, was I'm going to be as absolutely clear and honest as I can while helping people understand things through the choice of examples, the choice of words, et cetera. And what was amazing to me was to see that even doing that, I was getting some trauma based emotional responses. And so then I started to think more about that approach. Is it even the best approach? And so I've experimented a bit with pot stirring on purpose. [00:57:16] Speaker B: Oh, you're a troll, too? Me, too. [00:57:19] Speaker A: I didn't want to be. I didn't want, like, I started this whole public bitcoin Persona thing, not wanting to be in that situation. But what I found, and I have mixed feelings about this very, like, conflicted feelings. What I found is that there are some people, wherever I wasn't making any progress in conversing with them, they were locked in essentially a loop. And the only technique that I knew of to kind of potentially break that loop was to stir the pot a. [00:57:52] Speaker B: Bit, piss them off. [00:57:55] Speaker A: Yeah. Because you kind of raised their blood pressure to a certain degree, and now they have to respond to have a thought. Yeah. And so I've done a little bit of posturing now, and I am deeply, deeply conflicted about it. I prefer earnestness. I prefer that kind of clarity. [00:58:16] Speaker B: I still feel that's the best long term strategy. But I do agree there is, like, it's like you need both. And I think also it's kind of important that those are put in different. Like, there's something about the association and how you build. You hear this kid a little bit. The association and how you build relationships, like, you structure relationships to certain people in your mind, is that you give it to a role you put someone in some role because you can never. The degree to which, you know, anyone is always very, very shallow, especially when you're talking about large groups. It's increasingly just this tiny little, you know, I know, reading code from that episode of bitcoin audible, you know what I mean? Like, there's only so much depth that we can get out of this conversation. And so it's interesting that. And it's also why I've always liked, even though I don't really do this, because I mostly just because I'm lazy, but I also like this because of the idea of, like, anon accounts or pseudonymous like, secondary accounts where, like, you can be a troll and then you can be really honest and play in both of those things. And the troll can still incite the anger and encourage the convert, like, get people out of their stupid boxes that they put themselves in and then also champion kind of to just like, let's just be like, let's actually have an honest conversation and they can actually work off of each other. But I think there's some interesting element, and this is not super, just. Just something that, like, kind of pops into my head when I think about this all the time in. In having the separate roles for separate people. You know what I mean? Because there are some people who are just great at pot stirring. And I'm like, you it. Sometimes I'm having a lot of fun, but sometimes it's just like. Like I just walk away feeling ugh. About it. So I don't know. So I kind of. I get the way that you answered that is maybe the long thing that I'm trying to say there. [01:00:33] Speaker A: Yeah. It's a tricky thing. One thing I would say is that I think it's true that there was too much salesmanship with the taproot soft fork in particular. And it wasn't, I don't think, intentional, but it happened. The people talked about, oh, with snore signatures, we might be able to do cross input signature aggregation, and we might be able to do this and that. And the other thing, and I think that's part of the now start issue or trauma that we're working through in bitcoin consensus, is that people felt like they were sold to. And nobody likes to be sold to. [01:01:05] Speaker B: Yeah. [01:01:06] Speaker A: And so now we kind of have to figure out how to. To earn trust and help people to come back to trying to deeply understand things, because I think what happened was people were trying. Some people feel like they were trying to deeply understand what was going to come with taproot. They thought they understood, and then it turns out they didn't. And I've even talked to some very, very technical people who still think that we could have cross input signature aggregation within the existing taproot outputs on the keypath, which is not a possible thing. That's not. That's not part of the design. It was given up. [01:01:43] Speaker B: I thought that a long time, too. I don't know how many times I even said it on the show. Like, this was just so cool that you could do this because that's a cool. That's a cool ass idea. [01:01:52] Speaker A: You know, it's a good. Absolutely. Yeah. So. So we do need to be very careful with that. And that's one thing that while I may stir pots sometimes, I will. I will continue to try and really stay away from. From overselling because I think it's a thing. We are now dealing with the consequences of where people thought they understood. They thought they were getting this set of things. And then when that didn't come and you even see it in the way that some folks now go back and troll where they're like, taproot was going to do this and it didn't do any of this. So how can we believe anybody? And that's kind of where they're stuck. They're stuck in this loop of, I didn't get what I thought I was getting with Taproot, and now I'm going to be mad forever. So I think we should avoid doing that again as much as we can and trying to build consensus. [01:02:36] Speaker B: That sounds like a simple strategy that says, I agree. Guy checks. Checks that box. [01:02:44] Speaker A: But it's so hard, right? Because you're out there, whether you're me or anybody else, you're trying to build consensus around doing something because you think for whatever your internal mindset is, you think that this change or that change is the best way forward, and you're trying to get people on board with that. And it's so hard to not oversell that a little bit and say it also does this almost or it has this maybe potential someday because you really want people to come on board with your change. So I don't blame anybody. I'm not trying to cast shade about how things played out there. [01:03:18] Speaker B: And nuance is so hard to if it doesn't even seem like a massive, especially when it's something like a primitive like CTV, where it's literally fundamental. And what's funny is the more time goes on, the more I think about it, almost like P two sh in the, like in a lot of the parts of how and where the soft work is kind of in the, the whole stack of stuff. And it's hard to explain to someone, obviously, without a deep understanding, which is me most of the time. Like, it's hard to convince myself that something that sounds minor could actually have big consequences or really big benefits or consequences in general down the line, and that if anybody has any degree of hesitancy or negative association with it, that doesn't trump it when the perceived benefits feel minor too. You know what I mean? But they're so fundamental that they can actually be a lot bigger than you think. The idea of just being able to reliably and arguably simply split up the ownership of a UtxO, it seems like a very fundamental and very important piece because we have this strict Utxo limit that clearly is going to be here one day in some context. You know what I mean? [01:04:53] Speaker A: So anyway, yeah, it is really tricky. And I think that, again, that's where I entered this conversation. I started out being CTV, and then I had a lot of conversations with folks who were saying, basically, I'm not interested in a next soft fork unless it at least gives us rebindable lightning symmetry channels. And I think that's a very reasonable position. Frankly, rebindable channels are a fundamental improvement to the lightning network. We know the lightning network gives us certain benefits already, and if we can improve the lightning network and also get some other potential benefits, that's, I think, a very reasonable perspective to have. So that's part of why, you know, I made my proposal some months ago, the l enhance proposal, because with l enhance, you get maybe things like Arc and timeout trees and kind of that category of scaling proposals that are kind of more in depth utxo sharing, let's say. But at least with l enhance, you get lightning symmetry channels because everyone was saying CTV alone is not enough because it doesn't do this thing that I care about. So, yeah, it's not an unreasonable perspective that people are like, I don't want to consider this risky procedure of doing a soft fork unless I get a concrete benefit that I can kind of point at him, say, I'm getting this. Yeah, so, yeah, I get it. I do. [01:06:14] Speaker B: This is the Swan Bitcoin app, and this is how easy it is to just buy bitcoin whenever you're feeling like it. And I feel like it right now. And as it shows me right here, I still have $9,388 worth of my $10,000 of bitcoin buying that has no fees whatsoever. And now I have $10 more worth of bitcoin. I do this quite often. One of the really great things about Swan is the incredible number of resources they have for learning and understanding anything that you want to know about bitcoin. And importantly, they're going to teach you why you should not trade. They're not going to encourage you to trade. They are bitcoin only if you're looking for an easy and reliable way to get into bitcoin. If you're looking to put bitcoin in your IRA, if you're looking to put bitcoin in your business, if you're looking to do anything around getting on a bitcoin standard or getting exposed to bitcoin in your portfolio, check out swannbitcoin.com. guy is my special link, and you will find it very conveniently right in the show notes. Well, this is a perfect segue, I think, into that, because in Peter Todds, a couple of the things that I wanted to know more about that I thought in the l two review, I would get the coin pool. Ellen Hance, what was, there was another one that I was like, oh, cool. This is mentioned in here. This is going to be great. And almost all of them that I was very specific that I did not know anything about and I wanted to know about. He says, there's not really any good information on this, so we're not going to talk about it anymore. I was like, oh, come on, Todd. What the hell? So maybe lead us into Ellen Hans here. Explain it. Ellen Hans. Oh, and I also just want to make a comment that I really like your, like, that framing of that. Well, why don't we just, like, let's just focus on how do we make lightning better? Because lightning is clearly a really awesome solution that has done so much, and it is arguably the only successful l two like it. Really, it really just is. For as much shade as everybody and in shitcoin and everything wants to give, lightning is an incredibly functional, highly adopted layer two. That is a genuine layer two, I think, from that perspective is like, well, how do we make lightning more streamlined? How do we make lightning more better at its job? Better at its job in all of the different ways and cross off some of those limitations or negatives, I guess, for lightning. And also just. Can you define rebindable real quick? Just exactly what that means just for the audience? [01:08:58] Speaker A: Yeah, I mean, it's what we said earlier about how right now, all transactions are bound to a specific utxo. So this transaction must spend this utxo. It's the only one it can spend. But a rebindable transaction could spend this one or this one. If you have rebindable transactions, you can also have rebindable channels wherever this channel state is valid on any Utxo that matches the right shape as opposed to just the one channel point that was originally created. The reason that matters specifically is there's all these ideas about can we make channel factories where there's a bunch of people sharing a Utxo that spawn off a bunch of channels? And if we can have rebindable channels, then you can have a situation where the channel factory Utxo that has like 100 channels built off of it, you can actually take that channel factory UtxO, spend it to a new channel factory Utxo. But as long as it is still the same shape as the original channel factory UtxO, all those 100 channels stay still open. [01:09:55] Speaker B: Yeah. You don't have to have the interaction between all those hundred people to designate or have that new Utxo and say, come on, sign with me real quick. We have to do all this. You can do that unilaterally with one person, and you can also enforce the fact that it has to have that in the expenditure. [01:10:16] Speaker A: That's why rebindable channels, the most basic form of that is the lightning symmetry channel, where the update transactions can rebind to each other. But the broader idea, because the channels become rebindable at that point, is that you can also shift their underlying Utxo without having to resign a bunch of stuff. [01:10:36] Speaker B: Gotcha. Gotcha. Okay, that makes it a lot simpler to picture, I guess, in my head. So tell me about Ellen Hans. What is different about Ellen Hance and how exactly does it cover both grounds, I guess. [01:10:58] Speaker A: Yeah. So that's where that was my whole entry into this public conversation was I was looking for. There's this kind of argument of should we do any prev out or should we do CTV or should we do something else for the next software for bitcoin? And to me, when I entered the conversation, that's where I thought the conversation was it this thing or that thing. So s cash, any prev out has a certain set of properties which are both good and bad for various use cases. Sigma Save it is good for lightning symmetry channels on its own. Just that single sigh hash flag edition lets you do lightning symmetry channels. They're a teeny tiny bit weird because of this data availability problem. I don't want to get into details of that, but it exists they're a little bit weird. And then CTV on its own, has this potential of building things like Arc and timeout trees and better channel factories and all this other kind of VTX sharing stuff. But neither of them does the other one's thing very well. So that's why James A. Byrne made his covtools soft fork proposal not too long before I stepped into the fray, if you will. And his covtools proposal included both CTV and any prev out, along with his own op vault. Because he was saying, well, this because any prev out doesn't do everything CTV does, and CTV doesn't do everything that any prev out does. We won both. And then he, of course, had written Opvault, which he thinks is an important part of kind of improving self custody for bitcoiners. And that kind of. I would say upvault is really important for the middle tier of bitcoin holders. So the more than 100,000, less than 10 million in that area, Upvault is really helpful. So I get. I'm on board with that category of holders and improving their experience. Anyway, so that was the context when I came in, and my frustration was that any prev out and CTV are actually very similar. If you look at what is hashed in the signatures for any prev out, if you do sig hash any prev out, any script, I think are the two flags. Sighs any provide any script. The hash is almost, but not quite the same as the CTV hash. Now, the any priv out one has to be signed. The CTV one is just the hash with no signature. But the parts of the transaction they have hashed are almost the same. So I went down this whole path of trying to figure out, is there a different thing we could do where we can make a slightly more flexible sigh hash flag that would also get us the full CTV hash, and it would still be signed. And so I designed this thing called templatekey, which was a slightly more flexible version of sigh hash that allowed it to fully cover both CTV's use cases and any provout's use cases. I realized that that was probably unnecessarily wearing the complicators gloves. So I took off the gloves and I put them off to the side, and that's when I developed the combination of Ln Hanse. And the reason l enhance is useful is that the only thing that CTV was really missing from being able to do these lightning symmetry channels was the ability to sign the hash sigh. Any prev out is a sigh hash. So the hash is always signed. To CTV is just a hash. The hash is not signed. I needed to be able to sign this thing and then I can do lightning symmetry channels. So Lm hence is CTv plus checksig from stack, which lets me take the hash and sign it. [01:14:26] Speaker B: Gotcha. [01:14:27] Speaker A: Ok. And then added one more opcode, which is op internalkey. Because one other feature of sigache any prev out, the actual change they make is not just adding sigh hash flags. It's also adding a new special kind of key, which is a one byte key. And that one byte key is replaced with the internal key of the taproot output before the signature is checked. Op internalkey is the manual version of that. Instead of a magical one byte key that is replaced with the internal key. Let me just give an opcode for that. Op internal key takes the internal key and puts it on the stack for signature checking. [01:15:01] Speaker B: Gotcha. It just makes it an order of operations in doing the same thing that otherwise would be like its own tool, so to speak. [01:15:10] Speaker A: Right. So it's deconstructing some of the pieces of bitcoin. Right. We have opt do bitcoin op checksig and lmhance deconstructs that a little bit. It lets you do the hashing, get the signature, and then check the signature. [01:15:22] Speaker B: Gotcha. Okay, interesting. So ln Hance is the. Because I've heard this from a couple different people, and it might have been even you in a conversation at some point, but that CTV needs to have csfs, that needs to have the check sig from stack with it in order. [01:15:40] Speaker A: To basically get revital channels or like. [01:15:42] Speaker B: The real benefit that a lot of people are going for. That's also the big thing. And I thought that there was a construction of doing this with CTV where you could keep the CTV pool active or force that the CTV pool could stay active by switching the UTXO to a new one, but still basically have the tree of valid outputs for all of its participants stuck to it. [01:16:14] Speaker A: But yeah, you can do that with just ETV. There's everything has trade offs. [01:16:25] Speaker B: What's the trade off? [01:16:25] Speaker A: Yeah, if you just have CTV, the actual movement of the UTXO needs a standard signature on it, which means that signature has to be made for that specific UTXo to move it to the next one. That also includes the CTv tree. [01:16:43] Speaker B: Okay. You kind of have to have it already built down in the construction. You kind of already have to know where it's all going, basically. [01:16:52] Speaker A: Well, it'd be more like at the time, you want to move to a new Utxo for, like, you've got 100 people in this pool, and you want to move to a new UtXo that adds 100 in first person. At the time you want to do that move, you have to sign the route. [01:17:06] Speaker B: Okay? [01:17:06] Speaker A: Because that route has to be spent by a normal signature, which includes the Utxo in it. If you only have CTV, because you can't have predetermined that move, because you don't know who's going to want to join later. Potentially with Cig from Stack and CTV, you could have a pre signature that is valid as long as it goes to a compatible new place that's signed on the CTV. Again, there's annoying nuances in all of these things. The biggest thing, honestly, with adding checksig from stack is getting the rebindable channels, the lightning symmetry style channels. So CTV plus checks from stack gets you lightning symmetry channels and the kind of existing discussed payment pool type constructions, whether they be arcs or payment pools directly or channel factories. CTV alone does arcs and payment pools and channel factories and then checks it from stack. Get to the rebindable channels. [01:18:03] Speaker B: Gotcha. Question then on thinking about trade offs. Why do we want ln symmetry and why do we not want ln symmetry? [01:18:14] Speaker A: I think the people that don't want it are being foolish. Okay, but I'll lay out. I'll try to steal, man, what they say. [01:18:20] Speaker B: Nonetheless, we'll drop the opinion first. This is where our conclusion is going. Let's do it. We're going to. We're going to. We're going to Tarantino this. We're going to start at the end and then go to the. Go back to the. [01:18:30] Speaker A: Exactly. We'll do it backwards. So, yeah, so lightning symmetry channels. The benefit is that each party only needs to hold one piece of channel state for the duration of the channel. All they need to hold is the latest state that they want the channel to go to. So as we update the channel back and forth, back and forth, back and forth, sending funds back and forth, each of us is just holding the latest state we've seen, and that's the only thing we need to hold to successfully close. [01:18:57] Speaker B: Backups are easy. [01:18:58] Speaker A: Yeah, backups are easy, right. With existing lightning channels, most of your listeners should know, but we'll say it anyway. Each party has to hold a revocation transaction specific to each previous state. So as you're doing changes, you're like, I gotta hold this one and this one and this one, this one, this one. And you have to have a specific revocation for each previous state of the channel. There are some optimizations for that, where you can have only revocations for channels where your balance was lower so that you don't get screwed. But in general, you have to hold every revocation transaction for the history of the channel. [01:19:26] Speaker B: Yeah. [01:19:27] Speaker A: And so lightning symmetry just makes the backups a single, always the same size, always one final state. That's, that's the reason we want it. The other reason you might want it would be this symmetry aspect, which is, that has two benefits to it. One is it's symmetry, which means that both parties hold the same data. You can actually, if you have a channel partner who you trust a little bit, or you trust at the time you come back online, you can restore your channel from your partner to a correct and fully functional state. Even if your channel, you were offline for three weeks, whatever, come back online, your backups are gone. All you have is your seed. If your channel partners are nice and you trust them just a little tiny bit, you could say, give me the latest state. And if you're like, oh, yeah, I remember that. That's the right state. You're back online. You didn't have to do a close. You didn't have to like any weird, you're back. Whereas with a lightning penalty transaction, because the states are asymmetric, you can never get the correct revocation transactions and fully restore your channel state in the same way. Because your partner doesn't have the same state as you. They have a different. A different state, an asymmetric penalty state. The other benefit of the fact that it's symmetrical, or the or. And this is where the potential downside comes in, is that the incentives to not try and cheat are different. [01:20:51] Speaker B: Yeah. [01:20:51] Speaker A: Enlightening penalty. If you close a channel with the wrong state, not the latest state, your channel partner can sweep all the funds in the channel to themselves. You lose your channel balance to your partner if you close with an old state in lightning symmetry, because both parties hold the same final states. And if you publish an old state, we talked about this earlier, all the channel partner can do is correct it to the latest state. They can't penalize you. They can't take anything that wasn't ever theirs. All they can do is correct the state. So the lack of penalty I would consider a feature. But some of the folks who don't want lightning symmetry would consider that a worsening of the incentives around lightning. They think that channel partners will more frequently try to close with old beneficial states to themselves, because there's not a penalty attached because the only cost is. [01:21:43] Speaker B: A transaction fee, basically. [01:21:45] Speaker A: Right? [01:21:45] Speaker B: Yeah. [01:21:47] Speaker A: So that's why you wouldn't want it. Again, I disagree with that. I think we've already shown over the course of lightning's, what is it, six, seven years of being at least partially active? We've already seen that lightning requires a modicum of trust with your channel partner. Even in lightning penalty, your channel partner can. Can give you a pretty good screwing if they try to. Right. They can. [01:22:13] Speaker B: You're already locking up time and liquidity with them. And that's not a. It's not a decision that you just kind of make arbitrarily. You go and you select who you're connecting to. It's. It's. It's not trusted from a custodial point of view, but it's trusted from taking action and how your access to your funds in a certain time period, you absolutely are, because if they're not there, you're. You're out. You're out of funds for a week. You got to sit around and wait for this stupid forest close to. I'm not. [01:22:44] Speaker A: They can cost you some money and a lot of time. [01:22:46] Speaker B: Yeah, yeah. So I kind of agree with that. [01:22:50] Speaker A: And so because we've seen, like, originally, when lightning first came out, everyone was just, like, open channels to anybody. It's totally safe. It's not a custodial. It's. And people got hurt. And we've learned. And because of the. The way we've already learned about the properties of this network, again, as you said, you know, it's the one existing working layer two. So we've learned so much from it. And one of the things we've learned is that you have to have a certain degree of faith. It's, like, a little different than trust. You're not trusting them with your money, but you have to kind of trust them in taking actions, like you said, keeping their note online, just being a decent partner. And because of that, I think lightning symmetry is the more correct relationship. This is not a direct adversarial relationship where you need to penalize someone. It's a collaborative relationship where all you need to do is be able to correct if a mistake happens. And so that's the difference in thinking about whether you need to have that penalty or whether symmetry is really the more correct representation of the relationship that already exists. [01:23:45] Speaker B: Yeah. I'm curious. Do you know of a way, let's take the framing that this is actually a negative, to have to lose the penalty because you do change the incentives and there's certainly an argument to be made that, you know, that hasn't been a problem to date. And the. Anybody who's ever had to do a punishment, like nine times out of ten, it's a heart, a failed hard drive, or it's, you know, it's not. It's not someone being malicious. It's because there's been some sort of a mistake, and they're getting punished for no reason. Just because the punishment clause is the only thing the other person has, you know, that actually works. Well, in that same sense, you also have an argument that, well, that's because the lightning network works like that, because we have punishment clauses. So of course, we don't have a lot of examples of punishments being enacted because the incentives are there not to do it. So there's that element. But. Well, actually, before we go into the next thing, how would you address that if that seemed. That's a reasonable argument? [01:25:00] Speaker A: It's entirely reasonable that people might still sometimes use penalty transactions or, sorry, penalty channels. Adding lightning symmetry to the network doesn't mean that everyone has to use it on every channel. You can have a lightning network where this hop is penalty. This hop is symmetry, this hop is penalty. There's no incompatibility there. HTLC is route through either type of channel equally. And so you could have a network that's heterogeneous in that way. And people can choose which kind of channel fits their specific partner and negotiate, frankly, during channel open, which one is best suited. So that's, I think, one thing that people, people, I think have this, like, all or nothing idea about. It doesn't have to be all or nothing. It can be a mix. You know, my speculation is that it would end up being all symmetry because the benefits far outweigh the potential downsides to it. But if I'm wrong, that's fine. I think there are definitely a lot of places on the network where lightning symmetry channels just make more sense. If you're an LSP who has a relationship with people, they're buying channels from you. They're paying you to have a channel already. Symmetry channels just make more sense. It makes your client software for your customers simpler. It makes your kind of customer support simpler. If that customer loses their phone, all you do is close to the final state. There's no risk to it. It's just a better situation for those relationships. But maybe there are places where you want to be able to have a somewhat more adversarial channel where you want to have that penalty available to you and you open a penalty channel with that person. [01:26:29] Speaker B: Now, I'm curious, is there a way that you know of or that's possible without changing the UtXO? Granted, technically, you could change it with CTV plus css, but without changing it, you could actually have punishment. Have the punishment clause and the symmetry based on the conditions of the transaction. Like, let's say we're doing updates with 21 sats back and forth. 100 sats, a thousand sats. Well, I'm just going to do. I'm not going to. I'm not going to worry about signing a punishment clause or something for this one, but then 500,000 sats come through in a transaction. Let's sign a punishment clause for this one because this one's going to revoke a lot of the funds in this channel towards that other person. And if they use this update, like, basically, like a checkpoint system where every so often when enough funds have shifted in one direction or the other, which may be transactions right back to back, but sometimes it is 20 transactions before it actually gets to that amount where it's actually feasible. Like, I don't even know if that's technically feasible to do in the same channel, but is there some sort of a mutual construction that seems like a technically possible maybe? [01:27:52] Speaker A: I don't know of one. I am definitely not the best thinker about these lightning updates. I've learned a fair amount about it, but I'm not the one who would know these kind of things. There has at least been a proposal for a, um, sig cash any prov out based penalty style. There were some downsides to it that I don't remember the details of, and I don't know whether you could mix updates between plane symmetry updates and penalty updates within the same channel. It seems plausible that that could be done. Yeah. Like, so if you're. I. Like we said. Yeah. So if you're shifting a significant fraction of the channel's balance, your partner might not accept that update without you signing a penalty clause for them. Yeah, it seems plausible, but I would have to do a lot of script hacking to figure out whether it's actually possible. [01:28:40] Speaker B: Yeah, it might be. There's plenty of plausible sounding things that once you get down. Yeah. You have to close and reopen the channel to do this. So I don't think that's going to work. [01:28:50] Speaker A: Yeah. Another thing I've been thinking about is I think, and I can't 100% swear to this, but I think that without going on chain, I think you can switch a channel from penalty to symmetry, but not back. [01:29:15] Speaker B: Interesting. [01:29:17] Speaker A: I wouldn't, again, I wouldn't swear to that. There's some nuances in terms of whether those old states could become a problem. Yeah, but I. And I think what you'd have to do is you'd have to hold onto the state up to that point for revocation. [01:29:29] Speaker B: You would still need to maintain the. [01:29:30] Speaker A: Channel safety, but I think you could then switch it to a symmetry channel for future updates so you no longer have to keep accumulating penalties once the appropriate opcodes are available. [01:29:42] Speaker B: Interesting, huh? I have to look at that now. I'm really curious about that. But can you rebroadcast that with the same signature and change the amount that you have allocated for the fee? Maybe I completely just making that up. [01:30:03] Speaker A: I am struggling with the details of that. The biggest development that's happening around fees is really the ephemeral dust and truck transactions work that Greg Sanders and Gloria and Merch and all of them have been working on for a long time now. That's really as far as the biggest thing happening around channel fees. And it applies to both penalty and symmetry, where you, instead of having two anchor outputs and having to have the original transaction pay enough fees to relay, you can put all the fees into the anchor and have a zero fee commitment transaction which then gets pulled through by the anchor. I don't think the CTV or. Oh, that's what it was. Okay. Yes, it's coming back to me. Lightning symmetry using any prev out has the opportunity to do what you said, where the fees can be dynamically allocated, potentially because any prev out, you can use Sicache, any prev out sicache single where you only sign one of the outputs but not the other with the original signature. And then you can add an additional signature on additional input for fees into the one transaction. So instead of having to use an anchor output and then a new transaction, spending that in a single transaction, you can add an input for fees and change the size of the second output to adjust the fees because you have sole control over that second input and output. [01:31:28] Speaker B: Okay, gotcha. Yeah. [01:31:30] Speaker A: From talking to Greg about that. Given the mempool as it was, at least when he was developing lightning symmetry implementations, there were pinning attacks against that construction. And so he developed an example of lightning symmetry that did not have that feature where it used sigh any prev out sigh all and did not have that feature. If you're using lightning symmetry built with checksig from Stack and CTV, it does not have that feature because CTV always commits to all outputs. Gotcha that there's, as always, there's so much nuance. [01:32:06] Speaker B: This would specifically negate that. But because of a potential attack, not because of, you know, any, just, just because that actually needs to be. That opens up a problem as much as it opens up a benefit in that. [01:32:23] Speaker A: Yeah. And so currently the thinking is to use the ephemeral dust instead, essentially. And so the, the difference in total bytes used on chain between a single ephemeral dust anchor and using that other construction where you put the input into the actual commitment transaction with a second output, it's only a few bytes of additional space. I think it's like 15 or 18 bytes or something of extra total space to do the ephemeral dust style versus that. Is it more? Yes. Is it so much more that it's going to kill us? No, it's less than the fee cost of, or it's about the same. Fee cost is one signature. It's not a big difference. [01:33:05] Speaker B: Gotcha. Gotcha. Okay, interesting. So Peter's conclusion in his article was, and I thought this was a really interesting take and I hadn't quite considered this is to try to figure out how to get a. A go through the soft fork process just by doing something, quote, unquote easy, that let's do a consensus cleanup. Let's just kind of clean up these things that have been lingering for a really, really long time and make them unbroken or unbugged, so to speak, so that we don't have to work around them and then use that as a base to say, okay, well, this is how we may or ought to do a soft work when we actually want to do the upgrade. Like, what's your. What's your take on that? And actually, I'll just, we'll start there. What's your take on that? [01:34:06] Speaker A: Yeah, I'm totally fine with that. I, I hesitate to kind of say this is the path we, we should take. Sure, there's many ways we could go about this, and I said, I've said this before, but it's worth reiterating, I think that changes to bitcoin should be made when they're ready and well understood and safe and neither before nor after. So exactly when that's going to be for the contentious cleanup work, they're finding some nuances in even doing the consensus cleanup work that makes that work right now less ready than something like CTV. CTV, I would say, on its own is ready, but it's not ready in the sense that it doesn't give the benefits that some people specifically want around rebindable channels. So maybe it's not ready from that perspective. The point is we should just do these things when they're ready, not before and not after. And I wouldn't try to say we should do it in this sequence or that sequence. Consensus is a nuanced and ever shifting target. And I think we have to be flexible in how developing consensus looks and how soft forks look. We don't. It's funny that some people have. I had a brief chat with Luke the other day on X, and, and he's like, this is how soft forks have to look. You know, it's not a soft fork. It's. It's an attack. Unless it looks like this. [01:35:28] Speaker B: Yeah. [01:35:28] Speaker A: And it's fascinating to hear that, because we literally don't know. The last time we did a soft fork, bitcoin was a fraction of the size that it is today. [01:35:38] Speaker B: Yeah. [01:35:38] Speaker A: And to, so to assert that this is what it looks like, and none. [01:35:42] Speaker B: Of the soft forks have been the same. [01:35:44] Speaker A: Right? [01:35:44] Speaker B: They've all been different. They've all been different. Every single thing. The flag, the miner thing, the node thing, the time span, they've all been different. All of them just, they don't. There's no standard. And I completely agree. [01:35:59] Speaker A: It's. [01:36:00] Speaker B: It's a completely. We don't even know what this thing looks like. And that's the problem with consensus. Right? Like, it's outside of consensus. It's some totally different layer that we're trying to make a decision on, and it's a mess. It's really easy if you're just like, well, yeah, bitcoin works this way, but soft fork is not a part of how bitcoin works. [01:36:19] Speaker A: Yeah. And the thing that I think people have to get comfortable with is that at the end of the day, soft fork consensus will only be determined by game theory. And there's no, that's the highest layer. That's the layer that will make the final determination. It's not what bitcoin core puts in the code base. It's not what miners do or do not signal for. At the end of the day, it's going to be game theory that determines the outcome. I am not a game theory expert. I have some theories, some ideas about how it might play out. I've been posting about those recently. But the fact is, it is not whether the miners signal, it is not whether the nodes run this or that software, because these are backwards compatible changes. What's going to determine the outcome is game theory, and it's going to be who is willing to fight against this with their money, who is willing to. To rally kind of political opposition to this, who is going to publicly run bet their coins against or for a specific thing. You know, you can lock your coins in ways that are going to bet on one outcome or the other. There's all kinds of game theory that can play out in determining the outcome here, and I think people that have a very rigid idea of how software consensus is going to be reached are going to find themselves in a bit of discomfort. So I've been trying in my earnest way to put out there the idea that we do need to look at the game theory and look at it with an open mind of all the different strategies that players can use in that game theory to try and drive the outcome they're looking for. [01:37:56] Speaker B: Yeah, I'll tell you my personal subjective thinking on the strategy or whatever, I've always felt that like proposing a soft fork with, and making a client with something with those things that feel ready and then just giving it the longest time span that seems sober, that doesn't make you just go, oh, God, really? Like, literally like ten years. Give it a ten year flag day or some crap, and then somebody's like, oh, it says an attack. It's like, dude, it's ten. It's ten years. We like all of this. I'm giving you the time, all the time in the world. You need to hate on this, to contest this, to put it in a different client in a different way, whatever. I'm just saying, let's see what happens and set ourselves a timeline so that in the absence of anything, of all of the competition and all the caveats and all the attacking of it and everything, in the absence of consensus against it, so to speak, that the people who want to run that client can get it and they may still not use it. Maybe it's still only like 10% minor uptake and 15% node uptake. Well, nobody should use that because it's not secure. But there is an element, it's a soft work, it's backwards compatible. I could run a client right now with a soft fork and use it right now, day one. It's just that nobody, nobody's going to enforce it, you know what I mean? [01:39:38] Speaker A: You'd be risking your coins every time. [01:39:40] Speaker B: You raising my coins every time I use it. So part of me just thinks that to go about it that way, because it's a mixture of, listen, like, there's no, like, trying to convince someone that that's an attack. I feel like is is hard. You know, if, like, if I said three months right now and I'm just like, start calling all the miners and stuff, that feels like an attack. There's like, oh my God, I have to make a decision. I hate you. And whereas if you just give it such a gross timeline of like, nobody, like, this is just totally up in the air. But at the same time, we could start to plantain plan for this. We can start to build for it now. And it suddenly starts making sense. If you have 5%, 10% node uptake, it makes sense to actually make an investment to. All right, well, let's build out ark with it. And it's also, it feels like just the right amount of pot stirring at the same time to get people mad about it to start talking. So I don't know. I don't know. That's my brilliant master plan to get something. [01:40:51] Speaker A: There's a similar strategy that I think Shinobi was doing the last time around with Taproot, which is you can also just make a client that doesn't have an activation at all. It just starts enforcing it. You could make a client that just assumes Opcat was active or OPC TV was active from the beginning of time because there are currently no conflicting transactions. A client that enforces OPC TV from day zero of bitcoin is compatible with. [01:41:16] Speaker B: The, with everything that's already as it is. Yeah. [01:41:19] Speaker A: So forget activation, just turn it on. And that client, if people start running that and you could make it, since Peter Todd already wrote the preferential peering code for libre relay, you could make it a preferential peering network so that you can get a sense of how big that network is by preferentially peering. And you could just have it enforcing but not use it. Unless the nodes enforcing it become powerful enough that you trust it. You don't have to do a flag day, you don't have to do an activation. [01:41:44] Speaker B: Don't use this. Don't you. Don't use this right now. It's not an idea, but we're enforcing it. That's a good point. That's a really good point. [01:41:50] Speaker A: Now you risk forking yourself off if anyone publishes a conflicting transaction. So you don't want to be dumb about this. I'm not suggesting that this is a risk free thing to do, but again, the point of everything that you said and what I'm saying here is that this is nothing a, there's not a clear path. There's not a right way and a wrong way. People can do what they want. It's an. It's an anarchic consensus network. And people are going to take risks. Some people will take bigger risks and smaller risks. Some people are going to get burned. Some people are not. And let's be comfortable with that reality. We live in the world of bitcoin, where. Where game theory is going to rule. [01:42:25] Speaker B: Yeah. Yeah. Well, that feels like. That feels like a good. A good place to end. And I've taken a lot of your time already, dude. Thanks. Thanks for coming on the show. Thanks for sitting down and chatting with me about this. This has cleared up a lot of things that I've been desperately wanting to ask people on this. And it's really. Fuck. It's hard to find answers sometimes. [01:42:49] Speaker A: Yeah. I need to do more writing on that topic. It's hard to get clear answers, and I don't love consuming long form written content, but I know many people do. So I need you so that I know it. [01:43:02] Speaker B: I know a show. I know a show. [01:43:03] Speaker A: I'll tell you. Oh, yeah. You know what? Yeah, I've listened to plenty of audiobooks. Thank you. [01:43:11] Speaker B: Oh, man. [01:43:12] Speaker A: Thank you so much. Great chat. I love to get this stuff out there more and. Yeah. Love chatting. Thank you. [01:43:17] Speaker B: Any final thoughts? What's. If you wanted to sum it up, or was there something that you really wanted to add that never felt right? Give me your final words and then I will shoot you and we will close this out. [01:43:33] Speaker A: Yeah. I would say my final word is for all of us to continue working on setting aside our emotional reactions to things and focus on understanding things deeply. Let your emotions follow your understanding. And I think we can all have better conversations that way. And I struggle with it as well. So this is not a throwing stones or whatever. It's something that we can all work on and learn and kind of develop a better bitcoin together. [01:43:59] Speaker B: I like that. That's a very earnest and sensible thing to close out on. So amen. Amen to that. All right, man. Well, thank you again. And I'll have details and everything in the show, notes to follow you. If you do any writing on this, always send it my way. I'm around. Do that. I do a thing called reading quite a bit, so let me know. [01:44:23] Speaker A: Sounds great, man. Thank you. [01:44:25] Speaker B: Thanks, boss. All right, that wraps up our conversation. Another shout out to readencode. For doing this, for answering the questions, and for great input and also just fantastic work. I always appreciate being able to get into these issues and get a lot of answers all at once and from someone that I feel is giving an honest perspective and is trying their best also to be objective and to account for where they are obviously making mistakes as I often make mistakes and have a completely false or very shallow view of things going into them. So that's just something I really appreciate. And it's always good to have those people to lean on for conversations like this that often get difficult or obnoxious in Twitter land and social media. With that, don't forget to check him out. Don't forget to follow him. If you don't, you're very much missing out not only for his earnestness, but also his occasional pot stirring. And I will have links to socials in pubs, all those good things so that you can get up with and follow him if you would like, right down in the description of this show where you will also find our sponsor who supports the show and also keeps my bitcoin safe, the makers of the cold card hardware wallet and there is a discount code and there is a special link and you can let them know that I sent you and you can keep your bitcoin safe and you can actually own it. And all of those are good things. Like there's nothing, that whole list was just nothing but great things. So you should do it and you should check it out. And then of course a last shout out to the audio knots and everybody who boosts and leaves comments on fountain and zaps me on noster. Love you guys and I will catch you on the next episode of bitcoin Audible. And until then, everybody take it easy guys.