1
00:00:00,000 --> 00:00:07,760
Good day all you Liberty lovers and welcome to Fiendish and Friends episode 11 when we have a legend of the Bitcoin Cash

2
00:00:08,220 --> 00:00:09,120
ecosystem

3
00:00:09,120 --> 00:00:15,740
Jason Drazener joining us to talk about his proposed chips and developments including and I've got to take a big breath right now

4
00:00:16,300 --> 00:00:24,280
To get this all out. OP eval, pay2script, loops as well. Not only that but the fresh of the press proposed chip

5
00:00:24,280 --> 00:00:29,280
transaction version 5 and this includes many things including

6
00:00:29,880 --> 00:00:37,460
zero overhead covenants, detached signatures, comprehensive malleability protection, efficient covenant UTXO

7
00:00:37,720 --> 00:00:41,800
recycling, fractional satashis and fractional cash tokens

8
00:00:42,280 --> 00:00:49,640
Wow, someone's been a busy beaver. Hi Jason, welcome to Fiendish and Friends. It's a privilege to have you join us today

9
00:00:49,640 --> 00:00:53,640
Thank you for the intro. I'll try not to let it go to my head

10
00:00:54,640 --> 00:01:00,360
Yeah, to be honest, it's been it's been great seeing this because you know, you just locked in big ints and

11
00:01:02,520 --> 00:01:04,900
The virtual machine limits upgrade and

12
00:01:06,440 --> 00:01:09,840
Pretty much just a few weeks after that you come in and

13
00:01:11,280 --> 00:01:15,040
With some new chips, so no pause for the wicked

14
00:01:15,040 --> 00:01:22,440
By the way, I was actually looking at my notes the last time we were on a podcast together was way back in

15
00:01:23,560 --> 00:01:27,540
2022 that was when we were discussing the cash tokens upgrade

16
00:01:28,080 --> 00:01:31,680
Which was yeah, of course another one of your chips

17
00:01:31,680 --> 00:01:35,420
I guess everyone in the Bitcoin Cash ecosystem is well aware of cash tokens now

18
00:01:36,520 --> 00:01:44,480
Yeah, so anyway before we start delving into the weeds as this is your first time on Finnish and Friends and to ensure that everyone

19
00:01:44,480 --> 00:01:49,720
Out there knows exactly who you are. It'd be great to have an introduction

20
00:01:49,720 --> 00:01:56,280
So Jason, maybe you could just tell everyone who are you what you do and why all this incredible work towards Bitcoin Cash

21
00:01:57,440 --> 00:02:02,640
Thanks. Yeah, I've been working on I came to Bitcoin for the freedom

22
00:02:03,120 --> 00:02:07,680
I've been working on you know, professionally on Bitcoin Cash since 2013

23
00:02:07,680 --> 00:02:12,200
I was at Bitpay from 2013 to 2019 and I've been working on

24
00:02:12,200 --> 00:02:14,200
protocol improvements

25
00:02:14,600 --> 00:02:16,600
Necessary to make some

26
00:02:17,440 --> 00:02:19,440
Exciting

27
00:02:19,840 --> 00:02:22,000
On-chain applications possible since then

28
00:02:25,360 --> 00:02:26,840
Yeah, cool

29
00:02:26,840 --> 00:02:28,840
So you've been around for a long time

30
00:02:29,440 --> 00:02:32,080
It's been a while. It's been a while. Yeah

31
00:02:32,080 --> 00:02:32,360
Okay

32
00:02:32,360 --> 00:02:32,880
Yeah

33
00:02:32,880 --> 00:02:37,760
And I said so cash tokens was the last time we did a podcast together on the space together

34
00:02:38,280 --> 00:02:40,280
And this was one of the more

35
00:02:40,280 --> 00:02:45,240
Hyped upgrades of BCH's history. So just as a reflection to begin with, you know

36
00:02:45,240 --> 00:02:50,640
How have you personally found the results of cash tokens on the ecosystem since the upgrade in?

37
00:02:51,400 --> 00:02:53,400
2023

38
00:02:55,680 --> 00:03:00,080
Yeah, it's going well, there's a ton of work to do and

39
00:03:01,200 --> 00:03:02,840
in a lot of ways

40
00:03:02,840 --> 00:03:04,840
ketchup to do with

41
00:03:04,880 --> 00:03:06,880
many of the other

42
00:03:06,880 --> 00:03:13,880
Popular layer one networks that that in some cases were able to launch with token support and many of the

43
00:03:14,400 --> 00:03:16,400
Applications that we consider to be

44
00:03:16,880 --> 00:03:18,880
Very common in the space

45
00:03:19,120 --> 00:03:24,720
We're designed, you know, for example on aetherium because aetherium was the only player in town to do

46
00:03:25,520 --> 00:03:27,520
Interesting on chain protocols for a while

47
00:03:28,640 --> 00:03:32,160
And as we sort of discovered over the past few years

48
00:03:32,160 --> 00:03:35,680
That was a result almost entirely of some

49
00:03:36,480 --> 00:03:40,480
some rather silly virtual machine limits that that got

50
00:03:41,280 --> 00:03:43,280
reduced in 2010 and

51
00:03:43,920 --> 00:03:48,320
Essentially, no work. No progress was made on them until very recently

52
00:03:49,280 --> 00:03:51,280
so

53
00:03:51,280 --> 00:03:56,080
cash tokens was a was a good way to make a lot of

54
00:03:57,520 --> 00:04:00,880
Financial applications various things like that

55
00:04:00,880 --> 00:04:05,920
So we can express a lot of financial applications in in very short transactions and they're very quick to validate

56
00:04:07,120 --> 00:04:10,160
And they're useful for for representing a lot of things

57
00:04:11,200 --> 00:04:14,160
But then there are also some other virtual machine

58
00:04:14,880 --> 00:04:16,880
Limits that made it very difficult to do

59
00:04:17,840 --> 00:04:24,320
Even pretty trivial computations like like doing the math for a market making algorithm just calculating based on how much

60
00:04:24,640 --> 00:04:26,640
BCH you have and how many tokens you have

61
00:04:26,640 --> 00:04:32,240
What the what the new price should be? That was that was difficult to do even though

62
00:04:32,480 --> 00:04:38,400
You know, that's microseconds on on on a processor right or significantly less than that. I'm

63
00:04:39,360 --> 00:04:41,360
using

64
00:04:42,400 --> 00:04:44,400
So getting vm limits

65
00:04:45,440 --> 00:04:47,440
Fixed up this year

66
00:04:47,920 --> 00:04:52,880
Really opens up the space a lot for some of the other issues that have been sort of on hold since

67
00:04:52,880 --> 00:04:58,800
since 2010 in a lot of ways, so you know satoshi's original virtual machine

68
00:04:59,680 --> 00:05:06,000
Satoshi's original bitcoin system had a very very capable virtual machine the script system

69
00:05:06,800 --> 00:05:08,800
that

70
00:05:09,520 --> 00:05:14,640
Essentially right out of the gate would have supported anything you've seen on any cryptocurrency for sure

71
00:05:15,520 --> 00:05:20,000
Its issues were that it was a very academic approach to the

72
00:05:20,000 --> 00:05:23,280
to the problem and he had essentially just missed a

73
00:05:24,080 --> 00:05:26,080
very obvious

74
00:05:26,800 --> 00:05:28,800
set of exploits

75
00:05:29,120 --> 00:05:34,800
But he he by in taking a very academic approach. He basically tried to make the virtual machine

76
00:05:35,440 --> 00:05:39,280
Work without any limits by making it not Turing complete

77
00:05:40,080 --> 00:05:46,240
And so he didn't add any limits and he kind of told himself that that was sufficient because it's not Turing complete

78
00:05:46,240 --> 00:05:51,360
But of course the real world operates on on computers that that exist in reality

79
00:05:52,000 --> 00:05:56,720
And those computers have limited things like limited memory limited limited compute

80
00:05:57,680 --> 00:06:00,720
So, you know, he he discovered it very

81
00:06:01,520 --> 00:06:05,200
very suddenly like more than a year after the the

82
00:06:05,600 --> 00:06:09,120
Protocol had been launched and was in production like people were using bitcoin

83
00:06:09,680 --> 00:06:11,680
Just transactions back and forth to each other

84
00:06:11,680 --> 00:06:16,720
They were essentially for about a year and a half before on the bitcoin talk forums

85
00:06:17,520 --> 00:06:19,760
Gavin asks. Hey, what's this script thing?

86
00:06:20,640 --> 00:06:24,640
And you can see that the wheels turning very quickly you see like within eight hours

87
00:06:24,640 --> 00:06:29,680
It's really clear that satoshi like hadn't looked at it in a little while and he's on this

88
00:06:29,680 --> 00:06:34,800
He's on this protocol hardening kick and and he looks at the script system again, and he's like, oh god

89
00:06:34,800 --> 00:06:36,800
There's a lot we need to fix here

90
00:06:36,800 --> 00:06:41,840
And he was lucky at that point that it wasn't really used very much because I guess if he were to release something in that state

91
00:06:41,840 --> 00:06:44,800
Today as it was it's just gonna be oh, yeah

92
00:06:44,800 --> 00:06:48,320
Oh for sure. Yeah, I mean like it was possible

93
00:06:48,320 --> 00:06:51,840
I mean there were zero days to take anyone's money from any address like the

94
00:06:52,080 --> 00:06:56,320
You you could just put op return in and get anybody's money out of any address without providing a signature

95
00:06:56,320 --> 00:06:58,320
I mean, there's just a lot of good. Yeah

96
00:06:59,040 --> 00:07:01,040
That's a good basis of a money

97
00:07:01,040 --> 00:07:03,040
Just a good basis of a money

98
00:07:03,040 --> 00:07:08,640
That sounds good. Yeah, that's a good basis of a money. Yeah

99
00:07:09,360 --> 00:07:13,360
Uh in some ways it's a it's an indicator that whoever was working on the script system

100
00:07:13,360 --> 00:07:19,280
At least was a single was probably a single brain because they didn't talk about it with with another person very much

101
00:07:19,520 --> 00:07:24,400
Or they probably would have between each other like, you know penetrated some of the issues here

102
00:07:24,880 --> 00:07:29,200
Just that's why she was one person then from from your perspective at least whoever was working on the script system

103
00:07:29,280 --> 00:07:32,320
Script system was definitely one person and they didn't explain it to anybody else

104
00:07:32,320 --> 00:07:34,320
in the details

105
00:07:34,320 --> 00:07:36,240
Yeah, so um

106
00:07:36,240 --> 00:07:39,360
Or or they didn't explain it to anybody else who was who was technically in the details

107
00:07:39,760 --> 00:07:42,160
um the uh

108
00:07:42,160 --> 00:07:43,760
But yeah, so um

109
00:07:43,760 --> 00:07:51,600
Then you know fast forward a number of years. Um satoshi or i'll say, you know, so in 2010 he he uh, I guess is it 2011

110
00:07:51,680 --> 00:07:56,880
Wow. Yeah, uh, no, it's 2010. Yeah 2010 because he disappears at the end of 2010. Um

111
00:07:56,880 --> 00:08:00,080
Um, that's right

112
00:08:05,280 --> 00:08:08,560
I'm not fresh for sure on this stuff. Um, but uh

113
00:08:09,600 --> 00:08:11,600
He he then rapidly

114
00:08:11,760 --> 00:08:13,760
Um makes a bunch of patches

115
00:08:13,760 --> 00:08:14,480
um

116
00:08:14,480 --> 00:08:21,120
The first of you know, the first is like just a massive overhaul and then another massive overhaul comes like literally three days later

117
00:08:21,120 --> 00:08:27,920
Um, and then like another week later, there's some other massive changes and you know, he's disabling stuff and cutting stuff and setting magic

118
00:08:28,240 --> 00:08:30,480
Magic numbers for various constant limits

119
00:08:30,880 --> 00:08:33,360
um, just absolutely shredding it um

120
00:08:35,360 --> 00:08:43,600
And over the I think there are like six or seven, you know non-trivial consensus changes, uh, he schedules the first soft fork

121
00:08:44,160 --> 00:08:47,760
Um, and and then once it's done he he cleans it up

122
00:08:47,760 --> 00:08:53,120
Um by removing the logic from before because it's not necessary. It applies right over it. Um

123
00:08:54,240 --> 00:08:55,840
the uh

124
00:08:55,840 --> 00:08:59,120
There's uh, he adds the op-nop codes. Um

125
00:08:59,760 --> 00:09:05,440
The 201 opcode limit there's a lot a number of things there and then um, and then he disappears at the end of the year

126
00:09:05,840 --> 00:09:07,840
and and all all

127
00:09:08,080 --> 00:09:14,720
Progress and and in a lot of ways even interest in this mostly mostly fades. Um, it pops back up a little bit

128
00:09:14,720 --> 00:09:21,200
Uh again in 2020 uh 2012 with people talking about op eval which eventually became

129
00:09:21,760 --> 00:09:23,520
uh

130
00:09:23,520 --> 00:09:25,520
Paid a script hash

131
00:09:26,000 --> 00:09:28,960
But for the most part people were interested in use cases

132
00:09:30,000 --> 00:09:31,840
essentially that let people

133
00:09:31,840 --> 00:09:35,200
Uh give out addresses that had multi-signature conditions

134
00:09:36,400 --> 00:09:37,840
and so um

135
00:09:37,840 --> 00:09:42,800
Being able to support multi-signature wallets and coincidentally that is when I started working on bitcoin cash

136
00:09:42,800 --> 00:09:47,840
And and I worked at bitpay on the the first multi-signature wallet

137
00:09:48,400 --> 00:09:52,640
Copay, uh, I I led the design of of copay at that time

138
00:09:53,120 --> 00:09:54,640
um

139
00:09:54,640 --> 00:09:56,640
Yeah, being one of the only designers

140
00:09:58,000 --> 00:10:01,440
With a with a team of a few designers also, um

141
00:10:02,720 --> 00:10:04,320
uh

142
00:10:04,320 --> 00:10:06,320
then the

143
00:10:06,480 --> 00:10:08,560
Multi-sig uh multi-sig stuff

144
00:10:09,200 --> 00:10:10,480
finally

145
00:10:10,480 --> 00:10:15,840
Being possible after pay, uh p2sh, um probably attracted some more interest to the script system

146
00:10:16,640 --> 00:10:19,280
but um then the block size, uh

147
00:10:19,920 --> 00:10:23,440
Block size war essentially stopped all development in this in this

148
00:10:24,160 --> 00:10:25,920
field um

149
00:10:25,920 --> 00:10:28,080
until until 2017

150
00:10:28,560 --> 00:10:34,160
Uh 2018 we got a lot of op codes reintroduced. Um, uh

151
00:10:34,160 --> 00:10:40,320
Uh, there's probably a few other yeah, then there's a check check data sig happened in 2019

152
00:10:40,880 --> 00:10:46,800
Um 2022 we got introspection 2023. Um cash tokens, uh finally

153
00:10:47,520 --> 00:10:49,040
opened back up

154
00:10:49,040 --> 00:10:50,000
um

155
00:10:50,000 --> 00:10:52,000
general computation

156
00:10:52,000 --> 00:10:54,640
on on the virtual machine though with very very

157
00:10:56,320 --> 00:11:01,680
Low limits and so you had to do quite a few workarounds to get anything to get a lot of useful stuff done

158
00:11:01,680 --> 00:11:06,160
Um, there are a lot of things you you could already do even just with cash tokens

159
00:11:06,480 --> 00:11:10,400
Um, because you can express things pretty efficiently for some financial applications

160
00:11:10,800 --> 00:11:12,000
um

161
00:11:12,000 --> 00:11:17,360
but if you start having to do serious math you you have to break out your computations into multiple inputs and

162
00:11:18,080 --> 00:11:20,720
essentially, that's where things get purely theoretical because

163
00:11:22,000 --> 00:11:23,680
very few people

164
00:11:23,680 --> 00:11:26,960
Even really comprehend how to break apart the problem not

165
00:11:26,960 --> 00:11:31,360
Uh certainly not enough to uh build, um

166
00:11:32,160 --> 00:11:35,840
To build, you know user facing real world usable applications using it

167
00:11:36,320 --> 00:11:40,640
Yeah, exactly. I guess this is where the the big ink comes in for the for the upgrade that's locked this may

168
00:11:41,200 --> 00:11:44,000
Yes, and and the virtual machine limits so, you know, uh

169
00:11:45,280 --> 00:11:49,360
This is the virtual vm limits was a was a huge unlock

170
00:11:50,640 --> 00:11:52,640
That was that was preventing

171
00:11:52,960 --> 00:11:54,000
um

172
00:11:54,000 --> 00:11:58,560
a lot of otherwise quite simple improvements to to our

173
00:11:59,600 --> 00:12:03,360
our virtual machine how we can express programs, um simply because

174
00:12:03,840 --> 00:12:04,960
uh

175
00:12:04,960 --> 00:12:11,280
Before we we basically didn't have limits before except for some magic constants that applied at different places

