#648: Simplicity on Liquid with Andrew Poelstra

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
You've had a dynamic where money has become freer than free.

(00:10):
You talk about a Fed just gone nuts.
All the central banks going nuts.
So it's all acting like safe haven.
I believe that in a world where central bankers are tripping over themselves to devalue their currency,
Bitcoin wins.
In the world of fiat currencies, Bitcoin is the victor.
I mean, that's part of the bull case for Bitcoin.

(00:31):
If you're not paying attention, you probably should be.
Andrew Polstra, welcome back to the show, sir.
It's great to have you.
Hey, great to be back.
Like I said, I want to say it again.
Congrats on getting simplicity over the line.
I know it's been a long, almost a decade journey for Blockstream.

(00:52):
Yep. Yeah, for sure.
We got it onto the test network less than a year ago.
that was a big deal but this is our first production network with with real money on it
that you can use simplicity now with real money which is a pretty cool thing yeah so i guess for
anybody out there who's either newer to bitcoin unaware of simplicity why don't we give uh a

(01:16):
background i was gonna say brief background but i like your verbosity verbosity and you have deep
on it so i'm not gonna i'm not gonna um give any false promises to the audience we're about to get
an in-depth uh history on simplicity it really starts in 2012 when russle o'connor sort of
sketched the design and then you guys decided to really lean into it a block stream in like 2016

(01:40):
correct yep yeah that's about right um i would even say it started a little before how about this
i will try to be brief i always i always say i don't know why i'm probably saying it but i'll
try to be brief so uh that's even before even before simplicity in 2012 there was uh russell
o'connor had been in the bitcoin space he showed up very early days um 2010 i think maybe 2011 i

(02:03):
think it was 2010 and he had this concept called mast merkelized abstract syntax trees and this
eventually turned into what uh is now taproot where the idea is rather than having a script
system where you've got like if this then that kind of thing everybody runs this everybody has
to download this whole program and then run it and then they've got various conditions that that

(02:26):
apply under different conditions but they've always got to download it right they've always
got to see the whole script what if instead every time there was a conditional if this thing then
that thing what if we put them all in a merkle tree and so now you can have um hundreds or
thousands or millions of conditions and when you want to spend your coins at the time of spending

(02:49):
you know which conditions you're going to use to spend the coin so you just reveal that specific
one and the premise behind a merkle tree is is you can do exactly that it's this big structure
where you can commit to arbitrarily large numbers of things like up to up to billions before you're
you're spending too much compute time on it and then if you only want to reveal one of those

(03:11):
billions of things you have an overhead you reveal the one thing and then you have an overhead of
you know some some fixed cost maybe like a kilobyte or something versus having an overhead
of revealing a billion different things which is what you'd have to do in the traditional
model of script where the way you handle branches is by having a bunch of if then statements and

(03:32):
everybody's got to download the whole thing so in taproot we have that we have what's called the
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.
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.

(03:55):
And then whichever five participants you happen to have at the time of spending, you take the branch corresponding to those.
so this is an idea from 2010 2011 again like the very early days that eventually made it into tap
root much much later of course and simplicity kind of came out i promise it's relevant to simplicity

(04:16):
so the premise behind simplicity is what if we took that idea and we we really went to the extreme
with it so one big thing that simplicity has well first off simplicity is the way that it fits into
Bitcoin or the way that it fits into liquid is as basically a drop-in replacement for Bitcoin
script or the drop-in replacement for tap script as it is now. So you've got a tap tree, you've got

(04:39):
all these different scripts, and rather than using the existing Bitcoin script system, you use
simplicity instead. And within simplicity, you have these branches and these conditionals. So if
this person is available to sign, then check his signature. Otherwise, check this other signature.
or if the coin is old, like past a certain age,

(05:00):
then allow these backup keys to be used
or whatever conditionals you might want.
Then, okay, you've got these conditionals,
you reveal whichever side that you actually take.
That's cool.
There's some efficiency there.
Simplicity goes one step further.
And I says, well, conditionals are one way
of composing two pieces of code or two programs, right?

(05:24):
You've got some sort of flag, something that makes you decide what to do.
And you've got these two things that you might do.
And based on your flag, you pick one.
And you can compose things in other ways.
You could say, I've got these two programs.
I want to run them both in a row.
Bitcoin script is really good at this.
It's what's called a concatenative language.
You have a program.
You run it.

(05:45):
You just stick the other program right after and you run them.
You run them in order.
You might compose them by running both of your programs in parallel.
like on the same input and then somehow you combine their output.
So there's a couple other things you might do.
And it turns out that you can start with two different programs.

(06:06):
One of them does nothing.
It takes an arbitrary input and throws it away.
And the other does nothing.
It takes the arbitrary input and just passes it along.
And you take those two programs, arbitrarily many copies of them,
and you compose them with each other and other compositions
and you can build up any computation.
This is something called the sequent calculus, if you're into computer science, like historical computer science even.

(06:32):
It turns out you can build any computation just using these two basic functions and these combinators.
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.
most of them uh the bulk of them just push things onto the stack but then there are others that can

(06:57):
duplicate items there are others that can compare them to for uh to each other compare them to true
or false uh do branches based on them uh and then there's a collection of five or six that do kind
of cryptography right there's there's ones for four different kinds of hashes that are built into
bitcoin script there's one that checks a signature there's one that checks a multi-signature and

(07:21):
And Taproot is tweaked a little bit, but essentially it's checking a multi-signature.
And then there are a couple variants of these.
There are things for lock times.
And that's pretty much it, right?
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.

(07:42):
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.
And that's how you build programs.
And there are a few problems with this model.
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.

(08:06):
Well, you always have to write a whole bunch of code.
As a validator, you wind up having to download a whole bunch of code.
So even code that doesn't even get executed, you've got to download it because your whole program is in a straight line.
then another problem is that it's actually very difficult to reason formally about these things
so if you've got a bitcoin script that is supposed to implement some kind of crazy business logic and

(08:29):
stuff you ideally want some high assurance that it's going to do what you expect to the extent
that you can specify what you expect right um and and certainly you want some assurance that it's
not going to do like certain surprising things right the money won't move unless somebody signs
off on it. The script has certain behavior until a certain time at which backup conditions become

(08:52):
active. So those kind of things. And it's very hard to do this with Bitcoin script because the
way that you translate your specification, again, I'm glossing over, I'm using the word
specification in the interest of brevity. I'm not going to say what a formal specification is,
but it's a thing you can make that describes exactly what a program should do.

