1
00:00:06,880 --> 00:00:09,440
Hello everybody. 
I'm Shinobi, the technical 

2
00:00:09,440 --> 00:00:12,960
editor at Bitcoin Magazine, 
joined here by Stefan, also 

3
00:00:12,960 --> 00:00:15,760
known as Stickies, a Bitcoin 
Core contributor. 

4
00:00:16,160 --> 00:00:19,600
So we're going to talk a little 
bit about some of the work he's 

5
00:00:19,600 --> 00:00:23,280
been doing helping sedated with 
the Colonel project and then 

6
00:00:23,280 --> 00:00:26,280
kind of go into some of his 
review work before that. 

7
00:00:27,160 --> 00:00:30,000
So I guess kind of start like 
what? 

8
00:00:30,000 --> 00:00:32,960
What was the state of like the 
Colonel Project when you joined?

9
00:00:33,840 --> 00:00:38,080
So the kernel project largely 
had two different phases. 

10
00:00:38,920 --> 00:00:42,400
In the first phase, it was all 
about identifying which code 

11
00:00:42,400 --> 00:00:46,760
actually belonged to validation,
and then moving all of that into

12
00:00:46,760 --> 00:00:48,840
separate directories, or at 
least a separate library. 

13
00:00:51,040 --> 00:00:53,720
And then the second phase was 
about building a public 

14
00:00:53,720 --> 00:00:56,000
interface around all that 
validation logic. 

15
00:00:56,160 --> 00:01:00,880
And so when I started looking at
kernel in more detail, it was 

16
00:01:01,040 --> 00:01:05,519
somewhere halfway in that first 
stage of the code organization. 

17
00:01:06,040 --> 00:01:09,440
So the most work that I helped 
with since has been, yeah, just 

18
00:01:10,280 --> 00:01:15,280
moving everything into a more 
logical place, which also 

19
00:01:15,280 --> 00:01:17,560
involved a bunch of cleanups. 
Because you know, when you move 

20
00:01:17,640 --> 00:01:21,160
code around, it's also a good 
time to clean things up a bit 

21
00:01:21,240 --> 00:01:25,160
and remove some foot guns or 
some bugs or just make things a 

22
00:01:25,160 --> 00:01:27,760
bit nicer, more modernized as 
well. 

23
00:01:29,400 --> 00:01:37,360
And so like what, what was your 
kind of take on like the 

24
00:01:37,360 --> 00:01:40,280
progression of the project, I 
guess kind of from where it 

25
00:01:40,280 --> 00:01:45,440
started before Saturday took 
over and kind of the general 

26
00:01:45,440 --> 00:01:47,480
work that was involved in 
getting from the 

27
00:01:47,480 --> 00:01:49,840
conceptualization to like where 
things are now? 

28
00:01:52,200 --> 00:01:56,000
I think the pace for these 
projects kind of goes up and 

29
00:01:56,000 --> 00:01:58,960
down a bit based on where you 
are in the project and who's 

30
00:01:58,960 --> 00:02:04,400
contributing. 
I think in the first stage from 

31
00:02:04,400 --> 00:02:07,360
the part where I joined, 
progress was kind of moderate, 

32
00:02:07,360 --> 00:02:11,520
like it kept going at a steady 
but not super fast pace. 

33
00:02:12,520 --> 00:02:15,480
Also, because these changes were
very critical, like if you move 

34
00:02:15,480 --> 00:02:20,480
consensus code around, even if 
it's just moving it around, that

35
00:02:20,480 --> 00:02:22,240
can still introduce bugs 
potentially. 

36
00:02:22,240 --> 00:02:24,400
So you very much don't want to 
rush that process. 

37
00:02:24,640 --> 00:02:28,680
So yeah, not an excitingly fast 
pace, but I think quite 

38
00:02:28,680 --> 00:02:30,440
appropriate given the 
circumstances. 

39
00:02:31,040 --> 00:02:33,480
And we had a, a group of a few 
contributors who would regularly

40
00:02:33,480 --> 00:02:36,040
come back to those PRS and, and 
keep making progress. 

41
00:02:36,040 --> 00:02:40,200
So it, it felt like it was, it 
didn't feel like it was stalling

42
00:02:40,520 --> 00:02:43,200
for the most part. 
And then I feel when things 

43
00:02:43,200 --> 00:02:49,760
really picked up is about, yeah,
six months ago when we already 

44
00:02:49,760 --> 00:02:54,120
started working on the public 
interface of the Bitcoin kernel 

45
00:02:54,120 --> 00:02:57,400
library. 
So thinking about how we expect 

46
00:02:57,400 --> 00:03:00,560
and want people to use the 
validation logic, that's when 

47
00:03:00,560 --> 00:03:02,760
things, yeah, really pick the 
pace. 