176
00:12:11,760 --> 00:12:16,400
Um, and we're we're relative based on uh, the encoding format

177
00:12:17,520 --> 00:12:20,160
So our virtual machine limits only

178
00:12:20,160 --> 00:12:22,960
Uh were only implicitly defined

179
00:12:23,520 --> 00:12:30,080
And and the encoding format of the transaction was an important part of what the actual limits were

180
00:12:30,480 --> 00:12:32,960
um, and it's kind of insane to even describe it that way like uh

181
00:12:33,760 --> 00:12:42,640
To to know what the worst case performance of the virtual machine was with maximum size blocks producing the maximum compute transactions

182
00:12:43,120 --> 00:12:46,960
Um, you had to account for how many bytes they would take to encode

183
00:12:46,960 --> 00:12:51,200
And then apply your magic constants in the right spots to figure out what the actual limits were

184
00:12:52,240 --> 00:12:56,800
And so that was that was the work for that for last year was like just just

185
00:12:57,680 --> 00:13:04,800
Observing our system sufficiently to see where all of our limits were and then putting explicit limits in those spots

186
00:13:06,160 --> 00:13:13,200
Um, and that was uh, that was a just a gargantuan task that um, that is thank god finally done

187
00:13:13,200 --> 00:13:18,560
Thank god finally done. Um, and so there are a lot of other things now that um

188
00:13:19,120 --> 00:13:24,960
With with explicit limits now, there there's no program that that can be defined in in

189
00:13:25,600 --> 00:13:30,640
In bitcoin caches vm bytecode format. There's no program that can be defined that way without

190
00:13:31,280 --> 00:13:32,560
um

191
00:13:32,560 --> 00:13:38,800
That is not covered by the explicit limits and and it's it's very obviously and directly applied

192
00:13:38,800 --> 00:13:43,520
Um, there's there's nothing you can do that doesn't exhaust some limit. Um

193
00:13:44,400 --> 00:13:46,640
even pushing uh pushing data which

194
00:13:47,040 --> 00:13:51,120
Um, there there are a number of things that you know, when you first look at the problem

195
00:13:51,200 --> 00:13:53,600
It's really easy to be like, okay, we don't need any limits over that

196
00:13:54,000 --> 00:14:00,320
Um, but if you if you don't do it very comprehensively you start to run into issues the moment you start to talk about like

197
00:14:00,400 --> 00:14:02,240
Okay, can we make our fourth?

198
00:14:02,240 --> 00:14:07,200
Uh, our you know our fourth the vm bytecode language. Can we make it do loops?

199
00:14:07,200 --> 00:14:09,200
Can we make a do function application?

200
00:14:10,000 --> 00:14:14,800
Um, can we can we reallow pay to script instead of just pay to script hash?

201
00:14:15,520 --> 00:14:21,040
and a number of other things and the the vm limits chip talks at length about all of the

202
00:14:21,840 --> 00:14:25,440
um, essentially every other proposal, um

203
00:14:26,240 --> 00:14:29,360
About which we knew that has ever that has ever been made

204
00:14:30,320 --> 00:14:35,280
We wanted to make sure that the that the limit the explicit limits we we had

205
00:14:35,280 --> 00:14:37,280
Uh identified

206
00:14:37,280 --> 00:14:38,800
um

207
00:14:38,800 --> 00:14:41,520
Would also work even if we did need to make

208
00:14:41,840 --> 00:14:47,920
You know a small change here that allowed control flow to loop back over one part of the program or or if we added switch

209
00:14:48,000 --> 00:14:50,000
Statements or if we did obi val or things like that

210
00:14:50,480 --> 00:14:51,680
um

211
00:14:51,680 --> 00:14:52,720
so

212
00:14:52,720 --> 00:14:56,080
Yes, the virtual machine limit upgrade for the 2025 upgrade

213
00:14:57,680 --> 00:15:02,640
Makes the the previously implicit limits very explicit and it applies them

214
00:15:02,640 --> 00:15:07,700
Completely comprehensively to every byte you can possibly execute in the virtual machine

215
00:15:08,420 --> 00:15:12,580
Um, and that's the critical critical thing to understand. So, um

216
00:15:13,380 --> 00:15:16,900
Once you have vm limits, let's just get back to that point because yeah

217
00:15:16,900 --> 00:15:21,620
I'm thinking for people that are listening if it wasn't explicitly limited what what what's the outcome?

218
00:15:21,620 --> 00:15:26,100
Like what what's that? Why is that good or why is the opposite of that bad or dangerous?

219
00:15:26,500 --> 00:15:28,500
um, so the

220
00:15:28,500 --> 00:15:34,660
Um, we know that the the state it was in before and you know by definition it wasn't dangerous because that's how it was working

221
00:15:35,220 --> 00:15:37,220
So we know that that was safe, right?

222
00:15:37,140 --> 00:15:43,460
Um, at least so I wouldn't yeah, but but the question is like what can you change while?

223
00:15:44,100 --> 00:15:47,300
While like what can you what kind of improvements can you make without?

224
00:15:47,860 --> 00:15:50,340
Totally deleting that safety guarantee, right?

225
00:15:51,220 --> 00:15:56,500
And obi val is the is the the oldest most most ancient example

226
00:15:56,500 --> 00:16:00,980
Um, you you cannot make any changes i'll say even

227
00:16:02,420 --> 00:16:04,420
This this may maybe will be um

228
00:16:05,060 --> 00:16:10,420
A good indication of just how delicate it was before. I don't I don't think many people

229
00:16:10,820 --> 00:16:13,380
uh really understood that

230
00:16:14,180 --> 00:16:18,580
Changing the minimum transaction size amounted to a 2x

231
00:16:19,700 --> 00:16:21,700
almost 2x

232
00:16:21,700 --> 00:16:25,940
Increase in the worst case performance of the virtual machine

233
00:16:27,700 --> 00:16:29,700
Because the limits were implicit

234
00:16:29,700 --> 00:16:35,380
Um, so, you know the worst case attack before was 100 100 byte transactions

235
00:16:35,780 --> 00:16:42,740
And and the new worst case was 65 byte transactions. And so you get um, and you get an almost 50%

236
00:16:43,780 --> 00:16:45,780
increase in the worst case

237
00:16:45,780 --> 00:16:52,420
Standard, uh, so, you know, this is also in the mempool not just like a miner has to mine an attack block. This is this was

238
00:16:52,900 --> 00:16:53,860
you know

239
00:16:53,860 --> 00:16:54,820
Yeah

240
00:16:54,820 --> 00:16:56,820
In place in on the live network

241
00:16:57,140 --> 00:16:58,180
um

242
00:16:58,180 --> 00:17:01,220
So implicit limits are just a terrible idea. Um

243
00:17:02,820 --> 00:17:06,020
And they they they bleed and and

244
00:17:07,060 --> 00:17:10,420
leak out their their problems over every other

245
00:17:11,220 --> 00:17:13,700
possible improvement to the protocol, um

246
00:17:13,700 --> 00:17:16,900
And they make it really hard to even reason about

247
00:17:17,860 --> 00:17:18,900
uh

248
00:17:18,900 --> 00:17:24,820
What happens if you add support for loops or what happens if you add support for for function definition?

249
00:17:25,380 --> 00:17:27,060
um

250
00:17:27,060 --> 00:17:31,540
Which op eval is a is a way to do function definition. Um

251
00:17:32,260 --> 00:17:37,140
So things that you come to expect things that you you would expect of any programming language. We don't have

252
00:17:37,940 --> 00:17:40,180
because of essentially a vestige of

253
00:17:40,880 --> 00:17:42,500
satoshi's original

254
00:17:42,500 --> 00:17:44,740
Um kind of half-baked approach to limits

255
00:17:45,540 --> 00:17:51,860
And when he ripped all of that out, he he didn't remove this comment at the top of the script interpreter that said

256
00:17:52,340 --> 00:17:54,340
Uh, the script system has no loops

257
00:17:54,820 --> 00:17:59,220
Even though that was no longer his limit strategy. It was not relevant at all to the code below it

258
00:17:59,940 --> 00:18:00,820
But he didn't delete it

259
00:18:00,820 --> 00:18:08,100
So it like misled this this whole maybe, you know, six six to nine years of new developers who who read that who read that code?

260
00:18:08,100 --> 00:18:12,660
Just accepted as I read that comment just accepted it kind of you know

261
00:18:13,700 --> 00:18:15,700
without without critical thought

262
00:18:16,180 --> 00:18:18,820
and and it defined the uh

263
00:18:20,340 --> 00:18:21,780
What people

264
00:18:21,780 --> 00:18:29,540
Came to understand. Yeah came to believe about the the script system, you know being that that people believed that being

265
00:18:30,660 --> 00:18:35,060
Not Turing complete was an important property. Not not just that like being you know

266
00:18:35,060 --> 00:18:39,140
Uh, the the whole discussion about Turing completely was just completely useless

267
00:18:40,420 --> 00:18:44,020
Completely a red hair. It did not matter at all whether or not it was Turing complete

268
00:18:44,580 --> 00:18:48,900
all that mattered is what actually happens when when you validate a transaction and

269
00:18:49,380 --> 00:18:53,060
whether or not you're the the encoding you're using happens to be

270
00:18:53,700 --> 00:18:58,100
Turing complete or if it if it terminates because you have limits somewhere else

271
00:18:58,900 --> 00:19:00,900
And and you just expressed it less efficiently

272
00:19:00,900 --> 00:19:06,100
Um, so either one is the same result. Um, you know, it's either

273
00:19:06,820 --> 00:19:11,700
You either can express or not a use case and it either fails earlier or it doesn't

274
00:19:13,220 --> 00:19:15,220
but uh, anyways

275
00:19:15,540 --> 00:19:19,300
Once we got but getting past the the the vm limits

276
00:19:21,460 --> 00:19:26,100
Upgrade for 2025 it's now possible for us to to look at

277
00:19:27,700 --> 00:19:29,540
some of these

278
00:19:29,540 --> 00:19:32,020
You know big issues for contract authors like right now

279
00:19:32,660 --> 00:19:34,660
We cannot reliably say

280
00:19:35,540 --> 00:19:37,540
Check all of the input values

281
00:19:38,340 --> 00:19:40,100
And add them together

282
00:19:40,100 --> 00:19:42,820
It's not a reliable way to say that that you have to

283
00:19:43,460 --> 00:19:48,180
You have to instead of like saying hey loop through all the inputs and add them together. You have to say

284
00:19:49,140 --> 00:19:56,260
If there's one input add the value of input one if there are two inputs add the value of input one and two if there are

285
00:19:56,260 --> 00:20:02,420
Three inputs add the input a value one two and three and I i'm not kidding like it is it is truly absurd

286
00:20:02,900 --> 00:20:06,100
Um, just a joke that you you wouldn't even consider right?

287
00:20:06,100 --> 00:20:11,140
You know writing in a programming language that looked like this if it wasn't if it wasn't bitcoin or bitcoin cash

288
00:20:11,540 --> 00:20:14,340
um, but you know, we've we've had kind of

289
00:20:15,300 --> 00:20:20,100
a decade of of kind of stagnation on the development there, um

290
00:20:21,140 --> 00:20:22,260
and

291
00:20:22,260 --> 00:20:28,260
Uh, people were really making do and we're we are still making do a lot of contracts and bitcoin cash right now

292
00:20:28,260 --> 00:20:30,260
We're still making do without loops

293
00:20:31,140 --> 00:20:34,340
And uh, and it gets there are other cases where um

294
00:20:35,220 --> 00:20:37,380
So that's the case for loops for op eval

295
00:20:37,860 --> 00:20:39,860
um the the

296
00:20:40,900 --> 00:20:43,940
We can use the very same case if you need to um

297
00:20:44,900 --> 00:20:46,900
Take uh take the average

298
00:20:48,100 --> 00:20:48,900
of

299
00:20:48,900 --> 00:20:55,380
Of two numbers or something, uh and and add it to each input. I mean like just just some sort of

300
00:20:56,180 --> 00:20:59,220
Run some sort of mathematical function on each input

301
00:20:59,780 --> 00:21:01,780
well now you need to if

302
00:21:02,180 --> 00:21:07,700
If there's one input check the input value here and then specify all your code for the mathematical function

303
00:21:08,340 --> 00:21:14,660
And if there are two inputs grab the input one and grab input two and specify all the mathematical code for input one

304
00:21:14,660 --> 00:21:20,340
And specify all the mathematical code for input two and add them together. Whatever. Um, if there are three inputs

305
00:21:20,340 --> 00:21:23,140
Do it the same do the same thing for input one input two input three

306
00:21:23,380 --> 00:21:27,380
And also you have copied and pasted your your mathematical code six times now, right?

307
00:21:27,380 --> 00:21:32,020
It's factorial increase in the size of the program and that's just for one function

308
00:21:32,340 --> 00:21:33,700
Just for one function application

309
00:21:33,700 --> 00:21:37,140
Now if you start getting like if you do a function that needs to call another function

310
00:21:37,460 --> 00:21:40,660
Even if it's just a little bit of like just some very simple math

311
00:21:40,660 --> 00:21:47,300
Um, you are you are duplicating that interior function, you know six times the outside

312
00:21:47,860 --> 00:21:49,860
uh

313
00:22:04,100 --> 00:22:06,260
Testing you still there you go. You're back

314
00:22:06,260 --> 00:22:10,340
Yeah, my time limit, uh, my time limit went off for uh for x

315
00:22:10,900 --> 00:22:12,340
That's so funny

316
00:22:12,340 --> 00:22:16,980
I actually I do you know what just before this because last time last time I did the same thing

317
00:22:16,980 --> 00:22:22,500
I was kicked out because the time limit went off. I have a strict 15 minute time limit of x today

318
00:22:24,500 --> 00:22:30,820
But i'm always skipping, you know, but but but it's to try and control the uh, the x usage but yeah, sorry, please carry on

319
00:22:31,620 --> 00:22:32,580
um

320
00:22:32,580 --> 00:22:36,420
so that um there again so function application and loops are both like

321
00:22:37,300 --> 00:22:43,460
I mean you would you would laugh if somebody tried to introduce you to a programming language that didn't allow you to specify

322
00:22:43,860 --> 00:22:46,660
A subroutine as a function and call it multiple times

323
00:22:47,380 --> 00:22:51,860
Or or didn't allow you to like loop over the number of inputs and check them for something

324
00:22:53,220 --> 00:22:55,220
These are very very basic things

325
00:22:55,780 --> 00:22:56,660
and

326
00:22:56,660 --> 00:23:02,180
And mind you our our virtual machine is is based on the fourth programming language

327
00:23:02,180 --> 00:23:04,340
So the constructs we're talking about are are

328
00:23:05,140 --> 00:23:07,380
You know 50 years old or more

329
00:23:08,500 --> 00:23:10,500
the the op the the loops

330
00:23:12,660 --> 00:23:16,340
Proposal is proposing one of the loop constructions that is

331
00:23:17,220 --> 00:23:21,620
common to most fourth implementations op begin op until

332
00:23:23,300 --> 00:23:30,500
It's uh, I think from the 70s, um at 1970s and um, it's

333
00:23:30,500 --> 00:23:32,500
very

334
00:23:32,580 --> 00:23:37,860
Standard you can actually ask a large language model to to write an implementation of something and then be like oh

335
00:23:37,940 --> 00:23:42,420
A bitcoin cache added op begin op until fix this and it will actually give you the correct results

336
00:23:43,220 --> 00:23:46,180
Because it's look it's trained on lots of uh, lots of fourth code

337
00:23:46,660 --> 00:23:50,900
um, so so it's useful to have uh, you know to just

338
00:23:51,540 --> 00:23:56,020
Add the thing that most fourths use. Um, so that's the loops proposal

339
00:23:56,020 --> 00:24:02,340
Um, the op eval is a a very similar thing

340
00:24:03,780 --> 00:24:07,560
There are different ways you can you can add support for function definition

341
00:24:08,340 --> 00:24:14,020
If you're curious, there's some discussion in the bitcoin cache research forum about uh, kind of the different

342
00:24:14,980 --> 00:24:19,460
Approaches we could take and what their trade-offs are, uh, but in in short, um

343
00:24:20,660 --> 00:24:22,660
op eval is

344
00:24:22,660 --> 00:24:28,580
sort of the the very simplest thing we could possibly do that we can prove

345
00:24:29,380 --> 00:24:37,140
has um a set of use cases for which it will always be the most optimal, um, and so it's it's

346
00:24:38,100 --> 00:24:40,900
uh, it's very easy to and the reason I

347
00:24:41,700 --> 00:24:44,100
I'm, you know interested in it versus like trying to

348
00:24:44,500 --> 00:24:51,460
Bike shed out a specific way to define functions and let users define unspecified op codes or something like that like

349
00:24:51,460 --> 00:24:57,060
um, there there are there are large bike set bike sheds that could be painted but um

350
00:24:58,100 --> 00:25:00,100
we don't necessarily need to because