(09:15):
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.
Like, well, if I were a Bitcoin script interpreter, how would I do this?
Well, I'm going to push this onto the stack and push another thing and compare them.
And then I'm going to interpret this one as a public key and this other one as a signature.
And then I'm going to swap some things.
And I'm going to take the output of that, which is an opaque blob.

(09:36):
But I know it's going to be either zero or one.
And I'm going to move that to the alternate stack.
So it's out of the way.
And then I'm going to do this.
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.
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.

(10:09):
versus if you were constructing a program by starting with these two dead simple functions
the output nothing and the output what you give a function the the unit and the identity function
and then combining them in these various ways and in total by the way in simplicity you've got
those two basic functions and seven additional combinators that's it that's a whole language

(10:31):
nine nine combinators okay plus an extra one we add for witnesses and uh plus an extra one
called disconnect maybe we'll get into it okay 11 11 if i'm stretching um plus blockchain
introspection but we can also actually forget about this blockchain introspection is
even though formally we have to extend the language to support like how do you get what

(10:53):
the current lock time is how do you get the current amount amounts how do you get the current output
amounts etc all of those are very simple right they're just op codes op codes combinators that
take no input and output whatever they're supposed to do so okay 11 basic combinators all of which
are defined by like a single line of mathematical notation i've got a t-shirt i don't have it with

(11:16):
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
these t-shirts with the entire definition of simplicity language printed on it and importantly
it's not just simple in a uh kind of mathematical notation sentence it's simple in a formal sense
that can be captured by things like the rock theorem proving assistant or the lean proof

(11:40):
assistant or a language like idris or f sharp which has a type system that is capable of
supporting formal proof and the idea here is that now if you well there are two big ideas
come out of this so as a user of the language if you can specify what your program is supposed to do
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.

(12:10):
And then you can prove, you can produce a formal proof that your code matches the specification.
And perhaps you don't have a full specification, right?
Which is, it's difficult to create.
But maybe you can at least say some specific things.
You can say, at worst, no matter how this program executes, how much space will it take on my transaction?

(12:32):
You can answer that very cheaply.
And now you can bound your fee rates.
You can do fee estimation very accurately for arbitrarily complicated programs.
You can say, well, I don't really know.
I'm some countersigner, right?
I'm Blockstream.
I'm the Blockstream app.
I'm BitGo.
I'm whatever I am.
I don't know or care what this code is supposed to do, except that it shouldn't run without my signature.

(12:57):
Okay, it's whatever the customer says, plus my signature.
How can I formally prove that there's no possible way to spend this code without my signature?
Well, yes, you can prove something like that.
So that's one big thing.
And that's huge for users.
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.

(13:19):
so and we can be assured not only that's correct and that it matches the specification which we
have that's super cool but also it's correct and that it matches our intuition so in bitcoin script
there are at least once it used to be more frequent but like at least once every year or two
there's some new novel behavior in bitcoin scripts that somebody will discover that as near as we can

(13:41):
tell nobody knew before where if you kind of poke an opcode in exactly the right way then it will do
something surprising and let me give an example of this kind of thing um the if opcode in bitcoin
script it takes an input which is supposed to be true or false and in bitcoin script you don't have
true or false you have kind of blobs of data okay so you might think well probably false you might

(14:05):
represent by zero and and true you might represent by one is a natural way when you've got blobs of
data well it uh it turns out that false is represented by the empty string okay and also
zero and in fact also any arbitrarily long string of zeros except that also the leftmost zero is

(14:27):
allowed to be a one okay that that specific bit doesn't count okay and that's what false means
um oh and it can be arbitrarily long up to the 520 byte stack limit okay there's there's
only one other opcode that takes arbitrarily sized inputs like that.
And it's ifdup, which is the same, and not if.
Okay, so it's three.
All these if opcodes for something to take arbitrarily long inputs,

(14:48):
even though nothing else will accept arbitrarily long inputs.
Okay, so those are all the false values and everything else is true.
So that's a little bit surprising, right?
It means that if you could construct a public key or a signature
that happens to have this wonky shape of all zeros and then a one at the end,
then you could create a signature that evaluates to false,

(15:11):
even though every real signature that somebody produces
would evaluate to true.
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

(15:43):
In ECDSA, you can do that with something called public recovery, it turns out.
So you can do like arbitrarily badly formed signatures.
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.
Just like kind of we need some extra functionality that's bolted on.
And then there's kind of these like weird accidents of how certain opcodes interpret their input and they interact in crazy ways.

(16:09):
And this is part of why it's so hard to get new things in the Bitcoin script, right?
is that you can propose something like opcat,
which is three lines of code.
It's dead simple.
But how do you know how it fits into the system?
How do you know all of the behavior?
It takes so long and so much mental energy
to convince yourself that the simple-looking function

(16:29):
is not going to do surprising things.
And simplicity, by being the simple,
formally specified model,
saves you all of that effort.
So I'll stop.
so just building out not only comparing it to bitcoin script as it stands today but like i
guess i i think many bitcoin developers would look at something like how ethereum's implemented

(16:54):
script and it's it's created these sort of attack vectors that have been exploited
over time and what i'm picking up from what you just described within bitcoin specifically like
op codes or sort of this like modular way of doing it and i don't know if the intent of the
design was like let's do this modularly so you can have something out of the box but as you

(17:15):
described when you do that it's sort of clunky and you create um a burden for somebody trying
to build so it's very hard to audit and know exactly what it's going to do and so simplicity
just tries to be expressive yet finite um without having to have all that like complexity built in
Is that correct?

(17:36):
Yeah, exactly.
And expressive yet finite.
That's a good way to put it.
So yeah, EVM took Bitcoin script and just bolted on everything we want to be able to do.
Just bolted on to Bitcoin script, more or less, is roughly how EVM is structured.
And then they realized that the Bitcoin stack language is not a good model for that.
So they have what they call rich statefulness.

(17:57):
We've got these series of global database lookups.
So every contract has a bunch of code.
It has variables.
It can save and update and all this good stuff.
But it is very difficult to reason about.
They kind of inherited the difficulty in reasoning about Bitcoin script and in some ways made it much more complicated.

(18:18):
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.
But then the big thing is this word finite.
that you mentioned. So Ethereum for a while advertised itself as being Turing complete.

