1 00:00:30,560 --> 00:00:37,560 and I'll have 30 minutes. So, we're going to do 15 minutes of this kind of background lead-up 2 00:00:37,560 --> 00:00:43,640 to the problem, and about me and the context and the things that I think are important, 3 00:00:43,640 --> 00:00:47,960 and then five minutes on this thing, and then I do think the Q&A is really where the magic 4 00:00:47,960 --> 00:00:51,840 happens, so I think that Q&A is good. I'm going to say some pretty audacious things 5 00:00:51,840 --> 00:00:56,700 in this talk, so it's only fair that people get to ask questions about them, but I do 6 00:00:56,700 --> 00:01:02,580 have a kind of a long intro slide. So, I spoke at all three of the first scaling conferences. 7 00:01:02,580 --> 00:01:06,980 I was on the program committee for the fourth. This conference is supposed to be continuing 8 00:01:06,980 --> 00:01:12,980 in that vein, but what happened after the first three, or really even the first two, 9 00:01:12,980 --> 00:01:18,900 is that the scaling conferences quickly became pretentious academic junk conferences, so 10 00:01:18,900 --> 00:01:24,820 I stopped going, and I think this conference is also in danger of falling into that mold, 11 00:01:25,340 --> 00:01:31,740 although there were some good talks, but the other thing is that in December 2013, see, 12 00:01:31,740 --> 00:01:36,620 this is actually all important, because it's very difficult for you to understand why CUSF 13 00:01:36,620 --> 00:01:42,260 is the solution to something unless you understand me and sort of where I'm coming from, so all 14 00:01:42,260 --> 00:01:48,220 this is actually important, but back in December 2013, I had this peer-to-peer Oracle prediction 15 00:01:48,220 --> 00:01:53,020 market blockchain technology that I called Truthcoin, which was supposed to be a side 16 00:01:53,020 --> 00:01:59,500 chain L2, even back in 2013, which I quickly renamed to BitcoinHiveMind.com, and you can 17 00:01:59,500 --> 00:02:03,700 actually go to that site, and you can still look at it if you want. I had to rename it 18 00:02:03,700 --> 00:02:08,500 because people thought it was an altcoin, but this project basically became Polymarket. 19 00:02:08,500 --> 00:02:13,460 In fact, Polymarket is a much worse version of what I produced in 2013, but although I 20 00:02:13,460 --> 00:02:19,500 give them tons of credit for executing, but it just, this speaks a little bit to what 21 00:02:19,500 --> 00:02:26,340 a lot of this talk is about, which is that we've had a little bit of slow developer action 22 00:02:26,340 --> 00:02:34,500 that has translated to, you know, billions of dollars per month in lost volume, and so 23 00:02:34,500 --> 00:02:40,580 that's part of what I'm trying to get at here. Then, so the reason why this never turned 24 00:02:40,580 --> 00:02:45,500 on was because the company Blockstream that planned to deliver on peer-to-peer sidechains, 25 00:02:46,380 --> 00:02:51,340 they sort of never actually delivered on that, and so that's, this next thing is that after 26 00:02:51,340 --> 00:02:57,100 they failed to deliver that technology, I had to do it myself, which began as this essay 27 00:02:57,100 --> 00:03:02,180 measuring decentralization from September 2015, and then it later became the StriveChain 28 00:03:02,180 --> 00:03:06,180 blog post, and then it became BIP300 today, and that's part of what I'm going to talk 29 00:03:06,180 --> 00:03:13,300 about in a little while. And then furthermore, I did this presentation in June 2016 called 30 00:03:13,300 --> 00:03:18,860 sidechain Privatization, which basically anticipated not only MEV, but also the more 31 00:03:18,860 --> 00:03:25,380 complicated cross-chain MEV, and this led to an invention called Blind Merged Mining 32 00:03:25,380 --> 00:03:32,060 in January 2017, which later became BIP301, and which today would be known as Proposer-Builder 33 00:03:32,060 --> 00:03:38,900 Separation, and what this does is it automatically converts all L2 block value, including the 34 00:03:38,980 --> 00:03:44,820 transaction fees, any indirect value, DEX, arbitrage, whatever, it transforms all of 35 00:03:44,820 --> 00:03:50,220 that value into L1 transaction fees, and miners don't even need to look at what is happening 36 00:03:50,220 --> 00:03:55,460 on the L2, which is hence the name Blind, and then there's more stuff, but it's not 37 00:03:55,460 --> 00:04:00,580 really important, so. Okay, I have a very different take, which I'm going to explain 38 00:04:00,580 --> 00:04:07,300 now on this L2 situation, which is this is the endgame for Bitcoin as I see it. These 39 00:04:07,300 --> 00:04:11,780 circles are to scale, which is why I used the monospace font here to get them to scale, 40 00:04:11,780 --> 00:04:15,580 but the left circle is, you have to understand what I'm getting at here, which is a little 41 00:04:15,580 --> 00:04:20,940 hard to explain, but the left circle is all the transaction fees paid to miners in the 42 00:04:20,940 --> 00:04:27,900 year 2022, and the next one over is the fees in 2023, which was the ordinal's year, and 43 00:04:27,900 --> 00:04:33,220 the third one is back in 2022, all of the fees collected by all altcoins that are not 44 00:04:33,220 --> 00:04:38,980 Bitcoin, and then this gigantic circle all the way on the right is the value of all the 45 00:04:38,980 --> 00:04:45,620 transaction fees paid on earth in 2022 if they were on Bitcoin, and so this is an estimation 46 00:04:45,620 --> 00:04:49,060 that I made, so of course I have to admit that I sort of eyeballed it, but I did look 47 00:04:49,060 --> 00:04:54,340 at quite a few things. I looked at the credit card company statistics, I looked at WeChat 48 00:04:54,340 --> 00:04:59,500 pay, I looked at the Federal Reserve, there's a payments study, and I have a huge blog post 49 00:04:59,500 --> 00:05:05,220 where I go into the details in writing, which I'm going to reference later in the talk, 50 00:05:05,220 --> 00:05:09,780 so you'll be able to look it up if you're interested, but basically I came up, you know, 51 00:05:09,780 --> 00:05:13,820 I looked at like population of the world that is over 14 years old, and all this other stuff, 52 00:05:13,820 --> 00:05:21,820 so it's basically 6.4 trillion dollars in 2024, you know, trended back to 2022, and 53 00:05:21,820 --> 00:05:26,620 then the 10 cents for transaction, because that's very low, and it's significantly lower 54 00:05:26,620 --> 00:05:31,980 than basically everything else that exists, and it's so low, but you see once you get 55 00:05:31,980 --> 00:05:36,620 to 10 cents, someone can only undercut you by around 9 cents per transaction, and I thought 56 00:05:36,620 --> 00:05:40,900 that's probably not enough to get people to switch networks, so that's kind of, I just 57 00:05:40,900 --> 00:05:44,700 eyeballed it as the equilibrium fee, but people are free to use whatever numbers, but the 58 00:05:44,700 --> 00:05:49,940 point is it's a huge amount, and the other thing is it doubles in value, it grows at 59 00:05:49,940 --> 00:05:59,540 6.2% a year, it probably goes faster than that, that's the lowest estimate, it's something 60 00:05:59,540 --> 00:06:06,420 like, yeah, it's something like 3 per day per person above, yeah, it's per year, right, 61 00:06:06,420 --> 00:06:17,220 so this doubles every 11 to 12 years, yes, okay, so why do I bring this up? Well, okay, 62 00:06:17,220 --> 00:06:22,300 the first question is a very important one, which is, if Bitcoin took over the world, 63 00:06:22,300 --> 00:06:28,420 who would get this giant pile of money? And the current intellectual climate is pushing 64 00:06:28,420 --> 00:06:36,540 these non-mined L2s, which would include the Lightning Network, ARK, Rollups, Liquid, these 65 00:06:36,540 --> 00:06:41,900 are not mined L2s, and by that I mean the transaction fees on the L2, they do not go 66 00:06:42,060 --> 00:06:47,780 to the L1 Bitcoin miner, instead they go to someone else, they go to the Lightning Node 67 00:06:47,780 --> 00:06:54,740 that routed the payment, or they go to the LSP, or they go to the ARK SP, or they go 68 00:06:54,740 --> 00:07:00,660 to the sequencer, the Rollup sequencer, so the money goes to someone else, and of course 69 00:07:00,660 --> 00:07:04,260 that's kind of rude to the miners, but that's not really why I bring it up, it's really 70 00:07:04,260 --> 00:07:10,420 much worse than that, it's actually very, very interesting what will probably happen, 71 00:07:10,420 --> 00:07:14,820 and my guess, this is a complete guess on my part, but I don't see how it can be any 72 00:07:14,820 --> 00:07:21,780 other way other than to produce this horrendously unstable situation that will end in a conflict 73 00:07:21,780 --> 00:07:30,580 between the L1 and L2 overall, and a huge incentive for miner centralization, and then 74 00:07:30,580 --> 00:07:36,300 eventually vertical integration between the L2s and the L1 miners, and then this vertical 75 00:07:36,300 --> 00:07:42,100 integration will utterly obliterate the entire L2 security model in the first place, the 76 00:07:42,100 --> 00:07:47,820 L2 will end up fully custodial, possibly even miner custodial, and then the value will all 77 00:07:47,820 --> 00:07:55,580 become MEV in fact, I have a little bit more to say about that later, so the reason that 78 00:07:55,580 --> 00:07:58,940 I bring, let me explain a little bit more about this, which is to say, so the miners 79 00:07:58,940 --> 00:08:02,580 get this tiny circle, and then there's this huge circle above going to like the ARK Super 80 00:08:02,620 --> 00:08:08,660 Node or something, the reason why this is actually important is that the miners have an extreme 81 00:08:08,660 --> 00:08:17,340 ability to affect the L2s, every L2 is vulnerable to 51% attack by L1 miners, for example, the 82 00:08:17,340 --> 00:08:21,780 Lightning Network requires a L1 transaction to join the network, and it requires one to leave 83 00:08:21,780 --> 00:08:27,060 the network, and the Lightning Network only works at all if you can broadcast justice transactions 84 00:08:27,060 --> 00:08:33,420 to L1 whenever you want, and the 51% hashrate group can censor these transactions, and if you 85 00:08:33,420 --> 00:08:37,660 don't believe me, here's Rene Picard, who wrote the book Mastering Lightning, he's saying 86 00:08:37,660 --> 00:08:43,140 exactly what I'm saying here, and this is the same for BitVM, where BitVM has like a justice 87 00:08:43,140 --> 00:08:48,460 transaction that is basically something like, if someone does something that they would not be 88 00:08:48,460 --> 00:08:55,860 allowed to do in the L2, you pull this on L1 and you can slash their bond or whatever, the 89 00:08:55,860 --> 00:08:59,940 different L2s are very different from each other, of course, but no matter what the L2 is, the 90 00:08:59,940 --> 00:09:06,660 miners can block the entrance and the exit, if they can figure out what it is, so there's some 91 00:09:06,660 --> 00:09:12,900 little bit of animosity would go a long way, so basically if we return to this example where you 92 00:09:12,900 --> 00:09:18,780 have like something like a Foundry LSP, you know, or Antpool LSP, a Foundry Lightning on one hand, 93 00:09:18,780 --> 00:09:25,180 versus the Lightning Nodes that are not backed by giant amounts of hashrate, then it would be 94 00:09:25,180 --> 00:09:29,820 completely understandable for the actual end user to get nervous about using the non-mined 95 00:09:29,820 --> 00:09:36,980 LSPs, because they would not be secure, and the HTLC would really do nothing, and eventually the 96 00:09:36,980 --> 00:09:42,380 non-mined, you know, the non-miner associated LSPs would go out of business, and everyone would use 97 00:09:42,380 --> 00:09:49,060 a minor LSP, all the HTLC stuff would be superfluous, and the Lightning security model wouldn't even 98 00:09:49,060 --> 00:09:53,900 apply in this case anymore, and the interesting thing is that all of this, the whole L2 value of 99 00:09:53,900 --> 00:10:00,900 a giant sphere, or a giant circle, that would all become MEVs, since it would now become mandatory 100 00:10:00,900 --> 00:10:06,140 to become a Lightning service provider, it would now, every viable miner would have to become an 101 00:10:06,140 --> 00:10:11,380 LSP, and they would have a monopoly as well, because it would be very difficult to start a 102 00:10:11,380 --> 00:10:16,260 new Lightning company now, and on the flip side, it would be difficult to start a new mining pool, 103 00:10:16,260 --> 00:10:23,820 so it would really be some kind of like super MEV, and so the bizarre thing, ironically, the only way 104 00:10:23,820 --> 00:10:29,140 to undo the MEV at that point would be to create a mined L2, and then hope that everyone switches 105 00:10:29,140 --> 00:10:34,100 to it, and so even if the ones on the left had succeeded, they would end up, we would end up 106 00:10:34,100 --> 00:10:41,580 wishing that they had failed. In other words, the non-mined L2s are not going to work. They may 107 00:10:41,580 --> 00:10:47,940 work in the superficial sense of the software not crashing, or the software being able to put 108 00:10:47,940 --> 00:10:53,660 transactions through, for some people, but I think this means that they can never really be big, you 109 00:10:53,660 --> 00:10:57,340 know, they can never really be a big success, because as soon as they're a big success, they'll 110 00:10:57,340 --> 00:11:01,820 never really be this, you know, this huge circle. As soon as they are, miners will think, why am I 111 00:11:01,820 --> 00:11:06,220 getting this tiny circle, and the LSP is getting this huge circle. We can talk about why the tiny 112 00:11:06,220 --> 00:11:12,860 circle will probably stay tiny on L1, but it's a different question, and then people think, miners 113 00:11:12,860 --> 00:11:18,580 will think, well, why don't we start our own, you know, mining LSP, foundry LSP, and then they get 114 00:11:18,580 --> 00:11:25,620 into a fight, and it is a battle where one of the sides doesn't have any bullets. So instead, here's 115 00:11:25,620 --> 00:11:33,820 my proposal for the mined L2s, which I'm now calling 1313, due to a math coincidence, but the 116 00:11:33,820 --> 00:11:39,580 details are in two blog posts of mine that are very old. I mean, this one is from February 2021, 117 00:11:39,580 --> 00:11:47,340 but basically it's a very small L1 block size that we have already, and then 13 separate L2s 118 00:11:47,420 --> 00:11:53,660 distributed amongst users on the planet, more or less geographically, each released one at a time 119 00:11:53,660 --> 00:11:59,820 as the previous ones fill up, and they start with what is the equivalent of 13 megabytes, a block 120 00:11:59,820 --> 00:12:04,700 size that grows over time for each of them, and then this is the other one here. This is this post, 121 00:12:04,700 --> 00:12:10,300 all the world's transactions, where I talked about the estimates for, you know, how many transactions 122 00:12:10,300 --> 00:12:17,580 are actually in the world on a given year, and it has this table, and I have them, if they grow at 123 00:12:17,580 --> 00:12:24,060 those rates, and then it converges to a planetary scale by the year 2030, which is a 9.8 trillion 124 00:12:24,060 --> 00:12:31,620 transactions per year, and so that is this schedule, and this idea, from the end user's 125 00:12:31,620 --> 00:12:37,620 point of view, is better than Lightning, which is, you know, the viable L2 today, in the following ways. 126 00:12:37,620 --> 00:12:41,540 I'm not going to list them all, but I'll list a few, which is like, it has, there's no channels, there's no 127 00:12:41,540 --> 00:12:47,140 interactivity requirements at all, there's no liquidity problems at all, there's no, like, fee for 128 00:12:47,140 --> 00:12:53,740 liquidity, as with ORC, you can onboard people directly to L2 without using L1 bytes, and the payments 129 00:12:53,740 --> 00:13:04,260 don't fail, and of course, 100% of the fees are passed down to miners instead of 0%. It actually has 130 00:13:04,260 --> 00:13:10,140 more benefits also, it actually slightly improves miner centralization by allowing faster and smaller 131 00:13:10,140 --> 00:13:17,340 cashouts to, from pools to the end hashers, and furthermore, it does not require any changes to 132 00:13:17,340 --> 00:13:23,460 Bitcoin Core at all, but it does require this thing, CUSF, which I am going to get to eventually, pretty soon. 133 00:13:23,460 --> 00:13:32,820 So, and on top of that, we just, I love the dev tooling talk, that's great, the software already 134 00:13:32,820 --> 00:13:39,780 exists today, so here it is, we've built it, actually, and it even has a little GUI there, up in the top 135 00:13:39,780 --> 00:13:47,140 right, so it has a wallet, it has interface, Bitcoin Core, the L1 is in the bottom left, and then the L2 136 00:13:47,140 --> 00:13:54,100 thing is in the top right, you can't really see it right now, but this is the new CUSF version, in fact, so 137 00:13:54,100 --> 00:14:00,620 now, I think I have a little bit to get through what this is, it's, I think it's going to be kind of 138 00:14:00,620 --> 00:14:05,380 difficult to understand, you know, but I'm going to try to explain it anyway, so, because some people will 139 00:14:05,380 --> 00:14:09,780 think this is such a small idea, it doesn't count as anything, and other people will think this is so drastic 140 00:14:09,780 --> 00:14:16,980 an idea that it is, so I don't know what you'll find yourself in, but, CUSF stands for Core Untouched Soft 141 00:14:16,980 --> 00:14:25,620 Fork, and it threads the needle between these two roadblocks, and one of them is this, which is that Bitcoin 142 00:14:25,620 --> 00:14:33,380 Core cannot soft fork anymore, these numbers are from BitMEX research, they are not mine, but I put them in 143 00:14:33,380 --> 00:14:40,220 this table, and this is a table of soft forks in Bitcoin's history, and you can see that we used to do one every 144 00:14:40,220 --> 00:14:49,860 two years or so, and now we do basically zero, I also took the opportunity to look up the time it took to get from 145 00:14:49,860 --> 00:14:58,260 the first, you know, concrete mailing list suggestion of the idea, to when it was coded, and then when it was 146 00:14:58,260 --> 00:15:06,340 actually activated, and so you can see SegWit was 20 months, and Tapper was 46 months, and I think if you have been 147 00:15:06,700 --> 00:15:12,740 paying attention today, you see that there's all these ideas, but everyone has this, for whatever, every single idea 148 00:15:12,740 --> 00:15:19,260 that someone has put forward, that's like someone's least favorite idea, and so there is no actual consensus on 149 00:15:19,260 --> 00:15:27,100 anything, and so that is why there's this logjam here. So this is the first roadblock. The second roadblock, though, is 150 00:15:27,100 --> 00:15:31,420 that you really cannot just switch away from Bitcoin Core to something else, that's too drastic of a change for a 151 00:15:31,420 --> 00:15:42,340 variety of reasons, like to leave the, for a completely different client, it might disconnect you from the network, 152 00:15:42,340 --> 00:15:49,940 and it might, you might wonder, like, who is going to maintain this in the long run, so you can't do that type of thing, 153 00:15:49,940 --> 00:15:57,540 there's no way to actually compete with Bitcoin Core with the second client. One reason is that they have these CVEs that 154 00:15:57,540 --> 00:16:02,660 are only disclosed to them, they're the only ones who know about these security vulnerabilities, which they sort of must 155 00:16:02,660 --> 00:16:14,980 keep secret, and so this is just one reason among many why you cannot write a competing client, basically. And so this solution 156 00:16:14,980 --> 00:16:19,940 here is that you keep Bitcoin Core completely unchanged, and you just keep, it's almost like a dependency or something, you just 157 00:16:19,940 --> 00:16:26,300 have it there, doing its thing, same thing it did before, and then you release a second piece of software that manages the 158 00:16:26,300 --> 00:16:33,580 soft fork only, and that is called, you know, that would be the QCEV activator or something, so after Bitcoin Core scans the 159 00:16:33,580 --> 00:16:42,020 block, it passes the block to, like, the OP_CAT activator, for example, it scans the block again, and then if there's any OP_CAT 160 00:16:42,020 --> 00:16:49,500 rule-breaking over there, that's the only thing it's scanning for, second time, then it tells Bitcoin Core to reject the block, and 161 00:16:49,500 --> 00:16:57,100 this makes the soft fork, you know, it's much faster, safer, easier to understand. It's safer in particular because it's a little bit 162 00:16:57,100 --> 00:17:03,220 more reversible, you don't have to, like, restart the mining operation, you just add the second piece of software, and then if the 163 00:17:03,220 --> 00:17:09,460 second piece of software is low quality, or if it crashes or something, then it's just, like, not there. The soft fork temporarily 164 00:17:09,460 --> 00:17:17,100 deactivates in that situation, but it doesn't have, it doesn't affect any, doesn't have to affect anything that is currently running. I 165 00:17:17,100 --> 00:17:26,340 mean, it's a nuanced question, but. Yeah, and so also, this is a paper here. I stashed it at this site. This is just a site that I 166 00:17:26,340 --> 00:17:36,020 grabbed quickly, bit300qcev.com. There is a paper there, you can check it out. This thing, the ordinalization of soft forks, I don't 167 00:17:36,020 --> 00:17:41,220 know if that will help people understand or make it more confusing, but, like, ordinals are, like, you have the existing thing and 168 00:17:41,220 --> 00:17:48,340 then you run a second thing that helps you make more money, and this is similar in that way, so I don't know. It's not exactly the same, 169 00:17:48,340 --> 00:18:01,300 but. And we have the software already. I did do it for BIP300/301, and I also did it for OP_CAT, the bit 347 version that we heard 170 00:18:01,300 --> 00:18:10,060 about earlier today. So the software already exists, and you can fork this software, and you can make a CTV activator or whatever, if you 171 00:18:10,060 --> 00:18:19,060 wish. Okay, let's see. Okay, good. I have almost 20 minutes exactly, so I think I'm going to, I think I will do this slide, though, which is 172 00:18:19,060 --> 00:18:25,500 that, okay, this, in one sense, this is really no different than how any other soft fork would activate, but in another way, it's very, very 173 00:18:25,500 --> 00:18:33,740 different, so. It has the same effect as a soft fork. I think one interesting thing about this idea is that most people don't understand what a 174 00:18:33,780 --> 00:18:43,660 soft fork is or what it's doing, and as a result, this is like the best way of explaining to someone what a soft fork actually is and why it's, you 175 00:18:43,660 --> 00:18:54,380 know, mostly harmless. But it has the same effect, but there's two different software, you know, demons, and there's, it is inefficient in the 176 00:18:54,380 --> 00:19:02,220 sense that the computer basically has to do twice as much work as to scan all the blocks a second time, but it's more efficient in the sense of 177 00:19:02,220 --> 00:19:10,140 humans because we don't have to get a pull request through Bitcoin Core because they do not want to do any controversial pull request ever, and as 178 00:19:10,140 --> 00:19:20,940 you can see, it's very easy to just manufacture controversy even about things that are objectively harmless. So I guess I think I will sneak this 179 00:19:20,940 --> 00:19:30,380 last one in here. So again, so just to get it into three bullet points, I think the idea is miners run this, to scale Bitcoin, you know, miners run 180 00:19:30,380 --> 00:19:40,460 this BIP300 accusive activator, Bitcoin Core continues to do nothing, which they're very good at that, so, and then once 51% hashrate is running it, 181 00:19:40,460 --> 00:19:45,980 then this will activate. It will only activate for as long as they are running it, and then of course regular people can run the activator with their own 182 00:19:45,980 --> 00:19:57,260 node also to do that, to validate the rules, which would be the full node in that case. And then the miners activate these mined L2s and they collect money 183 00:19:57,260 --> 00:20:06,860 from them, and then Bitcoin has scalability, privacy, etc. And I have to compare this to, the alternative plan is to take the same people who for years have 184 00:20:06,860 --> 00:20:14,940 been overly optimistic about the viability of lightning, and then wait for them to finish ARK or whatever, or some other thing where there's not even dev tooling 185 00:20:14,940 --> 00:20:24,540 for it yet, which is going to be way worse for the end user, and it's more complicated and more expensive, and it may not work at all, and then such that even if it did 186 00:20:24,540 --> 00:20:33,340 work, the miners won't get any money, which will lead to this conflict that I mentioned before, and then that will lead to this total collapse of the original 187 00:20:33,340 --> 00:20:42,300 security model anyway, and then all of that is even if we, if it takes too long for us to actually finish this, Bitcoin might be replaced by something else, 188 00:20:42,300 --> 00:20:51,260 because we can go very slow for a long time, but until we actually have, if it's possible to get 8 billion users of a certain coin, and then other people are trying to do 189 00:20:51,260 --> 00:21:00,380 that as quickly as possible, and we don't, then that doesn't look great for us. So I think, yeah, I have tons of extra slides, and I have even more stuff, but I would like, I think the 190 00:21:00,380 --> 00:21:05,420 questions are far more important, so if you don't ask any questions, I will do random slides. 191 00:21:05,980 --> 00:21:07,980 Or let them know about the issuers. 192 00:21:08,460 --> 00:21:10,460 You can maybe just yell it out, I can repeat it. 193 00:21:10,460 --> 00:21:19,980 Okay, so my question is with the CUSF implementation, what about the fragility of having an additional client working through the RPC, connecting to Bitcoin Core, 194 00:21:19,980 --> 00:21:25,100 to then validate once, after they come in, to make sure that any rules are invalidated? 195 00:21:25,100 --> 00:21:33,580 Couldn't that be three scenarios where essentially you as a miner are kind of switching your validation logic on and off, depending on if the program is working properly? 196 00:21:33,660 --> 00:21:35,660 That's the point. 197 00:21:35,660 --> 00:21:37,660 You don't have to restart the whole server. 198 00:21:37,660 --> 00:21:39,660 You just have to restart the server here. 199 00:21:39,660 --> 00:21:41,660 Yes, the question, if people didn't hear it. 200 00:21:41,660 --> 00:21:43,660 You enforce the rule. 201 00:21:43,660 --> 00:21:45,660 It goes down, right? 202 00:21:45,660 --> 00:21:47,660 It's a very good question. 203 00:21:47,660 --> 00:21:49,660 It's a very good question. 204 00:21:49,660 --> 00:22:00,620 The question was, I think, if I heard it correctly, was, doesn't this, we have now a second P, instead of it all being in one Bitcoin Core, you have it in a few things, if one crashes, and the other people's done, 205 00:22:00,700 --> 00:22:06,700 and once it was on, then won't there be inconsistently enforced rules, and then maybe there'll be like a fork or something. 206 00:22:06,700 --> 00:22:14,700 Yeah, so the key thing to keep in mind about that is that that is accurate, but that is actually true of every soft fork. 207 00:22:14,700 --> 00:22:16,700 It's just this implementation. 208 00:22:16,700 --> 00:22:26,700 So I think, in a sense, you're right that how it is implemented may affect whether or not the implementation is reliable. 209 00:22:26,780 --> 00:22:34,780 But I think that the bigger issue is like, okay, let's think about it a little bit more like this. 210 00:22:34,780 --> 00:22:40,780 The new soft fork is just, this is not like something where you're going to keep releasing a new version every three months. 211 00:22:40,780 --> 00:22:46,780 This activator will just do like the OP_CAT 15 lines of code, and so it will be like a finished product. 212 00:22:46,780 --> 00:22:54,780 So it was kind of like, it will either crash at first, or it will be a finished project, I think. 213 00:22:54,860 --> 00:22:58,860 I don't know if that answers the, I know, this is a very new kind of weird thing. 214 00:22:58,860 --> 00:23:04,860 To rephrase that question as a comment, and then I'll make it a question, I guess. 215 00:23:04,860 --> 00:23:08,860 This is a terrible idea to have a separate piece of software, especially if it's something like Python, 216 00:23:08,860 --> 00:23:16,860 because if you do succeed in getting the soft fork activated, then that Python code with whatever subtle bugs it has 217 00:23:16,860 --> 00:23:22,860 becomes consensus, and somebody like Bitcoin Core will have to then reimplement it in C++ and make it permanent. 218 00:23:22,940 --> 00:23:26,940 But kind of what I would suggest here is if you want to activate a soft fork this way, 219 00:23:26,940 --> 00:23:32,940 just make a patch of Bitcoin Core, and yes, your pull request might never get merged, 220 00:23:32,940 --> 00:23:36,940 but you can always just release your own Bitcoin Core version that says like, 221 00:23:36,940 --> 00:23:42,940 this is identical to Bitcoin Core version 3.29.0 with only this new opcode added. 222 00:23:42,940 --> 00:23:46,940 The reason why that will not work is because of the rebasing. You have to constantly rebase. 223 00:23:46,940 --> 00:23:48,940 Yeah, rebasing and opcode is not that hard. 224 00:23:48,940 --> 00:23:50,940 I disagree. 225 00:23:51,020 --> 00:23:53,020 We've been in here to ask. 226 00:23:53,020 --> 00:23:57,020 I would say that if you can do that, you should not be doing soft forks. 227 00:23:57,020 --> 00:23:59,020 I refuse to accept this critique. 228 00:23:59,020 --> 00:24:07,020 The rebasing is like an endless vampiric draw on whoever wants to do something new. 229 00:24:07,020 --> 00:24:09,020 See, this is the issue. 230 00:24:09,020 --> 00:24:11,020 The issue is that the existing thing doesn't work. 231 00:24:11,020 --> 00:24:13,020 And the other thing is, I had this in extra slides. 232 00:24:13,020 --> 00:24:17,020 I know I'm like scamming people now with this, that I would do questions. 233 00:24:17,100 --> 00:24:19,100 I read this paper, which is a very cool paper. 234 00:24:19,100 --> 00:24:21,100 I read it on the train ride up here. 235 00:24:21,100 --> 00:24:25,100 And this is what we've been hearing a lot today about like, 236 00:24:25,100 --> 00:24:27,100 should we adopt the soft fork and like twiddling little, 237 00:24:27,100 --> 00:24:32,100 it's like, I don't know, we're changing the temperature on the faucet or something a little bit. 238 00:24:32,100 --> 00:24:34,100 But to me, this is a matter of life or death. 239 00:24:34,100 --> 00:24:40,100 Either we aggressively pursue innovation and adoption as quickly as possible, 240 00:24:40,100 --> 00:24:44,100 or we will probably eventually be replaced by something that does. 241 00:24:44,100 --> 00:24:46,100 So this is like a cheap alarmist thing. 242 00:24:46,180 --> 00:24:51,180 But I don't really see it this way of like, do this, do that, or whatever. 243 00:24:51,180 --> 00:24:55,180 I just think like this is like a huge mistake and a huge risk for no reason. 244 00:24:55,180 --> 00:24:58,180 And so we need something that actually works to draw in people who want, 245 00:24:58,180 --> 00:25:01,180 people like Jeremy, he can't be up here making a slide that says, 246 00:25:01,180 --> 00:25:04,180 I've been doing CTV for the last 800 years and nothing has happened. 247 00:25:04,180 --> 00:25:08,180 And then now later on, we decide, oh, covenants are great. 248 00:25:08,180 --> 00:25:11,180 No one was talking, Jeremy was talking about covenants like whatever, 249 00:25:11,180 --> 00:25:13,180 like in 2016 or something. 250 00:25:13,260 --> 00:25:16,260 And now everyone has decided, we can't wait. 251 00:25:16,260 --> 00:25:19,260 We have to do something where there's the risk. 252 00:25:19,260 --> 00:25:23,260 This is the whole point of this idea is it concentrates the risk in the new software 253 00:25:23,260 --> 00:25:28,260 and it does not, it has no interaction with the existing software. 254 00:25:28,260 --> 00:25:34,260 We cannot have people forced to explain it to Bitcoin Core 255 00:25:34,260 --> 00:25:37,260 because people in Bitcoin Core, no offense, you know, they don't get it. 256 00:25:37,260 --> 00:25:39,260 But you're describing two separate problems here, right? 257 00:25:39,260 --> 00:25:41,260 One is to get a change through that you want 258 00:25:41,340 --> 00:25:44,340 and maybe not everybody in Bitcoin Core wants it. 259 00:25:44,340 --> 00:25:47,340 And the second is implementing that change. 260 00:25:47,340 --> 00:25:50,340 So the first part, like if people don't want it, that's one discussion. 261 00:25:50,340 --> 00:25:54,340 But if you implement it in Python, which it sounds like what you're doing. 262 00:25:54,340 --> 00:25:56,340 No, it's not in Python at all, it's in Rust. 263 00:25:56,340 --> 00:25:58,340 Fine, you can put it in Rust. 264 00:25:58,340 --> 00:26:01,340 But the point is that that change is going to be there for eternity if it succeeds. 265 00:26:01,340 --> 00:26:04,340 And so somebody will have to execute that Rust code for eternity. 266 00:26:04,340 --> 00:26:06,340 I don't think that it necessarily should be. 267 00:26:06,340 --> 00:26:09,340 I actually think we should be a little more experimental with the software 268 00:26:09,420 --> 00:26:11,420 because they don't need to be there for eternity. 269 00:26:11,420 --> 00:26:14,420 Because imagine if the software crashes and is abandoned, 270 00:26:14,420 --> 00:26:16,420 then all it means is that the software deactivates 271 00:26:16,420 --> 00:26:18,420 and anyone who tried to use it loses money. 272 00:26:18,420 --> 00:26:22,420 But that's no different than the way the Lightning Network worked for like five, six years 273 00:26:22,420 --> 00:26:24,420 where it was like in a state of being half-completed 274 00:26:24,420 --> 00:26:26,420 and people would lose money all the time. 275 00:26:29,420 --> 00:26:32,420 Okay, clearly very fruitful for discussion. 276 00:26:32,420 --> 00:26:36,420 A lot of questions, but I'm sorry, we're going to have to move on to the next one. 277 00:26:36,500 --> 00:26:41,500 So, sorry Marshall, sorry Trey, sorry anyone else who has any questions. 278 00:26:41,500 --> 00:26:45,500 But if you do, grill Paul out in the hallway over there 279 00:26:45,500 --> 00:26:48,500 or in the conference room on floor 14. 280 00:26:48,500 --> 00:26:51,500 Also there's coffee out there now for anyone who needs a little bit of a pickup. 281 00:26:51,500 --> 00:26:55,500 But with that, thank you Paul, appreciate your thoughts.