351
00:25:00,740 --> 00:25:05,780
Uh, we can prove beyond the shadow of a doubt that op eval is the most optimal way

352
00:25:06,340 --> 00:25:09,700
To to do the the the thing that it that it does

353
00:25:10,260 --> 00:25:16,340
For a very large set of use cases for the first application and for the last application of any function

354
00:25:16,820 --> 00:25:18,020
um

355
00:25:18,020 --> 00:25:20,260
so uh

356
00:25:20,260 --> 00:25:25,300
And let me go back because there's probably an unstated, uh an unstated thing there that

357
00:25:26,340 --> 00:25:32,100
When when looking at at protocol upgrades, we we always want to find ways to make the protocol just timeless

358
00:25:32,580 --> 00:25:37,780
Like the protocol should not should not be changed to make something a little bit more convenient right now

359
00:25:37,860 --> 00:25:39,700
Even if we might find a better solution later

360
00:25:39,700 --> 00:25:45,540
Like that is that is not the the level of rigor required for a protocol change

361
00:25:45,540 --> 00:25:50,020
If our grandchildren are going to have to deal with the with the mistakes we make now

362
00:25:50,420 --> 00:25:56,580
Then we want to be absolutely sure that to the very best of our ability everything we every change we possibly make

363
00:25:56,980 --> 00:25:58,500
Will be perfect

364
00:25:58,500 --> 00:26:00,500
As far as we can see into the future

365
00:26:01,220 --> 00:26:03,220
um, yeah, definitely and this is

366
00:26:03,540 --> 00:26:09,380
This is the critical thing right because you know, I i'm very well aware of your vision of bitcoin cash

367
00:26:09,380 --> 00:26:10,980
We'll go into that later

368
00:26:10,980 --> 00:26:13,460
but um, you know really looking into uh

369
00:26:13,460 --> 00:26:21,940
Uh setting this network up to be money for the world so the world reserve a currency that every single person on the planet can use daily

370
00:26:22,420 --> 00:26:26,820
Uh as cash, um, and of course something like that doesn't happen overnight

371
00:26:26,900 --> 00:26:31,300
It takes time to snowball a certain time. It can hit critical mass and explode

372
00:26:31,300 --> 00:26:31,780
That's true

373
00:26:31,780 --> 00:26:37,620
But still if you're building something that's designed for the world, this isn't something that's you know to achieve that

374
00:26:37,620 --> 00:26:40,980
You're not going to be replacing it then a few weeks later over something else

375
00:26:40,980 --> 00:26:45,300
So everything that's happening now everything that's being built. It's incredibly important

376
00:26:45,780 --> 00:26:52,580
Um, which is why you know the chip process on bitcoin cash is is you know, the the greatest consensus model

377
00:26:52,580 --> 00:26:56,740
We've got right now and it is you know, there's a lot of this work, you know

378
00:26:56,740 --> 00:27:00,980
And I know you have highly respected within the community have a lot of regard

379
00:27:01,460 --> 00:27:04,900
Um, and and nevertheless, even though you have already proved

380
00:27:04,900 --> 00:27:13,460
Proved yourself in the ecosystem when a new chip comes out, of course people get excited, especially non-technical people like myself and i'm not a developer

381
00:27:13,940 --> 00:27:22,740
Um, but nevertheless those chips are taken and they're ripped apart and they're you know, they're analyzed they're criticized and and rightfully so

382
00:27:23,460 --> 00:27:27,380
Because this is important. Um, and and we want to make sure that we get this right

383
00:27:27,380 --> 00:27:32,900
And i'm just thinking about cash tokens. Of course, it's a great great addition to the bch ecosystem

384
00:27:32,900 --> 00:27:38,260
But I remember, you know the very first time I read about this was uh pm, uh, uh prediction markets version three

385
00:27:38,820 --> 00:27:43,780
Uh, which of course then if you think about the same thing happened ripped apart

386
00:27:45,220 --> 00:27:51,860
What came out of that was uh, of course much better and so jason's like just you know, because you're talking about opiaval

387
00:27:52,100 --> 00:27:58,260
Um, and yeah be really good to focus in on this one and zonen this one just thinking about the consensus

388
00:27:58,260 --> 00:28:04,020
Um, so the feedback that i've heard expressed by some bch developers

389
00:28:04,420 --> 00:28:09,140
Um is that from their perspective the benefits are limited, but it brings a lot of risk

390
00:28:09,620 --> 00:28:14,900
Um, and you know, i'm just looking at so this the opiaval there's a great, uh,

391
00:28:15,460 --> 00:28:19,080
Uh mention of it from mike herne on bitcoin talk.org

392
00:28:20,020 --> 00:28:22,020
Uh in october the 7th 2011

393
00:28:22,020 --> 00:28:28,020
Um, and uh, you know, he also expresses risk here and i'm just going to give this quotation. I would love to hear

394
00:28:28,420 --> 00:28:32,740
You know like what your how you would count that so this is a quote from mike herne

395
00:28:33,280 --> 00:28:37,860
2011 the current bitcoin design has been carefully reviewed and found to be strong

396
00:28:38,580 --> 00:28:42,020
People like kabinsky have tried the best and not discovered any issues

397
00:28:42,580 --> 00:28:47,460
major structural design changes like opiaval invalidate all

398
00:28:47,460 --> 00:28:51,860
All those assurances and put bitcoin back at square one

399
00:28:52,500 --> 00:28:59,860
I'm not seeing seeing the benefit this this base is cheap and pruning would reclaim far more than shrinking transactions by a small amount

400
00:29:00,320 --> 00:29:04,900
Lightweight clients don't even care. So this is of course, this is a long time ago

401
00:29:05,380 --> 00:29:10,340
um, and um, and the world's moved on from there, but there's pretty like just taking that

402
00:29:10,820 --> 00:29:15,960
Statement as it is. It's a pretty like damning assessment of opiaval

403
00:29:15,960 --> 00:29:21,480
Well, what would your chat? What how would you how would you answer that if that was being said by mike today?

404
00:29:22,040 --> 00:29:26,200
Yeah, um, well in first as you're saying there, um, but

405
00:29:27,000 --> 00:29:28,360
you know, uh

406
00:29:28,360 --> 00:29:34,840
He he did not have the information we have now and he was definitely right in in 20

407
00:29:35,000 --> 00:29:39,800
I think that was 2011. Maybe it was 2012. Yeah, yeah in 2011 2011. Um,

408
00:29:40,760 --> 00:29:43,960
And uh, he was definitely right in 2011. Um,

409
00:29:43,960 --> 00:29:47,000
um, and I should even go back and say that uh,

410
00:29:47,640 --> 00:29:49,640
Satoshi made a a

411
00:29:50,360 --> 00:29:53,240
huge number of just incredibly prescient

412
00:29:54,520 --> 00:29:56,520
decisions like um

413
00:29:57,080 --> 00:29:58,360
it

414
00:29:58,360 --> 00:30:02,040
I I am I i'm continuously, uh

415
00:30:02,760 --> 00:30:07,720
Surprised at how good of a choice it was to base our virtual machine on on fourth

416
00:30:08,360 --> 00:30:09,880
um

417
00:30:09,880 --> 00:30:11,400
like

418
00:30:11,400 --> 00:30:16,120
It may be because you know fourth is not something that sort of my generation of programmers

419
00:30:16,440 --> 00:30:19,320
Grew up on a little bit and so I feel like i'm you know

420
00:30:20,040 --> 00:30:24,680
in a lot of ways discovering lost ancient knowledge, um, but uh

421
00:30:25,560 --> 00:30:30,280
He he really did pick the right tool for the job in expressing virtual machine contracts

422
00:30:30,600 --> 00:30:35,320
Uh, because we can actually get quite a bit more concise code if it's expressed in fourth

423
00:30:35,320 --> 00:30:41,400
Then if we for example implemented something, you know, if we had web assembly was was our virtual machine system

424
00:30:41,720 --> 00:30:43,080
um

425
00:30:43,080 --> 00:30:49,400
It would be significantly less concise and for no performance benefit and people do not under people have not thought through

426
00:30:49,800 --> 00:30:54,040
These problems they just assume they're like, oh web assembly's fast throw it in there. That's the right thing to use

427
00:30:54,440 --> 00:30:56,200
um, but like

428
00:30:56,200 --> 00:30:58,760
You are throwing away 50 years of computing knowledge

429
00:30:59,160 --> 00:31:01,160
um

430
00:31:01,160 --> 00:31:07,880
So there I want to be really clear that I I would not judge any of the uh, any of the opinions

431
00:31:08,440 --> 00:31:10,440
From you know from before

432
00:31:11,140 --> 00:31:13,140
2013 um

433
00:31:13,880 --> 00:31:16,200
By any of our of our standards now

434
00:31:16,440 --> 00:31:20,600
We know so much more about what could be useful in the pro and in our programming model

435
00:31:20,600 --> 00:31:23,000
Like what kinds of applications people are going to want to build?

436
00:31:23,480 --> 00:31:27,160
Um, they're not if you if you read through that that bitcoin talk forum post

437
00:31:27,160 --> 00:31:31,880
Because they're not even thinking about you know things like loan protocols and I mean

438
00:31:31,880 --> 00:31:36,680
There's some sense of like hey we could eventually tokenize all the things and then decentralized exchanges

439
00:31:36,680 --> 00:31:41,080
But that's like where it ends there. There is there's certainly no one there

440
00:31:41,560 --> 00:31:45,960
uh considering that it will be practical at some point in the future to

441
00:31:46,440 --> 00:31:49,560
Implement zero knowledge proofs using the contract system

442
00:31:49,560 --> 00:31:53,960
Like there's just a foregone conclusion that it will be an opcode and I too

443
00:31:53,960 --> 00:31:57,160
Bought that foregone conclusion until like

444
00:31:58,440 --> 00:32:01,480
Within the past two years, um for sure, uh, the

445
00:32:02,360 --> 00:32:03,480
even

446
00:32:03,480 --> 00:32:05,800
even last year I was I was

447
00:32:06,820 --> 00:32:12,060
Surprised to see to notice how uh, how practical it could be to implement

448
00:32:12,520 --> 00:32:14,520
um some you know

449
00:32:14,760 --> 00:32:16,760
Something like zcash's halo 2

450
00:32:17,000 --> 00:32:19,000
um

451
00:32:19,000 --> 00:32:23,640
Uh zero knowledge proof construction stuff in bitcoin cash as a covenant

452
00:32:24,200 --> 00:32:28,840
um like that would have been if you had told me that in 2021, I would have just laughed at you but like

453
00:32:29,240 --> 00:32:31,000
um

454
00:32:31,000 --> 00:32:37,720
For sure, it's it's uh, it's viable. Um in the contract system and it can be expressed pretty concisely. Um

455
00:32:38,600 --> 00:32:39,640
the

456
00:32:39,640 --> 00:32:40,680
the

457
00:32:40,680 --> 00:32:47,560
You you do lose like if we're talking about um about performance you you do lose some overhead on the on the

458
00:32:47,560 --> 00:32:53,560
the actual um kind of manipulating bytes in in lots of ways but um

459
00:32:55,480 --> 00:32:59,880
For for the long tail of of various use cases out there

460
00:33:01,080 --> 00:33:05,000
It would be really really really hard to beat, you know satoshi's idea

461
00:33:05,400 --> 00:33:09,240
That giving people a a virtual machine that they can that they can work with

462
00:33:09,640 --> 00:33:14,760
That is that the system is the system is protected itself from people making silly programs

463
00:33:14,760 --> 00:33:18,680
But people are able to just permissionlessly go off and build what they want to build

464
00:33:19,160 --> 00:33:24,040
Um, we can actually get shockingly good performance out of it and you can build even crypto

465
00:33:24,740 --> 00:33:25,880
applications

466
00:33:25,880 --> 00:33:29,640
uh in this virtual machine system and and they're

467
00:33:30,200 --> 00:33:35,160
pretty darn good and they they also scale really well because the you know, the

468
00:33:35,880 --> 00:33:40,280
A lot of the biggest issue with scaling is not compute. It's bandwidth. Um

469
00:33:40,280 --> 00:33:45,400
Um compute we've got uh, we've got a a ceiling we've got a a safety

470
00:33:46,440 --> 00:33:48,600
Margin of 10 to 100 x right now

471
00:33:49,480 --> 00:33:56,680
You know a a completely normal consumer device should be able to handle the worst case scenarios

472
00:33:57,080 --> 00:34:00,600
Using less than 10 percent of their of their compute power

473
00:34:02,760 --> 00:34:06,760
Validating the bitcoin cash network. So it's then that's that's very

474
00:34:06,760 --> 00:34:12,440
Very normal consumer hardware and it gets better every year. So we're in a really good spot there. Um

475
00:34:14,600 --> 00:34:21,480
Our problem is not compute speed it is simply bandwidth it is simply how many bytes it takes to express things

476
00:34:23,560 --> 00:34:30,520
So, uh, that's that's what if anything when i've and i've kind of harped on um, all right, i've given i've given

477
00:34:31,140 --> 00:34:32,520
privacy

478
00:34:32,520 --> 00:34:39,160
Privacy applications as an example for some of this stuff because it's something really tangible that people can can understand quickly

479
00:34:39,480 --> 00:34:43,640
And and I think hopefully it helps to kind of break the the misconceptions

480
00:34:44,360 --> 00:34:45,480
around

481
00:34:45,480 --> 00:34:48,920
What what is reasonable to do in the vm?

482
00:34:49,480 --> 00:34:55,320
bytecode, um, it is reasonable to do crypto in the vm bytecode and not in like the you know,

483
00:34:56,280 --> 00:34:58,280
the way that uh

484
00:34:58,280 --> 00:35:02,140
Earlier iterations of sort of the bsva ecosystem

485
00:35:02,600 --> 00:35:06,040
Would talk about like oh we can do signature checking in in the script

486
00:35:06,040 --> 00:35:09,000
You just have to add these three megabytes of code or whatever it was

487
00:35:09,560 --> 00:35:14,920
We can do it really efficiently they can be small atomic transactions that don't look much different than a multi-signature transaction

488
00:35:15,560 --> 00:35:18,760
like people people need to really understand that like the

489
00:35:19,400 --> 00:35:21,400
There are there are

490
00:35:22,200 --> 00:35:24,200
relatively straightforward

491
00:35:24,200 --> 00:35:31,960
Optimizations that can be made to get our contract system to a place where you can implement anything that is being done

492
00:35:32,360 --> 00:35:36,040
By any layer one coin out there you can do it on bitcoin cash as a covenant

493
00:35:36,520 --> 00:35:41,000
And you can do it with the same efficiency that is being done by those layer one networks

494
00:35:41,240 --> 00:35:46,840
Like if you specifically designed a transaction format to be as efficient as possible to do a zero knowledge shielded transaction

495
00:35:46,840 --> 00:35:53,960
The the total number of bytes taken up by that transaction will be very similar to to the optimized version

496
00:35:54,520 --> 00:35:56,360
Of a bitcoin cash covenant

497
00:35:56,360 --> 00:36:03,000
Yeah, and for me this that that all sounds for me. That sounds incredibly important when we're at that sort of

498
00:36:03,560 --> 00:36:05,000
um, uh

499
00:36:05,000 --> 00:36:06,360
bandwidth

500
00:36:06,360 --> 00:36:11,960
Layer, so if you know, we're really pushing forward, you know, maybe we're heading towards our first hundred million or a billion

501
00:36:11,960 --> 00:36:17,320
um, what what interests me today is like just thinking about um, like the realities of

502
00:36:17,960 --> 00:36:24,120
Of bitcoin cash today where we have um now with abla we have this adjustable block size

503
00:36:24,520 --> 00:36:27,080
Um, but we're still you know, the average block size

504
00:36:27,160 --> 00:36:29,880
I don't know what it is if it's 200k or 100k

505
00:36:29,880 --> 00:36:35,480
But it's basically so currently the the throughput is not the bottleneck today, you know, of course

506
00:36:35,560 --> 00:36:37,560
I know you're looking ahead in the future

507
00:36:37,800 --> 00:36:39,880
um, but just as a real realism today

508
00:36:39,880 --> 00:36:47,320
What what benefits so basically so at the moment, of course all that transaction size is is also um,

509
00:36:48,040 --> 00:36:52,600
Uh a subsidy paid through for the miners for actually using up that block space

510
00:36:52,920 --> 00:36:57,240
So if we made that efficiency more efficient today with such low transaction volume

511
00:36:57,720 --> 00:36:58,920
um

512
00:36:58,920 --> 00:37:03,960
Could it not also so so what I also see is the impact of that is that the block size is is smaller now

513
00:37:03,960 --> 00:37:07,640
Of course, it's more efficient. That's all great when you've got the transactions, but in today's reality

514
00:37:07,640 --> 00:37:13,800
Um, I can see that there's sort of some of the negative sides to that but the the benefits then come

515
00:37:14,680 --> 00:37:18,520
Later on it so my question would be why why implement this now?