(18:39):
And the idea behind that phrase is that a Turing complete language can do anything at all.
A non-Turing complete language is kind of narrow and domain focused is the intuition, right? So as
an example, right, a programming language like JavaScript or like Python is Turing complete.
You can write anything that you can express, you can write in those languages.

(19:00):
a language like html is not html can only uh produce uh draw web pages basically um some things
would surprise you to learn that they're actually turing complete so css which is used to format
web pages to set the colors and the widths and the styles and stuff it turns out css is turing
complete because they're like conditional stylings that you can put in and the loops and stuff

(19:23):
uh postscript which is a document formatting language that predates pdf is turing complete
and I've exploited that to do some paper computer kind of projects.
There's a whole pile of languages that really shouldn't be Turing complete,
but accidentally are.
And Ethereum more or less is on purpose.

(19:44):
But there's a small caveat there.
Strictly speaking, to be a Turing complete language,
you need to have an infinite amount of memory
and an unbounded amount of memory and an unbounded runtime.
And in real life, of course, you're always bounded by, for one thing, by the constraints of your machine.
And then on Ethereum, you're bounded by this quantity of gas.

(20:06):
So you write an Ethereum transaction.
You decide how long you expect the transaction's contract code to run for.
And then you set a gas budget based on that, which is just actual Ether that you have to put up and you pay.
and where ethereum runs into trouble or one one place where ethereum runs into trouble

(20:27):
is that when you're trying to estimate how much gas your program's going to take you can't
do that in general and so there's these whole uh kind of categories of smart contract bugs
where it turns out that in order to call certain functions in a contract you have to use more gas
and is available, which means that you effectively cannot call those.

(20:50):
So there's functionality that you built into your script,
but it turns out it's not accessible because of this external gas limitation.
And that's kind of a problem for users.
It turns out it's also a problem for validators
because the way that you determine whether or not a script is valid,
whether or not it's used, all of the gas that it's been allocated,

(21:12):
is by running it.
You start running the script.
You figure out, did it run out of gas?
If it did, then you got to stop.
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?
Well, you can't do that.
That's a denial of service vector.
You already did all the work to do that.
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?

(21:38):
And maybe you limit yourself per transaction, whatever.
A bad guy gives you a million transactions that all take a microsecond.
And now you still wasted a second.
So in Ethereum, what happens is when you run out of gas, the transaction is still valid.
You still pass it along.
It winds up in the blockchain, but it doesn't do anything.
It just burns your gas.
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.

(22:03):
They just burn gas and do nothing else.
And these are almost certainly accidental because there's no reason for you to just burn gas the way that I'm describing.
And the way that Bitcoin avoids this problem,
in Bitcoin, if a transaction is invalid, it's invalid.
It doesn't go on the chain.
Is that in Bitcoin, there's kind of a neat trick we use,

(22:25):
which is that every opcode takes one byte to encode.
So Bitcoin script has no loops.
So every opcode can be executed at most once.
You can't go back and then redo stuff.
Which means that if you see a byte,
you know the absolute worst case,
that byte represents a single opcode of work.
And so you take the whole size of your transaction and you use that to swag how expensive that transaction will be.

(22:49):
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.
And that avoids this denial of service problem, basically.
So you don't have a gas limit.
What you have is the size of your transaction represents how much work it is.
And then your fee, you just attach whatever fee is appropriate for that.

(23:11):
And then miners and validators kind of order things,
which has the highest fee per weight kind of thing.
This is cool.
This is pretty cool.
But there's an obvious question then,
well, what if we want to,
surely we want to put loops
and go to some way of doing this kind of stuff
into Bitcoin, right?
Are we just forbidden from ever having a way
to execute an opcode more than once?

(23:32):
Because then it would break this,
how much the size of the transaction
representing the computational cost kind of model.
um and in ethereum the solution was gas they're like okay we're just going to have to throw away
the size size represents computation model and we're going to have to do this this unfortunate
thing in simplicity we have a much cooler solution which is that you can as a validator

(24:00):
you can scan through the program one byte at a time technically one bit at a time and you can
determine the maximum execution cost how much cpu is this going to use how much memory is it going
to use statically just like a single pass through the program and the program this is kind of cool
you can have a sub program or an op code however you want it to think of it that runs exponentially

(24:25):
often so you encode this bit of your program once and when you actually run the script it gets
evaluated you know like a trillion times you can totally do that in simplicity and your validators
will scan through the program they see your little bit they evaluate it once they say oh
that cost a trillion because it gets executed a trillion times and moves on and then eventually

(24:45):
it was you know the validator will say you know what a trillion is a lot you can't you can't fit
a trillion opcodes into into a single block kind of thing um but importantly even though you have
this kind of arbitrary blow up between the size of your program and the actual cost,
you still only have to scan the small one.
You have to scan the bytes of the program to figure out what that cost is.

(25:08):
And we call it a static analysis.
We call it a static bound.
And what that means is that we retain the Bitcoin ability for a validator to just look
at the transaction and immediately compute what the fee rate is and whether it should
be prioritized or whether it's never going to get into a block and we should just drop
it without ever having to execute the code.
And we do that while still getting this arbitrary amount of execution.

(25:33):
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.
None of which are a loop and none of which are a go-to, but it turns out you can still get arbitrary.

(25:55):
arbitrary computations this way and for each of those combinators as a validator you can say like
well okay if this is a parallel composition i'm running two things in parallel the cpu cost is
going to be you know the left guy plus the right guy the memory cost will be the maximum of either
one of them that can you kind of do that kind of analysis over and over now people who are

(26:20):
CS nerds or maybe just listening to me far too closely might be kind of suspicious about my claim
that you can do loops, that you can do an arbitrary computation in simplicity,
and that you don't have a looping construct or a go-to construct. And I'll briefly say something

(26:40):
about that, which is that there's actually another form of composition, which is not
sequential or conditional or parallel or these kind of basic things called recursive composition.
And that's where you have a function that's able to call itself and basically do a loop, right?
Go back.
So simplicity does support this through this extra combinator we call disconnect.

(27:02):
But it supports it in kind of a clever way where in principle, you can put an arbitrary
number of loops into your program at the time that you define it, at the time that you
construct your address that represents your program code. But when you actually go to spend it,
you are required to unroll the loop however many times you actually execute it. So Disconnect

(27:26):
Commender allows you to attach arbitrarily many copies of code, but you have to attach them as
spending time. And then if they are actual literal copies, one after the other, you don't have to
write the same code 20 times in a row. The encoding of simplicity will collapse it into a
single copy but the static bound they're still able to see that it's executed 20 times and assign

