Simplicity Comes To Liquid

Hi everyone and welcome back to Stephan Livera podcast. Joining me again today is Andrew Poelstra, director of research over at Blockstream. Andrew, welcome back to the show.

It's Stefan, great to be

back. So Andrew, I know, the team have recently launched Simplicity on Liquid, so, gonna chat a bit about that and what it means for Bitcoin development as well as Liquid. I suppose, maybe I'll, I'll just try to quickly- For new people, just to explain a little bit about Liquid, I, I guess in my understanding, and you tell me where I'm getting anything wrong, but the idea with Liquid, I guess the technical term people would use is it is a federated sidechain, meaning on Bitcoin, people can peg coins or BTC into Liquid, and then they've got L BTC, and then it's using a UTXO model, and people can send coins around inside of Liquid, and then they can peg out using a, a swap provider and so on. And, the general idea is it offers different- Trade-offs to Bitcoin main chain, it doesn't have mining, it has signed blocks, it has one minute block times, it has confidential transactions. So see, these are some of the different trade-offs that Liquid has, and so there are different, let's say, wallets and providers in the ecosystem of Liquid. So that's how I would explain Liquid just for somebody who's new, and then there are wallets, I guess, Blockstream, obviously, Blockstream app supports it. There are others like, Aqua, Bull Bitcoin Wallet, maybe Sia- ID Swap and some of these others, and Boltz dot Exchange as a provider, those are a few kind of off the top of my head as a bit of an overview on Liquid itself, and then, do you wanna, yeah, I guess do you wanna elaborate a bit on that, and then, then we can get into what is Simplicity? Yeah, for sure. That's, that's

a

great

summary of Liquid. it is, it's a side chain. it is, as a blockchain, it's a fork of Bitcoin.

It's directly a fork of Bitcoin Core where, where we've added a whole bunch of new stuff, as you said, confidential transactions, now simplicity, new script opcodes prior to simplicity, one minute blocks, multiple asset support, just a whole pile of, a grab bag of, of things like that. And we have a peg, right? So you can move Bitcoin from Bitcoin onto Liquid, you can move Bitcoin off. as you, as you mentioned, moving Bitcoin off of Liquid, to do this directly, there is a mechanism, but because that's... Reducing the balance of the side chain. There's some additional signatures that are required. So the typical way that you would do it is by, by using a swap provider, who eventually to, to rebalance their own, their own books will actually use the peg mechanism. But as a user, you probably just want to use a swap, right? 'Cause that's, that's gonna be instant in there. Or a few different ways that you can use that. So Liquid launched in 2018. before that, we had kind of a, a Liquid test network or a preview called Elemeth Alpha, and Elemeth Alpha had A number of, of kind of neat technology things. It had covenant support through extra opcodes, and it had a version of SegWit that predates the version of SegWit in Bitcoin, which actually was At the time that we developed it on, on Elements, it was pretty ugly. It would have been a hard forking change to put it into Bitcoin. And so from, from Elements, we developed the, the main idea of SegWit, and then a few people on the Bitcoin side, in particular Luke Dashjr, figured out that there was a way to deploy SegWit where it would be a soft fork and where it could be deployed with Much less, kind of coordination and like a flag day and, and all sorts of, of problems that would come with a hard fork. And then Bitcoin launched SegWit, and then we took the Bitcoin version of SegWit, pulled it back into Elements, which is now Liquid, and now, now we have it on Liquid. So the, the point of that story is that there's-- Liquid's been around for I guess seven, almost seven years now, and has a long history of, of kind of this interplay between, Liquid is, is a side chain in its own right, but also it sometimes serves as kind of a, a platform for demonstrating potential improvements to Bitcoin.

Gotcha. Yeah. And, as we were discussing the main, obviously the main topic we're gonna be talking about today is simplicity. So, can you give us just a, kind of a brief overview what is simplicity for people who maybe aren't as familiar? Familiar with some of these, you know, technical aspects. Sure. Yeah. So

Simplicity sits alongside Bitcoin Script or alongside TapScript, I should say, as a, a mechanism for people to attach scripts to their coins. So on Bitcoin, as many people are aware, there's, there's a scripting system that exists that typically is, is just used to validate signatures, but there, there are more advanced use cases that people do, various multi-signature and, time-locked backup keys and, and various constructions. Like this, and then also a couple more elaborate constructions that use hash preimages and so things like HDLC, which build up the, the lightning network and stuff. And what maybe fewer people are aware of is that with Taproot, the scripting system was, was slightly tweaked in that in Taproot, you can have multiple scripts associated with a single output. And the top level script, if you will, isn't actually even a script, it's just a key, it's just a, a signing key that you sign with. So the idea behind Taproot is that if you- Have some coins that, that maybe they're owned by, by you as an individual, maybe they're owned by multiple people, maybe there are multiple keys involved, but in all of those cases where Ultimately, there's some signers deciding whether to move the coins. They can come together and produce a signature, possibly interactively, they can produce a single signature for a single key. So the top level of a taproot is always just like signed with a single key, and that key might, might be multiple people even though it's one key. It's kind of a cool Cool trick that Schnorr signatures make able. But then embedded in that key, there's what's called the Merkle tree of different scripts. So there are all these different, situations that you can encode where if for whatever reason you can't sign a script. So the classic example is in a Lightning channel where one party just drops offline or tries to publish an old, version of the chain state, Or, or something like that, then obviously one of your parties isn't cooperating, so they can't participate in a signature. So then you've got to go use Bitcoin Script to say, "Well, okay, here, here are these alternate non-signature conditions that the blockchain isn't forcing for you." And in Taproot, you can have as many of those as you want. You can fit millions of them in there. And each of these scripts uses a language called Bitcoin Script, which supports checking signatures, it supports hash pre-images, it supports time locks, it supports composing these in various ways, right? You can have an and or an or, some thresholds, like three of five of these conditions kind of thing. And so Simplicity sits in where script would be. So in a Simplicity world, or on Liquid today, you can have a, a Taproot output where you have a Bitcoin- Bitcoin script that can be used as an alternate and a Simplicity script that can be used as an alternate, and they're, they're sitting beside each other. So what Simplicity is, is kind of an alternate script interpreter, and the benefits of Simplicity over the existing script, which we'll probably dig into, are it's much more expressible. Expressive, you can express any kind of computation that you might be able to do, and any pure computation that you can do, you can do in Simplicity. This isn't true of Bitcoin Script, at least without like BitVM-like tricks where you, you wind up using like You know, millions or, or billions of opcodes that you have to spread across multiple transactions and stuff to try to, to build up a computational engine out of the, the small arithmetic you can do in scripts. in addition to being able to do any pure computation, Simplicity has full covenant support, and this is something that you simply can't do in Bitcoin Script, no matter how many clever tricks you use. well Maybe you can use SHA collisions. All right, there, there are some clever tricks, but, but now we're, we're going beyond like practical methods. Yeah, yeah, yeah. Yeah. And then the other big benefit is that Simplicity is simple, and I mean that from an implementer's perspective, and that Simplicity is defined by a set of nine what we call combinators, which are these basic building blocks of a computation. And these combinators are-- each of them is, is really just like One line, not even a line of, of mathematical notation to describe, I bet you've got a, a t-shirt somewhere that I, I always forget to bring up before the, the podcast start, but you can fit the whole language onto a t-shirt and you can implement a simplicity interpreter off of this t-shirt. And the benefit of this is, for one thing, it's so simple that we can implement it in C on the, i-that what we do in the actual blockchain implementation. We also implemented, an interpreter in Rust, we implemented one in Haskell, and And more importantly, we implemented one in the Rock theorem proving assistant, and the Rock implementation serves as a formal specification of the language. So not only can we write these multiple implementations, and we know that they're all compatible with each other because this is so simple what they're doing. One of those implementations serves as a formal specification, and what you can do with that is either an implementer or a user, is you can produce machine-checkable proofs of correctness, or whatever, whatever sort of property that you might want your contract code to meet, you can produce a machine-checkable proof. And in, in Bitcoin script, you've got, got none of these. The language is, is not very expressive, it, it has tremendous limitations on the size of, numbers that you can manipul-manipulate. It doesn't have covenants. You can't reason About it, because it's defined in terms of the C++ implementation. And in fact, it's so far away from being able to be reasoned about that you can't even re-implement it consistently. And there's been, been a long history of, of alternate implementations of script, they're not so, so popular today anymore, where people would try to implement Bitcoin script in, in Ruby or in, in Python or in these various languages, and always after some weeks or months or years, there would be some Some obscure behavior in Bitcoin script that somebody would notice that, as far as we can tell, nobody had ever noticed before, and the Bitcoin core implementation would behave differently in this obscure edge case than the Python or the Ruby one. And in fact, there was kind of a golden era in maybe twenty fourteen, twenty fifteen, when Coinbase was using Bitcoin Ruby as their, as their, their way of validating Bitcoin scripts, and they had a bug bounty program. And whenever you found a divergence between Bitcoin Ruby and Bitcoin Core, they considered that a security bug, and they would pay you out a thousand dollars, which at the time was one Bitcoin. so you could just get like free bitcoins. I, I got two of these. What's the money? Yeah. And I, I know I got... A couple other people who got some of these, so, so sadly, sadly they, they stopped using Bitcoin. The golden