516
00:37:19,240 --> 00:37:21,240
As opposed to you know

517
00:37:21,640 --> 00:37:27,880
Later on when it's actually looking like okay, this is on the horizon now that this efficiency and bandwidth is required. Yeah, um,

518
00:37:28,440 --> 00:37:31,480
Yes, like if I if I understand the question correctly

519
00:37:31,480 --> 00:37:37,480
Why why make transactions more efficient when our blocks aren't full and we want to get more data in the blocks to pay?

520
00:37:37,480 --> 00:37:42,600
To today today is the question. Yes. Yeah, so of course I see the bad benefits of that. Yeah

521
00:37:43,240 --> 00:37:45,240
And and that is just not today. Yeah

522
00:37:45,320 --> 00:37:50,360
Um, and that is the argument that is driving btc today

523
00:37:50,440 --> 00:37:56,040
The argument that drives btc today is that we want to um, you know maximize the transaction fees

524
00:37:56,520 --> 00:38:00,520
uh in the immediate term with with uh

525
00:38:00,520 --> 00:38:08,200
uh ignoring the availability of alternatives and and substitute products and um

526
00:38:08,840 --> 00:38:13,400
and so as many people in bitcoin cash have discovered obviously that um

527
00:38:14,280 --> 00:38:19,320
There are use cases that are that are prevented if you require

528
00:38:20,040 --> 00:38:24,920
Large transaction fees for the use case like you're going to choose to use a different system

529
00:38:25,480 --> 00:38:28,280
other than bitcoin cash if you're if you're

530
00:38:28,280 --> 00:38:35,240
Uh per transaction cost is non-negligible basically if your per transaction cost is like more than a dollar

531
00:38:35,560 --> 00:38:40,120
You're thinking about ways you can switch to another system that doesn't cost you so much

532
00:38:41,000 --> 00:38:46,040
Um, and and this was this was just like the the critical and obvious flaw in the whole

533
00:38:46,200 --> 00:38:50,280
we're going to make every transaction cost a thousand dollars and and uh, and a

534
00:38:50,840 --> 00:38:56,280
A transaction on bitcoin is going to be as rare and special as chartering an oil tanker like this

535
00:38:56,280 --> 00:38:59,320
Absolutely delusional takes um

536
00:39:03,000 --> 00:39:08,120
No, what's gonna happen is they're gonna switch to a spreadsheet all the people that have to pay those fees are gonna switch to a spreadsheet

537
00:39:10,360 --> 00:39:14,920
Yeah, this is what we were joking about this is maybe not even a spreadsheet. It's just a piece of paper on michael saylors

538
00:39:17,560 --> 00:39:23,400
And the same is exactly true of of any use case that can technically be done

539
00:39:23,400 --> 00:39:25,960
on bitcoin cash covenants, but are

540
00:39:26,600 --> 00:39:29,400
Uh absurd to do bitcoin cash covenants, right?

541
00:39:29,560 --> 00:39:35,720
If it if it requires 20 megabytes of transactions to to run one zero knowledge proof

542
00:39:36,120 --> 00:39:39,240
You're not actually going to do that like you might do it for demo purposes

543
00:39:39,240 --> 00:39:43,320
Like I might do it just to just to prove to everybody i'm smart enough to write a zero conf

544
00:39:44,120 --> 00:39:48,920
Zero proof in this system, but I can make it work. Look I code golfed it guys

545
00:39:48,920 --> 00:39:53,560
Um, but like no, it doesn't actually matter. It doesn't move the needle for anybody on the network

546
00:39:53,960 --> 00:39:58,280
Um, if if the per transaction cost is absurd

547
00:39:59,000 --> 00:40:02,280
I've done nothing but but prove to you that I that I can do it

548
00:40:03,480 --> 00:40:05,640
It doesn't it doesn't translate into real use

549
00:40:06,920 --> 00:40:11,160
Real users aren't going to spend, you know 20 or 50 dollars or whatever it is per transaction

550
00:40:13,160 --> 00:40:15,160
Instead we want to find ways

551
00:40:15,160 --> 00:40:20,680
To make more and more use cases really reasonable on bitcoin cash

552
00:40:21,320 --> 00:40:24,120
So that people actually want to do them makes a lot of sense to me

553
00:40:24,680 --> 00:40:28,120
So yeah, but so but so is that what you're saying?

554
00:40:28,120 --> 00:40:35,640
So that's without opi value that the things that would make possible there really is taking like several orders of magnitude of data

555
00:40:36,440 --> 00:40:40,680
Down is that the case? Yes, uh insane. Yeah, both opi value because um, you

556
00:40:40,680 --> 00:40:45,720
Uh, you have to understand there are two things that are kind of are are huge limiters right now

557
00:40:45,800 --> 00:40:47,880
One is function application and the other is loops

558
00:40:48,200 --> 00:40:54,280
um, and you know, technically we could say that it's actually just function application because you can always do recursive functions, right so

559
00:40:54,920 --> 00:41:01,160
And and we we can recurse down to a hundred, uh a depth of 100 in our current vm limit system. No problem

560
00:41:01,160 --> 00:41:04,040
It's no, uh, no issue at all already handled by the vm limits

561
00:41:04,040 --> 00:41:10,040
Um, but loops are also like 25 more efficient for a vast majority of cases

562
00:41:11,080 --> 00:41:15,560
So it would be kind of silly to have obi val without out without also adding loops

563
00:41:16,040 --> 00:41:17,560
um

564
00:41:17,560 --> 00:41:24,040
The inverse is also technically true. It's technically possible to refactor a program

565
00:41:24,520 --> 00:41:29,240
um to to specify the program as a a giant

566
00:41:29,800 --> 00:41:31,800
Set or series of loops

567
00:41:31,800 --> 00:41:33,640
um

568
00:41:33,640 --> 00:41:35,640
where you

569
00:41:35,700 --> 00:41:42,280
Effectively activate and deactivate different sections of the code at just the right moment to get it to do the things you wanted to do

570
00:41:42,360 --> 00:41:47,400
As if you had function application like I think it is technically possible to say that they're equivalent

571
00:41:47,640 --> 00:41:51,560
But like that's ridiculous. You should just have function application, too

572
00:41:51,960 --> 00:41:54,680
um there we wouldn't even be talking about uh

573
00:41:55,400 --> 00:41:59,160
about what you can get away with in a programming language if

574
00:41:59,880 --> 00:42:02,520
We weren't starting with a severely

575
00:42:02,520 --> 00:42:04,520
uh reduced

576
00:42:04,520 --> 00:42:06,520
Programming language

577
00:42:06,520 --> 00:42:11,560
Um, so yes, it is useful to have both function application and loops

578
00:42:12,600 --> 00:42:15,160
For different for different reasons in different cases

579
00:42:15,560 --> 00:42:20,440
Um in each case one is is going to be much more optimal than the other

580
00:42:20,760 --> 00:42:27,480
Um, anything you can express as a loop is something around 20 to 30 percent more efficient to do with the loop

581
00:42:27,960 --> 00:42:29,160
um

582
00:42:29,160 --> 00:42:30,680
and then

583
00:42:30,680 --> 00:42:35,640
It would be hard to even do the it would be hard to even give you a a percentage for

584
00:42:36,280 --> 00:42:42,840
The the reverse where if you tried to specify the program as a giant loop and then activate and deactivate conditionals in the right

585
00:42:43,720 --> 00:42:49,720
You you have to know exactly how many code branches your problem has and how many times you're going to hit that part of the loop

586
00:42:49,800 --> 00:42:55,320
And where you're going to put stuff and by the way, you also need a compiler that's smart enough to produce these programs

587
00:42:55,560 --> 00:42:57,640
And I don't know who you plan on making that. Um

588
00:42:57,640 --> 00:43:05,160
Um, but uh, it's it's hard to do just just by hand. Um, it it and and i'm not even i'm not even

589
00:43:05,720 --> 00:43:09,740
Completely certain that it's possible to say it's always possible

590
00:43:10,600 --> 00:43:13,960
It's totally conjecture, but I think it's also it's always possible

591
00:43:14,440 --> 00:43:19,320
Um to to specify it that way. It's just ridiculous. It would be very silly to do it that way. Um

592
00:43:19,960 --> 00:43:21,960
Yeah, so when when looking at like so

593
00:43:21,960 --> 00:43:27,560
Uh out of the the free chips that you propose I believe in the yeah, no all in december. Sorry

594
00:43:27,880 --> 00:43:32,920
Um loops is the one that that seems you know from what i've seen in in the developer chats

595
00:43:33,160 --> 00:43:40,120
this one seems to have absolutely the the majority of the support that this is like a really something that can be really um

596
00:43:41,140 --> 00:43:46,440
Beneficial to bch the uh, uh, the risk reward is very nicely balanced

597
00:43:46,440 --> 00:43:51,960
One thing that interests me, um, and I didn't see an answer to this is the chip and unless i've written it down wrong

598
00:43:51,960 --> 00:43:54,440
But the chip is two thousand twenty one zero five

599
00:43:55,000 --> 00:43:58,760
Um, so it's it's dated three years before the other two

600
00:43:59,320 --> 00:44:04,840
So yeah, is there a reason like why why was this left untouched for so long? Why has it just been picked up?

601
00:44:05,000 --> 00:44:11,480
um and now and and and and uh proposed for the upgrade yeah, um, it was waiting on limits, uh,

602
00:44:11,480 --> 00:44:17,640
All of these all of this stuff was waiting on a reasonable solution to limits our limits were this, you know

603
00:44:17,800 --> 00:44:23,640
implicitly defined by magic constants and encoding sizes and now they're explicit and so um

604
00:44:24,600 --> 00:44:30,200
That there it's possible for us to um, actually go all the way back to um to my current comment there

605
00:44:30,920 --> 00:44:36,680
He said it very well in 2011 like we we are certain that the system is safe as it exists today

606
00:44:36,840 --> 00:44:39,640
If you change anything about the behavior of the system

607
00:44:39,640 --> 00:44:43,720
Um, you have essentially thrown away all of those guarantees

608
00:44:44,200 --> 00:44:45,160
um

609
00:44:45,160 --> 00:44:47,720
and the most applicable upgrade

610
00:44:48,360 --> 00:44:51,560
to to to point at that to compare to that

611
00:44:52,120 --> 00:44:53,080
um

612
00:44:53,080 --> 00:44:56,600
To that statement is the vm limits upgrade the vm limits upgrade

613
00:44:57,240 --> 00:45:00,920
uh by necessity it's not it's not possible to fix them without

614
00:45:02,020 --> 00:45:07,640
Necessarily exposing yourself to throwing away all of the security guarantees of what we had before

615
00:45:07,640 --> 00:45:14,440
Yeah, so to be very clear, um the the the mountain to get over was vm limits

616
00:45:15,640 --> 00:45:22,600
Um, and it took three years, uh, and and and that's just three years that the chip after the chip was proposed

617
00:45:23,000 --> 00:45:31,000
Um, and in practice it took me all of last year literally all of last year and several other people reviewing very carefully many times

618
00:45:31,000 --> 00:45:36,760
Um, uh, and that's just the the chip

619
00:45:38,040 --> 00:45:44,300
Before then we have another decade of people looking at this problem, right from 2011 to 2021

620
00:45:44,840 --> 00:45:47,160
There's a big gap. There's a whole decade gap between

621
00:45:47,720 --> 00:45:51,960
Um, when you know when mike hern says that you know any change to this

622
00:45:53,140 --> 00:45:58,520
Necessarily throws away our security guarantees. Um, that's where it necessarily throws away our safety guarantees rather

623
00:45:58,520 --> 00:46:00,360
Um

624
00:46:00,360 --> 00:46:01,800
uh

625
00:46:01,800 --> 00:46:03,800
So you have to you know, there's

626
00:46:04,120 --> 00:46:11,400
We had a decade a decade of thinking about it if you will before that chip was proposed and then the chip also in 2021

627
00:46:11,880 --> 00:46:13,240
um

628
00:46:13,240 --> 00:46:15,400
uh

629
00:46:15,400 --> 00:46:17,080
Was you know

630
00:46:17,080 --> 00:46:21,000
Maybe 50 of the way there but all of the work was in the last 20 percent

631
00:46:22,040 --> 00:46:26,440
Um, and and that was a lot of last year's work. So um, yeah the

632
00:46:27,320 --> 00:46:28,440
the

633
00:46:28,440 --> 00:46:30,760
the the huge risky thing

634
00:46:32,040 --> 00:46:34,040
Always is going to be

635
00:46:34,580 --> 00:46:37,160
Modifying how the virtual machine applies limits

636
00:46:37,720 --> 00:46:39,720
um that that is the

637
00:46:40,680 --> 00:46:42,200
uh

638
00:46:42,200 --> 00:46:45,400
That is the underlying concern in my current comment there

639
00:46:45,720 --> 00:46:50,200
It was the underlying concern in why we you know, anytime anyways, like why can't we just have loops like

640
00:46:51,080 --> 00:46:55,640
It would it doesn't change anything if I do if I do a loop versus copying pasting the code 10 times

641
00:46:55,640 --> 00:46:59,000
Like can't we just do loops that let you loop 10 times and that'd be fine

642
00:46:59,320 --> 00:47:03,560
and but the answer was was always well, yes, but um

643
00:47:04,520 --> 00:47:12,280
actually our limits are all implicitly defined and based on based on magic constants and and uh transaction encoding, so

644
00:47:12,840 --> 00:47:17,560
um, even if you did it that way you get these unpredictable spikes in the worst case in

645
00:47:18,200 --> 00:47:19,000
in

646
00:47:19,000 --> 00:47:22,200
Places that are that are hard to even reason about

647
00:47:22,200 --> 00:47:27,960
Um, and so in practice the answer is just like no we probably can't do that. Not unless we do something more reasonable for our limits

648
00:47:28,520 --> 00:47:30,120
um

649
00:47:30,120 --> 00:47:33,080
and so a lot of contract designers have

650
00:47:33,720 --> 00:47:36,920
Obviously, it's like the first thing you're going to encounter if you're doing anything non-trivial

651
00:47:36,920 --> 00:47:40,520
Is that you can't like do the same thing three times?

652
00:47:40,520 --> 00:47:45,080
Like you can't check the number of inputs and do the same thing across those three inputs

653
00:47:45,720 --> 00:47:47,080
um

654
00:47:47,080 --> 00:47:48,280
like

655
00:47:48,280 --> 00:47:50,520
Uh, so a lot of contract authors

656
00:47:50,520 --> 00:47:52,520
um

657
00:47:52,600 --> 00:47:59,640
Have you know direct real world experience where they have already had issues with um with loop

658
00:48:00,360 --> 00:48:02,360
Uh with not having loops

659
00:48:02,840 --> 00:48:07,000
um, i'd say this the op eval, um

660
00:48:08,360 --> 00:48:14,760
I think a lot of contract authors are a little bit insulated from the issue because they're using they're using cash script

661
00:48:14,760 --> 00:48:20,200
And and cash script lets them not really think too much about what's coming out the other end

662
00:48:21,400 --> 00:48:23,400
Of the system so, you know

663
00:48:24,440 --> 00:48:27,160
It's easy for them to not really notice that

664
00:48:28,280 --> 00:48:30,920
Hey, my my my compiled transaction

665
00:48:31,720 --> 00:48:33,080
Has 80 percent?

666
00:48:33,080 --> 00:48:36,600
Uh, 80 percent of the code in my compiled transaction is just copy pasted stuff

667
00:48:37,240 --> 00:48:39,240
um

668
00:48:39,640 --> 00:48:43,480
And and not just for loops it's for if you do need to do a

669
00:48:43,480 --> 00:48:48,840
A certain kind of transformation in two different spots or two different part code paths

670
00:48:49,160 --> 00:48:54,840
Um that that don't necessarily take place one after the other that you can't you can't rearrange how you use the stack

671
00:48:55,240 --> 00:48:57,240
To to turn them into a loop

672
00:48:57,240 --> 00:48:58,200
um

673
00:48:58,200 --> 00:49:01,000
It's just you know, fun programs use functions

674
00:49:02,120 --> 00:49:03,880
so, um

675
00:49:03,880 --> 00:49:06,840
Yeah, uh, I would say that's that's why you see

676
00:49:08,600 --> 00:49:12,520
Almost anyone who's worked at all with a version with with contracts is

677
00:49:12,520 --> 00:49:15,160
Is is going to notice the first thing they have to learn about

678
00:49:16,120 --> 00:49:18,280
about bitcoin caches virtual machine

679
00:49:18,920 --> 00:49:24,200
Uh system is that it doesn't have loops because they need them and they don't get them so they have to work around that

680
00:49:24,280 --> 00:49:26,520
Yeah, sure or in some cases they just don't

681
00:49:27,720 --> 00:49:33,320
Yeah, and and you say who who would no one would program in that if it wasn't this amazing thing of money

682
00:49:33,640 --> 00:49:38,600
Uh, so it's you know, this isn't it wasn't created because it was a great design choice from a from a coding perspective