(27:48):
at a cost of 20 so in the end what hits the blockchain is in fact finite is in fact built up
what hits the blockchain essentially does not have this recursive um uh way of combining of composing
computations in the end when you put it on the chain you have to enroll it and then it's just

(28:08):
regular old composition where you're running one thing after the other so you kind of get the best
of both worlds where at commitment time when you're writing your program and generating addresses
then you can do arbitrary unbounded computations but if you want to spend it on the blockchain
you have to do the computation and it has to terminate and you have to bound how much that

(28:31):
how long that computation took in order to put it on the chain otherwise you can't even code the
results like it's just like a nonsensical transaction so it's a user transaction creator
get this full expressivity,
but validators don't have to deal
with that expressivity,
which they don't need, right?
Like a validator knows
if your transaction is going untamed,

(28:52):
your program has to succeed, right?
It has to be valid, right?
That's like the one thing.
Validators' job is not to like
run the computation
and see what happens, right?
Their job is to validate
that you did the computation
and the right thing happened, right?
And as cheaply,
they want to do that as cheaply
and as predictably as possible.
So...
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.

(29:28):
Yeah, absolutely. Thank you for zooming out so much. That's exactly it, right?
all of these elaborate constructions i'm describing have that goal of how do we have something that
you can formally reason about where when you're when you're implementing the system you want to
know that it's doing something predictable that's not going to blow up people's computers or crash
when you're writing code you want to know that your code that you're writing does what you expect

(29:52):
it to and when you're running a full node when you're validating this stuff you want to know
that very quickly you can figure out the cost of this validation and you can charge the transaction
appropriately and with simplicity we've managed to do this in a model where we get the full
expressivity of something like evm or or chialisp or any of these languages that are out there that

(30:13):
you do arbitrary computations while preserving these goals yeah and i think this has been a big
a big theme in bitcoin for the better part of eight years now or nine ten years since
Ethereum launch specifically, which is like Bitcoin is an extremely important project.

(30:36):
We're trying to separate money in states.
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

(31:02):
And during that period, you had Ethereum, other smart contracting networks come to the market and say, look at us.
We're doing it better.
We're faster.
We have more features than Bitcoin.
And all the while, Bitcoiners, myself included, and I truly do believe this, it seems like it's beginning to manifest,
have been saying it will eventually come to Bitcoin.
We're just going to do it the right way.

(31:23):
And it seems like that's what you guys have been working on in Simplicity for a decade is doing it the right way.
Yeah.
Yeah.
Everything.
everything ethereum added everything these other chains added right comes with some trade-offs
and some of those are more reasonable than others right so a lot of these things have much faster
blocks than bitcoin and i think if bitcoin had been developed if in 2008 somehow satoshi had

(31:46):
compact blocks and mini sketch and all of this like peer-to-peer propagation tech that we have
today probably we would have faster blocks right there's certainly a trade-off between fast blocks
and decentralization.
And it's not inherently obvious that the 10-minute block
was the perfect optimal thing.
But then there are other things that are just clearly

(32:07):
very, very bad trade-offs, right?
And Ethereum introducing this super expressive language
with the trade-offs they made where validators have,
where you have to be able to put invalid transactions
into the chain because validators can't determine
whether or not it's valid without executing
an arbitrarily long piece of code.
and where once a transaction is once they've even validated a transaction they can't know that it

(32:32):
will stay valid until it's in a block because in ethereum it's possible to reorder transactions in
ways that made previously valid transactions become valid there's another reason that that
um that you have to just put bad transactions into blocks is because um you need you have to
charge the person who created the transaction and even if it appears while the transaction is on the

(32:52):
peer-to-peer network that it was legit. Maybe it turns out not to be legit because things changed.
That's a terrible trade-off, right? We would never have accepted an extension to Bitcoin that
added some sort of looping facility with these kind of problems. We would never have accepted
an extension to Bitcoin that allowed you to introspect a transaction in a way where if the

(33:12):
transaction appeared in a block in a different order or was reorgged back a block or two,
then it would suddenly become invalid and invalidate all the work that people did to
cash the transaction validity um we would never accept any change to bitcoin that changed what we
call monotonicity once the transaction is valid it stays valid forever with one exception of it

(33:34):
might get double spent and then the double spend might might wind up in the chain um but that
doesn't require rechecking the scripts or anything that just requires knowing which inputs it spends
and keeping an eye on them.
Those are terribly, obviously terrible trade-offs.
We would never accept an extension to Bitcoin
that had rich statefulness,
that had a global key value store of all this contract code

(33:57):
so that anybody could call an arbitrary piece of contract
and then call an arbitrary function in that.
And that function itself had this map that you can update
so that validating a single Bitcoin transaction
requires an unpredictably deep dive
into this massive terabyte-sized database that you've got to go through.
And so running a full archival node on Ethereum,

(34:21):
well, Jameson Lopp, I think, did some work trying to do this
five or six years ago, and it was, I don't know that he succeeded.
This is definitely worth looking up, and things have gotten even worse since then.
That led to a situation where nobody is running a full Ethereum node,
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.

(34:52):
So those kind of things I would say are obviously bad tradeoffs that like Bitcoin would never accept, right?
And as a historical thing, it's kind of interesting to me that Ethereum took so many of those choices, right?
Not just like, could we have faster blocks?
Could we have bigger blocks?
What if we used PubQ recovery in certain places?

(35:14):
What if we structured our transactions?
Even what if we had accounts versus UTXOs?
I think you can make arguments for both.
I think they were clearly wrong about that,
but it's just a much more subtle thing.
But the rich statefulness and the loops
and the inability to cash transaction validity
is either just fundamentally complete non-starters for Bitcoin.

(35:35):
right and that's that's a big part but but without them it's so hard to do anything right which is
why here we are in in 2025 um debating opcat and also debating what kind of crazy programs can you
build just as a concatenation opcode and by like abusing it to like fold back in on itself and like
run through the signature it's like it's crazy the kind of hacks that we have when um kind of to

(36:00):
somebody looking from the outside they'd be like guys this is crazy just put some freaking arithmetic
into your blockchain so people can do math already and do some computations and then
move on with your lives right um it's hard it turns out it's hard to preserve scalability and
decentralization um it's hard to preserve the properties that bitcoin has that make it scalable
and decentralized while getting this extra expressivity yeah and you said the word scalable