days are gone. Yeah. But, I guess bringing back to this concept of, you know, the formal verification, what does that mean in practice? Like, are we saying that makes it easier to make it secure? Does it mean if you were to build other sort of off-chain computation, it's easier for the security proof of that? contract or protocol, can you elaborate like what would that mean for us in practice if you are a builder or a developer in, you know, in Bitcoin or Liquid? Yep,

yeah, it means all of those. So it means a, a fairly wide spectrum of things. So in the, the most, kind of high level hand wavyest terms, right? It means that you can write a specification, a formal specification of, of what you expect your code to do and, and how you expect your code to behave. And you can write this in rock, you can write it in lean, There's all, F-star, I think. There's all these kind of, specification languages that exist, that you can use. And specifications can be as detailed or as general as you want, right? So you could have So if you were like NASA or somebody, you could write a full specification of every single aspect of your program behavior, right down to like, in every possible case, what will happen, no matter how users interact with your, your code. And if you're writing a non-trivial contract, then producing such a specification would probably take like multiple full-time specification engineers, like many months or, or, a long time to produce And then once you have the specification, you can produce a machine-checkable proof that your Simplicity code, which actually runs on the blockchain in the Simplicity interpreter, meets that specification. And because we have a formal spec of Simplicity itself, you can produce such a proof end-to-end. So you have a specification of what your code does, you produce a machine-checkable proof that your code matches that specification, and now whenever you update your code, whenever you add new optimizations, whenever you add New, use cases or whatever. assuming that any changes in behavior, correspond updates in your specification, then you can reproduce your machine checkable proof. and that, by the way, even producing the proof is, is potentially a, a lot of, of quite difficult engineering work, but, but the point is that you can do this, right? Now, a specification can also be extremely general and extremely small, right? So one form of specification you might say is This code will always execute, and if it succeeds, then it will use less than two hundred bytes of space in the transaction, okay? And that's the specification. It doesn't tell you a lot about what the code does, but on the other hand, it's very easy to write, and it gives you a pretty big guarantee that your code will not take, will, will not use more than two hundred bytes on the blockchain, and that lets you do fee estimation knowing that you have that, that bound on the size of your transaction. and you can imagine kind of a The, the whole family of, of simple conditions that you might write like that, you might say, "Uh, maybe you're a, a countersigner, maybe you're like BitGo or like the Blockstream app or, or one of these split custody things, and your specification might be, if this code succeeds, then it did so with a signature." Let, let me re-restate that. Without a signature from me, this code will not succeed. That's your specification, and you can do a formal proof of that. And for, for specifications like this, that are like these short one-line Miners that are a single condition, that's not months of work, right? That's something that, that anybody who's kind of a little bit familiar with the, the tools for formal specifications and machine-checkable proofs can produce. And actually, specifically for resource bounds, you don't even need to use these toolings. Simplicity has built-in, static, static bounds that we might talk about later, so you can bound the size of your program. But for something like the counter-signer example, anybody who's a little bit familiar with using Alloy or Lean or Rock or whatever You can kinda see the benefit, right? Where, the benefit of having these machine checkable proofs, where your specification is very flexible, it allows all sorts of, of changes in behavior while still meeting the spec. And so you can imagine if you're a counter signer, say, that your customer, your counterparty, is constantly updating their code and they're constantly tweaking stuff, and what you want as a counter signer is to know that no matter what crazy things they do, they aren't ever going to take away your signature requirement. Right? But conversely, you don't wanna limit what they can do. You don't wanna say, "Well, you're only allowed to do these five things that we vetted are okay." So by having this specification, you can prove that They give you a pile of code, you can produce a proof based on that code that it still meets whatever your requirements are, where your requirements can be as detailed as you want. As I'm reading

you, this sounds more like maybe like an enterprise sort of- Higher security use, as I'm understanding you. and I guess I, I'm also curious, like maybe you can spell out a little bit around the uses of, like, what, what does Simplicity enable people to build? I know there was some talk online about vaults, maybe some covenants and, a zk verifier. Can you just elaborate a bit on some of the different uses there, like what can Simplicity enable that's Difficult or impossible with Bitcoin Script today? Yep. Yep,

