1
00:00:00,000 --> 00:00:09,920
You've had a dynamic where money has become freer than free.

2
00:00:10,780 --> 00:00:13,040
You talk about a Fed just gone nuts.

3
00:00:13,500 --> 00:00:15,700
All the central banks going nuts.

4
00:00:16,380 --> 00:00:17,880
So it's all acting like safe haven.

5
00:00:18,360 --> 00:00:23,920
I believe that in a world where central bankers are tripping over themselves to devalue their currency,

6
00:00:24,440 --> 00:00:25,260
Bitcoin wins.

7
00:00:25,340 --> 00:00:28,460
In the world of fiat currencies, Bitcoin is the victor.

8
00:00:28,460 --> 00:00:31,380
I mean, that's part of the bull case for Bitcoin.

9
00:00:31,800 --> 00:00:34,240
If you're not paying attention, you probably should be.

10
00:00:37,520 --> 00:00:39,320
Andrew Polstra, welcome back to the show, sir.

11
00:00:39,380 --> 00:00:40,340
It's great to have you.

12
00:00:40,900 --> 00:00:41,960
Hey, great to be back.

13
00:00:43,040 --> 00:00:44,460
Like I said, I want to say it again.

14
00:00:44,620 --> 00:00:48,100
Congrats on getting simplicity over the line.

15
00:00:48,200 --> 00:00:51,860
I know it's been a long, almost a decade journey for Blockstream.

16
00:00:52,500 --> 00:00:53,660
Yep. Yeah, for sure.

17
00:00:53,660 --> 00:00:57,800
We got it onto the test network less than a year ago.

18
00:00:57,800 --> 00:01:01,220
that was a big deal but this is our first production network with with real money on it

19
00:01:01,220 --> 00:01:07,120
that you can use simplicity now with real money which is a pretty cool thing yeah so i guess for

20
00:01:07,120 --> 00:01:16,660
anybody out there who's either newer to bitcoin unaware of simplicity why don't we give uh a

21
00:01:16,660 --> 00:01:22,220
background i was gonna say brief background but i like your verbosity verbosity and you have deep

22
00:01:22,220 --> 00:01:28,440
on it so i'm not gonna i'm not gonna um give any false promises to the audience we're about to get

23
00:01:28,440 --> 00:01:35,560
an in-depth uh history on simplicity it really starts in 2012 when russle o'connor sort of

24
00:01:35,560 --> 00:01:40,320
sketched the design and then you guys decided to really lean into it a block stream in like 2016

25
00:01:40,320 --> 00:01:46,600
correct yep yeah that's about right um i would even say it started a little before how about this

26
00:01:46,600 --> 00:01:51,260
i will try to be brief i always i always say i don't know why i'm probably saying it but i'll

27
00:01:51,260 --> 00:01:57,440
try to be brief so uh that's even before even before simplicity in 2012 there was uh russell

28
00:01:57,440 --> 00:02:03,780
o'connor had been in the bitcoin space he showed up very early days um 2010 i think maybe 2011 i

29
00:02:03,780 --> 00:02:10,000
think it was 2010 and he had this concept called mast merkelized abstract syntax trees and this

30
00:02:10,000 --> 00:02:16,580
eventually turned into what uh is now taproot where the idea is rather than having a script

31
00:02:16,580 --> 00:02:21,660
system where you've got like if this then that kind of thing everybody runs this everybody has

32
00:02:21,660 --> 00:02:26,820
to download this whole program and then run it and then they've got various conditions that that

33
00:02:26,820 --> 00:02:30,760
apply under different conditions but they've always got to download it right they've always

34
00:02:30,760 --> 00:02:38,080
got to see the whole script what if instead every time there was a conditional if this thing then

35
00:02:38,080 --> 00:02:43,460
that thing what if we put them all in a merkle tree and so now you can have um hundreds or

36
00:02:43,460 --> 00:02:49,120
thousands or millions of conditions and when you want to spend your coins at the time of spending

37
00:02:49,120 --> 00:02:53,500
you know which conditions you're going to use to spend the coin so you just reveal that specific

38
00:02:53,500 --> 00:02:58,480
one and the premise behind a merkle tree is is you can do exactly that it's this big structure

39
00:02:58,480 --> 00:03:05,060
where you can commit to arbitrarily large numbers of things like up to up to billions before you're

40
00:03:05,060 --> 00:03:11,280
you're spending too much compute time on it and then if you only want to reveal one of those

41
00:03:11,280 --> 00:03:16,840
billions of things you have an overhead you reveal the one thing and then you have an overhead of

42
00:03:16,840 --> 00:03:22,920
you know some some fixed cost maybe like a kilobyte or something versus having an overhead

43
00:03:22,920 --> 00:03:26,620
of revealing a billion different things which is what you'd have to do in the traditional

44
00:03:26,620 --> 00:03:32,020
model of script where the way you handle branches is by having a bunch of if then statements and

45
00:03:32,020 --> 00:03:36,200
everybody's got to download the whole thing so in taproot we have that we have what's called the

46
00:03:36,200 --> 00:03:43,640
Tap tree, you've got all these different scripts you can have if you want to do like a five of 10 multi-sig for some reason.

47
00:03:44,620 --> 00:03:54,900
One way you can do that is by taking all of the 10 choose five possibilities that you might have as a number of a couple thousand, put them all into their own little tap branch.

48
00:03:55,040 --> 00:04:00,740
And then whichever five participants you happen to have at the time of spending, you take the branch corresponding to those.

49
00:04:00,740 --> 00:04:09,580
so this is an idea from 2010 2011 again like the very early days that eventually made it into tap

50
00:04:09,580 --> 00:04:16,340
root much much later of course and simplicity kind of came out i promise it's relevant to simplicity

51
00:04:16,340 --> 00:04:22,300
so the premise behind simplicity is what if we took that idea and we we really went to the extreme

52
00:04:22,300 --> 00:04:29,200
with it so one big thing that simplicity has well first off simplicity is the way that it fits into

53
00:04:29,200 --> 00:04:34,220
Bitcoin or the way that it fits into liquid is as basically a drop-in replacement for Bitcoin

54
00:04:34,220 --> 00:04:39,220
script or the drop-in replacement for tap script as it is now. So you've got a tap tree, you've got

55
00:04:39,220 --> 00:04:42,620
all these different scripts, and rather than using the existing Bitcoin script system, you use

56
00:04:42,620 --> 00:04:52,700
simplicity instead. And within simplicity, you have these branches and these conditionals. So if

57
00:04:52,700 --> 00:04:56,760
this person is available to sign, then check his signature. Otherwise, check this other signature.

58
00:04:56,760 --> 00:05:00,780
or if the coin is old, like past a certain age,

59
00:05:00,860 --> 00:05:02,700
then allow these backup keys to be used

60
00:05:02,700 --> 00:05:04,580
or whatever conditionals you might want.

61
00:05:05,560 --> 00:05:07,260
Then, okay, you've got these conditionals,

62
00:05:07,420 --> 00:05:09,580
you reveal whichever side that you actually take.

63
00:05:09,980 --> 00:05:10,500
That's cool.

64
00:05:10,660 --> 00:05:11,840
There's some efficiency there.

65
00:05:12,840 --> 00:05:15,120
Simplicity goes one step further.

66
00:05:15,800 --> 00:05:20,140
And I says, well, conditionals are one way

67
00:05:20,140 --> 00:05:24,640
of composing two pieces of code or two programs, right?

68
00:05:24,640 --> 00:05:28,480
You've got some sort of flag, something that makes you decide what to do.

69
00:05:28,540 --> 00:05:29,980
And you've got these two things that you might do.

70
00:05:30,280 --> 00:05:31,560
And based on your flag, you pick one.

71
00:05:32,920 --> 00:05:36,220
And you can compose things in other ways.

72
00:05:36,600 --> 00:05:38,040
You could say, I've got these two programs.

73
00:05:38,100 --> 00:05:39,280
I want to run them both in a row.

74
00:05:39,920 --> 00:05:41,340
Bitcoin script is really good at this.

75
00:05:41,460 --> 00:05:43,000
It's what's called a concatenative language.

76
00:05:43,220 --> 00:05:44,060
You have a program.

77
00:05:44,420 --> 00:05:45,000
You run it.

78
00:05:45,120 --> 00:05:47,260
You just stick the other program right after and you run them.

79
00:05:47,400 --> 00:05:48,320
You run them in order.

80
00:05:49,440 --> 00:05:54,040
You might compose them by running both of your programs in parallel.

81
00:05:54,040 --> 00:05:57,620
like on the same input and then somehow you combine their output.

82
00:05:57,760 --> 00:05:59,400
So there's a couple other things you might do.

83
00:05:59,760 --> 00:06:05,700
And it turns out that you can start with two different programs.

84
00:06:06,340 --> 00:06:07,480
One of them does nothing.

85
00:06:08,040 --> 00:06:09,960
It takes an arbitrary input and throws it away.

86
00:06:10,540 --> 00:06:11,560
And the other does nothing.

87
00:06:11,800 --> 00:06:13,980
It takes the arbitrary input and just passes it along.

88
00:06:14,720 --> 00:06:17,620
And you take those two programs, arbitrarily many copies of them,

89
00:06:17,820 --> 00:06:21,140
and you compose them with each other and other compositions

90
00:06:21,140 --> 00:06:23,220
and you can build up any computation.

91
00:06:24,040 --> 00:06:32,200
This is something called the sequent calculus, if you're into computer science, like historical computer science even.

92
00:06:32,900 --> 00:06:38,360
It turns out you can build any computation just using these two basic functions and these combinators.

93
00:06:38,820 --> 00:06:51,080
And that's the premise behind simplicity, is that rather than having an opcode-based language where you have in Bitcoin script, you know, 70 or 80 opcodes, they all do different things.

94
00:06:51,080 --> 00:06:57,300
most of them uh the bulk of them just push things onto the stack but then there are others that can

95
00:06:57,300 --> 00:07:02,360
duplicate items there are others that can compare them to for uh to each other compare them to true

96
00:07:02,360 --> 00:07:08,380
or false uh do branches based on them uh and then there's a collection of five or six that do kind

97
00:07:08,380 --> 00:07:14,780
of cryptography right there's there's ones for four different kinds of hashes that are built into

98
00:07:14,780 --> 00:07:21,060
bitcoin script there's one that checks a signature there's one that checks a multi-signature and

99
00:07:21,060 --> 00:07:24,840
And Taproot is tweaked a little bit, but essentially it's checking a multi-signature.

100
00:07:25,680 --> 00:07:29,240
And then there are a couple variants of these.

101
00:07:29,700 --> 00:07:31,260
There are things for lock times.

102
00:07:31,760 --> 00:07:33,060
And that's pretty much it, right?

103
00:07:33,460 --> 00:07:42,240
But the whole premise is that you have these built-in, the small set of built-in, pretty complicated functionality that are all one opcode.

104
00:07:42,640 --> 00:07:50,660
And then you can combine these in various ways by pushing and pulling things from the stack of data that you can also kind of insert stuff on.

105
00:07:50,660 --> 00:07:52,020
And that's how you build programs.

106
00:07:53,180 --> 00:07:56,660
And there are a few problems with this model.

107
00:07:57,560 --> 00:08:04,880
One is, as I mentioned, if you're trying to do conditionals, if you're trying to do if statements, then you wind up having to write a whole ton of code.

108
00:08:06,000 --> 00:08:07,580
Well, you always have to write a whole bunch of code.

109
00:08:07,900 --> 00:08:10,280
As a validator, you wind up having to download a whole bunch of code.

110
00:08:10,900 --> 00:08:15,680
So even code that doesn't even get executed, you've got to download it because your whole program is in a straight line.

111
00:08:15,680 --> 00:08:22,260
then another problem is that it's actually very difficult to reason formally about these things

112
00:08:22,260 --> 00:08:29,540
so if you've got a bitcoin script that is supposed to implement some kind of crazy business logic and

113
00:08:29,540 --> 00:08:35,660
stuff you ideally want some high assurance that it's going to do what you expect to the extent

114
00:08:35,660 --> 00:08:40,560
that you can specify what you expect right um and and certainly you want some assurance that it's

115
00:08:40,560 --> 00:08:45,040
not going to do like certain surprising things right the money won't move unless somebody signs

116
00:08:45,040 --> 00:08:52,440
off on it. The script has certain behavior until a certain time at which backup conditions become

117
00:08:52,440 --> 00:08:58,540
active. So those kind of things. And it's very hard to do this with Bitcoin script because the

118
00:08:58,540 --> 00:09:06,220
way that you translate your specification, again, I'm glossing over, I'm using the word

119
00:09:06,220 --> 00:09:11,660
specification in the interest of brevity. I'm not going to say what a formal specification is,

120
00:09:11,700 --> 00:09:14,800
but it's a thing you can make that describes exactly what a program should do.

121
00:09:15,040 --> 00:09:22,560
And to the extent you have a specification, to turn that into code in Bitcoin script is just you really got to do a whole bunch of ad hoc.

122
00:09:22,760 --> 00:09:26,000
Like, well, if I were a Bitcoin script interpreter, how would I do this?

123
00:09:26,120 --> 00:09:29,760
Well, I'm going to push this onto the stack and push another thing and compare them.