48
00:03:02,800 --> 00:03:07,080
I think for multiple reasons, 
but the main one probably it 

49
00:03:07,480 --> 00:03:10,200
becomes more tangible. 
Like if you just move code 

50
00:03:10,200 --> 00:03:13,680
around, except for people 
working on a project, it's not 

51
00:03:13,680 --> 00:03:15,720
that exciting because it doesn't
add any functionality, it 

52
00:03:15,720 --> 00:03:19,120
doesn't enable anything new. 
It's important because it helps.

53
00:03:19,120 --> 00:03:21,880
It makes it more robust, it 
helps us find bugs, it helps us 

54
00:03:22,040 --> 00:03:25,760
prevent introducing no bugs. 
When you make changes to what 

55
00:03:25,760 --> 00:03:29,160
should be non validation logic, 
it's just not that exciting. 

56
00:03:29,160 --> 00:03:33,600
It's important first step, but 
then once we started building 

57
00:03:33,600 --> 00:03:37,000
this public interface, we also 
asked people to try it out and 

58
00:03:37,000 --> 00:03:40,800
use it for small use cases. 
Like we had some people use it 

59
00:03:40,800 --> 00:03:44,920
for data science projects and 
then reports on findings on 

60
00:03:44,920 --> 00:03:48,200
delving, or it was used in an 
early prototype of Swift Sync. 

61
00:03:49,880 --> 00:03:54,440
And people could see that this 
was something that was working 

62
00:03:54,440 --> 00:03:57,440
even if in a limited fashion and
still very experimental. 

63
00:03:57,440 --> 00:04:01,760
But it became tangible. 
And I think that gave us both 

64
00:04:01,760 --> 00:04:04,560
the user feedback that was very 
helpful, but also checked it 

65
00:04:04,560 --> 00:04:08,840
more developer interest. 
So we've had a couple of new 

66
00:04:08,840 --> 00:04:12,960
contributors joining who weren't
contributing to Core before that

67
00:04:12,960 --> 00:04:18,160
are not spending like really 
useful time on building new 

68
00:04:18,160 --> 00:04:21,360
features, reviewing and bringing
everyone ideas into Corel. 

69
00:04:21,360 --> 00:04:25,120
And that's really been speeding 
things up at the moment. 

70
00:04:25,120 --> 00:04:27,600
Like we have a weekly call 
talking to my Colonel and 

71
00:04:27,600 --> 00:04:33,720
usually it's around 8 people on 
that call, which is a lot more 

72
00:04:33,720 --> 00:04:36,320
than I think what you would have
imagined a year ago. 

73
00:04:36,320 --> 00:04:38,600
So that's been that's been 
really fun to see. 

74
00:04:39,200 --> 00:04:42,480
And so, you know, before you 
started contributing to the 

75
00:04:42,480 --> 00:04:47,640
kernel yourself, you did like a 
lot of general review of kind of

76
00:04:47,640 --> 00:04:52,160
the project in general. 
I think that gives you kind of a

77
00:04:52,160 --> 00:04:56,360
good view into core as an 
overall project rather than just

78
00:04:56,360 --> 00:04:59,160
the like subsections or sub 
projects. 

79
00:05:00,400 --> 00:05:04,640
I guess to kind of start getting
into this, you think you can at 

80
00:05:04,640 --> 00:05:09,720
least take a, a college try at 
kind of breaking down like what 

81
00:05:09,720 --> 00:05:13,800
are the major like different 
areas of core as a project in 

82
00:05:13,800 --> 00:05:16,480
the code base? 
Like what's their functionality 

83
00:05:16,480 --> 00:05:19,200
like how do they touch other 
parts of the code base? 

84
00:05:19,840 --> 00:05:23,800
And just like how that that kind
of organization works in terms 

85
00:05:23,800 --> 00:05:25,360
of the different areas people 
work on. 

86
00:05:26,000 --> 00:05:28,160
Yeah, sure. 
Trying to give it some 

87
00:05:28,160 --> 00:05:30,400
structure. 
So I think a helpful way to 

88
00:05:30,400 --> 00:05:32,720
organize it is kind of a 
foundation of it all. 

89
00:05:33,080 --> 00:05:38,800
We have the the tooling and the 
the build system, the CI that 

90
00:05:38,800 --> 00:05:41,680
basically allows us to work to 
do the work that we're doing. 

91
00:05:42,680 --> 00:05:45,680
So over the last year or two, 
for example, we've had a big 

92
00:05:45,680 --> 00:05:49,720
project that moved the build 
system from all the tools to 

93
00:05:49,760 --> 00:05:54,080
Cmake, which was necessary for 
some technical reasons, but also

94
00:05:54,080 --> 00:05:57,040
just made for a smoother 
development experience. 

95
00:05:57,240 --> 00:05:59,840
CI, we've expanded lots like 
automated testing. 

