Good morning. Good morning. All right, that's the Drivechains fan club over there. Let's go. Let's go. So, very excited to have this conversation. We're joined today by two of the most OG Bitcoiners, in my opinion, two of the the wizards of Bitcoin. And, you know, y'all are very lucky to have an 80 IQ person moderating this discussion. I think it's going to make it very valuable for everyone here. So, to get started. First off, maybe introduce yourselves very, very quickly. Yeah, I'm Peter Todd. I seem to be mainly known for going to a ton of conferences. Okay, how long have you been in Bitcoin? A little bit more information, a little bit more. I read the white paper in, like, 2009. You know, started doing some stuff in 2014 and just kept on doing stuff. Done a bit of stuff in Bitcoin Core. Cool. Paul Sztorc. I think, you know, I've been like a Bitcoin researcher for, like, more than 10 years. A long time ago, I wrote this essay called Nothing is cheaper than proof-of-work. And that was a sequel to a related essay I wrote first that Adam Back at one point linked to on BitcoinTalk.org. So, I guess that was sort of, like, my big break or whatever. Cool. So, we have, I think, 30 minutes. And I wrote 20 questions I wanted to ask. So, we are going to jump around a little bit. We're going to move quickly. Some of these are going to have to be a sideline. So, to start with, let's just level set very quickly. Sidechains. Can someone briefly... Peter, can you briefly explain what a sidechain is? And can we level set, do we think sidechains are a valuable thing? Well, very briefly, sidechain is an altcoin, but tied to Bitcoin. So, you're trading Bitcoin. Okay, so all sidechains. That's where the term came from. All right. You know, it was meant to be like a something to the side of Bitcoin, denominated in Bitcoin. And there's a whole bunch of different varieties of sidechains. But, you know, the key concept was, hey, can we do another coin without doing another coin? Yeah. And do you think they're valuable? Sometimes. Okay, so we do think there are sometimes that they are valuable. I mean, Liquid has a small market of people who actually use it. Not very big markets, but for some circumstances, it could be useful. Okay. Would you have a different answer to that question of what a sidechain is? I think a sidechain is like a universal altcoin like emulator or something. So, whatever Zcash is doing, you send your Bitcoin over there and then you can do the Zcash things and then you can bring it back to L1. So, I would emphasize about the sidechain that it I would say that it's like the key to really understanding it is actually competition. You have, instead of only having Bitcoin core, you have developers compete over who gets the coins. I think that's really the essence of it, actually. Okay, so Drivechains is really an implementation of how to do a sidechain. I remember when I was in Bitcoin. Framework. A framework. A framework. Okay. Thank you. Again, 80 IQ, 80 IQ. All right. 90. So, when I was a young lad in Bitcoin, sidechains were always, not always, maybe depending on what part of the community you're from, but was like a holy grail of Bitcoin. It's like, okay, it's the technology to end all the shit coins. All right, though we didn't really call it that at the time. Now, it's like we can't really exactly get agreement on whether sidechains were ever a thing that was desirable in the first place. So, it's strange to see the perception, I guess, within the community change about, like, do we even want sidechains? Adam recently described the Drivechains implementation as DMMS, dynamic membership. Yeah, or multi-sig. Multi-sig, I think. Yeah, dynamic membership, multi-signature. Yeah, yeah, yeah, yeah, yeah. It has the word dynamic and signature in it. Yeah. So, do you all think that's a correct description of what Drivechains is? I think it's a cool, cool concept. Well, I'll disagree with you on the cool concept, but it matches, you know, what Blockstream originally proposed in their Merge Mine sidechain paper. Do you agree? That is a DMMS, but I don't know. I mean, the important thing about Drivechain is, you know, it has potential to give us planetary scale, like, immediately, and Zcash-level privacy, and it doesn't affect the L1 features of Bitcoin for the people who aren't using it, and you have security levels comparable to Lightning. Maybe we should explain for a quick second, like, what Blockstream meant by DMMS, which is the idea that you can have a signature scheme. The question is, who signs it? Well, in Blockstream's proposal, it's miners sign it, which, in the context of something like Bitcoin, means miners can decide to go and take coins and move them somewhere else, and it's purely based on what miners vote to do. It means those miners can change dynamically with whoever are the miners, rather than having set identities. Yes, the dynamic refers to the fact that anyone with hash power can start mining. Right. That's the part I think is cool. But I, so, as a framework, though, people in the audience, they can think of Drivechains, it's this sidechain that uses some sort of framework around a multi-signature setup, where the miners are the determinant of... So, I think from a tech point of view, DMMS makes a lot of sense, but I think for, like, a general audience, it really does come down to saying, hey, in normal Bitcoin, miners can't go move money, because they can't fake a digital signature. In Drivechains, as well as mergemine sidechains, the key console would say, hey, why don't we let miners decide where money goes? Okay, so, maybe we come back to that question, but, so, I want to talk about some of the risks around, specifically, Drivechains. So, first off, everyone up here has been cancelled before. It's part of the reason I respect both of y'all a lot, alright? One of your cancellable opinions that you have is that Bitcoin has a security budget problem, and that we need to re-evaluate the 21 million hard cap as a potential solution to Bitcoin's security problem. Emphasis on potential solution. There's a bunch of different ones. Potential solution. Okay, you know, when I look at Drivechains, part of the reason I think Paul's excited about Drivechains is he sees it as a potential solution to the security budget problem. You know, why, you know, why do you think that a proposal of increasing the hard cap of Bitcoin is less risky than a Drivechain's implementation is? Oh, I wouldn't necessarily say it's less risky. I think you're more likely to have other ways of fixing that problem. But, you know, certainly someone needed to go and talk about how that, you know, how that kind of thing works. So in, you know, 10-20 years into the future, there's plenty of time to go think about the different trade-offs. Sure. But, you know, I also got to stress, like, I don't believe Drivechains actually does solve that problem. You know, the problem with Drivechains is there's no block size limit. So there's no reason to expect transaction fee demand to be anything but minimal. Much the same way is that, you know, in the block size wars, those exact arguments that people gave against IDA, well, we'll just go increase the block size, transaction fees will flow in. It's like, well, unless you actually have a limit, you know, it's a supply and demand situation. Supply is infinite. Whatever the demand is, price is still going to wind up being zero. Right. So that was my next question is, like, do you think it'll actually generate more fees? Now, Paul, you have a different perspective on this. Obviously, I mean, because it won't literally be zero, of course. It can be any small amount. And then as long as you're increasing the quantity of sales, so to speak, you sell more transactions, even if it's one cent per transaction. Of course, if each new transaction will be increasing the amount, it's only if it's literally zero that it would have no effect, which obviously won't happen. I mean, nearly literally zero times a finite number of transactions is still basically zero. But this isn't a math proof we're talking about. This is economics. So, you know, Visa charges only a small amount, but they generate, you know, hundreds of millions of dollars per day. Visa charges, like, multiple percentages for a lot of people. I mean, it's not a small amount. They've got a monopoly. So I started off by asking, are sidechains a valuable thing? OK, so we're talking about fees. We're talking about, OK, is there something that people want to actually do that they're going to pay fees for? I guess that's the question, though. No, I don't think that's the question, though, because the problem is not, is there something people want to do that they'll pay fees for? It's, what is the mechanism by which there's a reason for them to pay anything but a trivial amount? You know, this is the same problem we have with infinite block sizes. The fact is, fee revenue gets driven down to zero because there's nothing stopping liners from underbidding each other. So I don't think that's actually an argument for Drivechains. So you think that if a Drivechain got popular, it could result in less fees being paid on the layer one? Oh, absolutely, yes, because Drivechains in that circumstance, you know, if the Drivechains are scaling, can represent people moving away to a cheaper system and less fee revenue coming in, versus something like Lightning, where there are trade-offs between different layers, and there's a very clear thing of, well, if you need to do an on-chain transaction, there is that much space, and you better bid for it. Now, I'm not going to argue that Lightning's perfect in that respect. I mean, this is why I advocate for built-in suspenders, but I don't think Drivechains can make that argument. Well, it's very easy to make the argument, though, because the miners themselves are the ones who set, like, the minimum fee rate. So if they find that their fortunes have decreased by going this route, they could just disable the Drivechain. But you're arguing for a cartel. I mean, you're arguing for a cartel. If it was truly a free market, someone would come in and underbid. No, absolutely not. I'm saying that if they don't want the block size effect to reduce the fee rate, they can either cap the size of the sidechain blocks or cap the min fee rate. It's the exact same thing. But again, when you say they can, you're really talking about a cartel here who can make a decision. In a free market system, that's not what would happen. Absolutely not. You could just have some formula do it. And if it really maximizes miners' revenue, then they will do it, of course. Obviously. You advocate that people can go create new Drivechains. Surely, if there's some formula, people will create another Drivechain that underbids this. I mean, there is no mechanism to set that limit. The mechanism is that the miners will maximize their fee revenue. Again, it's a cartel. This is a good— No, but it's not a cartel. You can do it with a formula. A good point of contention here. Very easy formula. I can underbid your formula. One question I have is Lightning Network. Is Lightning Network net adding to the on-chain demand on Layer 1? Or is it cannibalizing more fees than— I think it can definitely go both ways. But the thing with the Lightning Network is with current Comp Sci, there is no other alternative. Nobody's figured out a way to send single Satoshi payments over a blockchain. And it's not going to happen. And that's a strong need. Now, maybe we'll figure out something truly novel in Comp Sci. Like Drivechains. Well, I don't think Drivechains is novel. But, you know, I mean, that's just an inevitability with Lightning. Now, certainly in a lot of circumstances, Lightning can mean that the fees you do pay on Lightning channels can then flow back to Lightning nodes, which can then go pay much higher fees to bid to open and close channels, as well as adjust capacity with splicing. And in that circumstance, yeah, it can definitely flow more fees into miners. But, you know, I would not make the argument that that's a guarantee. Okay, so I want to keep moving just because there's other topics I want to hit on. But this is, I think, an important one to highlight is, will it actually drive more security budget? Okay. So, quick question. I think I know Paul's answer to this question about how many soft forks will exist in the future and maybe what Drivechains can do there. How many soft forks do you think, over the next hundred years, Bitcoin's going to have? Well, I mean, it absolutely has to have at least one, because Bitcoin ceases to exist in, you know... That's a hard fork, though. Well, that particular example is kind of a bit of both. It's a weird example. But, you know, if you're talking about hard forks, I mean, soft forks is basically the same discussion, right? It's like an even more extreme version of fork. Now, I think it would not be surprising, you know, backing away from that extreme, that we get Bitcoin to a state where it's essentially perfect. In much the same way as that TCPIP. Other than IPv6, which comes from the 90s and is gradually getting adopted, it really hasn't fundamentally changed much for a very long time. Because we figured out something that was essentially perfect. It might not have been absolutely perfect. It was more than close enough. And what did we do? Well, we built layers on top of it. In much the same way as that we're taking Bitcoin, we figured out how to go make lightning work. And we built that as a layer. And now you have this enormous amount of innovation happening above that layer. But we needed a soft fork for it. We needed one. Technically, the way we implemented it was like three. But we needed, you know, one set of changes and that was that. Now, in the future, with things like ARK as an example, it won't surprise me if the community as a whole says, hey, here's this new thing we need. Everyone's going to use it. Let's do that one fork and that's that. But this is a rare event. Whereas most of the innovation that happens is things that happen on layers above. I mean, RGB is a wonderful example. They're implementing all this semi-off-chain, like layer two-ish stuff that can trade assets in very efficient ways. But they don't actually need a fork to do that. My own Open Timestamps project is a much more boring example of the same thing. Open Timestamps, not only does it not need forks to exist, like it's basically impossible to stop. That's the kind of innovation that excites me. So to summarize, you think over the next 100 years, we're talking about a small number of soft forks. It could easily be less than a dozen. Easily. Okay. So, Paul, one reason why I like Drivechains is because I feel like there's a lot of changes in Bitcoin's future, like a lot of things that need to happen. And it creates an environment where we can do some of those changes in a low-risk way. Do you think that that's a correct description of the value prop of Drivechains? And yeah, how do you see that playing out? Well, yeah, certainly the developers are going to continue to invent things. And so the question is, what are they supposed to actually do with their invention? And one route is to try to get the invention, persuade people to add it to Bitcoin Core L1. But that takes a very long time. And I think it's been getting more and more difficult as the years go by. And there's also more and more people inventing more and more things. So there's more specialists in different directions. And so what are these people supposed to do with their invention that they make and that they really like and that maybe they've convinced other people is useful? ARK is a perfect example of something that we would have already had, probably in 2019 or even earlier. Because if you look at the timeline of when Jeremy Rubin was inventing CTV, that was a long time ago. And he tried to get it through the Bitcoin Core process, but it just found it to be too time-consuming. Well, he failed to convince people it was useful enough. I mean, it wasn't important. But the irony is now people have flipped on that. And then now they think he was right and it is important. Not yet. ARK is interesting. It's not there yet. So this kind of moves a little bit towards the activation discussion. But something I wanted to ask you about, Peter, is BIP-125. All right. You have to refresh me. Which one was that? Full replaced by fee. Well, no. Optin replaced by fee. Optin is 125? OK. Yeah, yeah. So the thing is, though, BIP-125, it's got nothing to do with consensus. I mean, it's not related to this discussion directly other than saying, yeah, you can go build things on top of Bitcoin. Well, I guess where I see parallels is that there's conflicting visions of Bitcoin. And I remember when everyone who was maybe wanting to make Bitcoin good for payments, they're like, we want zero conf because it's a good user experience. See, this is not a great example of this. Because this is a matter of conflicting visions of Bitcoin in general. This is more, there's a set of vision for Bitcoin that's just insecure and doesn't really work. And then there's a set of vision of Bitcoin, which basically all devs are saying, well, obviously you do it that way. In fact, I mean, you know, could ask the audience, go raise your hands, like how many people would wait a confirmation before accepting payment from a stranger? I mean, people have always said, we'll go wait. Yeah, I think replaced by fee has won the day. So I'm not questioning that. I'm saying like the full replaced by fee is not standard in Bitcoin. Well, like, I think right now, roughly 35% of hash power. When was it the first, when was it first proposed? Well, I mean, a decade ago, the first time actual code was written was a bit under a decade ago. So talk about just the process of like activate that. Well, I don't let her complain. I don't think that's a good example. I have written a software, check-lock-time-verify. That's a much better example because it's an actual software. And the process for that was, well, all right, I go have a somewhat good idea. Isn't that clever? Check-lock-time-verify. We start realizing payment channels need it. Simply that basically bidirectional payment channels. And very quickly, people figured out, well, you know, this looks really useful. And we're going to go need it for payment channels. We're going to need like one other mock code, check-sequence-verify for payment channels too. And from there, frankly, getting in was a fairly short process. Because once you've done that kind of groundwork, as things roll over to, hey, this is really needed, we were probably able to get that in in like roughly a year and a half, which was sooner than actual good implementations. So what caused the success? Did you go talk directly to miners to get miner support for it? I didn't need to do like a ton of groundwork on that, because it was such an obviously good idea. It was something, I mean, bidirectional payment channels, that's basically what's under the hood in Lightning. It's obviously really important. Everyone, with few exceptions, agreed this was a useful feature. So the nuance of what exactly should check-lock-time-verify do was really just a matter of discussing among some tech people certain nuances of exactly how the opcode should do things. We hit on the design very quickly. Where I'd contrast that to, say, check-template-verify is people just haven't been convinced that it's actually that useful. Now, something like ARC could change people's minds on that. But ARC still is not an idea that there's wide consensus that actually works. It's an idea that not that many people actually understand. Whereas payment channels, people figured out very quickly, hey, this is obviously a good idea. We should definitely do this. And it got in quickly. During that process, did you have critics? Frankly, not really, because it was a very hard idea to argue against. Taproot is probably your better example for arguing against. Most of that was really nuance of exactly how detail should work. Again, Taproot is an idea. Once people got their heads around it, it seemed very obvious. Oh, yeah, this is how Bitcoin scripts should have always worked. It took a while, I think, for people to realize that. But the idea spread very widely, because it's just such a good one. Speak about your experience with this. How was the activation discussion? Check-lock-time-verify, that was back in the pre... You had two eras. I think the first seven years of Bitcoin, we had done 15, 16-something soft forks. We had a ton of stuff to fix. And then we had SegWit, which was very dramatic. And then SegWit took 20 months from when it was proposed to when it was finally coded and activated. And then Taproot took 46 months. So that's really what it is. It's just a slowing over time of... And it's really the two eras. SegWit was so contentious that for many years, people refused to even discuss soft fork activation, which they still kind of do today, where they say, we don't want to touch anything controversial. Well, I should be clear. SegWit is another key part of Lightning. And again, I think SegWit falls in this example of, this was so obviously needed. And it also falls in the example of... Oh, but it was highly contentious. Well, it was contentious because it was a block-size debate. It wasn't contentious because tech people thought it was a bad idea. With, you know, a few exceptions of crazy people. Why do you think this idea is bad? Well, I think Drivechains is bad because it's basically a let's-go-trust-miners system. Yeah, but you're mixing up L1 and L2, though. But again, it's... It's only the L2 people who opt in. You are saying that we should have large amounts of coins tied in such a way that miners can just go steal it. That fundamentally changes how mining works right now. Yeah, but if miners steal from the Lightning network, it's the same problem. But they're not able to do that on the scale of Drivechains. Also, they're not able to do that, for instance, under a court order. You know, one of the things that I think a lot of people get really... The court order thing is silly. ...get really worried about with Drivechains is you're now creating Bitcoin in a situation where there are targets that can actually do things. I mean, I personally, for instance, am being sued by Craig Wright to try to go reassign Bitcoin. And it's a very real lawsuit. You know, it's quite a silly thing to worry about this argument from the lawsuit. You could even flip it around and say, this is what will decentralize mining because no one will be able to find them or something, if you want. But the whole thing is kind of silly. Anyone could be sued at any time for any reason. Yeah, but it's a much bigger threat if the lawsuit's valid. It's easy to... See, I can easily defend my lawsuit because I can't actually do that. The Lightning network, at different scales, that is part of the problem, is that on the Lightning network, miners can, like, mosquito attack individual channels. They need a lot of coordination with a lot of people. No, it's the same 51% cartel. It's exactly the same. All they have to do is censor this justice transaction. But the truth is that they won't do either because miners want Bitcoin to be a success. So, of course, they're not really going to steal from any... In the Drivechain, though, all of the fees... This is a key difference. In Drivechain, all of the fees go to the miners. So this is going to be, like, eventually... Well, again, I don't believe fees will be significant. Each new fee is... It's like planetary scale merge mine transactions would be hundreds of millions of dollars per day. It's already on... Ethereum is already... Bitcoin only does, like, $500,000 a day, and Ethereum is already doing millions of dollars a day. To be clear, Ethereum does have a block size limit because Ethereum is breaking at its current scale. I mean, they can't increase the scale of Ethereum right now. Yeah, but there is... Each individual sidechain will have a block size limit. Why do you say that? I mean, I can out-compete your sidechain with a block size limit The real question is, why would the miners mine it at all if it generates $0 in revenue? The whole point is to collect the revenue. I mean, again, this, I think, gets back to your fundamental difference about what centralization pressure is. Overhead matters. If I'm a miner that's mining... Like, for example, say I'm Foundry USA, and I'm mining, like, 30% of the Bitcoin hash power. I can afford the overhead to do things, like go pay guys to go get Drivechains that bring in, you know, $1,000 a day revenue. And that could be, like, a huge number of them. But it's a very different kind of thing when you're talking about smaller-scale miners where now I've got to go get all of these possible Drivechains that, for me personally, might go bring in, like, $1 a day of revenue. And that really screws over the small miner. But if it brings in $1 a day of revenue, it doesn't matter. I talked to a miner yesterday... It does matter, collectively. I talked to a miner yesterday who's in the audience. They have 15 megawatts of hash rate. They said that if they could get a 1% or 5% boost to revenue by adopting Drivechains, they would do it in a second. But the problem is... It won't be 1%. It will be 10x, 100x, or even 1,000x. I mean, hang on. Let's be clear, though. There's a misconception there, which is that Bitcoin difficulty adjusts. By adopting Drivechains, they're not going to get, you know, a 5% increase in revenue. They will only get that if they are the centralized miner who can do it in a way that other people can't. That's, you know, that's one of the key things. What it actually does is increase the overhead to get into mining. Why does it increase the overhead? Because if you want to go run a full node that actually properly processes this stuff and allows withdrawals to happen... The miners don't literally need to run anything. Yeah, don't I get a fit if I'm just... They just need to obtain the knowledge of, you know... They can run a node, obtain... It gives you absolute certainty. I mean, again, I think this has been touched... It doesn't really matter anyway because the software cannot possibly be so expensive to run. The regular full node users will have to be running the software. Wait, hold on. Let's just be super clear. Miners don't need to run a sidechain to profit from increased fees. That's correct. Sidechains that work properly need miners to go and run full nodes on them. Or the withdrawal process doesn't work properly. No, they just need to obtain knowledge from the hash from somewhere. If you wanted to be absolutely certain that there's not a single atom of titanium in some bread that you're going to eat or something, you'd have to go into a laboratory and make it from scratch. But you know that if you go down to the supermarket, you have a different type of knowledge. Well, let's back up. Let's explain to the audience what on earth you're talking about. So, like I said with Drivechains, the model is that miners can go vote to decide where coins go. Now, if you don't run a node, obviously you cannot validate any of these votes. You have no idea where coins are supposed to go. You can't validate that hash for that vote. That's not true. You just have indirect knowledge. Well, again, like I say, you can't validate it. You have to go and trust that someone else does it. It's like Bertrand Russell's teapot argument or whatever. Is there a teapot orbiting Jupiter or something? The only way to be absolutely certain would be to go and check, but we also know that it's not. I mean, if the teapot orbiting Jupiter was very important to a coin... But miners don't need to run any nodes either. That's what's very curious about it. I asked you what the problem with this idea was. You just said that you mixed up L1 and L2, and you said that I don't like miners having control over the L2 withdrawals, even though they already have control over the Lightning Network justice transactions. So it's exactly the same thing. Now we're in this weird odyssey on miner costs. merge mining the sidechain is essentially free. They don't even need their own node. They can just coordinate with someone else who has the node. When you say that miners have to cooperate for justice transactions, that's just categorically false. 51% hash rate can censor the justice transaction. If they do that, they can drain the Lightning channel for free all the time. Hang on. Let's be clear. That's not going to happen. To profit from this, they have to coordinate with the Lightning channels doing this. Yeah, but they also must coordinate in the case of Drivechains. It's actually much more difficult for them to coordinate in the Drivechain case because they have to pre-establish a withdrawal to themselves that is going to take effect months, three to six months later. They don't necessarily know if the pie chart will be the same. So quickly respond, and then we're going to move on because we have a few minutes. We're going to go over on our time. I'm sorry for the people who said don't go over on your time. We're going to go a little bit over. I mean, look, this is silly discussion. Go read the blog post I just posted for this detail. Okay, so I want to move just before we talk activation on exactly how something gets activated, one thing that you're very clear on, Paul, is the way that Drivechains will be implemented, would be implemented, it's unwindable. All right, can you explain what that means and if we agree that that's a valid view? Yes, of course. It takes this op-nop5 that's unused. It's the exact same thing that happened with the check-lock-time verify, and it reuses it to count to 13,000, which is all that it does on L1. And then if there's some kind of problem with that, all we have to do is the exact same soft fork that turned it on, you can just turn it off. You just censor op-nop5 from ever appearing again in the blockchain. So there's literally zero risk to this idea. Do you share that view that that would be effective in terms of unwinding Drivechains? I don't think you'd be able to pull that off in practice. And one of the really ugly things about this, of course, is that if this idea does go catch on, you wind up having funds tied up, which causes a whole lot of political ugliness. Yeah, but again, this only affects the people who opt in. This is crucial to the whole point, the distinction between L1 and L2 is the entire point. You know what I mean? You may not care about a certain thing like the EVM or something, but other people care about it. And you may not care about large blocks. This isn't about what other people like. It's about their ability to choose their own thing. So some people want, you know, Roger Ver wanted the block size to increase on his node. So if you can't keep L2 and L1 organized, then you will never understand this idea. To be clear, you're not talking about L2 and L1 here. That's not how these terms get used. You're talking about L1 changes. All of this is L1. The L1 change is just the OPTNOT5 counting to 13,000. That's all it is. Okay, so I want to talk activation for a quick second. So, you know, I'm a simple man. Why is it so difficult to unwind? He's got 40 seconds. Let him talk about his activation. All right, all right. It's very easy to unwind. Let him talk about his activation. Thank you. Thank you, Pops. So, activation. As far as I'm aware, all soft forks get activated by miners at the end of the day. That's a complex question. I know it's a complex and controversial question, but, I mean, am I wrong? In certain circumstances, yes. So I think a great circumstance was how SegWit got activated. But that's still a miner activation. Hang on a second. So what happened with SegWit is the community threatened the miners with an unobservable threat. Namely, we are running UASF nodes that activate SegWit. Thus, if at least one miner does anything SegWit related, suddenly a big chunk of the network will go switch off. And they will be mining on a useless change. And this is why it's complex, because that was an unobservable thing. So the majority of miners decided in that circumstance, arguably, hey, they're making this threat. We will just go and do SegWit. I guess what I'm a little bit confused about is, like, okay, what you just described, this user-activated soft fork, where there was basically a message to the miners that if you don't do this, we're going to fork you off the network. We're going to reject your blocks. How is that different than Paul and Drivechain supporters going to miners and saying, run this software. And if you don't run it, at some point in time in the future, our community is going to reject your blocks. Well, I mean, to be clear, I'm not making a statement that it's different at all. I'm just saying, like, that is the nature of this type of activation. There's other types of activation which looks more clearly like miners activating, like my own check-locked-on-verify, which you could argue was a miner vote, say, hey, on this threshold, now check-locked-on-verify is activating. I guess my point is that, like, even a user-activated soft fork, you are petitioning the miners to activate something, or you're going to do something. So it's a communication to the miners, a signal to the miners of, hey, we're demanding this. I mean, it's a tricky signal because it's a signal which, maybe I'll talk about it from a more pragmatic point of view. If we have a UASF that doesn't have overwhelming support, which is what would happen with Drivechains, if this goes badly, suddenly Bitcoin forks, and very bad stuff can happen where, you know, one exchange is simply not on the same Bitcoin as another exchange, yet they still have the same ticker price. And I think we can see how a disaster this would be. This particular soft fork should be miner-activated because it's so miner-centric anyway, and also because it does not affect, like, there's certain things like requiring the Coinbase to have the block height or something. There's certain things, this one is more opt-in, much more opt-in than usual, which is to say that people who aren't using it can ignore it completely. To be clear, like, the Coinbase thing is fixing a serious bug. The miner-centric one should be activated by miners because if they're not really into this idea, and if they don't really understand this idea, that they would make a huge amount of money by, you know, like, having this enormous extensibility upgrade to Bitcoin. If they don't really get it, then they don't get it. So, you know, I guess my final question here is, like, okay, if I'm Paul, I'm going directly to the miners and I'm making the case for why they need to adopt Drivechains, and I'm selling them on the benefits of it, and, you know, frankly, I don't really care what anyone else's views are because it's the miners at the end of the day I have to convince here. If the community had a problem with that, how does the community stop it? Well, I mean, I think the main thing that happens here is, what you're telling miners is, this is going to be a shit show. And if you go through this and you add all this uncertainty to Bitcoin, ultimately you're probably going to either just reduce the price in general, or you will go have a user-activated soft fork to undo Drivechains. And that is a huge mess. It is a much bigger mess than... So why do you say that it would be a shit show? Because it's just if the miners activate it, then everyone is on the same chain. Hang on a second. It is a much bigger mess than just doing nothing. I mean, if you're a miner, you think, well, you know, I get my money in Bitcoin. If I go through uncertainty in a shit show, reduce the value of Bitcoin by, like, 10%, was that really worth it for the hypothetical Drivechain that a bunch of tech experts think is a bad idea? You know, I think that's the main pushback. Now, obviously, if, say, a 51% majority of miners said, you know what, screw this, we're going to do this, they can go make a real mess, and they can go force other people to react. But, you know, this has never happened in Bitcoin's history, and we'd much rather it not play out that way. I mean, because it's a soft fork, couldn't they have already... I mean, it hasn't been... It's theoretically possible that they already activated BIP300. Yeah, but, I mean, if people don't know about it, it's not very relevant. And people have put things like off-and-off 5 and other stuff in blocks, so it's unlikely to be the case. Okay, so I'm going to conclude here, because we're already over, and the please wrap up is going. But I think, you know, I've found that in Bitcoin, it's now impossible to get everyone to agree on anything. It's just impossible. It always was. Yeah, it's even harder now. And so I feel like, you know, why Drivechains, I think, is important is because whether Drivechains goes forward or doesn't go forward, it helps define the boundaries of how Bitcoin advances in general. Okay, you have a problem with Drivechains, like, this is how you resist Drivechains. You want Drivechains, this is how you advocate for Drivechains. And right now, that's so unclear. It's unclear how to do it. I think that makes it very uninteresting, because from a tech point of view, you're creating something that has all of this software complexity and so on, when it's so much easier to just build other types of systems where you don't have to ask for permission. You know, to build interesting stuff on Lightning, you don't need to ask for permission. You just go do it, and you write code, and you release it. You know, open timestamps, I've never asked anyone. Well, you had asked for SegWit, though. Well, once we created the building blocks, but, you know, we've created a very thorough set of building blocks, so you can build an enormous amount of interesting stuff. You know, we took the Bitcoin protocol and fixed it. The problem with Lightning, though, of course, is that even the proponents don't expect 8 billion people to be able to use it. Whereas with this, they could, and so that's a pretty big difference. The tech people don't agree with you on that. No, you could go to drivechain.info/misconceptions, and you could search. I have a part where I have hyperlinked a bunch of things. So if you search this, this, this, this, this, and this, I have a link to a bunch of people, the top experts in Lightning. Don't take it from me. They have all these different interviews and posts to our blog. Let's be clear. You're talking about experts saying Lightning doesn't scale. That's not that Drivechains work. So I'm going to get in a lot of trouble already. We're way over. But can we get a round of applause for these two wizards of Bitcoin? Very important conversation. Paul, where can they follow more about Drivechains? I would just follow my Twitter on Truthcoin on Twitter. And, Peter, you're going to write the definitive takedown of Drivechains. Is that coming? I mean, I just posted it. Go to petertodd.org. Okay. Let's go. All right. Welcome back to the Bitcoin Amsterdam Live Desk, sponsored by Bitcoin Magazine. I'm joined by my esteemed panelist, Nifty, the founder of Base58, and Iago, a core contributor to Sovereign. We just heard a great panel about BIP300, obviously with Paul Sztorc, Peter Todd, and David Bailey. So I want to go right to you, Iago, with the first question. Does Bitcoin have a security budget problem to you? Yes or no? Yeah, clearly it does. We're seeing no growth in the value of transaction fees collected by Bitcoin miners over time. And we're not seeing a substantial increase in the number of transactions. And what Paul and Peter both want to do is try and find a way to increase that. I don't think that Drivechains is the way it used to be. For many years, I was a big supporter of Drivechains. But at this point, I think it's obvious that it's a really obsolete technology. What we need are roll-ups. That is the ability to add more transactions into every block using Bitcoin transactions. And it helps solve Peter Todd's concern with Drivechains, that you would have infinite transactions and no scarcity, because the scarcity of Bitcoin would remain. 20 seconds to you, Lisa. Do you think that we have a security budget problem with Bitcoin as well? No, I think I'm a security budget whatever. I don't think there's a security budget problem. Okay. Yeah, no worries. So I know we were talking about Lightning adding fees to L1 and helping out miners. Or is it cannibalizing miner revenues? Or is it a little bit of both? I'll go to you, Lisa. I think it's a little bit of both, honestly. I think that having Lightning there makes transactions that wouldn't be possible to happen, happen. So I think that's great. I do think there's a little bit of tradeoff between now we have transactions that are happening on Lightning that maybe could have happened on the base layer. Yeah. 15 seconds to you, Iago. What are your thoughts on Lightning? Cannibalizing miner revenue or adding to it? I think its overall impact is fairly marginal, because the level of adoption that we've seen with Lightning is quite marginal as well. And so what its theoretical impact would be, different from its practical impact. Yeah. Lisa, last question to you. Miners control the justice transactions. And I know that's what Paul was bringing up. And you were kind of shaking your head over here. What are your thoughts on him saying that they control the justice transactions? I think that's completely untrue. I think it's true that miners decide what transactions go into blocks. But I think that being able to choose between justice transactions or not, that's completely, I think, not how it actually works. All right. Thank you so much. We're going to bring it back to the main stage or the Genesis stage here to talk about the Nostr protocol. Catch us after that. Thank you, Miami, for the last three years in this amazing city. The whole world shut down. But Miami welcomed us with open arms. We want to show Bitcoin to the whole world. We are taking the conference on the road to set the stage for Bitcoin in a new city. Nashville. Bitcoin 2024 is coming to Nashville in Tennessee, a city that is known as a music and freedom city. Bitcoin 2024 in Nashville from July 25th to 27th.