124
00:09:29,820 --> 00:09:32,860
And then I'm going to interpret this one as a public key and this other one as a signature.

125
00:09:33,160 --> 00:09:34,640
And then I'm going to swap some things.

126
00:09:34,640 --> 00:09:36,980
And I'm going to take the output of that, which is an opaque blob.

127
00:09:36,980 --> 00:09:38,740
But I know it's going to be either zero or one.

128
00:09:39,140 --> 00:09:40,940
And I'm going to move that to the alternate stack.

129
00:09:40,940 --> 00:09:41,640
So it's out of the way.

130
00:09:41,720 --> 00:09:42,620
And then I'm going to do this.

131
00:09:42,620 --> 00:09:53,160
You know, you're kind of jumping through a whole bunch of contortions, each of which is manipulating this arbitrarily sized stack of arbitrarily sized elements.

132
00:09:53,640 --> 00:10:09,040
And you're using these opcodes, which do kind of complicated things to stack and which themselves are defined in terms of what does what happens in script slash interpreter dot CPP in the Bitcoin core source code.

133
00:10:09,040 --> 00:10:16,080
versus if you were constructing a program by starting with these two dead simple functions

134
00:10:16,080 --> 00:10:20,900
the output nothing and the output what you give a function the the unit and the identity function

135
00:10:20,900 --> 00:10:27,160
and then combining them in these various ways and in total by the way in simplicity you've got

136
00:10:27,160 --> 00:10:31,680
those two basic functions and seven additional combinators that's it that's a whole language

137
00:10:31,680 --> 00:10:38,540
nine nine combinators okay plus an extra one we add for witnesses and uh plus an extra one

138
00:10:38,540 --> 00:10:45,600
called disconnect maybe we'll get into it okay 11 11 if i'm stretching um plus blockchain

139
00:10:45,600 --> 00:10:49,020
introspection but we can also actually forget about this blockchain introspection is

140
00:10:49,020 --> 00:10:53,680
even though formally we have to extend the language to support like how do you get what

141
00:10:53,680 --> 00:10:57,220
the current lock time is how do you get the current amount amounts how do you get the current output

142
00:10:57,220 --> 00:11:04,320
amounts etc all of those are very simple right they're just op codes op codes combinators that

143
00:11:04,320 --> 00:11:09,460
take no input and output whatever they're supposed to do so okay 11 basic combinators all of which

144
00:11:09,460 --> 00:11:16,420
are defined by like a single line of mathematical notation i've got a t-shirt i don't have it with

145
00:11:16,420 --> 00:11:20,980
me it's in the laundry but um you can it's so small you can print it on a t-shirt so we have

146
00:11:20,980 --> 00:11:26,260
these t-shirts with the entire definition of simplicity language printed on it and importantly

147
00:11:26,260 --> 00:11:34,080
it's not just simple in a uh kind of mathematical notation sentence it's simple in a formal sense

148
00:11:34,080 --> 00:11:40,240
that can be captured by things like the rock theorem proving assistant or the lean proof

149
00:11:40,240 --> 00:11:47,740
assistant or a language like idris or f sharp which has a type system that is capable of

150
00:11:47,740 --> 00:11:54,940
supporting formal proof and the idea here is that now if you well there are two big ideas

151
00:11:54,940 --> 00:12:00,000
come out of this so as a user of the language if you can specify what your program is supposed to do

152
00:12:00,000 --> 00:12:09,980
And then you can take your simplicity code, which itself is formally specified because it's defined in terms of these combinators that are simple enough to be fit to these specification languages.

153
00:12:10,560 --> 00:12:16,640
And then you can prove, you can produce a formal proof that your code matches the specification.

154
00:12:17,840 --> 00:12:20,540
And perhaps you don't have a full specification, right?

155
00:12:20,640 --> 00:12:22,180
Which is, it's difficult to create.

156
00:12:22,440 --> 00:12:24,620
But maybe you can at least say some specific things.

157
00:12:24,620 --> 00:12:32,140
You can say, at worst, no matter how this program executes, how much space will it take on my transaction?

158
00:12:32,620 --> 00:12:34,000
You can answer that very cheaply.

159
00:12:34,280 --> 00:12:35,920
And now you can bound your fee rates.

160
00:12:36,100 --> 00:12:41,040
You can do fee estimation very accurately for arbitrarily complicated programs.

161
00:12:41,720 --> 00:12:44,560
You can say, well, I don't really know.

162
00:12:45,000 --> 00:12:46,540
I'm some countersigner, right?

163
00:12:46,640 --> 00:12:47,480
I'm Blockstream.

164
00:12:47,620 --> 00:12:48,520
I'm the Blockstream app.

165
00:12:48,680 --> 00:12:49,440
I'm BitGo.

166
00:12:49,600 --> 00:12:50,600
I'm whatever I am.

167
00:12:50,600 --> 00:12:56,920
I don't know or care what this code is supposed to do, except that it shouldn't run without my signature.

168
00:12:57,440 --> 00:13:00,060
Okay, it's whatever the customer says, plus my signature.

169
00:13:00,600 --> 00:13:05,320
How can I formally prove that there's no possible way to spend this code without my signature?

170
00:13:05,500 --> 00:13:07,320
Well, yes, you can prove something like that.

171
00:13:08,180 --> 00:13:09,220
So that's one big thing.

172
00:13:09,480 --> 00:13:10,460
And that's huge for users.

173
00:13:11,500 --> 00:13:19,440
And the other thing is from an implementation standpoint, it means that when we're implementing our simplicity code, we can be assured that it's correct.

174
00:13:19,440 --> 00:13:25,340
so and we can be assured not only that's correct and that it matches the specification which we

175
00:13:25,340 --> 00:13:30,560
have that's super cool but also it's correct and that it matches our intuition so in bitcoin script

176
00:13:30,560 --> 00:13:36,220
there are at least once it used to be more frequent but like at least once every year or two

177
00:13:36,220 --> 00:13:41,220
there's some new novel behavior in bitcoin scripts that somebody will discover that as near as we can

178
00:13:41,220 --> 00:13:47,920
tell nobody knew before where if you kind of poke an opcode in exactly the right way then it will do

179
00:13:47,920 --> 00:13:55,100
something surprising and let me give an example of this kind of thing um the if opcode in bitcoin

180
00:13:55,100 --> 00:14:00,560
script it takes an input which is supposed to be true or false and in bitcoin script you don't have

181
00:14:00,560 --> 00:14:05,040
true or false you have kind of blobs of data okay so you might think well probably false you might

182
00:14:05,040 --> 00:14:09,580
represent by zero and and true you might represent by one is a natural way when you've got blobs of

183
00:14:09,580 --> 00:14:19,540
data well it uh it turns out that false is represented by the empty string okay and also

184
00:14:19,540 --> 00:14:27,960
zero and in fact also any arbitrarily long string of zeros except that also the leftmost zero is

185
00:14:27,960 --> 00:14:32,080
allowed to be a one okay that that specific bit doesn't count okay and that's what false means

186
00:14:32,080 --> 00:14:37,220
um oh and it can be arbitrarily long up to the 520 byte stack limit okay there's there's

187
00:14:37,220 --> 00:14:41,680
only one other opcode that takes arbitrarily sized inputs like that.

188
00:14:42,100 --> 00:14:45,020
And it's ifdup, which is the same, and not if.

189
00:14:45,120 --> 00:14:45,600
Okay, so it's three.

190
00:14:46,020 --> 00:14:48,580
All these if opcodes for something to take arbitrarily long inputs,

191
00:14:48,660 --> 00:14:51,920
even though nothing else will accept arbitrarily long inputs.

192
00:14:53,160 --> 00:14:55,660
Okay, so those are all the false values and everything else is true.

193
00:14:56,460 --> 00:14:57,880
So that's a little bit surprising, right?

194
00:14:57,880 --> 00:15:01,820
It means that if you could construct a public key or a signature

195
00:15:01,820 --> 00:15:06,500
that happens to have this wonky shape of all zeros and then a one at the end,

196
00:15:06,500 --> 00:15:11,240
then you could create a signature that evaluates to false,

197
00:15:11,240 --> 00:15:14,680
even though every real signature that somebody produces

198
00:15:14,680 --> 00:15:15,920
would evaluate to true.

199
00:15:16,960 --> 00:15:42,650
And it turns out that you can produce an ECDSA signature this way because there encoding rules that just force you to set other things to one You can produce a Schnorr signature this way that will parse as a Schnorr signature but it won validate because when we added Schnorr signatures to Bitcoin we designed them such that you cannot produce an arbitrary signature and then back compute what your keys and your message have to be

200
00:15:43,070 --> 00:15:46,370
In ECDSA, you can do that with something called public recovery, it turns out.

201
00:15:46,370 --> 00:15:48,790
So you can do like arbitrarily badly formed signatures.

202
00:15:49,750 --> 00:15:56,110
So I go into all those details to just kind of describe how insane Bitcoin script is because it was implemented the way it was.

203
00:15:56,390 --> 00:15:59,490
Just like kind of we need some extra functionality that's bolted on.

204
00:16:00,250 --> 00:16:08,370
And then there's kind of these like weird accidents of how certain opcodes interpret their input and they interact in crazy ways.

205
00:16:09,270 --> 00:16:14,350
And this is part of why it's so hard to get new things in the Bitcoin script, right?

206
00:16:14,350 --> 00:16:17,290
is that you can propose something like opcat,

207
00:16:17,550 --> 00:16:18,650
which is three lines of code.

208
00:16:18,730 --> 00:16:19,310
It's dead simple.

209
00:16:19,870 --> 00:16:21,770
But how do you know how it fits into the system?

210
00:16:21,850 --> 00:16:22,990
How do you know all of the behavior?

211
00:16:22,990 --> 00:16:25,990
It takes so long and so much mental energy

212
00:16:25,990 --> 00:16:29,690
to convince yourself that the simple-looking function

213
00:16:29,690 --> 00:16:31,230
is not going to do surprising things.

214
00:16:31,690 --> 00:16:34,190
And simplicity, by being the simple,

215
00:16:34,330 --> 00:16:35,370
formally specified model,

216
00:16:35,990 --> 00:16:37,030
saves you all of that effort.

217
00:16:37,690 --> 00:16:38,830
So I'll stop.

218
00:16:38,830 --> 00:16:47,370
so just building out not only comparing it to bitcoin script as it stands today but like i

219
00:16:47,370 --> 00:16:54,010
guess i i think many bitcoin developers would look at something like how ethereum's implemented

220
00:16:54,010 --> 00:16:58,790
script and it's it's created these sort of attack vectors that have been exploited

221
00:16:58,790 --> 00:17:05,770
over time and what i'm picking up from what you just described within bitcoin specifically like

222
00:17:05,770 --> 00:17:11,170
op codes or sort of this like modular way of doing it and i don't know if the intent of the

223
00:17:11,170 --> 00:17:15,750
design was like let's do this modularly so you can have something out of the box but as you

224
00:17:15,750 --> 00:17:21,610
described when you do that it's sort of clunky and you create um a burden for somebody trying

225
00:17:21,610 --> 00:17:26,130
to build so it's very hard to audit and know exactly what it's going to do and so simplicity

226
00:17:26,130 --> 00:17:34,910
just tries to be expressive yet finite um without having to have all that like complexity built in

227
00:17:34,910 --> 00:17:35,890
Is that correct?

228
00:17:36,550 --> 00:17:37,650
Yeah, exactly.

229
00:17:37,890 --> 00:17:38,990
And expressive yet finite.

230
00:17:39,250 --> 00:17:40,810
That's a good way to put it.

231
00:17:41,290 --> 00:17:45,230
So yeah, EVM took Bitcoin script and just bolted on everything we want to be able to do.

232
00:17:45,410 --> 00:17:49,650
Just bolted on to Bitcoin script, more or less, is roughly how EVM is structured.

233
00:17:50,690 --> 00:17:55,350
And then they realized that the Bitcoin stack language is not a good model for that.

234
00:17:55,430 --> 00:17:57,430
So they have what they call rich statefulness.

235
00:17:57,630 --> 00:18:00,090
We've got these series of global database lookups.

236
00:18:00,890 --> 00:18:02,970
So every contract has a bunch of code.

237
00:18:03,050 --> 00:18:03,690
It has variables.

238
00:18:03,690 --> 00:18:05,890
It can save and update and all this good stuff.

239
00:18:06,870 --> 00:18:12,050
But it is very difficult to reason about.

240
00:18:12,150 --> 00:18:17,950
They kind of inherited the difficulty in reasoning about Bitcoin script and in some ways made it much more complicated.

241
00:18:18,930 --> 00:18:31,230
They also did some kind of unnecessary, like in addition to extending it computationally, they also added this rich statefulness notion where you have these global key value lookups and everything becomes very stateful, which is hard to reason about.

242
00:18:31,510 --> 00:18:33,410
But then the big thing is this word finite.

243
00:18:33,690 --> 00:18:38,730
that you mentioned. So Ethereum for a while advertised itself as being Turing complete.

244
00:18:39,170 --> 00:18:44,090
And the idea behind that phrase is that a Turing complete language can do anything at all.

245
00:18:44,710 --> 00:18:51,250
A non-Turing complete language is kind of narrow and domain focused is the intuition, right? So as