(36:25):
there so this is obviously uh gone live on liquid's mainnet which is a federated side chain
blockchain has been running for almost a decade now too and let's jump into that like the really
exciting stuff which is like the use cases that is this unlocks whether it's covenants and vaults

(36:45):
uh on-chain financial primitives programmable delegation like there's seems to be in endless
amount of potential applications that can be built on simplicity so let's jump in why liquid
how does it work on liquid specifically compared to how it could potentially work on bitcoin at the

(37:06):
protocol level if it ever does in the future maybe we can talk about if that's even a good idea
um and what do you expect to see get built sure so uh so liquid for people who don't know this
is a side chain that was developed by blockstream and that has been running yeah since since 2018
october 2018 was was our launch date uh liquid is what's called a federated side chain

(37:30):
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.
And so liquid is a sidechain.
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.

(37:55):
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.
And then any 11 of those are responsible for moving the money back when you request it on the Liquid blockchain.
So that's how the pay-in and pay-out mechanism work there.

(38:15):
And the Liquid has also made a couple trade-offs that are no-goes for Bitcoin, for sure.
So one is a federated model, right?
That's just completely alien to the Bitcoin proof of work based security model.
And everybody has, well, everything comes down to proof of work ultimately in Bitcoin, as well as not your keys, not your coins, right?

(38:40):
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?
Which is kind of nice.
So that's one.
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.

(39:16):
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.
Liquid doesn't have that problem because it has block centers.
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.

(39:44):
And here's really, you said, why Liquid?
Why Liquid?
We know Liquid and we can do stuff fast on Liquid.
So Liquid historically has been kind of a demo for many things that wound up on Bitcoin eventually.
So Liquid, or I should say the precursor to Liquid, what we called Elements Alpha, had SegWit before Bitcoin had SegWit.

(40:05):
And actually it turned out, the fun history there, that the version of SegWit in Elements was terrible.
It would have been a hard forking change.
It had all these bad properties and stuff.
And then Luke Dasher looked at this and he said, wait, we could tweak this.
And then it's a soft fork and then we could do this way better thing.
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.

(40:28):
And then we pulled it back into Liquid.
Yeah, that one's way better than ours.
So that was a cool back and forth.
Liquid also had check sequence verify, which is how you do lock time checks and script before Bitcoin did.
liquid has what's called confidential transactions which are a way of hiding the amounts and the asset
types of all of your inputs and outputs in a transaction which gets you a pretty big part of

(40:54):
the kind of privacy that monero or or zcash have without the the worst of the scalability trade-offs
and there there's there's an uncomfortable privacy uh scalability trade-off that liquid
show the different place that that wound up being pulled into monero for example um and uh and so now
we're working on simplicity right and so we took simplicity the nine or eleven if you want

(41:21):
combinators that uh that define the language we added a few extra bolt-on facilities for
introspecting liquid transactions which uh atsy would be much harder than doing the same thing
on Bitcoin. And then we deployed it there as a tap leaf version. So Liquid has taproot.
Frustratingly, Bitcoin got taproot before Liquid did. And we were like, internally,

(41:42):
everything's harder on Liquid because we have multiple assets and we have constant
transactions and stuff. But that one, we were like, internally, it was a race in our hearts.
In my heart, it was a race and we lost. But okay, we have taproot on Liquid now.
So within a taproot output on Liquid, you can choose for every script, you choose either to use scripts or to use simplicity.

(42:07):
And there you go.
That's how it fits in.
And the tradeoffs that we make before I jump into use cases, right?
So why do we do that on Liquid and why couldn't we just turn around and do it on Bitcoin?
Well, simplicity is an entire replacement for the script interpreter, right?
It's this giant blob of C code, which is several thousand lines at least.

(42:31):
It has some cool, complicated things where it identifies programs by these Merkle roots.
It builds this abstract tree of how your program is constructed and combined at a smaller thing.
It computes these Merkle roots.
It has a type system and a type inference system.
It has this notion of sharing that allows you to collapse repeated pieces of code into one.

(42:54):
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.
And the whole thing is just a very new – there's a lot of code that's like a really core piece of consensus.
And it's a new model and it's a scary thing.

(43:16):
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.
whereas on liquid we can just kind of do it right um we got to get we got to get approval from the
15 functionaries they all all these participants think that's a pretty cool thing um liquid well

(43:37):
we have very high assurance that simplicity is correct and it's not going to like lose money
and it's not going to crash the system or something um certainly nobody is at risk from simplicity who
isn't directly using it right which is nice that would also be true on bitcoin but uh but on bitcoin
there's always this worry that like what if it turns out that you can like crash nodes with it
or something and liquid just by nature of it's federated like that is not i really like it's not

(44:04):
going to happen it's like not i'm not suggesting that we would deploy something where it's possible
but if it did we would pick up the piece of the move on and on liquid we can kind of do that
because it's a federated system um and because ultimately all the coins are are uh backed by
bitcoins and and real bitcoins that are not moving on the bitcoin chain and stuff in a way that
bitcoin just can't right you you can't you can never never risk bitcoin doing that so um so we

(44:31):
launched it on liquid and in our kind of long-term vision of getting simplicity into into bitcoin
into real bitcoin users hands and like um getting out into the real world outside of liquid um
So this is a place, it's deployed on a blockchain.
This got some kind of neat asset features, which are useful for demonstrating simplicity.

(44:54):
And we can start to learn how simplicity behaves on the blockchain.
So as you hinted at, simplicity includes covenant support.
It includes the ability to look at transactions and make decisions based on the shape of your transactions.
So that's pretty cool.
So that gives you vaults.
That gives you kind of rate limiting kind of stuff.
Those are kind of the big ones.

(45:16):
it gives you um jeremy rubin has a construction i forget the name where where um if you're an
exchange you can process like a thousand withdrawals in one output and then each person takes their
part and puts the rest back into the output so the recipient pays for fee in this model uh which
which um greatly improves the incentives around exchange withdrawals and setting network fees

(45:39):
you can do all those kind of classic constructions on bitcoin but then because simplicity allows you
to do arbitrary computations,
there's a whole bunch of cool new stuff that you can do.
So you could write a zero-knowledge proof verifier in simplicity.
You could write a quantum hard signature scheme in simplicity.
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

(46:13):
where you say if um this is going to be a two of three multi-sig except if the fee rate is super
low then it needs to be three of three say because like then like you know you need all
everybody has to agree to do something that kind of screwy right you can like do constructions like
that you can do delegation you can do rebindable signatures um so uh in bitcoin we talk about