yeah. as you said, to close out the specification discussion for now. This is large, this is for implementers of large contracts, this is for enterprise kind of stuff. So as an ordinary user who's got a key, maybe a couple of keys, you, you really don't need a formal specification for coins that have a couple of keys, right? Now, what does simplicity enable? Beyond specification, right? The, the other pillar that I talked about is this new expressivity. And simplicity by dint of having full access to the transaction data can do any sort of covenant implementation and having full computational power Can implement basically any proposal that's been made for Bitcoin and beyond. So on our, we, we have online our, our website simplicity-lanq dot org. We have a, what we call a web IDE, which is, is more of just a playground for writing simplicity code in a high-level language called Simplicity HL. And in our web IDE, we have a couple example programs that include an implementation of OP_CAT, we have an implementation of Sighash N8 Prevout, we have an implementation of of a vault, and there, there are a couple other things there, but these, these are all kind of big proposals for Bitcoin that people have, and all of them can be captured by Simplicity. And the cool thing here is that It's maybe unsurprising for your listeners to hear that we can do covenants and we can do vaults and, and rate limited coins and payment pools and all of these kind of covenant things that we've been talking about a lot, but it might be surprising to hear that we can do something like SigHash any pre-voit. So for context, SigHashAPO, as, as it's called, is a proposal for Bitcoin that Lightning developers would like to have that allows you to produce a signed transaction, a signature on a transaction that's, that's what's called rebindable. You can use the same signature on multiple transactions, subject to certain constraints. And the idea here is that in the case of Lightning, if you've got some payment channel that's being updated hundreds or thousands or tens of thousands of times, there's always a risk that a misbehaving counterparty there will try to publish an old state. And then when they do so, the honest party needs to publish kind of a response transaction, taking the old state and then pulling the coins back and, and undoing it, right? Because old states are supposed to be in- So we have this, this claim or refund mechanism where if anybody posts an old state which, will continue to be valid according to Bitcoin because of a property called monotonicity, you can't turn things into, make things become invalid The old states will continue to be valid, so instead you have this extra refund step where, where somebody has to post us. And ideally, your counterparty Ideally, each party could have a single signature that they've got laying around that they could use no matter which of the thousands of old states are, are published. They can grab their signature, they can, put it onto, onto the chain, and they can, can undo the, the bad transaction. Today, you need a separate signature for every single, every single state update. And actually worse, because lightning channels are two party channels, you need a separate signature from both parties. And if one's misbehaving, he's not going to like reproduce them after the fact. So as you're going, you have to get two signatures. Everybody has to get their own signature and their counterparty signatures. And every update, they get new signatures which they've got to store. You've got this ever-growing, chain of, of signatures you've got to keep around. The sigas any prevout would mean that rather than having this ever-growing chain of signatures, you just have one pair of signatures. And if your counterparty misbehaves, he publishes an old state, you grab the single signature, it's rebindable, so it will work for any state, no matter which, which old one that he published, and then you publish it. And the way that you implement this in Simplicity is you have, you, you grab all of the transaction data that, that you want to sign, which is the entire transaction except for the specific input that you're signing. That's what any prevote means, is that you can put any input on, on the signature. You grab all of that data using the covenant mechanisms, you hash it all up, and then you check a signature on that hash. And, and by the way, you can do the same thing with OP_CAT and OP_CHECKSIG from Stack, 'cause it kind of gives you the same mechanism, build a sig hash and then, then sign it. you can do the same thing with TX hash plus check sig from stack, which is the form of OP_CT_V where you kinda split apart the, the signature from the, the,

Transaction template generation. but you can't do it, for example, with CTV. I don't think you can do it with Vault. You, you generally, you can't do it just with any sort of, of covenant implementation because it's, it's a little bit tricky. It's not just transaction introspection and transaction constraining you needed, you need, but you also need some way of, of having a signature on that transaction data. But in Simplicity, you just, It's there, all the tools are there, so we were able to implement it. And let me expand on that one more time before I hand back to you, which is that, In Simplicity, you can not only sign any transaction template, right? You can sign, as like in the APO example, you're, you're signing all the data except the input, okay. You can also sign arbitrary functions of your transaction, and here's something that really no script exten- no, no new opcode other than Rusty Russell's great script extension, which, which adds just everything, No, no kind of single small extension of script gets you. And an exa-as an example of this, you can define a-- you can, you can produce a signature Which delegates to another lower security key, with the additional condition that the lower, the, the less secure key's signature is only valid if the transaction was in a certain Fee rate range. So what you can do is you have this high security cold key, and it signs the transaction, but it signs the transaction only up to a point where it's still possible to modify the trans-- it's still possible to add new inputs and outputs, but the, the core transaction is signed. And furthermore, it signs the fact that the transaction's fee rate, and the fee rate, by the way, you compute the transaction's weight by adding up all the bytes in the transaction, and then you divide that by the, the total fee, which in Bitcoin is the, the Total input amount minus the total output amount. So you do this computation on, on all of your transaction data, and you check, is it in a range? And you sign that bit, that, that it's in a range or not, and you sign the program that produces that bit. And now you have this transaction, you hand it off to your, your cell phone wallet or whatever, and, and that's able to sign off and publish it. And if the transaction turns out not to confirm because the fee rate was too low and the, the fee market spiked and you, you weren't expecting it Your phone wallet, your low security key, is able to re-sign the transaction with a slightly higher fee rate. But we can do one better, right? We can even say the fee rate is a function of the age of the transaction. So in Bitcoin, we have something called relative time locks, which essentially allow you to gate certain logic in a script on how old the UTXOs you're spending are. So now you can say your, your high security key is going to sign a transaction with a tightly constrained fee rate that will become less and less tightly constrained as the Transaction gets older, and this allows your phone wallet to bump the fee rate, but only if the original transaction isn't being confirmed. So this, this is an example, actually, Sankeet Khandelkar implemented this, and he did a post on, on Delving Bitcoin describing how to do this in Simplicity. So this is, this is a kind of cool application that Really, you need, you, you need the full expressivity of Simplicity to implement something like this, right? And, and as far as I'm aware of, of the proposals that are on the table, right, for this, right? I'm calling Simplicity as, as a proposal, but as I'll say, it's, it's not like I'm We won't see simplicity on Bitcoin this decade, right? Like, simplicity is a big change, and I'm sure we'll talk about that later, but, but of the proposals that could fit into, to Bitcoin, right, there is Rusty Script's great, great script restoration. Great script restoration. Right. Which is, certainly the closest thing to, to something that we could deploy like tomorrow if, if we, had the will, there's Simplicity, and then there's something called TLSP, which, which came from Bram Cohen's, TiaCoin, I guess it's called, which is a, a form, a variant of Lisp which is designed for blockchain interaction, although it doesn't have a formal specification and, and there are a few, a few important ways in which it differs from Simplicity, but it's, it's got a lot of the same motivations and, and some of the same development power behind it. And everything else, all the stuff that we're really talking about, like all these small improvements, like can we add up CAT, can we add up Vault, can we add up CTV, can we add these indi-individual opcodes or seckash modes? They don't get you this kind of full, like, full bore, you can do anything kind of functionality the way the Simplicity does.