246
00:18:51,250 --> 00:18:57,150
an example, right, a programming language like JavaScript or like Python is Turing complete.

247
00:18:57,150 --> 00:19:00,030
You can write anything that you can express, you can write in those languages.

248
00:19:00,030 --> 00:19:10,810
a language like html is not html can only uh produce uh draw web pages basically um some things

249
00:19:10,810 --> 00:19:15,390
would surprise you to learn that they're actually turing complete so css which is used to format

250
00:19:15,390 --> 00:19:19,730
web pages to set the colors and the widths and the styles and stuff it turns out css is turing

251
00:19:19,730 --> 00:19:23,870
complete because they're like conditional stylings that you can put in and the loops and stuff

252
00:19:23,870 --> 00:19:28,610
uh postscript which is a document formatting language that predates pdf is turing complete

253
00:19:28,610 --> 00:19:33,030
and I've exploited that to do some paper computer kind of projects.

254
00:19:34,590 --> 00:19:38,750
There's a whole pile of languages that really shouldn't be Turing complete,

255
00:19:38,910 --> 00:19:39,810
but accidentally are.

256
00:19:40,950 --> 00:19:43,670
And Ethereum more or less is on purpose.

257
00:19:44,090 --> 00:19:45,470
But there's a small caveat there.

258
00:19:46,010 --> 00:19:49,550
Strictly speaking, to be a Turing complete language,

259
00:19:49,990 --> 00:19:53,890
you need to have an infinite amount of memory

260
00:19:53,890 --> 00:19:57,810
and an unbounded amount of memory and an unbounded runtime.

261
00:19:57,810 --> 00:20:02,110
And in real life, of course, you're always bounded by, for one thing, by the constraints of your machine.

262
00:20:02,750 --> 00:20:06,130
And then on Ethereum, you're bounded by this quantity of gas.

263
00:20:06,870 --> 00:20:10,230
So you write an Ethereum transaction.

264
00:20:10,830 --> 00:20:15,550
You decide how long you expect the transaction's contract code to run for.

265
00:20:16,330 --> 00:20:20,910
And then you set a gas budget based on that, which is just actual Ether that you have to put up and you pay.

266
00:20:20,910 --> 00:20:27,690
and where ethereum runs into trouble or one one place where ethereum runs into trouble

267
00:20:27,690 --> 00:20:34,070
is that when you're trying to estimate how much gas your program's going to take you can't

268
00:20:34,810 --> 00:20:40,710
do that in general and so there's these whole uh kind of categories of smart contract bugs

269
00:20:40,710 --> 00:20:46,790
where it turns out that in order to call certain functions in a contract you have to use more gas

270
00:20:46,790 --> 00:20:49,750
and is available, which means that you effectively cannot call those.

271
00:20:50,010 --> 00:20:52,450
So there's functionality that you built into your script,

272
00:20:52,810 --> 00:20:56,610
but it turns out it's not accessible because of this external gas limitation.

273
00:20:57,730 --> 00:21:00,130
And that's kind of a problem for users.

274
00:21:00,550 --> 00:21:02,410
It turns out it's also a problem for validators

275
00:21:02,410 --> 00:21:09,010
because the way that you determine whether or not a script is valid,

276
00:21:09,010 --> 00:21:12,190
whether or not it's used, all of the gas that it's been allocated,

277
00:21:12,550 --> 00:21:13,250
is by running it.

278
00:21:13,770 --> 00:21:14,830
You start running the script.

279
00:21:14,830 --> 00:21:17,550
You figure out, did it run out of gas?

280
00:21:17,770 --> 00:21:19,110
If it did, then you got to stop.

281
00:21:20,150 --> 00:21:26,730
And you might think, okay, if you're a validator, you receive a transaction, it runs out of gas, it's invalid, so you throw it away, right?

282
00:21:27,050 --> 00:21:27,830
Well, you can't do that.

283
00:21:27,950 --> 00:21:29,090
That's a denial of service vector.

284
00:21:29,690 --> 00:21:31,410
You already did all the work to do that.

285
00:21:31,490 --> 00:21:37,970
So if somebody could just give you a program that ran for a minute and then failed, well, then you'd be churning away for a minute, right?

286
00:21:38,630 --> 00:21:40,770
And maybe you limit yourself per transaction, whatever.

287
00:21:40,770 --> 00:21:44,310
A bad guy gives you a million transactions that all take a microsecond.

288
00:21:44,310 --> 00:21:45,750
And now you still wasted a second.

289
00:21:46,690 --> 00:21:51,410
So in Ethereum, what happens is when you run out of gas, the transaction is still valid.

290
00:21:51,910 --> 00:21:52,990
You still pass it along.

291
00:21:53,070 --> 00:21:54,950
It winds up in the blockchain, but it doesn't do anything.

292
00:21:55,230 --> 00:21:56,270
It just burns your gas.

293
00:21:56,830 --> 00:22:03,650
And so there's this other category of kind of Ethereum failure modes where there are these transactions that wind up on the chain that don't do anything.

294
00:22:03,690 --> 00:22:05,150
They just burn gas and do nothing else.

295
00:22:05,450 --> 00:22:13,430
And these are almost certainly accidental because there's no reason for you to just burn gas the way that I'm describing.

296
00:22:14,390 --> 00:22:17,370
And the way that Bitcoin avoids this problem,

297
00:22:17,910 --> 00:22:19,790
in Bitcoin, if a transaction is invalid, it's invalid.

298
00:22:19,910 --> 00:22:20,590
It doesn't go on the chain.

299
00:22:21,170 --> 00:22:25,450
Is that in Bitcoin, there's kind of a neat trick we use,

300
00:22:25,850 --> 00:22:28,790
which is that every opcode takes one byte to encode.

301
00:22:29,370 --> 00:22:30,550
So Bitcoin script has no loops.

302
00:22:30,770 --> 00:22:32,950
So every opcode can be executed at most once.

303
00:22:33,030 --> 00:22:34,750
You can't go back and then redo stuff.

304
00:22:35,190 --> 00:22:36,690
Which means that if you see a byte,

305
00:22:36,690 --> 00:22:39,430
you know the absolute worst case,

306
00:22:39,550 --> 00:22:41,610
that byte represents a single opcode of work.

307
00:22:42,550 --> 00:22:48,890
And so you take the whole size of your transaction and you use that to swag how expensive that transaction will be.

308
00:22:49,310 --> 00:22:59,170
And then you look at the transaction's fee and you compute what's called the fee rate, which is how much did they pay per byte, or I should say per weight of the transaction because certain bytes count more than others.

309
00:23:00,090 --> 00:23:03,270
And that avoids this denial of service problem, basically.

310
00:23:03,270 --> 00:23:04,730
So you don't have a gas limit.

311
00:23:05,150 --> 00:23:08,010
What you have is the size of your transaction represents how much work it is.

312
00:23:08,450 --> 00:23:11,390
And then your fee, you just attach whatever fee is appropriate for that.

313
00:23:11,610 --> 00:23:14,370
And then miners and validators kind of order things,

314
00:23:14,490 --> 00:23:16,830
which has the highest fee per weight kind of thing.

315
00:23:17,570 --> 00:23:18,390
This is cool.

316
00:23:18,510 --> 00:23:19,470
This is pretty cool.

317
00:23:19,730 --> 00:23:22,670
But there's an obvious question then,

318
00:23:22,750 --> 00:23:23,570
well, what if we want to,

319
00:23:23,850 --> 00:23:25,110
surely we want to put loops

320
00:23:25,110 --> 00:23:27,410
and go to some way of doing this kind of stuff

321
00:23:27,410 --> 00:23:28,170
into Bitcoin, right?

322
00:23:28,250 --> 00:23:30,770
Are we just forbidden from ever having a way

323
00:23:30,770 --> 00:23:32,450
to execute an opcode more than once?

324
00:23:32,950 --> 00:23:34,350
Because then it would break this,

325
00:23:34,890 --> 00:23:37,870
how much the size of the transaction

326
00:23:37,870 --> 00:23:39,870
representing the computational cost kind of model.

327
00:23:39,870 --> 00:23:46,430
um and in ethereum the solution was gas they're like okay we're just going to have to throw away

328
00:23:46,430 --> 00:23:49,930
the size size represents computation model and we're going to have to do this this unfortunate

329
00:23:49,930 --> 00:24:00,430
thing in simplicity we have a much cooler solution which is that you can as a validator

330
00:24:00,430 --> 00:24:06,330
you can scan through the program one byte at a time technically one bit at a time and you can

331
00:24:06,330 --> 00:24:12,010
determine the maximum execution cost how much cpu is this going to use how much memory is it going

332
00:24:12,010 --> 00:24:18,170
to use statically just like a single pass through the program and the program this is kind of cool

333
00:24:18,170 --> 00:24:25,170
you can have a sub program or an op code however you want it to think of it that runs exponentially

334
00:24:25,170 --> 00:24:30,850
often so you encode this bit of your program once and when you actually run the script it gets

335
00:24:30,850 --> 00:24:36,550
evaluated you know like a trillion times you can totally do that in simplicity and your validators

336
00:24:36,550 --> 00:24:41,490
will scan through the program they see your little bit they evaluate it once they say oh

337
00:24:41,490 --> 00:24:45,470
that cost a trillion because it gets executed a trillion times and moves on and then eventually

338
00:24:45,470 --> 00:24:48,890
it was you know the validator will say you know what a trillion is a lot you can't you can't fit

339
00:24:48,890 --> 00:24:55,650
a trillion opcodes into into a single block kind of thing um but importantly even though you have

340
00:24:55,650 --> 00:25:02,590
this kind of arbitrary blow up between the size of your program and the actual cost,

341
00:25:02,910 --> 00:25:04,770
you still only have to scan the small one.

342
00:25:04,830 --> 00:25:07,670
You have to scan the bytes of the program to figure out what that cost is.

343
00:25:08,170 --> 00:25:09,470
And we call it a static analysis.

344
00:25:09,650 --> 00:25:10,690
We call it a static bound.

345
00:25:11,410 --> 00:25:15,650
And what that means is that we retain the Bitcoin ability for a validator to just look

346
00:25:15,650 --> 00:25:19,530
at the transaction and immediately compute what the fee rate is and whether it should

347
00:25:19,530 --> 00:25:23,270
be prioritized or whether it's never going to get into a block and we should just drop

348
00:25:23,270 --> 00:25:25,290
it without ever having to execute the code.

349
00:25:25,650 --> 00:25:31,770
And we do that while still getting this arbitrary amount of execution.

350
00:25:33,770 --> 00:25:49,770
And the reason this is possible is because what you're encoding in your program is actually a composition of all of these basic kind of building blocks of computer science, none of which are a loop, importantly.

351
00:25:50,450 --> 00:25:54,110
None of which are a loop and none of which are a go-to, but it turns out you can still get arbitrary.

352
00:25:55,650 --> 00:26:02,310
arbitrary computations this way and for each of those combinators as a validator you can say like

353
00:26:02,310 --> 00:26:07,670
well okay if this is a parallel composition i'm running two things in parallel the cpu cost is

354
00:26:07,670 --> 00:26:12,530
going to be you know the left guy plus the right guy the memory cost will be the maximum of either

355
00:26:12,530 --> 00:26:20,250
one of them that can you kind of do that kind of analysis over and over now people who are

356
00:26:20,250 --> 00:26:27,510
CS nerds or maybe just listening to me far too closely might be kind of suspicious about my claim

357
00:26:27,510 --> 00:26:34,070
that you can do loops, that you can do an arbitrary computation in simplicity,

358
00:26:34,490 --> 00:26:40,270
and that you don't have a looping construct or a go-to construct. And I'll briefly say something

359
00:26:40,270 --> 00:26:45,930
about that, which is that there's actually another form of composition, which is not

360
00:26:45,930 --> 00:26:51,590
sequential or conditional or parallel or these kind of basic things called recursive composition.

361
00:26:52,170 --> 00:26:56,290
And that's where you have a function that's able to call itself and basically do a loop, right?

362
00:26:56,370 --> 00:26:56,790
Go back.

363
00:26:57,630 --> 00:27:02,190
So simplicity does support this through this extra combinator we call disconnect.

364
00:27:02,790 --> 00:27:10,330
But it supports it in kind of a clever way where in principle, you can put an arbitrary

365
00:27:10,330 --> 00:27:15,650
number of loops into your program at the time that you define it, at the time that you

366
00:27:15,650 --> 00:27:20,810
construct your address that represents your program code. But when you actually go to spend it,

367
00:27:21,310 --> 00:27:26,330
you are required to unroll the loop however many times you actually execute it. So Disconnect

368
00:27:26,330 --> 00:27:32,130
Commender allows you to attach arbitrarily many copies of code, but you have to attach them as

369
00:27:32,130 --> 00:27:37,610
spending time. And then if they are actual literal copies, one after the other, you don't have to

370
00:27:37,610 --> 00:27:43,410
write the same code 20 times in a row. The encoding of simplicity will collapse it into a

371
00:27:43,410 --> 00:27:48,590
single copy but the static bound they're still able to see that it's executed 20 times and assign

372
00:27:48,590 --> 00:27:55,550
at a cost of 20 so in the end what hits the blockchain is in fact finite is in fact built up

