Verifiable Smart Contracts with Simplicity

What is up, Vegas? How's it going, guys?

​

We got a full house in here.

​

Vibes are high. We have a great conversation lined up. Last time I interviewed Andrew, I asked him a single question, and he told a 30-minute story, and then we both walked off stage together. So we're going to start with Scott today. Scott is the founder of SideSwap. He's building self-custody financial services tools on Liquid.

​

Liquid is one of those projects that I find fascinating. It always seems technically intriguing, but in practice we haven't really seen much usage of it. I think SideSwap is probably the single best Liquid app experience I've ever used. So Scott, on that topic, when you're building out SideSwap and the other tools you're working on right now, how do you think about Liquid and Liquid adoption? Why do you think we haven't seen the kind of usage that maybe the hype would have had you believe five or six years ago?

​

It's a very good question. It's the one we are always struggling with in terms of how we can bring more people into Liquid. I think when the SegWit discussion was raging, Liquid probably took a bit of a beating during it. But in terms of the tech stack, in terms of what we hope to accomplish, I think Liquid has all the tools to build a Bitcoin-based financial system with multiple asset issuance and everything else around it.

​

Now, with Simplicity coming, there are so many more tools coming online, enabling us to truly build all of these products, like prediction markets, et cetera. We're super excited. We've been growing organically for quite some time, and I think adoption is finally growing. There's big adoption coming from Brazil right now with a stablecoin being issued there, and Liquid having USDt on the chain is a very big win for Liquid. It makes it the default Bitcoin sidechain to work on since it has USDt.

​

The Brazilian adoption is fascinating because it's been relatively organic. We had a conversation earlier where it kind of caught you off guard. You didn't manufacture that. The users came, and then you embraced them.

​

Andrew, to that point, I didn't introduce Andrew. Andrew is one of our Bitcoin wizards that we're very fortunate to have building in the Bitcoin space. You guys at Blockstream put a lot of work into Liquid. In your opinion, why hasn't the adoption necessarily lived up to the hype?

​

I can give a couple of answers to that. One issue that we've had continuously until quite recently is we've been pretty poor at communicating. It's nice of Scott to say all these nice things about having all the tools you need, but our developer documentation for many years was basically missing, atrocious, or out of date. Our developer outreach really was not focused on developers.

​

I can take some responsibility for this because I was, for most of Liquid's life, the director of research at Blockstream, and I was responsible for spearheading much of the technology that we were putting into Liquid. But as we were building technology that goes into the Liquid blockchain, we were thinking about what we can implement in a node, what we can verify efficiently, and what cool crypto we can pull together and verify efficiently. The question of how you actually use this was a problem for the wallet developers. We didn't really think about who the wallet developers were.

​

It largely wasn't us, and we didn't provide wallet developers the information they would need to build this. It turned out there are a lot of hard problems in developing wallets, some of which Scott might talk about, around how to handle multiple assets that have interesting semantic meaning when you're attaching scripts and stuff, and some are crypto issues.

​

We developed this thing called Confidential Transactions on Liquid, which was one of the headlining features of this blockchain. We could hide all of the amounts and all of the asset types in all your transactions without adding some ever-growing accumulator thing, and without having the same asymptotic scaling problems as Zcash. In order to do that, you effectively need to manipulate this extra secret key data for every single input and output in your transaction. So if you're trying to do a multi-party transaction, you now have to do some crazy multi-party crypto protocol instead of just passing a transaction around and signing it. We never really worked through that problem, and we didn't provide the documentation to even start working through it. We were focused on building other stuff.

​

That's one answer. I have one other answer, which is in terms of scripting capability. This is kind of more of the same thing. When Liquid launched, we took Bitcoin Script and extended it to provide covenants. We added OP_CAT, everyone's favorite opcode, and CHECKSIGFROMSTACK. Together, those two allow you to do covenants, basically arbitrary contracts that have multiple stages and all this cool stuff. We added a half-baked collection of other opcodes that aren't so interesting. We published a few blog posts saying, here's how you build covenants, and threw it out there to see if anybody would take our blog posts and try to build something.

​

Some years later, within Blockstream Research, we actually did start building options and financial products with this, and we immediately ran into this 201-opcode limit that we forgot to remove, and a bunch of other pain points that made it extremely difficult to do. So we frantically updated to Taproot, which conveniently removed a whole bunch of script limits and other stuff. That got us past all of these limits, and now we at least could use these opcodes to build cool stuff. But we couldn't reason about it. It was such a head-bending thing to try to build smart contracts this way. It basically didn't work.