683
00:49:38,840 --> 00:49:41,480
And I appreciate that and it's it's also interesting. So I was aware

684
00:49:41,480 --> 00:49:43,480
um that

685
00:49:43,480 --> 00:49:45,240
um that the uh

686
00:49:45,240 --> 00:49:50,520
The upgrade this year that allowed then further chips to come on but it's it's yeah that now makes sense that that's why

687
00:49:51,080 --> 00:49:55,880
Loops was parked um up until now. It's actually a great, uh, great time

688
00:49:55,960 --> 00:49:57,000
I don't know if you're aware of this

689
00:49:57,000 --> 00:50:03,480
So we're actually using cash tokens on phoenix and friends of technology, uh that you made possible with your chip

690
00:50:03,880 --> 00:50:07,960
um, and uh for um, there's a token called the

691
00:50:07,960 --> 00:50:13,560
Um emerald token, which you can actually use for um having a fiendish shout out

692
00:50:14,360 --> 00:50:17,400
And I think this fiendish shout out is that is well timed

693
00:50:17,880 --> 00:50:21,800
Uh, just thinking about that particular upgrade which is coming this may

694
00:50:23,160 --> 00:50:25,240
Oh, i've lost it now. There you are

695
00:50:26,360 --> 00:50:33,160
builder entrepreneur or freedom cash fan tickets for bch bliss are on sale now check out

696
00:50:33,160 --> 00:50:39,980
www.bliss.cash forward slash 2025 you can get the tickets on tap swap

697
00:50:40,620 --> 00:50:41,820
dot cash

698
00:50:41,820 --> 00:50:46,460
um, yeah, so this is for everyone that's listening bch bliss conference in may we're going to be uh,

699
00:50:47,180 --> 00:50:50,780
so you've got a lot of builders coming there and this is planned actually around the

700
00:50:51,260 --> 00:50:55,660
Uh virtual machine limit upgrades and big int so the chips are going on to main net

701
00:50:56,220 --> 00:51:01,420
um, and and allows then the the chips that jason is talking about

702
00:51:01,420 --> 00:51:08,780
Uh to be possible, you know to even to even be able to be uh implemented onto bitcoin cash if it passes through the consensus model

703
00:51:09,260 --> 00:51:13,740
Uh, and there's a general consensus that these chips uh add enough value

704
00:51:14,380 --> 00:51:16,380
um to the ecosystem

705
00:51:16,780 --> 00:51:22,700
Uh to warrant actually putting it in so jason just sorry just to sort of branch off a little bit just quickly on that note

706
00:51:23,340 --> 00:51:26,380
um, you know, these are your chips that are being

707
00:51:26,380 --> 00:51:33,360
Upgraded the the conference is a celebration of that and while also showcasing the the building that's going on in the ecosystem

708
00:51:33,520 --> 00:51:37,920
Peter ricin is also there joining to talk about his hardware and scaling of utxo

709
00:51:38,560 --> 00:51:42,080
Uh, is there any chance we'll be seeing yourself at bliss this may?

710
00:51:43,120 --> 00:51:45,120
No, I hope I can make it I I might

711
00:51:45,680 --> 00:51:50,480
Uh might not be able to but I hope I can I can make it somehow. Uh, maybe digital

712
00:51:51,440 --> 00:51:53,680
Okay, digital would would be okay

713
00:51:53,680 --> 00:52:00,480
We can accept this if you do if you do turn up, I I promise you at least one beer is on me

714
00:52:00,480 --> 00:52:02,480
So that's a pretty big offer

715
00:52:06,080 --> 00:52:12,160
Uh, it'd be great because yeah, we I don't think we've no we definitely haven't met uh met in person, uh, but it'd be lovely

716
00:52:12,160 --> 00:52:16,000
You know, uh, if you could join so I was there, uh, uh last year

717
00:52:16,400 --> 00:52:20,080
And I think like all the other builders that were there. It was a a tremendous experience

718
00:52:20,080 --> 00:52:25,840
So if something happened and you can make it to come then you'll be of course as you already know very very warmly welcome

719
00:52:27,200 --> 00:52:34,000
Well, thank you very much. Yeah, i'm i'm glad glad to see uh, it glad to see it happening. It's it's exciting to uh,

720
00:52:34,480 --> 00:52:38,320
To see the uh conferences beginning again sort of yes

721
00:52:39,600 --> 00:52:42,960
Yeah, definitely. It's important. You know, we can uh, uh

722
00:52:42,960 --> 00:52:49,280
Uh sit at home and we can code and and you know try and make the world world better from from our

723
00:52:49,680 --> 00:52:51,680
bedrooms or from our computer but

724
00:52:51,760 --> 00:52:55,840
We have you know, the really important thing of bitcoin cash is also getting out there meeting each other

725
00:52:56,960 --> 00:53:02,080
And and forming enterprises is what I always find interesting is you've done a lot of work

726
00:53:02,640 --> 00:53:04,640
um for helping the

727
00:53:05,520 --> 00:53:09,600
The chain and developing the chain and making it so that more things are possible

728
00:53:10,320 --> 00:53:12,160
on the chain

729
00:53:12,160 --> 00:53:13,520
and uh

730
00:53:13,520 --> 00:53:19,060
I think with these sort of conferences is a chance for actually people to come together the developers but also then the entrepreneurs

731
00:53:19,840 --> 00:53:21,840
In okay, how do we leverage this?

732
00:53:22,000 --> 00:53:28,720
To you know to make our business to make something profitable to make something that we can then grow the network even more

733
00:53:28,800 --> 00:53:34,800
And this is the thing that uh that excites me. Um, so uh, yeah, but I I guess this is the

734
00:53:34,800 --> 00:53:41,460
The uh working together with entrepreneurs to build products and apps. I guess this isn't your thing jason

735
00:53:44,400 --> 00:53:46,480
Uh, i've yeah, i've been focused on uh

736
00:53:47,040 --> 00:53:55,200
on protocol improvements that I I consider pretty foundational but um, i'm actually very excited i'm i'm certainly a little burned out on uh,

737
00:53:55,280 --> 00:54:00,720
on protocol things and i i'm excited to be spending more of my year on uh, on

738
00:54:00,720 --> 00:54:05,440
on software that I can ship myself and and don't have to uh,

739
00:54:07,360 --> 00:54:09,360
Don't have to advocate for so much

740
00:54:10,240 --> 00:54:15,520
Yeah, so yeah, i can imagine bit off id live off chain graph are all getting a lot more attention from me

741
00:54:15,680 --> 00:54:23,680
Uh already this month and the rest of this year for sure. Okay, um, and I should say let me if I can also mention also that like

742
00:54:24,160 --> 00:54:25,840
um

743
00:54:25,840 --> 00:54:30,880
In some ways, that's why the txv5 chip, uh looks the way it does. Um,

744
00:54:31,840 --> 00:54:34,640
The txv5 chip includes a lot of things. Um

745
00:54:35,360 --> 00:54:41,600
That are in some cases, you know, have been my notes for like the better part of a decade. Um, and

746
00:54:42,400 --> 00:54:45,920
Uh, I wanted to make sure that I got them specified somewhere. Um,

747
00:54:46,320 --> 00:54:50,240
where we can kind of serve a little bit as a as a checkpoint for um,

748
00:54:51,440 --> 00:54:52,560
uh

749
00:54:52,560 --> 00:54:56,080
If if we could if we could um

750
00:54:57,280 --> 00:55:01,040
Deploy a new transaction format. This is what I think it would look like

751
00:55:02,240 --> 00:55:04,240
this year, um and

752
00:55:05,040 --> 00:55:09,920
So i've posted in a few spots. Um, I answered some questions on on

753
00:55:10,720 --> 00:55:13,520
twitter yesterday, but uh, I I don't

754
00:55:14,080 --> 00:55:16,080
See the txv5 chip

755
00:55:18,000 --> 00:55:20,000
Being a good idea to deploy

756
00:55:20,000 --> 00:55:25,840
In 2027 unless bitcoin cash has has made it back into at least the top 10 cryptocurrencies. Um,

757
00:55:26,560 --> 00:55:27,840
because uh

758
00:55:27,840 --> 00:55:33,280
And the way I put it yesterday and I put it before is that um, you know transaction format version

759
00:55:33,760 --> 00:55:42,400
Is very very hard to do because it's a natural bottleneck for for um a lot more ecosystem players like these 2026 chips

760
00:55:43,040 --> 00:55:46,320
Essentially just uh, they require only node upgrade

761
00:55:46,320 --> 00:55:50,320
Only node upgrades. So, uh, they're the kind of the least

762
00:55:51,120 --> 00:55:56,080
Uh the the the lowest cost and and lowest risk kind of upgrade

763
00:55:56,800 --> 00:56:04,560
Um, and they then they have uh, and so their risk return ratio is a lot higher whereas a transaction format upgrade is really

764
00:56:05,840 --> 00:56:09,680
Really disruptive. Um, I have done a lot of review before

765
00:56:09,680 --> 00:56:16,080
On specifically what software would be would be broken by the pv3 upgrade actually in 2021

766
00:56:16,640 --> 00:56:18,160
and I was

767
00:56:18,160 --> 00:56:24,160
A little surprised actually at how few wallets actually consume the transaction format

768
00:56:24,720 --> 00:56:28,000
There are very few wallets out there that are that are decoding transactions

769
00:56:29,600 --> 00:56:36,960
Most of them are asking their asking their back-end servers for utxos directly and they're coming back in json format

770
00:56:36,960 --> 00:56:43,840
Or something like that. And so in practice what we might assume would be breaking with the transaction format is not quite as breaking as

771
00:56:44,560 --> 00:56:46,320
as uh

772
00:56:46,320 --> 00:56:52,240
As we might otherwise assume but in general transaction format upgrades are really really really disruptive

773
00:56:52,800 --> 00:56:59,440
And they're a natural place where any any company that's got like just uh, kind of has a bitcoin cash integration

774
00:57:00,080 --> 00:57:04,240
In their in their you know block explorer software

775
00:57:04,240 --> 00:57:10,160
or something like that and they they it's so it works with bitcoin cash right now, but if the transaction format was changed like they

776
00:57:10,160 --> 00:57:12,160
would just just as

777
00:57:12,560 --> 00:57:17,360
Likely remove bitcoin cash support rather than doing the even if it's just a little bit of work

778
00:57:18,160 --> 00:57:20,160
rather than doing the work to um

779
00:57:20,720 --> 00:57:28,320
You know fix the the new part of whatever transaction format is changed. So, um, that is that is just a problem of being

780
00:57:28,880 --> 00:57:31,360
Being relatively small. Um, maybe

781
00:57:31,360 --> 00:57:37,680
Being being relatively small. Um, no one is dropping ethereum over ethereum upgrades

782
00:57:37,760 --> 00:57:42,320
You know, they might be dropping ethereum, but it's not it's certainly not because of a transaction

783
00:57:43,440 --> 00:57:50,080
some some uh minor improvement that or minor change in how a transaction is encoded, um,

784
00:57:50,640 --> 00:57:52,640
You know dropping ethereum requires

785
00:57:53,040 --> 00:57:56,880
If they're they're making a different strategy for how their business operates, right?

786
00:57:56,880 --> 00:58:01,760
Um, and and my hope is that at some point, um bitcoin cash will be there

787
00:58:02,160 --> 00:58:07,280
That bitcoin cash will be in a position to deploy a transaction format upgrade

788
00:58:07,680 --> 00:58:13,760
Um, and if that were the case, I hope that this chip will have uh will have uh aged like wine

789
00:58:15,440 --> 00:58:17,440
To that point

790
00:58:18,400 --> 00:58:23,440
It's basically it sounds like this is a little bit of a present uh for the community while you sort of take a break and

791
00:58:23,440 --> 00:58:26,560
and hoping you know, just just during this uh,

792
00:58:27,440 --> 00:58:32,000
This episode bitcoin cash is written actually like seven seven to ten bucks

793
00:58:32,480 --> 00:58:36,640
Uh, so maybe we'll be back in the top ten by the end by the time we finish right for carrying like that

794
00:58:36,960 --> 00:58:42,240
um, but yeah, but it but you you've got something in your mind that this is really only when um,

795
00:58:42,640 --> 00:58:45,600
The the ecosystem is willing to swallow

796
00:58:46,160 --> 00:58:51,360
The the effort and pain of making a transaction a change to the transactions which makes sense

797
00:58:51,360 --> 00:58:53,840
What what interests me was um, like the

798
00:58:54,480 --> 00:58:58,880
Some of the other chips they seemed much more specific and and smaller

799
00:58:59,280 --> 00:59:03,360
Um, maybe not in the scope of what I actually enabled but but actually you know in the format

800
00:59:03,600 --> 00:59:09,700
Whereas this chip you've got multiple different aspects. You've got the zero overhead commonance detached signatures fractional satashis

801
00:59:10,160 --> 00:59:16,800
Um, and there was you know, I heard some groans from from developers at jesus, you know, this is an omnibus

802
00:59:17,600 --> 00:59:20,240
the bible of chips and and um,

803
00:59:20,240 --> 00:59:21,440
um, uh

804
00:59:21,440 --> 00:59:24,340
And just raising an eyebrow at that. So, you know from your perspective

805
00:59:24,960 --> 00:59:27,520
Like why why have all these bundled together?

806
00:59:27,600 --> 00:59:32,400
Is it that they're linked is it is it just for you for the amount of effort or is there a reason why they couldn't?

807
00:59:32,480 --> 00:59:34,480
Have just just been

808
00:59:34,480 --> 00:59:36,480
broken up into separate chips

809
00:59:36,800 --> 00:59:38,240
um

810
00:59:38,240 --> 00:59:41,520
Uh, yeah, and uh, so some of that is definitely justified there are

811
00:59:42,320 --> 00:59:45,360
This could be three chips. Um, there are two two

812
00:59:46,080 --> 00:59:48,080
other components that are

813
00:59:48,080 --> 00:59:51,280
Uh, very reasonably broken into a separate chip

814
00:59:51,680 --> 00:59:53,120
um, i'm

815
00:59:53,120 --> 01:00:00,960
Not interested in proposing them right now. Um, the 2026 chips are definitely the 80% of the value for 20% of the work

816
01:00:02,000 --> 01:00:04,980
So the the chips that I proposed for 2026

817
01:00:05,680 --> 01:00:09,520
uh, the the ones that I proposed in december are the ones that I think um

818
01:00:10,560 --> 01:00:16,720
Get us a huge amount of value for uh for very safe very contained and

819
01:00:16,720 --> 01:00:20,100
Demonstrably will stand the test of time

820
01:00:20,820 --> 01:00:22,020
uh

821
01:00:22,020 --> 01:00:23,540
changes

822
01:00:23,540 --> 01:00:24,980
the

823
01:00:24,980 --> 01:00:26,340
2027

824
01:00:26,340 --> 01:00:32,500
The stuff in the in that 2027 proposal the the transaction format proposal are things that um

825
01:00:33,780 --> 01:00:35,780
uh

826
01:00:36,180 --> 01:00:37,380
the uh

827
01:00:37,380 --> 01:00:39,780
most of the transaction format changes

828
01:00:40,580 --> 01:00:42,260
really truly just

829
01:00:42,260 --> 01:00:47,540
improve the compression of transactions a little bit like there there are 20 improvement versus

830
01:00:48,400 --> 01:00:50,400
op-eval and loops are a

831
01:00:50,900 --> 01:00:53,620
1000 or 10 000 x improvement

832
01:00:54,420 --> 01:00:56,180
and so

833
01:00:56,180 --> 01:00:58,740
It's not even reasonable to compare them and how and how

834
01:00:59,360 --> 01:01:06,420
Irrelevant the the differences are in in some of the transaction encoding stuff versus op-eval or or loops

835
01:01:06,500 --> 01:01:08,500
um, sure and so I

836
01:01:08,500 --> 01:01:14,100
Hear that and this is also kind of interesting for like for me. I'm more of a like from the pragmatic side

837
01:01:14,500 --> 01:01:15,300
um

838
01:01:15,300 --> 01:01:17,300
Is so what what I hear is um

839
01:01:18,100 --> 01:01:20,980
To implement this it requires really like some swallowing

840
01:01:21,460 --> 01:01:26,340
Of from from all the other stakeholders because they have to you know, it breaks basically everything

841
01:01:26,420 --> 01:01:32,420
Yeah for for very for very little I have to say if I wanted to go out and selling this I wouldn't take you

842
01:01:34,340 --> 01:01:38,100
Yeah, it's um, it's something that we should we should have

843
01:01:38,100 --> 01:01:41,060
It's important, but it but it's definitely not urgent

844
01:01:42,260 --> 01:01:46,900
there are a couple with a couple exceptions inside there that there's a

845
01:01:47,620 --> 01:01:51,380
Read-only inputs are are a backwards could be implemented as a very

846
01:01:52,000 --> 01:01:59,140
Isolated tight backwards compatible thing. They're definitely not as as important as the stuff I propose for 2026