373
00:27:55,550 --> 00:28:03,850
what hits the blockchain essentially does not have this recursive um uh way of combining of composing

374
00:28:03,850 --> 00:28:08,670
computations in the end when you put it on the chain you have to enroll it and then it's just

375
00:28:08,670 --> 00:28:13,390
regular old composition where you're running one thing after the other so you kind of get the best

376
00:28:13,390 --> 00:28:19,230
of both worlds where at commitment time when you're writing your program and generating addresses

377
00:28:19,230 --> 00:28:26,290
then you can do arbitrary unbounded computations but if you want to spend it on the blockchain

378
00:28:26,290 --> 00:28:31,310
you have to do the computation and it has to terminate and you have to bound how much that

379
00:28:31,310 --> 00:28:36,070
how long that computation took in order to put it on the chain otherwise you can't even code the

380
00:28:36,070 --> 00:28:40,670
results like it's just like a nonsensical transaction so it's a user transaction creator

381
00:28:40,670 --> 00:28:42,030
get this full expressivity,

382
00:28:42,530 --> 00:28:44,350
but validators don't have to deal

383
00:28:44,350 --> 00:28:45,250
with that expressivity,

384
00:28:45,930 --> 00:28:48,210
which they don't need, right?

385
00:28:48,250 --> 00:28:49,370
Like a validator knows

386
00:28:49,370 --> 00:28:51,950
if your transaction is going untamed,

387
00:28:52,230 --> 00:28:53,650
your program has to succeed, right?

388
00:28:53,650 --> 00:28:54,810
It has to be valid, right?

389
00:28:54,850 --> 00:28:56,130
That's like the one thing.

390
00:28:56,270 --> 00:28:57,510
Validators' job is not to like

391
00:28:57,510 --> 00:28:58,250
run the computation

392
00:28:58,250 --> 00:28:59,310
and see what happens, right?

393
00:28:59,330 --> 00:29:00,470
Their job is to validate

394
00:29:00,470 --> 00:29:02,610
that you did the computation

395
00:29:02,610 --> 00:29:03,730
and the right thing happened, right?

396
00:29:03,990 --> 00:29:05,030
And as cheaply,

397
00:29:05,350 --> 00:29:06,650
they want to do that as cheaply

398
00:29:06,650 --> 00:29:07,810
and as predictably as possible.

399
00:29:08,990 --> 00:29:09,310
So...

400
00:29:10,670 --> 00:29:28,150
Yeah, so in short, you're basically just guaranteeing expressiveness with formal safety guarantees that don't exist elsewhere and seems like has been a big problem needed to be solved for these particular types of systems.

401
00:29:28,810 --> 00:29:32,650
Yeah, absolutely. Thank you for zooming out so much. That's exactly it, right?

402
00:29:32,650 --> 00:29:38,870
all of these elaborate constructions i'm describing have that goal of how do we have something that

403
00:29:38,870 --> 00:29:44,070
you can formally reason about where when you're when you're implementing the system you want to

404
00:29:44,070 --> 00:29:47,770
know that it's doing something predictable that's not going to blow up people's computers or crash

405
00:29:47,770 --> 00:29:52,410
when you're writing code you want to know that your code that you're writing does what you expect

406
00:29:52,410 --> 00:29:57,170
it to and when you're running a full node when you're validating this stuff you want to know

407
00:29:57,170 --> 00:30:02,630
that very quickly you can figure out the cost of this validation and you can charge the transaction

408
00:30:02,630 --> 00:30:07,550
appropriately and with simplicity we've managed to do this in a model where we get the full

409
00:30:07,550 --> 00:30:13,870
expressivity of something like evm or or chialisp or any of these languages that are out there that

410
00:30:13,870 --> 00:30:21,090
you do arbitrary computations while preserving these goals yeah and i think this has been a big

411
00:30:21,090 --> 00:30:31,430
a big theme in bitcoin for the better part of eight years now or nine ten years since

412
00:30:31,430 --> 00:30:36,670
Ethereum launch specifically, which is like Bitcoin is an extremely important project.

413
00:30:36,670 --> 00:30:39,430
We're trying to separate money in states.

414
00:30:39,470 --> 00:31:02,120
And at this point it a two point two two point three trillion dollar market and is incredibly important that we make sure that the system doesn fail And so with that in mind we have to make sure we build things correctly so that protocol the network can stay sufficiently distributed and it actually achieves the goals it set out to

415
00:31:02,120 --> 00:31:09,240
And during that period, you had Ethereum, other smart contracting networks come to the market and say, look at us.

416
00:31:09,500 --> 00:31:10,460
We're doing it better.

417
00:31:10,840 --> 00:31:11,400
We're faster.

418
00:31:11,500 --> 00:31:12,740
We have more features than Bitcoin.

419
00:31:13,480 --> 00:31:19,500
And all the while, Bitcoiners, myself included, and I truly do believe this, it seems like it's beginning to manifest,

420
00:31:20,200 --> 00:31:21,840
have been saying it will eventually come to Bitcoin.

421
00:31:21,940 --> 00:31:23,120
We're just going to do it the right way.

422
00:31:23,260 --> 00:31:27,780
And it seems like that's what you guys have been working on in Simplicity for a decade is doing it the right way.

423
00:31:28,340 --> 00:31:28,480
Yeah.

424
00:31:28,480 --> 00:31:28,860
Yeah.

425
00:31:29,400 --> 00:31:29,800
Everything.

426
00:31:29,800 --> 00:31:34,940
everything ethereum added everything these other chains added right comes with some trade-offs

427
00:31:34,940 --> 00:31:40,100
and some of those are more reasonable than others right so a lot of these things have much faster

428
00:31:40,100 --> 00:31:46,700
blocks than bitcoin and i think if bitcoin had been developed if in 2008 somehow satoshi had

429
00:31:46,700 --> 00:31:52,060
compact blocks and mini sketch and all of this like peer-to-peer propagation tech that we have

430
00:31:52,060 --> 00:31:56,460
today probably we would have faster blocks right there's certainly a trade-off between fast blocks

431
00:31:56,460 --> 00:31:57,300
and decentralization.

432
00:31:58,120 --> 00:32:03,300
And it's not inherently obvious that the 10-minute block

433
00:32:03,300 --> 00:32:04,820
was the perfect optimal thing.

434
00:32:05,300 --> 00:32:07,120
But then there are other things that are just clearly

435
00:32:07,120 --> 00:32:08,760
very, very bad trade-offs, right?

436
00:32:09,440 --> 00:32:14,700
And Ethereum introducing this super expressive language

437
00:32:14,700 --> 00:32:18,360
with the trade-offs they made where validators have,

438
00:32:18,440 --> 00:32:20,080
where you have to be able to put invalid transactions

439
00:32:20,080 --> 00:32:22,580
into the chain because validators can't determine

440
00:32:22,580 --> 00:32:24,360
whether or not it's valid without executing

441
00:32:24,360 --> 00:32:25,720
an arbitrarily long piece of code.

442
00:32:25,720 --> 00:32:32,220
and where once a transaction is once they've even validated a transaction they can't know that it

443
00:32:32,220 --> 00:32:36,460
will stay valid until it's in a block because in ethereum it's possible to reorder transactions in

444
00:32:36,460 --> 00:32:40,920
ways that made previously valid transactions become valid there's another reason that that

445
00:32:40,920 --> 00:32:47,480
um that you have to just put bad transactions into blocks is because um you need you have to

446
00:32:47,480 --> 00:32:52,700
charge the person who created the transaction and even if it appears while the transaction is on the

447
00:32:52,700 --> 00:32:57,520
peer-to-peer network that it was legit. Maybe it turns out not to be legit because things changed.

448
00:32:59,040 --> 00:33:03,300
That's a terrible trade-off, right? We would never have accepted an extension to Bitcoin that

449
00:33:03,300 --> 00:33:07,200
added some sort of looping facility with these kind of problems. We would never have accepted

450
00:33:07,200 --> 00:33:12,980
an extension to Bitcoin that allowed you to introspect a transaction in a way where if the

451
00:33:12,980 --> 00:33:18,520
transaction appeared in a block in a different order or was reorgged back a block or two,

452
00:33:18,520 --> 00:33:22,620
then it would suddenly become invalid and invalidate all the work that people did to

453
00:33:22,620 --> 00:33:28,660
cash the transaction validity um we would never accept any change to bitcoin that changed what we

454
00:33:28,660 --> 00:33:34,200
call monotonicity once the transaction is valid it stays valid forever with one exception of it

455
00:33:34,200 --> 00:33:39,080
might get double spent and then the double spend might might wind up in the chain um but that

456
00:33:39,080 --> 00:33:42,860
doesn't require rechecking the scripts or anything that just requires knowing which inputs it spends

457
00:33:42,860 --> 00:33:44,220
and keeping an eye on them.

458
00:33:45,780 --> 00:33:48,120
Those are terribly, obviously terrible trade-offs.

459
00:33:48,500 --> 00:33:52,220
We would never accept an extension to Bitcoin

460
00:33:52,220 --> 00:33:53,400
that had rich statefulness,

461
00:33:53,560 --> 00:33:57,040
that had a global key value store of all this contract code

462
00:33:57,040 --> 00:34:00,400
so that anybody could call an arbitrary piece of contract

463
00:34:00,400 --> 00:34:02,700
and then call an arbitrary function in that.

464
00:34:03,040 --> 00:34:05,660
And that function itself had this map that you can update

465
00:34:05,660 --> 00:34:08,360
so that validating a single Bitcoin transaction

466
00:34:08,360 --> 00:34:10,940
requires an unpredictably deep dive

467
00:34:10,940 --> 00:34:16,300
into this massive terabyte-sized database that you've got to go through.

468
00:34:16,740 --> 00:34:20,440
And so running a full archival node on Ethereum,

469
00:34:21,860 --> 00:34:24,760
well, Jameson Lopp, I think, did some work trying to do this

470
00:34:24,760 --> 00:34:29,540
five or six years ago, and it was, I don't know that he succeeded.

471
00:34:29,720 --> 00:34:33,300
This is definitely worth looking up, and things have gotten even worse since then.

472
00:34:33,300 --> 00:34:37,120
That led to a situation where nobody is running a full Ethereum node,

473
00:34:37,120 --> 00:34:51,920
And where there's a culture of if your node kind of like gets bumped off of the network because you, you know, failed to validate something and then somehow you just got off the train, then you've got to just like restart your node and kind of trust the state that's coming into you and then carry on from there kind of thing.

474
00:34:52,460 --> 00:34:58,460
So those kind of things I would say are obviously bad tradeoffs that like Bitcoin would never accept, right?

475
00:35:00,500 --> 00:35:06,760
And as a historical thing, it's kind of interesting to me that Ethereum took so many of those choices, right?

476
00:35:07,120 --> 00:35:09,480
Not just like, could we have faster blocks?

477
00:35:09,580 --> 00:35:10,660
Could we have bigger blocks?

478
00:35:10,780 --> 00:35:14,400
What if we used PubQ recovery in certain places?

479
00:35:14,600 --> 00:35:15,820
What if we structured our transactions?

480
00:35:16,280 --> 00:35:18,920
Even what if we had accounts versus UTXOs?

481
00:35:19,780 --> 00:35:21,260
I think you can make arguments for both.

482
00:35:21,360 --> 00:35:23,340
I think they were clearly wrong about that,

483
00:35:23,380 --> 00:35:24,760
but it's just a much more subtle thing.

484
00:35:25,520 --> 00:35:27,160
But the rich statefulness and the loops

485
00:35:27,160 --> 00:35:29,460
and the inability to cash transaction validity

486
00:35:29,460 --> 00:35:35,600
is either just fundamentally complete non-starters for Bitcoin.

487
00:35:35,600 --> 00:35:40,520
right and that's that's a big part but but without them it's so hard to do anything right which is

488
00:35:40,520 --> 00:35:48,840
why here we are in in 2025 um debating opcat and also debating what kind of crazy programs can you

489
00:35:48,840 --> 00:35:53,340
build just as a concatenation opcode and by like abusing it to like fold back in on itself and like

490
00:35:53,340 --> 00:36:00,000
run through the signature it's like it's crazy the kind of hacks that we have when um kind of to

491
00:36:00,000 --> 00:36:03,920
somebody looking from the outside they'd be like guys this is crazy just put some freaking arithmetic

492
00:36:03,920 --> 00:36:07,900
into your blockchain so people can do math already and do some computations and then

493
00:36:07,900 --> 00:36:13,660
move on with your lives right um it's hard it turns out it's hard to preserve scalability and

494
00:36:13,660 --> 00:36:19,380
decentralization um it's hard to preserve the properties that bitcoin has that make it scalable

495
00:36:19,380 --> 00:36:25,680
and decentralized while getting this extra expressivity yeah and you said the word scalable

496
00:36:25,680 --> 00:36:32,660
there so this is obviously uh gone live on liquid's mainnet which is a federated side chain

497
00:36:32,660 --> 00:36:39,160
blockchain has been running for almost a decade now too and let's jump into that like the really

498
00:36:39,160 --> 00:36:45,820
exciting stuff which is like the use cases that is this unlocks whether it's covenants and vaults

