1 00:00:00,000 --> 00:00:08,820 So yeah, I just like have some examples of that. 2 00:00:08,820 --> 00:00:15,000 I talked about this Futarki in 2018, the top center there. 3 00:00:15,000 --> 00:00:19,360 And that went on to become like now Polymarket is very big, and this is very big in Solana, 4 00:00:19,360 --> 00:00:25,000 where they have this Futarki DAO, it's like $75 million, and Polymarket did $1.5 billion 5 00:00:25,000 --> 00:00:27,120 in trading. 6 00:00:27,120 --> 00:00:32,000 And then I talked about this MEV type of topic in 2019. 7 00:00:32,000 --> 00:00:35,640 I called it sidechain leeching back then. 8 00:00:35,640 --> 00:00:37,880 And now we just had a whole thing about that. 9 00:00:37,880 --> 00:00:43,240 But I did actually completely solve that problem back in January 2017. 10 00:00:43,240 --> 00:00:45,420 And even earlier, in fact. 11 00:00:45,420 --> 00:00:48,440 But I guess some people are still unconvinced. 12 00:00:48,440 --> 00:00:52,600 And then I did talk about Drivechain at TabConf in 2021. 13 00:00:52,600 --> 00:00:56,920 And then I did the debate with Peter Todd last year. 14 00:00:57,720 --> 00:01:02,160 Now, there are a lot of altcoin versions of that that were very bad, or they just became 15 00:01:02,160 --> 00:01:04,480 some kind of scam or something. 16 00:01:04,480 --> 00:01:11,080 But there is a decent one in Ethereum called Eigenlayer, and it just raised $100 million 17 00:01:11,080 --> 00:01:13,120 from A16z. 18 00:01:13,120 --> 00:01:16,920 So with all that in mind, I'm going to today talk about soft forks. 19 00:01:16,920 --> 00:01:21,160 And this is going to build off of some very much earlier work that I did in the past, 20 00:01:21,160 --> 00:01:26,580 and the talk I did at MIT last year. 21 00:01:27,240 --> 00:01:29,060 And so here's the agenda, which is that the intro. 22 00:01:29,060 --> 00:01:30,060 We're done with that. 23 00:01:30,060 --> 00:01:31,580 I kind of really like that Q&A. 24 00:01:31,580 --> 00:01:35,740 So I think maybe one of these 10-minute ones, I'll cut way short, and then maybe there'll 25 00:01:35,740 --> 00:01:37,700 be 20 minutes of Q&A at the end. 26 00:01:37,700 --> 00:01:41,620 But then I'm going to talk about some basics and some more advanced things, a lot about 27 00:01:41,620 --> 00:01:43,180 the history of the soft fork. 28 00:01:43,180 --> 00:01:49,700 And then I will talk about this thing, CUSF, the Core Untouched Soft Fork, which is like 29 00:01:49,700 --> 00:01:53,380 a new kind of a new thing, and then Q&A. 30 00:01:53,380 --> 00:01:56,180 So before that, though, I have this one slide about me. 31 00:01:56,180 --> 00:01:59,060 And I'm the author of BIP300/301. 32 00:01:59,060 --> 00:02:01,540 Those are collectively known as Drivechain. 33 00:02:01,540 --> 00:02:06,500 I run a technical Bitcoin blog called Truthcoin.info. 34 00:02:06,500 --> 00:02:09,700 And I'm also the founder and CEO of LayerTwo Labs. 35 00:02:09,700 --> 00:02:12,060 And I did not ask them to put the sign here, but here it is. 36 00:02:12,060 --> 00:02:14,260 It's very nice looking. 37 00:02:14,260 --> 00:02:17,220 So that was created December 2022. 38 00:02:17,220 --> 00:02:21,340 But we have already produced the following pieces of software. 39 00:02:21,340 --> 00:02:22,940 We have our own test net. 40 00:02:22,940 --> 00:02:29,260 We have the CUSF enforcer for not only BIP300, 301, but also for OP_CAT, in case anyone 41 00:02:29,260 --> 00:02:30,260 cares. 42 00:02:30,260 --> 00:02:31,260 Oops, sorry about that. 43 00:02:31,260 --> 00:02:32,260 Changed the style. 44 00:02:32,260 --> 00:02:37,460 And we have a sidechain L2 that emulates Zcash, which is like a million times better than 45 00:02:37,460 --> 00:02:40,180 CoinJoin for privacy. 46 00:02:40,180 --> 00:02:45,340 We have an L2 that emulates Ethereum called EthSide, basically just Ethereum on Bitcoin. 47 00:02:45,340 --> 00:02:48,940 That would be Matt Corral's worst nightmare, except that it has Blind Merged Mining. 48 00:02:48,940 --> 00:02:51,500 So the L1 miners would never even see it. 49 00:02:51,580 --> 00:02:56,460 They'd just see that they're getting more money, and they don't really care why. 50 00:02:56,460 --> 00:03:01,460 We have a version of Namecoin on Bitcoin called BitNames, and we have L2 for token and token 51 00:03:01,460 --> 00:03:03,500 trading called BitAssets. 52 00:03:03,500 --> 00:03:08,020 And then we have a set of large block sidechains that could scale to 8 billion users tomorrow 53 00:03:08,020 --> 00:03:11,300 that I call Thunder as a kind of joke. 54 00:03:11,300 --> 00:03:15,580 And I also have a new GUI for Bitcoin Core, because I really don't like the existing GUI. 55 00:03:15,580 --> 00:03:19,260 So that's the intro. 56 00:03:19,260 --> 00:03:20,820 And I do have a lot of strong opinions. 57 00:03:21,140 --> 00:03:22,140 I'm well known for this. 58 00:03:22,140 --> 00:03:25,060 I'm always pulled onto the unpopular opinions panel for things. 59 00:03:25,060 --> 00:03:28,860 But I do think that all these things on the right are basically a distraction and a waste 60 00:03:28,860 --> 00:03:33,180 of time distracting from Bitcoin's mission to take over the world. 61 00:03:33,180 --> 00:03:38,060 And Lightning, Ardcoin, CoinJoin, DLCs, Bitcoin Core itself, I think that they are a waste 62 00:03:38,060 --> 00:03:39,060 of time. 63 00:03:39,060 --> 00:03:40,900 Sorry about that. 64 00:03:40,900 --> 00:03:41,980 OK. 65 00:03:41,980 --> 00:03:46,220 So now I'm going to review some basics of the soft fork. 66 00:03:46,220 --> 00:03:48,700 I don't know why the lights keep moving up and down. 67 00:03:48,700 --> 00:03:53,220 It seems very ominous. 68 00:03:53,220 --> 00:03:54,660 This is how powerful the soft fork is. 69 00:03:54,660 --> 00:04:00,700 It can bend light in hue and color. 70 00:04:00,700 --> 00:04:02,980 OK. 71 00:04:02,980 --> 00:04:03,980 So yeah, these are some basics. 72 00:04:03,980 --> 00:04:05,420 You probably already know this. 73 00:04:05,420 --> 00:04:08,940 But actually what's up here is not perfectly accurate, as we will see. 74 00:04:08,940 --> 00:04:13,180 But it is the conventional wisdom, so it is a great starting point. 75 00:04:13,180 --> 00:04:18,420 The conventional wisdom is that the soft fork tightens the rules, and the hard fork loosens 76 00:04:18,540 --> 00:04:19,540 the rules. 77 00:04:19,540 --> 00:04:22,540 But that is not completely true. 78 00:04:22,540 --> 00:04:25,540 Guys, what are you doing over there? 79 00:04:25,540 --> 00:04:29,540 I would seriously like to know. 80 00:04:36,100 --> 00:04:39,100 Yeah. 81 00:04:39,100 --> 00:04:42,100 OK. 82 00:04:42,100 --> 00:04:45,100 All right, great. 83 00:04:45,100 --> 00:04:48,100 OK. 84 00:04:48,100 --> 00:04:49,820 Yeah, so that's the conventional wisdom. 85 00:04:49,820 --> 00:04:52,420 But you see there's a second competing definition, which 86 00:04:52,420 --> 00:04:55,380 is that there's an optional discretionary upgrade 87 00:04:55,380 --> 00:05:00,420 versus an immediate and mandatory upgrade. 88 00:05:00,420 --> 00:05:02,740 And those two are kind of in conflict with each other, 89 00:05:02,740 --> 00:05:05,220 actually, as we'll see. 90 00:05:05,220 --> 00:05:06,740 So these are some famous soft forks. 91 00:05:06,740 --> 00:05:09,220 So in August 2010, Satoshi took a bunch 92 00:05:09,220 --> 00:05:12,060 of messages that you could previously broadcast in Bitcoin. 93 00:05:12,060 --> 00:05:14,180 And he banned all these so that they would no longer 94 00:05:14,180 --> 00:05:16,980 be acceptable in the blockchain. 95 00:05:16,980 --> 00:05:21,020 And that tightened the rules, as you can see. 96 00:05:21,020 --> 00:05:23,220 And it's also the case that regular users who 97 00:05:23,220 --> 00:05:24,860 didn't upgrade could just upgrade later 98 00:05:24,860 --> 00:05:25,860 whenever they wanted to. 99 00:05:25,860 --> 00:05:27,460 So it satisfies both bullet points. 100 00:05:30,180 --> 00:05:34,980 And then September 2010, Satoshi added the infamous block size 101 00:05:34,980 --> 00:05:36,940 limit of one megabyte. 102 00:05:36,940 --> 00:05:41,500 He's shrinking the block size, tightens the rules. 103 00:05:41,500 --> 00:05:44,980 That would be a soft fork, and then 104 00:05:44,980 --> 00:05:47,020 increasing the block size of the hard fork, 105 00:05:47,020 --> 00:05:48,980 loosening the rules. 106 00:05:48,980 --> 00:05:53,620 I have these examples at the bottom, 107 00:05:53,620 --> 00:05:56,380 which are the infamous attempted hard forks, all of which 108 00:05:56,380 --> 00:05:56,880 failed. 109 00:06:00,020 --> 00:06:01,340 The block size limit increased. 110 00:06:01,340 --> 00:06:02,460 That was a big drama. 111 00:06:02,460 --> 00:06:07,700 SegWit2x, and then BCH, which became its own community. 112 00:06:07,700 --> 00:06:10,460 So this is the basics. 113 00:06:10,460 --> 00:06:12,660 And now I'm going to bring up four things that I think 114 00:06:12,660 --> 00:06:14,700 are really not widely known. 115 00:06:14,700 --> 00:06:16,940 And they get to the heart of what the soft fork is. 116 00:06:16,940 --> 00:06:18,440 And this is a very important issue, 117 00:06:18,440 --> 00:06:21,300 because I've got a couple of slides in where this is a very, 118 00:06:21,300 --> 00:06:22,740 I'll come back to this in a second. 119 00:06:22,740 --> 00:06:24,300 But this is a hotly debated issue. 120 00:06:24,300 --> 00:06:25,700 It's like, what is a soft fork? 121 00:06:25,700 --> 00:06:27,820 Both people disagree on whether or not something 122 00:06:27,820 --> 00:06:29,460 counts as a soft fork or not. 123 00:06:29,460 --> 00:06:31,700 But they also disagree as the core essence. 124 00:06:31,700 --> 00:06:35,140 So this is Adam Back and Luke Dashjr. disagreeing. 125 00:06:35,140 --> 00:06:37,900 But I'll get back to that in a second. 126 00:06:37,900 --> 00:06:42,260 So yeah, so Gavin called these, for those of you 127 00:06:42,260 --> 00:06:45,660 who don't know, Gavin sort of, Satoshi kind of handed 128 00:06:45,660 --> 00:06:48,140 the reins to Gavin, kind of. 129 00:06:48,140 --> 00:06:51,460 And he was like the sort of leader for a little while 130 00:06:51,460 --> 00:06:52,380 in 2010. 131 00:06:52,380 --> 00:06:56,140 And Gavin wrote this in 2012. 132 00:06:56,140 --> 00:06:57,700 He used the word changes. 133 00:06:57,700 --> 00:06:59,820 So he said, there are soft rule changes 134 00:06:59,820 --> 00:07:01,460 and there are hard rule changes. 135 00:07:01,460 --> 00:07:07,220 And the point of this is that he says, when he says, 136 00:07:07,220 --> 00:07:09,180 at this point, he's saying something like, 137 00:07:09,180 --> 00:07:11,540 at this point, it is much more difficult or impossible 138 00:07:11,620 --> 00:07:13,700 to roll out hard changes. 139 00:07:13,700 --> 00:07:15,940 And when he says, at this point, he's 140 00:07:15,940 --> 00:07:19,500 talking about June 29, 2012. 141 00:07:19,500 --> 00:07:23,380 And so that was quite a long time ago. 142 00:07:23,380 --> 00:07:26,700 And ironically, Gavin would later attempt himself 143 00:07:26,700 --> 00:07:30,260 to do the hard fork block size increase change. 144 00:07:30,260 --> 00:07:31,580 And he would fail exactly the way 145 00:07:31,580 --> 00:07:34,300 that he predicted that he would. 146 00:07:34,300 --> 00:07:35,300 So that was ironic. 147 00:07:35,300 --> 00:07:37,460 But what I want to convey here is 148 00:07:37,460 --> 00:07:40,500 that something is forbidden on the grounds of impracticality. 149 00:07:40,540 --> 00:07:42,300 It's almost like the software can't do it, 150 00:07:42,300 --> 00:07:44,420 the laws of physics don't permit it, or whatever. 151 00:07:44,420 --> 00:07:45,940 So money has these network effects 152 00:07:45,940 --> 00:07:47,220 and people don't want to split. 153 00:07:47,220 --> 00:07:49,260 So this is going to be a very important idea. 154 00:07:49,260 --> 00:07:52,220 Now, first I have this. 155 00:07:52,220 --> 00:07:53,860 This is the second of the four things 156 00:07:53,860 --> 00:07:55,300 that people don't really consider, 157 00:07:55,300 --> 00:07:59,220 which is that when people say hard and soft fork, 158 00:07:59,220 --> 00:08:02,540 we actually aren't really referring to a visual fork 159 00:08:02,540 --> 00:08:03,980 at all, which is very strange. 160 00:08:03,980 --> 00:08:08,940 These are normal culinary fork, tuning fork, fork in the road. 161 00:08:08,980 --> 00:08:11,060 But actually, when there's a soft fork, 162 00:08:11,060 --> 00:08:13,020 there really is no split. 163 00:08:13,020 --> 00:08:15,820 It's just like the purple just becomes blue or whatever 164 00:08:15,820 --> 00:08:17,660 and there is no red part. 165 00:08:17,660 --> 00:08:21,740 And even when the community upgrades via hard fork, 166 00:08:21,740 --> 00:08:22,980 they abandon the old network 167 00:08:22,980 --> 00:08:25,940 and so there isn't a fork in that sense either. 168 00:08:25,940 --> 00:08:29,780 So this is something of a puzzle in the sense of like, 169 00:08:29,780 --> 00:08:31,500 why does it have the word fork? 170 00:08:33,500 --> 00:08:35,100 Given that there is no visual fork 171 00:08:35,100 --> 00:08:37,380 and that is what I'm going to explain. 172 00:08:37,540 --> 00:08:39,140 I have actually tracked it down. 173 00:08:39,140 --> 00:08:41,180 There's a very satisfying answer to that question. 174 00:08:41,180 --> 00:08:43,020 You would think, what is going on? 175 00:08:43,020 --> 00:08:47,460 But this is the first ever usage of the term soft fork 176 00:08:47,460 --> 00:08:48,380 that I could find. 177 00:08:48,380 --> 00:08:50,260 I looked really hard. 178 00:08:50,260 --> 00:08:52,860 And this is five months after Gavin's remark 179 00:08:52,860 --> 00:08:55,620 about hard and soft changes. 180 00:08:55,620 --> 00:08:57,940 So this is, where did the word fork come from? 181 00:08:57,940 --> 00:09:01,740 This person gave a whole, like a giant post 182 00:09:01,740 --> 00:09:03,020 on all these terms. 183 00:09:03,020 --> 00:09:05,700 And this is where hard and soft fork are in. 184 00:09:05,740 --> 00:09:09,300 And so I'll just read this at you. 185 00:09:09,300 --> 00:09:12,540 But it's quite interesting. 186 00:09:12,540 --> 00:09:15,660 But again, I forgot I've had this slide in here about, 187 00:09:15,660 --> 00:09:18,940 this is something where people really disagree. 188 00:09:18,940 --> 00:09:22,020 So maybe in the Q&A, people will come forward and say, 189 00:09:22,020 --> 00:09:23,540 that's not what a soft fork is or whatever. 190 00:09:23,540 --> 00:09:26,300 But these are the original, 191 00:09:26,300 --> 00:09:29,140 the definitions I'm about to give you are the earliest. 192 00:09:29,140 --> 00:09:31,220 They are the only ones that are logically consistent 193 00:09:31,220 --> 00:09:32,580 in my point of view. 194 00:09:32,580 --> 00:09:35,540 But more important than either of those two things, 195 00:09:36,380 --> 00:09:38,740 I'm going to explain what problem it is 196 00:09:38,740 --> 00:09:41,300 these words were invented to solve. 197 00:09:41,300 --> 00:09:43,700 And so in that way, they are fundamental. 198 00:09:46,420 --> 00:09:47,260 And so here we go. 199 00:09:47,260 --> 00:09:49,580 I'm just gonna read these, but you know. 200 00:09:49,580 --> 00:09:52,620 Okay, quote, when there are a sufficient number 201 00:09:52,620 --> 00:09:55,700 of Bitcoin clients on the network that disagree 202 00:09:55,700 --> 00:09:57,340 on the rules about how blocks are created 203 00:09:57,340 --> 00:09:58,660 and recorded in the blockchain, 204 00:09:58,660 --> 00:10:01,020 it leads to a split in the chain. 205 00:10:01,020 --> 00:10:02,980 One set of clients falls one branch 206 00:10:02,980 --> 00:10:05,260 and another set falls the other 207 00:10:06,060 --> 00:10:07,300 This is the important part. 208 00:10:07,300 --> 00:10:10,740 To fix hard fork, some action must be taken by us. 209 00:10:12,380 --> 00:10:14,620 And then I got orphan blocks in here, it's important. 210 00:10:14,620 --> 00:10:17,900 When a soft fork or a hard fork occurs, 211 00:10:17,900 --> 00:10:20,140 the blockchain is split into two paths. 212 00:10:21,180 --> 00:10:23,300 One of these paths will eventually be considered 213 00:10:23,300 --> 00:10:28,020 the valid one and the other will be invalid chain. 214 00:10:28,020 --> 00:10:31,140 Blocks that are an invalid chain are called orphan blocks. 215 00:10:32,140 --> 00:10:35,420 And then soft fork, you see at the end, it says, 216 00:10:36,340 --> 00:10:38,500 these kinds of forks will solve themselves 217 00:10:38,500 --> 00:10:40,940 without any intervention from us. 218 00:10:40,940 --> 00:10:43,340 So this is actually the heart and soul of the matter 219 00:10:43,340 --> 00:10:44,900 that when the network splits, 220 00:10:44,900 --> 00:10:48,580 this is not like a benign feature or even intended feature 221 00:10:48,580 --> 00:10:51,140 like with a fork in the road, fork splits, 222 00:10:51,140 --> 00:10:52,900 that was the whole point all along. 223 00:10:53,900 --> 00:10:55,140 But when the blockchain splits, 224 00:10:55,140 --> 00:10:56,900 this is a problem to be solved. 225 00:10:56,900 --> 00:11:00,820 This is an undesirable state and it must be addressed. 226 00:11:01,500 --> 00:11:03,620 So we want the network to be tightly synchronized. 227 00:11:03,620 --> 00:11:05,060 We don't want any orphan blocks. 228 00:11:05,060 --> 00:11:08,740 We want zero orphan blocks basically. 229 00:11:08,740 --> 00:11:12,140 So the forking is a problem. 230 00:11:12,140 --> 00:11:13,740 The hard fork and the soft fork, 231 00:11:13,740 --> 00:11:16,220 they are both problems to be solved. 232 00:11:16,220 --> 00:11:17,900 The hard fork is a hard problem 233 00:11:17,900 --> 00:11:19,940 because we have to do something about it. 234 00:11:19,940 --> 00:11:21,820 The soft fork actually is not a big problem. 235 00:11:21,820 --> 00:11:23,220 We don't have to do anything about it. 236 00:11:23,220 --> 00:11:27,700 It will actually work itself out automatically. 237 00:11:27,700 --> 00:11:29,580 So that's why fork is kind of a good word. 238 00:11:29,580 --> 00:11:34,060 After all, if you keep in mind that fork equals problem. 239 00:11:34,060 --> 00:11:37,340 And now, I'm gonna, the very next slide has an example. 240 00:11:37,340 --> 00:11:38,700 So if this is too abstract, 241 00:11:38,700 --> 00:11:40,820 I will have a very concrete example soon. 242 00:11:40,820 --> 00:11:45,820 But this is the logic, is that soft fork resolves itself. 243 00:11:47,340 --> 00:11:49,620 And so when you upgrade via soft fork, 244 00:11:49,620 --> 00:11:52,100 you either, the whole blockchain, 100% of it, 245 00:11:52,100 --> 00:11:53,620 no orphan blocks, whatever, 246 00:11:53,620 --> 00:11:55,980 the whole thing will collapse either in the direction 247 00:11:55,980 --> 00:11:58,580 where everyone can safely use the new feature, 248 00:12:00,580 --> 00:12:02,140 or it will collapse the other way, 249 00:12:02,140 --> 00:12:04,020 where the new feature is just broken for everyone 250 00:12:04,020 --> 00:12:06,500 and the soft fork never activates. 251 00:12:06,500 --> 00:12:10,380 But no matter what happens, there will not be any splitting. 252 00:12:10,380 --> 00:12:12,020 So the soft fork means that it won't, 253 00:12:12,020 --> 00:12:14,980 the split, any splitting will solve itself automatically. 254 00:12:16,460 --> 00:12:17,820 And ideally, like immediately, 255 00:12:17,820 --> 00:12:21,340 so there will only ever be like maybe one candidate block 256 00:12:21,340 --> 00:12:23,500 and it will never actually be a real split. 257 00:12:24,660 --> 00:12:26,660 And hence the heart and soul of the soft fork, 258 00:12:26,780 --> 00:12:30,220 which is that, as before with Gavin's comment 259 00:12:30,220 --> 00:12:31,540 about the changes in 2012, 260 00:12:31,540 --> 00:12:33,900 it's too difficult to get everyone to upgrade. 261 00:12:33,900 --> 00:12:35,660 But if we just have a few people 262 00:12:35,660 --> 00:12:38,140 plus 50% of hash rate to upgrade, 263 00:12:38,140 --> 00:12:40,540 then we can deploy the feature 264 00:12:40,540 --> 00:12:43,260 in like an optional consensual way. 265 00:12:43,260 --> 00:12:47,340 So the feature goes from being 0% safe to 100% safe 266 00:12:47,340 --> 00:12:50,140 as soon as 51% of miners upgrade. 267 00:12:51,540 --> 00:12:55,500 And on top of that, with hash rate signaling, 268 00:12:55,500 --> 00:12:58,540 anyone can learn the exact date that a feature activates 269 00:12:58,540 --> 00:13:00,900 so they know when it has become safe. 270 00:13:00,900 --> 00:13:02,140 So this is very, very useful, 271 00:13:02,140 --> 00:13:04,820 especially when paired with the op-nops that Satoshi put in. 272 00:13:04,820 --> 00:13:06,140 And so this is my example. 273 00:13:07,500 --> 00:13:11,100 The example is check-lock-time-verify. 274 00:13:11,100 --> 00:13:14,580 I did the debate with Peter last year. 275 00:13:15,500 --> 00:13:17,460 And of course, I have a lot of disagreements with Peter, 276 00:13:17,460 --> 00:13:18,860 but I do have to give it to him. 277 00:13:18,860 --> 00:13:20,780 He wrote this BIP and the text is, 278 00:13:20,780 --> 00:13:23,020 this is so short and clear that this is great. 279 00:13:23,020 --> 00:13:24,660 And you can ignore the bullet points. 280 00:13:24,660 --> 00:13:27,180 They're not important, but I'm gonna explain. 281 00:13:27,180 --> 00:13:31,180 Check-lock-time-verify redefines op-nop2 or nop2. 282 00:13:32,300 --> 00:13:36,860 When executed, if any of these conditions are true, 283 00:13:36,860 --> 00:13:39,500 the script interpreter will terminate with an error. 284 00:13:40,500 --> 00:13:42,020 Blah, blah, blah, forget about that. 285 00:13:42,020 --> 00:13:44,620 And then otherwise, script execution will continue 286 00:13:44,620 --> 00:13:46,820 as if a nop had been executed. 287 00:13:46,820 --> 00:13:47,780 So for these nops, 288 00:13:47,780 --> 00:13:50,980 the default behavior is to allow the transaction. 289 00:13:50,980 --> 00:13:52,580 The transaction was always allowed. 290 00:13:52,580 --> 00:13:53,900 It was always valid. 291 00:13:53,940 --> 00:13:57,380 Even years before check-lock-time-verify was thought up, 292 00:13:57,380 --> 00:13:59,300 the op-nop2 is always valid. 293 00:13:59,300 --> 00:14:02,300 And what happens is you add new conditions 294 00:14:02,300 --> 00:14:06,380 that trigger suddenly being invalid, invalidating the block. 295 00:14:06,380 --> 00:14:08,220 And so this is maybe a little counterintuitive, 296 00:14:08,220 --> 00:14:12,620 but hopefully that explains some of it a little bit. 297 00:14:12,620 --> 00:14:14,060 So those are a little bit more. 298 00:14:14,060 --> 00:14:15,900 This is a part that I think I might cut short 299 00:14:15,900 --> 00:14:17,740 because I think the questions may be, 300 00:14:17,740 --> 00:14:20,500 I had so much fun asking the questions last time. 301 00:14:20,500 --> 00:14:21,780 But I'll just try to go through this. 302 00:14:22,260 --> 00:14:24,260 Softworks are intimately related 303 00:14:24,260 --> 00:14:25,780 to how the protocol evolves over time. 304 00:14:25,780 --> 00:14:28,300 So I had some slides about this from the MIT talk, 305 00:14:28,300 --> 00:14:30,460 so I just kept them in here. 306 00:14:30,460 --> 00:14:32,340 This is like, what does governance mean? 307 00:14:32,340 --> 00:14:33,180 I think no one knows. 308 00:14:33,180 --> 00:14:37,820 But my point is that the existing definition 309 00:14:37,820 --> 00:14:38,660 definitely doesn't work 310 00:14:38,660 --> 00:14:40,900 because Bitcoin doesn't have governed people. 311 00:14:40,900 --> 00:14:42,660 Everyone's peer-to-peer in Bitcoin. 312 00:14:43,860 --> 00:14:46,340 So I say this definition sucks. 313 00:14:46,340 --> 00:14:47,980 And then I say that actually, 314 00:14:48,860 --> 00:14:50,260 the only thing that makes sense in Bitcoin 315 00:14:50,300 --> 00:14:54,060 is how do I find out what the node software is? 316 00:14:55,500 --> 00:14:58,180 And then it's actually a peer-to-peer definition again, 317 00:14:58,180 --> 00:15:00,540 because now we're all trying to figure out 318 00:15:00,540 --> 00:15:02,980 how do I get the Bitcoin node software 319 00:15:02,980 --> 00:15:05,540 and how do we tell Bitcoin nodes from non-nodes? 320 00:15:05,540 --> 00:15:07,060 Of course, a lot of the stuff with the block size 321 00:15:07,060 --> 00:15:08,220 were kind of hinged on this, 322 00:15:08,220 --> 00:15:09,620 like is this the real Bitcoin 323 00:15:09,620 --> 00:15:13,580 or does this count as Bitcoin even though such and such? 324 00:15:13,580 --> 00:15:16,740 So this is this definition I came up with 325 00:15:16,740 --> 00:15:18,340 and I call it node constructor theory. 326 00:15:18,340 --> 00:15:21,860 And I think it's quite an interesting question. 327 00:15:21,860 --> 00:15:24,620 And I do, this is something that I think I'll still explain, 328 00:15:24,620 --> 00:15:27,460 which is that there are three different, 329 00:15:27,460 --> 00:15:30,660 mostly three different strategies about this. 330 00:15:31,860 --> 00:15:34,020 Luke Dashjr. and also Mike Kern, 331 00:15:34,020 --> 00:15:36,660 who was coincidentally mentioned before. 332 00:15:36,660 --> 00:15:37,580 I didn't plan on that. 333 00:15:37,580 --> 00:15:40,540 But as well as Satoshi at first, 334 00:15:41,940 --> 00:15:44,580 they thought you must be a participant in the community 335 00:15:44,580 --> 00:15:47,140 and you must run the latest version. 336 00:15:47,140 --> 00:15:48,220 Although everyone started to, 337 00:15:48,220 --> 00:15:50,180 except for Luke Dashjr., 338 00:15:50,180 --> 00:15:52,220 who still really believes in this. 339 00:15:52,220 --> 00:15:53,740 But a lot of other people have abandoned this. 340 00:15:53,740 --> 00:15:57,180 And in particular, Satoshi removed this thing op-ver, 341 00:15:57,180 --> 00:15:58,340 which is very neat. 342 00:15:58,340 --> 00:16:01,660 So Mike Kern just thinks like you, 343 00:16:01,660 --> 00:16:03,740 here's this line, you're the decider, 344 00:16:05,500 --> 00:16:06,980 from this very interesting post 345 00:16:06,980 --> 00:16:08,820 that he wrote back in the day. 346 00:16:10,020 --> 00:16:13,020 The op-ver thing pushed the version number to the stack. 347 00:16:13,020 --> 00:16:16,420 So it actually resulted in the network forking 348 00:16:16,460 --> 00:16:18,900 every time a new version of the software came out, 349 00:16:18,900 --> 00:16:20,020 but it was never used. 350 00:16:20,020 --> 00:16:23,220 But Satoshi, what I want to bring up is that 351 00:16:23,220 --> 00:16:25,940 Satoshi put it in and then he quietly removed it, 352 00:16:25,940 --> 00:16:28,740 because I think he realized that this was a terrible idea. 353 00:16:29,660 --> 00:16:32,420 And then this second one has a very interesting story. 354 00:16:32,420 --> 00:16:33,740 The second thing is like, 355 00:16:33,740 --> 00:16:37,740 you just run the old version of the software. 356 00:16:37,740 --> 00:16:39,740 And you just say the old version works. 357 00:16:39,740 --> 00:16:41,340 If it's not broke, don't fix it. 358 00:16:41,340 --> 00:16:43,420 So never upgrade. 359 00:16:43,420 --> 00:16:45,420 And this is very, very old. 360 00:16:45,420 --> 00:16:49,020 There's this guy, Mircea Popescu, who ran this place. 361 00:16:49,020 --> 00:16:51,980 He possibly is dead, he possibly faked his own death. 362 00:16:51,980 --> 00:16:54,620 He's definitely qualified to fake his own death. 363 00:16:54,620 --> 00:16:56,500 So we'll never know. 364 00:16:56,500 --> 00:16:59,220 He is one of the most interesting people in the whole world, 365 00:16:59,220 --> 00:17:00,660 and also completely crazy. 366 00:17:00,660 --> 00:17:03,820 But they ran this version of Bitcoin, 0.5.4, 367 00:17:03,820 --> 00:17:05,980 and they told everyone else to run it as well, 368 00:17:05,980 --> 00:17:07,540 and he had a great sense of humor. 369 00:17:07,540 --> 00:17:09,740 Copyright, whatever, you do not have, 370 00:17:09,740 --> 00:17:11,420 nor can you ever acquire the right 371 00:17:11,420 --> 00:17:13,520 to use, copy, or distribute this software. 372 00:17:14,520 --> 00:17:16,280 Should you use this software for any purpose, 373 00:17:16,280 --> 00:17:17,840 you are breaking the laws of blah, blah, blah. 374 00:17:17,840 --> 00:17:19,400 So he's quite a character. 375 00:17:19,400 --> 00:17:22,680 But this is actually sort of the Michael Saylor view today. 376 00:17:22,680 --> 00:17:24,680 So this has actually come full circle. 377 00:17:24,680 --> 00:17:26,920 And this is even the complaint about Mev view, 378 00:17:26,920 --> 00:17:28,960 and the hall monitor view, 379 00:17:28,960 --> 00:17:31,800 that we have to be very, very, very conservative. 380 00:17:31,800 --> 00:17:34,200 Meanwhile, everyone around us is making whatever, 381 00:17:34,200 --> 00:17:36,640 that's not gonna hold back any altcoin community. 382 00:17:36,640 --> 00:17:38,280 They're gonna push whatever version of the software 383 00:17:38,280 --> 00:17:39,480 they think is best. 384 00:17:39,480 --> 00:17:44,480 But we will have to go really, really, really slowly, 385 00:17:44,480 --> 00:17:46,680 and be very deferential to the old version. 386 00:17:47,720 --> 00:17:49,800 This third point of view was really my point of view, 387 00:17:49,800 --> 00:17:52,040 and I really thought it was most people's point of view. 388 00:17:52,040 --> 00:17:54,040 I may have been mistaken about that. 389 00:17:54,040 --> 00:17:57,640 But definitely after 2017, and after the block size war, 390 00:17:57,640 --> 00:18:00,000 it has fallen relatively, 391 00:18:00,000 --> 00:18:02,800 and the second one gained a lot of ground. 392 00:18:02,800 --> 00:18:06,000 But the third one is this idea that, 393 00:18:06,000 --> 00:18:08,680 as long as you have a line of compatible protocols, 394 00:18:08,680 --> 00:18:10,440 it kind of doesn't matter which one you use, 395 00:18:10,440 --> 00:18:12,800 and so you can just use whichever one you like. 396 00:18:12,800 --> 00:18:16,040 And this emphasizes consent of people. 397 00:18:17,880 --> 00:18:20,520 Now I had a big thing about the relative 398 00:18:20,520 --> 00:18:21,680 costs and benefits of this, 399 00:18:21,680 --> 00:18:23,760 but I think that it's actually not as important 400 00:18:23,760 --> 00:18:25,800 as the next stuff that I wanna talk about. 401 00:18:25,800 --> 00:18:28,920 And so I'll come back to it if there are no questions. 402 00:18:28,920 --> 00:18:30,840 But you can see, I'll just go to where the table 403 00:18:30,840 --> 00:18:32,080 is completely filled out. 404 00:18:33,080 --> 00:18:38,080 And so they have some advantages and disadvantages. 405 00:18:39,360 --> 00:18:41,080 The second one, for better or worse, 406 00:18:41,080 --> 00:18:42,560 is currently in vogue, 407 00:18:42,560 --> 00:18:44,600 and that one has the disadvantage 408 00:18:44,600 --> 00:18:48,360 that it does not easily allow for innovation. 409 00:18:48,360 --> 00:18:50,440 And so if we don't innovate and other people do, 410 00:18:50,440 --> 00:18:53,200 then we would be losing ground, 411 00:18:53,200 --> 00:18:55,240 potentially being replaced at some point. 412 00:18:57,000 --> 00:18:58,400 Oh, one thing that I should point out, though, 413 00:18:58,400 --> 00:19:02,640 is that it's not super great. 414 00:19:02,640 --> 00:19:03,800 The third one isn't perfect, 415 00:19:03,800 --> 00:19:08,080 because if two people try to soft fork at the same time 416 00:19:08,080 --> 00:19:11,200 with different little incompatible soft forks, 417 00:19:11,200 --> 00:19:13,320 then that actually does become a hard fork, 418 00:19:13,320 --> 00:19:14,800 and so that is not great. 419 00:19:14,800 --> 00:19:16,320 But there is a way of improving on that, 420 00:19:16,320 --> 00:19:17,680 which is to do all these things 421 00:19:17,680 --> 00:19:19,040 on the sidechains themselves, 422 00:19:19,040 --> 00:19:21,640 or in layers, or using this Qsift thing 423 00:19:21,640 --> 00:19:23,880 that I will talk about at the end of the talk. 424 00:19:23,880 --> 00:19:26,240 And this gives you the best of all the different worlds. 425 00:19:26,240 --> 00:19:28,160 You can do any kind of innovation you want, 426 00:19:28,160 --> 00:19:30,120 and everything is separated, 427 00:19:30,120 --> 00:19:33,480 so that if one thing doesn't work, 428 00:19:33,480 --> 00:19:36,320 then that's not a big deal, 429 00:19:36,320 --> 00:19:38,920 so then we have rapid experimentation, 430 00:19:38,920 --> 00:19:40,840 and so that promotes error correction. 431 00:19:40,840 --> 00:19:42,440 But then since nothing is, 432 00:19:42,440 --> 00:19:45,680 in the stack of layers, nothing is mandatory. 433 00:19:45,680 --> 00:19:48,080 So you can just stay on whatever layers you've been using, 434 00:19:48,080 --> 00:19:50,240 and just wait to trust them more. 435 00:19:51,840 --> 00:19:53,760 Now I'm gonna skip, yeah, I'll skip ahead to this part, 436 00:19:53,760 --> 00:19:54,600 which is good. 437 00:19:54,600 --> 00:19:56,840 So this is soft forks over time. 438 00:19:56,840 --> 00:19:58,960 I took this list from BitMEX. 439 00:19:58,960 --> 00:20:00,720 I would make my own, but it's inherently, 440 00:20:00,720 --> 00:20:02,200 as I've tried to explain, 441 00:20:02,200 --> 00:20:04,760 it's actually quite a controversial subject. 442 00:20:04,760 --> 00:20:08,400 So I have decided to take BitMEX's table, 443 00:20:08,400 --> 00:20:10,640 and then I have re-tabled it like this. 444 00:20:11,640 --> 00:20:15,600 And here I have put the first eight years 445 00:20:15,600 --> 00:20:17,920 of Bitcoin's history on the top row, 446 00:20:17,920 --> 00:20:20,360 and then the next eight years, 447 00:20:20,360 --> 00:20:23,360 closing out in 2024 there, at the bottom. 448 00:20:27,240 --> 00:20:30,160 So as you can see, in the past, 449 00:20:30,160 --> 00:20:31,280 it's kind of hard to tell, 450 00:20:31,280 --> 00:20:33,640 but this is BitMEX's list. 451 00:20:33,680 --> 00:20:35,040 So I just took it from them. 452 00:20:35,040 --> 00:20:38,440 We averaged about two soft forks a year, 453 00:20:38,440 --> 00:20:41,000 and we never really went more than 12 months 454 00:20:41,000 --> 00:20:42,400 without doing at least one. 455 00:20:43,680 --> 00:20:45,600 But in the second, the lower period, 456 00:20:45,600 --> 00:20:47,720 we have only done two total. 457 00:20:48,760 --> 00:20:50,400 And I've also taken, as you can see, 458 00:20:50,400 --> 00:20:51,640 I took the liberty of tracking down 459 00:20:51,640 --> 00:20:53,840 when each was coded, first announced, 460 00:20:53,840 --> 00:20:55,400 coded, and then activated. 461 00:20:56,480 --> 00:20:59,160 And as you can see, SegWit took 20 months 462 00:20:59,160 --> 00:21:01,840 from when it was first announced at scaling two. 463 00:21:01,840 --> 00:21:03,760 Oh, is this a beeping sound? 464 00:21:03,760 --> 00:21:04,600 Oh, sorry. 465 00:21:04,600 --> 00:21:05,440 Okay, great. 466 00:21:07,120 --> 00:21:08,520 Yeah, so that took 20 months, 467 00:21:08,520 --> 00:21:10,920 and then Taproot took 46 months. 468 00:21:10,920 --> 00:21:13,080 So it's been slowing down, 469 00:21:13,080 --> 00:21:14,240 and if you extrapolate, 470 00:21:14,240 --> 00:21:16,480 then the next one will have taken nine years 471 00:21:16,480 --> 00:21:18,640 from when it was first announced 472 00:21:18,640 --> 00:21:20,760 to when it actually activates. 473 00:21:20,760 --> 00:21:22,520 So then the question is, 474 00:21:22,520 --> 00:21:24,720 what's the problem, or is there a problem? 475 00:21:25,960 --> 00:21:27,920 I think certainly there is a problem. 476 00:21:27,920 --> 00:21:29,640 For me, it actually skips, 477 00:21:29,640 --> 00:21:31,280 I mean, a lot of people don't think this is a problem, 478 00:21:31,280 --> 00:21:32,640 and they think this is great. 479 00:21:32,640 --> 00:21:34,280 They say, we don't want Bitcoin to change. 480 00:21:34,280 --> 00:21:36,400 But you see, this quite misunderstands 481 00:21:36,400 --> 00:21:38,800 why the soft fork was invented in the first place, 482 00:21:38,800 --> 00:21:40,000 which is that the old protocol 483 00:21:40,000 --> 00:21:41,560 does not have to change at all. 484 00:21:42,440 --> 00:21:44,800 So soft forks are not a mandatory change, 485 00:21:44,800 --> 00:21:48,240 since the old software works in the original conception. 486 00:21:48,240 --> 00:21:51,200 So let's just skip to the third bullet point, 487 00:21:51,200 --> 00:21:53,440 which is, since that's the case, 488 00:21:53,440 --> 00:21:55,400 since it's a voluntary consensual update 489 00:21:55,400 --> 00:21:57,440 that people do in their own time, 490 00:21:57,440 --> 00:22:01,320 there really can't be any costs to the soft fork, 491 00:22:01,320 --> 00:22:03,120 since it is optional. 492 00:22:04,120 --> 00:22:06,080 On top of that, they're actually reversible. 493 00:22:06,080 --> 00:22:09,760 So although it's bad if two different people 494 00:22:09,760 --> 00:22:11,720 use opnop6 for different things, 495 00:22:12,840 --> 00:22:15,600 what you could do is have someone claim opnop6, 496 00:22:16,520 --> 00:22:17,560 use it for something, 497 00:22:17,560 --> 00:22:20,480 then we all decide as a community this is terrible, 498 00:22:20,480 --> 00:22:22,720 and then have, just as Satoshi did originally 499 00:22:22,720 --> 00:22:23,720 at the beginning of the talk, 500 00:22:23,720 --> 00:22:25,160 you can just ban opnop6, 501 00:22:25,200 --> 00:22:26,760 and now you have deleted, 502 00:22:26,760 --> 00:22:28,440 you've created something via soft fork, 503 00:22:28,440 --> 00:22:31,640 and then via a second soft fork you have deleted it. 504 00:22:32,760 --> 00:22:34,560 But the third sub-bullet point here I have 505 00:22:34,560 --> 00:22:35,760 is that they are inevitable, 506 00:22:35,760 --> 00:22:39,840 because if the soft fork makes money for miners, 507 00:22:39,840 --> 00:22:42,040 they can just unilaterally activate the soft fork. 508 00:22:42,040 --> 00:22:43,600 I don't know how, if people will trust 509 00:22:43,600 --> 00:22:46,880 that they really will stick to the soft fork, 510 00:22:46,880 --> 00:22:50,280 but one would think that if this actually 511 00:22:50,280 --> 00:22:52,320 is something that makes money for miners, 512 00:22:52,320 --> 00:22:55,160 they will just do it, 513 00:22:55,160 --> 00:22:56,680 and then there's nothing that people can do about it. 514 00:22:56,680 --> 00:22:58,800 I think some people have some extremely interesting, 515 00:22:58,800 --> 00:23:03,800 suspicious views about if you can resist a soft fork 516 00:23:04,400 --> 00:23:05,400 that is done by miners, 517 00:23:05,400 --> 00:23:08,320 but if all of those types of things 518 00:23:08,320 --> 00:23:11,240 rely on an end user voluntarily rejecting 519 00:23:11,240 --> 00:23:12,760 the heaviest valid chain rule, 520 00:23:12,760 --> 00:23:14,440 and so actually all of those things are, 521 00:23:14,440 --> 00:23:16,880 paradoxically, those things are hard forks, 522 00:23:16,880 --> 00:23:18,680 those people will hard fork off 523 00:23:18,680 --> 00:23:21,000 onto a network that has less hash rates, 524 00:23:21,000 --> 00:23:23,040 so they will be the only ones on their network, 525 00:23:23,040 --> 00:23:25,720 and anyone who does nothing will be on the, 526 00:23:26,680 --> 00:23:28,040 which is exactly the point. 527 00:23:29,040 --> 00:23:31,240 So I do think that the soft fork is a good thing, 528 00:23:31,240 --> 00:23:32,560 and I also think it is inevitable, 529 00:23:32,560 --> 00:23:34,400 so we should kind of, I don't know, 530 00:23:34,400 --> 00:23:35,800 make our peace with it or something, 531 00:23:35,800 --> 00:23:38,240 or learn how to do it the right way. 532 00:23:38,240 --> 00:23:41,400 As was alluded to earlier today numerous times, 533 00:23:41,400 --> 00:23:42,360 the second bullet point, 534 00:23:42,360 --> 00:23:44,920 we have the potential for enormous benefits 535 00:23:44,920 --> 00:23:46,040 via the soft fork. 536 00:23:46,040 --> 00:23:48,600 So they, we want, I think this is something 537 00:23:49,320 --> 00:23:52,040 that one gentleman made about, 538 00:23:52,040 --> 00:23:53,480 we want the software to improve. 539 00:23:53,480 --> 00:23:55,080 The more the software improves, 540 00:23:56,160 --> 00:23:58,720 the better Bitcoin is, the more competitive it is, 541 00:23:58,720 --> 00:24:00,360 more users, more happiness. 542 00:24:02,360 --> 00:24:04,560 Things that we like today, Multisig and Lightning, 543 00:24:04,560 --> 00:24:07,520 they were created by soft fork. 544 00:24:07,520 --> 00:24:09,280 OpVault, I would love OpVault, 545 00:24:09,280 --> 00:24:12,560 because OpVault is like, if you have a ton of money, 546 00:24:12,560 --> 00:24:14,200 a ton of Bitcoin, and people come to your house 547 00:24:14,200 --> 00:24:17,480 and they want to torture you 548 00:24:17,720 --> 00:24:20,080 and get you to give up your private key, 549 00:24:20,080 --> 00:24:21,120 I don't want to be tortured. 550 00:24:21,120 --> 00:24:24,080 So I like OpVault, because OpVault is like, 551 00:24:24,080 --> 00:24:25,240 you can only, you can set it up 552 00:24:25,240 --> 00:24:27,480 so that you can only take a small amount of money 553 00:24:27,480 --> 00:24:30,680 at a time, and this is a deterrent, you know. 554 00:24:30,680 --> 00:24:33,440 This is a deterrent from, if you can't. 555 00:24:33,440 --> 00:24:35,040 So we don't, what we really don't want 556 00:24:35,040 --> 00:24:37,440 is a situation where thieves steal, 557 00:24:37,440 --> 00:24:39,240 they torture people and they get a lot of money. 558 00:24:39,240 --> 00:24:40,080 Then they're gonna be thinking, 559 00:24:40,080 --> 00:24:41,680 oh, we should make a list of people, 560 00:24:41,680 --> 00:24:43,480 we should keep this going and keep torturing people. 561 00:24:43,480 --> 00:24:45,680 So we don't want that, so why can't we get OpVault? 562 00:24:45,680 --> 00:24:46,520 I don't know. 563 00:24:47,400 --> 00:24:49,680 Okay, finally, this is my new thing. 564 00:24:49,680 --> 00:24:51,520 I have this this year. 565 00:24:51,520 --> 00:24:54,120 This is a Core Untouched Soft Fork. 566 00:24:55,200 --> 00:24:57,440 You could also call it the ordinalization of soft forks 567 00:24:57,440 --> 00:25:00,600 or the sidechainization of soft forks. 568 00:25:01,052 --> 00:25:12,212 I have this little paper about it on this little site, BIP300CUSF.com, so you can read the paper if you want, but basically the idea is to leave Bitcoin Core untouched. 569 00:25:13,932 --> 00:25:23,572 The key is, what problem does CUSF solve? Well, actually, the Bitcoin Core merge process is the source of the slowdown, where something like ordinals just launches. 570 00:25:24,332 --> 00:25:47,332 So the idea is, actually, you can do that with soft forks. You have a second piece of software. It takes blocks from Bitcoin Core and just gives them a second pass, and if it finds any rule breaking, it's exactly like, okay, I'll come to this in a second, but if it finds any rule breaking, it just has Bitcoin Core call and validate block on that block, and then it achieves the same thing. 571 00:25:47,332 --> 00:26:02,092 So if you can remember back to the black slide where I had check-lock-time-verify from Peter Todd, and you had the op-nop-2, and the script interpreter will throw an error if any of these conditions are met, that would be like the red thing, which is the old ways at the top there. 572 00:26:03,652 --> 00:26:17,292 The old way is the red thing, the script interpreter, will fail the block if soft fork rules are broken, and the new way is that you have the orange rectangles are the same. 573 00:26:17,612 --> 00:26:33,852 It's just the same thing, but you add a red thing, a new server, a new software daemon or whatever, and that thing will just call, well, that will ask your local version of Bitcoin Core to call and validate block if it detects any. 574 00:26:34,212 --> 00:26:35,612 So it has the exact same effect. 575 00:26:35,932 --> 00:26:38,972 It's kind of a neat way of teaching people what the soft fork is anyway. 576 00:26:38,972 --> 00:26:41,292 It's just invalidate block if something happens. 577 00:26:42,292 --> 00:26:46,452 It's very inefficient from the computer's point of view because it's twice as much work. 578 00:26:46,452 --> 00:27:02,092 You have to scan through the whole block twice, but it actually is better at the human level because these things are all separable now, and now everyone can just do whatever they want, and even though this is almost exactly like what was happening before, this is much easier to do. 579 00:27:02,092 --> 00:27:04,812 It has a long list of advantages, so I think. 580 00:27:05,812 --> 00:27:09,412 I would just kind of blur through them quickly, but I'm not really. 581 00:27:09,412 --> 00:27:13,012 I'll just give this one this part here, which is that. 582 00:27:13,012 --> 00:27:35,212 Well, I think maybe it's better if people just read. Hopefully, people can tell, like the one simple one is that the new soft fork activator thing can be written in any programming language, and it can have any style, and it can be in any idiosyncratic way, so some one random guy can just do that in an independent way. 583 00:27:35,972 --> 00:27:41,132 So there's no need to talk to other people or have the pull request get merged. 584 00:27:41,732 --> 00:27:46,212 And then one thing I wanted to mention is that the bottom of this one here, the lowest row. 585 00:27:47,932 --> 00:28:07,012 The principle of the whether or not miners activate is just whether or not they make more money, so then this becomes sort of this is sort of almost the way the inverse of the MEV talk where I'm saying the miners will write software and then run it in order to get more money, and this is not only inevitable, but perfectly safe because they will eventually. 586 00:28:07,412 --> 00:28:20,892 There's no way that you can have something that's a blockchain unless it's like open source node software, so anyway, that's just like there's kind of a little bit more to it than that, but I did want to try to. This is all exists already, and you can download this if you go to the site. 587 00:28:21,852 --> 00:28:28,732 Bit300accusives.com you can download this. We have it for OP_CAT and for BIP300, 301. 588 00:28:30,852 --> 00:28:36,052 And I think this is easy way of restoring the soft fork to its former glory that it lost. 589 00:28:37,172 --> 00:28:41,412 As a result of just pointless drama during the scaling war so. 590 00:28:42,572 --> 00:28:47,652 OK, I got I got like maybe slightly faster than I thought so. 591 00:28:48,412 --> 00:28:52,692 All good questions Paul so want to give a big round of applause for Paul. 592 00:28:53,532 --> 00:28:54,012 Thank you. 593 00:28:56,412 --> 00:28:57,892 Alright, here's our first question. 594 00:28:58,892 --> 00:29:04,572 So yes, invalidate block prevents any other blocks from being mined on top of it so. 595 00:29:05,292 --> 00:29:15,612 If someone invalidates one block and the miners go on then they may be on the situation where no miners are building on the chain that they believe exists. 596 00:29:16,012 --> 00:29:25,812 Yes, it must be done. It must be the case that no one invalidates any blocks until 51 majority hash rate is is running the activator thing. 597 00:29:26,372 --> 00:29:45,252 So otherwise it will not work, and in fact it may just cause miners to lose money, but they'll just invalidate their own. I'll shoot their own block in the head and then that for no reason so that will not work so if I understand the invalidate logic also includes coordination logic with other people running the activator. 598 00:29:45,812 --> 00:29:47,292 That's that's the part I missed. 599 00:29:48,252 --> 00:29:54,092 Yes, and in fact I didn't I don't think I haven't written that into the code yet so, but that is that must be a part of it. 600 00:29:56,292 --> 00:29:56,852 Yes. 601 00:29:57,892 --> 00:29:58,452 That's right. 602 00:29:59,452 --> 00:30:06,492 You cannot just it would be very what would be very interesting is if you could just if we were in a situation where like someone with 5% of the hash rate could like. 603 00:30:07,012 --> 00:30:20,772 Only activate soft fork and get the benefits from it kind of like a privatized improvement, but then we wouldn't have any problems at all because nothing would be everything would just be privatized raise your hand if you have a question and I will bring you the mic. 604 00:30:22,052 --> 00:30:24,092 Yeah, hey Paul thanks for the talk. 605 00:30:25,092 --> 00:30:31,852 One of just maybe pushing back on one thing you said it there was a slide where you mentioned that if. 606 00:30:32,932 --> 00:30:50,292 That it's technically a hard fork if somebody tries to reject a soft fork, but I would I would say that it's not it's it's more like the situation that we just described where somebody is trying to do a soft fork, but there aren't enough miners. 607 00:30:51,212 --> 00:31:06,532 To you know kind of build on them, so they end up just kind of halting there's a fork there's a chain split, but there's not it's not a hard fork my point of view is that the software doesn't really start until 51% of miners are in. 608 00:31:06,932 --> 00:31:16,572 So I have like maybe I don't know everyone has their own definitions or something, but to me what I'm referring to in this bullet point the second one in the little set. 609 00:31:17,572 --> 00:31:28,652 I'm referring to a case where there is 51% of the hash rate upgrades and then some people say I will never allow anything that uses up not five I reject that blockchain. 610 00:31:29,932 --> 00:31:37,012 Yes, people will they have added a rule they have this is the paradox of the soft fork they have tightened the rules from their point of view. 611 00:31:38,012 --> 00:31:40,212 But in practice. 612 00:31:40,772 --> 00:32:05,092 They will be on they have the same effect as if they were running Bitcoin cash or something because they will only be on the same network with other people. So this is the paradox. I think it maybe does go in a circle if you it is a chain split. It's just it's not a hard fork. I would say I don't have no miners at all, then there would never be more blocks. Hypothetically. Yeah, it does depend on sort of nuanced. I think yeah. 613 00:32:05,692 --> 00:32:09,652 Um, I also had a question about your 614 00:32:10,652 --> 00:32:34,252 One of your last slides where you're saying that the accuser software. It requires validating the block twice. And I wonder if you think that this would slow down mining to any material degree such that you know miners would be hesitant to run the software because they don't want to be slower than other miners weren't validating blocks twice. 615 00:32:34,252 --> 00:33:03,252 That's a good question. If it if I don't think so. First of all, but the second of all, I think that even if it did that would not fundamentally make it that's not that that's not that specific to this to the soft fork in general or any particular soft fork because like any other thing. It's just their business decision to make a cost benefit analysis and say we could make this much money or at this percent risk. So even like a sick boost was that you probably remember. 616 00:33:04,252 --> 00:33:17,012 That was like much faster, but it had like something. I don't remember exactly like 12% of the time it would. It would make an erroneous block or something, but it was so much faster that I don't know the exact details, but it was something like that. There was a cost benefit. 617 00:33:17,012 --> 00:33:46,532 Involved the reason why I definitely don't think it would is that imagine that you just if the when they refresh that if they refresh the template like every five seconds or something. They just they stick with a template that's that's perfectly good and then the new transactions stream in to the mining pool or whatever they assemble the block. They run the block through each first through Bitcoin core. They have the mempool that is in Bitcoin core and then the activator the activator. 618 00:33:47,012 --> 00:34:04,172 Will flag the any invalid ones is requiring a fee of 21 million coins, which they will never have so so that's happening somewhere else. So it's just when they refresh the template. So they refresh the template every 10 seconds or something. It's very, very, very, very, very, very unlikely that that would be. 619 00:34:04,172 --> 00:34:30,252 Paul, can you help me understand on this page that you've got up there? How does the CUSF actually make the transaction fail? 620 00:34:31,252 --> 00:34:40,612 What was the question? How does it actually want well on your on your map or on your graph there? You've got the bit 119 activator. How does this actually make the transaction fail? 621 00:34:42,252 --> 00:34:46,452 I didn't I didn't hear it quite again, but is it? How did it? How does the? 622 00:34:47,452 --> 00:35:04,732 Oh, there is actually a there are actually many ways, but there is an RPC in Bitcoin. That's since been hidden, but it's still there called invalidate block that just you curse a block and it's as if it and it's actually very important one because during various times of crisis like in 2015. 623 00:35:04,732 --> 00:35:16,412 2015 had to be used for some reason, but it is very you can just curse it, but even if that weren't there, you could do any. 624 00:35:17,972 --> 00:35:30,692 The way of implementing CUSF doesn't it kind of doesn't matter what form it takes, but this is by far the most convenient form. There's already an RPC. You just do invalidate block and then the block hash and then it will. The software will treat that as if it broke a consensus rule. 625 00:35:31,692 --> 00:35:34,692 So that has been in every version of Bitcoin for a very long time. 626 00:35:35,692 --> 00:35:45,692 Although it is now hidden, it's one of the infamous hidden RPCs. You learn to hear first everyone. There are secret RPCs that are not. They don't show up and help, but they're still there. So look at them up there very interesting. 627 00:35:46,692 --> 00:35:59,692 Could you talk a little bit about the history of activation methods for soft forks and do you have like a preferred activation method? Yes, OK, that's a very, very good question. And this is also a thing that people are like really, really, really. 628 00:36:00,692 --> 00:36:05,692 Passionate about and they are very. 629 00:36:06,692 --> 00:36:09,692 OK, yeah, alright. 630 00:36:10,692 --> 00:36:16,692 So yeah, there were these things. Bip 9 was this old one. So historically there was an idea that. 631 00:36:17,692 --> 00:36:22,692 OK, what I really need to stress is that historically there was no controversy about soft forks. 632 00:36:23,692 --> 00:36:37,692 This started with SegWit because of the way SegWit activated and I can go into enormous detail on that. But basically, actually, it's probably worth reviewing because SegWit was there was this block size dispute. 633 00:36:38,692 --> 00:36:46,692 And then in 2015 there was these two scaling conferences, scaling 1 and 2 and then scaling 3, which is where I was talking about with Matt Corral before. Scaling 3 was much, much longer time had elapsed. 634 00:36:47,692 --> 00:36:54,692 So at the end of scaling 2 people had promised like lightning is the way to go and SegWit is the best way to get lightning. And then someone said that I don't know who this person was. 635 00:36:55,692 --> 00:36:59,692 Someone said SegWit will be ready by April 1st or something, which you should never do in software. 636 00:36:59,692 --> 00:37:07,692 And so it wasn't ready by April 1st at all, but then people started to get really stressed out in 2016. It was a very stressful year. 637 00:37:08,692 --> 00:37:23,692 Scaling 3, SegWit still hadn't activated and so it had been coded. So people were very annoyed, or at least some of the people who had come to scaling 3 including some miners, some Chinese miners. 638 00:37:23,692 --> 00:37:31,692 They thought that there would be more tangible progress or something on this. 639 00:37:32,692 --> 00:37:42,692 So one of them went, they looked at the program, the schedule, and the whole first day didn't have anything. It only had one thing about scaling. It was about privacy or something. 640 00:37:42,692 --> 00:37:53,692 So this one irate person flew back to China and switched. They had 9% of the hash rate, which they switched to mine this thing, Bitcoin Unlimited, which is a long story. 641 00:37:54,692 --> 00:38:03,692 But the reason I bring this up is there used to be this 95% threshold limit. So people are constantly shipping new versions of Bitcoin Core, new versions coming out. 642 00:38:04,692 --> 00:38:16,692 And it used to just be when 95% of the miners are running, when you upgrade to this, you put a little flag in the version bits and everyone can tell that you have updated. 643 00:38:17,692 --> 00:38:29,692 And then when that gets to 95, then there's like a two-week grace period for any straggling miners to upgrade and then it's locked in. And then if you do not enforce the rule, you are kicked off the network. 644 00:38:30,692 --> 00:38:37,692 And then Luke has a completely different point of view. His view is that to involve the miners at all is like giving them hostages or something. 645 00:38:38,692 --> 00:38:46,692 Now, I want to crack open something a little new about this. I don't think a lot of people talk about this, this idea of toxic limbo, which I think is extremely important. 646 00:38:47,692 --> 00:38:52,692 This is why, and this is a huge difference between, you might think, where am I going with this? 647 00:38:53,692 --> 00:39:03,692 But, you know, America and the UK have this first-past-the-post voting system and the continental Europe has this proportional representation, which is these things are as different as chalk and cheese. 648 00:39:04,692 --> 00:39:10,692 They are completely different. And one is better because it does not produce toxic limbo. 649 00:39:11,692 --> 00:39:13,692 And what on earth am I talking about this? 650 00:39:14,692 --> 00:39:20,692 Originally, it was 95 and then it was dropped to 90 for a speedy trial that happened recently. 651 00:39:21,692 --> 00:39:26,692 Now, the problem with anything other than 51, there are multiple problems, actually. I don't even want to get into them all. 652 00:39:27,692 --> 00:39:33,692 But there's one huge problem with, if the threshold is 51 percent, then you have a logical situation. 653 00:39:34,692 --> 00:39:36,692 But if you have anything else, you have an illogical situation. 654 00:39:37,692 --> 00:39:42,692 And so the problem with 90 percent is that two different coalitions of 11 percent can emerge. 655 00:39:43,692 --> 00:39:47,692 And now the problem is totally unsolvable because maybe these two people want different things. 656 00:39:48,692 --> 00:39:51,692 No one, there's no way of satisfying both. 657 00:39:52,692 --> 00:40:01,692 And even the people who are now, whatever that would be, 88 or whatever, the 88, they know that it will never actually, excuse me, 78. 658 00:40:02,692 --> 00:40:05,692 They know that it will never actually succeed. So they can just keep signaling. 659 00:40:06,692 --> 00:40:10,692 So the whole thing is in gridlock and you don't know to whom your grievance should be addressed. 660 00:40:11,692 --> 00:40:13,692 If it's 51, then everyone has to take a side. 661 00:40:14,692 --> 00:40:17,692 And you know, some people, OK, we've only convinced 10 percent so far. 662 00:40:17,692 --> 00:40:20,692 So we haven't convinced, and then 90 percent are unconvinced. 663 00:40:21,692 --> 00:40:26,692 And so this is a terrible situation to be in. 664 00:40:27,692 --> 00:40:34,692 And this is an issue, my view is that actually most of the problems in Bitcoin today were caused by this detail. 665 00:40:35,692 --> 00:40:36,692 You think it's a tiny detail. 666 00:40:37,692 --> 00:40:41,692 And I just have to stress that in the past, the soft fork was not controversial. 667 00:40:41,692 --> 00:40:50,692 And that was why it had the 95 percent threshold, because it was just as a courtesy, we'll wait for everyone to upgrade. 668 00:40:51,692 --> 00:40:56,692 But when it becomes like a governance thing, now it is a like a poker chip or something. 669 00:40:57,692 --> 00:41:00,692 And now that one guy, I don't even think that person knew what they were doing. 670 00:41:01,692 --> 00:41:06,692 They were just upset. And that one guy switched, diverted his 9 percent of his hash to something that wasn't Bitcoin Core. 671 00:41:06,692 --> 00:41:10,692 At the same time that they were working on the hackathon after scaling three to ship SegWit. 672 00:41:11,692 --> 00:41:13,692 So I think that this actually caused the whole scaling war. 673 00:41:14,692 --> 00:41:16,692 The miners didn't even realize that they could veto soft forks. 674 00:41:17,692 --> 00:41:18,692 They didn't even think of it. I don't even think that was on their mind. 675 00:41:19,692 --> 00:41:24,692 So I think that most of the problems today that we have, because the software isn't as good as it could be, 676 00:41:25,692 --> 00:41:30,692 supporting privacy, scalability, and these other things, more competition, more development, more focus on users. 677 00:41:31,692 --> 00:41:36,692 I believe that actually a lot of those problems are caused by this 90 percent number. 678 00:41:37,692 --> 00:41:42,692 So, but yeah, there is BIP-9 was the old thing, which is the miners will activate at some point. 679 00:41:43,692 --> 00:41:47,692 Then there was this lock-in true or false things. I don't know. I hate to keep rambling on about this. 680 00:41:48,692 --> 00:41:50,692 Okay, we'll have one last question over here. 681 00:41:52,692 --> 00:41:57,692 Yeah, I can't really follow why the 51 percent would be better than the 90 percent. 682 00:41:58,692 --> 00:42:08,692 Because you would still have a 94 percent chain that might be longer than the 51 percent chain for a long time, 683 00:42:09,692 --> 00:42:16,692 which would lead to pretty deep forks potentially and can affect all users which have not upgraded to the new rules 684 00:42:17,692 --> 00:42:20,692 and potentially lead to double spend attacks or just a lot of chaos. 685 00:42:21,692 --> 00:42:27,692 Well, I think that type of premise in the question relies on like, okay, there's a lot of statistical. 686 00:42:28,692 --> 00:42:32,692 If it was actually split 51-49, then there is some statistical noise in there. 687 00:42:33,692 --> 00:42:37,692 And so it's not a guarantee that the 51 percent will be further. 688 00:42:38,692 --> 00:42:45,692 So I completely agree with that. And in fact, in practice, 51 percent is not, because of the noise, it's not realistic. 689 00:42:45,692 --> 00:42:55,692 And so I would actually accept that as a critique, that this is like a platonic ideal is 51 percent or 50.0001. 690 00:42:56,692 --> 00:43:01,692 But I think that's only because of the noise, that is not because of the principle of the matter, 691 00:43:02,692 --> 00:43:09,692 that actually there is no one to, you don't know what to do to solve the problem when the threshold is higher than 50 percent. 692 00:43:09,692 --> 00:43:16,692 So I think it's really 50 percent plus a buffer, a margin of error to account for the noise. 693 00:43:17,692 --> 00:43:25,692 I agree that actually firing the gun as soon as it's 50.0001 is actually not what you would want to do in practice 694 00:43:26,692 --> 00:43:30,692 because you would not want to actually maybe mismeasure because there's a lot of luck involved. 695 00:43:31,692 --> 00:43:34,692 You wouldn't want to mismeasure how much hashrate support something had and that would not be good. 696 00:43:35,692 --> 00:43:36,692 So I would agree with that. 697 00:43:36,692 --> 00:43:38,692 All right, thanks everyone. 698 00:43:39,692 --> 00:43:40,692 Appreciate it. 699 00:43:41,692 --> 00:43:42,692 Paul, a big round of applause for Paul. 700 00:43:43,692 --> 00:43:44,692 Thank you guys.