96
00:05:59,840 --> 00:06:02,840
Whenever we push and merge code 
into the code base, that's been 

97
00:06:02,840 --> 00:06:05,680
expanded a lot. 
It's been made faster, more 

98
00:06:05,680 --> 00:06:08,840
robust, So everything that makes
that developer experience better

99
00:06:08,840 --> 00:06:13,680
and helps us catch bugs faster 
before they even can be merged 

100
00:06:14,040 --> 00:06:18,600
into the master branch. 
Then we've had a lot of work 

101
00:06:18,600 --> 00:06:24,920
happening on everything like net
processing, basically all the 

102
00:06:24,920 --> 00:06:28,320
peer-to-peer stuff is another 
big area of the code, maybe not 

103
00:06:28,600 --> 00:06:33,960
as much in recent years, but 
that's a big part of it as well.

104
00:06:33,960 --> 00:06:38,560
We've had a lot of policy work 
happening and work cluster 

105
00:06:38,560 --> 00:06:43,320
obviously has been the latest 
one that has gotten merged and 

106
00:06:43,320 --> 00:06:47,760
is getting close to being in AI 
guess final ish state. 

107
00:06:48,040 --> 00:06:51,680
But then also of course the 
policy related work that's been 

108
00:06:51,680 --> 00:06:57,000
a bit more in the news recently.
The IPC interface is a big one 

109
00:06:57,000 --> 00:07:01,160
that's been making a lot of 
progress this year, especially 

110
00:07:01,560 --> 00:07:04,480
multi process has been around 
for I think almost 10 years now.

111
00:07:04,480 --> 00:07:07,640
It's the longest running project
that's still open in Bitcoin 

112
00:07:07,640 --> 00:07:09,400
Core. 
But then thanks just just. 

113
00:07:09,680 --> 00:07:12,840
Real quick, you kind of want to 
like explain for your listeners 

114
00:07:12,840 --> 00:07:16,360
like what the multi process 
project is like, why that's been

115
00:07:16,360 --> 00:07:19,000
such a long ongoing project. 
Yeah, sure. 

116
00:07:19,080 --> 00:07:24,920
So the the goal of multi process
initially was to allow us to run

117
00:07:24,920 --> 00:07:28,000
different parts of what is 
currently Bitcoin Core into 

118
00:07:28,000 --> 00:07:29,840
separate processes. 
So Bitcoin Core is an 

119
00:07:29,840 --> 00:07:32,800
application that does a lot of 
things at the same time. 

120
00:07:32,960 --> 00:07:36,360
So I think the initial outline 
of that project was to have a 

121
00:07:36,360 --> 00:07:41,560
separate process to run the 
wallet, to run the node and to 

122
00:07:41,560 --> 00:07:43,000
run the GUI. 
Those were the three main 

123
00:07:43,000 --> 00:07:45,320
components where for example, 
you could run your node on your 

124
00:07:45,320 --> 00:07:47,240
remote server and run the GUI 
locally. 

125
00:07:47,240 --> 00:07:48,760
You could spin it up and down 
how you want it to. 

126
00:07:49,280 --> 00:07:53,600
So it enables certain new kinds 
of functionality and it also 

127
00:07:53,600 --> 00:07:57,120
offers security and safety 
benefits that process isolation 

128
00:07:57,120 --> 00:08:00,000
offer. 
It was a very ambitious project 

129
00:08:00,640 --> 00:08:03,320
and so it took a while to, you 
know, be developed and 

130
00:08:03,320 --> 00:08:06,080
especially to be reviewed as we 
kind of became inactive. 

131
00:08:07,720 --> 00:08:12,080
Well, this is before my time 
quite a few years ago until we 

132
00:08:12,080 --> 00:08:16,440
had a new use case pop up about 
a year ago or so because there 

133
00:08:16,440 --> 00:08:19,640
was there's a lot of work 
happening on Stratum V2, the 

134
00:08:19,640 --> 00:08:24,160
upgrades of the mining pool 
protocol to help mining pools 

135
00:08:24,160 --> 00:08:30,160
communicate with hashers. 
And an initial approach on 

136
00:08:30,200 --> 00:08:36,480
making Bitcoin Core compatible 
with Strata V2 was to basically 

137
00:08:36,720 --> 00:08:39,440
incorporate a lot of Strata V2 
logic into Bitcoin Core. 

138
00:08:40,120 --> 00:08:43,080
But this of course adds to the 
total service of the Bitcoin 

139
00:08:43,080 --> 00:08:45,440
Core code base. 
And so there was another 

140
00:08:45,440 --> 00:08:47,880
approach suggested to try and 
keep it out of Core and 

141
00:08:47,880 --> 00:08:51,400
basically have separate 
applications talk to each other 

142
00:08:52,000 --> 00:08:55,680
over IPC, over this inter 
process communication protocol. 