499
00:36:45,820 --> 00:36:54,060
uh on-chain financial primitives programmable delegation like there's seems to be in endless

500
00:36:54,060 --> 00:37:00,540
amount of potential applications that can be built on simplicity so let's jump in why liquid

501
00:37:00,540 --> 00:37:06,600
how does it work on liquid specifically compared to how it could potentially work on bitcoin at the

502
00:37:06,600 --> 00:37:12,600
protocol level if it ever does in the future maybe we can talk about if that's even a good idea

503
00:37:12,600 --> 00:37:19,740
um and what do you expect to see get built sure so uh so liquid for people who don't know this

504
00:37:19,740 --> 00:37:24,760
is a side chain that was developed by blockstream and that has been running yeah since since 2018

505
00:37:24,760 --> 00:37:30,380
october 2018 was was our launch date uh liquid is what's called a federated side chain

506
00:37:30,540 --> 00:37:41,620
They're a set of 15 mutually distrusting parties spread across the globe who together, every minute, 11 of those 15 come together to sign a new liquid block.

507
00:37:42,980 --> 00:37:45,620
And so liquid is a sidechain.

508
00:37:45,900 --> 00:37:55,760
So in addition to being this kind of blockchain that has this federated signing model, it's a sidechain, meaning that it's possible to move Bitcoin from the Bitcoin network onto liquid and move it back.

509
00:37:55,760 --> 00:38:06,960
And the mechanism by which you do that is a little disappointing, I would say, which is that you literally transfer the Bitcoin into custody of the 15-member federation.

510
00:38:07,120 --> 00:38:12,080
And then any 11 of those are responsible for moving the money back when you request it on the Liquid blockchain.

511
00:38:12,280 --> 00:38:14,580
So that's how the pay-in and pay-out mechanism work there.

512
00:38:15,820 --> 00:38:24,380
And the Liquid has also made a couple trade-offs that are no-goes for Bitcoin, for sure.

513
00:38:24,380 --> 00:38:25,780
So one is a federated model, right?

514
00:38:25,800 --> 00:38:31,460
That's just completely alien to the Bitcoin proof of work based security model.

515
00:38:31,980 --> 00:38:40,040
And everybody has, well, everything comes down to proof of work ultimately in Bitcoin, as well as not your keys, not your coins, right?

516
00:38:40,080 --> 00:38:47,180
So even if like miners all shut down, if you just held on to your UTXOs that you couldn't spend, even if you didn't want to, nobody else can take them, right?

517
00:38:47,260 --> 00:38:48,360
Which is kind of nice.

518
00:38:50,400 --> 00:38:51,160
So that's one.

519
00:38:51,160 --> 00:39:16,140
So another trade-off that Liquid made that Bitcoin never would is that it has multiple assets that are native on the chain. And the reason Liquid can do that is because Liquid has block signers who are not being paid in kind. So Bitcoin, by using miners that are paid by new Bitcoins, needs, in order to function, in order to have the long-term economic properties that it has, Bitcoin needs to be the asset on the Bitcoin blockchain.

520
00:39:16,140 --> 00:39:28,740
You can't have economic activity that's happening in other assets, at least not to a significant degree that would rival Bitcoin, because then your minor incentives suddenly are not aligned with always extending the longest chain.

521
00:39:29,360 --> 00:39:31,300
Liquid doesn't have that problem because it has block centers.

522
00:39:32,280 --> 00:39:44,640
Liquid, by virtue of being smaller and by virtue of being developed by a block chain, is something that we can do cool crypto experiments on much faster than we can on Bitcoin.

523
00:39:44,640 --> 00:39:46,320
And here's really, you said, why Liquid?

524
00:39:46,740 --> 00:39:47,320
Why Liquid?

525
00:39:47,400 --> 00:39:49,480
We know Liquid and we can do stuff fast on Liquid.

526
00:39:50,420 --> 00:39:58,960
So Liquid historically has been kind of a demo for many things that wound up on Bitcoin eventually.

527
00:39:59,340 --> 00:40:05,140
So Liquid, or I should say the precursor to Liquid, what we called Elements Alpha, had SegWit before Bitcoin had SegWit.

528
00:40:05,880 --> 00:40:10,260
And actually it turned out, the fun history there, that the version of SegWit in Elements was terrible.

529
00:40:10,420 --> 00:40:11,700
It would have been a hard forking change.

530
00:40:11,780 --> 00:40:13,140
It had all these bad properties and stuff.

531
00:40:13,800 --> 00:40:16,880
And then Luke Dasher looked at this and he said, wait, we could tweak this.

532
00:40:16,940 --> 00:40:19,040
And then it's a soft fork and then we could do this way better thing.

533
00:40:19,640 --> 00:40:27,900
And then James and Lopp and Sipa and all these people kind of pulled together and produced SegWit on Bitcoin, which we all know and love.

534
00:40:28,200 --> 00:40:29,540
And then we pulled it back into Liquid.

535
00:40:29,920 --> 00:40:31,140
Yeah, that one's way better than ours.

536
00:40:31,280 --> 00:40:32,940
So that was a cool back and forth.

537
00:40:33,380 --> 00:40:41,640
Liquid also had check sequence verify, which is how you do lock time checks and script before Bitcoin did.

538
00:40:41,640 --> 00:40:47,980
liquid has what's called confidential transactions which are a way of hiding the amounts and the asset

539
00:40:47,980 --> 00:40:54,640
types of all of your inputs and outputs in a transaction which gets you a pretty big part of

540
00:40:54,640 --> 00:41:02,080
the kind of privacy that monero or or zcash have without the the worst of the scalability trade-offs

541
00:41:02,080 --> 00:41:07,140
and there there's there's an uncomfortable privacy uh scalability trade-off that liquid

542
00:41:07,140 --> 00:41:14,020
show the different place that that wound up being pulled into monero for example um and uh and so now

543
00:41:14,020 --> 00:41:21,760
we're working on simplicity right and so we took simplicity the nine or eleven if you want

544
00:41:21,760 --> 00:41:27,000
combinators that uh that define the language we added a few extra bolt-on facilities for

545
00:41:27,000 --> 00:41:31,340
introspecting liquid transactions which uh atsy would be much harder than doing the same thing

546
00:41:31,340 --> 00:41:36,040
on Bitcoin. And then we deployed it there as a tap leaf version. So Liquid has taproot.

547
00:41:39,080 --> 00:41:42,460
Frustratingly, Bitcoin got taproot before Liquid did. And we were like, internally,

548
00:41:42,640 --> 00:41:46,520
everything's harder on Liquid because we have multiple assets and we have constant

549
00:41:46,520 --> 00:41:51,240
transactions and stuff. But that one, we were like, internally, it was a race in our hearts.

550
00:41:51,340 --> 00:41:56,640
In my heart, it was a race and we lost. But okay, we have taproot on Liquid now.

551
00:41:56,640 --> 00:42:06,360
So within a taproot output on Liquid, you can choose for every script, you choose either to use scripts or to use simplicity.

552
00:42:07,800 --> 00:42:09,680
And there you go.

553
00:42:09,760 --> 00:42:10,660
That's how it fits in.

554
00:42:11,320 --> 00:42:15,780
And the tradeoffs that we make before I jump into use cases, right?

555
00:42:15,860 --> 00:42:19,560
So why do we do that on Liquid and why couldn't we just turn around and do it on Bitcoin?

556
00:42:20,220 --> 00:42:24,620
Well, simplicity is an entire replacement for the script interpreter, right?

557
00:42:24,620 --> 00:42:30,720
It's this giant blob of C code, which is several thousand lines at least.

558
00:42:31,440 --> 00:42:38,200
It has some cool, complicated things where it identifies programs by these Merkle roots.

559
00:42:38,360 --> 00:42:42,940
It builds this abstract tree of how your program is constructed and combined at a smaller thing.

560
00:42:43,700 --> 00:42:44,700
It computes these Merkle roots.

561
00:42:44,880 --> 00:42:48,100
It has a type system and a type inference system.

562
00:42:48,540 --> 00:42:54,120
It has this notion of sharing that allows you to collapse repeated pieces of code into one.

563
00:42:54,120 --> 00:43:05,700
And it has these new consensus rules related to how sharing has to be enforced to ensure that certain kinds of transaction malleability are eliminated and certain kinds of denial of service vectors are eliminated.

564
00:43:06,540 --> 00:43:12,980
And the whole thing is just a very new – there's a lot of code that's like a really core piece of consensus.

565
00:43:13,280 --> 00:43:15,460
And it's a new model and it's a scary thing.

566
00:43:16,340 --> 00:43:23,580
And we wouldn't even – we'd be laughed out of the room if we even proposed that for Bitcoin without having some real-world usage kind of thing.

567
00:43:23,580 --> 00:43:30,180
whereas on liquid we can just kind of do it right um we got to get we got to get approval from the

568
00:43:30,180 --> 00:43:37,020
15 functionaries they all all these participants think that's a pretty cool thing um liquid well

569
00:43:37,020 --> 00:43:41,120
we have very high assurance that simplicity is correct and it's not going to like lose money

570
00:43:41,120 --> 00:43:46,780
and it's not going to crash the system or something um certainly nobody is at risk from simplicity who

571
00:43:46,780 --> 00:43:51,600
isn't directly using it right which is nice that would also be true on bitcoin but uh but on bitcoin

572
00:43:51,600 --> 00:43:55,780
there's always this worry that like what if it turns out that you can like crash nodes with it

573
00:43:55,780 --> 00:44:04,500
or something and liquid just by nature of it's federated like that is not i really like it's not

574
00:44:04,500 --> 00:44:08,640
going to happen it's like not i'm not suggesting that we would deploy something where it's possible

575
00:44:08,640 --> 00:44:13,440
but if it did we would pick up the piece of the move on and on liquid we can kind of do that

576
00:44:13,440 --> 00:44:19,980
because it's a federated system um and because ultimately all the coins are are uh backed by

577
00:44:19,980 --> 00:44:24,340
bitcoins and and real bitcoins that are not moving on the bitcoin chain and stuff in a way that

578
00:44:24,340 --> 00:44:31,280
bitcoin just can't right you you can't you can never never risk bitcoin doing that so um so we

579
00:44:31,280 --> 00:44:39,580
launched it on liquid and in our kind of long-term vision of getting simplicity into into bitcoin

580
00:44:39,580 --> 00:44:46,280
into real bitcoin users hands and like um getting out into the real world outside of liquid um

581
00:44:46,280 --> 00:44:48,940
So this is a place, it's deployed on a blockchain.

582
00:44:49,340 --> 00:44:54,160
This got some kind of neat asset features, which are useful for demonstrating simplicity.

583
00:44:54,860 --> 00:44:58,080
And we can start to learn how simplicity behaves on the blockchain.

584
00:44:59,040 --> 00:45:04,480
So as you hinted at, simplicity includes covenant support.

585
00:45:04,840 --> 00:45:08,780
It includes the ability to look at transactions and make decisions based on the shape of your transactions.

586
00:45:09,100 --> 00:45:09,840
So that's pretty cool.

587
00:45:09,920 --> 00:45:11,380
So that gives you vaults.

588
00:45:11,380 --> 00:45:13,440
That gives you kind of rate limiting kind of stuff.

589
00:45:14,440 --> 00:45:16,120
Those are kind of the big ones.

590
00:45:16,120 --> 00:45:22,780
it gives you um jeremy rubin has a construction i forget the name where where um if you're an

591
00:45:22,780 --> 00:45:27,540
exchange you can process like a thousand withdrawals in one output and then each person takes their

592
00:45:27,540 --> 00:45:32,980
part and puts the rest back into the output so the recipient pays for fee in this model uh which

593
00:45:32,980 --> 00:45:39,280
which um greatly improves the incentives around exchange withdrawals and setting network fees

594
00:45:39,280 --> 00:45:45,120
you can do all those kind of classic constructions on bitcoin but then because simplicity allows you

595
00:45:45,120 --> 00:45:46,960
to do arbitrary computations,

596
00:45:47,620 --> 00:45:49,880
there's a whole bunch of cool new stuff that you can do.

597
00:45:50,500 --> 00:45:54,040
So you could write a zero-knowledge proof verifier in simplicity.

598
00:45:54,540 --> 00:45:58,020
You could write a quantum hard signature scheme in simplicity.

599
00:45:58,400 --> 00:46:13,290
You could write a kind of like code that checks arbitrary cryptographic instructions arbitrary Merkle routes these kind of things you can write kind of like weighted threshold constructions

600
00:46:13,290 --> 00:46:21,870
where you say if um this is going to be a two of three multi-sig except if the fee rate is super

601
00:46:21,870 --> 00:46:27,070
low then it needs to be three of three say because like then like you know you need all

602
00:46:27,070 --> 00:46:30,790
everybody has to agree to do something that kind of screwy right you can like do constructions like

603
00:46:30,790 --> 00:46:38,110
that you can do delegation you can do rebindable signatures um so uh in bitcoin we talk about

604
00:46:38,110 --> 00:46:42,390
sig hash any prep out as like this extension that would allow lightning to be implemented with

605
00:46:42,390 --> 00:46:47,610
with backups that aren't growing linearly right uh in simplicity you can just implement sig hash