​

Then we started prioritizing Simplicity, which we'd been working on without launching for about ten years. We were like, okay, now we need a serious smart contract language. Let's just put Simplicity out there. We made a huge push. We cleaned everything up. We got everything polished, production ready, and tested, and launched it on Liquid. That was only like a year ago, 18 months ago, or something. Liquid has been around since 2018.

​

This whole time we've been hyping up a confidential transaction system that wallets don't know how to use, an expressive scripting system that was basically impossible to use, and then a pile of other features. Really, we failed to communicate. Over the last year or two, we've come to terms with these problems. Blockstream has done the right thing in hiring a lot of people who are not me to work on these things, because this is not my core competency, making things people can use and explaining how to use them. I think it took me a long time to come to terms with that, and I guess the company as well.

​

Maybe somebody could try to spin that positively for me.

​

It's going to be a hard one, but we made it. I don't see him in the audience, but real quick, huge shout out to Francis and Pedro, because the live zaps are really cool. Maybe I'm just a nerd. I will say to anyone who's listening from the BTC Mag team, it'd be great if I could see the zaps up here next year. Wouldn't it be awesome if you just saw people throwing money at us? Anyway, thank you for your support, whoever is zapping, because I can't see.

​

Scott, to Andrew's point, what are you excited about building with Simplicity? The crazy thing to me about Simplicity is it's actually very complicated. The name is misleading. It's a hard thing for me to wrap my head around. What is the end-user experience that you think you can build with something like that?

​

Again, a great question because there are so many things to figure out. The first thing that we did was build this Liquid Connect function where web pages can connect to our wallets. When you build these different products that use Simplicity, you need to be able to create the transactions and have everyone interact with each other, because the whole premise is that it's non-custodial. Since you need multiple parties to join in and create transactions together, you need a way for everyone to communicate with each other and to make that efficient. We built this Liquid Connect function, which basically connects the wallet.

​

Over and above that, you obviously need to build the Simplicity products that people will use. The UX is very important, to make the function easy so they can connect to any web page, like a MetaMask-type connection or connect wallet. Once they have that, you need to make the interaction on the web page as easy as possible. In a sense, you need to obfuscate quite a bit of the flow to the user.

​

The function will effectively have the ability to see a watch-only copy of the wallet, so it can create all the inputs and outputs for the transactions. But once the user gets on to the web page, they don't really interact with the Simplicity scripts themselves. Everything runs in the background, so you can obfuscate a lot of it in the UI. It becomes point and click. Just sign the transaction, and once you have placed the prediction that you want, anyone who's looked at any of the prediction market pages will recognize that it works the same way. Once you click the button, you'll receive the transaction notifications in your app so you can review everything in the app, decide if it makes sense, sign in the app, and it goes back.

​

There are a couple of cool technical problems that Scott glossed over in describing this Liquid Connect thing. A big one is that Liquid has no bulletin board. If you're building smart contracts in the Ethereum ecosystem, there is a culture and a lot of technical support for this. If you need to store state, if you need to store data, just throw it into your contract code. They have a payment system, and we can argue about whether this is incentive aligned, but essentially every single node for every single contract maintains this giant lookup table of arbitrary amounts of data that they are able to query and look up. There is this global key-value store that everybody can query.

​

Liquid inherited from Bitcoin both a cultural and a technical opposition to that. The technical opposition is that this doesn't scale. If you've got nodes that are validating all of your transactions and all your blocks, you can't make them maintain this giant stateful database. Even before the recent boom in data storage needs, disk space was kind of at a premium, certainly the fast random-access disks that you need for this.

​

So this is a problem if you're building smart contracts. If you're trying to do a multi-party transaction where one party publishes an offer and somebody needs to take that offer or drop it, somehow you need a way to find out about this. We don't have a global storage medium other than the blockchain itself, which is not indexed to do random data lookups. You can't access arbitrary blockchain data from within the script system. We don't really have a storage mechanism. You have to do this commit-reveal dance, which is difficult and importantly doesn't give you broadcast. The peer-to-peer layer doesn't support this.

​

Bitcoin, and therefore Liquid, is not Nostr. It's not an arbitrary data-passing-around layer. Nostr appeared and is actually helpful for this kind of problem because it turns out in a lot of cases you can freeride on Nostr. They want a bunch of noise to help obfuscate whatever the legitimate use case of Nostr is. It's just everybody passing around data that they can't see. It's awesome. That has been helpful.

​

