Key Takeaways

Andrew Poelstra’s decade-long work on Simplicity, a formally verifiable, expressive yet finite smart contracting language, has reached a milestone with its launch on Liquid’s mainnet. Built from a handful of mathematically defined combinators, Simplicity enables provable correctness, static cost analysis, and advanced features like covenants, vaults, custom sighash modes, and zero-knowledge proof verification, all without sacrificing Bitcoin’s scalability or decentralization. By deploying first on Liquid, Blockstream can safely test and refine real-world applications before pursuing integration into Bitcoin, with Simplicity HL providing a Rust-like interface to make development more accessible.

Best Quotes

“Expressive yet finite, that’s a good way to put it. We wanted something you can formally reason about, where you can prove it does what you expect, without blowing up validators or breaking the fee market.”

“It’s insane how many surprising behaviors are lurking in Script, little accidents of how opcodes were bolted on over the years. Simplicity’s formal model saves you from that.”

“Ethereum introduced an expressive language, but validators can’t even know a transaction is valid without running arbitrarily long code. That’s a trade-off Bitcoin would never accept.”

“On Bitcoin, we’d be laughed out of the room without real-world usage first. Liquid lets us experiment safely, it’s our proving ground.”

“You could implement vaults, zero-knowledge proof verifiers, custom sighash modes, or dynamic fee curves, all in Simplicity, all with formal guarantees.”

“Every time someone new tries to write raw Simplicity, they end up making their own higher-level language. Simplicity HL is ours, it looks like Rust but compiles to formally verifiable code.”

“The answer to ‘should I pay attention to Simplicity?’ is finally yes. It’s live, it’s real, and now it begins.”

Conclusion

Simplicity represents a careful, security-first path to expanding Bitcoin’s programmability, avoiding the pitfalls of other smart contract platforms while enabling advanced, verifiable use cases. Launching on Liquid allows developers to explore its potential in a live environment, test integrations, and refine tooling, with the long-term goal of bringing its formally provable contracts to Bitcoin itself. If adoption grows, Simplicity could unlock powerful new capabilities while preserving the network’s core principles of decentralization, predictability, and trust minimization.

Timestamps

0:00 - Intro
0:11 - "Brief” rundown of simplicity
16:13 - Bitkey & Opportunity Cost
17:51 - Smart contracts on bitcoin vs Etheruem
30:18 - Unchained
30:44 - Why liquid first
51:04 - Dev tools
57:51 - Road to simplicity on bitcoin
1:03:34 - Economic concerns
1:12:15 - Oracle problems and final thoughts

Transcript