606
00:46:47,610 --> 00:46:53,170
any prep out you can implement whatever sig hash mode that you want um you can implement sig hashes

607
00:46:53,170 --> 00:46:58,510
where you sign the output of an arbitrary computation on your transaction which sounds

608
00:46:58,510 --> 00:47:02,370
like just crazy cs you know wankery but but there's there's real applications here where

609
00:47:02,370 --> 00:47:12,190
for example um i could sign i could have a two of two with my child where i sign the transaction

610
00:47:12,190 --> 00:47:18,110
such that his signature is only valid if the output stays like within a certain range within

611
00:47:18,110 --> 00:47:22,650
a certain fee rate uh only going to a certain destination you know i can kind of sign the

612
00:47:22,650 --> 00:47:27,870
high level parameters um of the transaction and he can he can fill in the rest and sign the rest of

613
00:47:27,870 --> 00:47:31,590
that kind of thing. And I don't have to choose that upfront, right?

614
00:47:31,630 --> 00:47:35,510
In my script code, what I say basically is if Andrew's key,

615
00:47:35,970 --> 00:47:40,030
it's signed some conditions and the kid's key needs to,

616
00:47:40,030 --> 00:47:43,730
needs to follow, needs to sign the whole transaction,

617
00:47:43,870 --> 00:47:45,650
following those conditions, right? End of story.

618
00:47:45,970 --> 00:47:48,370
And you can imagine like less personal, right?

619
00:47:49,110 --> 00:47:52,610
Kind of corporate settings where you have business policy that you want to

620
00:47:52,610 --> 00:47:56,290
enforce in this way, where you've got some sort of hierarchy of,

621
00:47:56,290 --> 00:48:04,290
of trust and hierarchy of business logic and you uh you can implement that directly in simplicity

622
00:48:04,290 --> 00:48:09,450
and like kind of no matter how arbitrarily complicated what you're describing is

623
00:48:09,450 --> 00:48:13,510
if you can specify it you can prove that your program meets the specification

624
00:48:13,510 --> 00:48:21,170
um one more example is you can create a signature where you sign that your fee rate has to be a

625
00:48:21,170 --> 00:48:29,170
certain amount but then based on how old your output is the allowable fee rate goes up so if

626
00:48:29,170 --> 00:48:35,070
you write a transaction it doesn't confirm rather than you having to resign it um you can just say

627
00:48:35,070 --> 00:48:38,990
or anybody can just kind of edit the transaction maybe the second party was a weak key who has to

628
00:48:38,990 --> 00:48:43,470
resign it which you probably want um you don't have to go get your keys out of cold storage to

629
00:48:43,470 --> 00:48:49,010
resign it with a higher fee rate just by dint of being old enough and having not confirmed to spend

630
00:48:49,010 --> 00:48:52,270
the new higher fee rate becomes valid with your original signature.

631
00:48:52,590 --> 00:48:55,530
And you can define these kind of ramping up signatures kind of stuff.

632
00:48:56,310 --> 00:49:02,910
So there's a whole pile of stuff that really nobody is talking about on Bitcoin

633
00:49:02,910 --> 00:49:07,410
because you really need this total arbitrary computational ability

634
00:49:07,410 --> 00:49:08,730
to do these kind of things on Bitcoin.

635
00:49:08,990 --> 00:49:12,490
And even with something like Rusty's Great Strip Restoration Project,

636
00:49:13,130 --> 00:49:16,150
some of these are too out there to describe,

637
00:49:16,150 --> 00:49:20,590
like having these exponential ramp-up curves of allowable fee rates

638
00:49:20,590 --> 00:49:25,570
or trying to do like zero-knowledge proofs or giant Merkle tree reductions

639
00:49:25,570 --> 00:49:27,910
or all this kind of crazy stuff.

640
00:49:31,150 --> 00:49:32,190
Yeah, it's fascinating.

641
00:49:32,350 --> 00:49:36,050
And you guys have built what seems to be, from the outside looking at it,

642
00:49:36,050 --> 00:49:41,890
I haven't played around with it, but like a sort of a UI front-end with simplicity HL.

643
00:49:41,890 --> 00:49:46,390
so is is this sort of just trying to abstract everything and make it

644
00:49:46,390 --> 00:49:52,970
uh easy for people to interact with simplicity and without having to get deep into the weeds

645
00:49:52,970 --> 00:50:01,250
yeah for sure so simplicity itself um it sounds so wonderful it sounds so simple when i say it in

646
00:50:01,250 --> 00:50:07,850
these high level oh you just compose these things um every time somebody new at blockstream tries

647
00:50:07,850 --> 00:50:08,550
to write Simplicity.

648
00:50:09,250 --> 00:50:11,730
They get so upset by how difficult it is

649
00:50:11,730 --> 00:50:13,730
to wrap your head around this programming model

650
00:50:13,730 --> 00:50:16,230
and how difficult it is to construct these programs

651
00:50:16,230 --> 00:50:19,670
that they turn around and write their own programming language

652
00:50:19,670 --> 00:50:20,830
that compiles down to Simplicity.

653
00:50:20,970 --> 00:50:21,710
It's kind of funny.

654
00:50:21,770 --> 00:50:23,690
This happened three times in a row.

655
00:50:24,290 --> 00:50:27,870
And the latest iteration, which we're letting the public use,

656
00:50:28,030 --> 00:50:29,950
that we really want to be out there and usable,

657
00:50:30,130 --> 00:50:31,970
is Simplicity HL, as you said.

658
00:50:31,970 --> 00:50:46,890
So while simplicity is a very low level, like, you know, contort your computation into this composition of identities and units kind of construction, simplicity HL looks and feels like the Rust programming language.

659
00:50:46,890 --> 00:50:52,230
you can tell as you're writing it that like secretly you're doing some sort of functional

660
00:50:52,230 --> 00:50:57,750
construction thing but it looks like you do like do this then that if this then do this

661
00:50:57,750 --> 00:51:04,990
do this you know the loop this many loop over this you know at most this many times kind of thing

662
00:51:04,990 --> 00:51:09,870
and that that at most restriction is because these programs are finite we would like to remove that

663
00:51:09,870 --> 00:51:13,650
using the disconnect off code but there's there's more work to be done behind the scenes there

664
00:51:13,650 --> 00:51:21,150
um so simplicity so you can go to simplicity-lang.org is where our our sandbox and documentation

665
00:51:21,150 --> 00:51:26,650
sandbox our play uh playground that's the word uh we've got like a web interface you can write

666
00:51:26,650 --> 00:51:30,810
the simplicity hl code and compile it to simplicity see what it looks like and so on

667
00:51:30,810 --> 00:51:37,430
and simplicity hl we expect will be the way that people interact with simplicity programs

668
00:51:37,430 --> 00:51:42,990
until somebody makes a better language than simplicity hl that can also compiles down to it

669
00:51:42,990 --> 00:51:48,970
um so yeah so directly interacting with with simplicity that's that's for compilers and for

670
00:51:48,970 --> 00:51:54,310
proof assistance right so it's really not for humans because it's such a solo level and such a

671
00:51:54,310 --> 00:52:00,390
strange way to think about computation so simplicity hl is out there it works we've got a compiler you

672
00:52:00,390 --> 00:52:06,450
can use it uh there's a lot of stuff still to do um so one of the first things people come to us

673
00:52:06,450 --> 00:52:09,990
and they're like well i want to use libraries and i want to like call to these other functions and

674
00:52:09,990 --> 00:52:14,090
have modules and stuff well we don't have a module system and we don't have libraries yet like you

675
00:52:14,090 --> 00:52:17,730
just got to kind of write all your code and you can break it into functions but it's all just like

676
00:52:17,730 --> 00:52:22,250
one giant file with all your functions listed so so that's not great and we'll hopefully have that

677
00:52:22,250 --> 00:52:30,670
addressed in the coming weeks and months um there are kind of unbounded loops um people want loops

678
00:52:30,670 --> 00:52:34,310
that feel unbounded it's a little bit tricky because remember behind the scenes this has to

679
00:52:34,310 --> 00:52:38,530
turn into disconnect it has to turn into something bounded and we still want to make sure that we're

680
00:52:38,530 --> 00:52:45,030
showing users what the actual cost will be right not you know an ethereum style like who knows how

681
00:52:45,030 --> 00:52:48,950
much this will cost like good luck you can deploy this but you know you might be paying an infinite

682
00:52:48,950 --> 00:52:58,390
fee rate or an infinity fee to to satisfy it kind of thing um there are a few other kind of just

683
00:52:58,390 --> 00:53:02,910
extensions to the language i talked about how in simplicity you can implement sigh hash any prev out

684
00:53:02,910 --> 00:53:07,970
you can't do that in simplicity hl unfortunately because we don't we haven't exposed enough of the

685
00:53:07,970 --> 00:53:10,590
low-level SIG hashing kind of mechanisms and stuff.

686
00:53:11,430 --> 00:53:15,330
But if you want to write a zero-knowledge proof verifier,

687
00:53:15,610 --> 00:53:16,410
you totally can.

688
00:53:16,510 --> 00:53:20,770
If you want to write any of the crazy delegation code

689
00:53:20,770 --> 00:53:23,690
that I described, if you want to write a program

690
00:53:23,690 --> 00:53:27,090
that restrains your fee rate to some sort of curve

691
00:53:27,090 --> 00:53:29,730
based on the age of your coins, you can totally do that.

692
00:53:31,070 --> 00:53:34,490
Although I think parametrizing it by the signature,

693
00:53:35,490 --> 00:53:36,930
I think you can do it.

694
00:53:36,930 --> 00:53:39,890
So I'd have to think about that for a sec.

695
00:53:40,690 --> 00:53:43,950
There's most of the things that I described in my description.

696
00:53:44,130 --> 00:53:46,070
If you want to implement vaults, you can totally do that.

697
00:53:46,170 --> 00:53:49,150
If you want to implement delegation, you can totally do that.

698
00:53:49,850 --> 00:53:52,490
All the kind of like big covenant applications that are out there,

699
00:53:52,570 --> 00:53:54,810
you can totally implement today in Simplicity HL.

700
00:53:55,370 --> 00:53:58,850
So we have the compiler.

701
00:53:59,310 --> 00:54:00,870
You can produce Simplicity code.

702
00:54:00,870 --> 00:54:04,190
We've got a tool that will produce addresses from that.

703
00:54:04,190 --> 00:54:06,850
once you're actually building transactions

704
00:54:06,850 --> 00:54:08,930
and you better be a programmer

705
00:54:08,930 --> 00:54:10,450
who's developing a wallet

706
00:54:10,450 --> 00:54:11,550
because right now we don't have

707
00:54:11,550 --> 00:54:13,590
like the user-facing tooling

708
00:54:13,590 --> 00:54:14,990
to do cool stuff like this.

709
00:54:16,970 --> 00:54:18,510
We've got to build that into wallets

710
00:54:18,510 --> 00:54:19,970
over the coming weeks.

711
00:54:20,070 --> 00:54:21,210
So it's not something that today

712
00:54:21,210 --> 00:54:23,830
as like a user of Bitcoin

713
00:54:23,830 --> 00:54:25,210
just hoping to move money around

714
00:54:25,210 --> 00:54:27,090
might write these simple programs.

715
00:54:27,270 --> 00:54:28,230
We're not there yet,

716
00:54:28,410 --> 00:54:29,730
but we're certainly at the point

717
00:54:29,730 --> 00:54:31,430
where we're wallet developers

718
00:54:31,430 --> 00:54:33,050
who say I want my users

719
00:54:33,050 --> 00:54:35,510
to be able to do these arbitrary cool things,

720
00:54:36,050 --> 00:54:38,770
we'll have the toolkit to make that possible.

721
00:54:40,370 --> 00:54:41,390
Yeah, and on that point,

722
00:54:41,570 --> 00:54:44,530
who's out there at the Museum of Aqua,

723
00:54:44,770 --> 00:54:47,230
BullBitcoins implemented, Liquid,

724
00:54:47,990 --> 00:54:49,310
there are a few others.

725
00:54:50,890 --> 00:54:53,870
Have you guys been having conversations

726
00:54:53,870 --> 00:54:55,230
with these wallet developers,

727
00:54:55,630 --> 00:54:57,910
and what are they most excited about?

728
00:54:58,890 --> 00:55:00,130
Yeah, for sure.

729
00:55:00,290 --> 00:55:01,270
So there's a couple people.

730
00:55:01,270 --> 00:55:05,090
I'm not sure who all I'm allowed to talk about here.

731
00:55:05,890 --> 00:55:08,670
The one big one that you can find on GitHub,

732
00:55:08,950 --> 00:55:11,970
and I don't know when this podcast is going live,

733
00:55:12,050 --> 00:55:13,430
but they'll have a blog post out soon,

734
00:55:13,510 --> 00:55:15,830
is that the Starkware folks have developed a Stark verifier,

735
00:55:16,090 --> 00:55:18,590
a zero-knowledge proof verifier that works on simplicity.

736
00:55:18,850 --> 00:55:21,970
So that's personally, I think, the coolest thing that people are building.

737
00:55:22,950 --> 00:55:25,450
And then as far as wallet development goes,

738
00:55:26,470 --> 00:55:29,430
we're in the very early stages.