Having no bulletin board is one difficulty. The other one, which the Ethereum world embraced but we in the Bitcoin world cannot, is that if you have an order matching mechanism where you publish an order and somebody grabs it, this is inherently front-runnable by whoever is collecting and matching all of these orders. In the Ethereum world, the block collectors or block creators take all of these orders, put them together, and reorder them in whatever way gives them the maximum amount of fee, or may even allow them to be a middleman. The result has been this incredible centralization of block construction in the Ethereum world, which has been a great cautionary tale for us.

​

In Liquid, because Liquid is a federated chain, it's not a public blockchain with arbitrary miners. We could arguably embrace this as well, but we won't, because we don't have the constitution to do something that would be so antithetical if it was on Bitcoin. We've got to figure out how to solve this problem without creating these horrible incentives to create miner centralization and block construction centralization, which is a really difficult open problem.

​

Then Scott shows up with a company to run and a product to build. I'm saying this is a really difficult open problem, and the future of the social fabric of Bitcoin depends on us not doing it wrong, so if you could hold off on making money until we solve it right, that would be cool. It's a tough ask.

​

Completely agree. We're not looking to solve a math problem with SideSwap. We're just trying to build a usable product so people can actually access and benefit from the structures within it. What we did initially when we built SideSwap was effectively build a bulletin board so that two people can find each other and construct an atomic swap between two parties, which initially was effectively Liquid Bitcoin and USDt. Lately we've seen quite a bit of volume in DEPIX, the Brazilian stablecoin. Two parties can effectively create an atomic swap between each other.

​

The service that SideSwap offers is the bulletin board and the messaging back and forth. What we also do with Segregated Witness is remove the signatures so that one party will never receive a signed transaction half from the other user, so they cannot effectively save those UTXOs and broadcast them at a later date, or create the transaction if the price moves in their favor. That's a problem that SideSwap has solved within the atomic swap aspect.

​

We also use that as a matching engine for when two people want to trade into, shall we say, a binary outcome contract, which can be anything from a prediction market to anything else. When you have two parties, we can effect that atomic swap into the contract between each other so that you don't have resting orders that can be picked up.

​

I don't really understand how it works under the hood, but Uniswap and things like Uniswap run an AMM model or something instead of a regular order book. With SideSwap, you decided to go with this open order book, almost like you would see on exchanges. Is there a reason you did that instead of going with the Uniswap model?

​

I think Andrew is much better placed to answer, but I don't think it's even possible to do the AMM model, is it?

​

It's not impossible. It's harder. Liquid is in the UTXO model rather than the account model. A lot of the front-running and reordering of transactions I was alluding to in Ethereum, you can't do in Liquid because if you reorder transactions, they no longer become valid. There is a fixed transaction graph. Every transaction takes input from previous transactions and so on.

​

If you implement an AMM on Liquid, the way that you have to do it is essentially you've got some single UTXO out there that has AMM code on it. When somebody wants to deposit or withdraw from the AMM, they take that and spend it. In order to spend that, they have to satisfy the rules of the AMM, and Simplicity would enforce that. Then whatever the final balances are have to wind up back in the AMM contract, and then the next person does this.

​

Without some sort of coordination mechanism, if you have a hundred people or a thousand people trying to use this AMM at once within a block, what you'll have is a thousand different conflicting transactions, and only one of them can get into the next block. This is bad for block propagation and not great for the network, but also for users of the system. It means if you try to interact with the AMM and create and publish a transaction, maybe you've got a 0.1% chance that you're able to get into the next block. Otherwise somebody is going to have to reconstruct this.

​

In Ethereum, it's pretty easy to do an AMM-style solution because you've got this AMM contract code sitting there and it doesn't care what order things happen in. That's the block creator's problem. In Liquid and in the UTXO model in general, that order needs to be fixed in advance.

​

There are solutions to that, but they're hard. They're harder than just using SideSwap, and they're harder than using some sort of bulletin board outside of the system. Ultimately they ground out on either having some sort of central coordinator who is choosing an order and signing off on it, or using complicated Simplicity code to break the transaction graph in a way that allows it to be reordered, and then somehow teaching miners or nodes how to do that reordering, and doing so in a way where they aren't incentivized to develop crazy profit-maximizing ways to do the reordering, plus all the other wallet, user-facing, and infrastructure pieces around that. That's many of the difficulties in building an AMM on Liquid.

​

That actually makes sense. Scott, you keep saying prediction markets are your goal here. Are you trying to build a Polymarket competitor on Liquid?