(46:38):
sig hash any prep out as like this extension that would allow lightning to be implemented with
with backups that aren't growing linearly right uh in simplicity you can just implement sig hash
any prep out you can implement whatever sig hash mode that you want um you can implement sig hashes
where you sign the output of an arbitrary computation on your transaction which sounds

(46:58):
like just crazy cs you know wankery but but there's there's real applications here where
for example um i could sign i could have a two of two with my child where i sign the transaction
such that his signature is only valid if the output stays like within a certain range within
a certain fee rate uh only going to a certain destination you know i can kind of sign the

(47:22):
high level parameters um of the transaction and he can he can fill in the rest and sign the rest of
that kind of thing. And I don't have to choose that upfront, right?
In my script code, what I say basically is if Andrew's key,
it's signed some conditions and the kid's key needs to,
needs to follow, needs to sign the whole transaction,

(47:43):
following those conditions, right? End of story.
And you can imagine like less personal, right?
Kind of corporate settings where you have business policy that you want to
enforce in this way, where you've got some sort of hierarchy of,
of trust and hierarchy of business logic and you uh you can implement that directly in simplicity

(48:04):
and like kind of no matter how arbitrarily complicated what you're describing is
if you can specify it you can prove that your program meets the specification
um one more example is you can create a signature where you sign that your fee rate has to be a
certain amount but then based on how old your output is the allowable fee rate goes up so if

(48:29):
you write a transaction it doesn't confirm rather than you having to resign it um you can just say
or anybody can just kind of edit the transaction maybe the second party was a weak key who has to
resign it which you probably want um you don't have to go get your keys out of cold storage to
resign it with a higher fee rate just by dint of being old enough and having not confirmed to spend
the new higher fee rate becomes valid with your original signature.

(48:52):
And you can define these kind of ramping up signatures kind of stuff.
So there's a whole pile of stuff that really nobody is talking about on Bitcoin
because you really need this total arbitrary computational ability
to do these kind of things on Bitcoin.
And even with something like Rusty's Great Strip Restoration Project,

(49:13):
some of these are too out there to describe,
like having these exponential ramp-up curves of allowable fee rates
or trying to do like zero-knowledge proofs or giant Merkle tree reductions
or all this kind of crazy stuff.
Yeah, it's fascinating.
And you guys have built what seems to be, from the outside looking at it,

(49:36):
I haven't played around with it, but like a sort of a UI front-end with simplicity HL.
so is is this sort of just trying to abstract everything and make it
uh easy for people to interact with simplicity and without having to get deep into the weeds
yeah for sure so simplicity itself um it sounds so wonderful it sounds so simple when i say it in

(50:01):
these high level oh you just compose these things um every time somebody new at blockstream tries
to write Simplicity.
They get so upset by how difficult it is
to wrap your head around this programming model
and how difficult it is to construct these programs
that they turn around and write their own programming language
that compiles down to Simplicity.
It's kind of funny.

(50:21):
This happened three times in a row.
And the latest iteration, which we're letting the public use,
that we really want to be out there and usable,
is Simplicity HL, as you said.
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.

(50:46):
you can tell as you're writing it that like secretly you're doing some sort of functional
construction thing but it looks like you do like do this then that if this then do this
do this you know the loop this many loop over this you know at most this many times kind of thing
and that that at most restriction is because these programs are finite we would like to remove that

(51:09):
using the disconnect off code but there's there's more work to be done behind the scenes there
um so simplicity so you can go to simplicity-lang.org is where our our sandbox and documentation
sandbox our play uh playground that's the word uh we've got like a web interface you can write
the simplicity hl code and compile it to simplicity see what it looks like and so on

(51:30):
and simplicity hl we expect will be the way that people interact with simplicity programs
until somebody makes a better language than simplicity hl that can also compiles down to it
um so yeah so directly interacting with with simplicity that's that's for compilers and for
proof assistance right so it's really not for humans because it's such a solo level and such a

(51:54):
strange way to think about computation so simplicity hl is out there it works we've got a compiler you
can use it uh there's a lot of stuff still to do um so one of the first things people come to us
and they're like well i want to use libraries and i want to like call to these other functions and
have modules and stuff well we don't have a module system and we don't have libraries yet like you
just got to kind of write all your code and you can break it into functions but it's all just like

(52:17):
one giant file with all your functions listed so so that's not great and we'll hopefully have that
addressed in the coming weeks and months um there are kind of unbounded loops um people want loops
that feel unbounded it's a little bit tricky because remember behind the scenes this has to
turn into disconnect it has to turn into something bounded and we still want to make sure that we're

(52:38):
showing users what the actual cost will be right not you know an ethereum style like who knows how
much this will cost like good luck you can deploy this but you know you might be paying an infinite
fee rate or an infinity fee to to satisfy it kind of thing um there are a few other kind of just
extensions to the language i talked about how in simplicity you can implement sigh hash any prev out

(53:02):
you can't do that in simplicity hl unfortunately because we don't we haven't exposed enough of the
low-level SIG hashing kind of mechanisms and stuff.
But if you want to write a zero-knowledge proof verifier,
you totally can.
If you want to write any of the crazy delegation code
that I described, if you want to write a program

(53:23):
that restrains your fee rate to some sort of curve
based on the age of your coins, you can totally do that.
Although I think parametrizing it by the signature,
I think you can do it.
So I'd have to think about that for a sec.
There's most of the things that I described in my description.

(53:44):
If you want to implement vaults, you can totally do that.
If you want to implement delegation, you can totally do that.
All the kind of like big covenant applications that are out there,
you can totally implement today in Simplicity HL.
So we have the compiler.
You can produce Simplicity code.
We've got a tool that will produce addresses from that.

(54:04):
once you're actually building transactions
and you better be a programmer
who's developing a wallet
because right now we don't have
like the user-facing tooling
to do cool stuff like this.
We've got to build that into wallets
over the coming weeks.
So it's not something that today
as like a user of Bitcoin
just hoping to move money around

(54:25):
might write these simple programs.
We're not there yet,
but we're certainly at the point
where we're wallet developers
who say I want my users
to be able to do these arbitrary cool things,
we'll have the toolkit to make that possible.
Yeah, and on that point,
who's out there at the Museum of Aqua,
BullBitcoins implemented, Liquid,

(54:47):
there are a few others.
Have you guys been having conversations
with these wallet developers,
and what are they most excited about?
Yeah, for sure.
So there's a couple people.
I'm not sure who all I'm allowed to talk about here.
The one big one that you can find on GitHub,