739
00:55:29,430 --> 00:55:32,830
So what we're hearing is that we need to implement simplicity.

740
00:55:33,350 --> 00:55:38,310
We need to integrate simplicity into, for example, LWK, the Liquid Wallet Toolkit.

741
00:55:38,790 --> 00:55:41,050
We've got to provide higher level interfaces.

742
00:55:41,830 --> 00:55:46,890
So right now we are talking to several people who are excited about using simplicity.

743
00:55:47,890 --> 00:55:57,010
And we're at the stage right now where they think is very cool, but there's a gap between how do I take the simplicity code and how do I integrate it into my existing wallet?

744
00:55:57,010 --> 00:55:58,350
Like how do I make it real?

745
00:55:58,350 --> 00:56:03,550
and there there's a couple layers of integration work that we are we're putting together in

746
00:56:03,550 --> 00:56:08,270
particular integration into lwk because that's that's the wallet toolkit that's what lets people

747
00:56:08,270 --> 00:56:12,590
you know connect simplicity to real utxos that the wallet's taken care of

748
00:56:13,230 --> 00:56:23,690
yeah it's exciting stuff then is your hope that there will be an incredible amount of development

749
00:56:23,690 --> 00:56:31,190
activity around simplicity on liquid and then sometime down the line it'll prove to be

750
00:56:31,190 --> 00:56:38,090
sufficiently robust expressive finite secure that the conversation will begin to potentially

751
00:56:38,090 --> 00:56:46,570
implement on the bitcoin protocol or is this something that should exist on a second layer

752
00:56:46,570 --> 00:56:53,470
federated side chain like liquid no no we'd like to go towards bitcoin so the uh it's a long we've

753
00:56:53,470 --> 00:56:57,890
got a long roadmap here right so so what we're doing right now is this launch on liquid is like

754
00:56:57,890 --> 00:57:05,130
the very first like um identifying like if we want to use simplicity in real life what are the gaps

755
00:57:05,130 --> 00:57:09,510
that didn't even occur to us on like the product and usability front like this is great we've got

756
00:57:09,510 --> 00:57:12,950
the language we've got a front-end language we've got a compiler we've got this command line tooling

757
00:57:12,950 --> 00:57:16,510
like this is great we did we built the whole language here and then you try to use it and

758
00:57:16,510 --> 00:57:20,810
you're like oh wait a minute how do i how does a wallet how is a wallet supposed to reason about

759
00:57:20,810 --> 00:57:25,350
these like fee rates that are increasing how is the wallet supposed to like figure out how to work

760
00:57:25,350 --> 00:57:28,610
with covenants how is the wallet how is the wallet supposed to do anything in this whole

761
00:57:28,610 --> 00:57:36,010
so that's what we're doing right now on the low level like simplicity on liquid uh how do we get

762
00:57:36,010 --> 00:57:42,330
it past liquid because liquid aside from being a small federated side chain off of bitcoin and not

763
00:57:42,330 --> 00:57:49,130
not bitcoin itself it also behaves in some ways it's the same as bitcoin it's still the utxo model

764
00:57:49,130 --> 00:58:01,010
Right. Still, your work was wrapped Bitcoin. So it's the same currency. But in other ways, it behaves quite differently because of the multi-assets and because of confidential transactions are the two big things.

765
00:58:01,010 --> 00:58:08,470
so our next big plan is that we are working on the bitcoin integration branch right now so you

766
00:58:08,470 --> 00:58:13,230
can go to the simplicity repo there's a branch that's that's reasonably up to date it should be

767
00:58:13,230 --> 00:58:20,950
up to date as of today um that is an extension of bitcoin core that includes simplicity and our

768
00:58:20,950 --> 00:58:28,230
game plan here is that we hope by the end of the year maybe maybe early next year to be able to go

769
00:58:28,230 --> 00:58:33,790
to one of the more experimental test networks out there.

770
00:58:34,090 --> 00:58:37,090
So as people may know, there's Bitcoin at the main net,

771
00:58:37,170 --> 00:58:38,850
and there's this thing called Testnet 4,

772
00:58:39,010 --> 00:58:41,190
which is like the official Bitcoin test network

773
00:58:41,190 --> 00:58:42,930
that exactly matches what's on Bitcoin.

774
00:58:43,570 --> 00:58:45,290
But then there's also something called SigNet,

775
00:58:45,830 --> 00:58:50,110
which is a signing-based network that has signed blocks.

776
00:58:50,410 --> 00:58:54,610
It matches Bitcoin, but with a few proposed extensions to Bitcoin

777
00:58:54,610 --> 00:58:55,950
that people want to experiment with.

778
00:58:55,950 --> 00:59:03,410
And then there's MutinyNet, which is like Cygnet, but even more just like, let's just put crazy stuff on here that we really want to see what would happen.

779
00:59:03,850 --> 00:59:08,610
And then it turns out there's even more of these networks out there, some of which are pretty widely used.

780
00:59:08,850 --> 00:59:17,670
And a couple months ago, I was talking to Jeremy Rubin, who's one of the main developers or admin kind of people for one of these networks.

781
00:59:18,370 --> 00:59:20,190
And I said this to him.

782
00:59:20,230 --> 00:59:24,550
I said, yeah, we're going to propose it to Cygnet, but maybe then we'll try MutinyNet.

783
00:59:24,550 --> 00:59:26,010
And then that seems more likely.

784
00:59:26,190 --> 00:59:26,510
And then we'll try.

785
00:59:26,830 --> 00:59:27,730
And he says, put it on mine.

786
00:59:27,910 --> 00:59:28,430
Do you have a branch?

787
00:59:28,550 --> 00:59:29,710
I'll deploy it right now.

788
00:59:29,990 --> 00:59:30,610
I laughed.

789
00:59:30,670 --> 00:59:31,730
This is like in April, right?

790
00:59:31,830 --> 00:59:35,230
I just said, I have a branch, but don't do it.

791
00:59:36,210 --> 00:59:38,910
It was super cool to get that kind of enthusiasm.

792
00:59:39,210 --> 00:59:47,610
So we're very confident that we'll be able to find one of these test networks that is based off of Bitcoin where people really want to deploy simplicity.

793
00:59:47,610 --> 01:00:02,710
And that's where, that's probably where we're going to start seeing like experimentation from the wider Bitcoin community and like, cool, like, can we, so I've said we can implement any, say gosh, any Prevout in simplicity.

794
01:00:02,910 --> 01:00:04,230
Well, is anyone going to actually do it?

795
01:00:04,770 --> 01:00:13,110
Can we try to use simplicity as a specification language for any Prevout or for OpCat or for CTV or any of these proposals?

796
01:00:13,110 --> 01:00:21,850
In principle, you can implement them all in simplicity and do so has the benefit that then you can say this is exactly the behavior of my proposed opcode.

797
01:00:22,290 --> 01:00:34,670
And your QA problem of how do we know it's going to behave well is reduced to how do we know that the C++ code will match the simplicity code, which at least is a more tangible target.

798
01:00:36,950 --> 01:00:39,690
That's the kind of exciting stuff that I'm looking forward to seeing.

799
01:00:39,690 --> 01:00:53,090
And right now with the Liquid launch, we're at the step before that, where rather than what are all the cool stuff that we can build and deploy, it's like, how can we build and deploy something that's like do the full end-to-end stack?

800
01:00:53,250 --> 01:00:59,770
What all is involved in doing a full deployment of something novel using Simplicity to do a full end-to-end stack?

801
01:01:00,810 --> 01:01:06,530
And frustratingly, like with all such things, it's bigger than we expected, right?

802
01:01:06,530 --> 01:01:08,530
We're a small team right now.

803
01:01:08,530 --> 01:01:10,770
The simplicity team right now is four people.

804
01:01:12,070 --> 01:01:15,230
And one of us is not even a developer.

805
01:01:15,670 --> 01:01:20,870
And we really thought we could get all of this pulled together.

806
01:01:21,570 --> 01:01:22,870
We thought we could do it even sooner.

807
01:01:23,450 --> 01:01:30,190
But it turns out that there's a lot more to writing a blockchain language than just writing the blockchain.

808
01:01:30,216 --> 01:01:31,116
validation code.

809
01:01:32,116 --> 01:01:36,156
Ironically, all of the low-level consensus code,

810
01:01:36,276 --> 01:01:38,196
the stuff that we fight so much over in Bitcoin,

811
01:01:38,656 --> 01:01:41,636
is actually the easy part of any of these things

812
01:01:41,636 --> 01:01:45,156
when you actually want it to change things for real users.

813
01:01:45,856 --> 01:01:47,696
So yeah, we're excited.

814
01:01:47,896 --> 01:01:49,416
This is a huge step.

815
01:01:49,556 --> 01:01:51,716
Despite me like, oh, we're still in the early days,

816
01:01:51,756 --> 01:01:53,916
this is a huge step getting this launched onto Liquid.

817
01:01:54,116 --> 01:01:55,576
This is what lets us start.

818
01:01:57,256 --> 01:01:58,716
Now it begins, basically.

819
01:01:58,716 --> 01:02:00,016
But what's beginning?

820
01:02:00,216 --> 01:02:01,296
It's a pretty big project.

821
01:02:01,836 --> 01:02:04,056
It's been a 13-year journey from paper.

822
01:02:04,456 --> 01:02:06,656
Well, you said even longer from math to here.

823
01:02:06,936 --> 01:02:07,156
Yeah.

824
01:02:07,556 --> 01:02:08,876
15 years if we look at it that way.

825
01:02:09,736 --> 01:02:21,716
And so many people will hear like simplicity, if it ever makes it on the Bitcoin, will enable all this stuff and get worried that it will disrupt the fee market.

826
01:02:21,716 --> 01:02:25,856
You'll have all this perceived junk on chain.

827
01:02:25,856 --> 01:02:35,396
Does implementing this stuff via simplicity sort of prevent, like you said, like you know exactly what's going to happen, you have that certainty.

828
01:02:35,916 --> 01:02:45,276
Does that prevent sort of unknown consequences that many people surmise these individual opcodes, if added, will introduce to the network?

829
01:02:45,276 --> 01:02:46,256
Yeah, yeah.

830
01:02:46,256 --> 01:02:58,756
Um, no, it will not prevent it, but using simplicity as an upgrade mechanism should make these things tractable and manageable.

831
01:02:58,756 --> 01:03:20,116
So let me first say is that if we want no MEV and none of these kind of risks that people will find a way to build new assets on the Bitcoin kind of thing, then probably we can't do any extensions at all.

832
01:03:20,656 --> 01:03:27,856
It seems like almost everything we do, and even maybe doing nothing, still makes it possible to do these kind of elaborate things.

833
01:03:27,856 --> 01:03:46,036
But one nice thing is that one reason this stuff is such a problem on chains like Ethereum or Solana is that the easy path for wallet developers is one that enables these kind of things.

834
01:03:46,036 --> 01:03:56,796
Ethereum really encourages the creation of DEXs that enable front running and contract code where the behavior changes based on your reordering of transactions.

835
01:03:57,016 --> 01:03:59,976
The account model also contributes to that, which Bitcoin doesn't have.

836
01:03:59,976 --> 01:04:06,996
so if we were to develop code if we were to have a simplicity interpreter as a mechanism for adding

837
01:04:06,996 --> 01:04:11,736
new features and new functionality to bitcoin then wallet developers would have the tools at

838
01:04:11,736 --> 01:04:18,516
their disposal to say here's how i can make sure there's only one path whatever the user chooses

839
01:04:18,516 --> 01:04:21,816
to do that is that is what's going to happen and it's not going to be other weird things that

840
01:04:21,816 --> 01:04:27,656
happen to the transaction along the way here's how i can bound the total size of my witnesses

841
01:04:27,656 --> 01:04:29,016
so my fee rates are manageable.

842
01:04:29,496 --> 01:04:31,516
And here's how I can change my code to tighten that bound

843
01:04:31,516 --> 01:04:32,696
to improve predictability.

844
01:04:33,976 --> 01:04:38,996
Because a fortunate economic truth is that MEV is bad

845
01:04:38,996 --> 01:04:41,176
not only for the network, but it's bad for individual users.

846
01:04:41,696 --> 01:04:46,576
And the reason that MEV happens is because it's just difficult

847
01:04:46,576 --> 01:04:48,716
to design these giant and complicated systems.

848
01:04:48,996 --> 01:05:07,303
But if we give people the tools to avoid MEV then they will use those tools because it valuable to them That very fortunate because sometimes in economics you get the opposite where just like your incentives are inherently stacked against you And that a very difficult problem Then your problem becomes like

849
01:05:07,343 --> 01:05:10,823
how do we just ban all bad behavior? How do we make it impossible to do anything bad because

850
01:05:10,823 --> 01:05:14,543
incentives are so lossful? But fortunately with things like MEV, they're not.

851
01:05:14,543 --> 01:05:22,184
um will simplicity related to mev right will simplicity enable these like alternate asset

852
01:05:22,184 --> 01:05:28,343
markets on top of bitcoin and then will you have economic activity on bitcoin that is not in bitcoin

853
01:05:28,343 --> 01:05:38,244
and that skews mining incentives and and all this terrible stuff and it will i don't think it will