143
00:08:56,520 --> 00:08:59,120
And so that was like an actual 
real use case to help move the 

144
00:08:59,120 --> 00:09:04,400
multi process project forward. 
And that's also why we released 

145
00:09:04,520 --> 00:09:08,320
the mining interface. 
I think in version 29 it can be 

146
00:09:08,320 --> 00:09:11,160
off of the number as the first 
version to help strategy 2 

147
00:09:11,160 --> 00:09:13,880
clients connected with CONCORD 
without putting the strategy 2 

148
00:09:13,880 --> 00:09:17,320
logic in with CONCORD to help 
maintain that modularity. 

149
00:09:19,280 --> 00:09:22,320
Hey everyone, it's Shinobi and 
I'm here in front of the Chicago

150
00:09:22,320 --> 00:09:24,960
Fed to talk to you about the 
core issue of Bitcoin Magazine. 

151
00:09:25,400 --> 00:09:28,520
The last few years have been a 
bit of a communication breakdown

152
00:09:28,520 --> 00:09:30,800
between developers and people 
using Bitcoin. 

153
00:09:31,320 --> 00:09:33,080
Bitcoin exists to be an 
alternative. 

154
00:09:33,080 --> 00:09:36,200
To this institution. 
But to do that, it needs people 

155
00:09:36,200 --> 00:09:38,880
to actively maintain it. 
If you actually want to hear 

156
00:09:38,880 --> 00:09:41,640
from developers themselves, how 
they approach their work and 

157
00:09:41,640 --> 00:09:45,400
what they choose to work on, go 
to bitcoinmagazine.com and get 

158
00:09:45,400 --> 00:09:46,840
yourself a copy of The Core 
Issue. 

159
00:10:20,930 --> 00:10:26,480
And I mean, it's this is all 
kind of, I guess a giant project

160
00:10:26,480 --> 00:10:30,520
untangling the mess. 
I guess you could say Satoshi 

161
00:10:30,520 --> 00:10:34,360
left like if you if you 
actually, you know, even if you 

162
00:10:34,360 --> 00:10:39,520
don't program or really 
understand software engineering,

163
00:10:40,120 --> 00:10:44,480
like I think if you look at like
the code base today or like 

164
00:10:44,480 --> 00:10:48,720
other typical code bases versus 
what Satoshi released, like it 

165
00:10:48,720 --> 00:10:53,360
was just a giant BLOB of code 
with everything all tangled 

166
00:10:53,360 --> 00:10:55,840
together. 
Versus like traditionally 

167
00:10:55,840 --> 00:10:58,120
software is made modular to 
begin with. 

168
00:10:58,120 --> 00:11:01,440
Like you have this process over 
here, that process over here, 

169
00:11:01,520 --> 00:11:05,080
like cleanly talking to each 
other through a defined protocol

170
00:11:05,080 --> 00:11:10,800
or API. 
And yeah, I really, I really 

171
00:11:10,800 --> 00:11:14,560
think like viewers should, 
should appreciate like how 

172
00:11:14,560 --> 00:11:18,240
important something like this is
just from the point of view of 

173
00:11:18,600 --> 00:11:22,560
this is software developers have
to continue maintaining like 

174
00:11:22,560 --> 00:11:26,600
Bitcoin, even if the consensus 
rules never changing on. 

175
00:11:26,680 --> 00:11:30,000
Like it is not a piece of 
software that can just never 

176
00:11:30,000 --> 00:11:35,360
change, never have code updated 
to respond to changing realities

177
00:11:35,360 --> 00:11:39,280
of the world. 
And like, that really is a 

178
00:11:39,280 --> 00:11:43,080
necessary thing if we want 
people like yourself to continue

179
00:11:43,680 --> 00:11:46,320
spending your time actually 
keeping this working for us. 

180
00:11:46,600 --> 00:11:49,840
Yeah, no, absolutely. 
I think it's reality that like 

181
00:11:49,840 --> 00:11:52,400
software just needs to be 
maintained because you know, 

182
00:11:53,120 --> 00:11:55,480
change, compilers change and 
just keeping up to date with 

183
00:11:55,480 --> 00:11:58,600
that reality is already a 
reasonable part of the low. 

184
00:11:58,600 --> 00:12:01,920
But you also see the way that 
Bitcoin is used to changes. 

185
00:12:02,480 --> 00:12:07,320
I think the the min relay fee 
changes that were done a few 

186
00:12:07,320 --> 00:12:08,960
months ago I think are a good 
example of that. 

187
00:12:08,960 --> 00:12:13,080
That is not something that was 
initiated or pushed by Core, but

188
00:12:13,080 --> 00:12:15,320
it was something that Core had 
to react to because suddenly 

189
00:12:15,320 --> 00:12:18,880
users decided to use Bitcoin in 
a different way. 