The lead sponsor of this show is Bold, the banking platform designed for Bitcoiners. With the Bold Virtual Visa Debit Card, you earn Bitcoin back on every purchase. The more Bitcoin you buy with Bold, the more Sats back you get on the card. Buy twenty-five hundred dollars of Bitcoin and earn three percent Sats back. Keep stacking with Bold to earn up to ten percent Sats back. Bold offers the industry's lowest fees on Bitcoin buys and sells with When starting out, you can use Bold Wallet, which is managed by the team, but Bold is also supporting self custody with Bold Vault, a two-of-three collaborative custody multisig for zero monthly fees. With Bold, you get your own FDIC-insured checking account to store and send fiat, pay bills, direct deposit your paycheck, and replace your legacy fiat bank. Sign up today and get zero fees on your first ten thousand dollars of Bitcoin buys and twenty-five dollars of free Bitcoin when you buy a hundred dollars of Bitcoin or more. Go to getbold dot io. This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q. Now, some people think self-custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self-custody gives you a true feeling of liberty. The Coldcard Q has a full keyboard and big screen. It's got two secure elements and a true air gap, allowing you to go fully air-gapped using QR codes from seed generation to transaction signing. You can power the device using three triple-A batteries, so you don't even have to plug

Wallet for PC or nunchuck on mobile, and you can dial it into the right level of security and complexity that you choose. If you want a simple setup, just use twelve words and single signature. If you want passphrase, it's easy. If you wanna add multi-sig or co-signing features, you've got those too. So go to coinkite dot com, use code livera to get ten percent off on your cold card or other devices and level up your self custody today. Yeah, I see. So, yeah, it comes down to, I guess, what you're saying around what is enabled, what's expanded here. so I guess putting this into like, what would be What would you, what could you envision that might get built with Simplicity, at least on Liquid? So things like, actually, I was curious to ask you this, I know Jonas, Nick from your team has this, idea called Shielded CSV. Could that be built using Simplicity? So Shielded

CSV actually, I believe, works on Bitcoin. Shielded CSV doesn't. So then, let me do a brief digression into Shielded CSV. so Shielded CSV, the CSV here stands for client-side validation. And the premise behind client-side validation Is that rather than having scripts that go on the chain and every blockchain validator checks that the script passes and that all the rules are being followed, in shielded CSV, essentially all your blockchain is doing is checking that transactions are embedded in the chain, in, in the order. All, all the blockchain is doing is enforcing an order, and, and possibly doing like balance checks and making sure transactions balance, but they don't even need to do that in full client-side validation. And the idea there is that as a User, when you receive a coin, you don't go to the blockchain, you don't go to your full no-node and say, "Is this a valid coin whose entire history followed all the rules?" Instead, for that individual coin from your sender, you receive a transcript of its whole history, and then you validate that before accepting the coin. And the transcript will make reference to the blockchain, but only as a proof of publication and a, and an ordering mechanism, not as, "Here are the scripts that are involved in, in every blockchain validator." I checked that the scripts were passed. And this idea has been floating around since probably twenty thirteen, fourteen, or, or earlier. I remember Adam like really, in, in the twenty fourteen, in the early days of, of Blockstream, Adam really wanted us to, to go at this, and I'm like, no, it's impossible. Like, that doesn't, like, come on, think about it. Right? Because as a person receiving a coin, the history of that coin is massive, right? Like that coin came from a transaction that had multiple inputs, and now all the inputs are themselves, you gotta go back and check where that they come from and they expand, and then eventually they all grounds out in Coinbase outputs and like the blocks that originally created the coins. But very quickly, the history of every coin kind of expands until it's basically half the size of the original blockchain. And then, okay, why don't you just download the blockchain and validate? It ahead of time, right? Like what, what is CSV getting you? And the innovation of Shielded CSV and, a couple other papers before it is that using updatable zero knowledge proofs and some clever accumulation and aggregation techniques, it turns out that you can have an entire coin's history packed into a zero knowledge proof that is just, I think a couple hundred or a couple thousand bytes is a fixed size. It doesn't grow forever. It certainly doesn't grow to the size of, yeah, of the whole chain. and that proof has to refer back to, I believe, the single most recent output on the chain. There's a little bit of blockchain validation you have to do, but what you're validating aren't full transactions, what you're validating are, are outputs that just have a, something like a forty byte kind of, kind of marker or a Commitment embedded in them. And so what's preventing Shielded CSV from being a real thing that we're using today is actually off-chain development work. Like somebody's gotta write a bunch of crypto code, somebody's gotta like- There's a lot of like really difficult crypto work to be done, but it's actually all independent of Bitcoin. And I believe what you need from Bitcoin is just a platform to stick these commitments in, and we've already got opt-in outputs and, and some more clever things using Taproot tweaks and, signed contract tweaks. so Shield of CSV doesn't need anything from the blockchain. It certainly doesn't need simplicity. Although, Shield of CSV, as described in the paper, has no scripting ability. The, the premise behind Shield of CSV is that it's individuals sending coins to each other, like one key at a time. And i- ideally, and in theory, you could put a scripting system into Shield of CSV and then use your knowledge to

extend, it's like extending that idea

further. Right, exactly. And then, m- you could do simplicity inside of Shield of CSV, and then that's kind of cool because it's not happening on chain, it doesn't need consensus, and then you could, you could do it, So that, that's-- when I think of simplicity in Shield of CSV, that's, that's the direction that's exciting to me, is maybe that's a mechanism to get, to get simplicity. Gotcha. I guess,

bringing it back to, I guess things that are like, more kind of things that people are doing that

Inside Simplicity, can you elaborate a bit on that and what, what's being enabled there?

Yeah,

yeah. So