(55:08):
and I don't know when this podcast is going live,
but they'll have a blog post out soon,
is that the Starkware folks have developed a Stark verifier,
a zero-knowledge proof verifier that works on simplicity.
So that's personally, I think, the coolest thing that people are building.
And then as far as wallet development goes,
we're in the very early stages.

(55:29):
So what we're hearing is that we need to implement simplicity.
We need to integrate simplicity into, for example, LWK, the Liquid Wallet Toolkit.
We've got to provide higher level interfaces.
So right now we are talking to several people who are excited about using simplicity.
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?

(55:57):
Like how do I make it real?
and there there's a couple layers of integration work that we are we're putting together in
particular integration into lwk because that's that's the wallet toolkit that's what lets people
you know connect simplicity to real utxos that the wallet's taken care of
yeah it's exciting stuff then is your hope that there will be an incredible amount of development

(56:23):
activity around simplicity on liquid and then sometime down the line it'll prove to be
sufficiently robust expressive finite secure that the conversation will begin to potentially
implement on the bitcoin protocol or is this something that should exist on a second layer

(56:46):
federated side chain like liquid no no we'd like to go towards bitcoin so the uh it's a long we've
got a long roadmap here right so so what we're doing right now is this launch on liquid is like
the very first like um identifying like if we want to use simplicity in real life what are the gaps
that didn't even occur to us on like the product and usability front like this is great we've got

(57:09):
the language we've got a front-end language we've got a compiler we've got this command line tooling
like this is great we did we built the whole language here and then you try to use it and
you're like oh wait a minute how do i how does a wallet how is a wallet supposed to reason about
these like fee rates that are increasing how is the wallet supposed to like figure out how to work
with covenants how is the wallet how is the wallet supposed to do anything in this whole
so that's what we're doing right now on the low level like simplicity on liquid uh how do we get

(57:36):
it past liquid because liquid aside from being a small federated side chain off of bitcoin and not
not bitcoin itself it also behaves in some ways it's the same as bitcoin it's still the utxo model
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.

(58:01):
so our next big plan is that we are working on the bitcoin integration branch right now so you
can go to the simplicity repo there's a branch that's that's reasonably up to date it should be
up to date as of today um that is an extension of bitcoin core that includes simplicity and our
game plan here is that we hope by the end of the year maybe maybe early next year to be able to go

(58:28):
to one of the more experimental test networks out there.
So as people may know, there's Bitcoin at the main net,
and there's this thing called Testnet 4,
which is like the official Bitcoin test network
that exactly matches what's on Bitcoin.
But then there's also something called SigNet,
which is a signing-based network that has signed blocks.

(58:50):
It matches Bitcoin, but with a few proposed extensions to Bitcoin
that people want to experiment with.
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.
And then it turns out there's even more of these networks out there, some of which are pretty widely used.
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.

(59:18):
And I said this to him.
I said, yeah, we're going to propose it to Cygnet, but maybe then we'll try MutinyNet.
And then that seems more likely.
And then we'll try.
And he says, put it on mine.
Do you have a branch?
I'll deploy it right now.
I laughed.
This is like in April, right?
I just said, I have a branch, but don't do it.
It was super cool to get that kind of enthusiasm.

(59:39):
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.
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.

(01:00:02):
Well, is anyone going to actually do it?
Can we try to use simplicity as a specification language for any Prevout or for OpCat or for CTV or any of these proposals?
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.
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.

(01:00:36):
That's the kind of exciting stuff that I'm looking forward to seeing.
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?
What all is involved in doing a full deployment of something novel using Simplicity to do a full end-to-end stack?

(01:01:00):
And frustratingly, like with all such things, it's bigger than we expected, right?
We're a small team right now.
The simplicity team right now is four people.
And one of us is not even a developer.
And we really thought we could get all of this pulled together.

(01:01:21):
We thought we could do it even sooner.
But it turns out that there's a lot more to writing a blockchain language than just writing the blockchain.
validation code.
Ironically, all of the low-level consensus code,
the stuff that we fight so much over in Bitcoin,
is actually the easy part of any of these things

(01:01:41):
when you actually want it to change things for real users.
So yeah, we're excited.
This is a huge step.
Despite me like, oh, we're still in the early days,
this is a huge step getting this launched onto Liquid.
This is what lets us start.
Now it begins, basically.
But what's beginning?
It's a pretty big project.

(01:02:01):
It's been a 13-year journey from paper.
Well, you said even longer from math to here.
Yeah.
15 years if we look at it that way.
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.
You'll have all this perceived junk on chain.

(01:02:25):
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.
Does that prevent sort of unknown consequences that many people surmise these individual opcodes, if added, will introduce to the network?
Yeah, yeah.

(01:02:46):
Um, no, it will not prevent it, but using simplicity as an upgrade mechanism should make these things tractable and manageable.
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.

(01:03:20):
It seems like almost everything we do, and even maybe doing nothing, still makes it possible to do these kind of elaborate things.
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.

(01:03:46):
Ethereum really encourages the creation of DEXs that enable front running and contract code where the behavior changes based on your reordering of transactions.
The account model also contributes to that, which Bitcoin doesn't have.
so if we were to develop code if we were to have a simplicity interpreter as a mechanism for adding

(01:04:06):
new features and new functionality to bitcoin then wallet developers would have the tools at
their disposal to say here's how i can make sure there's only one path whatever the user chooses
to do that is that is what's going to happen and it's not going to be other weird things that
happen to the transaction along the way here's how i can bound the total size of my witnesses

(01:04:27):
so my fee rates are manageable.
And here's how I can change my code to tighten that bound
to improve predictability.
Because a fortunate economic truth is that MEV is bad
not only for the network, but it's bad for individual users.
And the reason that MEV happens is because it's just difficult
to design these giant and complicated systems.

(01:04:48):
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
how do we just ban all bad behavior? How do we make it impossible to do anything bad because

(01:05:10):
incentives are so lossful? But fortunately with things like MEV, they're not.
um will simplicity related to mev right will simplicity enable these like alternate asset
markets on top of bitcoin and then will you have economic activity on bitcoin that is not in bitcoin
and that skews mining incentives and and all this terrible stuff and it will i don't think it will

(01:05:38):
make it any more possible than it is today.
So I've been surprised and kind of disappointed at how much ordinals took off, where ordinals
or sorry, inscriptions, which are based on ordinals, where there's no Bitcoin script