190
00:12:18,920 --> 00:12:20,080
And so you have to react to 
that. 

191
00:12:21,760 --> 00:12:24,880
And then, yeah, there is reality
that like you're given a certain

192
00:12:24,880 --> 00:12:30,960
code base to work with, which 
was not perfect in all ways, but

193
00:12:30,960 --> 00:12:32,520
yeah, that's, that's what you 
have to deal with. 

194
00:12:33,120 --> 00:12:35,760
And so I think a lot of the work
that we're doing now is to help 

195
00:12:37,800 --> 00:12:41,520
turn that into a foundation that
we can build on for not just 

196
00:12:41,520 --> 00:12:42,840
next year, but for decades to 
come. 

197
00:12:43,000 --> 00:12:45,320
And a big part of that is just 
spending the time to, for 

198
00:12:45,320 --> 00:12:50,160
example, modularize code more as
we do with the kernel project 

199
00:12:50,800 --> 00:12:54,480
and to for example, with the 
multi process projects to just 

200
00:12:54,840 --> 00:12:58,480
increase that robustness. 
And that is also one of my 

201
00:12:58,480 --> 00:13:02,400
personal goals for the future is
to make sure that even with 

202
00:13:02,400 --> 00:13:07,240
reduced developer resources, we 
can still maintain and make make

203
00:13:07,240 --> 00:13:11,000
sure that Bitcoin Core is as 
reliable, robust and useful as 

204
00:13:11,000 --> 00:13:14,480
it is now, even if in the future
it will have more, more features

205
00:13:14,480 --> 00:13:17,160
and more functionality than it 
has now. 

206
00:13:19,120 --> 00:13:23,040
And I guess like, are there 
other big areas of the code base

207
00:13:23,040 --> 00:13:25,160
or projects you think are worth 
mentioning? 

208
00:13:25,760 --> 00:13:27,280
Oh yeah. 
So I think I already mentioned 

209
00:13:27,280 --> 00:13:29,760
to the the build system and CI 
is like 1 components. 

210
00:13:29,800 --> 00:13:33,520
You have all of the P to P logic
that deals with, you have all 

211
00:13:33,520 --> 00:13:35,840
these different Bitcoin nodes 
that need to talk to each other.

212
00:13:36,120 --> 00:13:38,800
How do you do that in a Safeway?
Because you're dealing with an 

213
00:13:38,800 --> 00:13:42,440
authenticated protocol. 
So you have to build in certain 

214
00:13:42,440 --> 00:13:44,640
defenses that people can't bring
down your nodes. 

215
00:13:44,720 --> 00:13:48,400
And that's a bit of a different 
paradigm than most other 

216
00:13:48,400 --> 00:13:52,120
software that is authenticated. 
Then of course you have a whole 

217
00:13:52,120 --> 00:13:54,720
lot of validation logic that 
deals with validating 

218
00:13:54,720 --> 00:13:58,360
transactions and blocks 
everything consensus related. 

219
00:13:59,720 --> 00:14:04,720
We also have a lot of effort 
focusing on testing these years.

220
00:14:05,200 --> 00:14:08,000
We have our unit tests and our 
functional tests, but then also 

221
00:14:08,960 --> 00:14:12,920
rather recent focus has been the
first testing, which has been 

222
00:14:12,920 --> 00:14:16,160
getting a lot of attention in 
recent years. 

223
00:14:16,400 --> 00:14:21,240
Basically in a smart way to 
hammer the system with all kinds

224
00:14:21,240 --> 00:14:24,040
of possible inputs and see what 
kind of output it creates and 

225
00:14:24,040 --> 00:14:25,400
see if that can crash your 
application. 

226
00:14:25,760 --> 00:14:29,120
Which helps you catch a whole 
range of issues that are just 

227
00:14:29,120 --> 00:14:31,960
very difficult to do with manual
testing because we're humans and

228
00:14:32,360 --> 00:14:35,680
we don't see all the options all
the time. 

229
00:14:37,160 --> 00:14:39,600
The wallet is not a big 
component of Bitcoin Core. 

230
00:14:41,400 --> 00:14:44,920
We also have a visual user 
interface, the GUI that helps 

231
00:14:44,920 --> 00:14:47,840
people that don't want to run 
Bitcoin Core in their command 

232
00:14:47,840 --> 00:14:53,240
line to give them a bit of a an 
easier access into the software.

233
00:14:54,400 --> 00:14:57,280
And we have some other more 
utility like software, for 

234
00:14:57,280 --> 00:15:01,240
example, some indexes that you 
can build with the concord for 

235
00:15:01,240 --> 00:15:08,240
common stats for addresses. 
And I think I'm probably 

236
00:15:08,240 --> 00:15:09,960
forgetting something, but I 
think top of mind, that's 

237
00:15:09,960 --> 00:15:14,560
roughly the main areas of work. 
And So what you know, when you 