​

Effectively, yes. But right now we're just playing around at the edges of what's possible and trying to figure out the best way to onboard users in terms of the UX. They will need a SideSwap wallet because no other wallet is able to interact with the products that we're building yet, but hopefully one day more wallets will be able to participate.

​

For now, we've built the initial products, where you can bet on Bitcoin prices. Will it be higher or lower in the next amount of time, or will the Bitcoin price go up or down a certain percent first? We're also looking at creating more casino-style games where you have provably fair betting and can place bets. The nice thing is that we're looking at making it so anyone can be on the dealer side. Anyone can act as the house effectively.

​

The same thing applies with prediction markets. As long as you have a binary contract, you can have any outcome that an oracle can decide as a yes or no outcome. As long as you trust the oracle, the contract is a fairly straightforward setup. You just need to arrange all the market mechanics around it.

​

At this stage, with the contracts we're looking at, anyone who enters into them must hold the contract until maturity, which is a limitation right now. Another limitation is that once you enter into a contract, the position that one party has taken cannot be traded with a third party, so that someone else can replace whoever has taken the contract. At least at this iteration stage, anyone who enters into a contract needs to hold it to maturity. An open-ended contract with uncertain end dates wouldn't be wise today. But baby steps.

​

I think those are all solvable. As a fan of Polymarket, one of the coolest innovations of Polymarket compared to a traditional sportsbook is that you basically have liquidity before the term ends. I think that's a key piece. Do you think that piece is solvable?

​

That piece is definitely solvable because it's effectively just someone who is willing to quote prices at some point in the order book. Just like any other bots that hedge between exchanges, you could effectively hedge between prediction markets, I suppose. I don't see any issue there.

​

One interesting bit of financial context is that you can build a prediction market out of a tradable options market. You can also build a futures market out of tradable options. You can enable all sorts of hedging and speculation use cases. You can basically build anything in the financial world just by cobbling together enough options.

​

Maybe a natural question is to say, why don't you build an options market? That will solve all these problems for you. The answer is that all the problems you've described, you have to solve in order to do options.

​

I think we were talking before this, and one of the biggest ones is that in order to have positions that you can trade out of, whether these are just prediction-market-like binary tokens or whether they're options or whatever, you need a way for a wallet to understand what these tokens mean. At some layer of the technology stack, you can implement these as dumb tokens, like the equivalent of ERC-20s in Ethereum or something. But in the end, if the user is holding an options token that represents the right to purchase Bitcoin at a given price on a given date, the wallet needs to know what that price and date are, and whether it's a put or call.

​

If it's a betting token, it needs to know that this token represents the outcome of some event which is signed by such and such an oracle, which will conclude at such and such a date or under such and such conditions. This leads into the general question of whether everybody who implements these kinds of markets needs to implement their own wallet. Do we have some general wallet language for describing these kinds of things? What does the life cycle of one of these tokens look like?

​

The main question is, when you set these contracts up, do you have the contracts so that at expiry they pay out to predetermined addresses, or do you have it so they pay out to whoever controls a claim token effectively? If you create these tokens, how do you handle it in the wallet at the end, where everyone needs to claim? What happens with coins or tokens that never claim anything? Coins get stuck. There are so many other UX issues that arise because of it, so that's why we're initially starting at the easiest point.

​

Quick final thoughts, Scott?

​

I love the work that they're doing with Liquid. Bitcoin is finally getting the scripting capabilities so that we can actually build proper financial products, just like all the other chains. I think the volume there has come from Bitcoin not having these capabilities. Finally, it's coming. SideSwap is a company trying to help solve this. If we're doing it correctly, who knows. But I love it.

​

You're doing great, Scott. Final thoughts, Andrew?

​

Believe it or not, I am very excited and optimistic about all of this stuff. These problems are definitely solvable. The ways that we're coming up with to solve them, we didn't dive into the technicals of Simplicity or SimplicityHL or what this wallet protocol that I hinted at would look like, but the solutions that we're building for these things are big and general. It's sometimes difficult to just get a product out the door with them, but they enable a very broad range of things at a level of trustlessness, or a minimum of trust, however you want to frame it, that really nothing else even comes close to. That's super cool to me.

​

I just want to give a huge shout out and thanks to BTC Inc for how many resources they continue to put behind the open source stage and this whole hub area. It's actually been really beautiful to watch over the last five or six years. It started in a sweaty nerd tent in 2021 in Miami, and we've really come a long way. Huge round of applause for Andrew and Scott. Thank you, guys.