0:00 This is everyone, this is the great Robin Linus who invented BitVM. 0:02 So, you may have seen BitVM on maybe a PowerPoint slide, or someone's pitch deck or something. 0:08 And, I mean, you know, I'm not going to say that all those slides are fake, 0:15 and that this guy is one million times more relevant than everything that those people ever do in their entire lives, 0:20 but it's something like that. 0:22 So, BitVM from last October or something like that, or September. 0:30 And I created this other thing, BIP300. It's also great. 0:36 But we're going to be up here talking about whatever you guys want us to talk about. 0:40 We got roped into doing this. What do you think we should talk about? 0:42 Well, thank you for the favor, guys. 0:45 My name is Michael B. Casey. I am Director of Engineering for Marathon, 0:49 and I architected a sidechain platform to try to bring some of the Drivechain stuff to fruition after all these years. 0:57 And, you know, of course, we always want to leverage. 1:00 I'm not out there like everybody else, claiming we've got it working, 1:03 but I want to leverage, if possible, BitVM for a more decentralized pegging mechanism or whatever else it could offer. 1:10 And basically what this panel is about, you know, to finish introductions, we have Robin Linus. 1:15 Do you want to give a quick introduction to yourself? Because Paul gave you a little bit of one. 1:20 Yeah, I came up with the idea of BitVM, and I'm working on that. 1:27 I'm implementing it with my team, and I'm also a big fan of sidechains in general. 1:34 I'm a big fan of the work that Paul is doing. 1:39 Maybe I should even add that BitVM is more or less just a workaround to enable something like BIP300 without a soft fork. 1:46 So it's essentially just a way to get around the activation drama. 1:50 Do you think that's possible in the near term? That's intriguing. 1:55 Oh, yeah, sure. I don't see any big obstacles from the technical side for BitVM in particular, 2:02 because now we have implemented that SNARK verifier in a huge Bitcoin script. 2:07 And that script is 3 gigabytes, which is, of course, huge. 2:12 But with BitVM, too, we can chunk it up into smaller chunks. 2:16 And as long as it's smaller than 4 gigabytes, we can probably run it on the main chain, actually. 2:22 And we brought it down to 3 gigabytes, which means that it will probably work. 2:29 Maybe something super surprising comes up, but currently it looks very good. 2:33 Cool. Well, when can we expect it to ship? 2:36 Yeah, good question. I was stupid and said four weeks just this morning. 2:41 Oh, no. 2:43 I hope my team didn't hear that. I don't know if they agree with that. 2:47 But, yeah, that's kind of like the time frame. 2:50 It is looking pretty good. We are almost finished, I would say. 2:54 And I think it's quite realistic to ship the first prototype within the next four weeks. 3:00 So for those watching who actually aren't familiar with BitVM, 3:04 I don't know who on the planet wouldn't be at this point. 3:07 If you want to give just a brief high-level description. 3:11 Yeah, that is complicated. 3:13 But I think from the most high level, the most important thing that I care about or that BitVM cares about 3:20 is both throughput and privacy. 3:23 Those are the most important things. 3:25 Because I think Bitcoin should be used as currency. 3:28 Bitcoin should be used for payments. 3:30 And for that it has to be cheap and private. 3:33 And so we have to scale it and we have to make it private. 3:37 And doing that on the main layer is complicated, in particular the privacy part, 3:43 because we would have to change a lot about the main layer to make Bitcoin actually really private. 3:49 And so what BitVM does is that it helps us to build bridges. 3:54 Essentially, BIP300 is also a bridge. 3:56 So just so it's not a roll-up-centric use case for the virtual machine, just to be clear about that, right? 4:03 Yeah, roll-up is one use case. 4:05 In general, it's about bridges to side systems, whatever those side systems are, 4:09 like sidechains, roll-ups, ZK coins is another protocol that I'm working on. 4:15 So it solves the Bitcoin is dumb problem. 4:19 Yeah, that is what the bridge solves. 4:21 Bridging Bitcoin to other systems that can be way more expressive 4:27 and that can do all kinds of things that the main layer cannot do. 4:30 Well, thank you very much. 4:31 So Paul here, Paul has created probably more sidechains, at least in theory, 4:37 than anybody else on the planet. 4:39 So how many would you say that you have actually set up? 4:42 Is it about quantity? 4:43 Like if I make enough sidechains, then one of them will be activated on Bitcoin. 4:48 So far, right? 4:51 I have made quite a few, and some are clones of altcoins, which I think is clever. 4:56 So we have a clone of the latest version of Zcash for privacy, 4:59 and we have a clone of the latest version of Ethereum. 5:02 And I have designed and built many sidechains, 5:06 and I think the sidechain is definitely the way that Bitcoin will scale 5:10 and achieve all these features that people want their money to have. 5:17 And in particular, anything that someone builds anywhere, 5:19 someone builds something into an altcoin or something else, 5:23 they have written the code, so it is theoretically possible. 5:26 And so why don't we just take whatever they do. 5:29 I don't know. 5:30 Did you have something specific that you wanted to know about the difference? 5:33 No, no. 5:34 I mean, it is just like I know you have quoted many times saying 5:38 the entire reason you went on this mission to create Drivechains 5:41 is because you wanted to implement Hivemind, and it was impossible. 5:44 Yeah, the prediction markets, yes. 5:45 I was interested in one specific thing. 5:49 However, the sidechain idea is much bigger than merely the prediction markets idea. 5:56 Prediction markets happens to be an interest of mine, 5:58 and I have this website, bitcoinhivemind.com, 6:01 and you can read to your heart's content about all that. 6:06 But really, sidechains, I think, are going to be necessary for Bitcoin's future 6:11 because we can't really live in a world where there is not enough scale 6:15 or where there is some other system that is actually meeting everyone's needs 6:20 for payments and for privacy. 6:24 So we don't want rival systems. 6:25 Scale is a very important point. 6:27 Yeah. 6:28 Network effects are very important when it comes to money. 6:31 So most people prefer to use the money that their friends are using, 6:35 and if something hits a scale ceiling and something else does not, 6:39 I do think that the thing that is limited will eventually be replaced. 6:44 So, Paul, how would you optimize a sidechain for scale, if that was your goal? 6:49 Yeah, I think I have written a post about this, 6:52 and I have produced the software also. 6:56 And I think you can push the, you know, there was this big block size war in the past. 7:01 I'm familiar. 7:02 It was very, very famous. 7:03 Yeah. 7:04 And it's actually not that, we're very, very close. 7:08 If you can do things like shrink the size of transactions, which is not that hard, 7:12 and then increase the block size by maybe two orders of magnitude, 7:16 so it's not quite unlimited, but it's not quite, instead of one megabyte, 7:20 we do something like eight megabytes that slowly grows to 80 and 80, 7:26 or 800 over like 10, 15 years. 7:30 And then the other thing you can do is you have 10, you can have multiple sidechains. 7:34 You have 10 that are sort of geographically distributed. 7:37 So you have some for Europe, some for East Asia, some for the United States, 7:44 some for like South America. 7:46 Because most of the people will be transacting with people who are, you know, it will clump up. 7:52 So I think actually if you do those things, 7:54 it's actually possible to process all the transactions in the world 7:57 using this sort of team of sidechains in a triangle. 8:03 And I have written a bunch of posts about that. 8:06 So if you go to this one website, Truthcoin.info, which is my blog, 8:10 I have a website, all the world's transactions, 8:13 and I have another one called Thunder, which is like a joke. 8:18 Do you have anything to add? 8:22 What would you want to see in sidechains of Bitcoin? 8:29 I want to see Bitcoin being used as the money of mankind. 8:34 I think we should all use Bitcoin all the time 8:36 instead of that fucking government money that is ripping us all off. 8:40 I think fiat is really, it's a scam, it's a form of cancer, 8:45 and we have to cure ourselves from it with Bitcoin. 8:49 So what do you consider actually really a sidechain? 8:53 I have my own definition. 8:55 But what makes a sidechain actually just not a complete scam to you? 9:01 I think it should have Bitcoin as its native currency. 9:04 That is the most distinguishing feature. 9:09 The other thing is it should probably have a consensus mechanism 9:14 that is anchored into Bitcoin as well. 9:16 By anchored do you mean specifically like merge mining? 9:19 That is one option. 9:20 What other options? 9:22 There is another option that is basically Bitcoin-backed proof-of-stake 9:26 where you stake Bitcoin in the main chain to become a sidechain validator. 9:31 I find that kind of interesting in comparison to other proof-of-stake systems 9:35 because other proof-of-stake systems, they try to secure themselves with themselves, 9:38 which is a bit absurd. 9:40 And here you have an external thing. 9:43 You anchor the proof-of-stake into Bitcoin's proof-of-work, 9:46 and this is how you resolve that absurdity of classical proof-of-stake. 9:50 Yeah, but the problem that I see with that is 9:54 that does nothing to benefit the layer 1 miners. 9:57 And to me, that eventually leads to rotten incentives for securing main chain. 10:04 Absolutely. 10:05 I think that's a very valid concern 10:07 that the miner incentives are getting reduced over time 10:12 by these layer 2s that do not use or that do not pay the miners. 10:17 And that's one of the reasons why I like BIP300 so much 10:20 that it actually takes into account the miner incentives 10:24 and pays the miners for the work that they are doing. 10:27 Now, Robin, last year when we met at this conference, 10:30 you weren't talking about BitVM at all. 10:32 You were talking about ZeroSync. 10:35 So what role do technologies like UtrexO and ZeroSync play 10:41 in making Bitcoin and sidechains more wieldy? 10:47 Yes. 10:48 ZeroSync was about applying snarks to the main chain 10:52 and essentially compressing the main chain 10:54 in a way that you can verify it on a phone or so, 10:58 or in general on weaker devices and weaker networks. 11:03 So full node on a phone, people. 11:05 I don't want to underlay the importance of what you just said. 11:09 So fully verifiable. 11:11 You can verify the validity of any transaction from your phone directly. 11:16 We have not implemented that yet. 11:17 The thing that we have implemented is more or less like an SPV client, 11:21 which is the basic version of it. 11:27 Proof systems have improved a lot in these two years, 11:30 and if we would start it from scratch now, 11:32 it would be much easier to implement a full chain state proof now 11:35 that actually can run a complete full node on any phone. 11:40 I think, to come back to your question, 11:44 if we had something like that, 11:45 we could probably also increase the block size with less risk. 11:51 That would be obviously a good thing for miners 11:53 because then we could have more transactions on the main layer 11:56 and more network effects. 11:58 So it's another way to decentralize 12:00 because there's less burden on nodes. 12:02 Well, yeah, and the same thing could be done for sidechains, too. 12:05 Make them lighter, more realty, 12:06 and then you could spread them across. 12:08 You've got multiple clients running on a single phone. 12:11 For sidechains, if you don't have BIP300, 12:13 it is actually a necessity that you prove the entire sidechain. 12:16 No, that's true. Yeah, okay. 12:18 Yeah. 12:19 That makes sense. 12:20 Because you cannot actually check what the state of the sidechain is 12:23 when you're doing a pegout, when you bridge back to the main layer. 12:26 Well, for bridging, yes. 12:29 But you could handle that with also SPV, correct? 12:32 Sorry? 12:33 Couldn't you handle that with SPV? 12:35 You can handle that with SPV to some degree. 12:41 If you would just have an SPV proof, 12:43 you'd create an incentive for miners to mine invalid SPV proofs, 12:48 just like a pegout that just didn't happen on the sidechain, 12:51 but gives the money to you. 12:53 Well, yeah. 12:54 You need it in order to mine, but not to transact, right? 12:58 I mean, it depends on what the pegout mechanism is. 13:00 If there is a dispute, it's possible to dispute. 13:02 Well, I'm talking about for just sidechain transactions on the sidechain, 13:06 not for pegouts. 13:07 I mean, the original sidechain paper by Blockstream had that idea, right? 13:10 Yeah. 13:11 That you use SPV proofs, 13:12 and they discarded that idea because of that toxic incentive 13:17 that a miner would just have to mine like some five blocks or so, 13:22 including one transaction that was just made up out of nowhere, 13:25 that doesn't have any history, 13:27 and it just gives the money to the attacker. 13:29 And essentially it means you can steal from the bridge if you have enough mining power. 13:34 And that is an issue. 13:36 And that is an issue that can be solved with SNARKs. 13:38 That's also why on the Adura platform we actually use a dual mechanism. 13:43 So it's not 100% informed, just only on proof of work. 13:46 There's also a federation consensus component that does reorg protection 13:52 and also validates via full nodes. 13:55 That's basically the same conclusion that Liquid came to, right? 13:58 Yeah. 13:59 Well, I mean, it's tradeoffs, unfortunately. 14:00 That's the best thing going. 14:02 That's why I'm hoping we can get there with better solutions like BitPM. 14:06 I honestly don't like that we have to run a federation. 14:09 It's just the best possible path now in order to get stuff shipped. 14:13 So, yeah. 14:14 It totally makes sense if you just want to go fast and ship something. 14:18 It's the best we have so far, and it works. 14:20 Back to the operative question of the talk. 14:22 What should we ship? 14:23 What makes sense? 14:24 What does Bitcoin need, right? 14:28 Maybe you want to talk about it. 14:31 I mean, I'm kind of repeating myself a little bit, though. 14:33 But, I mean, I have shipped a lot of stuff that I think people need. 14:37 If you go to LayerTwoLabs.com slash download, you can check it all out with plain money. 14:41 Yeah, which one of them should we do next? 14:43 We could talk about this. 14:45 Yeah, this is also this thing that I also came up with called the CUSF, the Core Untouched Soft Fork. 14:51 See, this is the thing is that the miners have not – 14:54 the soft fork is this great thing that has basically no downsides and innumerable upsides. 15:01 But for some reason, we have stopped doing it. 15:03 And so I've made it slightly easier to do, I guess is what I would say. 15:08 I mean, before, you'd have to do a pull request in GitHub to Bitcoin Core and have it merged, 15:14 which is like – could take years. 15:16 But instead, you can do the soft fork via its own little application. 15:19 It just rides along. 15:22 So I think that's a good idea. 15:24 I have shipped that also on this site, 5300cusf.com, C-U-S-F. 15:31 And then the sidechains that I think we need are these ones that I mentioned earlier in the day about scale, 15:37 scale, privacy, being able to mimic other chains that people like, such as Ethereum, assets, names. 15:47 I think all of that's important. 15:49 And I've shipped a lot of that already. 15:51 You can just try it for yourself. 15:54 So, Robin, I have a question just in general. 15:58 What would you say are the defining characteristics? 16:00 Everybody tends to lump all the VM stuff together, between like OP_CAT and Cat VM versus what's going on with BitVM. 16:07 I mean, I've been a big proponent of Cat until the Taproot Wizard started pushing it so hard. 16:20 I just don't trust these guys. 16:23 I don't see them as Bitcoiners. 16:25 I see them as like shitcoiners who are selling worthless tokens to people and like promoting spam, like audio notes and stuff like that. 16:35 And I see that as like the opposite of the stuff that I am interested in. 16:41 I don't think it gets us anywhere closer to beating the dollar. 16:47 So I got very skeptical of Cat. 16:49 But on the other hand, there are lots of people who are definitely legit, who are pushing for Cat now. 16:57 And it's a complicated topic. 17:03 I see a lot of potential in Cat. 17:05 I see all the things that we can do with Cat. 17:07 But I also see ways to abuse it. 17:11 And we have seen how the audio notes people have been abusing essentially Taproot to spam the chain. 17:19 I mean, as a miner, you probably like the fees. 17:21 What happened with SegWit and Taproot is just so ironic to me. 17:24 Because SegWit, none of this ordinal stuff would exist if it were not for the SegWit discount. 17:29 At all. Period. 17:32 And also for Taproot allowing you to inscribe 4 megabytes of data into the chain, right? 17:40 Yeah, again, unintended consequences. Very important. 17:45 My take on Eric and Udi, I think everyone has different skills or whatever. 17:51 I think they kind of like for some reason just took a guess that OP_CAT would be like the next easiest soft fork to do. 18:00 And so they kind of just got ahead of it. 18:02 I don't think they really even know or care that much about it. 18:06 How do you feel about OP_CAT, Paul? 18:08 I think the more important thing is that we have lost the ability to do the soft fork. 18:12 And so there's all these, like, you could refactor 10,000 lines of code and no one will care. 18:16 Or you could write tests on GitHub. 18:19 Or you could do something else. 18:21 You could do like, so like the Mac Corral's inflation bug was introduced as a result of a refactor. 18:27 There was really not a lot of discussion. 18:29 You can delete main.cpp from a C++ project and then put in the GitHub commit, this is real, 18:36 the lyrics to I Can Show You the World from Disney's Aladdin. 18:41 You can do all that weird stuff. 18:43 And you can accidentally cause inflation bug. 18:46 Or in the case of the level DB, the Berkeley DB, level DB, 18:50 you can cause the chain to actually crash and go down for like five hours. 18:54 Which is the only time that Bitcoin has ever gone down. 18:56 So there's many, many changes that are totally unscrutinized. 19:00 And yet, if you want to reactivate OP_CAT, which is an opcode that is already, 19:04 like, you know what I mean? 19:05 We've moved very, very far away. 19:07 We've been moving in the wrong direction culturally. 19:10 So like the whole reason the soft fork was invented back in 2012 is because we couldn't get everyone to upgrade. 19:16 So the soft fork is this thing where it's like, we don't need, this is a clever idea, 19:21 where we don't need everyone to upgrade. 19:23 Whoever wants to use the new feature upgrades, and then a 51% hash rate upgrades, 19:27 and it's safe for everyone to use. 19:29 Even people on the old network. 19:31 So we've had this idea of kind of tolerating conservatism while also allowing people to do what they want. 19:39 This kind of like, I don't know what you would call it, but maybe like a liberalism, 19:44 like a kind of live and let live thing. 19:47 And now we can't even do that because it's like, 19:51 So I think the bigger problem is just it's too hard to do any of these soft forks. 19:55 We mentioned Utrex-O, you get a mobile phone, full node on a mobile phone, 20:00 with the soft fork to have the Utrex-O commitment. 20:05 We could do the commitment to remove the need for the, whatever they're called, you know, the bridge. 20:10 We're overusing that word. 20:12 There's Relay, there's some kind of like secondary person that has to publish like a huge, 20:18 what do they call it? 20:19 I don't know. 20:20 Whatever it is, you could do the Utrex-O. 20:23 You could do, just forget Utrex-O, just any kind of Utrex-O commitment you could put into Coinbase. 20:29 And this would have some utility, you know, to a lot of, to like many, many people 20:33 because most people use SBB or something. 20:35 You could say, well, but no one wants to even talk about doing any of that. 20:40 And then you have what happened with CTV where Jeremy Rubin not only quit CTV, 20:44 but he quit Bitcoin until very recently. 20:46 Came back in multiple years. 20:47 Now he would spend multiple years away from Bitcoin. 20:49 He had to grow a beard. 20:50 It happens. 20:51 And he has shaved the beard, so now he's fully back, I guess. 20:53 He still has that mustache, though. 20:55 And APO was created as a lightning bit. 20:59 It checks all the boxes, right? 21:00 It's a lightning bit. 21:01 It was made by the right people. 21:03 It was on Signet. 21:04 I mean, it was on Inquisition or whatever. 21:07 So it did all these things. 21:08 It's many, many years and they're not pushing it, I think, just because no one knows how to do any soft fork 21:13 and no one wants to touch the soft fork. 21:16 So I think that, so you say, what do I think of OP_CAT? 21:18 It doesn't matter. 21:19 The soft fork category is the issue. 21:22 It's the soft fork part. 21:23 And that is why the CUSF idea, actually, I think, is the good idea. 21:27 That is C-U-S-F. 21:32 One thing that I'm concerned about is this general crackdown on crypto from governments. 21:38 I'm not sure exactly how it is here in the U.S. 21:42 I think Elizabeth Warren is trying things. 21:47 But in Europe, it's quite extreme. 21:49 Like the EU Parliament is going quite crazy on crypto and seeing these things. 21:57 I get a bit concerned about adding too much features to Bitcoin's script 22:01 because one thing that could happen is that at some point, 22:05 governments say that you cannot take your money from exchanges 22:10 except for to addresses which are fully KYC'd. 22:13 Yeah, that's very scary. 22:16 If you can impose that restriction at the protocol level, that's very dangerous. 22:20 And like perpetual KYC on the protocol level would be already almost possible with OP_CAT. 22:26 It's a definite concern. That could happen. 22:30 A handful of opcodes that are currently debated would definitely enable 22:35 essentially perpetual KYC on the base layer. 22:38 So like CTV, that's not a concern with CTV. 22:40 You can do that one time, but you couldn't do it recursively, right? 22:44 You need more dynamics. CTV would be too static. 22:47 But with OP_CAT, you could have like trees, 22:51 Merkle trees of addresses that you are allowed to send to. 22:54 And then let's say you have Opcheck from stack as well. 22:58 Then the government could sign routes of Merkle trees of addresses 23:03 which you are allowed to send to. 23:05 And OP_CAT would give you enough covenant introspection to check which amounts you're sending and everything. 23:10 There's no risk of anything like this with BitVM, right? 23:13 Well, BitVM in general cannot enable anything that is not possible already today. 23:24 There are always ways to abuse things, right? 23:31 In general, the entire community of bad people has not spent a year 23:35 of trying to do the worst with BitVM possible. 23:39 It just did not happen yet. 23:40 So we don't know the worst thing that can happen with BitVM. 23:44 And there's always unintended consequences. 23:46 There are always unknown unknowns. 23:50 I'm not sure what's the worst thing that BitVM can do, 23:54 but I'm very certain that a particular set of opcodes could enable very bad things on the main layer. 24:01 And the other thing is many of the new users like Blackrock 24:07 or the people with huge pockets, 24:10 they would not care at all if the base layer would enforce KYC all the time. 24:13 They would be happy about it. 24:14 They think regulation is a great thing and they just want to have digital gold 24:20 and they would not care if everything would be KYC all the time. 24:24 They would be happy about it. 24:26 Is there any hope now for just general Lightning as a scalability layer of Layer 1 Bitcoin? 24:39 I don't really see Lightning working as a scalability solution for end users. 24:42 And in particular, when fees are rising, and we hope that fees are rising to fix... 24:47 Fees have to rise eventually. 24:49 Otherwise, the miners will stop getting paid and the whole thing collapses. 24:53 And if fees are rising, then Lightning will become worse and worse for end users. 24:58 And to some point, it will not even be possible to enforce users' rights anymore 25:02 because you have to be able to pay on-chain fees to enforce your channel's rights. 25:06 Now whenever I hear anybody talk about Lightning, they talk about it as a settlement layer. 25:09 It's hilarious to me because seven years ago, 25:12 that's the way everybody started talking about Bitcoin. 25:14 They said, oh no, you'll use Lightning for payments. 25:16 No, no, Bitcoin's a settlement layer now. 25:18 So now we've come full circle and it's just settlement layers all the way down. 25:21 Yeah, I don't like that either. 25:22 I like Lightning in general. 25:23 I think it's a great technology, but it does not work for payments for end users. 25:27 Yeah, it's not a scaling apparatus. 25:29 It does a lot of things really, really well, 25:31 but scaling isn't one of them because of the fee problem. 25:36 You want to add something? 25:38 No, I agree completely with all of that. 25:40 I'm not sure that I would care so much about the... 25:43 I do actually think it's a... 25:44 I agree that we shouldn't add too much expressivity to L1 25:48 because it is possible to make really bizarre... 25:53 But I think that problem would actually solve itself 25:55 because it's quite possible to add functionality via soft fork, 26:02 but it's also very easy for miners to chip away, 26:05 like carving a marble statue or something. 26:07 It's pretty easy to go back in and just start disabling things. 26:10 So if something problematic arose, 26:13 I do think it would be easier to just delete, you know what I mean? 26:17 Like what Satoshi did when he removed OP_CAT. 26:20 What's the hard fork? 26:21 Well, that was only a hard fork, I think, as I understand it. 26:25 It was because that was the same commit that he added the opnops, 26:28 and the opnops are the hard fork. 26:30 So I think he tore out a bunch of... 26:32 He just said these are all banned, 26:33 and then the opnops are all new, and they always succeed. 26:38 That's what I remember, right? 26:41 It's kind of a minutiae thing. 26:43 Really? 26:44 What do you mean by that? 26:47 Well, it was certainly a hard fork 26:49 because he disabled something that was possible before. 26:57 So soft forks, I think Paul's right. 26:59 With soft forks, you can restrict functionality. 27:01 You can't expand functionality to prior nodes. 27:06 You can soft fork anything out of existence, 27:08 so you can't do that anymore. 27:11 That's how it would work if it contains OP_CAT. 27:15 Yeah, you're right. 27:18 So it would be interesting to have an old consensus. 27:22 We want it with OP_CAT still. 27:23 The old version of OP_CAT, but it's not tap or the dangerous one. 27:26 Oh yeah, there's a new... 27:28 There was some details about that. 27:31 It was a hard fork in the sense that it became incompatible. 27:35 Like the version that was before that fork is not compatible. 27:41 A soft fork is usually defined to be backwards compatible. 27:45 That's what I meant. 27:47 It's funny that I actually wrote a blog post 27:49 about how the terminology is screwed up 27:51 because there's actually three different dimensions 27:53 to whether or not something is a hard or soft fork 27:55 and people constantly switch between them. 27:57 And there's backwards compatibility, 27:59 and then there's whether or not it resolves itself 28:01 without the user having to do anything, 28:03 and then there's something else like whether or not 28:05 it is restricting the user. 28:07 But yeah, the terminology is actually terrible. 28:09 But the point that I was trying to make is that 28:13 if you add something terrible in, 28:15 you can probably get rid of it pretty easily. 28:17 So I wouldn't really be that worried 28:19 about the unintended consequences of adding the functionality to L1 28:23 because there are unintended consequences to just doing nothing. 28:27 I do think we would probably both agree 28:30 that we cannot just spend another ten years 28:33 doing whatever it is that we've been doing for the last ten years. 28:36 I think that is not good enough. 28:40 So let's talk more about Core Untouched Soft Forks. 28:47 Do you have a question or anything? 28:49 Yeah, I can try to give you a devil's advocate there. 28:52 Yeah, sure. 28:53 Yeah, please. 28:54 Okay, so do you want to give miners the power over the network now? 28:58 Is it now like a miner democracy 29:01 where it is decided by the people who have the most hash power? 29:06 Yeah. 29:07 The flip side of this is 29:09 do people actually really believe in proof of work at all 29:12 or is it just going to be some kind of communist bureau 29:15 that decides everything that happens? 29:17 But I think the miners have a special ability 29:22 over the activation of a soft fork. 29:24 And I think this has always been true. 29:26 And CUSF doesn't really change it, I think. 29:29 I think that it just states it more clearly, in fact. 29:34 So this is just... 29:36 There's a difference between when does something activate and how. 29:40 And then it will only really be part of the protocol 29:43 when lots of end users' nodes are enforcing it. 29:46 So I think those things are not really that different about CUSF. 29:49 The CUSF thing is just a very, very small idea 29:54 that's just about in what order should things happen. 30:00 And so it is about right now there's like a pocket veto and there's just like no one knows how to get the process started. 30:05 And no one knows who's responsible. 30:07 Generally, it's just safer to do nothing, right? 30:09 That's what it's viewed as. But I mean, if you do nothing for long enough, then there's a problem. 30:13 Then, you know, eventually you die, right? 30:16 But in the short run, it's always safer to do nothing, right? 30:19 So that's, I think, what the default is. 30:22 But exactly as you said, in the long run, if you do nothing, you will die. 30:26 So I don't know if that answers it. 30:29 The idea of giving more power to miners, it's like the miners are users. 30:34 So with the soft fork, unless you upgrade to the new software, you cannot use the new feature. 30:41 That's pretty normal. 30:43 But if the miners want to collect the transaction fee, they also need to be users of the new feature. 30:49 So it's just like people adopting software that they like. 30:56 It's not like some kind of... 30:57 They have no additional power over the protocol that was pre-CUSF, which is 99% of it. 31:06 So if I understand you correctly, miners just don't get much more power with the CUSF in comparison to regular... 31:14 I think it's a status quo. It's just a different way of describing it. 31:18 I think it's just a different way of describing the status quo. 31:21 The miners could always be the ones who... 31:23 They could be on GitHub releasing the next version of Bitcoin Core and then running it, right? 31:28 They could do that, but they just don't. 31:31 But there's nothing fundamental about that, you know what I mean? 31:34 That's like an ad hominem fallacy of the... 31:40 Actually, I wanted to play devil's advocate, but you didn't mention a very important point that I think you should add. 31:46 A strong counter-argument is, should we give the core devs the full power? 31:53 With the Communist Bureau, I was referring to them, so maybe it's a little too subtle. 31:59 But yeah, it's like someone is deciding, and right now they decide mostly what impresses their friends. 32:04 Really, though, that goes back to the definition of Bitcoin and continuity. 32:08 And it's like the core devs, even the core devs that exist now, 32:11 almost none of them are the same core devs that initially put SegWit through. 32:16 I think there is a very bad incentive, actually. 32:20 The miners have a very good incentive to keep the users happy and to generate transaction fee revenue. 32:25 They want... The more users, the more growth. 32:29 These are real users who pay real money. 32:31 We're going to need transaction fee revenue, because the block reward is going to keep going down. 32:36 It's a very good criterion to say, can we maximize the amount of money collected? 32:43 And whereas in Bitcoin Core, I don't know, the incentive is something else. 32:47 The incentive is like, can you come up with something really complicated that's very impressive, 32:50 and then you get a grant or whatever, or you get something. 32:55 And so I think that it is... 32:57 So it's just like everything else, it all boils down to incentives. 33:02 Maybe you could also say it takes away unwanted pressure from core devs, 33:08 because I feel like many core devs don't want to be the rulers of the system, not at all. 33:14 It's more like they shy away from controversial ideas. 33:17 Especially nowadays, I think. 33:20 Well, that's the impetus on them to not push it for any soft fork, 33:24 because then there's nothing controversial for them to have to deal with. 33:28 It kind of removes politics from core. 33:32 But I mean, it removes politics... 33:34 As we mentioned before, the story with APO is like, this is one where... 33:39 Built by them. 33:41 Built by the insiders, basically. 33:44 And the lightning thing, but they don't want to touch activation because they just don't... 33:50 Well, yeah, it wasn't built by... 33:52 Maybe some people would be so... 33:55 Can you tell us, is it? 33:57 Well, yeah, I'm just saying it's like from Bitcoin core universe, 34:01 from the Bitcoin dev mailing list, from the lightning universe. 34:04 But even that one is not... 34:06 That one, they just coded it, and then it just sits there on a shelf, being not activated. 34:16 So... 34:17 I see your point about they don't want the politics. 34:21 Yeah, I'm just saying it might be good for them. 34:24 It might be diminishing their role, but giving them the role that they actually want. 34:32 Well, sooner or later, decisions have to be made about what's going to be done. 34:37 It's nice to work on projects for years that have minorly meaningful optimizations, 34:44 but eventually, either things are going to stay exactly the same they are now, 34:48 or they're going to have to change, and they will be. 34:52 I don't know, it's just getting to the point where I'm not seeing anybody asking 34:56 and trying to actually take up these issues at my core level. 34:59 They just kind of throw up their hands and say, 35:01 oh, we'll decide when we have consensus. 35:03 And we never reach consensus because nobody's tackling anything. 35:07 I don't know. 35:09 Here's one thing about CUSF, though, that probably the both of us like, 35:14 but maybe you don't. 35:15 It does push some of the responsibility onto the mining pool, such as Marathon. 35:19 So it's like, you guys can just decide now if you run the software or not. 35:23 So now, you can just say, ah, there's no consensus or whatever, 35:27 but now it's your decision to make, not yours personally. 35:33 Marathons, maybe. 35:34 Well, there is something to be said to have somebody to appeal to, 35:37 as we do in the current system. 35:40 Yeah. 35:42 You know to whom your grievance should be addressed. 35:46 That is an advantage of this, where it's like, 35:49 you know that the answer is no until 51% pools say yes, 35:54 so that you at least know where you are. 35:56 I actually had an idea. 35:57 I published a little stupid Medium article way during the block size war, 36:01 and I always wanted to see if it would work. 36:05 What if you created a wallet that tracked actual transactor sentiment 36:09 as to whether they won or something by the amount of transaction they spent? 36:14 So that way, the miners could tell how the people who are paying them fees 36:17 actually think and feel, rather than Twitter. 36:22 I don't know. 36:23 As a miner, you could actually measure it, right? 36:25 Because as a miner, you see how much of these fees you actually get yourself. 36:28 Right. 36:30 It's distributed kind of randomly, but yeah. 36:33 But that is the point. 36:34 Because otherwise, the metric could be gamed. 36:36 If another miner that has a lot of hash power would just game the metric 36:39 by inserting transactions that pay themselves, 36:42 then you would never get that, and then you would not get that signal. 36:45 But money that is paid to you is no lie. 36:49 Nobody can lie about that. 36:51 So that is a very high signal. 36:52 Exactly. 36:53 Because if you're only monitoring things you know that cannot be gamed. 36:56 Unless people want to pay you money, in which case you don't care if it's gamed or not. 36:59 They're paying you money. 37:01 I think another interesting thing is that it's actually not possible for miners 37:07 to activate arbitrary soft forks. 37:09 Let's say the miners wanted to activate a soft fork 37:13 that increases the block reward or something. 37:16 Then users would resist that a lot. 37:19 So the incentives for miners are aligned to activate soft forks 37:24 only if users actually support it. 37:26 They have very low incentive to try to push a soft fork against the user's will. 37:32 And I feel like in that regard, the incentives are quite well aligned with CUSF. 37:38 Thank you guys. 37:39 It's been a wonderful panel, 37:40 but I think we should try to take some questions from the audience if possible. 37:43 Oh yeah, sure. 37:44 Ask any questions. 37:47 Don't be shy. 37:48 Ask a question. 37:51 If you want. 37:54 Okay, thanks. 37:55 Nobody was expecting, well, maybe nobody, 37:58 but the whole Ordinals improvement to DRC-20 is part of that. 38:02 And I'm detecting the feeling that the core community is not going to want to see 38:08 something go off the rails again. 38:10 There's an obvious question about that. 38:12 Couldn't we see like two or three years of ossification here 38:16 before a new BIP really got approved? 38:18 I actually think that Ordinals is a negative consequence of ossification. 38:23 So it's actually if we had had normal progression in development 38:28 and also normal developer community that actually cared about 38:31 what the end users who pay a fee, those are the real customers. 38:37 If the developer community actually cared about those people, 38:41 they would have long ago built something or promoted something that worked for them. 38:45 And we could have solved all the earlier problems. 38:48 So like Counterparty was like a very early version of this. 38:50 Everything that was on an altcoin was originally on Bitcoin, 38:53 like years ago in like 2011, 2012. 38:56 So like all this stuff, Ordinals, Runes, 38:59 it's like almost an offshoot of ERC-20 on Ethereum, 39:02 but that was an offshoot of Counterparty and colored coins 39:05 and all this other stuff that's ancient on Bitcoin itself. 39:09 But what happened was in Bitcoin, 39:11 the developers have a lot of contempt for the user. 39:15 They have a lot of hatred for the user, 39:17 and they don't want to build something that the user likes. 39:19 And so Counterparty and these other things were suppressed, 39:23 partially for good reasons, because they did have negative... 39:26 But the point is if you actually put engineering effort 39:29 and human creativity into that, 39:33 you could address what didn't work 39:35 while still giving the end user what they did want. 39:38 And so if we had done that, 39:40 there would never have been an Ethereum in the first place, 39:42 and there would never be any Runes or Ordinals on L1 either, 39:45 because everyone would already have gotten what they wanted 10 years ago. 39:48 But instead, we have this weird other thing. 39:51 So I kind of don't think it works that way. 39:53 And I do think Ordinals and Runes, again, 39:56 this is another thing where it's like 39:59 you can't get the thing that you want directly, 40:01 so you get it very indirectly 40:03 at a way that is interfering with L1's normal operation. 40:09 So I have a very different view on that. 40:12 I don't know if you share that view or not. 40:16 Yeah, I totally agree that Ordinals is a symptom 40:19 of mainchain fees being too low, 40:22 and that is a symptom of the system not being useful enough, 40:26 and that is a symptom of the system not being scalable enough. 40:30 So in that regard, I totally agree. 40:37 I think it's a distraction. 40:39 It kind of distracts the Bitcoin community 40:42 from the actual core goal that we should have, 40:45 which is establishing Bitcoin as a currency worldwide. 40:51 But yeah, maybe in hindsight, 40:53 it was a good thing to shift the overtone window, 40:56 to change the discussion in different directions 40:59 and make people think about other things. 41:04 I agree that it is. 41:06 The whole topic kind of is a distraction. 41:10 The one good thing that came out of it 41:12 was that there was so much ossification, 41:15 and then Ordinals and Runes were like someone doing something new 41:18 and something fun, and people actually liked that. 41:21 So weirdly... 41:24 Anyway, feel free to ask anything else. 41:29 Ask a question, everyone. 41:31 Some critics of Bitcoin under its chain 41:34 say that it's caused deep reworks, 41:37 and the miners are stealing the sidechain 41:40 and using it as an opportunity for merchants to prevent that. 41:43 Is that a deep rework? 41:45 Yeah, that's just like incorrect, 41:47 and it's kind of like a weird thing that people think about that. 41:50 But what would actually happen in the timeline of events 41:53 is like miners preemptively declare 41:55 that they will destroy the BIP300 sidechain, 41:58 and then users preemptively declare 42:00 that they will not allow that transaction in the block in the future. 42:05 So nothing has happened for many months. 42:07 Like three months later, there will be the moment of truth 42:10 when the transaction tries to make it into the block. 42:13 At this point, anyone who has voluntarily, 42:16 who is already a user of BIP300, 42:18 who has voluntarily decided to UASF the transaction, 42:22 this is already like a much smaller percentage then. 42:25 Everyone who is just ignoring it completely 42:28 and going about their lives, nothing will happen to them. 42:31 But these people, if they were using BIP300 sidechain, 42:35 and they tried to do the UASF, 42:37 and the miners tried to destroy the chain, 42:40 and the miners are successful 42:43 in attracting 51% hash rate to their cause, 42:46 and they're not deterred at all by the fact 42:48 that they will lose the entire stream 42:50 of transaction fee revenues and blah, blah, blah, 42:52 no one stops them. 42:54 If all of those things happen, 42:56 what will happen is the people who do the UASF 42:58 will just be stuck in a chain that never finds a block again 43:01 until they give up. 43:03 So there will never be a reorg ever under any circumstances. 43:06 And the only thing that will happen is that people who have chosen to... 43:09 The other thing I would mention is that actually the UASF 43:12 is a contradiction because despite the name, 43:15 it must either be a hard fork or it must be driven by miners. 43:19 So if you have a situation where the user has minority hash rate, 43:24 they are then breaking the heaviest valid chain rule, 43:28 which is in principle no different than breaking the 21 million coin limit 43:32 or the block size limit. 43:34 So they're breaking the heaviest valid chain rule in one specific way. 43:38 It also has the same property as a hard fork 43:41 in that only the people who have done this activity 43:44 will find themselves on the new network. 43:46 Everyone who's doing nothing, 43:48 which is going to be 99% of the people, 43:50 will just be doing nothing and ignoring all of this. 43:52 All of those people will find themselves on whatever the heaviest chain is. 43:55 So there will never really be a reorg. 43:58 And if there is, it's just because people have decided 44:01 that they want to reorg for some reason. 44:03 You know what I mean? 44:04 Like they could always just decide, 44:06 I don't like this block has the hex spells out a certain thing 44:09 and now we want to reorg or something. 44:11 It's not really... 44:12 The other thing is that risk of reorg is always a part of Bitcoin anyway. 44:15 So it's in... 44:17 There's no such thing as like being free of the risk of a reorg. 44:20 So even in that case, it's not because of BIP300. 44:25 To cement his argument, 44:27 just to spice up the discussion a bit, 44:30 it is definitely true that BIP300 would change the miners' incentives 44:36 in a sense that if 51% of the miners... 44:41 60%? How much is it? 44:44 75. 44:45 If 75% of the miners would collude 44:48 and decide to rob a sidechain, 44:51 they could just do that. 44:53 They could just vote to process an invalid pegout 44:59 that gives the money to them, 45:01 stealing all the money from the sidechain users. 45:04 And that is true. 45:05 But that would not change the layer 1 incentives, right? 45:08 Right, exactly. 45:09 So that is true that the sidechain can fail that way, 45:12 but I see that as actually sort of a good thing in a way. 45:15 The whole theory behind Drivechain is that 45:18 the transaction fees from the sidechain 45:21 will be more than enough to offset whatever can be stolen. 45:25 And the reason why this is likely is because, 45:28 first of all, no one will use a sidechain that doesn't have that property. 45:31 It's kind of like if you open a restaurant. 45:33 Will the restaurant make enough money 45:35 so that you don't rip out the copper wires and the piping or something like that? 45:39 Start a restaurant and not every restaurant is going to succeed, 45:43 and that's actually a good thing. 45:44 That is how we make sure that the list of sidechains is only the good ones. 45:48 And no one should use a sidechain at first. 45:50 You should just wait and see if it is actually viable first. 45:54 But the turnover and the stock and the flow are different things. 45:59 So you could deposit like 2 Bitcoin to a sidechain, 46:02 and over there, there could be this huge turnover 46:05 so that millions of people are using it. 46:08 They each pay a tiny transaction fee, 46:11 and 1.5 out of that 2 Bitcoin ends up as transaction fees for the miners. 46:17 There's only 0.5 left. 46:19 But you got an unbelievable amount of use out of it, 46:22 millions or trillions of people. 46:25 Just maybe as a thought experiment, 46:27 I would bring up like you put two coins into a desert island 46:32 that has two gold coins. 46:34 They can circulate like a million times. 46:36 So the fact that there's only two coins on the island, 46:38 it doesn't mean anything about the limitations. 46:40 So the reason I bring that up is just to say 46:43 the two coins, that's what the miners can steal and destroy. 46:46 But what they have to gain is potentially much more than that. 46:53 But essentially it's a change in the sense that you can say 46:56 if someone has enough hash power, they can steal from the sidechain. 47:00 So there would also be an incentive to collude. 47:05 Yeah. 47:07 Well, I don't know about it. Maybe. 47:09 If so, if they destroy all the sidechains, 47:12 we'll just be back to where we were now. 47:14 So again, it's kind of weird if that's considered a change. 47:17 We'd be changed, just changed back to where we, the current status quo. 47:21 I think we have another question. 47:23 Yes. 47:24 Hey. 47:25 It's been a long time. 47:29 Excuse me. 47:32 I'd like to hear your expert opinions 47:35 on how it relates specifically to Drivechains 47:39 and also VPN. 47:41 Can you answer it? 47:42 Yes. 47:43 In case someone in the chat did not get to know us. 47:46 Like, do you like how it relates to the work with VPN and Drivechains? 47:54 I see you're wearing their hats. 47:56 Are you in their team? 47:58 You're just a fan. 48:00 Okay. 48:04 I didn't have time to really look into it. 48:07 In particular, BitcoinOS, 48:08 I think they have not open sourced their code yet, 48:11 which is hard to assess then for me as a developer. 48:18 I mean, I know the people behind that. 48:22 I know they are doing interesting things. 48:26 But I cannot say right away how good it is. 48:31 Of course, I'm super psyched that people are working on it, 48:35 that people are investing developer resources 48:38 into building BitVM kind of like things. 48:42 That's cool to see. 48:43 I'm, of course, very happy to see my child grow. 48:49 But I would be careful with these things. 48:51 Like, it's quite easy to announce something 48:53 and it's really hard to build something 48:54 that actually works in practice. 48:58 The other thing is, as far as I know, 49:01 they are using the BitVM 1 model. 49:04 zk-SNARKs. 49:05 Yeah, zk-SNARKs. 49:07 But it's not true? 49:10 Sorry? 49:11 It's Google. 49:12 Ah, okay. 49:13 Yeah, they're using the BitVM 1 model. 49:16 And that was the same model that we started out with. 49:20 However, we came to the conclusion 49:23 that it's quite hard to build efficient bridges with it. 49:26 Like, to verify a snark is the one thing, 49:29 but the other thing is to actually use that snark in a bridge 49:32 to bridge Bitcoin to other systems. 49:35 And our conclusion was that BitVM 1 is a bit too complex, 49:40 or BitVM 1 bridges in particular are a bit too complex. 49:43 And that's why we went back to the drawing board 49:46 and reconsidered everything 49:47 and came up with a BitVM 2 design that we are working on right now. 49:50 And that is definitely... 49:52 Four weeks! 49:54 ...that we will hopefully release within the next few weeks, 49:56 the first prototype version of it. 49:58 Let's get one more question. 50:04 My question was to Osbert. 50:08 Why don't you go directly to banks to get Bitcoin? 50:13 No, that is... 50:18 In a way, CUSF sort of is doing that, in a way. 50:22 The miners, though, are like, you know, 50:24 they're just committed to just, like, blah, blah, blah, 50:26 saying, like, we'll look into it later, or whatever. 50:28 Even though it makes them hundreds of billions of dollars in the future. 50:31 But I think that that is the healthier thing, 50:35 because... 50:37 But the miners are very interested in, like... 50:40 They have, like, a focus on just getting cheap power. 50:42 They're, like, very narrowly focused, I think. 50:44 They're not really... 50:46 These things are like a palace affair to them, or something. 50:48 It's like it's... 50:50 Maybe you know, like... 50:52 So, like, in a way, I... 50:54 Okay, yeah. Do you have something else to say? 50:57 Okay. 50:59 One thing is, of course, they risk a chain split. 51:02 Like, if somebody were to use a resisted soft fork, 51:06 then the chain could split. 51:07 And in general, I think miners don't want to see 51:11 any funny business in that direction. 51:14 And that's why they're hesitant. 51:16 You just say you want to enforce it 51:18 until there's a super-majority hash rate. 51:20 I mean, that's like a solvable problem, right? 51:22 Then you will never get the actual split. 51:25 Only the user-resisted... 51:27 Again, that's like... 51:28 Again, this is really... 51:29 The UASF really is a hard fork, 51:31 because you just put yourself on your own network 51:33 with whoever else is running the new software with you. 51:35 It's the threat of a hard fork. 51:37 Yeah, yeah. 51:38 So, I think that's a very, very, very, very empty threat. 51:42 It's very silly. 51:43 But maybe. I don't know. 51:45 I think, in general, just a lot of people 51:47 have to wrap their heads around a lot of things. 51:49 I don't have an answer for you. 51:51 I mean, I think the miners should do it, 51:53 activate it unilaterally. 51:55 They should activate all these soft forks unilaterally, 51:58 which they can't do easily. 52:01 Microphone. 52:03 Oh, sorry, Eric. 52:05 Yeah, because of the fact that 52:07 consensus rules aren't enforced by 52:09 node-runners and the economic acquisition network, 52:11 the miners are going to be just trusting themselves 52:14 to not kind of... 52:15 Hey, we're going to kind of back out of this. 52:17 Yeah. 52:18 We might start not applying... 52:19 But first of all, that's very likely to work. 52:21 And second of all, it's not strictly true either, 52:23 because as soon as someone else runs 52:27 the same software that's enforcing the rules, 52:29 you have, like, all the miners plus one person, 52:31 and you have... 52:33 The miners have no way of knowing 52:35 the exact date and time that Coinbase 52:37 or some exchange decides to actually run. 52:39 So it's actually... 52:41 Even if it was only miners, 52:43 it would still be likely to work, 52:45 because the miners have no real way 52:47 to defect out of the coalition 52:49 without stabbing each other in the back 52:51 an endless number of times. 52:53 But then they also don't know 52:55 who else is enforcing the new soft fork rules. 52:57 So I don't actually... 52:59 I think that would... 53:01 Even that, which is a very, very, very extreme 53:05 way of activating the soft fork, 53:07 I think that would work just fine, actually, 53:09 if you actually made me guess. 53:13 Iago? Yeah, we got something? 53:15 So this is pure hearsay. 53:17 I just looked up, and so you guys 53:19 don't get any surprises. 53:21 You have the... 53:23 He was asking about it. 53:25 Hey, you have the hats. 53:27 Just asking about the news. 53:43 I'm not saying to be careful 53:45 about any BitVM things. 53:49 I think I said explicitly 53:51 that I'm happy to see people building 53:53 BitVM-like things. 53:55 I just said I'm careful about announcements 53:57 when I don't see the code. 54:09 We have a tech talk 54:11 on the open-source stage tomorrow. 54:13 We also want to provide 54:15 a deep dive into 54:17 growth. We were thinking about 54:19 doing it at the Dare to Growth 54:21 tomorrow night. 54:23 Can you get this work out? 54:27 I know the other announcement 54:29 from Rootstock. 54:33 Also, full disclaimer, 54:35 I like the guys from Rootstock as well. 54:37 I think they're doing interesting things. 54:39 They have committed 54:41 interesting contributions 54:43 to our code base as well. 54:47 Unfortunately, I didn't have time 54:49 to follow the announcement because I was traveling. 54:51 What I saw was 54:53 that they said they're ready. 54:55 There were a couple of questions. 54:57 They said they're ready 54:59 except for these two things 55:01 and some minor other things. 55:07 I see the marketing point of things, 55:09 but on the other hand, 55:11 I think 55:13 having things that 55:15 are useful to people in practice, 55:17 that is what we should be about. 55:19 Whoever does that 55:21 first should have 55:23 the glory and the honor.