238
00:15:14,560 --> 00:15:18,640
go through reviewing PRS in 
different sections of the code 

239
00:15:18,640 --> 00:15:22,400
base, like given the state of 
things now in like the past 

240
00:15:22,400 --> 00:15:27,200
couple years, like how often 
does somebody who say just wants

241
00:15:27,200 --> 00:15:30,960
to make a change to the wallets 
or something in the peer-to-peer

242
00:15:30,960 --> 00:15:35,840
logic have to kind of cross the 
boundaries and deal with other 

243
00:15:35,840 --> 00:15:40,120
parts of the code base? 
Like, is that like as common as 

244
00:15:40,120 --> 00:15:43,080
it used to be? 
I think that's improved a lot. 

245
00:15:43,800 --> 00:15:47,760
So a lot of the work that has 
already been done for the multi 

246
00:15:47,760 --> 00:15:52,920
process project was to basically
build those interfaces between 

247
00:15:52,920 --> 00:15:55,200
different parts of the code, for
example, between the node, 

248
00:15:55,200 --> 00:15:58,880
between the wallets, between P 
to P to really separate those 

249
00:15:58,880 --> 00:16:01,520
concerns. 
So if you make changes in the 

250
00:16:01,520 --> 00:16:05,280
wallet, you really should not 
have to be concerned about most 

251
00:16:05,280 --> 00:16:07,680
of the other codes. 
But there are exceptions like 

252
00:16:07,880 --> 00:16:11,840
the isolation is not perfect. 
And so when you do make those 

253
00:16:11,840 --> 00:16:15,440
changes, you do need someone 
with a bit more in depth 

254
00:16:15,440 --> 00:16:18,920
knowledge to verify that what 
looks like a safe change is a 

255
00:16:18,920 --> 00:16:20,920
need to save change because 
those side effects are sometimes

256
00:16:20,920 --> 00:16:24,080
hard to anticipate. 
So I'd say mostly it's in a 

257
00:16:24,640 --> 00:16:27,760
pretty good shape isolation 
wise, but not perfect, which 

258
00:16:27,760 --> 00:16:31,400
makes it. 
How much does it like slow down 

259
00:16:31,400 --> 00:16:35,720
the the progress in APR when 
somebody does have to deal with 

260
00:16:35,720 --> 00:16:38,920
that overlap and like consider 
what's going on in some other 

261
00:16:38,920 --> 00:16:41,920
system based on what they've 
changed and what they're working

262
00:16:41,920 --> 00:16:44,440
on? 
I think it's maybe one of the 

263
00:16:44,440 --> 00:16:48,720
biggest factors in, yeah, which 
PRS make progress and which 

264
00:16:48,720 --> 00:16:51,960
don't. 
Obviously, you know, people 

265
00:16:51,960 --> 00:16:55,640
review PRS as a function of how 
important they think that 

266
00:16:55,640 --> 00:16:58,040
changes. 
That's probably the biggest 

267
00:16:58,040 --> 00:16:59,600
factor. 
But then also how likely is it 

268
00:16:59,600 --> 00:17:01,880
to make progress? 
And is it going to get merged 

269
00:17:01,880 --> 00:17:04,240
eventually? 
Because if you know like no one 

270
00:17:04,240 --> 00:17:07,480
else is going to review it or 
it's just too complex to be 

271
00:17:07,480 --> 00:17:09,880
merged, then it's kind of hard 
to convince yourself to spend 

272
00:17:09,880 --> 00:17:12,280
time on something because it 
doesn't really serve an actual 

273
00:17:12,280 --> 00:17:16,240
purpose. 
It's assuming that the change is

274
00:17:16,240 --> 00:17:18,720
meaningful enough to satisfy 
that first criteria. 

275
00:17:20,599 --> 00:17:24,720
If the code that's being touched
is more complex, as in it 

276
00:17:24,720 --> 00:17:27,880
touches different systems, then 
people just find it much more 

277
00:17:27,880 --> 00:17:30,160
difficult to be confident that a
change is safe. 

278
00:17:31,280 --> 00:17:34,240
And then it becomes much more, 
again, much more difficult to 

279
00:17:34,240 --> 00:17:36,520
justify spending your time on 
that because you just, you have 

280
00:17:36,520 --> 00:17:39,680
to spend much more time reading 
the code and thinking about edge

281
00:17:39,680 --> 00:17:45,640
cases and maybe adding tests. 
And yeah, that's what I 

282
00:17:45,680 --> 00:17:47,840
personally see. 
I think those PRS usually stall 

283
00:17:47,840 --> 00:17:50,880
the most because it's just hard 
to stay enthusiastic and 

284
00:17:50,960 --> 00:17:52,960
motivated about working on that.
Yeah. 

285
00:17:52,960 --> 00:17:57,920
So the multi process project 
quite literally is something 