the, and this, this is actually not Liquid specific, but it's, it's been done on Liquid, 'cause that's where we have Simplicity. But because Simplicity can do any computation, in particular, it can verify zero-knowledge proofs of, of any form. And so the folks at StarkWare have put together a Stark verifier. written in Simplicity that fits into a block. I think it even fits into a standard transaction, but, but right now the verifier is, is very large, and I'll, I'll talk about that in a sec. But You can take any Stark proof, which you might produce by writing some sort of code in Cairo, which is StarkWare's high level language for producing zero knowledge proofs, and then you can verify those Starks on Liquid. So a lot of the kind of zk rollups and other things that have been built in the StarkWare ecosystem now can be deployed Pretty much just deployed on Liquid by producing zero knowledge proofs that are validated on Simplicity. And this is, is very exciting by itself for one thing, because, as, as your listeners will, will notice, if they go to SimplicityLang dot org and, and go to our GitHub page and try to get started, right? They'll, they'll find that there's still quite, quite a few rough edges. We're not, we're not as welcoming as we wanna be. But the guys at StarkWare apparently were undaunted and they, they dug into our, our code Is great. super, super cool. one observation about the Stark verifier is, as I said, it's very large, right? And the reason for that is that simplicity itself Is a very low level language. You have to, if, if you're writing code in Simplicity, you've gotta, gotta build, build up your computations from first principles. And to avoid every transaction being enormous, like every signature validation taking, you know, like a million or a billion, Simplicity components that are all like inventing bits and then pasting bits together, we have a feature called Jets, where for large- Common simplicity expressions. We have optimized C code that when the simplicity interpreter encounters one of these common expressions, or rather, as, as a, a developer, when you have one of these expressions, you can just replace it with a jet. And here's another benefit of having a formal specification, is that we can write this jet code in Verified C, which is a subset of the C language, which is supported by the CompCert C compiler, and the, the The Verified C has a formal specification and the CompCert C compiler, which, which sadly is, is not open. You, you've gotta pay to use it, but if, if you wanna do this, maybe, maybe you should. you can compile Your code and the, the compiler has been verified, has been proven in a, a machine verifiable way to meet that specification, which means that we can prove that a jet for simplicity code Is actually a drop-in replacement for the Simplicity code. This is replacing previous machine-checkable proof that the C code and the Simplicity code are exactly functionally equal, even though the Simplicity code might take multiple hours to run and the C code takes tens of microseconds, right? or nanoseconds. And, and as a, a specific example of this, we actually did this with the SHA-256 jet, where if you are If you want to compute a SHA-256 hash in Simplicity, you wouldn't write it out in Simplicity, right? You would instead use a Simplicity jet, which is specified in Simplicity. And then rather than the interpreter executing the simplicity specification and actually execute some C code, and in two thousand and eight or so, some researchers developed a verified C implementation of SHA two fifty six and verified that it matches the mathematical description of SHA two fifty six. So you have this chain of the, the pure, the, the Platonic mathematical SHA two fifty six has been proven equivalent to the C code, which we proved equivalent to the simplicity specification. Which means that you can swap those out. And so now rather than, doing SHA-2 directly in Simplicity, which would be very large and slow, you just do it in C. But we've got this chain of custody that shows that this new, this new jet, this new kind of op code, if you will, It hasn't changed the behavior. It doesn't have weird edge cases, it doesn't have surprising things where it turns out that it's not actually SHA256. Sometimes if you give it a funny input, it will output all zeroes or something, which is the kind of thing that C++ code tends to do. So anyway, we have jets for SHA-256, we have jets for verifying Schnorr signatures, we have jets for, a whole bunch of arithmetic in, in, bit sizes from, from, I think, eight bits up to two hundred and fifty-six bits. we have multiplication, division, modular arithmetic, Euclidean, the, the extended Euclid algorithm, which is, is used to implement modular inversion. we have a couple things for tweaking Taproot keys, and for manipulating SECP256K1 points. So as a result, if you're trying to implement some novel crypto that uses Libsecp2 or that uses a secp256k1 curve, you can do it in efficiency, in simplicity, pretty damn efficiently. But if you're StarkWare and you have a separate, curve that you're using and you're using these kind of custom thirty-one bit finite fields and these, these Merkle trees that use custom hash functions and stuff, you've got to basically implement all of that yourself using the arithmetic chips that we've provided. And when they did so, and, and prior to doing any optimization, which I think will be their focus and, and we'll be helping over the next several months, right? when they did so, the result was a very large program. So what this illustrates is that prior to Simplicity, if you wanted to do something that just wasn't supported by the chain, it just wasn't supported, you can't do it. After Simplicity, if you wanna do something wild and like completely unsupported by the chain, you can do it, but it will probably be expensive. So if you're trying to do post quantum signatures, if you're trying to do Stark verification, if you're trying to do pairing based crypto, if you're trying to do,

Like a risk five processor implementation, like, like whatever you can, can think of here, there's a chance that it's going to be pretty large. And so what we can do, yeah, is, is add more just, so just out of

curiosity, what would that, what would that mean then, like? In this example, are we saying being able to do this kind of zk verification using Simplicity would that mean like, I don't know, some of these zero knowledge like rollup things could Like you could have like, I mean, I guess Liquid is already a side chain, but would you have like a rollup that, is, you, you know, ha-having proofs posted to the Liquid blockchain or w-w-what, what would, what would be the idea there?

Yeah, yeah. So there are, so right now with these Stark verification proofs that are, Stark verification programs that are extremely large. Yeah, I mean, the, the only way you can use these in practice is by doing rollups, right? Where kind of off-chain, you've got, you know, thousands or tens of thousands of transactions that are all rolled up into a single Stark proof and that's verified on Liquid. And you could indeed have basically a layer two on Liquid, if, if you think of Liquid as a layer two of Bitcoin. And now you've got like a layer two of a layer two. I forget if we call those L3s or if that means something else. But that, that's, that's one thing you would see. But also because the, the, the, Stark proofs are very general and have kind of already been designed to the extent possible to be blockchain agnostic. You can use this to produce bridges and stuff, you can do atomic swaps inside of the, the Stark rollups where you are directly transacting in a way where you're manipulating both Bitcoin on Liquid and Bitcoin or, or whatever on Ethereum or whatever other kind of assets these different chains support, and across all sorts of chains. So there, there would be essentially the, the existing Stark Rollup ecosystem, Liquid kind of gets to join for free, for free, because even though at Blockstream and on Liquid, these ecosystems aren't really a focus that we're looking at, Simplicity is expressive enough that those ecosystems through, through StarkWare are able to extend themselves to now support Liquid, right? And that they get these rollups, and they don't-- they didn't need to petition us for a Stark verifier and like convince us to, to hire a cryptographer to spend a year Reviewing all of their code and like deciding whether Starks are really the zero-knowledge proofs that we want, or maybe we want to wait for Starks two, or maybe we want to like, you know, use zkBoo or one of these other things that are floating around. None of that, they just implemented in Simplicity. And then, once they have the Simplicity code is working, we can look at that and say, "Well, if it- How, how widely used is this, and how general can we break up the Stark verifier into general components that we could jet out? And then, with our assistance, we can make their code much cheaper and more efficient on Liquid. Again, without us having to implement a whole Stark verifier on Liquid and like have that tied into our consensus logic and stuff, we can kinda build it up by jetting out larger and larger computations and computations that we feel are, are very generally widely used, right? yeah. So we have a, a lot of flexibility in, in how we move forward.

Okay. And now if we talk through, let's say some of the vault or maybe this kind of- Coinpool sort of idea, as I understand, some of the covenant techniques could be applied to do that. So I guess I'm trying to imagine, like, as an example, Even, some of these decentralized exchanges or maybe not decentralized, but just like, you know, Bull Bitcoin or some of these swap providers, maybe they could do a lot of batching of their payouts to the customers using some of these kind of coin pool, Shared vault kind of ideas that are possible now in Simplicity, right? Yep.