847
01:01:59,300 --> 01:02:04,740
That's why it's in the 2027 stuff and it's the 2027 stuff is sort of like and this is stuff

848
01:02:04,740 --> 01:02:11,300
uh, that's on the horizon that I i'd like to start the conversation for um, but but um, and

849
01:02:13,300 --> 01:02:19,380
I definitely don't consider to be uh important enough to draw attention away from the stuff that I propose for 2026 like

850
01:02:19,780 --> 01:02:23,460
Uh, if there's if there's anything that's worth spending spending your your

851
01:02:24,180 --> 01:02:31,220
Your brain power working on it's the it's the thousand x and 10 000 x improvements you get out of the 2026 stuff

852
01:02:31,700 --> 01:02:32,580
um

853
01:02:32,580 --> 01:02:38,260
The read-only read-only inputs are so I I would say you could break the 2027 stuff

854
01:02:38,420 --> 01:02:40,980
um, you could break it into three chips that the

855
01:02:41,700 --> 01:02:46,740
The read-only inputs can be a very isolated thing and they're a big chunk of the value in that

856
01:02:47,300 --> 01:02:50,020
uh in in that chip also like they're

857
01:02:50,500 --> 01:02:51,620
um

858
01:02:51,620 --> 01:02:54,660
They would allow us to get to the zero overhead covenants. Um

859
01:02:55,620 --> 01:02:57,460
I

860
01:02:57,460 --> 01:03:04,500
I I wouldn't necessarily even be against trying to make that happen in 2026, but I I consider it to be a lot less

861
01:03:05,140 --> 01:03:06,740
certain than

862
01:03:06,740 --> 01:03:09,700
loops and eval and p2s simply because

863
01:03:10,260 --> 01:03:16,340
Like loops and eval p2s. There really is just not a lot of space for bike shedding like there's there's um, there's a

864
01:03:16,980 --> 01:03:22,020
Correct way to implement loops in the fourth programming language and it's been around for 50 years

865
01:03:22,020 --> 01:03:28,260
Like you can ask ask a large language model to like as I mentioned earlier to to implement your program using

866
01:03:28,420 --> 01:03:31,700
Op begin op until and it will do it right like um

867
01:03:32,420 --> 01:03:34,580
It would it would be really hard to justify

868
01:03:35,220 --> 01:03:38,580
Uh inventing our own thing for for loops

869
01:03:39,060 --> 01:03:41,060
um and in the same way op eval

870
01:03:42,180 --> 01:03:46,980
Does the simplest thing as we said before it says the simplest thing possible that we can prove

871
01:03:47,620 --> 01:03:49,300
will never

872
01:03:49,300 --> 01:03:50,900
be

873
01:03:50,900 --> 01:03:52,340
uh

874
01:03:52,340 --> 01:03:54,340
Will never become outdated

875
01:03:55,460 --> 01:03:57,460
by a new uh

876
01:03:57,540 --> 01:04:01,860
a new clever way of of approaching the op eval problem like

877
01:04:02,500 --> 01:04:06,660
It will always be and we can prove it will always be the most efficient way to

878
01:04:08,020 --> 01:04:10,100
Take one item from the stack and evaluate it to you

879
01:04:10,100 --> 01:04:15,540
It's always the most efficient way to do a single function call or the last function the last call of a particular

880
01:04:16,100 --> 01:04:18,180
function

881
01:04:18,180 --> 01:04:22,100
So it's one of those it's it's the the one approach that

882
01:04:22,420 --> 01:04:27,860
We can be certain would stand the test of time versus something that we tried to kind of invent ourselves if you will

883
01:04:28,340 --> 01:04:33,540
Um, and then the p2s stuff similarly is quite literally unifying

884
01:04:34,980 --> 01:04:39,940
Three limits so that they they are logically consistent like they're right now. They're not logically consistent

885
01:04:40,340 --> 01:04:42,260
and so uh

886
01:04:42,260 --> 01:04:43,940
of all of those

887
01:04:43,940 --> 01:04:46,580
To me, uh feel like much more obvious things

888
01:04:46,580 --> 01:04:49,620
Than anything that I kind of put in the txv5 stuff

889
01:04:50,260 --> 01:04:54,500
um, and the txv5 stuff is uh, quite honestly in a lot of ways is like

890
01:04:55,060 --> 01:05:01,620
I am I am I don't have it in me to break those out and like try to champion them and start the process like

891
01:05:02,180 --> 01:05:08,820
They uh, I think I think everything in there are the correct ideas and they're the things we should probably be talking about for for the

892
01:05:08,900 --> 01:05:11,540
the problems they they they address um

893
01:05:11,540 --> 01:05:16,180
Read-only inputs could be its own thing and then the the bytecode limits could could be their own thing

894
01:05:16,580 --> 01:05:20,100
Everything else actually does have to be its own chip. It does have to be one

895
01:05:20,900 --> 01:05:22,900
transaction format upgrade

896
01:05:22,900 --> 01:05:30,180
Um, and and that's that that is just the nature of a transaction format upgrade like it is necessarily an ominous an omnibus bill

897
01:05:30,740 --> 01:05:34,420
Uh, you you can't just kind of break the transaction format

898
01:05:34,660 --> 01:05:40,180
If you're gonna if you're gonna trim all of the dead weight from the transaction format, you should get it all right the first time

899
01:05:40,180 --> 01:05:45,220
Yeah, sure. Um, and that's what that's what the rest of the chip is like for me again

900
01:05:45,220 --> 01:05:51,060
This is just looking at the pragmatism of of bitcoin cash today. So, you know the the transaction, um,

901
01:05:51,700 --> 01:05:54,660
Unchained transactions are relatively stable now

902
01:05:55,220 --> 01:05:58,660
Since the end of the the bear market

903
01:05:58,740 --> 01:06:05,140
So 2023 of course is that like there's some spikes of particular use cases that you know testing of new software

904
01:06:05,140 --> 01:06:08,820
But the base layer baseline is pretty pretty stable

905
01:06:08,820 --> 01:06:14,660
It's pretty pretty standard. So, um, you know, basically right now i'd say bitcoin cash the

906
01:06:15,380 --> 01:06:20,020
Where I can imagine this would be useful is is for example if we do end up with the zero knowledge proof

907
01:06:20,180 --> 01:06:22,180
um

908
01:06:22,180 --> 01:06:28,260
So you can have as you put it's nicely like the monero like or you know, potentially even better you can have some

909
01:06:28,740 --> 01:06:29,860
um

910
01:06:29,860 --> 01:06:31,460
modern security

911
01:06:31,460 --> 01:06:33,460
um privacy

912
01:06:33,540 --> 01:06:35,700
layers on on on bitcoin cash

913
01:06:35,700 --> 01:06:41,380
um, and maybe maybe this would generate a lot of transactions theoretically and you know,

914
01:06:41,460 --> 01:06:49,220
for example if that was to happen and and bch was to cannibalize the entire dark market usage and and monero for example users would

915
01:06:49,620 --> 01:06:51,780
Would use bitcoin cash missing. Okay, the

916
01:06:52,500 --> 01:06:59,700
there's a real like this is being used and um, then what i'm the one I understand, um this chip is

917
01:07:00,100 --> 01:07:02,100
Okay, if we were to implement this

918
01:07:02,100 --> 01:07:06,180
We get to basically we get to say I don't I I don't know but I would you know

919
01:07:06,180 --> 01:07:10,020
Whether it's 20 or 30 on on that transaction size

920
01:07:10,500 --> 01:07:12,660
Uh, so that we can end up having more throughput

921
01:07:13,140 --> 01:07:17,300
Um and still you know stay on the course to being a a world used

922
01:07:17,940 --> 01:07:20,660
um currency even with those particular

923
01:07:21,380 --> 01:07:23,380
Covenant's being used is yes

924
01:07:24,020 --> 01:07:29,220
Yeah, um, and I'd go further a little bit a little bit of my intention of like just kind of getting it all in one

925
01:07:29,220 --> 01:07:32,100
technical technical spec all the things we need to

926
01:07:32,660 --> 01:07:36,980
Uh clean up to be able to put a literally put a bitcoin cash

927
01:07:37,700 --> 01:07:45,620
Zero knowledge proof covenant transaction side by side with a z cash shielded transaction and compare them in byte length and and demonstrate

928
01:07:45,620 --> 01:07:50,180
That the bitcoin cash transaction is the same length or shorter than the z cash transaction

929
01:07:50,580 --> 01:07:52,980
um, and my my intention is to

930
01:07:52,980 --> 01:07:59,140
Is to prove beyond the shadow of a doubt that that's possible to to just dispel the idea that you need

931
01:07:59,700 --> 01:08:03,140
Layer one consensus upgrades to add privacy you don't um

932
01:08:03,540 --> 01:08:09,300
I I wanted to get that in a technical spec so that I could I could point to exactly what changes we would need to make

933
01:08:09,300 --> 01:08:11,300
To shave off every single bite

934
01:08:11,540 --> 01:08:13,540
um

935
01:08:13,540 --> 01:08:18,420
Uh required to to put those next to each other and say yes, we can do z cash on bitcoin cash

936
01:08:18,980 --> 01:08:21,540
Uh at at no bandwidth cost

937
01:08:21,540 --> 01:08:23,540
um

938
01:08:23,780 --> 01:08:28,420
Uh at no no additional bandwidth cost and actually um

939
01:08:29,380 --> 01:08:32,100
As I I mentioned in a few places in the chip too

940
01:08:32,980 --> 01:08:37,940
There there are real advantages to doing it at a user layer where users can deploy

941
01:08:38,500 --> 01:08:44,500
Their own protocols they can deploy covenants that implement a new protocol because there are there are you know

942
01:08:44,500 --> 01:08:47,940
Bleeding edge ideas and a lot of these um zero knowledge proof

943
01:08:47,940 --> 01:08:55,860
Uh fields where a a layer one network simply cannot deploy something

944
01:08:56,260 --> 01:08:58,660
That is a white paper that came out three weeks ago

945
01:08:59,700 --> 01:09:04,580
Bitcoin cash would be able to deploy it and people would be able to use it with 10 bucks and it would be fine if it broke

946
01:09:05,940 --> 01:09:09,540
It wouldn't it wouldn't jeopardize the network and it would bring the it would bring

947
01:09:09,540 --> 01:09:18,180
Um like university teams that are working on these things or or or new companies that that have

948
01:09:18,660 --> 01:09:23,860
You know, they're they're coming from from the math side of the academic world

949
01:09:24,260 --> 01:09:27,060
Um, whether they're coming from the zero knowledge proof academic world

950
01:09:27,860 --> 01:09:33,060
And they're wanting to turn their turn their ideas into a product. Um

951
01:09:33,700 --> 01:09:35,780
that uh, that is

952
01:09:35,780 --> 01:09:40,020
Usable on a real cryptocurrency. I think bitcoin cash could be a

953
01:09:40,820 --> 01:09:43,300
An ideal target for them to to

954
01:09:44,100 --> 01:09:50,820
Essentially publish their white paper with a proof of uh with a proof in um, I I think that there that

955
01:09:51,380 --> 01:09:55,620
There's there's certainly a future possible in the next few years where

956
01:09:56,180 --> 01:09:59,940
Novels your knowledge proof constructions are our first

957
01:10:00,980 --> 01:10:02,980
Demonstrated on bitcoin cash

958
01:10:02,980 --> 01:10:08,740
And because because our vm will be capable of it and and it's actually unique to bitcoin cash because ethereum

959
01:10:09,140 --> 01:10:16,340
It would be completely unreasonable to try to implement these things in ethereum because the transaction fees because ethereum has this kind of 1000x or worse

960
01:10:16,900 --> 01:10:21,620
Scaling disadvantage versus bitcoin cash and there's no way to fix that. That's an architectural problem

961
01:10:22,820 --> 01:10:25,140
To fix that you need to make it look like bitcoin cash

962
01:10:25,940 --> 01:10:29,940
So which I think is which I think is such an important point, right?

963
01:10:29,940 --> 01:10:33,620
So and that's why you know, I love what you're doing. I think it's important with the vision

964
01:10:33,620 --> 01:10:36,100
It's why i'm with bitcoin cash is because

965
01:10:36,740 --> 01:10:40,660
Technically, um, it's built for the future. Technically it's built

966
01:10:41,220 --> 01:10:42,020
for

967
01:10:42,020 --> 01:10:44,020
um for mass usage

968
01:10:44,340 --> 01:10:49,620
Um, and also, you know, but but it's also on the flip side of that the build it and they will come thing

969
01:10:50,020 --> 01:10:52,340
Um, it's clearly not true, right because ethereum

970
01:10:53,220 --> 01:10:55,940
They've got this something, you know, that's not as scalable

971
01:10:55,940 --> 01:11:00,980
But but it's being massively used bitcoin cash has this amazing ecosystem. That's massively more scalable

972
01:11:01,540 --> 01:11:05,300
And it's used, you know a fraction of that which is where you know for me

973
01:11:05,300 --> 01:11:10,660
It's important to get that balance of basically where where the resources are put where the effort is put in the ecosystem

974
01:11:11,220 --> 01:11:17,220
To make sure that the users are are growing but before I'd like you know, we've got a few more things

975
01:11:17,220 --> 01:11:19,780
I'd love to talk about i've got a final fina show out here

976
01:11:19,780 --> 01:11:27,380
From bruno get a bunch of self-licensed cypher punks working on your privacy aria vpn underscore net

977
01:11:27,380 --> 01:11:31,220
It's a strict no logs policy zero knowledge architecture vpn provider

978
01:11:31,860 --> 01:11:37,540
Not in any of the 14 i countries bch zero conf and xmr only 30 bucks for a whole year plan

979
01:11:38,100 --> 01:11:40,820
Business solutions available. So go and grab your vpn

980
01:11:41,540 --> 01:11:44,580
With uh paid with bch or monero

981
01:11:44,580 --> 01:11:50,420
So, um, yeah, this is jason then the intention of this by the way is to get transactions going

982
01:11:50,740 --> 01:11:55,300
Because people can actually pay with uh with tokens on bitcoin cash

983
01:11:55,620 --> 01:12:02,500
And they send it and it just basically just goes around in a flow, uh between uh between essentially my wallet and uh

984
01:12:03,140 --> 01:12:09,380
And cauldron decks is to encourage people to actually use the tokens and use bitcoin cash. Um,

985
01:12:09,940 --> 01:12:12,020
So, um, so this is a

986
01:12:12,020 --> 01:12:14,020
Bitcoin cash. Um

987
01:12:14,420 --> 01:12:17,860
So, I mean have you got any ideas on that yourself? Like where do you see?

988
01:12:18,580 --> 01:12:24,440
Um the big growth coming from in bitcoin cash over the next, you know in the in the short to midterm

989
01:12:31,380 --> 01:12:37,960
Um, I would say that the the all of the important work to be done there is actually on the entrepreneurs

990
01:12:37,960 --> 01:12:42,280
Uh and and you know specific products side

991
01:12:43,320 --> 01:12:50,520
I've spent a lot of time on these protocol upgrades, uh, because they're they're very foundational and they they unlock a lot of uh,

992
01:12:51,000 --> 01:12:58,440
A lot of possible entrepreneurship. Um, but yes, i'm i am personally very excited to not be working on protocol upgrades

993
01:13:00,040 --> 01:13:03,480
So i'm uh, i'm quite done. Um

994
01:13:04,200 --> 01:13:06,200
and uh as as I

995
01:13:06,200 --> 01:13:11,080
Like, you know kicking out the txv5 stuff, um, probably indicated. Um

996
01:13:11,800 --> 01:13:15,080
I uh, yeah, I will personally be working on um

997
01:13:15,880 --> 01:13:19,400
on chain graph and and libauth are

998
01:13:21,160 --> 01:13:23,160
Tooling to make um

999
01:13:23,400 --> 01:13:27,560
Kind of advanced wallet development easier. Um and and more advanced, uh

1000
01:13:28,420 --> 01:13:30,360
decentralized applications

1001
01:13:30,360 --> 01:13:33,720
Decentralized applications that you can use in across multiple wallets

1002
01:13:33,720 --> 01:13:40,760
Um, I think that's a big a big field that bitcoin cash is uniquely well positioned to to to kind of conquer

1003
01:13:41,240 --> 01:13:46,920
Whereas in ethereum and these other ecosystems like most most of the world is kind of based around everybody just

1004
01:13:47,320 --> 01:13:49,880
Builds their app and a website and pretends it's decentralized

1005
01:13:50,440 --> 01:13:51,480
um

1006
01:13:51,480 --> 01:13:53,960
so I I think that there's um, I think there's some

1007
01:13:54,680 --> 01:13:55,880
some

1008
01:13:55,880 --> 01:13:59,240
Some unique advantages in in how bitcoin cash works

1009
01:13:59,240 --> 01:14:04,040
Um that are just going to require a lot of a lot of more development and work

1010
01:14:05,080 --> 01:14:05,880
to

1011
01:14:05,880 --> 01:14:08,600
uh to to make them uh really