286
00:17:58,000 --> 00:18:02,640
that could drastically improve 
development pace and development

287
00:18:02,640 --> 00:18:07,240
speed like finishing the last I 
guess string of things that need

288
00:18:07,240 --> 00:18:09,160
to be finished there. 
I think it's actually already 

289
00:18:09,160 --> 00:18:14,240
done. 
The the isolation work, as far 

290
00:18:14,240 --> 00:18:18,400
as I've seen, is pretty much 
complete, the most outstanding 

291
00:18:18,400 --> 00:18:20,840
work that needs to be done. 
There is more the code that 

292
00:18:20,840 --> 00:18:22,760
actually deals with the 
communication between those 

293
00:18:22,760 --> 00:18:26,160
different parts, because you're 
suddenly talking about different

294
00:18:26,160 --> 00:18:28,120
processes that need to 
communicate to each other 

295
00:18:28,120 --> 00:18:31,560
efficiently, reliably. 
You need to be able to debug it 

296
00:18:31,640 --> 00:18:34,760
and kind of monitor those 
processes quite efficiently. 

297
00:18:35,400 --> 00:18:38,880
And that introduces new 
dependencies, which then again 

298
00:18:38,880 --> 00:18:41,800
need to be understood and 
reviewed because we shouldn't, 

299
00:18:41,800 --> 00:18:44,680
we don't dependencies in the 
code base without knowing that 

300
00:18:44,680 --> 00:18:49,560
they are secure and reliable and
have a, a minimum service to 

301
00:18:49,560 --> 00:18:52,080
introduce potential risks for 
the code. 

302
00:18:52,920 --> 00:18:56,080
And I think that's the main hold
up with multiples at the moment,

303
00:18:56,080 --> 00:18:58,720
is that that code is just fairly
complex. 

304
00:18:59,440 --> 00:19:02,280
And again, with some of these 
complaints, people are less 

305
00:19:02,280 --> 00:19:04,280
confident that it's safe. 
And if they're not confident 

306
00:19:04,280 --> 00:19:06,440
that it's safe, then they're 
going to be much more reluctant 

307
00:19:06,440 --> 00:19:10,480
to, to leave your X. 
And yeah, that's a, that's a 

308
00:19:10,480 --> 00:19:14,360
difficult thing to get out of. 
But having the actual demand, 

309
00:19:15,240 --> 00:19:17,400
you know, we, we had the use 
case now with the mining 

310
00:19:17,400 --> 00:19:20,480
interface for Stratton V2. 
And so the complexity is still 

311
00:19:20,480 --> 00:19:22,240
there. 
But if demand increases, then 

312
00:19:22,240 --> 00:19:24,520
you're more likely to make 
progress on these kind of 

313
00:19:24,520 --> 00:19:27,240
projects that are important. 
But it's just it takes more 

314
00:19:27,240 --> 00:19:28,880
resources all. 
Right. 

315
00:19:28,960 --> 00:19:33,800
And I guess, you know, when 
looking at like this kind of 

316
00:19:33,800 --> 00:19:38,360
work and the fact that a lot of 
developers time is kind of spent

317
00:19:39,040 --> 00:19:43,400
on this, I, I, I wouldn't call 
RE architecture completely, but 

318
00:19:43,400 --> 00:19:47,440
you know, the re architecting of
things and kind of polishing and

319
00:19:47,440 --> 00:19:51,960
streamlining things, maintenance
optimization, like a lot of 

320
00:19:51,960 --> 00:19:56,720
people in the community kind of 
look at those things being 

321
00:19:56,720 --> 00:20:01,200
prioritized and see that as 
something to criticize, like 

322
00:20:01,200 --> 00:20:03,680
they're better things that 
developers should be doing with 

323
00:20:03,680 --> 00:20:06,400
their time or more important 
things to focus on. 

324
00:20:07,080 --> 00:20:07,680
Like what? 
What? 

325
00:20:07,680 --> 00:20:11,520
What do you think when you hear 
like that type of criticism from

326
00:20:11,520 --> 00:20:15,760
people? 
I think it's definitely, there's

327
00:20:15,760 --> 00:20:19,120
a lot of truth to it. 
I think it's important that 

328
00:20:19,400 --> 00:20:24,200
developers work on projects and 
features that matter and that 

329
00:20:24,200 --> 00:20:26,920
have impact. 
And we shouldn't get lost in 

330
00:20:27,000 --> 00:20:33,120
academic exercises on, you know,
building stuff that is very nice

331
00:20:33,120 --> 00:20:35,400
on paper, but in practice it 
doesn't serve real purpose. 

332
00:20:35,400 --> 00:20:37,480
And I think it's important to 
keep an eye out for that. 

333
00:20:38,240 --> 00:20:43,840
But I also think the people 
working on Core do that because 

