1 00:00:07,000 --> 00:00:10,480 Hello everybody, I am Shinobi technical auditor at Bitcoin 2 00:00:10,480 --> 00:00:15,360 Magazine, joined by Seditid, Bitcoin Core developer 3 00:00:15,360 --> 00:00:18,200 contributing to the Colonel project. 4 00:00:18,200 --> 00:00:23,440 So Seditid, there's a little bit of a long tangled history to the 5 00:00:23,440 --> 00:00:27,680 Colonel project. Years ago there was the Lib 6 00:00:27,680 --> 00:00:32,080 consensus project. So attempting to actually take 7 00:00:32,600 --> 00:00:36,480 all of the consensus rules and move them to a totally external 8 00:00:36,480 --> 00:00:39,960 library that could just be called used independently on its 9 00:00:39,960 --> 00:00:43,600 own like any other software library. 10 00:00:44,080 --> 00:00:48,240 And that project kind of got sunsetted in favor of the 11 00:00:48,240 --> 00:00:52,320 Colonel project, which as opposed to trying to become a 12 00:00:52,320 --> 00:00:57,800 full library is looking at just isolating kind of the consensus 13 00:00:57,800 --> 00:01:01,920 logic in the Bitcoin Damon so that you can call it 14 00:01:01,920 --> 00:01:07,800 independently or like granularly bit by bit from that program 15 00:01:07,800 --> 00:01:11,200 running rather than having to go through the whole validation 16 00:01:11,200 --> 00:01:15,480 flow as its implemented in core. You kind of want to talk a 17 00:01:15,480 --> 00:01:21,240 little bit about why all the efforts switched from the Lib 18 00:01:21,240 --> 00:01:25,000 consensus project to Colonel and kind of the the logic and the 19 00:01:25,000 --> 00:01:27,320 reasoning for that? Yeah, sure. 20 00:01:27,880 --> 00:01:36,360 So I when it started out, the initial goal was to just isolate 21 00:01:37,200 --> 00:01:44,120 a very small subset of the entire consensus logic and 22 00:01:44,120 --> 00:01:49,680 specifically was only the script interpreter that was surfaced 23 00:01:49,680 --> 00:01:53,160 through the original consensus library. 24 00:01:55,040 --> 00:02:03,560 And some projects did integrate this, but the traction it got 25 00:02:03,560 --> 00:02:08,720 was pretty limited. And this had a multitude of 26 00:02:08,720 --> 00:02:13,960 reasons, but I think the main one was that it just didn't give 27 00:02:14,480 --> 00:02:19,160 enough leverage to the programmers using the library 28 00:02:20,120 --> 00:02:23,360 and it's feature set was also pretty limited. 29 00:02:25,120 --> 00:02:31,800 And the main problem with expanding the scope of the 30 00:02:31,800 --> 00:02:37,120 original library was that the code within Bitcoin Core just 31 00:02:37,120 --> 00:02:40,640 wasn't suitable for that at the time. 32 00:02:41,320 --> 00:02:46,960 So because everything was so very tightly coupled with 33 00:02:47,320 --> 00:02:51,200 completely unrelated functionality like the GUI or 34 00:02:51,200 --> 00:02:57,280 the wallet was basically impossible to surface more 35 00:02:57,440 --> 00:03:01,080 validation logic, that just did one thing at a time. 36 00:03:02,200 --> 00:03:09,920 And yeah, it just took a lot of time since that original, the 37 00:03:09,920 --> 00:03:14,080 Bitcoin consensus release, to get the internal code into a 38 00:03:14,080 --> 00:03:23,000 state where we can now finally add a bit more, let's say, 39 00:03:23,240 --> 00:03:28,640 flexibility for the developers using the library and features 40 00:03:30,000 --> 00:03:37,000 beyond just verifying scripts. And he was specifically asking 41 00:03:37,000 --> 00:03:42,880 before where like the cuts between LIP Bitcoin consensus 42 00:03:42,880 --> 00:03:45,480 and the new LIP Bitcoin kernel happens. 43 00:03:46,360 --> 00:03:52,000 And the main difference there is that the LIP Bitcoin kernel 44 00:03:52,000 --> 00:03:58,240 functions are stateful, so they maintain system resources that 45 00:03:58,240 --> 00:04:00,560 are allocated on the hardware itself. 46 00:04:02,640 --> 00:04:06,160 It has all the database functionality that a typical 47 00:04:06,600 --> 00:04:12,960 Bitcoin node would have, and servicing all of that through 48 00:04:13,240 --> 00:04:16,560 the original LIP Bitcoin consensus architecture was 49 00:04:16,560 --> 00:04:21,279 basically impossible. And yeah, that's why the step 50 00:04:21,279 --> 00:04:26,880 had to be taken to deprecate it. So it's just, you know, because 51 00:04:27,080 --> 00:04:32,240 consensus entangles so many things outside of script is just 52 00:04:32,240 --> 00:04:37,240 like unpredictability in terms of how trying to apply that 53 00:04:37,240 --> 00:04:41,480 library, interacting with alternate implementations of 54 00:04:41,880 --> 00:04:46,120 consensus critical things like the UTXO set or a block database 55 00:04:46,120 --> 00:04:49,160 like that, that kind of issue. But you you can isolate the 56 00:04:49,160 --> 00:04:53,280 script rules, but you can't actually guarantee that the rest 57 00:04:53,560 --> 00:04:57,240 of everything that needs to be touched in the consensus process 58 00:04:57,240 --> 00:04:59,640 will behave properly. Yeah, exactly. 59 00:04:59,720 --> 00:05:06,800 So I guess it would have theoretically worked if you 60 00:05:06,800 --> 00:05:11,000 would have been very, very careful to like patch out all 61 00:05:11,000 --> 00:05:15,960 the unrelated functionality with like stop functions that you 62 00:05:15,960 --> 00:05:20,200 manually copy in. But once you're doing that, 63 00:05:20,920 --> 00:05:25,480 yeah, it's too much of A hassle to release, right? 64 00:05:25,840 --> 00:05:30,400 You you could just take the current code wholesale if that's 65 00:05:30,400 --> 00:05:33,760 what you're doing anyway, so. At that point, you're not 66 00:05:34,120 --> 00:05:39,760 achieving the goal of having a known, consistent, reproducible 67 00:05:39,760 --> 00:05:42,440 consensus rule sets or implementation that you. 68 00:05:42,440 --> 00:05:45,960 Use exactly the The entire point is that you don't have to 69 00:05:45,960 --> 00:05:50,880 autismally interfere with the code every time you want to just 70 00:05:51,280 --> 00:05:54,800 verify a block, right? We just want to give this one 71 00:05:54,800 --> 00:05:58,400 function that does the logic correctly and everybody can just 72 00:05:58,560 --> 00:06:03,400 call it in exactly the same way and get a reproducible result. 73 00:06:04,360 --> 00:06:09,040 So what what was kind of the original impetus for, you know, 74 00:06:09,040 --> 00:06:11,720 Lib consensus and now the Colonel project? 75 00:06:11,760 --> 00:06:16,200 I mean, Bitcoin Core is unquestionably the dominant 76 00:06:16,200 --> 00:06:20,640 client on the network. Like any serious miner is either 77 00:06:20,640 --> 00:06:25,640 running core or running something very tightly related 78 00:06:25,640 --> 00:06:29,600 to core in terms of custom behavior or code base changes. 79 00:06:30,000 --> 00:06:33,600 All the major businesses exchanges are running core. 80 00:06:34,240 --> 00:06:39,200 Like, why put so much time and effort into trying to strip out 81 00:06:39,200 --> 00:06:42,560 and isolate the consensus rule so they can be used somewhere 82 00:06:42,560 --> 00:06:46,360 else as opposed to just continuing to focus on core as 83 00:06:46,360 --> 00:06:48,600 an implementation? Yeah. 84 00:06:48,600 --> 00:06:53,480 So I think initially the emphasis was purely on a 85 00:06:53,480 --> 00:06:59,960 philosophical level where we don't just want Bitcoin Core to 86 00:07:02,000 --> 00:07:06,400 dictate everything to the entire ecosystem and kind of prohibits 87 00:07:07,040 --> 00:07:10,880 other node implementations from ever receiving the same trust 88 00:07:10,880 --> 00:07:14,800 level just because they kind of gate keep the validation logic. 89 00:07:15,040 --> 00:07:20,240 But even beyond that, the kernel has like significant benefits to 90 00:07:20,240 --> 00:07:26,080 the project because it's really clearly demarcates what actually 91 00:07:26,080 --> 00:07:28,760 is validation codes and what isn't. 92 00:07:29,760 --> 00:07:34,360 And yeah, making things nice to use from the outsides will 93 00:07:34,360 --> 00:07:39,920 automatically also make it nicer to use for our own codes and 94 00:07:40,120 --> 00:07:46,000 allow us to also experiments more freely with it, write our 95 00:07:46,000 --> 00:07:48,840 own tools and utilities with it. Yeah. 96 00:07:48,840 --> 00:07:53,520 So it gives us a whole lot more flexibility and also confidence 97 00:07:53,520 --> 00:07:59,720 with reading the codes and doing reviews of, yeah, sometimes 98 00:07:59,720 --> 00:08:01,720 pretty complex validation changes. 99 00:08:03,600 --> 00:08:09,280 So how is implemented kernel impacted or affected the work 100 00:08:09,280 --> 00:08:11,320 towards multi process separation? 101 00:08:11,440 --> 00:08:15,160 Like that's that's something, you know, for a similarly long 102 00:08:15,160 --> 00:08:21,160 time, core as a project has kind of been trying to clean up the 103 00:08:21,160 --> 00:08:24,960 code base so that things are nicely isolated. 104 00:08:25,440 --> 00:08:29,400 Could potentially in future actually be separated into 105 00:08:29,400 --> 00:08:32,640 completely separate programs that talk to each other as 106 00:08:32,640 --> 00:08:35,799 opposed to, you know, 1 singular code base. 107 00:08:35,799 --> 00:08:41,720 But it's it's been a long road, I think a lot longer than Lib 108 00:08:41,720 --> 00:08:46,920 Consensus and the Colonel project going from the giant 109 00:08:46,960 --> 00:08:52,200 file that Satoshi left everybody to like the much more modular 110 00:08:52,200 --> 00:08:53,920 clean code base that we have today. 111 00:08:54,320 --> 00:08:59,360 Yeah, definitely. I would say the time spent on 112 00:09:00,120 --> 00:09:04,560 either, probably more time was spent on the multi process 113 00:09:04,560 --> 00:09:10,680 project cumulatively so far. Initially the efforts that went 114 00:09:10,680 --> 00:09:16,400 into separating the code for multi process were also really 115 00:09:16,400 --> 00:09:23,000 useful for the kernel, but by and large that split is kind of 116 00:09:23,000 --> 00:09:25,800 done now. Like there there are a few areas 117 00:09:25,800 --> 00:09:30,320 where we definitely still need to separate a bit more cleanly, 118 00:09:30,440 --> 00:09:34,720 for example for the indexing code, but that doesn't really 119 00:09:34,720 --> 00:09:36,800 directly affect the kernel anymore. 120 00:09:37,040 --> 00:09:42,840 So the kernel is already like 1 sub components of the innermost 121 00:09:43,040 --> 00:09:47,880 multi process binary or like the Bitcoin nodes multi process 122 00:09:47,880 --> 00:09:51,840 binary. And most of the organization 123 00:09:51,840 --> 00:09:55,640 that takes place now in the kernel project is within that's 124 00:09:55,840 --> 00:09:58,560 Bitcoin nodes multi process program already. 125 00:09:58,800 --> 00:10:03,720 So there's not really much of A symbiosis between the two. 126 00:10:03,720 --> 00:10:07,480 They're just yeah on separate tracks and don't really 127 00:10:07,480 --> 00:10:10,640 interfere with each other. Yeah, just kind of a little work 128 00:10:10,640 --> 00:10:14,280 overlap, I guess in the early phases, Yeah, Kernel, OK. 129 00:10:15,520 --> 00:10:20,040 You know, I think kind of the the original goal of, you know, 130 00:10:20,040 --> 00:10:25,640 Lib consensus of Colonel project was to kind of enable other 131 00:10:25,640 --> 00:10:30,120 implementations to just take cores consensus logic and then 132 00:10:30,120 --> 00:10:34,240 build out all the rest of an implementation themselves, 133 00:10:34,240 --> 00:10:38,840 knowing that the core thing that matters is going to be 134 00:10:39,160 --> 00:10:41,040 interoperable with the rest of the network. 135 00:10:41,960 --> 00:10:46,680 Practically speaking, like how far from that stage is 136 00:10:46,680 --> 00:10:49,440 development for the project? Like do you think that would be 137 00:10:49,440 --> 00:10:53,640 a safe thing to do now or is there kind of still some more 138 00:10:53,640 --> 00:10:56,280 groundwork to be laid before we're really at that point? 139 00:10:56,600 --> 00:10:59,320 I think it's a fairly safe thing to do now. 140 00:10:59,560 --> 00:11:04,160 We are at the point where there's I think two or three 141 00:11:04,160 --> 00:11:08,880 projects which are now trying to build out a complete full nodes 142 00:11:09,000 --> 00:11:12,440 around the kernel library. My main hesitation still with 143 00:11:12,440 --> 00:11:18,240 that is the splits and the end of phases for that are still 144 00:11:18,240 --> 00:11:22,640 pretty immature. Like probably want to wait a few 145 00:11:22,640 --> 00:11:27,080 more release cycles before we say OK, we now officially 146 00:11:27,080 --> 00:11:30,440 released this. It has been used successfully by 147 00:11:31,000 --> 00:11:33,640 I don't know maybe 1020 other projects. 148 00:11:34,560 --> 00:11:38,520 No major bugs have been reported in like half a year, because 149 00:11:38,520 --> 00:11:42,960 obviously we really can't mess this up once it hits yeah, 150 00:11:43,000 --> 00:11:46,480 production. So yeah, we definitely have to 151 00:11:46,480 --> 00:11:50,960 be very careful with that. So most recently, I think 2 152 00:11:50,960 --> 00:11:57,120 weeks ago, Floresta, one of the Utrixo implementations, 153 00:11:57,120 --> 00:12:00,160 integrates with the kernel or the subset of the kernel 154 00:12:00,160 --> 00:12:02,520 library. Yeah, that's the project 155 00:12:02,520 --> 00:12:05,120 Vintium's funding in Brazil, right? 156 00:12:05,320 --> 00:12:07,440 Yeah. So they're they're running it 157 00:12:07,440 --> 00:12:12,240 now, which is pretty cool. And they've also committed to 158 00:12:12,400 --> 00:12:15,400 working with us a bit and giving good feedback. 159 00:12:15,400 --> 00:12:20,720 And we also try to upstream changes that we're planning to 160 00:12:20,720 --> 00:12:22,800 roll out Bitcoin Core soon to them. 161 00:12:23,280 --> 00:12:24,880 Yeah, that's been a good symbiosis. 162 00:12:26,120 --> 00:12:29,160 Hey everyone, it's Shinobi and I'm here in front of the Chicago 163 00:12:29,160 --> 00:12:31,800 Fed to talk to you about the core issue of Bitcoin Magazine. 164 00:12:32,240 --> 00:12:35,360 The last few years have been a bit of a communication breakdown 165 00:12:35,400 --> 00:12:37,640 between developers and people using Bitcoin. 166 00:12:38,200 --> 00:12:39,960 Bitcoin exists to be an alternative. 167 00:12:39,960 --> 00:12:43,080 To this institution. But to do that, it needs people 168 00:12:43,080 --> 00:12:45,760 to actively maintain it. If you actually want to hear 169 00:12:45,760 --> 00:12:48,560 from developers themselves, how they approach their work and 170 00:12:48,560 --> 00:12:52,240 what they choose to work on, go to bitcoinmagazine.com and get 171 00:12:52,240 --> 00:12:53,720 yourself a copy in the court issue. 172 00:13:27,880 --> 00:13:31,280 All right. And I guess you should probably 173 00:13:31,280 --> 00:13:35,960 try to keep this higher level. But you know, I, I guess for 174 00:13:35,960 --> 00:13:40,160 some of the curious viewers out there, you think you can kind of 175 00:13:40,160 --> 00:13:45,680 like walk through the different validation steps that were in 176 00:13:46,080 --> 00:13:49,200 the code base and isolated in the kernel now. 177 00:13:49,200 --> 00:13:54,120 And I don't know, maybe kind of talk a little bit about which of 178 00:13:54,120 --> 00:13:58,840 those was maybe the toughest to kind of isolate or was sprawled 179 00:13:58,840 --> 00:14:01,440 the most across different sections of the code base? 180 00:14:01,880 --> 00:14:06,560 Yeah, I can try to do that. So on a high level, you get a 181 00:14:06,560 --> 00:14:11,120 block from the network and then you pass that to various 182 00:14:11,120 --> 00:14:16,200 functions in the kernel library and those functions then 183 00:14:16,200 --> 00:14:19,240 validate the block header. So check the proof of work, 184 00:14:19,240 --> 00:14:22,520 check the time stamp, the previous block that the Merkel 185 00:14:22,520 --> 00:14:24,720 root is actually calculated correctly with all the 186 00:14:24,720 --> 00:14:28,440 transactions in the block. And yeah, once that is done, it 187 00:14:28,880 --> 00:14:31,480 commits it to disk or writes it to disk router. 188 00:14:31,840 --> 00:14:37,160 And once that is done, it validates all the transactions 189 00:14:37,200 --> 00:14:39,360 and all the scripts from the transactions. 190 00:14:39,360 --> 00:14:44,640 So it it checks the signatures of every single spent output in 191 00:14:44,640 --> 00:14:47,200 the transaction. So yeah, that's basically like 192 00:14:47,200 --> 00:14:52,560 the high level overview of of what the logic actually does in 193 00:14:52,560 --> 00:14:56,120 terms of what was most challenging was probably the 194 00:14:56,120 --> 00:15:01,040 step between writing a block to disk and doing the actual 195 00:15:01,040 --> 00:15:03,120 validation. There were like a couple of 196 00:15:03,200 --> 00:15:07,840 callback hooks back into the GUI and some extra functions that 197 00:15:07,840 --> 00:15:10,200 called out to the boiler to unnecessarily. 198 00:15:11,440 --> 00:15:14,720 It's not really too complicated stuff, but I that I had to deal 199 00:15:14,720 --> 00:15:17,120 with personally. But also have to say at that 200 00:15:17,120 --> 00:15:20,840 point that when I took the project over three years ago 201 00:15:20,840 --> 00:15:24,560 now, it already was in the fairly mature shades. 202 00:15:25,240 --> 00:15:30,040 And that preceded yeah, all the multi process work before. 203 00:15:30,040 --> 00:15:33,800 It's that cleaned that up some of the work that Corey Fields 204 00:15:33,800 --> 00:15:37,760 did on the old lipid con consensus originally, some of 205 00:15:37,760 --> 00:15:39,920 the work that called on did. Yeah. 206 00:15:40,000 --> 00:15:44,000 So it's really been this long process over. 207 00:15:44,720 --> 00:15:48,160 Yeah, probably more than a decades to to get to this point. 208 00:15:48,440 --> 00:15:50,400 Yeah. You know, it's, it's kind of, 209 00:15:50,440 --> 00:15:54,840 you know, hard for me to reconcile looking at like how 210 00:15:54,840 --> 00:15:58,960 much work has gone into things like this in core. 211 00:15:58,960 --> 00:16:02,520 You know, like Lib consensus, the Colonel after that multi 212 00:16:02,520 --> 00:16:07,800 process, like all of these things that are decade long 213 00:16:07,800 --> 00:16:13,200 projects at this point with the explicit goal of opening the 214 00:16:13,200 --> 00:16:18,200 project of making it easier for more people to do different 215 00:16:18,200 --> 00:16:22,080 things with it or to integrate it into something in different 216 00:16:22,080 --> 00:16:23,720 ways. Or even, you know, with kernel 217 00:16:23,720 --> 00:16:27,840 itself to explicitly build something from scratch entirely 218 00:16:27,840 --> 00:16:30,920 around that core consensus logic. 219 00:16:30,920 --> 00:16:34,840 That is really what matters. You know with this attitude 220 00:16:34,840 --> 00:16:41,760 nowadays that core developers are like some ivory tower group 221 00:16:41,760 --> 00:16:46,320 from above just trying to force their will on the network or 222 00:16:46,560 --> 00:16:50,720 retain like some position of power, influence. 223 00:16:51,040 --> 00:16:55,800 When the work I see is things like this, trying to do the 224 00:16:55,800 --> 00:16:58,080 exact opposite. Like actually trying to give 225 00:16:58,080 --> 00:17:01,920 away like some of that power and influence that they have and 226 00:17:01,920 --> 00:17:05,640 make it as easy as possible for other people to pick that up and 227 00:17:05,640 --> 00:17:09,680 actually do something with it. You know what's what's it like 228 00:17:10,119 --> 00:17:12,960 working on something like this in that environment? 229 00:17:13,880 --> 00:17:21,640 Yeah, it's, I mean, honestly, I don't really get that criticism. 230 00:17:22,240 --> 00:17:27,119 So one, one of the things I've heard repeatedly is those might 231 00:17:27,119 --> 00:17:31,760 actually centralized power further around coal because now 232 00:17:32,160 --> 00:17:34,920 we're extending our control into other projects. 233 00:17:35,440 --> 00:17:39,520 But I think that's even further from the truth because the the 234 00:17:39,520 --> 00:17:42,360 only thing that we're really establishing here is an 235 00:17:42,720 --> 00:17:46,480 interface and everybody can tinker with the actual 236 00:17:46,480 --> 00:17:49,000 validation codes as much as they want to. 237 00:17:49,800 --> 00:17:55,200 And the cool thing to see over the past year of development on 238 00:17:55,200 --> 00:18:00,400 it was that a few people actually showed up and did 239 00:18:00,400 --> 00:18:04,080 exactly that. So they only wanted this 240 00:18:04,080 --> 00:18:07,840 interface that they can rely on and reuse for their own 241 00:18:07,840 --> 00:18:10,600 projects. And they ended up implementing 242 00:18:10,600 --> 00:18:15,840 some of the new op codes, some weird tap tap script stuff. 243 00:18:16,360 --> 00:18:21,720 So yeah, this is, I mean, it gives me a very good feeling and 244 00:18:21,720 --> 00:18:25,000 it makes me very hopeful for Bitcoin as a whole. 245 00:18:25,280 --> 00:18:30,640 If we can get this project out there and just allow people to 246 00:18:30,640 --> 00:18:35,120 do whatever they want with it with the confidence that they 247 00:18:35,120 --> 00:18:39,280 have this interface, yeah, they can tinker with it and probably 248 00:18:39,280 --> 00:18:42,920 have a bit of risk doing that. But All in all, they can build 249 00:18:42,920 --> 00:18:47,440 on this 1 1/2 decades strong foundation. 250 00:18:47,640 --> 00:18:52,760 So yeah, that's pretty cool. That's that's kind of just 251 00:18:52,760 --> 00:18:57,040 confusing logic to me that something like Colonel would 252 00:18:57,040 --> 00:19:03,040 give more power to Core because like the the underlying dynamic 253 00:19:03,040 --> 00:19:09,200 here is like to do something completely from scratch. 254 00:19:09,240 --> 00:19:12,880 Like unrelated to core is the risk of consensus 255 00:19:12,880 --> 00:19:16,960 incompatibility. And that's only a risk because 256 00:19:16,960 --> 00:19:20,200 of how big core is. And you know, they're the 257 00:19:20,200 --> 00:19:22,240 dominant implementation on the network. 258 00:19:22,240 --> 00:19:25,480 Almost everybody economically relevant is running that. 259 00:19:25,920 --> 00:19:30,240 And when you open the door like this to build entirely new 260 00:19:30,240 --> 00:19:33,840 things knowing they're compatible with core, you're 261 00:19:33,840 --> 00:19:37,200 opening the door for anything to come in and compete and gain 262 00:19:37,200 --> 00:19:41,760 network share without that risk of a consensus split. 263 00:19:42,560 --> 00:19:45,440 And at that point, if it comes down to it, if, if something 264 00:19:45,440 --> 00:19:49,560 else using the kernel were to actually, you know, gain 265 00:19:49,560 --> 00:19:54,080 adoption, become a majority of the network, like at that point 266 00:19:55,160 --> 00:19:57,080 it's just just another repository. 267 00:19:57,200 --> 00:20:00,880 Like those other projects can simply fork it and do whatever 268 00:20:00,880 --> 00:20:03,320 they want with it. Like Core has no power just 269 00:20:03,320 --> 00:20:06,400 because they originally implemented that code base. 270 00:20:06,960 --> 00:20:10,840 Like just click fork. And if everybody's running some 271 00:20:10,840 --> 00:20:13,680 other thing built around it instead of Core itself, like 272 00:20:14,600 --> 00:20:17,920 Core literally voluntarily obsoleted itself in that 273 00:20:17,920 --> 00:20:20,440 scenario. I just, I don't. 274 00:20:21,240 --> 00:20:24,480 Get the argument that that's entrenching core more. 275 00:20:26,000 --> 00:20:28,560 Yeah, I don't buy it either for the same reason. 276 00:20:29,120 --> 00:20:34,720 One thing that I can see playing out maybe is that people will 277 00:20:34,720 --> 00:20:40,120 just stick with us because we have all this tradition that 278 00:20:40,120 --> 00:20:43,080 we're building on top of. But I mean, as long as that is 279 00:20:43,600 --> 00:20:48,440 well earned and it can't be switched away from easily, which 280 00:20:48,480 --> 00:20:53,240 definitely can if we deploy this common interface that everybody 281 00:20:53,240 --> 00:20:59,120 just uses anyway, then yeah, this is just a pure win in my 282 00:20:59,120 --> 00:21:02,240 eyes. Yeah. 283 00:21:02,240 --> 00:21:07,480 I mean, it's, it's definitely an important project. 284 00:21:08,160 --> 00:21:13,800 You know, I think, I think to kind of like go back to the 285 00:21:13,800 --> 00:21:18,960 lineage of like live consensus and then kernel and kind of 286 00:21:18,960 --> 00:21:22,720 project out to the future. You know, the next ideal step 287 00:21:22,720 --> 00:21:28,000 would be a formal specification, like an actual like bit for bit. 288 00:21:28,000 --> 00:21:30,200 This is how the protocol should operate. 289 00:21:30,200 --> 00:21:32,240 This is how it should evaluate data. 290 00:21:32,240 --> 00:21:35,920 This is the result that should be output in whatever conditions 291 00:21:37,040 --> 00:21:41,640 to provide the same degree of guarantee that the kernel is 292 00:21:41,640 --> 00:21:45,200 aiming to without any actual codependency. 293 00:21:46,240 --> 00:21:51,120 Like that is a really sticky topic in in this space. 294 00:21:51,120 --> 00:21:55,600 In terms of the practicality of that, you know, whether that's 295 00:21:56,760 --> 00:21:59,440 worth the effort, whether that's something that's even 296 00:21:59,440 --> 00:22:03,240 potentially possible. Like what are your thoughts on 297 00:22:03,240 --> 00:22:06,440 just the issue of a formal specification? 298 00:22:06,720 --> 00:22:10,960 For yeah, you're definitely right that it is sticky topic. 299 00:22:11,000 --> 00:22:15,360 I think it was one of the first topics that were this custom 300 00:22:15,360 --> 00:22:18,400 bitcoins history from the very beginning. 301 00:22:18,880 --> 00:22:25,480 So we have been going a bit in circles around is it better to 302 00:22:25,680 --> 00:22:30,720 have a specification or is it better to just have the codes be 303 00:22:30,840 --> 00:22:35,960 the reference? Yeah, you have to re implemented 304 00:22:35,960 --> 00:22:40,440 bug for bug if you want to and that's going to be very hard 305 00:22:40,680 --> 00:22:45,520 because the code is difficult to read and it's pretty 306 00:22:45,520 --> 00:22:49,480 complicated. Yeah, looking out into the 307 00:22:49,480 --> 00:22:53,840 future, I think I would like to see a specification of Bitcoin 308 00:22:53,840 --> 00:22:57,880 eventually. And I'm kind of hoping that the 309 00:22:57,880 --> 00:23:03,080 kernel can be a tool to make that easier so that we can break 310 00:23:03,280 --> 00:23:08,320 all the validation logic into like separate calls to the 311 00:23:08,320 --> 00:23:12,440 kernel library itself and have these calls be super, super 312 00:23:12,440 --> 00:23:17,280 granular where you just do a single check per valid per 313 00:23:17,280 --> 00:23:21,080 validation function. And then you just let the 314 00:23:21,080 --> 00:23:23,760 interface for each of that validation function. 315 00:23:24,240 --> 00:23:29,320 And what it exactly does be the specification for Bitcoin? 316 00:23:29,400 --> 00:23:36,240 I think that would is probably the cleanest way to achieve any 317 00:23:36,240 --> 00:23:39,640 kind of formal description of Bitcoin just because you have 318 00:23:39,640 --> 00:23:43,480 this guarantee that you don't introduce a bug when you 319 00:23:43,480 --> 00:23:46,660 translate from the reference clients to MM. 320 00:23:46,660 --> 00:23:55,680 Hmm. Yeah, it's really, it would have 321 00:23:55,680 --> 00:24:01,400 been hard enough as just a distributed system, but with the 322 00:24:01,400 --> 00:24:05,800 mess that the code base was beginning as the worst problem 323 00:24:05,960 --> 00:24:10,720 to go backwards rather than having started with a spec and 324 00:24:10,800 --> 00:24:14,240 like move towards an implementation which is the 325 00:24:14,240 --> 00:24:16,640 norm, you know, when you really look at things. 326 00:24:16,960 --> 00:24:19,160 Yeah, but that's not what we have, right? 327 00:24:19,680 --> 00:24:22,480 Yeah. We have what Satoshi gave us. 328 00:24:22,760 --> 00:24:23,720 Yes. All right. 329 00:24:23,720 --> 00:24:27,960 Well, yes. Any you know last thoughts on 330 00:24:27,960 --> 00:24:30,480 the project or your work over the last few years? 331 00:24:31,040 --> 00:24:31,720 You want. To voice. 332 00:24:32,240 --> 00:24:37,400 Yeah, I'm, I'm pretty hopeful on what it will enable for the 333 00:24:37,440 --> 00:24:42,560 ecosystem at large. Like I was hesitant I think a 334 00:24:42,560 --> 00:24:45,480 year ago or so we had the feeling that it didn't really 335 00:24:45,480 --> 00:24:50,280 get traction. But now we have like 3-4 bigger 336 00:24:50,280 --> 00:24:54,760 projects completely external to Bitcoin Core actually using it, 337 00:24:55,240 --> 00:24:57,800 actually integrating it into the stacks. 338 00:24:58,200 --> 00:25:01,640 Second, one of the ARC implementations now uses it in 339 00:25:01,640 --> 00:25:05,520 their test framework. I can see a the future where the 340 00:25:05,520 --> 00:25:10,120 Lightning implementations will use it to either check their 341 00:25:10,400 --> 00:25:15,800 scripts for their transactions or do some pre validation that 342 00:25:16,400 --> 00:25:19,880 their transactions that they create actually pass the policy 343 00:25:19,880 --> 00:25:24,040 rules. Yeah, that's just so much that 344 00:25:24,040 --> 00:25:28,560 can be built with this. And I think just putting it out 345 00:25:28,560 --> 00:25:34,400 there, ensuring that it is as easy to use for developers as 346 00:25:34,400 --> 00:25:38,040 possible, that's going to take a lot of work still, but I think 347 00:25:38,280 --> 00:25:42,240 it'll be very worthwhile. I couldn't agree more. 348 00:25:43,960 --> 00:25:48,400 Thanks for sitting down and talking sedative and I hope you 349 00:25:48,400 --> 00:25:50,080 all enjoyed. Thank you.