1012
01:14:09,480 --> 01:14:15,640
uh make them really into into practical products that that people can use but um

1013
01:14:16,040 --> 01:14:18,360
I won't I won't pretend to be uh good at

1014
01:14:19,320 --> 01:14:27,240
Identifying which specific entrepreneurial, uh ideas are going to are going to rise in the marketplace and and who's going to make it happen?

1015
01:14:27,240 --> 01:14:31,960
Because I mean ultimately in practice, uh, it's the it's

1016
01:14:32,840 --> 01:14:37,720
The individuals that are that are building these companies and products that are going to make all the difference. Um

1017
01:14:38,360 --> 01:14:39,640
and so uh

1018
01:14:39,640 --> 01:14:45,560
The the goal of any of this protocol upgrade stuff is is basically just to make sure that we've fully gotten out of their way

1019
01:14:46,520 --> 01:14:49,480
that the silly things that that are kind of just

1020
01:14:50,040 --> 01:14:51,560
you know

1021
01:14:51,560 --> 01:14:55,080
historical baggage in our in the protocol, um where

1022
01:14:55,080 --> 01:14:58,440
you know with in the case of limits we we kind of um,

1023
01:14:58,920 --> 01:15:02,840
You know satoshi basically kind of patch stuff up real quick duct tape some stuff and then left

1024
01:15:03,400 --> 01:15:08,360
um and uh and you know, we kind of we've been we've dealt with that for quite some time

1025
01:15:08,840 --> 01:15:15,320
Um getting that kind of in a in a better spot where people can use contracts to kind of the extent they expect

1026
01:15:16,200 --> 01:15:21,080
The the thing you know, everyone is in the community is quite well aware of how

1027
01:15:21,960 --> 01:15:23,400
BTC is

1028
01:15:23,400 --> 01:15:27,560
Is look down on bitcoin cash and like to you know

1029
01:15:28,120 --> 01:15:35,000
Joke about every aspect of it, but that's changed quite a lot recently when it comes to the development and tooling that's

1030
01:15:35,720 --> 01:15:38,440
Happening on bitcoin cash. I guess you've seen this on on twitter

1031
01:15:39,000 --> 01:15:41,000
um, and uh

1032
01:15:41,240 --> 01:15:44,840
Yeah, this is definitely an interesting change that people people are becoming more aware

1033
01:15:45,480 --> 01:15:50,440
Um in the ecosystem in the wider ecosystem outside of bitcoin cash. Most importantly

1034
01:15:50,440 --> 01:15:54,360
That okay things are cooking here. Like these guys are really improving

1035
01:15:54,360 --> 01:15:59,880
This isn't just bigger blocks because that's that's what most people think right bitcoin cash is just bitcoin with bigger blocks

1036
01:16:00,520 --> 01:16:02,520
Well, not anymore

1037
01:16:03,880 --> 01:16:05,880
Um, yeah, there's uh

1038
01:16:06,280 --> 01:16:12,040
Yeah, i'm excited to especially this next couple years are going to be are going to be exciting some of this stuff

1039
01:16:12,600 --> 01:16:16,040
um, you know as we've seen with cash token it cash tokens it

1040
01:16:16,760 --> 01:16:18,760
Took more than a year to get um

1041
01:16:18,760 --> 01:16:22,920
um, some of the some of the software in place even though we had you know, we had a

1042
01:16:23,560 --> 01:16:26,840
patches for a block explorer and patches for a wallet or two

1043
01:16:27,400 --> 01:16:29,060
um before

1044
01:16:29,060 --> 01:16:32,120
Activation, um, it's just really really hard to

1045
01:16:32,740 --> 01:16:37,800
Speculatively work on products that were that rely on a consensus upgrade

1046
01:16:38,280 --> 01:16:44,760
Um until it's until it's locked in at least locked in and and in practice a lot of companies are still going to be

1047
01:16:45,300 --> 01:16:47,300
uncertain until after may 15th

1048
01:16:47,300 --> 01:16:50,340
um, because that's what they've come to expect for from

1049
01:16:51,060 --> 01:16:53,060
the the wider

1050
01:16:53,760 --> 01:16:58,020
Specifically the wider bitcoin ecosystem, but also just all cryptocurrencies like you don't know it

1051
01:16:58,260 --> 01:17:02,580
You don't know it's going to be it's going to be a stable ground until it's for sure there

1052
01:17:03,140 --> 01:17:06,360
Um, and you can't you can't waste your company's resources

1053
01:17:08,100 --> 01:17:11,540
Building building for something that that might not ever work

1054
01:17:12,180 --> 01:17:13,220
um

1055
01:17:13,220 --> 01:17:15,220
so having having

1056
01:17:15,220 --> 01:17:17,540
The kind of protocol upgrades

1057
01:17:18,260 --> 01:17:20,900
actually live and working, um

1058
01:17:21,780 --> 01:17:29,380
Is is a necessary prerequisite for the the kinds of efforts that are you know, uh a year-long technical development effort

1059
01:17:30,100 --> 01:17:32,100
producing a product that that is

1060
01:17:32,660 --> 01:17:34,660
That that could really it

1061
01:17:35,860 --> 01:17:40,660
Uh could really improve our bottom line on that on that layer one usage that we were talking about

1062
01:17:41,140 --> 01:17:43,140
um, so and what what are the ideas

1063
01:17:43,140 --> 01:17:46,340
Was that sorry you said I mean you say you're not an entrepreneur

1064
01:17:46,340 --> 01:17:50,600
But you've come up with some some nice ideas that could at the very least be used by entrepreneurs

1065
01:17:50,980 --> 01:17:56,740
And one of the you know, it was that prediction markets, you know, which we're seeing uh, to some degree with bch guru

1066
01:17:56,740 --> 01:18:02,100
although, you know the prediction markets, you know, I as understood you had had in mind and I think that really interests me is

1067
01:18:02,660 --> 01:18:06,100
Um is wider than that so, you know to actually start sort of

1068
01:18:06,820 --> 01:18:11,460
validating truth or what is the truth or putting some money behind actually what the truth is and

1069
01:18:11,460 --> 01:18:16,020
um, which is very interesting but but one of the things you had was jadex

1070
01:18:16,740 --> 01:18:19,060
Which you know, you saw a lot of opportunity here

1071
01:18:19,540 --> 01:18:22,340
uh for people to very easily, uh

1072
01:18:23,620 --> 01:18:30,020
Sell their tickets and set up basically a system where they can where they can uh distribute and uh

1073
01:18:30,980 --> 01:18:33,220
Set up their own exchange for for just pennies

1074
01:18:33,620 --> 01:18:36,420
Um, is that something that's been parked?

1075
01:18:36,420 --> 01:18:42,100
Is it is it shelved now or is it something that is if potentially, you know, you would continue working on at some point?

1076
01:18:42,740 --> 01:18:44,900
um, yeah, certainly, uh, it's uh

1077
01:18:46,020 --> 01:18:48,740
No, um, everything was everything was parked

1078
01:18:49,540 --> 01:18:51,140
except for vm limits

1079
01:18:51,140 --> 01:18:56,420
Uh for essentially all of 2024. Uh, so as far as my personal my personal development schedule

1080
01:18:56,980 --> 01:19:04,900
Including including basically nothing other than vm limits. Uh, in fact my real life schedule included almost nothing but vm limits last year, but um

1081
01:19:04,900 --> 01:19:10,820
Um, but uh, by the way, which thank you, you know, really it's very highly appreciated

1082
01:19:11,380 --> 01:19:14,100
Work in the in the ecosystem. Thanks. Um

1083
01:19:14,820 --> 01:19:18,900
But uh, yeah, so 2025 i'm definitely excited to be working on um on

1084
01:19:20,180 --> 01:19:21,940
more, uh

1085
01:19:21,940 --> 01:19:23,780
essentially just

1086
01:19:23,780 --> 01:19:24,660
uh

1087
01:19:24,660 --> 01:19:31,140
direct products, um, and yeah, I I have a lot of work to do in chain graph and I've uh,

1088
01:19:31,700 --> 01:19:33,860
A lot of work to do in lib off

1089
01:19:33,860 --> 01:19:35,860
um the javascript library, um

1090
01:19:36,980 --> 01:19:41,220
To uh make some of these things that are until now have been kind of demos

1091
01:19:41,780 --> 01:19:48,420
To make them really practical and easy to implement in wallets and and uh easy to kind of copy templates between wallets and just run it

1092
01:19:48,580 --> 01:19:56,020
Um, yeah, there's there's um, there's some very exciting stuff to be done there. Um, and i'll be working on that

1093
01:19:58,020 --> 01:19:59,140
And uh

1094
01:19:59,140 --> 01:20:04,340
At some point when that stuff's good enough then then actually the jet x template from 2022 will just work

1095
01:20:05,140 --> 01:20:10,260
so, uh in any wallet that implements, uh the wallet template stuff, so um

1096
01:20:11,140 --> 01:20:13,140
The the design of that is

1097
01:20:13,540 --> 01:20:19,140
Uh, you know 80 of the work done and with big end. Um, the last 20 is simply removed

1098
01:20:19,620 --> 01:20:24,660
Um, you you don't need it. So, uh, yeah, so the the 2022

1099
01:20:24,660 --> 01:20:32,180
Um implementation is actually already fully optimized and ready to go but getting from you know,

1100
01:20:32,260 --> 01:20:37,460
A theoretical protocol spec like that to something where you click a button in a wallet and it actually works

1101
01:20:37,780 --> 01:20:41,620
Um that that's a lot of work and and it's not just like tooling work

1102
01:20:41,700 --> 01:20:45,220
But also there's some entrepreneurship there of like, uh getting getting

1103
01:20:45,700 --> 01:20:49,220
Wallets in in the hands of users that are wanting to use it in that way

1104
01:20:49,220 --> 01:20:54,260
Um, so yeah, I I definitely expect to work on um the

1105
01:20:55,140 --> 01:20:56,260
the

1106
01:20:56,260 --> 01:21:00,660
um wallet engine in libauth over the next um

1107
01:21:01,380 --> 01:21:03,380
You know into the future

1108
01:21:03,680 --> 01:21:10,260
indefinitely, um now uh and and uh when that is um

1109
01:21:11,200 --> 01:21:17,940
Sufficiently capable it will be possible for it to just execute the jet x template from 2022. Um, so yeah

1110
01:21:17,940 --> 01:21:21,700
Anyways, if jettix specifically is is as done as it can get

1111
01:21:22,340 --> 01:21:27,780
Until you get to the to the wallet integration side and and then there's a lot of wallet integration tooling work to be done

1112
01:21:28,500 --> 01:21:31,620
And i'm i'm working on that now. So um, yeah, we'll see

1113
01:21:33,300 --> 01:21:37,620
That's what we want to hear I mean this is this is the thing that I I think um

1114
01:21:38,180 --> 01:21:45,540
It is clear in bitcoin gash is the entrepreneur side. This is that the people that have got to you know, the eye of the resources

1115
01:21:46,100 --> 01:21:47,780
to um

1116
01:21:47,780 --> 01:21:49,780
to use what's what's there?

1117
01:21:49,940 --> 01:21:55,540
um all of the the possibilities on the chain all of the work or the groundwork that you've set out already on the

1118
01:21:56,020 --> 01:22:04,660
um on the main chain to to then extract value, uh rather well offer value right um from from the chain, um, and

1119
01:22:05,620 --> 01:22:09,860
Because you know, there's always the the things coming up, you know how to get bitcoin cash. Um

1120
01:22:10,500 --> 01:22:14,420
Used more we need more marketing and so well, you know, my question is well who's going to pay for that?

1121
01:22:14,420 --> 01:22:17,940
Uh, whereas of course you have entrepreneurs selling their product or service

1122
01:22:18,740 --> 01:22:23,460
Um, then they're they're paying for the marketing and and they're financially incentivized to do that

1123
01:22:23,460 --> 01:22:27,060
I think the biggest bitcoin cash marketers that I see

1124
01:22:27,700 --> 01:22:34,100
Um are general protocols, uh, you know, but you you see the any hedge comics going out you see uh,

1125
01:22:34,740 --> 01:22:40,100
You know always something and because they're marking their marketing their product. Um, and and I think this is the greatest way

1126
01:22:40,740 --> 01:22:43,060
That will see bitcoin cash use grow

1127
01:22:43,060 --> 01:22:48,500
Uh is through that so i'd love to see more entrepreneurship in the ecosystem and what I think is really important

1128
01:22:48,980 --> 01:22:56,100
Um, because as a non-developer it's uh, and also I think it's just also someone that's that's not got a business that's running on

1129
01:22:56,900 --> 01:22:59,060
um, the bitcoin cash like directly

1130
01:22:59,700 --> 01:23:06,500
Is is to make sure that the chips that are being put in are actually based on economical need

1131
01:23:06,980 --> 01:23:08,500
um

1132
01:23:08,500 --> 01:23:10,180
you know because the

1133
01:23:10,180 --> 01:23:17,460
When you have entrepreneurs that are that are building things then of course then that feedback the the mix between entrepreneurs their needs for

1134
01:23:17,620 --> 01:23:19,620
For business that is really

1135
01:23:19,920 --> 01:23:23,300
Utilizing bch as money and everything that it offers

1136
01:23:23,780 --> 01:23:24,820
um

1137
01:23:24,820 --> 01:23:27,620
That's actually a direct economical factor of hey, you know

1138
01:23:27,780 --> 01:23:32,580
This has a reason why it should be adapted because by by adapting this is allows my business to

1139
01:23:32,900 --> 01:23:38,660
To be even bigger and grow faster and and use the chain even more than than it than it's being used today

1140
01:23:38,660 --> 01:23:44,260
um and and that's what i'd love to see just to make sure that this balance this balance is there because um,

1141
01:23:44,500 --> 01:23:49,140
You know, you're clearly an incredibly smart person and you're looking very far into the future

1142
01:23:49,620 --> 01:23:50,580
um

1143
01:23:50,580 --> 01:23:52,820
But nothing beats cold hard reality

1144
01:23:53,540 --> 01:23:58,980
What's what's what's actually happening today? You know how people are using things? I think in the sort of feedback mechanism

1145
01:23:59,460 --> 01:24:01,940
Um, which I guess we could do a bit more of today

1146
01:24:03,860 --> 01:24:07,620
Um, yeah, a lot of very smart people have been completely ruined by mr market so

1147
01:24:07,620 --> 01:24:09,620
Yeah

1148
01:24:12,660 --> 01:24:17,460
Yes, I definitely agree i'm excited to see lots of bitcoin cash companies, um,

1149
01:24:18,100 --> 01:24:19,860
uh doing

1150
01:24:19,860 --> 01:24:26,020
building more and more uh products that are sort of unique to bitcoin cash and especially like uh token

1151
01:24:27,300 --> 01:24:34,660
Token related products where you need both good good token support reasonable contracting capabilities

1152
01:24:34,660 --> 01:24:39,380
And pretty low transaction fees. Um, and that's actually a mix. You can't really get anywhere else

1153
01:24:39,380 --> 01:24:41,540
You can kind of get it a little bit on solana right now

1154
01:24:41,940 --> 01:24:42,980
um

1155
01:24:42,980 --> 01:24:45,700
but uh certainly not at the scale and um

1156
01:24:46,660 --> 01:24:53,940
But yeah, not at the scale that uh that bitcoin cash could offer it so um, yeah, scale and transaction fee, uh, yeah reliability

1157
01:24:54,820 --> 01:24:57,300
Like get transactions that don't get uh, don't get cancelled

1158
01:24:57,700 --> 01:25:01,060
um, yeah, and and I guess uh also

1159
01:25:01,060 --> 01:25:04,280
Decentralized but um, yeah anyhow, um

1160
01:25:05,080 --> 01:25:11,800
Yeah, so i'm very excited to see that stuff happening and uh, and hopefully to to contribute a little bit of a little bit more of it myself

1161
01:25:13,160 --> 01:25:16,520
From that side a bit. Yeah, I've spent a lot. Yeah, I've spent a lot of time on

1162
01:25:17,000 --> 01:25:21,080
On you know, basically making our programming language support loops and stuff

1163
01:25:22,680 --> 01:25:25,640
Yeah, and it's really and it's really you know, everyone

1164
01:25:25,640 --> 01:25:30,460
Everyone expected after getting the lock in in november

1165
01:25:31,000 --> 01:25:36,680
Um everyone expected and certainly I did that we won't be seeing much of jason now for a while

1166
01:25:37,000 --> 01:25:40,440
You know whether it's going to be five months or six months. I'm sure he's going to you know

1167
01:25:40,440 --> 01:25:44,200
He's going to just calm down a bit and uh, just a few weeks later. Whoa

1168
01:25:46,520 --> 01:25:49,320
Three new chips, uh, you know, no piece of the wicked

1169
01:25:49,320 --> 01:25:55,720
Um, so I think you deserve you definitely deserve a break. I can imagine that the many developers in the community that go through