334
00:20:43,840 --> 00:20:46,920
of and in ways that they think 
are important. 

335
00:20:48,120 --> 00:20:50,360
It's because they get excited 
about certain projects. 

336
00:20:51,000 --> 00:20:54,120
And yeah, some or maybe even a 
lot of those projects at the 

337
00:20:54,120 --> 00:20:59,080
moment are focused more on 
maintenance or improving the 

338
00:20:59,120 --> 00:21:03,680
robustness of Core rather than 
adding new features like 

339
00:21:03,800 --> 00:21:06,920
protocol upgrades or covenants, 
which is a big one. 

340
00:21:08,160 --> 00:21:13,680
And I don't think 1 should be 
done instead of the other. 

341
00:21:13,920 --> 00:21:16,360
It's more a function of what are
the people working on the 

342
00:21:16,360 --> 00:21:20,240
software care about the most 
based on their experience and 

343
00:21:20,240 --> 00:21:22,320
their view. 
And I think a lot of people, at 

344
00:21:22,320 --> 00:21:25,560
least it's my own personal 
preference, my priority for 

345
00:21:25,640 --> 00:21:30,400
working on Core is to make sure 
that we can we have this 

346
00:21:30,400 --> 00:21:34,640
foundation that we can easily 
and reliably keep building on 

347
00:21:35,400 --> 00:21:38,680
for the next decades to come. 
And I think having software that

348
00:21:38,680 --> 00:21:41,480
is easy to maintain, easy to 
understand, easy to review, 

349
00:21:41,720 --> 00:21:44,080
increases the pace of future 
development. 

350
00:21:44,080 --> 00:21:46,560
Because if you have code that 
you can easily grog, that you 

351
00:21:46,560 --> 00:21:50,040
can safely make changes to 
because you have good testing 

352
00:21:50,040 --> 00:21:53,080
infrastructure in place that is 
more modern. 

353
00:21:53,080 --> 00:21:56,360
So it can't introduce some of 
the bugs that you could have 

354
00:21:56,360 --> 00:21:59,040
with like older C code, for 
example. 

355
00:21:59,960 --> 00:22:06,000
That's kind of investing into. 
You invest time now and you 

356
00:22:06,000 --> 00:22:08,720
expect to get a return on the 
time in the future because 

357
00:22:08,760 --> 00:22:12,520
adding features on the code base
that you don't understand, it's 

358
00:22:12,520 --> 00:22:15,360
just incredibly dangerous to do.
And you know, after all, we are 

359
00:22:15,360 --> 00:22:20,120
building software for the future
that should never introduce any 

360
00:22:22,120 --> 00:22:24,720
significant bugs, especially 
stuff like consensus fields that

361
00:22:24,720 --> 00:22:27,000
that's absolutely critical to 
the system. 

362
00:22:28,000 --> 00:22:33,520
And so, yeah, I think neglecting
the importance of those kind of 

363
00:22:33,520 --> 00:22:36,040
changes, having good testing, 
having good build systems, 

364
00:22:36,240 --> 00:22:40,080
having good modularity, having 
modern and easy to understand in

365
00:22:40,080 --> 00:22:44,200
code is absolutely critical for 
being able to do the also 

366
00:22:44,200 --> 00:22:46,320
important work such as protocol 
upgrades. 

367
00:22:47,840 --> 00:22:51,240
So yeah, I just invite anyone 
that thinks that a certain 

368
00:22:51,240 --> 00:22:56,160
feature or change is important 
to conjoin and and help us do 

369
00:22:56,160 --> 00:22:59,560
the work, not instead of just in
addition to. 

370
00:22:59,960 --> 00:23:01,680
Both things I think can happen 
at the same time. 

371
00:23:02,360 --> 00:23:05,800
Yeah, I mean, it's kind of like,
you know, your car breaks down. 

372
00:23:05,800 --> 00:23:11,840
Do you just stubbornly go deal 
with the, you know, complexity 

373
00:23:11,920 --> 00:23:15,200
of public transit or taking a 
cab everywhere and the extra 

374
00:23:15,200 --> 00:23:17,360
cost? 
Or do you just take the time and

375
00:23:17,360 --> 00:23:19,920
fix your damn car so you can get
where you need to go? 

376
00:23:19,920 --> 00:23:22,720
All right. 
Well, I really appreciate you 

377
00:23:22,720 --> 00:23:24,440
sitting down and talking to me 
about this, Stefan. 

378
00:23:25,080 --> 00:23:29,440
And I hope everybody who watched
this has a little bit better of 

379
00:23:29,440 --> 00:23:34,080
an idea as to how core is 
organized as a project and why 

380
00:23:34,520 --> 00:23:36,920
developers prioritize certain 
things over the other. 

381
00:23:37,520 --> 00:23:39,640
So thank you again. 
Thanks for the chat.