Yep, absolutely. so there's kind of two, two pieces of technology that, that Simplicity makes possible that's valuable for them. So the one is, as you say, these, these payment pools, or, or shared vaults or, or however, there's a few different kind of similar ideas where the, the, payment processor or the, the swap provider produces a single output that represents coins for You know, hundreds or, or thousands or millions of, whatever, withdrawals, and it's a single output, which means that the swap provider can attach a, a relatively very high fee to that and get a very high priority transaction. So it's like very

high efficiency on chain.

Yeah. And then individual participants would then create a new transaction, which effectively withdraws from the shared output and puts back all of the old coins. And the trick there is that each participant can choose their own fee rate. So every individual- People is paying for their own transaction, right? So now that the incentives are aligned properly, and, and so users who want their withdrawal right now can, can just sign a very high fee rate one, and, and users who aren't in any particular rush can sign a very low fee rate transaction. and everybody, kind of the, the money is coming from the people who, who are incentivized to, to move the money. So that's, that's a big thing, right? That's, that's definitely an application of vaults that, that, improves incentives and of the market, which is a little ironic, right? Because it's obviously increased the, the total amount of, of stuff that hits the blockchain, if you've got multiple transactions where previously you had one, but because the transaction structure is more economically efficient. It works out better for, for participants in the network. then the other piece, which particularly for swap providers and decentralized exchanges and stuff, is that simplicity allows you to do on-chain orders. So the right now, in order to be a swap provider or in order to execute a, a cross-chain swap or even a, a single-chain swap, essentially what you need is every single participant in that swap needs to sign a single transaction which executes the swap atomically, right? So if you have-- This is, by the way, why custodial exchanges are so, so fast, so much faster and, and, so much simpler It's cheaper, right? Is that there you, you don't have multiple participants who have to come together on a, on a single transaction. But the fact that you need all these multiple participants to sign the same transaction is, well, for one thing, it's, it's a little bit expensive, it's also quite inflexible in that everybody has to agree on exactly the transaction. You can't have one participant who says, "You know what? I'm willing to sign like any, any price within this range, like just, whatever, guys, I'll just, you guys figure it The last Satoshi, what's the transaction they're signing? If anything changes, including a change in the participants, then everybody has to re-sign. So this is really the big user cost is that in order to participate in one of these decentralized exchanges or one of these swap protocols, you need to have hot keys, right? You've got to have your phone wallet or something that's always online, constantly re-signing these completed transaction orders. And Using existing script capabilities, it's very hard to make this flexible, right? You can, you can do this sort of like, you can sign half the transaction and let somebody else sign the other half, but you've still gotta define the exact parameters down to the last Satoshi of what that transaction looks like, right? whereas with Simplicity You can do a limit order, say, where you can say, "Here are some wrapped USDS. I am going to put these up, and anybody can take the USDS as long as they give me at least X amount of Bitcoin, where X corresponds to a Bitcoin price of, like a hundred and twenty K or, or higher, I think of that. As we're recording this, I think we just hit an all-time high, by the way." Oh, fantastic. And I, I think I, I don't have it.

Alright, I won't get stuck. Oh yeah, I think it's like a hundred and twenty K. Anyway, yeah. Yeah. So anyway, we're talking about the decentralized exchange case and re-signing or- So you can,

so you can, you can describe these, these conditions, right? So here's, here are my coins, right? Here are my dollars, or here are my Bitcoin. here's what I'm willing to trade it for, and here's a range of, of prices that I'll accept. and anybody can take my, my side of the trade The threshold. and that actually, and this is like such a basic piece of functionality, like in, in traditional markets, like you can do a limit order, right? That's like, often like the only kind of, of order that you can do, it's such a, such a basic piece of functionality that people miss that actually is, is kind of an interesting algorithmic thing where you're telling your brokerage, or you're telling your exchange, or you're telling your DeFi software, these are, this is kind of an open-ended set of conditions under which I am Willing to execute any specific trade that meets these, these general conditions. And some brokerages offer like completely open-ended, like algorithmic trading, many, many brokerages offer trading APIs, so you write your own algorithm and run it on your, your own computer, and then it, it executes trades based on, on what your algorithm does. if you're some sort of like, you know, billionaire, like if, if you are a brokerage, then you can often execute algorithms on the exchange's computers directly, and that's kind of cool because they, they can do matching extremely quickly And what simplicity gets you, like EVM or, or like, you know, these other, kind of, kind of full, Turing complete, rich statefulness kind of blockchains, simplicity lets you do arbitrary things, it lets you do limit orders, it lets you do arbitrary algorithmic trades, it lets you build financial products, so, so something Weirdly similar to a limit order is a fully collateralized option or a, a, a stock option, which is a financial contract where you basically bundle up a trade. You say, "I'm willing to sell Bitcoin at this price at this date," and then you throw the trade, and the trade can You can trade the trade, right? Like the, the trade is bundled up into this, this contract called an option, and then that has a market price, and people who, who want to be on either side of that trade, you can buy or sell that, and so you can get a bit of money up front as a, as a premium for basically selling your trade into the market. and this is basically just like a limit order that you, you bundle up and then, and let, let trade around, and that's the kind of thing that you can implement directly on chain or within a So that, that I would expect we're, we're going to also see some new financial products that, that are, are built and implemented using this. So

more like in the Dex world and, you know, cross-chain swapping and, maybe liquid assets, this kind of thing, like, like I know, well, Adam from Blockstream, I know he's obviously very big on Bitcoin treasury companies, and he's also very big on Stocker and LBTC trading against those Bitcoin treasury companies as well, so I know he's super into that, and so maybe, maybe we see some more, something in that direction also. also just curious to get your Thoughts on, I guess, what direction do you see the main liquid uses being? Like, as I see it, it seems like you've got this capital markets use, like, which we were talking about, like trading, let's say, liquid Bitcoin for CMSTR, which is like the tokenized form of- strategy or something like that, or the other, other treasury companies. And then I, I guess the other big one I've seen is a lot of people using, as an example, Breeze SDK Nodeless, which is like Or, which is like using, like having a liquid Bitcoin-based wallet, but using it for like swaps in and out of Lightning, using Boltz dot Exchange as like a transactional- Wallet, and also maybe in some cases like Aqua, where you've got like Liquid Bitcoin, but that user can easily rotate in and out of Liquid Tether or the various Tether forms. So I'm curious, where do you see the main uses, for Liquid, I guess nowadays or into the future, if you could elaborate on that?

