{ "episodeId": "SLP573", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "brandon_black": { "name": "Brandon Black", "role": "guest", "tag": "BRANDON" } }, "segments": [ { "speaker": "stephan", "time": "00:13", "start": 12.69, "text": "Hi everyone, welcome back to Stephan Livera podcast brought to you by Swann dot com. Today I'm chatting again with Brandon Black aka Reardon Code who, has just come back from BTC++. so Brandon, welcome back to the show." }, { "speaker": "brandon_black", "time": "00:27", "start": 27.12, "text": "Thank you so much. I'm glad to be here, and it was a great conference." }, { "speaker": "stephan", "time": "00:30", "start": 29.72, "text": "Yeah, so let's talk a little bit about it. Let's first set the context. Obviously, you've been, you know, wrangling, about in, in and amongst some different Bitcoin proposals to bring covenants to Bitcoin. Obviously, you have your proposal, which is LN Hand, and there's some other ones in the mix, so do you wanna just kind of set the context, you know, what was happening before you got to the, the conference?" }, { "speaker": "brandon_black", "time": "00:52", "start": 51.75, "text": "Yeah, it seemed like Two that were kind of in, in front running had the most mine share, probably OpCat was one of the ones that had the biggest mine share, going into the conference, and then somewhere, somewhere behind that there was Ellen Hance and maybe CTV, those were kind of in the mix as, as top proposals for adding covenants, TXHash also maybe, and, and each of those has different trade-offs they make. For example, Ellen Hance is only has one hashing mode, included in the CTV hashing mode, Whereas Kat enables you to check any part of a transaction because of the, the generalized covenant that it ena- it enables. And there was a lot of discussion about whether, one hashing mode is sufficient for Bitcoin, whether that would give us the expressivity that we want to build these layer two protocols that everyone really thinks we need to scale Bitcoin. And so that was really where the discussion was going in. Arguments on both sides were pretty strong." }, { "speaker": "stephan", "time": "01:44", "start": 103.73, "text": "And so I guess if you could spell out for people where some of the disagreements were, like as I, as I'm understanding it, some people had View of CTV is too minimalistic, right? In their view, they wanted more, more power, more firepower per se. There are other people who maybe might have a concern about what these things are turning on. As an example, does OP_CAT enable, OP_CAT combined with some other things, would that enable drive chains and does that centralize the miners, right? Like, these kinds of concerns. Can you just spell out for-- and I guess the other kind of the OG concern might just be, how do you restrain the thing? Because, you know, the for the se-for the reason OP_CAT was taken out to begin with, for that reason. So if you could explain some of the different camps, some of the different concerns that people had." }, { "speaker": "brandon_black", "time": "02:33", "start": 153.22, "text": "Yeah, yeah. So I think on the CTV being too minimal side, many, you know, high-profile Bitcoin developers have this concern that I think is, there's some validity to it. It's not my concern, so I'll just try to express it as steelman as I can, that, with CTV-based layer twos, you're always gonna have to add the fees in a separate transaction for closing out a channel that's based on CTV or for, exiting unilaterally from a layer two using CTV, you're always gonna have to bring the fees separately. Someone's gonna have to have a separate UTXO to bring the fees. Whereas with some of these more, flexible protocols like OP_CAT, they can express, they can be Here as to this part of the transaction, of one transaction, is for the exit and that part is fees. So a single transaction can do the exit from the protocol and bring in the fees. So that's kind of the concern about CTE being too minimal, at least that's the main one that I've heard. Then on the, on the flip side of C- or of CAT being kind of too expressive or doing too much, exactly as you said, there is this, there has been historically at least, this concern about, quote, \"CAT enables drive chains.\" one We've recorded spaces, discussing this specific problem with the likes of Post Capone and, and Shinobi on X over there. and, and to briefly summarize that What we seem to have co- come to is there is a difference between drive chains enabled by BIP 300 and 301 versus drive chains that kind of come along with OP_CAT. and the difference is whether you say, \"Here's this thing you can do, hash rate escrows, \"and it's included in the base Bitcoin protocol, versus \"Here's this thing you can do, hash rate escrows, \"and it's applied to one UTXO that some people chose to lock in this way. \" And that is a, we, we think now a pretty fundamental difference. And so I, I think it is, I've now come to think that it's important to separate drive chains, as in Bitcoin three hundred three one, versus hash rate escrows Or Upcat or Check Contract Verify, probably even TXHash, although I'm not positive, many of these enable hashless escrows, but they're not Bit three hundred, and so that, that is a difference," }, { "speaker": "stephan", "time": "04:48", "start": 287.63, "text": "So actually, could you just spell out why, why does that matter? Like, why does it matter what it's called, right? Like, just for, for listeners, they might be thinking, \"Why do I even care?\" Like, does it, is it just enabling the same thing?" }, { "speaker": "brandon_black", "time": "04:58", "start": 298.44, "text": "Yeah, so the, the difference is that if you, if you do Bitcoin 300, you're saying, \"Here's the way to peg funds in and out of side chains is hash rate escrows.\" Whereas if you enable OP_CAT, you could do hash rate escrows, but that would probably be the least effective way to peg funds in and out of a side chain. And so you would expect, and we talked a lot about this a lot in Austin, that side chain designers would, would make some way other than hash rate escrows to move funds in and out because hash rate escrows are user hostile. It takes thirteen thousand blocks or, or whatever the number exactly is, to get funds out of a hash rate escrow based side chain. There are many better ways to move funds in and out of side chains that are much more user friendly. And so hash rate escrows could be problematic if they became the dominant way that many people move funds in and out of a side chain, but if they're just like a, you know, a side play A few people use it, they're completely irrelevant. And that's why it matters whether it's in the drive chain, BIP three hundred, where it's a part of the block includes this hash rate escrow commitment every single block, and that's gonna mean that many more people are gonna use it versus, oh yeah, some UTXOs over there, they're doing hash rate escrows, and no one cares. That's a very different situation." }, { "speaker": "stephan", "time": "06:11", "start": 370.65, "text": "Right, well, thank you for explaining that. and, were there any other camps? Like maybe there are people who just wanna, you know, just use script as we have today, and that's, you know, that's it." }, { "speaker": "brandon_black", "time": "06:23", "start": 383.0, "text": "Not in Austin, Texas. I didn't hear a single person who was like, \"Script is fine the way it is.\" And in Austin, of course, it was a very developer-focused conference, and, and so the folks who were there are, are kind of not your general Bitcoin audience, you know, very" }, { "speaker": "stephan", "time": "06:35", "start": 395.24, "text": "developer-focused. Did the conversation evolve? Right, it sounds like there's, you know, just from judging from your posts as well as some other discussion from what I'm hearing from people, there seems to be a lot of excitement around You know, great script restoration, which I guess is part of related to what Rusty was talking about. So if you want to just spell out a bit around that." }, { "speaker": "brandon_black", "time": "06:59", "start": 419.47, "text": "No opcode left behind. No." }, { "speaker": "brandon_black", "time": "07:04", "start": 423.69, "text": "Yeah, so that was, that was a, a pretty crazy time. I, I went into-- we had kind of this, this Covenant's pre-summit, the day before the actual conference when, when Rusty did his talk. And I went in thinking, \"Oh, this is gonna be way too ambitious. It's gonna be too much,\" 'cause Rusty had mentioned that in some context, you know, that this was a thing you were gonna present on. And as he was talking about it, what I, what I kind of realized is that he was right. We've been in the situation of debating which little pieces we wanna change and upgrade for, for years now basically, and that's because we've fundamentally framed the problem wrong. Instead of framing the problem as, \"Let's engineer the best future Bitcoin we can have,\" the problem was, was framed as, \"Let's try to get any minimal change we can to move Bitcoin forward.\" And that different framing of best Bitcoin we can make versus anything we can possibly get is very important. And, and Rusty immediately set that, that framing difference in, in the conversation, the day before the main conference. And so with that conversation, you know, we drew up on the, on the whiteboard all the different options we had out there. You know, we listed like, you know, let's just do just CTV or just CAT or just this. Let's do a few opcodes like Alan Hance does, the Great Script Restoration, Simplicity The way off in the other room. so, so we had this whole line of possible things that we could, we could do, and the more we talked about it over the course of that day, we, we kept coming back to something along the lines of great script restoration is really where we have a balance of all the existing tools we have for using Bitcoin, for making Bitcoin scripts, they work with re-restored script, and, and one of the ways I put it was, we really want developers building on scripts not to feel sad every day when they, they try to build something using script and and so that's really where we came to this great script restoration, and, and, and there's still lots to work out about it, just to be clear, like this isn't a, a concrete ready-to-go proposal or something. it's just this, it's more of an idea of we want to engineer the best Bitcoin script that maintains compatibility with all the tools, that is resource safe, it doesn't hurt nodes in any way. You know, like one of the most important things was we're not gonna increase validation cost beyond what it could already be today, and that's a really important part of any script upgrade." }, { "speaker": "stephan", "time": "09:24", "start": 564.34, "text": "Okay. So let's just walk it back just one tick and just explain great script restoration. So what is great script restoration?" }, { "speaker": "brandon_black", "time": "09:33", "start": 572.9, "text": "Yeah, like I said, it, it's more of an idea than a concrete proposal. some things are, are clear in it, that the, the, the idea behind it is to make script back to what it kind of originally was, with knowledge of the intervening years, right? So obviously it's not gonna be exactly the same as what Satoshi pub-published in two thousand and nine, because that was broken, but we're gonna make it as much as we can like that with all of the intervening knowledge. So bring back the opcodes that were disabled for the CVE in But with strict resource limits. Bring back variable length integers. Original script, I, I learned this at the conference, had variable length integers, but we don't need negative numbers, so we can simplify all of the variable length integer handling By using just, whole numbers, zero and, and above, because in Bitcoin scripts, being a validation language, there isn't a need to go negative. Negative is a failure mode, and so you just fail when you have negative numbers. whereas in a general purpose programming language, you need negative numbers, you don't in Bitcoin script. So, so variable length integers, whole numbers, not integers, bring back the opcodes, and then because bringing back the opcodes includes op cat Which gives us, as you've probably heard from others, you can inspect any part of the transaction, but it takes twenty cats to do so. so OpCat is, is very powerful and interesting, and it makes scripts that are both large and difficult to reason about, also add introspection in a nicer way. and that's basically the contents of OpCat or of, sorry, of, great script. There's one more thing, which is in the intervening years we added Taproot And so before Taproot, if you had introspection, you could define a new output in script, but Taproot, to define an output, you have to do this operation called tweak add And so we wanna bring back that functionality as well that old scripts had, of, of being able to contraint, constrain an output. And to add that, we have to have OpTweakAdd or something similar. You know, the, the exact details again are not clear, but something like, like OpTweakAdd needs to be added as well." }, { "speaker": "stephan", "time": "11:36", "start": 696.31, "text": "So let's just try to, again, make sure it's accessible for people. So the- I guess the way I'm understanding it is there was this early CVE vulnerability, and that's what basically caused Satoshi to basically turn all of these things off, right, to try to-- It's like twelve or fourteen episodes," }, { "speaker": "brandon_black", "time": "11:53", "start": 713.23, "text": "yeah." }, { "speaker": "stephan", "time": "11:54", "start": 714.17, "text": "Right. And this is like, I don't know, twenty ten or something, like super early. And ever since, it depends on how you view it. S-- you know, some people, I guess, have argued that, \"Oh, it's a good thing that Bitcoin is restricted.\" And other people saying, \"No, actually, there's all this capability, there's all these extra things that we could build, and now we're starting to bump into the limits, right?\" So I guess that's kind of where-- I presume that's where most of the developer types are coming from because they have, that we don't have now because of what happened back in twenty ten, and that's where this kind of context is coming, and so am I accurate there or how would you, is that right?" }, { "speaker": "brandon_black", "time": "12:34", "start": 754.26, "text": "Yeah, I think that's right. And, and you know, we've, we've spent the last, whatever it is, fourteen years building without these things, and we've been able to make huge progress. You know, we've got these great mini script wallets, we've got, you know, powerful multi sig contracts, we've got Lightning, all this stuff has happened, and now we're, we're kind of remembering what was written in the original Lightning paper. I think we talked about it last time on your show of, you know, it, it would take 133 megabyte blocks to get everyone on the Lightning network. And that's a very optimistic number, even. And we're obviously not going to make hundred and thirty-two megabyte blocks, we know that for sure. So we do want to let more people use Bitcoin in a self-custodial way, and now here in twenty twenty-four, we have all these different designs for doing that, and all of them, with the possible exception of BitVM, although I, I, I'm skeptical there, require some improvement to Bitcoin. And so that's why we had this horse trading thing going on, this opcode for that layer two, or this opcode for that layer two This important difference also of the how versus the what. It matters how we get these things. We should be engineering the best way to get them, not focusing on what is enabled by this specific opcode. So like, CTV gives us payment pools, APO gives us lightning symmetry, Cat gives us CatVM, that's the what, but the how matters. And so engineering a good script will then enable all of these things because we engineered it well, and that's the how. We engineered well, and then all these things happen because of the good engineering." }, { "speaker": "stephan", "time": "14:03", "start": 842.89, "text": "And so I'm curious if there was any more, let's say, conservative voice in the room or someone who's kind of more like, \"This sounds kind of like you just want to turn on the whole world, right?\"" }, { "speaker": "brandon_black", "time": "14:13", "start": 852.96, "text": "There wasn't really, you know, different people voiced different concrete concerns and then they were, they were addressed in, in various ways. One, one, my personal voice in, in this conversation, was that incrementalism might make sense here. We have, with the great script restoration, we have a good idea of a destination. We want to restore script functionality so that Bitcoiner, Bitcoiners who are developers can be happy while working on script, they can accomplish the things, the designs they want. And then with that destination in mind, we can look and say, \"We know for sure that restored script is going to have this. Why don't we do that now as, as the, as the next step toward that destination?\" And of course, in, in all software projects, when you do those steps, some of them are gonna be right and some are gonna be wrong. It's okay to, to make a concrete step that's not the exact right one, and then when you do the actual script restoration, you maybe swap it for a slightly better piece that could fit in that place. And so with maybe a little bit more incrementalism. But then, I mean, the counter to that is fairly compelling in that then we'll be back to horse trading. What's the right first step? Where, where, where again, a-as much as it sounds like kind of a lot, I think a good way to view script restoration is, is as, this is the small step. It's a much, much smaller step than Taproot or SegWit was. They, those, you know, SegWit kind of resolved some long standing issues with transaction malleability and the cost of spending versus the cost of creating UTXOs. Taproot resolved the long standing problem of scripts having to be fully revealed when you, when you spend, and then we have a long standing problem of script being hard to program in because of those opcodes being removed. Let's keep resolving chunks of this problem that Bitcoin has, of, of limited limitations Bitcoin has. Let's keep resolving them in chunks, and maybe script restoration, it's- Just the new script version. It's not a new witness version, it's not changing the block layout, it's, it's, it's still dramatically smaller than Taproot or SegWit in terms of block radius." }, { "speaker": "stephan", "time": "16:21", "start": 980.88, "text": "And in terms of, let's say the accelerators or the accelerationist people who like, you know, I'm sure there'll be some people who are like, \"No, we needed...\" CTV yesterday, we needed it two years ago and it's already too late. do you have any thoughts on that kind of idea? Now, I, I personally don't hold that view, but I'm curious if you have any thoughts on that view, 'cause I know there's people out there who believe that." }, { "speaker": "brandon_black", "time": "16:44", "start": 1003.91, "text": "Some of them are, are my friends, yeah. Oh man, it's such a hard thing. The, the frustration that people feel working on Bitcoin, I know how, how real that is. It's a consensus network. That's not something that, like, changing a consensus network can't be taken lightly. It can't happen the way you want. You, you have to, to be successful long term Bitcoin, you really have to take a step back and, and look at the The, the weird organizational and structural things that go into building a consensus network. And so I certainly feel some of that. I mean, I get very excited about things as well, you know, my own idea that the Ellen Hansen combination And I think what I would say is read the room and see where people are excited and, and where you can get the activation energy needed to change a consensus network. I'm not I can't say for sure that great scriptoration is going to-- great script restoration is going to be that, but I think it has the potential, it has the right mindset, again, this mindset of engineer the best thing, I think is a, is a much better starting point of how to, to upgrade Bitcoin than How do I get anything into Bitcoin? You know, I'm gonna, I'm trying to push through anything, which is kind of the mindset some of the accelerationists have. Better to focus on, let's engineer the very best thing we can." }, { "speaker": "stephan", "time": "18:00", "start": 1079.84, "text": "Yeah, I see. And a-as I'm sure you saw, AJ had a really cool blog post called \"Slow and Steady,\" kind of with this idea of team, team, team slow and steady, right? This idea of when it's ready, you know? And I mean, there's some logic and reason to that too," }, { "speaker": "stephan", "time": "18:37", "start": 1117.13, "text": "and so, y-y That's gonna necessarily push things out, you know, it's gonna be a longer timeline before any change happens, and that, and that also means you have to be comfortable giving something up, right? Like if you're really for something, you all-- it also means like, what are you comfortable giving up, right? In order to be slow and steady, you can't move as fast, and that means, hypothetically, if there's a big fee event, let's say there's some big fee spikes At that point, there's not gonna be a lot that people can do other than use custodial things, right? Like Fedi, Mint, or Cashu, or Federated, you know, whether it's Liquid or some other-- they're gonna, or custodial exchanges and wallets, they're just gonna have to use custodial, and that's just gonna have to be kind of like, everyone's gonna shrug and say, \"Look, sorry, that's the trade-off, that's the, that's the choice we made.\"" }, { "speaker": "brandon_black", "time": "19:30", "start": 1169.92, "text": "Yeah. And one more thing I'll say with that There's, there's a, a, a quote from a, a, a not-- Well, I love it. A movie I, I loved as a kid anyway, called, I think it's called Days of Thunder. Slow is smooth and smooth is fast. When you get a bunch of people pulling together, as opposed to this horse trading, I think people may be surprised at how fast things come together. I don't know for sure, 'cause I don't know how much time each individual's gonna have to work on something like the great script restoration, but I think people might end up being surprised at the, the way the timeline shifts When you get people pulling together. And so I think that's really what I'm, what I'm looking at here, and kind of again, organizationally, we got all these people. And, Lisa Nifty did an amazing job bringing people with representing, I think she said she got every single opcode that's been, concretely proposed in the last several years, she got every single one represented in Austin. And we got all of us together in one place, we all talked about this, and You know, with minor details, we all ended up pulling together by the end of the conference, and that's something that can really fundamentally change the, the environment for moving forward." }, { "speaker": "stephan", "time": "20:39", "start": 1238.72, "text": "Okay, so the other question I'm sure some listeners will have is kind of like, why do I care, right? They'll just kind of be a, a, a point like, a-and, you know, that point has to be answered, right? They'll say, \"Look, all you developer guys, you're super into this, and you wanna code this all these different projects, and why does the everyday hod Yeah, as opposed to, let's say, the three hundred most engaged Bitcoin developers, some, you know, loosely." }, { "speaker": "brandon_black", "time": "21:05", "start": 1264.77, "text": "Yeah, a-and, and the answer is we, I think all of us in Bitcoin-- Well, I shouldn't say all, most of us in Bitcoin, whether developers or not, have this belief that everyone should be able to hold their own keys, and I think that is really why to care about these projects, whether they be Ellyn Hance or Kat or Script Restoration. We want people to be able to hold their own keys long into the future, and the way Bitcoin is right now, that's just not possible for more than, you know, I don't know how many people are holding Bitcoin of their own right now, is it maybe one or two million? so we can ten x that, but, but that's the limit, the-- and that's like the absolute limit of Bitcoin as it is today. And we want, we want much more for people. We want people to be able to hold their own keys. That's why, that's why I should" }, { "speaker": "stephan", "time": "21:50", "start": 1310.5, "text": "Yeah. Although, I mean, I, I think the numbers could be quibbled with a little bit, right? I was talking with, actually, I don't wanna dox this individual, but I was talking with somebody offline, and I sort of said, \"Oh, yeah, maybe it's like ten to a hundred million, like, like we were talking about, like you and I were talking about.\" And he had this idea that, \"Wait a minute, actually, it could be more than that, but not regularly transacting. It could be kind of like if you Hold some coin, but not necessarily be regularly spending, and so, but of course, you know, in fairness, that wouldn't be the vision of like everybody can spend and receive and regularly use Bitcoin. It would be kind of more like everyone's holding, right? Everyone's just kind of the digital gold or the super gold use case, so I'm curious what you reckon about that, like- Where you think, do you think that's a, you know, in terms of numbers, is that reasonable?" }, { "speaker": "brandon_black", "time": "22:50", "start": 1370.35, "text": "I, I don't, I, I can't imagine treating something as money where I can only move it to or from my, my self custody once every few years. That's not money. That, at that point, that's, that's a A crappy collectible, like it's not-- it's no, it's no longer really interesting to me if that's the only way I can use it. so that's certainly not what I want for people, and not what I want for myself. And, and yeah, what we'll have then is that most people will keep most of their Bitcoin on custodial services so that they can use it. And yeah, they might stash away like the under-the-mattress backup amount, but, but most of the Bitcoin that's being used is gonna be on custodial services then." }, { "speaker": "stephan", "time": "23:30", "start": 1409.89, "text": "I see, yeah. And I guess that's the other big, kind of exciting thing people had kind of going into it, they were kind of just like, \"Oh yeah, eCash, you know, just, everyone just use eCash, right?\" And I'm sure you've seen that perspective, people like maybe Alex B or others might hold that kind of view of like, \"Oh yeah, what about just eCash?\" Although even, I'm sure that view changed during the conference also." }, { "speaker": "brandon_black", "time": "23:50", "start": 1430.16, "text": "E-Ecash is great. I, I love, I'm a long-term E-Cash maximalist, let's say. I think that this, this idea of custodial mini-banks that, that facilitate exchange using, you know, connected by the Lightning Network is very compelling. Not everyone, not, not literally everyone is gonna wanna hold their own keys. And especially even people that do hold their own keys for their savings account, and let's say they transact on that 'cause it's kind of, kind of expensive even in the future, maybe they, they transact monthly or weekly, they're still gonna have their daily expenses in something like eCash. I, it is my guess. I mean, every, you know, we're speculating about the long future here, but, you know, guessing, I could certainly imagine that. So I'm, I'm, I love eCash, I love the blinding, I, I love a lot" }, { "speaker": "stephan", "time": "24:39", "start": 1478.63, "text": "Try to make some of these ideas a little more, let's say, tangible for listeners. Maybe if you could explain a little bit about some of the ideas that you're most excited about in terms of like end user- Products or protocols that they may actually interact with. Is it things like, you know, LN symmetry? Is it ARC? Is it some kind of coin pool protocol? Which of these do you see as, or maybe some kind of more advanced vault construct that people can use for their ho-- for their long-term hodling? What uses do you see as the most-- Because I guess one thing is we're talking here what can be seen, seen as an esoteric developer level, right? Like, oh, get this scripting enhancement here, and you can like- Like shift it left or shift it right here, and, and it's not, it's not at all, compelling to an end user 'cause they're like, \"I don't care about shifting left or shifting right, I don't care about adding, concatenating, what does that mean to me, right? \" But actually, the end result of being able to do those little operations is that more people can use ARK or LN symmetry or something like that. So if you could just spell out a little bit in that, if you could elaborate a bit on that." }, { "speaker": "brandon_black", "time": "25:49", "start": 1548.78, "text": "Yeah, no, it's a great question, and someone asked me the same thing on, on X the other day, yesterday. Yeah, we have to sell this to users. Users don't care about this stuff, and, and the fact is that, yeah, it's true. Everything in Bitcoin that we build at the protocol or script level is, is developer focused, and then the developers have to say, \"Here's the products I can build to sell to And you, whatever we do here, whether it's Ellen Hertz or Grace Cup Restoration or Kat, are Vault and Symmetry channels for, for Lightning. So, so briefly, you know, Vaults are the idea that you can have reactive security for your Bitcoin. So your key is compromised, and then you have a chance to respond before it can possibly go anywhere other than where you specified. And that's, that's a really powerful tool, 'cause right now, there are ways to get a little bit of responsive security, but it's, it's always-- and you lose ten percent of your Bitcoin or something, which, which like, using something like SeedX or with the Cold Card, where you, you have, two seeds that come together to make your final seed, you can put some real Bitcoin on the two partial seeds, so if those get compromised, you know they've been compromised, and then you can move your main stash, right? That kind of reactive security" }, { "speaker": "brandon_black", "time": "27:04", "start": 1623.52, "text": "Ellen Hance, or whether you do OpVault, or whether we do great script restoration, any of those give us this reactive security or cat, I should say, you know, all of these have that ability. So that's one of the very important things that basically all of these options that are being actively considered give us some way to build pretty good reactive security vault type things. So that's a big one. and, and what's funny about vaults is In the long term of Bitcoin, we're talking the, the fifty year vision, vaults will be mostly used by custodians to protect your Bitcoin when it's with a custodian. but even that is very compelling to me. I, I want-- I don't want custodian hacks to lose my Bitcoin and have to go to an insurance fund or whatever. I want my custodians to have better security and I'll vault or, or, or vault type things enable that so it's compelling for end users right now and then custodians in the very long run. And then, yeah, I mentioned symmetry channels or lightning symmetry. This is kind of an interesting one. I, I was actually talking with Christian Decker about this, 'cause he's kind of one of the original authors of, of the idea of L2 and Lightning Symmetry. And, and we get so focused on the two party Lightning channel with Symmetry, because that's what we have today. We have this Lightning routed network where each channel is two people, and then you can route across these two party channels. and part of the reason that Lightning is this two-party thing is because with Lightning Penalty, it's not impossible, but impractical to have more than two parties involved in a channel. With symmetry channels, it's much, much more practical to have more than two parties in a channel. So the immediate benefit of symmetry channels in the Lightning network is that if your node crashes and you restore from a ba-- an old backup, There's no chance you're going to lose all of your funds. The worst thing the channel partner can do, if you publish an old state, is update the channel to the correct final state. So that's like the, the big end user selling point for a Lightning end user who runs their own node is You ha- you don't have to be as obsessively paranoid about your backups because the most likely outcome of a bad backup is just that the channel state gets corrected on chain. Oh well. but also the, the, the Lightning Symmetry channels are what, what are called rebinding. Which means that they can move funds among multiple parties, they can, they can shift outpoints while the channel being active. There's, there's lots of stuff about symmetry channels that makes them easier to use for more advanced constructs. And I think that's something people forget, whether it's multi-party or channel factories or, et cetera, et cetera, et cetera. When your channels are rebindable, they become more powerful. So, so that's another thing that's very important to end users, is, is, is that Because it's not just Lightning symmetry, it's symmetry channels that can be used in other ways as well. And then the last thing, yeah, these, these multi-party protocols like ARC or timeout trees, et cetera." }, { "speaker": "brandon_black", "time": "30:04", "start": 1803.54, "text": "It's so hard to predict the future on these, and I think this was really actually one of Rusty's other core messages. We can see the things people are proposing right now based on certain concrete opcode they're proposing, but we shouldn't say, as the developers of the Bitcoin protocol, we shouldn't say, \"And that's the future that we are going to kind of build for.\" We should instead be building a Bitcoin protocol that can be used for any of those and more that we can't even imagine right now. So I can't really concretely predict one of those. I did have the cool experience of, Tierra sending me some ARK Bitcoin on, on Liquid, and that was super cool." }, { "speaker": "brandon_black", "time": "30:41", "start": 1841.48, "text": "So, so the fact that ARC is becoming more real, it's awesome. And I, I-- So, yeah, I don't wanna predict what the future is there, but I can say that something like these, these many party UTXO sharing protocols that make- Certain trade-offs to let people hold their own keys while mitigating on-chain fees is gonna be incredible, and I don't know exactly what's gonna look like though." }, { "speaker": "stephan", "time": "31:04", "start": 1863.89, "text": "Back to the show in a moment. Swan dot com is the leading place to buy Bitcoin, and the Swan team has a mission to onboard millions of people into Bitcoin. Now, the team have been working really hard to update the Swan Bitcoin app, which you can find on the Apple App Store or the Google Play Store. So the team have created created a really slick and smooth experience, so now you can go from zero to Bitcoin in just a few minutes. So if you have family and friends who you are struggling to get them onboarded, well, Swan Bitcoin application is a great way for you to help them. You can be standing there, right there with them, and in just a few minutes, they can have been onboarded and be buying Bitcoin. And Swan are making it really easy to do this because now there's zero fees on the first ten thousand dollars of Bitcoin buys. You do, and it's not just for new customers, it's also for existing customers. So remember to tell your friends and family to go to the app store and search Swan Bitcoin, install the app, and get started with Bitcoin with Swan Bitcoin. CoinKite dot com are my favorite providers of Bitcoin hardware security products. Now, when it comes to securing our Bitcoin, as we say, it's not your keys, not your coins, and you need to learn to use some of these different tools to help create your private keys offline and then keep your private keys off Offline, and that's where some of these devices like the Coldcard Mark IV or the new Coldcard Q device can come in and help you, because they can help you create your private keys offline. You write down your twelve or twenty-four word seed, and that helps you interact with the Bitcoin network in a self-sovereign way. And so you can use these devices easily with software such as Sparrow Wallet or Electrum or Specter or Nunchuk as a few examples. Now, the really cool part is that you're keeping the private keys offline. Because you're signing in an offline way. So if you're a beginner, yes, you can just directly plug it to the computer, but you can use these devices also in an airgapped mode. So for example, the micro SD card, which is available on the Mark IV, or you can also use micro SD cards on the Coldcard Q, and the Coldcard Q also has an extra way, which is this QR code, so you can scan, and read it back that way, and do your transactions also in that fashion. So there's a range of different features But you can just start basic with a single signature hardware wallet, and then later think about, okay, do I wanna do a passphrase? Do I wanna use bip85? Do I wanna use seed x or do I want to use multi-signature? So these are all some of the things that are available to you. The Coldcard and CoinKite team are always innovating and putting out new products. They have a range of different products. For example, the TapSigner is a cheaper device for those people who want a specific, different kind of UX that's also there. They also have For you to backup your seed words in a metal product. So there's all kinds of products there. Go to coinkite dot com to get yours and use the code Livera for a discount over at coinkite dot com. This show also brought to you by Nomad Capitalist. Nomad Capitalist is a service that can help you in terms of going overseas, lowering your taxes, getting a plan B residence or citizenship, or perhaps even a plan A citizenship or residence. Now, as many of you know, I left Australia for a few reasons, taxes The COVID tyranny and other aspects of, you know, the wokeism, but with Nomad Capitalist, you can find a way to choose an alternative. You can go where you're treated best, as Andrew says. So there are dozens of countries around the world that they work with, and you can consider which are the correct countries for you by working with the team, and they can help you understand what are some of the different options, what are some of the citizenship programs out there, what are some of the residence programs out there, how do you make it work, how do you get a fiat bank? As well for those of you who, who need fiat banking in different countries, I think it's just a, a holistic service that will help you understand how to put the different puzzle pieces together. As you know, I'm in Dubai, but I'm not saying, you know, Dubai is the one size fits all that everybody has to go to. If you go with Nomad Capitalist, they can help consult with you as they are experts in the field, they've been doing it for over ten years now. They can help you consult on where the pieces and how, how to put those pieces together importantly That is, suited for people with a liquid net worth above one million USD or those of you with a high income. But if you go to nomadcapitalist dot com slash apply, you can find out more about how to, use this service to improve your self-sovereignty and to potentially lower your taxes and gain access to some of the benefits of going overseas and living overseas. This show also brought to you by Mempool dot space, the leading Bitcoin and blockchain visualizer. I use it all the time. To keep an eye on what's happening in Bitcoin's mempool, to keep an eye on the fee rates in order to get into the next Bitcoin block, of course, you can search Bitcoin transactions and see all kinds of information. They have all kinds of ways to visualize important information, whether that is the RBF history of a particular transaction, the replaced by fee history, or looking at what's going on in the mempool in terms of, transaction fee rates. Now, for those of you interested, they have a mempool enterprise program if you're with a company And you wanna support Mempool.Space, they've got various options including support for things like a co-branded Mempool.Space or an in-improved SLA or with increased API limits. with the higher tiers, you can have increased access to the team for things like feature requests, as well as having, a more custom design, opportunities available. So for those of you interested, go and check that out over at Mempool.Space slash enterprise. And for those of you Those of you who just wanna see the fee rates and search things, mempool.space is the site for you. And now back to the show. Yeah, interesting. might be a good spot to also bring up the, Exit problem, right? Because people have spoken about in the Lightning context of thundering herd, right? And you and I offline, we sort of spoke about this idea. Well, I was kind of coming to you with this example and just trying to understand if it made sense, right? I, I, I was talking about this idea of a parachute, right? The idea that, look, most of us today, or at least most listeners of this podcast probably, have flown on a commercial airplane without a parachute. Now that might seem really crazy, like if you, you know, if we were talking to people in a world, you know, what? You mean, what happens if the plane goes down? Well, yeah, okay, they've made it safe enough over time that it's stand-- in fact, standard practice for us to go up in the air in these big planes without a parachute. And so maybe it's a similar analogy with on-chain exits, right? Because this is another common criticism point that comes from people where maybe they believe that, \"Oh, there's not that much point exploring all this.\" This UTXO sharing, it may not work out anyway because what happens when the channel breaks down or whatever this multi-party construct breaks down, everyone needs to hit the chain, and all of a sudden, boom, now you're back to the same problem. What if fees aren't affordable for every participant in that? Multi-party channel or construct." }, { "speaker": "brandon_black", "time": "38:19", "start": 2298.54, "text": "Yeah, it is an important topic, and, and it was, it was great, again, having everyone in Austin at the same time 'cause we, we had some conversations about this exact, challenge. So I think Partially agreed about the parachute analogy, and there's-- but the great thing about Bitcoin and, and, and script, hopefully restored script, in my opinion, is that it's not binary like it is, \"Do I have a parachute or not?\" It's like, \"How costly is it to use my parachute?\" Right. And so, yeah, i-in the early days, maybe it's critical that, that you can use the parachute without, let's say, without even bumps and bruises, because, because the, there's, it's so much more likely in the early days that there's going to be a, a, a, an issue with your, with your level, layer two construct, because it's early. But then as things mature, you're willing to say, \"Well, I, I have this parachute, but it's like an ejector seat where, where it might break my back, but I'll, I'll, I'll live.\" You know? So we're, we're willing to take somewhat more pain to access that parachute as the, as the protocols mature, to your point. But, but all of these protocols have the option of that parachute in some way or another. It's just how, how costly it is to use it. And so yeah, then there's the question of the thundering herd. What, what happens when you've got, let's just use the example of Ark, since I mentioned it, you've got an ark full of ten thousand people, and there's a bug in the ark software and everyone has to go on chain? that can be very, very costly. And I think the first answer is, by the time it's so big that it'd be that costly, 'cause it's a thundering herd, the chance of As you said with the airplanes, right? Airplanes crash incredibly infrequently. By the time you've got ten thousand people in one arc, bugs are very infrequent, but it's gonna happen. this is pretty much the nature of software, the bug is gonna happen at some point. And so, I think the answer is that it takes a while to unroll, and it's gonna be, you know, people are gonna be stuck in maybe some kind of a Covenant based congestion control situation where they're waiting to be able to unroll their stuff on chain till fees come down to something. In the meantime, you know, their, let's say their funds are kind of safe-ish, you know, they can't access them, but no one else can either inside of this unroll tree. Is that a major problem in that, in that event? Again, we have the parachute, it's gonna be there, you're gonna, your funds are gonna be locked in this unroll tree. You know, I think we can, we can handle that as a, You know, because we have, we know this possibility exists that you're gonna be stuck, we offer, as part of joining an arc, we offer insurance that, that pays you a, you know, buys your share of that timeout tree for a fraction, like what happened with MTKO, even, you know, we, we know for sure that the real world can solve problems like this. You know, your funds are stuck, your funds are there, but they're still stuck for ten years. Okay, what do you do? Well, you, you get, you sell your share of Okay, that's not actually a terrible situation, and it's the way that these things are, are solved. We, we don't have to like, there's like a utopianism about saying we have to solve the Thundering Herd completely. of course you don't You can, you can make it so that it's good enough that it fits into the existing real world systems we have." }, { "speaker": "stephan", "time": "41:30", "start": 2490.17, "text": "Yeah, and I think that's a fair point, it's a good, good explanation. So in that model, you have like, you might have trees For which this segment of the people have to go on chain, right? It might be like something like that where, and maybe, and I've heard other pe- other people mention ideas, like Shino has mentioned this idea of OP_EVICT to me as well, and other kind of opcodes that could be used to sort of manipulate the tree or, in this hypothetical, let's say you have a multi-party channel, one party's gone unresponsive or he's gone offline for whatever reason, having this kind of op code that can kick someone out if they're unresponsive. Something like that, that might be another direction things go, right?" }, { "speaker": "brandon_black", "time": "42:12", "start": 2532.4, "text": "Absolutely. There, there's many ways these protocols can be designed, and this goes right back to that point of we shouldn't, right now as protocol developers, try to constrain what that next level, layer two is gonna look like. We should be focusing on building a generalized script that can be used to build many layer twos with different trade-offs. So some might be, let's say, it might be more costly on the coordination side to use something that has alpha-vict, but it gives you this flexibility of any party in it misbehave, you can kick them out, and, you know, they get their money on chain, it costs them, they're on chain fee, but everyone else gets to stay in and not cost them anything, or minimal, let's say. but you might also say we have these protocols that have a centralized coordinator, where if the coordinator misbehaves, we all have to go on chain. Now, the trade-off is that they're much easier to use in the meantime, but the downside is that they're gonna be more costly if the coordinator misbehaves. So we don't know" }, { "speaker": "brandon_black", "time": "43:05", "start": 2585.35, "text": "I think the KatVM idea is pretty cool in this, where, there, I think there is a coordinator, but any one party can unilaterally exit without making the whole tree go on. So if there's like a conflict between Bob, but Alice and Carol wanna stay in the KatVM, Bob can leave that coordinator, he takes the on-chain cost, so instead of, he can like evict himself. Instead of like the top evict, evict someone else, and then there's evict yourself with KatVM. So again, I can't predict which of these things is gonna become Them to be experimented with." }, { "speaker": "stephan", "time": "43:37", "start": 2617.41, "text": "Right. And so then, as an example, in that world, let's say great script restoration has happened, at that point, if you want a CTV functionality, how would you achieve that? Like, is there, it, like, at this point, it's not that you need another special op code, you're just using other things like op cat to sort of give you the same functionality, is that what you're doing? Or what is it, how's it gonna work? Yeah." }, { "speaker": "brandon_black", "time": "44:00", "start": 2639.73, "text": "So concretely in great script restoration, The OP_TX_HASH proposal is kind of implicitly included in it, like it's implicitly and explicitly. And so TX_HASH has the same default hash mode as CTV, and so you get that CTV. And, and the reasoning there is, if we're gonna have OP_CAT and OP_LEFT and OP_RIGHT and OP_SUBSTRING, which I'll come back with restoring the original opcodes, they give us introspection, but they give us introspection that's so ugly, no one should use it. So we should also have OP_TX and OP_TX_HASH to get introspection that's not so ugly" }, { "speaker": "brandon_black", "time": "44:34", "start": 2674.35, "text": "I think the focus here is great script restoration should let people build the better things so they don't build the worse things." }, { "speaker": "stephan", "time": "44:41", "start": 2680.97, "text": "And when it comes to designing these, you know, protocols, so yeah, so I guess the, like coming back to what you were saying is the idea is you, you, you're trying to-- or I guess this, this idea is to try to make Good tools available for everybody, and then you, you pick, you pick what you're gonna do, whether it's, you know, some cat VM thing or some ARC thing or some, you know, congestion control thing. And introspection, as I understand, is this idea that, as an example, let's say you wanted to build like a rate limiting thing, like you want a vault, but it only allows zero point one Bitcoin to leave per day or some, something like that. And introspection, the concept, would allow you to Sort of make a vault that allows that, and it's enforced at the protocol level, it's not done kind of at an app level. That's-- is that right? Or can you just elaborate a little bit about how introspection would work and what it would mean for us?" }, { "speaker": "brandon_black", "time": "45:35", "start": 2735.0, "text": "Yeah, so that, that example is a great one because it, it does actually nicely cross over from what is being talked about into what's not being talked about. To do a daily limit, you'd have to have kind of global introspection, where you can say, \"Look at all the addresses that are part of this This vault and make sure that no more than ten million sats comes out, comes out of it per day. And that isn't being talked about. That's looking beyond this transaction, maybe even beyond this block, but to like a global state, introspection. That's not being talked about. So the introspection that is being talked about is looking at anything happening in this transaction. So you could say, make sure that no more than ten million sats moves in one transaction out of this vault. And that's the introspection that's being talked about, is look at this transaction, look at" }, { "speaker": "brandon_black", "time": "46:21", "start": 2781.07, "text": "This transaction and restrict specific aspects of it, say, you know, this script can only be spent with that other script, or this amount can only be spent as long as that amount goes to some address sp-- that's specified in the con-- in the introspection script. So that's what's being talked about, is restricting the transaction in which some Bitcoin can be spent." }, { "speaker": "stephan", "time": "46:44", "start": 2803.7, "text": "I see. And that will have kind of different security implications because you might have designed your security setup, on this idea, or maybe a company might sell a service based on this idea of something per day, but actually that's not feasible under, you know, under this model because what we're talking about here is at the transaction level, not at the global, let's say, day level. but anyway, nevertheless, it's there, and so the concept is there and it, you know, should help people. The other, thing And I, I caught some of Rusty's talk on the, on the, the YouTube version of it, and just curious to kind of hear your reactions on some of this, because I think One thing that sort of came out to me was this idea that how do you make sure it's safe, right? Like how do you make sure-- And what Rusty was getting at in there was like saying, similar to how there's a SIGOPS limit, could there be a VAROPS limit? And could you just explain a little bit about that? You know, for the regular user, what does that mean to try to restrain, the scripting language such that you're not, creating that same problem, you know, that was, yeah, you know, created before?" }, { "speaker": "brandon_black", "time": "47:55", "start": 2875.49, "text": "Yeah, I think it's, it's a, it's, it's probably the most important single thing that, that Rusty talked about was this, this var op limit. So I'm glad you asked to get more detail on it. like I said at the very beginning, the point here is to make sure that the worst case validation cost of a, of a, an input is never worse than it was Before, or the worst case val- re-really actually going more global in this case, what we wanna make sure is that the worst case validation cost of a block is no worse than it was already. So, so Rusty kinda started with this premise of, let's pretend there's a block that has the maximum number of signature operations that we currently allow in consensus in that block. How long does that take to validate? Okay, now let's take the worst case of every other opcode and smash the worst case of every other opcode into a block. How long does that take to validate? And can we come up with a way to structure some limits on opcodes so that they never exceed the existing worst case as Bitcoin is right now? And so each operation has, has a different cost. And the thing that he," }, { "speaker": "brandon_black", "time": "49:01", "start": 2941.23, "text": "the reason it's called VarOps is because unlike signature checking, which has a fixed cost per, per call, you know, not exactly perfectly fixed, but very close to fixed, Some opcodes are very variable depending on what their, their inputs are. OP_CAT is a great example of this, right? OP_CAT of, of, let's say a two-byte number and another two-byte number is almost free, it's four bytes, no one cares, right? But OP_CAT on the five hundred and twenty byte stack size input limit and another five hundred and twenty bytes, that actually takes a little bit of time. So it's a VAR op because the inputs to the op code affect the cost of it. So the limit we end up with is basically a cost in terms of, of how many variable bytes are being processed by these various opcodes. And so he did some benchmarking, well, a lot of benchmarking, I should say, on the different opcodes, you know? Okay, so we have numbers, do multiplication, division, et cetera, compare multiplication to signature checking, compare hashing to signature checking, compare, concatenation to signature checking based on the number of bytes going in, and then Looked at, at what he, what he found was that in, in most cases, it's how many bytes on, of memory in the computer are touched is what determines the cost, with the one exception being hashing where there's a kind of a fixed multiplier applied. And, and he did benchmarking that showed that, that the, the practical case is actually better than the estimate you get by just taking the number of bytes touched by the opcode and using that number of bytes as your, as your kind of cost factor. The, the real case is a little bit less bad than that across all the opcodes he benchmarked. Which is great, 'cause it means that if we use the number of bytes touched as our metric, except for hashing, we get this very consistent, it's at least better than this across a wide variety of opcodes, which lets us very confidently then say the worst case block validation has gotten no worse than just signature checking. That's, that's how it comes together, is the number of bytes you're, you're touching determines your worst case, not common case, but worst case validation cost, and that worst case is no worse than signature checking, and so we're confident then that we're not gonna make the overall worst case any worse than it is today. It'll actually be, if someone filled up blocks with these other opcodes, it would be better than sigops, and that's a good situation to be in." }, { "speaker": "stephan", "time": "51:28", "start": 3087.83, "text": "So in simple terms, it's sort of taking the worst possible outcome, assessing w-how long that would take, and comparing that to today, in the worst possible outcome, with the limits that we have today, and there already are certain limits, I think the SigOps limit on the, in the block and things like that, there are various limits I'm not familiar with all of them myself, obviously, but that's the approach. So then going forward, what is it gonna take to move that forward? Like what, what would next steps be here?" }, { "speaker": "brandon_black", "time": "51:57", "start": 3116.7, "text": "So I think there's, there's a few concrete steps, one of which I've been participating in, a-and, and that is, let's, one of the key things about the SigOps limit is that it's there, but Script can never actually hit it in practice, because you couldn't write a script that would hit that limit unless you were deliberately trying to attack the network, and so we wanna kind of make sure if we're gonna do this VarOps thing as the, the next step for, for Script, that Similarly, no practical script that's not trying to break things is going to hit those limits. So, so I, I, at, in Austin, I, I kind of wrote up a script that would implement, RSA like PGP style signature or, decryption in script. And, and I, I chose that because it tends to operate on large chunks of data, so it's gonna stress this var ops limit. And at least up to the four thousand ninety-six bit keys for RSA, using Rusty's model as he pub- as he showed at the, at the event, RSA decryption fits into the VarOps limit. You have, you have plenty of budget in your VarOps to not hit that. So that's a good sign on the other hand, it was, it was not an order of magnitude less, it was, it was about four x less than the VarOps limit for that script that I wrote. so it's not as much headroom as you might like. And so there's that kind of work, which is figuring out, is it true that with this VarOps limit, no practical script is going to ever hit it? Because that's an important aspect, if you remember, the Taproot soft fork. Try to re- or remove limits as much as possible to make it easier to statically analyze scripts and confirm they're going to execute okay. And so if we have a VAR OPS limit that real scripts will hit, we kind of break that rule that Taproot got us. Taproot gave us this, we don't have to think about the, the limits because a practical script will never hit it, and we want the VAR OPS limit to be similar. So that kind of work, the other big work to be done here is a lot of benchmarking. So Rusty benchmarked on his laptop. Before we could say concretely we've hit the worst cases, we need to benchmark across a variety of machines, right? We need to hit Macs, we need to hit PCs, we need to hit Raspberry Pis, we need to hit, ARM servers and data centers, we need to hit, you know, all kinds of different machines and make sure that the, this kind of general idea is consistent across all of them or tweak the limit" }, { "speaker": "stephan", "time": "54:14", "start": 3253.8, "text": "so let's summarize a few things, oh, I guess, is there any, anything else in terms of the, the conference or, you know, anything else that you thought was noteworthy?" }, { "speaker": "brandon_black", "time": "54:23", "start": 3262.69, "text": "Christian Decker's talk, I think was also quite noteworthy. He made an incredible point, and it, and it's frankly something I think we've talked about on one of the podcasts I was on with you before. But I think he put it very beautifully of being a salesman in Bitcoin is, is not good. And so while I'm here talking about things in the conference, and I really like the great script restoration idea I will always try to be as, as concrete about the trade-offs, the benefits, and the downsides of something that I'm talking about, and I think that's very, very important for all of us in Bitcoin, from, from the developers to the, to the, the Maxis, to the podcasters, like everybody in the space, we need to be very careful that we talk about things directly and not in a salesman way. we kind of saw this problem that Christian was, was pointing out with Taproot, and I think it's part of why people are a little scared of change in Bitcoin. Taproot, people said, \"Oh, Taproot's going to enable SIZA and NUSIG and blah, blah, blah,\" and that wasn't quite the reality, right? Taproot didn't end up getting SIZA, that was something you could do with Schnorr signatures that didn't go into Taproot. But the message kind of got out into the com-communications that Taproot did cross-input signature aggregation and SIZA. and then similarly MuSig, oh, we're gonna have signature aggregation for, with MuSig right off the bat, but it was two years later before MuSig came to production. And so- I think that was a really, really important message for all of us in Bitcoin as we talk about Bitcoin, to not oversell things. Even, even when you're orange-pilling people, right? Don't oversell. Bitcoin is expensive to use on chain. Don't sell, \"Oh, you can hold your own keys and it's gonna cost nothing.\" You know, because that was the thing that, that Roger did all those years ago, right? Being a salesman in Bitcoin is going to burn us every single time, and we've seen it already many times. So, so that was a great talk" }, { "speaker": "brandon_black", "time": "56:16", "start": 3375.64, "text": "Bitcoin, all of this stuff is so important." }, { "speaker": "stephan", "time": "56:18", "start": 3377.64, "text": "Fantastic. Well, I think that's a great spot to, finish up there then. So, I guess any closing thought or, on, you know, where you wanna leave things?" }, { "speaker": "brandon_black", "time": "56:27", "start": 3387.15, "text": "I think let's pull together on, on improving Bitcoin and, and a great script restoration is a great, great script restoration is a good way to go and pull it together." }, { "speaker": "stephan", "time": "56:35", "start": 3394.53, "text": "Great. Well, thank you for joining me." }, { "speaker": "brandon_black", "time": "56:36", "start": 3396.21, "text": "Thank you so much." }, { "speaker": "stephan", "time": "56:37", "start": 3397.17, "text": "I hope you enjoyed the chat. Make sure to share this episode and press like and give us a" } ] }