(01:05:58):
functionality being used at all for inscriptions, right?
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.
Or, you know, somehow or other just the virtue of how they were created on the Bitcoin chain.

(01:06:24):
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.
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?

(01:06:48):
What's blocking this stuff is kind of nothing, right?
It's just like the cost of using the Bitcoin network.
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.

(01:07:08):
And then that will make Bitcoin be used for Bitcoin.
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.
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.

(01:07:33):
So my feeling is I'm not an ossificationist.
I don't think we should stop dead where we are.
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.

(01:07:53):
and if we were to try to implement
kind of like arbitrary computations
of the form that you would need
to introduce like new quantum hard signatures
or other like crazy new cryptography
I think simplicity is pretty much the only way to go
where we would preserve the ability
to reason about transaction code

(01:08:14):
while having these extra abilities Yeah that makes sense Like you say you you know simplicity enabling like one of the examples i
been a big big advocate of for years hasn't uh hasn't hit the scale or adoption yet but like
something like dlcs where you have like these like external events that are basically feeding data to

(01:08:40):
a conditional transaction sending bitcoin one way or the other depending on what the conditions of
the particular contract are like you can see people building financial sort of products on
top of that denominated in bitcoin which make a lot of sense today yeah dlcs are so cool i i agree
like they should be so much bigger than they are um and it's it's a slow burn i think in part because

(01:09:04):
it's technically difficult to build big stuff with dlcs right i guess it's a pretty uh
that's clunky right yeah yeah that's a good i was gonna say like a rigid building block right
clunky right it's hard to hard to build complicated and flexible it's hard to build flexible things
with with dlcs but those are super cool um and simplicity in some ways

(01:09:27):
kind of takes the fun out of it because in simplicity you can directly check oracle signatures
um right so if you have some external event and you have some some third party that's willing to
sign on on that event being uh having happened one way or the other you can directly check that
simplicity although the one crazy thing that dlcs have that almost nothing else has is that

(01:09:51):
you have a third party in oracle broadcasting that like a game came out one way or another or
you know a hurricane did or did not devastate a particular lot unit or whatever kind of insurance
slash gambling product you're trying to build with it.

(01:10:13):
With DLCs, you can use that in your script
and the person making the signatures can't tell.
Property that you get,
which is that you can use these signatures
without having to reveal that you're using the signature
so that the person producing the signature
can't come after you and say,
like we were using our signatures in violation of return to service or like we don't like

(01:10:34):
the particular construction that you did or or what so um i'm gonna stop because your screen
has locked up i saw it stopped for like 10 like 10 seconds storing dlcs but i think okay perfect the um
so you're you're just explaining there's like this oracle problem that exists yeah yeah so

(01:10:56):
The brief summary is, right, Simplicity can do oracles directly.
DLCs do oracles in a way where the oracle can't tell
even after the fact that you're using their signature.
Yeah.
So that's a really cool anti-censorship property, the DLCs.
And a lot of these kind of like tweaking signatures kind of tech has.
So that's super cool.
And where Simplicity will help that stuff, I think, is in the unhappy case.

(01:11:23):
So a lot of the kind of trick with a lot of these DLC type constructions and adapter signatures
and PTLCs and all these related things is that they, as long as the parties are both
online and following the protocol correctly, they work perfectly.
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

(01:11:52):
So you wind up as like, it's cool DLC stuff
plus this extra backup condition.
And simplicity hopefully can make those backup conditions
more subtle or flexible and make DLCs user
more user friendly and usable in other contexts, basically.
but yeah no i think those problems are also further mitigated by just using like a threshold

(01:12:17):
of multiple oracles providing the same data yeah yep yeah exactly um and that i mean bitcoin's
great at doing thresholds of signatures um simplicity can improve on that but like
in ways that matter no right um the bitcoin's really good at threshold signatures so that's
part of why dlcs are so exciting yeah well it's been awesome i'm gonna say it again i'm pumped

(01:12:41):
you guys i think yeah thanks university has been talked about for most of the time that i've been
paying attention and involved in bitcoin it was uh really cool to see that you guys got it on
liquid maiden and hopefully people that already have liquid liquid implemented into their wallets
start playing around with it. Obviously,

(01:13:03):
as you mentioned, there's
some development kits and
interfaces that need to
be built out, but it seems like we're finally
at the point where, all right, we can get cooking
with this stuff.
Yeah, absolutely. We've launched on
Mainnet. We have a high-level language
that compiles to Simplicity. You can use it today.
simplicity-lang.org
If you've been wondering,

(01:13:24):
should I pay attention to Simplicity?
Now the answer is yes. Finally,
the answer is yes.
Well, congrats again. Thank you for all the work and for coming and explaining this to us.
I hope at the beginning when I prefaced to the audience that you like to go down rabbit holes and explain things thoroughly.

(01:13:47):
You didn't take it as a dig.
I love speaking with you because the extent of the detail that you go into just really triggers my nerd, my inner nerd.
And I get giddy when you go down these rants.
So thank you.
And don't ever try to be brief is what I'm trying to say.
All right.
Thank you.
There we go.

(01:14:07):
I'll stop apologizing.
Yeah.
Thanks.
Any final parting messages for anybody listening?
No, I'm just going to repeat the website again.
Simplicity-lang.org.
And keep an eye on our GitHub as well.
GitHub.com slash blockstreamresearch
is where our Simplicity and our SimplicityHL

(01:14:30):
and Rust Simplicity,
we have a whole Rust library for building this stuff.
That's where all those things live.
If you want to get involved,
if you want to be a developer,
if you want to be a tester, that's great.
If you want to work for us,
we are we've got some simplicity related positions open uh so definitely keep an eye on our jobs
posting i forget the url for that now um or just you know shoot me an email shoot any of us an email

(01:14:53):
and we'll figure it out so so yeah thanks i will uh let me see company careers blockstream.com
slash careers if you're looking for those jobs uh perfect andrew thank you uh excited to see
what gets built.
Yep. Thank you.
Peace and love, freaks.

All Episodes

Episode Transcript

Popular Podcasts

New Heights with Jason & Travis Kelce

Dateline NBC

On Purpose with Jay Shetty

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}#648: Simplicity on Liquid with Andrew Poelstra

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}New Heights with Jason & Travis Kelce

Dateline NBC

On Purpose with Jay Shetty

All Episodes

#648: Simplicity on Liquid with Andrew Poelstra

New Heights with Jason & Travis Kelce