Yeah, yeah. So as, as from my position as, as director of Blockstream Research, right? Like I, I like to pretend that Liquid is, is a technology kind of demo platform or, or even especially a, a platform for demo- for demoing things that I would like to see in Bitcoin one day. but the truth is Liquid is, is very different from Bitcoin in, in a couple important aspects. So one is that we can deploy- well, okay, one is that we assign blocks and we, we have, you know, a federated trust model and stuff, which is a huge difference. another way is that Liquid, because of its nature as, as a side chain, which is, that, that, that is not trying to be as broadly usable as Bitcoin itself, we can demand a much higher hardware requirements from people who are validating the chain, and this lets us do things like confidential transactions and, and throw all this really heavy crypto onto the chain. But then the big way that Bitcoin That we differ from Bitcoin, where Bitcoin will never follow, right, is that we have multiple asset support on Liquid. Right? So Liquid, as a blockchain, allows you to issue new assets. once you've issued an asset, alongside that, you can issue or not, what we call re-issuance tokens, which are, are NFTs that allow you to reissue more of that asset. So, so you might do like a closed issuance, where you issue it, there are no re-issuance tokens, and everyone can see forever that there's a Have reissuance tokens that are held by, like if, if, for, for example, Tether has a reissuance token that is held by the Tether Corporation, right? So they're able to issue new Tethers onto, onto Liquid. and we have built into confidential transactions, we have what we used to call confidential assets, where we hide not only the input and output amounts, the way that the CT works, the way it would work on Bitcoin, the way it works on Monero and so forth, but we also hide the individual assets. So you can have transactions that have multiple assets going in, multiple assets going out. And so this gives us a platform where beyond being kind of a, a place to demonstrate new Bitcoin technology components, it's actually a very different ecosystem that has multiple assets, many of which are wrapped assets from other blockchains and, and many of which are, are freshly issued assets that are tokenized forms of, of other financial products, including, by the way, Blockstream's, mining node, the BMN. is one of the, the, earliest, you know, I would say interesting financial products that was floating around on Liquid. And so what? Liquid as a platform gets you for these kind of tokenization and, and trading use cases. Well, well, one, I hinted at, right, is that we have supply controls that are very easy to reason about, right? When you issue an asset, that's public, you can actually do confidential issuances. I don't know if anyone's doing confidential issuances or why you, why you would, but it was easy for us to support, so you can do it. But typically, you do an issuance in the clear, so everyone can see the total amount that you're issuing How many re-issuance tokens exist, if any, right? And that's, that's a big important piece of information. And so you now you know the total supply of every asset on Liquid, up to, I guess anybody can burn coins confident. You can have like a confidential op-return on it, I suppose. So you, you could secretly reduce the supply, but nobody can inflate the, the supply, except by the parameters that are, are publicly visible. Beyond that, we also have ways that people can have visibility into and, and control over how their assets are traded. so we have various classes of assets that use what we call AMP, the, the asset management platform on top of Liquid, which allows, Users who are, are trying to issue assets where for whatever reason they only want, like, whitelisted, a whitelisted set of traders to interact with those assets, you know?

and again, it sounds to me mainly like you're, you're speaking about asset issuance on Liquid, right? That's kind of the direction you see things going.

Yep. And asset issuance. Yep. That is, is transparent in a way that it isn't on other blockchain platforms, and, and simplicity is kind of part of that, right? So it's, adding arbitrary functionality to these asset issuances in a way where everything is publicly verifiable, and Everything is, is to the extent people are willing to do the work to make the proofs, right? Everything can be proven in a machine-checkable way. That's, that's really the goal, that people can have rock-solid. Yeah.

Okay, one other topic that I think it's kind of topical just because the last few days there's been a bit of chatter about this, around what some of the stablecoins are doing, right? That they are now, a bunch of them, I think Tether, Circle, and, One or two others have basically come out saying, "Hey, we're gonna do our own chain, we're gonna do our own L1 token." and I think, you know, there's been a lot of back and forth on this, but I'm curious to get your thought on this about, you know, what it means, for Bitcoin and Liquid, if anything.

Yep. I'm really, I'm, I'm a Bitcoiner at heart. I've, I've never used a stablecoin. I, yeah, I wasn't aware of this, this announcement. This does surprise me a little bit. So I, I would like to understand more about what they would get from having their own chain versus having, you know, an existing multi-asset chain like, like Liquid or maybe there are other ones like that. My speculation,

I don't know for sure. My speculation would be maybe there's more compliance checking, so maybe it's It's kind of like the US government is sort of say, is, I'm speculating, right? I don't have inside info, but this is my guess. My guess is it's kind of like, US government is sort of bringing them in the fold and saying, "Hey, you can have a seat at the table, but we want more compliance checking, or we wanna-- we want a bit more on their side. Maybe they want like AML and sanctions to, quote unquote, stop the terrorists and whatever, or to stop the sanctioned, whatever individuals." Maybe that's I don't know. I, of course, stablecoins right now are also surveilled. That is a standard thing that people should be aware of. they don't have the same censorship-resistant qualities, obviously, that Bitcoin has, but that's my guess. But I also think it kind of-- this idea that the stablecoin issuers are putting out their own chains themselves, maybe it undermines this quote-unquote so-called utility token thesis that some people spoke about, that, you know, of- Some of the altcoin chains, things like Tron or Ethereum and whatever else, Solana, whatever. so that, that, that's, that was my interpretation of it, i-in favor of Bitcoin, because obviously there's a reason to hold Bitcoin, right? There's no more than twenty-one million, we see it as the future of money, all these typical things, whereas I think this utility token thing has always been a bit of a bunk idea, and now it seems like, you know, I guess, I guess what I'm driving at, and I think this isn't A kind of centralization, fact or kind of force, because these things weren't decentralized anyway, you know, like no one cared, no one was pretending that stablecoins are a decentralized thing if they are issued by a known individual with, like, backing by whatever US government bonds and whatever else. So maybe there's kind of a general, a centralization, you know, force there, that-- now of course, Bitcoin is in a unique category, but I'm curious, do you have any reactions or thoughts?

Yeah, yeah. so, yeah, so I, I'm certain that, that within Blockstream or, or business development people are, are looking at this and, and like trying to figure out what, what problem they think they solve by, by going onto their own, own blockchain. And, and for me personally, I, I hope that I don't get pulled into those phone calls. but the, but it sounds like, at least for now, it doesn't sound

like they're taking away support from other chains. Right. Okay. But it's just like

Yeah,

I mean, the big reason to have these, these kind of mega chains that support all of these different tokens, right, is that it makes the swaps very easy, right? It makes it very easy to do DeFi-like things because you can have a single transaction on a single chain that executes whatever sort of trade under whatever conditions people want to enforce. And as soon as you've got independent blockchains, then you're doing cross-chain swaps, which are, are certainly possible, but they're, they're harder, right? They're, they're slower, they're, they're more difficult to and they have, they have these, these weird like timing issues, like there's this kind of free option problem where, where somebody can wait till the last second they're allowed to sign and then, then sign or not. and

Yeah, it-it-it's,