(00:00) But on Bitcoin, there's always this worry that a user of Bitcoin just hoping to move money around might write these simple programs. We're not there yet. Andrew Pra, 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.
(00:25) I know it's been a long almost a decade journey for Blockstream. Yep. Yeah, for sure. We uh we got it onto the 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.
(00:44) So, I guess for anybody out there who's either newer to Bitcoin, unaware of simplicity, why don't we give uh a background? I was going to say brief background, but I like your verbosity, verbosity, and you go deep on it. So, I'm not going to I'm not going to um give any false promises to the audience. We're about to get an in-depth uh history on simplicity.
(01:07) It really starts in 2012 when Russo Oconor sort of sketched the design and then you guys decided to really lean into it in Blockstream in like 2016, correct? Yep. Yeah, that's 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 that.
(01:25) I don't know why I even bother saying it but I'll try to be brief. So uh at even before even before simplicity in 2012 there was uh Russell Okconor had been in the Bitcoin space. he showed up very early days uh 2010 I think maybe 2011 I think it was 2010 and he had this concept called mast merkelized abstract syntax trees and this eventually turned into what uh is now tap routt where the idea is that 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:01) apply under different conditions But they 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 Merkel tree? And so now you can have um hundreds or thousands or millions of conditions.
(02:20) And when you want to spend your coins at the time of spending, 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 Merkel tree is is you can do exactly that.
(02:37) It's this big structure where you can commit to arbitrarily large numbers of things um 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 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.
(02:57) uh 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 by having a bunch of if then statements and everybody's got to download the whole thing. So in tap routt we have that we have what's called the tap tree.
(03:16) You've got all these different scripts you can have if you want to do like a five of 10 multi-ig for for some reason. Um, one way you can do that is by taking all of the uh 10 choose five possibilities that you might have as a number of a couple thousand.
(03:34) Put them all into their own little tap branch and then whichever five participants you happen to have at the time of spending you you uh 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 routt much much later of course and simplicity kind of came out I promise this is relevant to simplicity. So the premise behind simplicity is what if we took that idea and we we really went to the extreme with it.
(03:59) So one big thing that simplicity has well first off simplicity is the way that it fits into Bitcoin and 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 as it is now.
(04:16) So you've got a tap tree, you've got all these different scripts and rather than using the existing Bitcoin script system, you use simplicity instead. Okay. And within simplicity you have these branches and these conditionals, right? So if 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 then allow these backup keys to be used or what whatever conditionals you might want then okay you've got these conditionals you you reveal whichever side that you actually take that's cool that's there's some efficiency there simplicity goes one
(04:49) step further and it says well conditionals are one way of composing two pieces of code or two programs, right? You've got uh some some sort of flag, some 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. Okay? 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.
(05:16) Bitcoin script is really good at this. What's called a concatenative language. You have a program, you run it, you just stick the other program right after, and you you run them. You run them in order. uh you might compose them by running both of your programs in parallel like on the same input and then somehow you you combine their outputs.
(05:33) There's there's a couple other things you might do. And it turns out that you can start with two different programs. 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.
(05:53) 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 any computation. This is this is something called the um the sequent calculus if you're into uh computer science or like historical computer science even. Uh it turns out you can build any computation just using these these um these two basic functions and these combinators.
(06:17) And that's the premise behind simplicity is that rather than having an opc codebased language where you have in Bitcoin script you know 70 or 80 op codes they all do different things. Most of them uh see the bulk of them just push things onto the stack but then there are others that can duplicate items. There are others that can compare them for uh to each other compare them to true or false uh do branches based on them.
(06:42) 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 and tap routt is is tweaked a little bit, but essentially it's checking a multi- signature.
(07:03) And then there are a couple variants of these. Um, there are things for lock times. Uh, and that's that's pretty much it, right? But the the whole premise is that you have these built-in this small set of built-in pretty complicated functionality that are all one op code 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 that's how you build programs.
(07:28) 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 or 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 right so even code that doesn't even get executed you 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
(07:58) got a Bitcoin script that is supposed to implement some sign of of crazy business logic and 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.
(08:23) Um the uh the the script has certain behavior until a certain time at which backup conditions become active. Those those kind of things. And it's very hard to do this with Bitcoin script because the way that every the way that you translate uh your your specification again I'm I'm glossing over I'm using the word specification in the interest of brevity.
(08:48) I'm not going to to say what a formal specification is but it's a thing you can make that describes exactly what a program should do. And to the extent you have a specification to turn that into code in Bitcoin script, it's 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 like push this onto the stack and push another thing and compare them.
(09:05) 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, 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.
(09:16) And then I'm going to do this. you know, you're 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 op codes, which do kind of complicated things. This is stack and which themselves are defined in terms of what does what happens in script/interpreter.
(09:46) cpp CPP in the Bitcoin core source code versus if you were constructing a program by starting with these two dead simple functions output nothing and the output what you give it function the the unit and the identity function and then combining them in these various ways and in total by the way in in simplicity you've got uh those two basic functions and seven additional combinators that's it that's a whole language nine combinators okay plus an extra one we add for witnesses and uh uh plus an extra one called disconnect that maybe we'll get into but okay 11 11 if I'm stretching
(10:19) um plus blockchain introspection but we we can also actually forget about because blockchain introspection is even though formally we have to extend the language to support like how do you get what the current lock time is how do you get the current amount amounts how do you get the current output amounts etc uh all of those are very simple right they're just op codes op codes combinators that take no input and and output whatever we're supposed to do.
(10:44) 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 me. It's in the laundry, but um you 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 sense.
(11:06) is simple in a formal sense that can be captured by things like the rock theorem proving assistant or the lean proof assistant or uh a language like Idris or F which has a a type system that is capable of supporting formal proofs and the idea here is that now if you well there there are two big ideas that 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
(11:41) simple enough to be be fit to these spec specification languages and then you can produce 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 um at worst no matter how this program executes how much space will it take on my transaction? You can answer that very cheaply and now you can bound your fee rates. You can you can do fee
(12:11) estimation uh very accurately for for arbitrarily complicated programs. You can say well I don't really know I'm I'm some counter signer, right? I'm I'm Blockstream. I'm the Blockstream app. I'm Bit Go. I'm I'm whatever I am. Uh I don't know or care what this code is supposed to do except that it shouldn't run without my signature.
(12:32) Okay? It say it's whatever the customer says plus my signature. How can 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 that's one big thing and that's huge for users.
(12:50) Um, 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. 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 script that somebody will discover that as near as we can tell nobody knew before where if you kind of poke an op code in exactly the right way then it will do something surprising. And let me give an an
(13:25) example of this kind of thing. um the if op code 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 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 ly long string of zeros except that also the leftmost zero
(14:02) is 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 byt stack with it. Okay, there's there's only one other op code that takes arbitrarily sized inputs like that and it's if dup which is the same and not if. Okay, it says three.
(14:21) All these if op codes for some reason take arbitrarily long inputs even though nothing else will accept arbitrarily long inputs. Um, 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, uh then you could create a signature that evaluates to false even though every real signature that somebody produces would evaluate to
(14:50) true. And it turns out that you can you can't produce an ECDSA signature this way because there's encoding rules that that just force you to set other things to one. You can produce a Schnore signature this way that will parse as a Schnore signature, but it won't validate because when we added Schnore signatures to Bitcoin, we designed them such that you cannot produce an arbitrary signature and then back compute what your your keys and your your message have to be.
(15:19) In ECDSA, you you can do that with something called public key 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.
(15:37) Uh, and then there's kind of these like weird accidents of how certain op codes interpret their input and they uh they interact in crazy ways. And this is part of why it's so hard to get these things into Bitcoin scripts, right? is that you can propose something like opc cat which is three lines of code is dead simple but how do you know how it fits into the system? How do you know all of the behavior? It it takes so long and and so much uh mental energy to convince yourself that uh that this simple looking function is not going to do surprising things and and simplicity by being the simple formally specified model saves you all of that effort. So I'll stop freaks.
(16:14) This rip at TFTC was brought to you by our good friends at BitKey. Bit key makes Bitcoin easy to use and hard to lose. It is a hardware wallet that natively embeds into a two or three multisig. You have one key on the hardware wallet, one key on your mobile device and block stores a key in the cloud for you.
(16:37) This is an incredible hardware device for your friends and family or maybe yourself who have Bitcoin on exchanges and have for a long time but haven't taken a step to self-custody because they're worried about the complications of setting up a private public key pair, securing that seed phrase, setting up a PIN, setting up a passphrase. Again, Bit Key makes it easy to use, hard to lose.
(16:54) It's the easiest zero to one step, your first step to self-custody. If you have friends and family on the exchanges who haven't moved it off, tell them to pick up a bit key. Go to bit.world. Use the key TFTC20 at checkout for 20% off your order. That's bit.world, code TFTC20. Sup freaks, guess what? We launched a browser extension.
(17:13) It's called Opportunity Cost, and it helps you see the true cost of everything in Bitcoin. Convert prices to Bitcoin as you browse the web. Opportunity cost automatically displays fiat prices in Bitcoin or SATs, helping you think in a Bitcoin standard. It works on Amazon, Zillow, X, your bank account, QuickBooks. So, you can convert everything to Bitcoin. It's really cool. It's also 100% open- source MIT license.
(17:36) We don't collect any data. All of the conversions happen in your browser on your local device. It's a great way to recalibrate your life and begin thinking in SATS. Go check it out at opportunitycost.app. That's opportunitycost.app. So just building not only comparing it to Bitcoin script as it stands today, but like I I guess I think many Bitcoin developers would look at something like how Ethereum's implemented 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
(18:14) you just described within Bitcoin specifically like op codes are 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 described, when you do that, it's sort of clunky and you create um a burden for somebody trying to build something. It's very hard to audit and know exactly what it's going to do.
(18:39) And so simplicity just tries to be expressive yet finite um without having to have all that like complexity built in. Is that correct? Yep. Yeah, exactly. And expressive yet finite. That's a good way to put it. Um so yeah, EVM took Bitcoin script and just bolted on everything we want to be able to do just bolted onto Bitcoin script more or less. Um is is roughly how EVM is structured.
(19:03) Um and then they realized that the Bitcoin stack language is is not a good model for that. So they they have what they call rich statefulness where you've got these series of like global database lookups that uh so every contract has a bunch of code. It has variables. It can save and it can update and all this good stuff.
(19:22) But it is very difficult to reason about. They kind of inherited the difficulty in reasoning about Bitcoin script and and in some ways made it much more complicated. Uh they also did some kind of unnecessary like in addition to to extending it computationally.
(19:40) They also added this rich statefulness notion where you have these global key value lookups and everything becomes very stateful which 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 as being touring complete and that the idea behind that that phrase is that a touring complete language can do anything at all.
(19:59) A non-ouring complete language is is kind of uh narrow and and domain focused is the the intuition right. So as an example right uh a programming language like JavaScript or like Python uh is touring complete. You can write anything that you can express you can write in those languages. A language like HTML is not HTML can only uh produce uh draw web pages basically.
(20:20) Um some things would surprise you to learn that they're actually turning 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 turning complete because there are like conditional stylings that you can put in and then the loops and stuff.
(20:38) Uh Postcript which is a document formatting language that predates PDF is touring complete. Um, and I've I've exploited that to uh to do some paper computer kind of projects. Um, there are there's a whole pile of of languages that really shouldn't be tingcomplete, but but accidentally are. and Ethereum more or less is is on purpose.
(20:59) But there's there's a small caveat there that strictly speaking to be a touring complete language, you need to have an an infinite amount of lang of of memory and and an infinite um or 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.
(21:17) Uh and then on Ethereum, you're bounded by this this quantity called gas. Okay, so you write a Ethereum transaction. You decide how long you expect the transactions uh contract code to run for uh and then you set a gas budget based on that which is 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 is that when you're trying to estimate how much gas your program is going to take, you can't do that in general.
(21:48) And so there's these whole uh 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 than is available, which means that you effectively cannot call those.
(22:04) So there there's functionality that you 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 is valid, whether or not it's used uh all of the gas that it's been allocated is by running it.
(22:25) You start running the script, you figure out um 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.
(22:42) Um, you already did all the work to do that. So, somebody could just give you a program that like ran for a minute and then failed. Well, then you'd be be turning away for a minute, right? Um, and maybe you limit yourself per transaction, whatever. A bad guy gives you a million transactions that all take, you know, a microscond. Now, you still wasted a second.
(22:59) 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.
(23:15) They just burn gas and do nothing else. And these are almost certainly accidental uh because there's there's no reason for you to just burn gas the way that uh the way that I'm describing. And the way that Bitcoin avoids this problem in Bitcoin, if a transaction is invalid, it's invalid.
(23:32) It doesn't go on the chain is that in Bitcoin, there's kind of a a neat trick we use, which is that every op code takes one bite to encode. So, Bitcoin script has no loops. So, every op code can be executed at most once. You can't go back and then redo stuff, which means that if you see a bite, you know that abs the absolute worst case that bite represents a single op code of work.
(23:57) And so you take the whole size of your transaction and you use that to swag how expensive that transaction will be. 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 bite 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.
(24:15) 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. And then miners and validators kind of order things, but which has the highest fee per weight kind of thing. This is cool. This is this is pretty cool.
(24:33) But it uh there's an obvious question then. Well, what if we want to like surely we want to put loops and like go to like some way of doing this kind of stuff into Bitcoin, right? Are we just like forbidden from ever having a way to execute an op code more than once because then it would break this like how much uh uh the size of the transaction representing the computational cost kind of model.
(24:53) Um, and in Ethereum, their 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, you can scan through the program one bite at a time, technically, one bit at a time, and you can determine the maximum execution cost.
(25:21) 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 uh a subprogram or an op code, however you want to to think of it, that runs exponentially often.
(25:40) 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 it was, you know, the validator will say, "You know what? A trillion is a lot.
(25:59) You can't you can't fit a trillion op codes into into a single block kind of thing." Um, but importantly, even though you have this kind of arbitrary blow up um between the size of your program and the actual cost, you still only have to scan the small one.
(26:18) You have to scan the bytes of the program to figure out what that cost is. And we call this static analysis. We call that 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's whether it should be prioritized or or whether it's never going to get into a block and we should just drop it without ever having to execute the code.
(26:42) And we do that while still getting this arbitrary amount of execution. And the reason this is possible is because what you're encoding in your program is actually a composition of all these basic um 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.
(27:08) But it turns out you can still get arbitrary um 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 if 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 kind you kind of do that kind of analysis over and over.
(27:30) Now, people who are CS nerds or maybe just listening to me far too closely might be kind of suspicious about my claim that you can do loops uh that you can sorry that you can do an arbitrary computation in simplicity and that you don't have a looping construct or a go-to construct.
(27:53) And I'll briefly say something about that which is that there's actually another form of composition which is not sequential or conditional or parallel or or these these kind of basic things called recursive composition. And that's where you have a function that's able to call itself and and basically do a loop, right? Go back. So simplicity does support this through this extra combinator we call disconnect.
(28:14) But it supports it in kind of a clever way where in principle you can put an arbitrary number of of loops into your program at the time that you define it at the time that you uh construct your address that represents your program code.
(28:35) But when you actually go to spend it, you are required to unroll the loop however many times you actually execute it. So disconnect commentator 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 you don't have to write the same code 20 times in a row.
(28:52) Uh the encoding of simplicity will collapse it into a single copy but the static bounds are still able to see that it's executed 20 times and assign it a cost of 20. So in the end what hits the blockchain is in fact finite is in fact built up.
(29:12) The what hits the blockchain essentially does not have this recursive um uh uh way of combining of of composing computations. In the end when you put it on the chain you have to enroll it and then it's just 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.
(29:36) 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 comput how long that computation took in order to put it on the chain. Otherwise, you can't even encode the result. Like it's just like a nonsensical transaction.
(29:54) So, so you the transaction creator get this full expressivity but validators don't have to deal with that expressivity which uh which they don't need right like a validator knows if your transactions going on chain your program has to succeed right it has to be valid right that that's like the one thing validator's 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 as cheaply they want to do that as cheaply and as predictably as possible Serious about your Bitcoin? Start acting like it. Unchain just launched the financial freedom bundle, a curated pack
(30:25) that includes a premium Bitcoin book, a new hardware wallet guide, and access to a private macro event with Tur de Mester legend. It's time to take control of your generational wealth. Go to unchained.com/tc to request yours. That's unchained.comTFTC. Pretty hot package, freaks. Go pick it up. Yeah.
(30:51) So in short, you're basically just guaranteeing expressiveness with like 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. Yeah, absolutely. Thank thank you for zooming out so much. That's exactly it, right? Um, 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 it's doing something predictable that's not going to blow up people's computers or
(31:21) crash. When you're writing code, you want to know that your code that you're writing does what you expect 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.
(31:38) And with with simplicity, we we've managed to do this in a model where we get the full expressivity of something like EVM or or uh cholisp or or any of these languages that are out there that you do arbitrary computations while preserving these goals. Yeah. And I I think this has been a big a big theme in Bitcoin for the better part of 8 years now or 9 10 years since Ethereum launched specifically which is like Bitcoin is an extremely important project.
(32:13) We're trying to separate money in states and at this point it's a 2.2.3 two$ two.3 trillion dollar market and is incredibly important that we make sure that the system doesn't fail. And so with that in mind like we have to make sure we build things correctly so that protocol the network and say stays sufficiently distributed and it actually achieves the goals it's set out to 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 like we're faster we have more features than Bitcoin and all the while Bitcoiners myself included and I I truly
(32:50) do believe this and it seems It's beginning to manifest. Have been saying it will eventually come to Bitcoin. We're just going to do it the right way. And it seems like that's what you guys have been working on at Simplicity for a decade is doing it the right way. Yeah. Yeah.
(33:08) Um everything everything Ethereum added, everything these other chains added, right, comes with some trade-offs. Um and some of those are are more reasonable than others, right? So a lot of these things have much faster blocks than Bitcoin. Um, and I think if Bitcoin had been developed, if in 2008 somehow Satoshi had uh compact blocks and and minis sketch and all of this like peer-to-peer propagation tech that we have today, probably we would have faster blocks, right? There there's certainly a trade-off between fast blocks and decentralization.
(33:31) Um, and it's not um, you know, it's not inherently obvious that that, you know, the 10-minute block was was a perfect optimal thing, but then there are other things that are just clearly very very bad trade-offs, right? and Ethereum introducing uh this super expressive language was a trade-off 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
(34:02) transaction is once they've even validated a transaction they can't know that it 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.
(34:26) And even if it appears while the transactions on the peer-to-peer network that that it was legit, maybe it turns out not to be legit because because things changed. Um those that's a terrible trade-off, right? Like we we would never have accepted an extension to Bitcoin that added some sort of looping facility with these kind of problems.
(34:45) We would never have accepted an extension to Bitcoin that allowed you to introspect a transaction in a way where if the transaction appeared in a block in a different order or was reorged like back a block or two, then it would suddenly become invalid and invalidate all the work that people did to cach the transaction validity. Um, we would never accept any change to Bitcoin that changed what we call monotonicity.
(35:05) Once a transaction is valid, it stays valid forever with the one exception of it 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 and keeping an eye on them. Um, those are terribly obviously terrible trade-offs.
(35:22) um we would never accept a a um extension to Bitcoin that had rich statefulness that had a global key value store of all this contract code 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 like terabyte size database that you've got to you've got to go through and so running a a full archival node on Ethereum. Well, Jameson Lop I think did some some work trying to do this like five or six
(35:59) years ago and it was I don't know I don't know that he succeeded. This it's definitely worth looking up and and things have gotten even worse since then. So that 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 um you know failed to validate something and then somehow you just got off the 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. So those those kind of things I would say are obviously
(36:29) bad trade-offs 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 of those choices, right? Not just like could we have faster blocks, could we have bigger blocks, what if we used uh pub recovery in in certain places, what if we structured our transactions, even what if we had accounts versus UTXOs.
(36:53) I think you can make arguments for both. I think they were they were clearly wrong about that, but it's just a much more subtle thing. But the rich statefulness and the loops and the the inability to cash transaction validity, these these are just fundamentally complete non-starters for Bitcoin, right? And that's that's a big part.
(37:13) 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 op code and by like abusing it to like fold back in on itself and like run through the signature.
(37:32) It's like it's crazy the kind of hacks that we have when um kind of to 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.
(37:51) Um it's hard to preserve the properties that Bitcoin has that make it scalable and decentralized while getting this extra expensivity. Yeah, and you said the word scalable there. So, this has obviously uh gone live on Liquid's mainet, which is a federated side chain. Blockstream's 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 this this unlocks whether it's covenants and vaults uh onchain 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?
(38:35) How does it work on liquid specifically compared to how it could potentially work on Bitcoin at the protocol level if it ever does in the future? Maybe we could talk about if that's even a good idea. Um, and what you expect to see get built. Sure.
(38:54) 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. Uh, October 2018 was was our launch date. Uh, Liquid is what's called a federated side chain. There are a set of 15 mutually distrusting parties like spread across the globe uh who together every minute 11 of those 15 come together to sign a new liquid block.
(39:18) Um and so liquid well liquid is a side chain. So in addition to being this this kind of blockchain that has this federated signing model is a side chain meaning that it's possible to move bitcoin from the bitcoin network onto liquid and move it back. And the mechanism by which you do that is uh is you know a little disappointing I I would say right which is that you you literally transfer the bitcoin into custody of this 15 member federation and then any 11 of those are responsible for moving the money back when you request it uh on the liquid blockchain. So that's that's how the pay in and pay out mechanism work there and
(39:50) the liquid has made liquid has also made a couple trade-offs that that are no-go for for Bitcoin for sure. So, one is a federated model, right? This just completely alien to the the uh uh Bitcoin uh proofof workbased security model and everybody has has well everything comes down to proof of work ultimately in Bitcoin.
(40:13) Um as well as not your keys, not your coins, right? So, even 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 is kind of nice. Um so, that's one. Another trade-off that Liquid made that Bitcoin never would is that it has multiple assets that are native on the chain.
(40:30) And the reason Liquid can do that is because Liquid has block signers who are not being paid in kind. So, 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.
(40:53) You can't have econom economic activity that's happening in other assets at least not to to a significant degree that would 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.
(41:10) Liquid by virtue of being smaller and by virtue of being developed by by blockchain is something that we can do cool crypto experiments on much faster than we can on Bitcoin. And here's really you said why liquid? Why liquid? We know liquid and we can do stuff fast on liquid. Um so liquid historically has has been um kind of a a demo for many things that that wound up on Bitcoin eventually.
(41:33) So Liquid or I should say the precursor to Liquid what we called Elements Alpha had SegWit before Bitcoin had SegWit. Um and actually it turned out the fun history there that the version of SegWit in Elements was like 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 Lop and and Sippa and and all these people kind of pulled together and
(41:57) produced SegWit on Bitcoin, which we all know uh we all know and love. And then we pulled it back into Liquid. They were like, "Yeah, that one's way better than ours." So So that was a cool back and forth. Uh, Liquid also had check sequence verify, uh, which is how you do lock time checks in script before, um, uh, before Bitcoin did.
(42:16) Um, 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 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 uh scalability trade-off that the liquid chose a different place that that wound up being pulled into Monero for example.
(42:46) Um and uh and so now we're working on simplicity right and so we took simplicity the nine or 11 if you want combinators that uh that define the language. We added a few extra bolt-on facilities for introspecting liquid transactions which uh actually would be much harder than doing the same thing on Bitcoin and then we deployed it there as a taple leaf version. So liquid has taproot.
(43:13) Um the frustratingly Bitcoin got tap routt before liquid did and we were like internally like everything's harder on liquid because we have multiple assets and we have confidential 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.
(43:29) Um but okay we we have we have tap routt we have tap routt on liquid now um so within a tap routt output on liquid you can choose um for every every script you choose either to use scripts or to use simplicity and well and there you go that's that's how it fits in right and the trade-offs that we make when before before I jump into use cases right so so why why did we do that on liquid and why couldn't we just turn around and do it on on Bitcoin well um simplicity is an entire replacement for the script interpreter, right? It's this giant blob of of C code uh which is
(44:01) is uh you know several thousand lines at least. It uh it has some some cool complicated things where it identifies programs by these these Merkel roots. It like builds this abstract tree of of how your program is constructed and and combined at a smaller thing computes these Merkel roots.
(44:19) It has a type system and a type inference system. Uh it has this notion of sharing that allows you to collapse repeated pieces of code into one. And it has these new consensus rules related to how sharing has to be enforced to ensure that uh uh certain kinds of transaction malleability are eliminated and certain kinds of denial of service vectors are eliminated.
(44:43) 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 it's a new model and it's it's a scary thing and we wouldn't even we'd be laughed out of the room if we even propose 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 uh approval from the 15 functionaries they all all these participants think that it's a pretty cool thing um liquid Well, 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,
(45:17) 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 federated like that is not I really like it's not going to happen.
(45:43) And it's like not like I'm I'm not suggesting that we would deploy something where it's possible, but if it did, we would pick up the pieces and 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 uh backed by bitcoins and and uh 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.
(46:05) So um so we 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 the real world outside of liquid. Um this is a place it's deployed on a blockchain that's got some kind of neat asset features which are are useful for demonstrating simplicity.
(46:28) Uh and we can we can start to learn how simplicity behaves on the blockchain. So, as you hinted at, um, 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.
(46:46) Uh, that gives you kind of rate limiting kind of stuff. Um, those are those are kind of the big ones. It gives you um uh 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 and so that the recipient pays for fee in this model uh which which um greatly improves the incentives around exchange withdrawals and setting network fees. You can do all those kind of classic constructions on Bitcoin. But then because simplicity
(47:18) 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 um um kind of like code that checks arbitrary cryptographic instructions, arbitrary Merkel roots, uh these kind of things.
(47:43) You can write kind of like weighted threshold constructions where you say if um this is going to be a two of three multi-ig 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 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 sig hash any prep out as like this extension that would allow lightning to be implemented with with backups that that aren't growing
(48:17) linearly, right? Uh in simplicity, you can just implement sig hash any preval. 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 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,
(48:53) only going to a certain destination, you know, I can kind of sign the the highle parameters um of the transaction and then 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 up front, right? In in my script code, what I say basically is if Andrew's key is signed some conditions and the kid's key needs to um needs to to follow needs to sign the whole transaction following those conditions, right? And a story and you can imagine like less personal, right?
(49:22) um uh 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 of business logic and you uh you can implement that directly in simplicity 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.
(49:53) 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 you write a transaction, it doesn't confirm rather than you having to resign it, um, you can just like or anybody can just kind of edit the transaction. Maybe there's a second party with a weak key who has to resign it, which you probably won't.
(50:16) um you don't have to go get your keys out of cold storage to resign it with a higher fee rate just by dent of being old enough and having not confirmed to spend the new higher fee rate becomes valid with your original signature and you can you can define these kind of ramping up signatures kind of stuff.
(50:33) So, uh there's a whole pile of stuff that uh that really nobody is talking about on Bitcoin because you you really need this this total arbitrary computational ability to do these kind of things on Bitcoin. And even with something like Russy's great strip restoration project, some of these are are too out there to to describe like having these exponential ramp up curves of um of allowable fee rates or having or trying to do like zero knowledge proofs or or giant Merkel tree reductions or you know all this kind of crazy stuff. some. Yeah, it's fascinating. And you guys
(51:06) have built what seems to be from the outside looking at it, I haven't played around with it, uh, but like a sort of a 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.
(51:32) So simplicity itself um it sounds so wonderful. It sounds so simple when I I say it in these high level how 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 this programming model and how difficult it is to to construct these programs um that they like turn around and write their own programming language that compiles down to simplicity. It's kind of funny. This happened like three times uh in a row.
(51:57) And uh the the latest iteration which we're letting the public use that we really want to be out there and usable is is simplicity HL as you say. So while simplicity is a very lowlevel like you know contort your computation into this composition of identities and units uh kind of construction. Simplicity HL looks and feels like the Rust programming language.
(52:22) Um, 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. Um, do this, you know, loop this many uh loop over this, you know, at most this many times kind of thing.
(52:41) Um, and that that at most restriction is is because these programs are finite. We we would like to remove that using the disconnect op code, but there's there's there's more work to be done behind the scenes there. Um, so simplicity. So you can go to simplicity-lang.org work is is where our our sandbox and our 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 and compile it to Simplicity see what it looks like and so on and simplicity HL we expect will be the way that people interact with Simplicity programs um until somebody makes a better language than simplicity HL that
(53:14) that also compiles down to it um so yeah so so directly interacting with with simplicity that's that's for compilers and for proof assistance, right? It's really not for humans because it's it's such a so low level and and such a a strange way to think about computation.
(53:34) 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 these other functions and have modules and stuff. Well, we don't have a module system and we don't have libraries yet.
(53:52) like you just got to kind of write all your code and you can break it into functions, but it's all just like one giant file with all your functions listed. So, so that's not great and we'll we'll hopefully have that addressed in the 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.
(54:11) It has to turn into something bounded and we still want to make sure that we're 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 sig hash any prevout you can't do that in simplicity hl unfortunately because we don't we haven't exposed enough of the like low-level sig hashing kind of mechanisms and
(54:44) But um if you want to write a zero knowledge proof verifier, you totally can. If you want to write uh any of the crazy like delegation code that I described, if you want to write a program that restrains your fee rate to some sort of curve based on the age of your coins, you can totally do that.
(55:07) Um although I think parameterizing it by the signature, I think you can do it. I'd have I'd have to to think about that for a sec. Um there most of the things that I described in my my description of things. If you want to implement vaults, you can totally do that. If you want to implement um delegation, you can totally do that.
(55:25) Um all the kind of like big covenant applications that are out there, you can totally implement today. Simplicity HL. So we uh we have the compiler. You can you can produce Simplicity code. We've got a a tool that will produce addresses from that. um 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 front like the userf facing tooling to do cool stuff like this um that we've got to build that into wallets over over the coming weeks. That's not something that today as like a user of Bitcoin
(55:57) just hoping to move money around and like write these simple programs. We're not there yet. Um, but we're certainly at the point where where wallet developers who say, "I want my users to be able to do these arbitrary cool things will will have the toolkit to to make that possible." Yeah.
(56:16) And on that point, like who's out there? You have Aqua, Bull Bitcoin's implemented, Liquid, uh there are a few others. what uh from have you guys been having conversations with these wallet developers and what are they most excited about? Yep. Yeah, for sure. So, there's a couple people I'm not sure who all I'm allowed to to talk about here.
(56:40) Um the uh so one one big one that you can find on GitHub and they'll um I don't know when this podcast is 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 that's personally I think the coolest thing that people are building.
(56:58) Um and then as far as as wallet development goes, what we're uh we're in the very early stages. What what we're hearing is that we need to implement Simplicity. We need to integrate Simplicity into for example LWK the liquid wallet toolkit. Um we've got to 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 like how do how do I make it real um and
(57:32) there there's a couple layers of integration work that we are uh we're putting together in particular integration into LWK uh because that's that's the wallet toolkit that's what lets people you know connect simplicity to real UTXOs that that the wall is taken care of. Yeah, it's exciting stuff.
(57:52) Then is your hope that there will be an incredible amount of development activity around simplicity on liquid and then sometime down the line it'll prove to be sufficiently robust, expressive, finite, secure that a conversation will begin to potentially implement on the Bitcoin protocol or is this something that should exist on a second federated side chain like liquid.
(58:22) No, no, we we'd like to go towards Bitcoin. So the uh it's a long we've got a long road map 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 this language. We've got a front-end language. We've got a compiler. We've got this command line tooling.
(58:47) 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 a wallet supposed to like figure out how to work with covenants? How is a wallet how is a wallet supposed to do anything? Is this whole So that's what we're doing right now on the lowlevel like simplicity on liquid.
(59:12) Uh how do we get it past liquid? Is 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 it's still the UTXO model, right? Um still you work with wrapped Bitcoin. So it's it's the same currency.
(59:30) Uh but in other ways it behaves quite differently because of the multiassets and because of uh confidential transactions are the two big things. So our next big plan is that we are working on the Bitcoin integration branch right now. Actually you can go to the Simplicity repo there. There's a branch that's that's reasonably up to date. It should be up to date as of today.
(59:52) 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 to one of the more uh experimental uh test networks out there. Right. So, so, so as people may know, right, there's Bitcoin, the main net, and there's this this thing called test net 4, which is like the official Bitcoin test network that exactly matches what's on Bitcoin.
(1:00:17) But then there's also something called Signet, which is this signing based uh network that um has signed blocks. It matches Bitcoin, but with a few proposed extensions to Bitcoin that people want to experiment with. And then there's mutinet which is like signet but like even more just like let's just put crazy stuff on here that like we really want to see what would happen. And then it turns out there's like even more of these networks out there that some of which are are pretty widely used.
(1:00:43) And uh a couple months ago I was talking to Jeremy Rubin who's who's one of the main um developers or admin kind of people for one of these networks. And I I said this to him. I said, "Yeah, we're going to propose it to Signnet, but uh no, maybe, but then then we'll try mutiny and then that seems more likely and then we'll try." And he says, "Put it on mine.
(1:01:02) Do you have a branch? I'll deploy it right now." And I laughed. This is like in April, right? I said, "We have a branch, but don't don't do it." Um it was it was super cool to get that kind of enthusiasm. So, we're we're very confident that we'll we'll be able to find uh uh one of these these test networks that is based off of Bitcoin where people really want to deploy simplicity.
(1:01:26) And then that's where um that's probably where we're going to start seeing like experimentation from the the wider Bitcoin community and like cool like can we so I said we can implement any sash any prevote in simplicity well is anyone going to actually do it uh can we try to use simplicity as a specification language for any prevote or for opcat or for ctv or any of these proposals in principle you can implement them all in simplicity and doing so has the benefit that then you can say this is exactly the behavior of my proposed op code and you you uh your QA problem of how do we know it's
(1:01:59) 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 is a more tangible target. Um, that's the kind of exciting stuff that that I'm looking forward to seeing. And and right now with a 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 endtoend stack, what all is involved in doing a full deployment of something novel using simplicity doing a full uh full end to end stack. And
(1:02:36) frustratingly, like like with all such things, it's bigger. It's bigger than we expected, right? We're we're a small team right now. Um the Simplicity team right now is is four people. Um and uh and and one of us is not even a developer. And we're uh we really thought we could get all of this pulled together. Um we thought we could do it even sooner.
(1:03:01) Uh but it it turns out that that um there's a lot more to writing a blockchain language than just writing the the blockchain validation code. Um ironically, the uh all of the the low-level consensus code, the stuff that we fight so much over on Bitcoin is actually the easy part of uh of any of these things when you actually want it to to change things for real users.
(1:03:20) So So yeah, we're excited. This is like this is a huge step. like despite me like oh we're still in the early days this is a huge step getting this launched onto liquid and this is this is what lets us start um now it begins basically but uh but what's beginning is a pretty big project so it's been a 13-year journey from paper and well you said even longer from math to here yeah 15 days if you look at it that way and so many people will hear like simplicity if it ever makes it on Bitcoin will enable all this stuff and get worried that it uh it will disrupt
(1:03:54) the fee market have all this perceived junk onchain. Does implementing this stuff via simplicity sort of uh prevent like like you said like you know exactly what's going to happen. You have that certainty. Does that prevent unknown consequences that many people surmise these individual op codes if added will introduce to the network? Yeah.
(1:04:22) Yeah. Um no it will not prevent it but using simplicity as an upgrade mechanism should make these things tractable and manageable. So let let me try to uh so let me first say is that if we want no MEV and no like none of these kind of risks that people will find a way to like build new assets on the Bitcoin kind of thing then probably we can't do any extensions at all right like it seems like almost everything we do and even maybe doing nothing still makes it possible to do these these kind of elaborate things But
(1:05:02) one nice thing is that the reason one reason this stuff is such a problem on chains like Ethereum or Salana is that the easy path the easy path for wallet developers is one that enables these kind of things that Ethereum really um encourages the creation of dexes that enables front running and contract code where the behavior changes based on your reordering of of transaction. The account model also contributes to that which Bitcoin doesn't have.
(1:05:35) So if we were to develop code, if we were to have a simplicity interpreter as a mechanism for adding 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 that wherever 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.
(1:06:00) Here's how I can bound the total size of my witnesses so my fee rates are manageable. And here's how I can change my code to tighten that bound to improve predictability. Um, because a a fortunate economic truth, right, 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 it's just difficult to design these giant complicated systems.
(1:06:26) But but if we give people the tools to avoid meth then they will use those tools because it's valuable to them. You know that that's very fortunate because sometimes sometimes in economics you get the opposite where it's like your incentives are inherently stacked against you and then that's a that's a very difficult a very difficult problem. Um then your problem becomes like how do we just ban all bad behavior? How do we make it impossible to do anything bad because the incentives are are so awful? But but fortunately with things like no they're not.
(1:06:52) Um, will simplicity related to ME, 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 make it any more possible than it is today.
(1:07:18) So, I've been surprised and and kind of disappointed at how much ordinals took off where ordinals or sorry um inscriptions which which are based on on ordinals um where there's no Bitcoin script um functionality being used at all for encriptions.
(1:07:43) 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 um you know some somehow or other just the virtue of how they were created on the Bitcoin chain 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
(1:08:17) actually what's blocking this stuff is not extra functionality, right? What's blocking this stuff 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 uh uh behaviors. And then that will make Bitcoin be used for Bitcoin.
(1:08:45) 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 um that miners are being paid in and that that are incentivizing miners to continue the chain working correctly.
(1:09:07) So my feeling is I'm not an oificationist. 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 extracript expressivity projects, I think the simplicity is a really good way to go in that direction. Um, 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 is pretty much the only way to go where we would we would preserve the ability to to reason about
(1:09:47) transaction code while while having these extra abilities. Yeah, that that makes sense. Like so you en simplicity enabling like one of the examples I've been a big big advocate of for years hasn't uh hasn't hit the scale or adoption yet but like something like DLC's where you have like these external events that are basically feeding data to a conditional transaction sending Bitcoin one way or the other depending on what the conditions of the particular contract are.
(1:10:24) like you can see people building financial sort of products on top of that denominated in Bitcoin which make a lot of sense to me. Yeah, DLC's 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 I think in part because it's technically difficult to build big stuff with DLCs, right? Like it's a pretty uh that's clunky, right? Yeah.
(1:10:48) Yeah, that's a good I was going to 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 DLC's. Uh but those are super cool. Um and simplicity in some ways 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 in simplicity.
(1:11:21) Although the one crazy thing that DLC's have that almost nothing else has is that 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 or whatever kind of insurance/gambling product you're trying to to build with it in um um with DLC's You can use that in your script and you can't the person making the signatures can't tell property that you get which is that you can use these signatures without um without having to reveal that you're using the signature. So that the person producing the signature can't
(1:12:02) like come after you and say like you were using our signatures in violation of our terms of service or like we don't like the particular construction that you did or or what. So um I'm gonna stop because your screen has locked up. I saw it stop for like 10 like 10 seconds during DLCs, but I think Okay, perfect.
(1:12:21) The um so you were just explaining there was like this oracle problem that exists. Yeah. Yeah. So, let me the brief summary is right simplicity can do oracles directly. DLC's do oracles in a way where the oracle can't tell even after the fact that you're using their signature. Yeah.
(1:12:40) So that's a really cool anti-censorship property that the DLC's and a lot of these kind of like tweaking signatures kind of tech has super cool. Um and what where simplicity will help that stuff I think is in the unhappy case. Um, so, so a lot of the the kind of trick with a lot of these DLC type constructions and adapter signatures and PTLC's and all these related things is that they as long as the parties are both online and following the protocol correctly, they work perfectly.
(1:13:13) And then if somebody goes offline or is providing inconsistent data or somehow misbehaving, you got to have this backup condition, right? And you DLC themselves can't do it, right? So, so you wind up as like this cool DLC stuff plus this extra backup condition and simplicity hopefully can make those backup conditions more subtle or flexible and make DLC's user more user friendly and usable in in other contexts basically.
(1:13:50) Um but yeah no I think those problems are also further mitigated by just using like a threshold 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 is really good at threshold signatures. So So that's part of why DLCs are so exciting.
(1:14:09) Yeah. Well, it's been awesome. I'm going to say it again. I'm pumped for you guys. I think has been talked about for most of the time that I've been paying attention and involved in Bitcoin. And it was uh really cool to see that you guys got it on liquid maidenet. And hopefully people that already have liquid implemented into their wallets start start playing around with it.
(1:14:35) Obviously, as you mentioned, there's some development kits and sort of 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. Yep. Yeah, absolutely. We've got it's launched on mainet. We have a high level language. It compiles. the simplicity. You can use it today. simplicity-lang.org.
(1:14:55) Um, if you've been wondering like, 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 I hope at the beginning when I prefaceed to the audience that that you uh like to go down uh rabbit holes and explain things thoroughly, you didn't take it as a dig.
(1:15:26) I love speaking with you because the the extent uh of the detail that you go into just like really triggers like my nerd, my inner nerd, and I like I I get giddy when you go down these rants. So, thank you. And don't ever don't ever try to be brief is what I'm trying to say. All right. Thank you. There we go. I'll stop apologizing. Yeah. Thanks.
(1:15:49) Uh any any final parting messages for anybody listening? Uh no, I'm just going to repeat the the website again. Simplicity lang.org. Simplicity-lang.org. Um and uh and keep an eye on our our GitHub as well. github.comblockstream research um is where our Simplicity and our SimplicityHL uh and Rust simplicity. We have a whole Rust library for building this stuff.
(1:16:08) That's where all those things live. Uh if you want to get involved, if you want to be a developer, if you want to be a tester, uh that's great. If you want to work for us, we are we've got some some simplicity related positions open. Uh so definitely keep an eye on our our jobs posting. I forget the URL for that now.
(1:16:24) Um or just, you know, shoot me an email, shoot any of us an email and we'll figure it out. So So yeah, thanks. I will uh let me see company careers blockstream.comcareers if you're looking for those jobs. Uh perfect. Andrew, thank you. Uh, excited to see what gets built. Yep. Thank you. All right. Peace and love, freaks.
(1:16:46) Freaks. Thank you for listening to the show. I hope you liked it. If you did like it, please make sure you subscribe, rate, review the show. It helps us out a lot. And also, if you like these conversations, I've come to realize that many people listen to the podcast, they don't know we have another sort of layer of this media company. We had the newsletter, the Bitcoin brief. Go to tfttc.io.
(1:17:07) Make sure you subscribe there. A lot of the topics that are discussed on this podcast I write about 5 days a week in the newsletter. We also have the TFTC elite tier. If you sign up for that, become a member. We have a private Discord server for the elite freaks out there where we're dropping adree versions of this show and having discussions about everything we talk about a day early.
(1:17:37) Logan wanted me to make sure if you want to get the show a day early, become a TFTC elite member. You will get that. We have our Discord server. Right now, it's conversation between myself and TFTC elite tier members, but we're going to expand that. We'll probably do closed Q&As's with people in the industry. Uh I may be doing macro Mondays. So, join us. Go to tftc.io. Subscribe.
(1:18:01) Find the button in the top right corner of the website. become a TFTC elite member. Thank you for joining us.

Spread the signal,
earn Bitcoin.

Get your unique referral link when you subscribe.

Learn more →