854
01:05:38,244 --> 01:05:41,383
make it any more possible than it is today.

855
01:05:42,223 --> 01:05:50,644
So I've been surprised and kind of disappointed at how much ordinals took off, where ordinals

856
01:05:50,644 --> 01:05:58,383
or sorry, inscriptions, which are based on ordinals, where there's no Bitcoin script

857
01:05:58,383 --> 01:06:04,983
functionality being used at all for inscriptions, right?

858
01:06:04,983 --> 01:06:16,883
The way that inscriptions work is you take Bitcoin's UTXO model and we say, well, certain UTXOs outside of the network are assigned a special number or they were created with a particular JPEG attached to them.

859
01:06:16,883 --> 01:06:23,423
Or, you know, somehow or other just the virtue of how they were created on the Bitcoin chain.

860
01:06:24,023 --> 01:06:31,063
External to Bitcoin, there is a set of value that has been kind of layered onto that, which has created this market and all these distortions and stuff.

861
01:06:31,063 --> 01:06:48,043
And so as disappointed as I am by that, it takes a little bit of the pressure off of script extensions and new functionality for Bitcoin to see that actually what's blocking this stuff is not extra functionality, right?

862
01:06:48,144 --> 01:06:51,083
What's blocking this stuff is kind of nothing, right?

863
01:06:51,103 --> 01:06:53,083
It's just like the cost of using the Bitcoin network.

864
01:06:53,083 --> 01:07:07,083
And then when you frame it that way, well, if we can make legitimate uses of the Bitcoin network more productive and more valuable, then that should help crowd out these kind of inscription type behaviors.

865
01:07:08,264 --> 01:07:10,264
And then that will make Bitcoin be used for Bitcoin.

866
01:07:10,264 --> 01:07:16,843
And if we can make Bitcoin more valuable so that people aren't creating like wrapped versions of other assets, they're just using Bitcoin.

867
01:07:17,063 --> 01:07:31,343
That again, it means that Bitcoin is in an even stronger position as the asset on the Bitcoin network that miners are being paid in and that are incentivizing miners to continue the chain working correctly.

868
01:07:33,163 --> 01:07:38,224
So my feeling is I'm not an ossificationist.

869
01:07:38,224 --> 01:07:40,244
I don't think we should stop dead where we are.

870
01:07:41,264 --> 01:07:53,523
And given that, I think that if we're going to move forward at all on these extra script expressivity projects, I think the simplicity is a really good way to go in that direction.

871
01:07:53,523 --> 01:07:56,704
and if we were to try to implement

872
01:07:56,704 --> 01:07:59,083
kind of like arbitrary computations

873
01:07:59,083 --> 01:08:00,764
of the form that you would need

874
01:08:00,764 --> 01:08:03,644
to introduce like new quantum hard signatures

875
01:08:03,644 --> 01:08:05,523
or other like crazy new cryptography

876
01:08:05,523 --> 01:08:08,883
I think simplicity is pretty much the only way to go

877
01:08:08,883 --> 01:08:11,343
where we would preserve the ability

878
01:08:11,343 --> 01:08:14,663
to reason about transaction code

879
01:08:14,663 --> 01:08:26,971
while having these extra abilities Yeah that makes sense Like you say you you know simplicity enabling like one of the examples i

880
01:08:26,971 --> 01:08:33,691
been a big big advocate of for years hasn't uh hasn't hit the scale or adoption yet but like

881
01:08:33,691 --> 01:08:40,071
something like dlcs where you have like these like external events that are basically feeding data to

882
01:08:40,071 --> 01:08:45,751
a conditional transaction sending bitcoin one way or the other depending on what the conditions of

883
01:08:45,751 --> 01:08:52,191
the particular contract are like you can see people building financial sort of products on

884
01:08:52,191 --> 01:08:59,171
top of that denominated in bitcoin which make a lot of sense today yeah dlcs are so cool i i agree

885
01:08:59,171 --> 01:09:04,031
like they should be so much bigger than they are um and it's it's a slow burn i think in part because

886
01:09:04,031 --> 01:09:08,391
it's technically difficult to build big stuff with dlcs right i guess it's a pretty uh

887
01:09:09,051 --> 01:09:13,931
that's clunky right yeah yeah that's a good i was gonna say like a rigid building block right

888
01:09:13,931 --> 01:09:19,471
clunky right it's hard to hard to build complicated and flexible it's hard to build flexible things

889
01:09:19,471 --> 01:09:27,011
with with dlcs but those are super cool um and simplicity in some ways

890
01:09:27,011 --> 01:09:32,591
kind of takes the fun out of it because in simplicity you can directly check oracle signatures

891
01:09:32,591 --> 01:09:38,611
um right so if you have some external event and you have some some third party that's willing to

892
01:09:38,611 --> 01:09:43,671
sign on on that event being uh having happened one way or the other you can directly check that

893
01:09:43,671 --> 01:09:51,891
simplicity although the one crazy thing that dlcs have that almost nothing else has is that

894
01:09:51,891 --> 01:09:58,531
you have a third party in oracle broadcasting that like a game came out one way or another or

895
01:09:58,531 --> 01:10:03,391
you know a hurricane did or did not devastate a particular lot unit or whatever kind of insurance

896
01:10:03,391 --> 01:10:05,831
slash gambling product you're trying to build with it.

897
01:10:13,251 --> 01:10:16,371
With DLCs, you can use that in your script

898
01:10:16,371 --> 01:10:19,611
and the person making the signatures can't tell.

899
01:10:19,871 --> 01:10:20,831
Property that you get,

900
01:10:21,051 --> 01:10:22,811
which is that you can use these signatures

901
01:10:22,811 --> 01:10:26,951
without having to reveal that you're using the signature

902
01:10:26,951 --> 01:10:28,631
so that the person producing the signature

903
01:10:28,631 --> 01:10:30,771
can't come after you and say,

904
01:10:30,771 --> 01:10:34,771
like we were using our signatures in violation of return to service or like we don't like

905
01:10:34,771 --> 01:10:41,251
the particular construction that you did or or what so um i'm gonna stop because your screen

906
01:10:41,251 --> 01:10:48,211
has locked up i saw it stopped for like 10 like 10 seconds storing dlcs but i think okay perfect the um

907
01:10:50,771 --> 01:10:56,611
so you're you're just explaining there's like this oracle problem that exists yeah yeah so

908
01:10:56,611 --> 01:10:59,931
The brief summary is, right, Simplicity can do oracles directly.

909
01:11:00,451 --> 01:11:03,351
DLCs do oracles in a way where the oracle can't tell

910
01:11:03,351 --> 01:11:05,791
even after the fact that you're using their signature.

911
01:11:05,911 --> 01:11:06,071
Yeah.

912
01:11:06,491 --> 01:11:09,811
So that's a really cool anti-censorship property, the DLCs.

913
01:11:10,251 --> 01:11:14,011
And a lot of these kind of like tweaking signatures kind of tech has.

914
01:11:14,231 --> 01:11:14,951
So that's super cool.

915
01:11:16,351 --> 01:11:23,411
And where Simplicity will help that stuff, I think, is in the unhappy case.

916
01:11:23,411 --> 01:11:30,451
So a lot of the kind of trick with a lot of these DLC type constructions and adapter signatures

917
01:11:30,451 --> 01:11:35,691
and PTLCs and all these related things is that they, as long as the parties are both

918
01:11:35,691 --> 01:11:39,171
online and following the protocol correctly, they work perfectly.

919
01:11:39,171 --> 01:11:52,899
And then if somebody goes offline or is providing inconsistent data or somehow misbehaving you got to have this backup condition right And you DLCs themselves can do it right

920
01:11:52,899 --> 01:11:55,779
So you wind up as like, it's cool DLC stuff

921
01:11:55,779 --> 01:11:57,618
plus this extra backup condition.

922
01:11:57,618 --> 01:12:00,998
And simplicity hopefully can make those backup conditions

923
01:12:02,338 --> 01:12:05,418
more subtle or flexible and make DLCs user

924
01:12:05,418 --> 01:12:10,418
more user friendly and usable in other contexts, basically.

925
01:12:10,418 --> 01:12:17,118
but yeah no i think those problems are also further mitigated by just using like a threshold

926
01:12:17,118 --> 01:12:23,979
of multiple oracles providing the same data yeah yep yeah exactly um and that i mean bitcoin's

927
01:12:23,979 --> 01:12:28,578
great at doing thresholds of signatures um simplicity can improve on that but like

928
01:12:28,578 --> 01:12:34,338
in ways that matter no right um the bitcoin's really good at threshold signatures so that's

929
01:12:34,338 --> 01:12:41,058
part of why dlcs are so exciting yeah well it's been awesome i'm gonna say it again i'm pumped

930
01:12:41,058 --> 01:12:47,558
you guys i think yeah thanks university has been talked about for most of the time that i've been

931
01:12:47,558 --> 01:12:52,538
paying attention and involved in bitcoin it was uh really cool to see that you guys got it on

932
01:12:52,538 --> 01:13:00,479
liquid maiden and hopefully people that already have liquid liquid implemented into their wallets

933
01:13:00,479 --> 01:13:02,538
start playing around with it. Obviously,

934
01:13:03,198 --> 01:13:04,338
as you mentioned, there's

935
01:13:04,338 --> 01:13:06,238
some development kits and

936
01:13:06,238 --> 01:13:07,738
interfaces that need to

937
01:13:07,738 --> 01:13:10,399
be built out, but it seems like we're finally

938
01:13:10,399 --> 01:13:12,418
at the point where, all right, we can get cooking

939
01:13:12,418 --> 01:13:13,019
with this stuff.

940
01:13:14,238 --> 01:13:16,378
Yeah, absolutely. We've launched on

941
01:13:16,378 --> 01:13:18,099
Mainnet. We have a high-level language

942
01:13:18,099 --> 01:13:20,458
that compiles to Simplicity. You can use it today.

943
01:13:20,599 --> 01:13:21,958
simplicity-lang.org

944
01:13:21,958 --> 01:13:23,878
If you've been wondering,

945
01:13:24,058 --> 01:13:25,618
should I pay attention to Simplicity?

946
01:13:26,418 --> 01:13:27,998
Now the answer is yes. Finally,

947
01:13:28,238 --> 01:13:29,218
the answer is yes.

948
01:13:30,479 --> 01:13:37,378
Well, congrats again. Thank you for all the work and for coming and explaining this to us.

949
01:13:37,519 --> 01:13:47,338
I hope at the beginning when I prefaced to the audience that you like to go down rabbit holes and explain things thoroughly.

950
01:13:47,718 --> 01:13:48,718
You didn't take it as a dig.

951
01:13:48,718 --> 01:13:58,899
I love speaking with you because the extent of the detail that you go into just really triggers my nerd, my inner nerd.

952
01:13:59,038 --> 01:14:01,418
And I get giddy when you go down these rants.

953
01:14:01,578 --> 01:14:02,238
So thank you.

954
01:14:02,599 --> 01:14:05,538
And don't ever try to be brief is what I'm trying to say.

955
01:14:06,238 --> 01:14:06,899
All right.

956
01:14:06,958 --> 01:14:07,318
Thank you.

957
01:14:07,338 --> 01:14:07,779
There we go.

958
01:14:07,918 --> 01:14:08,779
I'll stop apologizing.

959
01:14:08,958 --> 01:14:09,139
Yeah.

960
01:14:10,298 --> 01:14:10,738
Thanks.

961
01:14:11,258 --> 01:14:14,238
Any final parting messages for anybody listening?

962
01:14:14,238 --> 01:14:18,738
No, I'm just going to repeat the website again.

963
01:14:19,118 --> 01:14:21,599
Simplicity-lang.org.

964
01:14:22,639 --> 01:14:25,038
And keep an eye on our GitHub as well.

965
01:14:25,158 --> 01:14:26,998
GitHub.com slash blockstreamresearch

966
01:14:26,998 --> 01:14:30,599
is where our Simplicity and our SimplicityHL

967
01:14:30,599 --> 01:14:32,118
and Rust Simplicity,

968
01:14:32,318 --> 01:14:34,298
we have a whole Rust library for building this stuff.

969
01:14:34,399 --> 01:14:35,458
That's where all those things live.

970
01:14:36,218 --> 01:14:37,198
If you want to get involved,

971
01:14:37,318 --> 01:14:38,118
if you want to be a developer,

972
01:14:38,258 --> 01:14:40,279
if you want to be a tester, that's great.

973
01:14:40,318 --> 01:14:41,618
If you want to work for us,

974
01:14:41,618 --> 01:14:47,599
we are we've got some simplicity related positions open uh so definitely keep an eye on our jobs

975
01:14:47,599 --> 01:14:53,218
posting i forget the url for that now um or just you know shoot me an email shoot any of us an email

976
01:14:53,218 --> 01:15:01,458
and we'll figure it out so so yeah thanks i will uh let me see company careers blockstream.com

977
01:15:01,458 --> 01:15:08,279
slash careers if you're looking for those jobs uh perfect andrew thank you uh excited to see

978
01:15:08,279 --> 01:15:09,038
what gets built.

979
01:15:10,399 --> 01:15:11,178
Yep. Thank you.

980
01:15:11,338 --> 01:15:12,318
Peace and love, freaks.