1170
01:25:55,960 --> 01:25:57,960
These chips and really pick them apart

1171
01:25:58,360 --> 01:26:00,360
Uh, they also

1172
01:26:00,440 --> 01:26:03,160
Will be happy with a break. I think it's exciting

1173
01:26:03,160 --> 01:26:07,720
You know, I think it's really great to have uh more ideas than we need and to be able to pick the best ones and throw

1174
01:26:07,720 --> 01:26:09,880
Away, um, you know more I think that's great

1175
01:26:10,360 --> 01:26:14,680
um, but you know what I also you know, as we've said I think uh,

1176
01:26:14,680 --> 01:26:19,480
Um, the the stage right so you know one of the one of the chips and I know you've mentioned and you said hey

1177
01:26:19,480 --> 01:26:21,400
We have to be in the top 10 and so forth

1178
01:26:21,400 --> 01:26:27,320
But one of the parts of the the the new chip that you sort of uh, the announced, uh, was it just yesterday?

1179
01:26:27,800 --> 01:26:29,720
Um, it is gonna know today. Yeah

1180
01:26:31,000 --> 01:26:34,760
Yeah, I mean this talk being a good forcing function. We're like, I should probably get that out. All right

1181
01:26:35,880 --> 01:26:37,080
Yeah, yeah

1182
01:26:37,080 --> 01:26:40,440
Yeah, and it's great and I love the you know, um the the reaction it

1183
01:26:40,440 --> 01:26:43,560
It creates in the community. It sort of gives the

1184
01:26:44,120 --> 01:26:47,960
I think quite a high signal of how you are regarded and people are excited

1185
01:26:47,960 --> 01:26:52,040
You know about what what's possible and what can be done and how are we going to improve this chain?

1186
01:26:52,440 --> 01:26:55,880
Uh, which is why I think such an exciting chain to work at because people want it to see

1187
01:26:56,360 --> 01:26:59,320
We want it to be the best money that that can ever that will ever

1188
01:26:59,800 --> 01:27:05,000
Exist. Um, and one of the things that you know, fractional satoshis. I looked at this and I saw some people going

1189
01:27:05,000 --> 01:27:07,000
Yeah, yeah with this is something, you know

1190
01:27:07,000 --> 01:27:09,560
I have to admit I laughed and I thought wow, you're bullish

1191
01:27:11,960 --> 01:27:15,180
Fractional satoshis, you know, there's a hundred million satoshis

1192
01:27:15,960 --> 01:27:19,000
Satoshi is in a bitcoin our bitcoin cash

1193
01:27:19,560 --> 01:27:26,680
Um, so, you know, you're already planning for eight billion people using this and transacting everything on this. So I mean

1194
01:27:27,560 --> 01:27:29,560
Yeah, so it just I mean

1195
01:27:29,880 --> 01:27:32,840
You know, it's a problem we should have a good answer for when it rises

1196
01:27:32,840 --> 01:27:39,080
Um, it would be good for it to for for us to have argued about it a little bit here in 2025

1197
01:27:39,480 --> 01:27:43,160
Um, and you know there and again, there are also been other proposals

1198
01:27:44,200 --> 01:27:48,440
Uh in the past couple years and then there are some proposals from kind of 2013 era

1199
01:27:49,320 --> 01:27:51,320
And I just wanted to kind of get on paper

1200
01:27:51,880 --> 01:27:54,440
What I consider to be a pretty um a pretty

1201
01:27:55,720 --> 01:28:01,000
Uh straightforward solution, um that optimizes the things that matter to optimize

1202
01:28:01,000 --> 01:28:08,920
Um, and uh, and some rationale for it. So just uh that so that conversation can be can be brewing for some time

1203
01:28:09,320 --> 01:28:15,160
Um, but yeah, certainly fractional satoshis are not urgent. Uh, if anything fractional cash tokens

1204
01:28:15,800 --> 01:28:21,240
Are are much more urgent in that there are lots of use cases that there's a there is a plausible

1205
01:28:21,960 --> 01:28:25,820
A plausible concern that you wouldn't quite have enough precision

1206
01:28:26,360 --> 01:28:30,040
Uh with with what cash tokens offer right now because cash tokens essentially offer the same

1207
01:28:30,040 --> 01:28:32,040
Precision as satoshis

1208
01:28:32,520 --> 01:28:37,240
Um, and by design that was intentional to make sure that you know, whatever we do with fractional satoshis would do the same

1209
01:28:37,240 --> 01:28:40,280
We'd do the same thing with fractional cash fractional cash tokens, but um

1210
01:28:41,160 --> 01:28:42,520
uh

1211
01:28:42,520 --> 01:28:44,520
the um

1212
01:28:45,000 --> 01:28:48,520
Yeah, I can I can certainly see fractional cash tokens being becoming

1213
01:28:49,460 --> 01:28:55,640
Relevant even a little bit before the fractional satoshis. Um, but then there's also you know, if we if we had a huge

1214
01:28:55,640 --> 01:29:01,320
uh uptick and and increase in layer one, uh volume, um

1215
01:29:02,040 --> 01:29:07,400
There's a chance that fractional satoshis would be useful essentially just for specifying transaction fees

1216
01:29:07,960 --> 01:29:13,400
Um, that's kind of the primary use anyways, um in in the much longer term, but um

1217
01:29:14,280 --> 01:29:16,680
There are and the chip talks a little bit about um

1218
01:29:17,560 --> 01:29:23,480
You know today's largest, uh financial markets use tick sizes that aren't quite representable. Um

1219
01:29:23,480 --> 01:29:27,160
Um, if you if you don't have a little bit better division, um

1220
01:29:27,880 --> 01:29:32,200
So yeah, you can look at the rationale there, but i'm glad to be uh, sort of done with that

1221
01:29:32,920 --> 01:29:34,920
for a while

1222
01:29:35,240 --> 01:29:37,240
For a while, let's see

1223
01:29:38,920 --> 01:29:41,160
One or two months and be like oh shit i'm bored i'm coming back

1224
01:29:43,080 --> 01:29:48,600
Roll up the sleeves and get cracking. Yeah, i'll continue. Um, I want to continue like, uh,

1225
01:29:49,240 --> 01:29:52,440
Um clarifying rationale and stuff like that for for all of these

1226
01:29:52,440 --> 01:29:57,880
Um, but yeah to be super clear the the 2026 stuff is stuff that I um

1227
01:29:58,600 --> 01:30:00,360
I that I think

1228
01:30:00,360 --> 01:30:01,560
is

1229
01:30:01,560 --> 01:30:03,000
far

1230
01:30:03,000 --> 01:30:08,600
um, you know potentially far less controversial and far more straight far straight forward like things that

1231
01:30:09,080 --> 01:30:10,280
um

1232
01:30:10,280 --> 01:30:16,120
I have easy easy proofs that um, they will stand the test of time

1233
01:30:16,840 --> 01:30:18,840
versus the stuff that I I didn't

1234
01:30:18,840 --> 01:30:25,880
Um, you know try to propose for 2026 is the stuff that uh, I can't easily prove is going to be the optimal design or or

1235
01:30:26,040 --> 01:30:31,800
or has has designed decisions that that are kind of subjective or or um,

1236
01:30:32,440 --> 01:30:34,040
that uh

1237
01:30:34,040 --> 01:30:36,520
There's it's possible that we might uh

1238
01:30:38,280 --> 01:30:41,480
Come up come up later with a slightly better way of doing something

1239
01:30:43,240 --> 01:30:47,880
Versus the 2026 stuff, uh is essentially all sort of

1240
01:30:47,880 --> 01:30:54,440
In some ways sort of ancient tech but also just timeless things like the loops and and obi val are like

1241
01:30:54,920 --> 01:30:58,360
You're not going to do better than taking one thing from the stack and evaluating it. Um

1242
01:30:59,160 --> 01:31:00,360
uh versus

1243
01:31:00,360 --> 01:31:02,360
Doing something more clever

1244
01:31:02,920 --> 01:31:04,200
um

1245
01:31:04,200 --> 01:31:12,040
so, uh, yeah, I i'm i'm hopeful that uh that i'm interested in in the continued review of the the 2026 stuff and

1246
01:31:12,040 --> 01:31:19,640
I'm going to keep working on on tooling to make it very useful. Um in in end user wallets, um,

1247
01:31:20,200 --> 01:31:22,200
because that's uh, that's

1248
01:31:22,520 --> 01:31:27,080
Where I planned where I plan to spend my time for much of this year, but um

1249
01:31:27,800 --> 01:31:29,320
but uh

1250
01:31:29,320 --> 01:31:30,920
yeah, and I I

1251
01:31:31,720 --> 01:31:32,120
I

1252
01:31:32,120 --> 01:31:34,680
I i'm excited that there there's already a lot of

1253
01:31:35,400 --> 01:31:36,200
um

1254
01:31:36,200 --> 01:31:40,360
A lot of interest obviously in the loop stuff. I think the opi val, um

1255
01:31:40,360 --> 01:31:41,960
opi val, um

1256
01:31:41,960 --> 01:31:43,960
was certainly surprising, um

1257
01:31:44,760 --> 01:31:46,440
uh

1258
01:31:46,440 --> 01:31:47,880
because uh

1259
01:31:47,880 --> 01:31:54,360
again very few people are exposed to function application in their contract design because they're using they're using cash script and they just kind of

1260
01:31:54,680 --> 01:31:57,640
Ignore what comes out the other end in a lot of cases like you know

1261
01:31:57,720 --> 01:32:02,280
you put in the cash script and you and you get whatever it comes out and and you know if you if you

1262
01:32:03,860 --> 01:32:05,860
Disassemble it and and

1263
01:32:05,880 --> 01:32:09,000
Consider how you might make it more efficient. Um

1264
01:32:09,000 --> 01:32:17,480
Um, you would find that you know, there are some there's some obvious, uh places where a function application would cut cut 50% of your transaction size or something

1265
01:32:17,480 --> 01:32:21,080
But you know, is it most people are not exposed to that problem because it doesn't show up

1266
01:32:21,560 --> 01:32:25,400
At the at the cash script side where you need a construct to pretend that you have loops

1267
01:32:25,960 --> 01:32:32,920
Yeah, sure, and the same is true of the pos stuff, but if it's came with you so uh emergent. So john neary from

1268
01:32:33,880 --> 01:32:35,880
general protocols he would love to

1269
01:32:35,880 --> 01:32:39,160
Uh, yeah say something. So yeah john, you're you've got the mic

1270
01:32:39,960 --> 01:32:46,200
Hey, I just wanted to make sure that it's clear that uh, I completely disagree with fiendish's point that it's okay to take a break

1271
01:32:46,280 --> 01:32:48,280
No breaks

1272
01:32:51,960 --> 01:32:57,720
And if I know Jason probably his brain if there's something important to be done it's not gonna let him take a break

1273
01:32:59,240 --> 01:33:01,480
Listen I was playing the long game. Jesus

1274
01:33:01,480 --> 01:33:03,480
Jesus

1275
01:33:04,840 --> 01:33:08,280
Of course he's not allowed to take a break but we can't say that out loud man

1276
01:33:11,400 --> 01:33:15,720
Also actually constructive um, so about the topic uh, jason was saying

1277
01:33:16,280 --> 01:33:21,880
Uh that it's really important to develop. Uh, you know, it doesn't matter as we've been saying for for several years now at gp

1278
01:33:21,960 --> 01:33:23,080
It doesn't matter

1279
01:33:23,080 --> 01:33:27,720
Uh how much power your chain has if it's not accessible to developers and users?

1280
01:33:27,720 --> 01:33:35,080
And so, you know, that's the whole concept of the native wallet and as long as we've been working and thinking and conceptualizing about it

1281
01:33:35,080 --> 01:33:41,080
Jason's been conceptualizing about it even longer, right? Like he's had this code out for what is it like eight years or?

1282
01:33:42,840 --> 01:33:44,840
Like the cli wallet anyway

1283
01:33:45,480 --> 01:33:49,880
For a very long time because he also 2018. Yeah, I think it was 2018, right? Yeah

1284
01:33:49,880 --> 01:33:55,240
Yeah, it was the earliest stuff at the end. Maybe 20. Yeah, I have some videos of it. Yeah, so

1285
01:33:55,240 --> 01:34:00,040
Yeah, we we totally agree with that and I was also in the process of writing an email

1286
01:34:00,520 --> 01:34:05,080
Uh to invite jason to our internal, uh, we have a like a bi-weekly meeting

1287
01:34:05,080 --> 01:34:09,320
We call xo connect right because that's our attempt at the at the native wallet

1288
01:34:09,720 --> 01:34:15,000
concept and so i'd really like uh, i'm really hoping jason will join us at xo connect and uh

1289
01:34:15,400 --> 01:34:17,880
Have us hash out some of these uh issues where

1290
01:34:18,600 --> 01:34:23,400
You know, we we've got the concepts and then now it's time to like really uh make the rubber

1291
01:34:23,400 --> 01:34:25,880
Meet the road and actually put these things out in people's hands

1292
01:34:25,880 --> 01:34:31,000
And so there's a lot of little details to iron out and we'd love to have you on jason

1293
01:34:31,000 --> 01:34:37,160
So I hope you'll you'll join us sweet. Yeah, i'd be happy to have don't know how much I can commit to but I could for sure

1294
01:34:37,160 --> 01:34:43,240
It'd be fun to uh get together a bit. Yeah. Yeah. All right. Anyway, thanks for the time. I appreciate it

1295
01:34:44,840 --> 01:34:49,640
Thanks, you're more than welcome. Thank you jason so much for coming on so

1296
01:34:49,640 --> 01:34:56,040
Uh, yeah, I I promised not to not to take too much more of your time than than an hour and a half

1297
01:34:56,040 --> 01:34:58,600
Um, so I think that's a good point just to sort of

1298
01:34:59,240 --> 01:35:04,920
Uh wrap wrap things up. So um, yeah, thanks again jason for your time

1299
01:35:04,920 --> 01:35:09,000
It's been really humbling to have you on the show today, uh, and an absolute pleasure

1300
01:35:09,560 --> 01:35:15,640
Can't stress enough appreciate all your work that you've done in making decentralized sound money a reality

1301
01:35:16,280 --> 01:35:18,280
um, and uh, yeah and all the time

1302
01:35:18,280 --> 01:35:25,880
And uh, yeah and all of this, you know, it's an important mission and you know separating money from the state is something that is going to transform

1303
01:35:26,680 --> 01:35:29,640
Money more than anything that's happened ever before in human history

1304
01:35:30,280 --> 01:35:35,640
And I believe that we're on the right path to to reach that and that's through your help and work. So, thank you

1305
01:35:37,720 --> 01:35:40,680
Amen and thank you and i'll try not to let that other stuff go to my head either

1306
01:35:42,040 --> 01:35:45,240
You can let it go to your head and then so when you want to take your break you like shit

1307
01:35:45,240 --> 01:35:50,120
But i'm a god here. I can continue working ridiculous. You see that's the strategy

1308
01:35:50,520 --> 01:35:52,520
It's a good one. It's gonna work. I can feel it

1309
01:35:53,880 --> 01:35:54,360
All right

1310
01:35:54,360 --> 01:36:00,360
That's it the txv5 is the last of the of the chip stuff I I have in my backlog. That's uh,

1311
01:36:00,760 --> 01:36:02,760
I'm gonna go work on software now

1312
01:36:02,840 --> 01:36:07,640
Good. All right. We'll let you off. We'll let you off and we'll welcome you back when you manage to get back in so

1313
01:36:08,040 --> 01:36:12,040
for all the listeners, make sure follow jason on twitter at

1314
01:36:13,000 --> 01:36:14,280
bitjason so j

1315
01:36:14,280 --> 01:36:19,800
S o n to keep up with all of the bch developments see see if he can manage this see if he can go the

1316
01:36:19,880 --> 01:36:22,200
The rest of the year without uh chip proposals

1317
01:36:23,000 --> 01:36:28,520
I'm sure you can make a bet against this on bch guru because I think there's gonna a lot of people that'll take that bet

1318
01:36:29,080 --> 01:36:31,080
To be honest, let's see. Um

1319
01:36:31,800 --> 01:36:34,120
If you enjoyed the show and want to show your appreciation

1320
01:36:34,200 --> 01:36:39,720
Please feel free to drop some bch or a fiendish token into the wallet the address is in the comments at the start of the spaces

1321
01:36:39,720 --> 01:36:45,560
Um, the next episode of fiendish and friends is again at four o'clock central european time next friday

1322
01:36:45,880 --> 01:36:53,000
And it's featuring joshua petty aka elon moist developer behind now defunct decentralized social media app twitch

1323
01:36:53,240 --> 01:36:56,860
Let's talk about bitcoin scaling and the future of pdcash and cryptocurrencies

1324
01:36:58,120 --> 01:37:04,360
So great, uh again, thanks for being here and jason this was fiendish and friends

1325
01:37:04,360 --> 01:37:10,060
I wish you all a good morning. Good day and good night. Take care