it's, so for something like a utility token, like almost

The whole point is that you can trade it, right? Like, I'm not sure what other purpose many of these things have other than being tradable, or like, maybe like what purpose these things have to be on a blockchain? Other than it makes the trading more efficient, right? Yeah,

'cause otherwise, I mean, at a certain level, it's like you might as well just have a SQL database or something, you know? Yeah, yeah. Not even have a chain, you know?

Yeah, yeah, exactly, right? So.

Yeah, I've got the same impression as you. Maybe it's a bit of an open question. I, I mean, none of us really knows. We're just kind of speculating a bit just to understand what's going on. Now, different arguments I've seen kind of online, some people saying, "Okay, but actually the real reason is so-called compositability, right, between this chain or the other." Or maybe the other argument I've seen is like, "Well, hang on, actually some of these issuers might like the kind of idea of having a bit of a, we Whatever coin or chain, that's out of my control. So maybe there's, there's a bit of that, that kind of regulatory, let's say, arbitrage or something, for that reason, I don't know. I guess one other thing I'm curious to get your thought on, while we're talking about Liquid, how are you seeing this evolution now of Liquid as compared with different L2s on Bitcoin, right? Because we've got obviously Lightning, the most decentralized and, you know, arguably the most, adopted L2 for Bitcoin, and then now we're seeing ARC and we're seeing Spark, you know, we've got Liquid, there's things like eCash, I guess it depends, it depends how you count these things, but where do you see Liquid? Contrasted with those, like are, are we seeing, or at least are you seeing Liquid more in the, let's say, the capital markets, asset issuance space? how do you see Liquid comparing?

Yeah, yeah. So in, in short, yes. So, so by, by Liquid being a public blockchain, in some sense, it's just not a scaling solution. So, so if you consider an, an L2 to be something on top of Bitcoin that allows Bitcoin to, to scale better, Liquid's sort of not that. I mean, it is- It sort of is in the, the, the set of liquid validators, like the swap providers, the gold star exchange and this

kind of thing. Yeah.

Yeah. So like as a Bitcoin user, I, who like doesn't want to validate the Bitcoin chain, is willing to like trust it briefly, right? You could, you could swap into Liquid and then do a bunch of transactions that are, that are trusted in the sense that you're not validating it, and then swap back, and then you, you've kind of limited your exposure. you're of course welcome to run a Liquid

So, so no. So, but y-you can compare that to something like Lightning, where the premise behind Lightning is that you've got a, a sequence of two-party payment channels, and all of the updates are happening in these two-party payment channels that only those two participants need to validate until the, the channel gets closed out, right? And then that is a real scaling improvement in that you haven't reduced your trust model. In any way, you still have the full backing of the Bitcoin chain, and it's this public blockchain, although you're not, except in the uncooperative case, you're not falling back on that. But you greatly improve scale-improve scalability because Each transaction, every transaction except the final one is only verified by the two participants in the channel, right? They, they sign it, they, they verify it's good, they do another update, they throw it away and sign a new one, right? And then that one that they threw away doesn't have to be published, it doesn't have to be verified by everybody, and that's a meaningful scaling improvement, right? And then, like ARC is, is similar, it's, it's- In many ways, like Lightning, it has a different topology of, of how, how, how channel closures work, which, which should be more resilient to like some catastrophic everybody trying to exit at once kind of construction, and which I think has more room to be improved by covenants. so I've never really thought of Liquid as a scaling solution for Bitcoin, as, as far as its relationship to Bitcoin. Right? I think it, it, it works nicely as a place to prototype some functionality, at least where that functionality doesn't depend on or, or get interfered with by the, the multi-sig support too much, right? The testing ground, let's say. Yeah, yeah. It's a testing ground, I should say, right? It's not, I, I really don't want to, to pretend like, of course, yeah, testnets and Signet and so The Li-Liquid is very different from Bitcoin, and, and lots of Bitcoiners really don't like Liquid, so I don't wanna pretend like it's, it's sanctioned or by the Bitcoin community in, in any sense. But it is a very similarly shaped blockchain that, that, we've got a number of Bitcoin developers working on who are able to, to kinda get stuff deployed on, fairly quickly, and with less, less coordination than on Bitcoin. So yeah, so as I see these L2s evolving on Bitcoin, I think that that's awesome, obviously, that's great for Bitcoin. And then I maybe keep half an eye on like, do we want those L2s on top of Liquid? Right? Like I think of Liquid as a separate L1 beside it, and like, is use cases or not? Liquid isn't, isn't competing with other L2s, right? If anything, Liquid could be, Liquid could just like copy those L2s and we, we could use the same L2s on Liquid, if we, if we ran out of space in our four meg, right? As,

I know some people talking about you could theoretically run Lightning on top of Liquid, right? And so you could do kind of various ideas. but I guess one thing, definitely I noticed was Liquid did get a bit more adoption during the fee spike of the, you know, the Retardinals or Audenals era. So, that was something we saw a lot, you know, we saw a lot more people using it for this kind of- Swap, like, like Aqua Wallet or this kind of Boltz dot Exchange, Breeze SDK sort of use case. there's another wallet called Stash, I think it's Stash Pay. But anyway, the point is, there are people who are using this as like a kind of a cheap transactional chain, let's say. ironically, kind of like the, the B-casher transactional chain, which is ironic given the way historically things played out. but, yeah, it sounds to me like your focus is maybe, yeah, it's a testing And also this asset issuance, capital markets seem to be more like the likely use cases of Liquid, let's say. Yeah. so I guess any closing thoughts? What should people think about? what are you looking for in terms of, I guess, feedback or developers to go have a look at Simplicity?

Yeah, yeah. So we, we launched Simplicity, probably when this was published close, close to two weeks ago, and it's, it's live on Liquid. we are, Working, we have a website, simplicity dot hl dot org, and we are, we are frantically working to, to write READMEs and contributing documents and welcome pages and, and documentation and all this to, to bring people in. we have one job opening, probably we'll have a, a few more soon, for a developer advocate, which is somebody who wants to play with our web IDE, wants to put together presentations, wants to, to work on this documentation, really just even identifying missing documentation and, and letting the rest of us know. So that, that's super helpful. building, improving our error messages in our compiler, improving, all these kind of user-facing things and, and, understanding what people are trying to do with Simplicity and, and where the pain points are. So we've, we've got a job opening, for that, which you can find at blockstream.com/careers and, and keep an eye on that page for, for more things. and I'll probably close with that. Simplicity-ligh- dot org, And hey, hopefully I'll be back in six months, and we'll be able to talk about how we have simplicity on, on Cygnet or on MyniNet or something. But we're not there yet, so, so where I'll close today is, is Simplicity on Liquid, it's live today, simplicity-lightning.org. So, thanks. Fantastic.

Alright, well, thank you for joining me, Andrew.

Yeah, thanks.