Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - James Prestwich: Summa One – Cross-chain Financial Instruments and Contracts

Episode Date: December 12, 2018

While trustless interactions on Ethereum are native to the protocol, trustless interactions between the Ethereum blockchain and other blockchains are difficult to implement. Interoperability protocols heavily rely on atomic swaps, which typically come with a free option problem. For this episode we’re joined by James Prestwich, CEO at Summa. Summa designs and implements cross-chain financial contracts and instruments such as swaps, options, futures, and auctions. Summa recently conducted a dutch auction spanning the Bitcoin and Ethereum blockchains: Ethereum NFTs were auctioned off trustlessly to bidders on the Bitcoin network. We also discuss Riemann, a framework for deploying transaction scripts to UTXO-based chains, as well as the advantages of the predictability of transactions in UTXO-based chains and how to bring some of those advantages to Ethereum smart contracts. Topics covered in this episode: James background in Japanese and how he became interested in blockchain James contributions to Bitcoin Script Summa’s recent cross-chain auction in which Ethereum NFTs were auctioned off to participants on the bitcoin network Riemann, a framework for deploying script based transactions to UTXO blockchains Atomic swaps leading to free options Advantages of transaction predictability in UTXO based chains Episode links: Summa Website Cross-chain Auctions via Bitcoin Double Spends (article) Statesless SPV (article) Declarative Smart Contracts (article) Introducing Reimann (article) James Prestwich on Twitter Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Friederike Ernst and Sunny Aggarwal. Show notes and listening options: epicenter.tv/265

This episode of Epicenter is brought you by Microsoft Azure. Configure and deploy a consortium blockchain network in just a few clicks with pre-built configurations and enterprise-grade infrastructure. Spend less time on blockchain scaffolding and more time building your application. To learn more, visit aka.m.s.combe. Welcome to Epicenter. This is Federica Ernst, and I have with me. Sonia. All right.

And today we're speaking with James Bestwich. who is the founder of Summer and is talking with us about cross-plain options and how to improve the smart contract development on Ethereum with ideas that come from the UTXO world. Yeah, so, you know, I actually met James first time about probably 2016, I think. So I had actually given a talk at blockchain at Berkeley on Storj, which is a project he worked in the past. And so he actually saw my talk. He reached out to me. He said like, oh, wow, this is like, you know, probably one of the best, like, uh, quick explainers of StorJ I've seen. And then, you know, I invited him to come give, uh, even more in-depth talk on, uh, at, at Blackson

and Berkeley. And he gave this, like, really cool talk about, like, you know, how Bitcoin scripting and stuff works. And they had, at that time, they were going through this process of actually, uh, moving Storjay from, uh, counterparty, which is, like, built on. on Bitcoin and moving it over to Ethereum. So he was actually, you know, from very early on, I knew he was like super into like the whole like relationship between like different smart contracting paradigms and whatnot. Yes, and you will tell us all about how they recently did a first option,

reverse Dutch auction, auctioning of NFTs on Ethereum for Bitcoin on the Bitcoin network. So that was super interesting. Yeah. And so, you know, Summa, they've been working on, like, all sorts of different cross-chain, like, contract. So, you know, obviously I, you know, working on Cosmos, I'm very interested in, like, you know, cross-chain stuff as well. But we focus more on, like, the sidechains side of things. Well, Summa is more on, like, the atomic swaps, like, you know, trading Bitcoin for ether, like, atomically or, you know, let's say I'm selling some, or, like, you know, this whole new cross-chain auction stuff that they're working on, where it's like, you know, I can, sell a CryptoKitty or Ether or some ERC20 on Ethereum for Bitcoin.

And so, you know, they've been using like a Dutch auction system, which, you know, Frederick you're obviously very familiar with. So, you know, that was a very cool, like, kind of we didn't get, we got a chance a little bit to like talk a little bit about the differences between like, you know, what are the benefits of like cross-chain Dutch auction versus like a fully on Ethereum Dutch auction, which is cool. And then, you know, just for full disclosure for all the listeners, you know, I, my, I actually, my roommate or flatmate, rather, is actually Rachel, who is a, you know, one of the lead engineers at Summa. So, you know, I, I'm quite familiar with Summa, and I said, you know, I do have a little bit of, you know, indirect personal relationship with them. So just as a forewarning.

Enjoy. Welcome to Epicenter. And today we're here with James Springer. Presswitch, who is the founder and CEO of Summa, according to their website, a fairly young startup offering cross-chain financial services. So welcome to the show, James. Can you maybe introduce yourself a little bit, tell us a little bit about what your background is, and how did you first get involved in the blockchain space? As you said, my name is James Crestwich, founder of Summa. Previously, I worked with Chia on the Chia BLS implementation a little bit,

as well as on Chia Script. And before that, I was the co-founder and COO at Storage, decentralized cloud storage system for about three years. I got involved in the blockchain space back in 2013 and had been working here full-time since 2014. I guess what really got me interested in at first was the consensus aspect is that we can use proof of work and we can use blockchains to bring thousands of nodes to consensus on something. I think we've spent the last four or five years trying to figure out what that thing should be and it's still kind of an open question. But, you know, it's fun.

So what got you interested in decentralized trials? storage? That's one of those things where the market for storage hardware is pretty fragmented. There's a few big manufacturers, but it's all split up between consumers, enterprises, and data centers. And when you look at the market for cloud storage, there's really only two or three major players. I think we could do a lot better. And trying to solve that problem is what got me interested in the first place. I get involved storage because I was living in rural Japan and had way too much free time to think about things like this. So yeah, I guess I kind of stumbled into it mostly.

Speaking of rural Japan, I actually saw on your LinkedIn that your, you know, your bachelor's was in Japanese and then you just like sort of jumped right into like building decentralized storage marketplaces. And how did you like, you know, that, that leap come in. Like how did you, you know, what was the relation there? You know, what my LinkedIn won't tell you is, that I did a few years of computer science major as well before switching out. Japanese was and still is a passion of mine. I was expecting to take like two semesters of a language as an elective

and ended up spending four years on it and then moving to Japan. I think like what they have in common is that you have to be constantly learning and all of the problems are hard and interesting. Yeah, learning a language is difficult. Learning a blockchain is very similar. You have to go into all of these intricacies and these special little rules that only apply in certain situations. It's half memorization, half investigation, and the third half is just like spending the time, right?

Yeah, for sure. So you spent three years at the storage and then left. What happened? What made you leave? You know, I think a few of us were looking to leave. a while and we went through the whole token sale process. We set the company up for success in the future and they're doing great and then we decided it was about time to move on.

And so from there you when you moved on to, you mentioned you were working with Chia a little bit, especially working with them on like, you know, I know Chia was really, they were focused on like kind of like improving Bitcoin script and updating it and so you were helping about a bit on that. How did you, you know, get involved with that, yes? Yeah, I ran into Graham Cohen at, let's see, it must have been scaling Bitcoin at Stanford, end of 2017. And so we got talking about the kind of advantages and disadvantages of Bitcoin script and the Bitcoin consensus mechanism design, kept loosely in touch for a few months until it made sense to work together.

While I was there, we mostly worked on Chia's BLS signature implementation and on designing ChiaScript. Of course, it's been almost a whole year since I left, and their stove is doing good work on Chia Script. It's very much a work in progress. It's great, and it has most of the properties that I want out of a scripting language, so very excited about it. And finally, at the beginning of this year, you started your own project, right, Summa, with two co-founders, Barbara and Matthew. Can you tell us a little bit about how you know the two and what made you three set out

and start Summa, what your vision is? Yeah, Barbara and Matthew and I all work together at Storage. And so we already knew each other. We had a lot of experience working together in high pressure situations. And so around the beginning of the year, it just all made sense. We had all taken some time off and worked contracting on other things. And around January, February, we got together and started looking to raise money to work on cross-chain financial contracts. And, you know, that's how Sue was started.

What got you interested in cross-chain financial contracts in the first place? Yeah. So towards the end of last year, I had a lot of spare time to spend on learning about the interests of Bitcoin, learning how blockchains work in practice. So all of the fiddily implementation details and the leftover bugs from Satoshi. and one of the things that I spent a lot of time on was atomic swaps. And back then I wrote a little blog post about how frustrating they are and how bad the user experience of atomic swaps is.

And, you know, I thought it would be just a little one-and-done, you know, blog post complaining about stuff. And, you know, it kind of got me thinking about it a lot. more is if you actually want to use these things how can you improve them how can you take them from something that's a like six-hour synchronous protocol uh with the free option problem with liquidity trolling issues and turn it into something that people could actually usefully use and so after that it was a i think i like woke up one morning with a few ideas like two weeks later and started just writing it down.

Very few people have worked on these in practice. Almost no research has been done into how you extend the protocol or modify it. So at this point, we have four or five good variations on the Atomic Swap, which I've talked about some in public, but mostly just have notes on. And we're building out software, seeing what works, seeing what people want to use,

and trying to put a product out there people will use. I see. So, I mean, I know, going through your blog, your personal blog, a few months ago, you actually had a post talking about, or not a few months, maybe even a year ago. You actually had a post talking about why people should be less excited about atomic swaps. What changed? You know, I spent a bit of time on it,

and part of it was figuring out a few ways to improve the atomic swap construction. And part of it was realizing that people were just trying to use it to do the wrong thing. It's really poorly suited to exchanges. It's actually pretty well suited to options. You know, I mentioned the free option problem earlier. In an atomic swap, one of the participants has the choice to complete the trade or to cancel it. And they have that choice for several hours. So they decide what happens.

In that sense, they have an option on the other coin, right? And so it's pretty hard to patch out this option, but what you can do is embrace it and use the atomic swap to do a cross-chain option. So it's not really that something's changed, it's that my perspective on it flipped a little bit. So essentially, like, you know, what you originally saw as the bug in these atomic swaps

which you saw was like getting free options, you decided to decide, like, you know, let's turn that into the feature, let's make the cross-chain auctions itself, like the product that we're selling. Yeah, yep. Cool. So maybe like, could you explain to us a little bit

about how that atomic swap works and like why this like whole option situation exists? Yeah, the atomic swap is a two-player game, basically. We want to exchange my Bitcoin for your ether, right? And we want to do it at a rate that we decide between us, say maybe 20 ether for one Bitcoin. I don't follow price bunch, so that may be way off. But, you know, we want to agree on this rate, and we want to do this trade with no third parties involved, all on chain.

So we can make it completely trustless, right? So what we're going to do is I'm going to make a secret and tell you the hash of that. secret. And I'm going to make a Bitcoin contract that is payable to you if you learn that secret. And otherwise, it'll refund the coins to me after a certain amount of time passes, right? So I'm going to pay Bitcoin into that contract. You can see that I did this. So you know that you'll get those coins if you learn the secret. You're going to pay ether into the same contract. Except this time, the ether is payable to me if I tell you the secret. Now, when you say same contract, but it's a similar design contract on a different chain, right?

Yeah, it's the same terms, but on a different chain. So you're paying into an ether smart contract here. The smart contract enforces basically the same terms, but obviously it doesn't in solidity on chain and ether, which is completely different from Bitcoin script. So you're going to pay into the same contract terms. Payable to me if I tell you the secret, refunds to you after a certain amount of time. And so at this point, we've set up the atomic swap. I can reveal the secret to take your ether. You can see that secret on chain and use it to get my Bitcoin. So the free option comes in if I just, decide not to reveal the secret. So because we do this on chain, it takes block confirmation

time. Anytime we want to change the state of this contract, we have to wait a whole block confirmation cycle, an hour, give or take. So I have at least one hour where I get to choose whether or not to reveal the secret. And that means I choose whether the trade happens or whether we both get a refund. And so if the ether rate moves against me, so if ether drops 50% in that hour, I can choose just not to complete the trade. And then you get stuck with the ether and I keep my Bitcoin. So in this sense, it works like an option contract, right? I have the choice and you are just along for the ride. So essentially what's happening here is like normally when I do an options contract with you, I have to pay some sort of like premium on that, right?

Whoever has the choice pays a premium. Right. And here I'm getting it for free. Yeah. In the real world, I would be paying you money and here I'm getting it for free. I see. That's not really a sustainable situation. One of the other major concerns is once I have paid the initial Bitcoin into this contract, my Bitcoin are locked up for some amount of time, several hours, probably five or six. And you are supposed to send ether into this atomic swap contract, but you could just walk away. And so this is the liquidity trolling problem, is you can just cause me to lock up my Bitcoin for no reason, and then I lose access to it for six hours. And you lose nothing. And it costs me, well, a lot of annoyance,

probably some money. So there are a few ways to fix these things. The liquidity trolling is pretty complex to get into, but the free option problem, you can add a premium payment, and we can embrace the fact that this is an option. If you've listened to previous episodes with Marley Gray and Matt Kernar, you know that Microsoft is committed to providing enterprise-grade tools

and infrastructure for blockchain developers. Well, the Azure blockchain workbench is perfect for organizations building consortium networks. Take the Ethereum proof of authority template, for example. It's ideal for permission networks where consensus participants are known and reputable. Ethereum on Azure has on-chain network governance that leverages Parody's extensible proof of authority client. Each consortium member has the power to govern the network or delegate their consensus participants to a trusted operator. And Parody's WebAssembly support allows developers to write smart contracts in familiar languages like C, C++, and Rust.

Azure Blockchain Workbench was created on the same principles that drive all production services in Azure, so you know you're relying on secure, redundant infrastructure that can scale. And with built-in services like authenticated APIs, off-chain databases, and secure key management services, you can scaffold your infrastructure

in just a few hours. To learn more about Azure Blockchain Workbench and how Microsoft is advancing blockchain usability and enterprise, check out aka.m.s. And start building today. like to thank Microsoft Azure for their supportive epicenter. So I know I saw one of your talks at a conference a few months ago in SF, I think.

And by the way, it was my favorite talks because it was like right in the middle of a bunch of like ICU pitches and stuff. And you had this like 15 minute time slot. You just like went in, explained a bunch of technical concepts and just got off the stake. This is the most efficient technical talk I've ever seen. But yeah. So in that you actually talk about what you, that talk was actually. you know, you titled it better atomic swaps. And so there you talked about like mechanisms where you can actually like play with the timeout and include some additional constraints that

actually make this atomic swap process better. So can you explain a little bit about what, you know, a short gist of that talk that you gave? This gets pretty technical pretty quickly. But um, what I was talking about that day was a quick solution to the free option problem. Unfortunately, Unfortunately, it can't be used with every chain. So this is basically like doing an atomic swap inside out, is saying that both of us must fund within an hour, and then after that, it's mandatory for both of us. Either of us can back out within that hour,

but it's mandatory after that. And so this kind of gets rid of the liquidity trolling issue, right? because I have this period where if you don't fund, I can just back out and get my money immediately. And it gets rid of the free option problem because once an hour has passed, there's no more optionality. It just happens, right?

The downside here is that it can only be used with certain chains. At least one of them has to support a specific transaction expiry feature. So that side of things you can basically only, do with Ethereum or other smart contract chains right now. And so you might be able to do this improved atomic swap between Ethereum and Bitcoin or Ethereum and Lightcoin, but you can't do it between Bitcoin and Lightcoin, say. And this is really interesting to me because I came up with this when I was really investigating the differences between all of the deployed blockchains. You might notice that the atomic swap that everybody uses is perfectly symmetrical, right?

We both pay into contracts with the same terms. What is really interesting is that when we start making them asymmetrical, when we use different terms on Ethereum than we do on Bitcoin, we can do some really powerful things, like patching out the liquidity problem. I see. And so, you know, you mentioned also a few minutes ago that, like, you know, there's different ways you can create, you can parameterize these atomic swaps in order to create sort of different financial instruments or derivatives. And so, you know, we talked about, you know, we talked so far mostly about, like, options that, you know, I've been told that it's possible to also create things like futures or other sort of instruments.

So can you explain about, like, you know, you mentioned, you. had four like different like designs that you have and could you explain a little bit about how each of these work or what at least what they are? Yeah. So we work on a bunch of things that are based on atomic contracts and we work on some things that are based on SPV proofs, which we can talk about a bit later. Talking about atomic contracts, we've covered a lot on options and we've covered some of just mandatory exchange. You enter into a contract and then it must happen, right? If we're willing to get away from just strict exchange of Bitcoin for Ether,

we can actually use atomic contracts to pay Bitcoin for any smart contract call on Ether. So for example, we can pay Bitcoin for E&S domains, or we can pay Bitcoin for NFTs. One of the prototypes that we built is paying Bitcoin to issue new tokens from an ERC20 contract so that anybody could pay Bitcoin to buy new, fresh-minted ERC-20s. The structure is really flexible and generalizable that way. Almost anything you can implement in Ethereum can be paid for.

for with Bitcoin. Maybe to make this a little bit more concrete. So you did this recently, right? So basically you actually had this contract that actually sold a number of NFTs on Ethereum for Bitcoin. So how does it work exactly? What actually happens to the Bitcoins that I pay? Well, we've actually done this two completely different ways now.

We've done minting using the atomic construction. So we've talked a lot about options. When we're talking about minting something fresh, we usually call it a warrant. It's the same as an option just on fresh minted tokens instead of some ether that already exists. The other thing that we did very recently was a cross-chain auction on some NFTs. And this doesn't use the atomic swap construction. This uses something new that we came up with called Stap.

stateless SPV proofs. I'm not sure where to start explaining these. Atomic swaps have to be pre-negotiated. So me and Sonny have to agree on this exchange or this contract that I'm bringing into. And then we have to agree on the hash of a secret and who holds it and how it all works. The real advantage of SPV proofs is that we don't have to agree on anything ahead of time. If I'm selling ether, I can just set my requirements and let someone come in and pay me. This is going to get real technical, real fast.

But the basic way it works is I want to sell 20 ether. I have an asking price of one Bitcoin. Anybody can come in and pay me a Bitcoin and submit a proof that they did so. So this proof comes in the form of a Bitcoin transaction that pays me, a Merkel proof of inclusion in a Bitcoin block header for that transaction, and then a bunch of headers that come after that that have a lot of work done on them. So anybody can come in and show this proof to the smart contract, and the smart contract will validate it, which validates that Bitcoin. was paid to me. And if the transaction and the proof and the header chain I'll check out, the smart contract will distribute the ether or the tokens or whatever. How do you make sure that this only happens once? Or how do I make sure that if I want to

buy something off of you, I don't run the risk that someone else has had the same idea previously and has already started doing this because this is a timely process, right? because you need a number of, you need to wait out a number of blocks until you have the proper proof that I can come show you. How do you make sure that several people don't do this at the same time? The process does take time. Getting six or seven Bitcoin block headers takes an hour, sometimes more. It's worth noting that this is still strictly better than the atomic swap, which takes like four hours in the happy case and longer in the sad case. Okay, maybe we can back up a step. The purpose of a blockchain, The reason these things were invented is to solve something called the double spend issue,

which is, what if I send the same coins to two people? How does the system resolve which spend happened and which spent didn't? Obviously, they can't both be valid, so how do we choose one? The whole proof of work consensus mechanism and the blocks and the transactions are all about solving the double spend problem for digital money. So as a result, Bitcoin is really, really, really, good at preventing double spends. It's literally, you know, the only thing it was designed to do. So what we do is we make it so that everybody trying to pay me is also trying to double

spend Bitcoin. So when I list my ether for sale, I will attach to it a tiny, tiny little bit of Bitcoin. Right now we use 550 Satoshi's, which is something like 0.3 cents. something like that. So they'll attach to it a tiny amount of Bitcoin and say you can pay me, but if you want to get my ether, you have to pay me by spending these coins. So the smart contract checks that those specific coins were spent in the transaction that's included in the proof, that's included in the block, that's included in the chain. And so anybody can come in make a bid, they'll all use those coins to do it, and Bitcoin will ensure that only one of those bids goes on chain. Yes, I understand now that like, you know, Bitcoin's UtXO model, make sure it's only

one person can spend a certain amount of, you know, one UTXO, and two transactions trying to spend the same UTXO, they won't both make it onto the chain. But given that, now how do you apply that to making bids in an auction. Like, you know, not everyone's bidding with the same Bitcoin. Everyone has their own Bitcoin that they're trying to bid with. In Bitcoin, we have inputs and we have outputs. So unlike Ethereum where you have an account with a balance, in Bitcoin, you just have a bunch of coins with serial numbers on them.

And you spend specific coins as your inputs, and you get new specific coins with new serial numbers as your outputs. right? And so what we do is each of the bidders takes the seller's small UTXO. That's an unspent transaction output. It just means some coins that exist and haven't been spent yet. They take the seller's UTXO and they add their own inputs to it so that there's more value, right? and then they take the seller's preferred output, that one Bitcoin I want to be paid, and they add their own other outputs to it. And so each bidder submits a Bitcoin transaction with the seller's input and output

and their own inputs and outputs. So in order for them to do this, they look at the Ethereum contract, they see the sellers input and output there, and they extend that transaction. You know, they add more inputs and they add more outputs and they sign it and they broadcast it to the network. So that works really simply for set price orders, right? If I just say I want one Bitcoin, I can just say, okay, here's a transaction that

pays me one Bitcoin, add your own inputs, add your own outputs. What we've been doing recently is Dutch auctions. So that's a falling price auction, right? And we do this as stepwise. It's not a continuous price, unfortunately, though I think we can do that later. So the way we do this is using another Bitcoin protocol feature, which is time locks. When I sign a transaction as the seller, I can specify that it's not good until a specific time. We can do this in Unix time or we can do it in blocks.

And so if I'm the seller and I want to run a Dutch auction, I'll take this one input, one output that are mine, my like 500 Satoshi In and my one Bitcoin out, and I'll sign that with no time lock. And then I'll make another one that's 500 Stoci in and 0.9 Bitcoin out. And I'll add a time lock for five blocks down the road. So that won't be valid. nobody can pay me that way for five blocks, right? And I'll make a third one with 500 in and 0.8 out. And I'll say that that's valid in 10 blocks. And I can make as many of these as I want

so I can set up a falling price auction by saying one Bitcoin now or 0.9 and 5 blocks or 0.8 and 10 blocks. And so when you want to bid, you see, okay, what's the latest valid transaction or the lowest priced valid transaction? And I will, if that's an acceptable price at my own inputs, add your own outputs, and broadcast to the network. I pay a price that depends on time.

And for that, I actually get something on the Ethereum network. Yeah. Is that correct? Yes. So basically, it's always the same thing that I get on the Ethereum network. Is that correct? Yeah. So we're selling, say, 20 ether for one Bitcoin.

But after five blocks, the price will fall to 0.9. You still get the 20 ether, but you pay 0.9. After five more blocks, it'll fall to point date. At that point you're paying 0.8 Bitcoin for 20 ether. So the price will fall this way until someone out there in the world wants to buy those ether for Bitcoin. until it reaches some market clearing price, right? Okay, so how does it look from the other side? How does the Ethereum smart contract now know that it can release the Ether?

So the Ethereum smart contract is just looking at proofs. It's not following the Bitcoin chain like BTC Relay does. It's just looking at a specific slice. So somebody needs to tell it. about this transaction and about the Merkel proof of inclusion about the headers. The way we set it up that can be anybody. Right now we've been doing it for auctions, we're going to build it into the client pretty soon so that it'll just happen automatically. So I will construct a proof, I will submit it to the smart contract and the smart contract

will check it. So what it does to check it is it sees that it's a validly formatted bitcoin transaction. It checks that it's spending the seller's input, so it knows that the seller is okay with this price. It checks that the transaction is included in the block's Merkle tree by validating a Merkel proof of inclusion. Bitcoin typically has 2,500 transactions in a block, so that means 12 to 13 hashes in the Merkel proof. And so it validates that the transactions included in a block, and then it starts checking work. So the nice thing about proof of work is that you can check it. So we take this block header and we check the hash of that block header and we compare it to the difficulty target.

And then we take another header and we verify that it is that it references the first one and that it has enough work on it. So we hash it and compare it to the work target and we repeat that four or five more times. So the goal here is that we get not 100% certainty, but a very high degree of certainty that this transaction was included in Bitcoin, in the Bitcoin main chain. Exactly, in the main chain, because otherwise you could just use an uncle chain and try to build blocks on that. That would be counteracted by the fact of the work. Is that correct? Yeah, work is expensive. When we're making six Bitcoin block headers, it takes quite a bit of electricity, a small mountain of A6, and quite a bit of time. So the Bitcoin main chain makes block headers at about every 10 minutes, right?

So if I have 10% of the Bitcoin hash rate and I want to make some fake headers, I can only make one every 100 minutes. And if I spend 10% of the Bitcoin hash rate, I'll get 10% of the Bitcoin hash rate, I'll get 10% of. percent of new bitcoins on the main chain, but if I spend it on fake headers, I won't get any new bitcoins. So we'd never actually check that this SPV proof is really included in the main chain. What we check is that somebody spent an awful lot of money building it. What is the benefit of doing this like stateless model over, for example, using BTC relay, which like, you know, tries its best to follow the, like, have the entire history of the Bitcoin header,

Bitcoin header chain. Well, I think there's a few different advantages. One is that I can write stateless SPV proofs in about two days while writing reorg logic and solidity takes weeks and more months. One is that BTC relay, relies on relayers. And historically, relayers have failed to appear. The last time I looked, BTC Relay hadn't been operational in six months.

All those smart contracts are still there. They probably still work, but nobody has actually submitted a header to it recently. BTC Relay costs about the same as doing SPV proofs in the long run. I'm hoping to get some more analysis on this out the door soon. but I don't have a lot of free time to write at the moment. Because BTC Relay has to store information about every header and stores information about transactions and proofs, whereas stateless SPV proofs are basically predicates,

they can just be evaluated immediately and then discarded. And storage is probably the most expensive thing you can possibly do in solidity besides zero knowledge proofs. And so we save quite a bit of gas by not storing anything. I guess for me the main advantage is that they stand alone. They don't need to be included in a larger context like BTC relay or in a larger system. You can look at an SPV proof, you can figure out how much work was put into it,

and you can decide your confidence level immediately with no other context. But so doesn't this like set some sort of like limit on, how valuable of an auction you can do. Because like, you know, let's say the cost of me creating list of six blocks on Bitcoin is like, you know, a million dollars. And then, but that means I can't like auction that like one crypto kitty that went for like 1.8 million or whatever. You know, for to parameterize a little bit, it's about $500,000 right now to create a six block

header chain. Fortunately, that's not the only to. fence we have. So as I mentioned earlier, how much of the Bitcoin hash rate do you have? Because if it's 10%, it's going to take you 10 hours to make a six block header chain. If it's 25% of the Bitcoin hash rate, it's still going to take you four hours, right? So unless you have, you know, almost enough hash rate to 51% attack Bitcoin, it's going to take you a very long time to make a fake proof. So any honest buyer will beat you to the punch because they will have the main Bitcoin chain making headers for them every 10 minutes. And so it's not just a

dollar value here. It's also a level of confidence that a dishonest party cannot make a false proof in a reasonable amount of time. So let's say there's a system in which there's only a single buyer, no one else is buying, is the idea that then the next step of fallback is that there will be a timeout. So let's say you're trying to defend against up to someone with 10% of the hash rate. For them to create a six block chain, it'll take them, you know, 600 minutes and you can say, okay, this auction times out in 300 minutes. And so that basically means you're kind of secure against someone with up to like, you know,

at least 10% of the hash rate? Yeah. If you set your auction to time out in three hours, then you're secure against someone with up to like 30% of the hash rate. There's a little bit of fiddliness here. Because one of the things about timing out auctions is that they can, that mechanism can prevent honest buyers from submitting real proofs. but the Bitcoin transaction that the seller created doesn't get invalidated.

And so you can end up in a situation if you're not careful where an honest buyer paid Bitcoin, but the auction timed out before he was able to submit a proof. And so there's a lot of timing-related edge cases there, which is why we haven't implemented timeouts in this version. Right now, the safest thing to do here is to have these seller cancel. And this is something that can be done fairly trustlessly. If the seller spends their own UTXO, then nobody else can spend it. And they've effectively canceled the auction and can

reclaim their ether. I have a follow-on question here. So basically, you said that creating a six, a six block chain on Bitcoin right now is a half a million dollars. And that's, that's, that's sets an upper boundary to how much you can actually have in an auction. But that's always assuming that there's just one auction going on at any one time, right? So basically, if you use Bitcoin network as sort of an anchor, if you had a lot of outgoing auctions at the same time, this would no longer hold. Is that correct? There's actually a few different ways you can arrange this.

Right now, every auction gets its own proof and has its own confidence level as a result. And the seller sets the amount of work that they want. We don't use like a standardized six-header thing. The seller decides how much security it should have. So in the future, it's conceivable that we could be proving many transactions, many Bitcoin transactions for different auctions in a single Ethereum transaction. And there's a lot of different ways you can do that and a lot of different tradeoffs there.

So I think we haven't sat down and mapped all those out yet, but I'm confident there's something good there. I can somewhat buy this model for something like Bitcoin, right? Have you thought about how this like security model works for, you know, things like minority hash rate chains and whatnot? Well, you know, it really doesn't for a few reasons. Obviously with things like the Verge or the Verk coin 51% attacks, it would be pretty trivial to create fake proofs just by renting hash rate. So, you know, in that sense, it's pretty broken for small chains. The other thing is that Bitcoin is actually the only chain that we can do this for in solidity.

We're going through each header in this proof and we're verifying the work that was done on it. Bitcoin uses Shaw 256, which the EVM conveniently has a pre-compiled contract for. So it's actually really cheap to do Shaw-256 in the EVM. But if you look at Lightcoin, they use S-Crypt. Zcash uses Equahash. D-Cred uses Blake 256. None of those can be done in the EVM efficiently. So for all of these minority hash rate chains, I think it's not even an issue because we just can't do it anyway.

Bitcoin's really the only chain that this can work with right now. I guess if we really wanted to, we could write zero knowledge proofs of SPV proof for all of these other chains. So I can make a zero knowledge proof that I know a Zcash SPV proof that you got paid. but that would be really painful for everybody involved, I think. I see. This all seems like a lot of very complicated, like, smart contracts. You're writing stuff on the Ethereum side of things or writing stuff on the Bitcoin side of things. Rachel has been, you know, always complained to me about like, you know, how complicated a lot of this stuff is.

And so, you know, I know that you guys have this other project called Riemann, which is sort of a, you know, I guess the goal here, was to make all this like, you know, in the Ethereum world, you know, there's a lot of tooling around like solidity and whatnot that makes it like, you know, not a pleasure, but like at least usable to like write like complex smart contracts. And so is this sort of what like RIMAN is or, you know, can you actually just give us a brief rundown of what this RIMAN project you guys have is? Sure. So this is something that we started back in March and it's basically a transaction construction library for Bitcoin and other similar chains. Right now it supports 20 odd chains including Bitcoin, Bitcoin Cash. I need to update it for

the new Bitcoin Cash children, but it supports Zcash, Decred, Vertcoin, Mona coin, aurora coin, broscel coin, and like 15 other coins that I don't know. So the goal here is to make it extremely easy to build transactions. We've talked so far about time locks and a little bit about the Cigash stuff. And I have like long 10 page blog posts about how these things work. But the goal of Remon basically is if you know what you want your Bitcoin transaction to be, you should be able to make it and get it on-chain within 10 minutes. It's a toolbox for building Bitcoin transactions.

If you want to, you know, as the seller, make this partial transaction and sign it, and then the bidder needs to come in, parse that, look at it, validate it, and then add their own stuff to it, No wallet is going to do that for you right now. Electrum won't do that. Jacks certainly won't. And most wallet devs won't even know what you're talking about or what any of this stuff does. So we went and wrote a whole library for just building Bitcoin transactions simply and quickly. And we use it for everything we make now just because it's the, you know, we built the, you know,

we built the tool we wanted to use. I'm quite familiar with a project called Ivy, which is something one of my friends, Dan Robinson, wrote while he was working at Chain. And so what he was doing there was he created like a higher level language that, you know, a declarative smart programming language that compiles to Bitcoin script. So it basically makes it very easy to write like, you know, interesting financial. contracts and have them compile to Bitcoin script. Is that, you know, similar to what Ryman is doing, or is it something a little bit different? Am I like, are these complementary things or are they,

like, how do these two pieces fit together? These are definitely complementary things. I've looked at and used IV a little bit, and it's very good. So the script is really just a pretty small part of the transaction. In legacy transactions, it goes in as part of the input. each input has what's called a script sig. And for Segwit transactions, it's in the witness. So what the script does is it validates that you're allowed to spend those coins. It's kind of a smart signature scheme. So in Ethereum, you just use ECDSA digital signatures and, you know, one key, one account.

In Bitcoin, we can set up smart signatures. with additional spending conditions on them. So you can say this signature is valid only after next week. Or in addition to having a signature, you must also know the pre-image of a hash. So Ivy is intended to make it so that you can write more complex scripts more easily. Riemann is intended to make it so that once you have

the script you want, you can just shove it into a transaction and put it on chain immediately. it's really like two parts of the development set here i see so you know would it be like fair to almost like categorize it given that you know people are probably more familiar with the ethereum development environment would it be fair to call ivy sort of like solidity and uh reman sort of like the web three library i think that's a pretty fair analog um generally speaking uh everything in bitcoin is going to be a bit smaller and tighter than stuff in Ethereum.

So Riemann has a lot fewer features, just because Bitcoin has fewer features. But I think that's a pretty fair analogy, is Ivy is a language that compiles down to the EVM bytecode, or I guess Ivy doesn't compile the EVM bytecode yet. Ivy compiles down to Bitcoin script, and then Riemann helps you get that script on chain. I see.

And so, you know, I guess kind of going on from there is, you know, kind of when we started this episode, we talked a little bit about how you were very interested in these like Bitcoin script style stuff. And, you know, I follow you in Twitter and, you know, we chat a lot on like, you know, different telegram groups. You know, you often take a lot of issue with like how the EVM model works for smart contracting. And you really like the more stateless and like, like, you. You know, like, you. You, you often take a lot of issue with like how the EVM model works for smart contracting. And you really like, you really like, you know, you. You really like, you. You know, you often like, you UTXO modeled of like Bitcoin style of systems. So, you know, could you tell us a little bit of your pitch of like why you really are heavily favor this style of smart contracting? Definitely. But before we get into this, I wouldn't describe myself as a partisan here. I tend to lean more towards Bitcoin style, but we've spent this whole time talking about my system for connecting Bitcoin and Ethereum and improving both of them. So So Bitcoin's design is around security in a lot of ways. With the UTXO model and with Bitcoin's transaction model and script, we actually specify

the exact change that we want to make. And we provide a signature and other forms of cryptographic proof that we're allowed to make that change. In Bitcoin, you know, we say, I'm spending these exact coins, these UTXXs. and I'm creating these UTXOs. And this transaction is valid after this date, and here is my signature. And so what we do is we commit to an exact state change that we want,

and we know that we will get exactly that or nothing. Whereas in Ethereum, when we call a smart contract, we really have no guarantees about what it'll do. I think that Ethereum developers have run into this repeatedly over the last few years. I was around for the Dow. I was around for the parody wallet double feature a few years back too. There have been a lot more big and small issues because when you sign an Ethereum transaction, you cannot tell what it's going to do with your money.

You can have some pretty good guesses, but you can't be sure in most cases. And this opens up doors where people like miners and other users can interfere with your transactions for profit, right? If you're buying something in an on-chain exchange like EtherDelta, the miners can get in ahead of you and interfere with your order. Or another user can pay more gats and get into the block ahead of you and interfere with your order. And so because you don't know what your order is going to do, you're going to end up losing money that way. Whereas in Bitcoin, once I have signed this transaction, it's all or nothing. Like it happens exactly as I want or it doesn't happen at all. And I think that's a much stronger security property.

And it's really something that I rather prefer in my money. You know, I like my money to be fairly predictable. And so this kind of goes back to that thing you were talking about earlier, about like, you know, it's not that transactions in Bitcoin can't ever conflict, right? It's like, you know, for example, I could have, you know, let's say there's a one of two multi-sig between me and my buddy. And we both send a transaction trying to spend from the same multi-sig, and we didn't realize the other person also sent that transaction.

So we have a conflicting transaction, but the difference is that only one of them will ever make it onto the chain, while in Ethereum, both transactions will go onto the chain, and it's up to like the smart contract to decide which one is valid and, you know, one of us will lose some gas, even though we ended up doing nothing. In Bitcoin, conflicts are resolved at the Mempool level. So they're resolved before consensus happens. In Ethereum, they're resolved after consensus happens. Every conflict in Ethereum, except for account nonses,

happens in a smart contract somewhere. And so it's all happening on chain and it's being executed on chain. And as a result, everybody involved pays gas. And that's the best case for what happens in a conflict is everybody pays gas. So in my opinion as well, This is a Bitcoin Mempool level conflict resolution is a better property for programmable money.

I completely understand. So basically what you're getting is that in an Ethereum transaction, you never know which state the transaction you sent out is actually acting on, right? Right, right. So do you think there's a way to ameliorate that without switching to a UTXO model? So I think that people have done a lot of research into smart contract patterns and best practices that minimize this. So in solidity development, we usually teach people something called CEI, checks, effects, interactions, which is that we make a bunch of require statements and then we change local state and then we call another contract. And that minimizes the problem here because any failed conditions that cause a conflict and error out get caught immediately.

There's been some loose discussion of other consensus layer resolutions to this. So one of the ideas I've toyed with is having transactions commit to the state that they want to act on. unfortunately, this really interferes with a lot of the nice features of Ethereum. The great thing about solidity contracts is that a bunch of users can interact very quickly and that they can all interact with the same state. That causes a lot of problems, but it also lets us have nice things like Auger and nice, like all of these smart contracts that we use, if each transaction commits, to its starting state and is invalid if that state changes,

what you get is basically a one right per block per contract kind of thing, where once somebody has gone to Ether Delta, well, now Ether Delta's state has changed, and everybody else who is going to interact with it in that block can't anymore. All of their transactions go away now. And so I think it's really difficult to fix this issue without severely impacting Ethereum smart contracts utility.

Essentially, there's like some tradeoff going on here between like the security of, you know, how users interact with the system and, you know, the actual usable, like the functionality of the contracts. Yeah. And I totally agree. There's a tradeoff there.

You either get this guarantee that you know exactly what will happen, or you get to interact with other users in useful ways. So generally speaking, for my money, I prefer to know exactly what's going to happen, but at the same time, it is obviously useful to interact with users in smart contracts on Ethereum.

So I don't see like one model winning out here. I think we're going to find a lot of different use cases for both models. We're not going to end up with one dominant chain. We're going to explore the tradeoff space a little bit. Yeah. And so you actually, you know, I saw another one of your blog posts where you talk about how you can write, you know, declarative smart contracts in solidity using, you know, a series of require statements. And so this is sort of like, you know, your proposal of how do you do more increase the security model? It makes it, it kind of makes it act a little bit more like the UTXO system.

So is this like something you use in your smart contracts right now? So it's not currently. It's a little gas inefficient. So to add a little more context here, we talked about checks effects interactions earlier. You can think of declarative smart contracts as checks, checks, and also more checks. The core idea is that instead of having effects,

we just make the user provide an end state, and we check if that end state is valid given our current state. So maybe if I want to have a multi-sig wallet, I make the user tell me what transaction they want to send to the network, and I have the wallet check if it's valid, and check if there are enough signatures on it. The goal here is that instead of having the smart contract programmatically decide what happens based on the current state, you have the user decide what happens and have the smart contract check the user's work. And so this is a bit of a middle ground between the hardcore Bitcoin all or nothing and the current state of Ethereum where it's a free for all.

all where anything goes. The user can submit this transaction and know that the smart contract will invalidate it if they don't get exactly what they want out of it. So just to maybe help some of the listeners visualize this paradigm that you suggested here, it would be like in an ERC20, instead of me saying a transaction saying send five, you know, Weth from Sunny to James, it would instead be, let's say the current state is I have 10, we have 0, I send

it a transaction saying, update state to 5 and 5. And the system will say, well, you know, what's required to make this happen? It's that that would be the result of deducting the same amount from yours and adding the same amount to yours. Is this valid? If so, that's executed.

So that's kind of like, you know, you're declaring the end state rather than saying the imperative version, which is send something. Yeah, and in the contract, you're declaring what's allowed. So specifically for that token, you know, you're going to send in a new state, and your new state is Sunny has five and James has five.

And the contract's going to check that the sum of our balances has not changed. So James plus Sunny is still 10. So we didn't create or destroy any tokens here. It's going to check that, you know, you haven't approved someone else to move those tokens around. and it's going to check your signature, and that's all it needs to know. We didn't create or destroy tokens. You were authorized to move them, so just write down what you said to do. Whereas an ERC20 contract normally is going to actually go in and adjust your balance minus 10,

and adjust my balance plus 10. This just writes down what you say to write down, assuming it passes all the checks. Thank you. That was a super interesting and certainly very interesting perspective on smart contract design. We are coming almost to an end. We skipped over one very crucial question earlier on, namely what's actually the business model of summer? So we have a few candidates here. Right now, what we're concerned with is not how we monetize so much as how we get users. So as I mentioned earlier, we ran an auction a few weeks back for 10 NFTs.

We ended up selling all of them for Bitcoin. We got a tiny, tiny amount of revenue from it in Bitcoin, which is pretty cool. But since then, we've run one more auction. This time, instead of selling NFTs, we sold Ether. Our Ether auction closed at 4 or 5% below Coinbase's price for Ether. And so the people who bought ether from us got a pretty nice discount. What we're going to do is keep running auctions every two weeks for the next several months, and then step it up to every week, and then multiple times a week.

The goal here is that we get people actually using this stuff. It's one thing to talk about atomic swaps. It's a completely other thing to have a healthy market out there for SB. V-based swats. In order to have a business model, you have to provide some amount of utility to users, right? And so that's what we're focusing on first, is what useful product can we make? Get out there, build users, build out a real marketplace. And then the business model is going to be a natural result of that. Okay, so the business model is there to be determined. Well, it's flexible. And so what's next for Summa?

So you know, you guys have launched this cross-chain auction and you're going to be continuously launching cross-chain auctions. What are some of the, you know, next steps are you going to be rolling out like some of the, you know, option systems or what's next for Summa? For a little while, we're going to be focusing on liquidity. We have this auction market. Right now it's in a very, very early state. We don't have any tools for other people to list auctions. And the smart contracts out there on chain, but even if you figured out how to list an auction,

users wouldn't be able to see it in the app yet. There's a really long technical roadmap for us. And I think, you know, what's next is refining the app, adding the tools so that other people can list auctions. and keep focusing on adoption and usage. We can circle back to more complex derivatives like forwards and options. You know, once someone actually uses the simple stuff.

So I agree that liquidity is everything on a platform like this. So people need to be sure that they can actually get a decent market price. So currently, are you enforcing this in some way? So basically, if no one turns up, do you close the auction yourself? how do you currently handle this? You know, we haven't run into that problem yet. So we let the previous auction close at a discount, right? We think that we will continue doing that for the next few auctions.

After we open it up to other sellers and have good tooling there, we'll let everyone decide what to do for themselves. Very cool. Well, that's our time for this show today. So, you know, I, for all of our listeners, I have really, like, you know, suggest reading a lot of James's blog posts. Like, there are some of, like, the most, like, technical blog posts, but, like, you know, very well written.

And so we'll definitely link that down in the show notes. So we'd like to thank you, James, for joining us today. And it was great to having you on the podcast. I learned a lot about, you know, Bitcoin script and, like, atomic swaps and, you know, part of the world I never really touched. And I've always wanted to learn more. So that was really cool. Thank you.

Yeah, thanks for having me. If we ever have more time, we should probably go over like interblockchain protocol versus stateless SPV versus stateful SPV versus Atomic. Yeah, this has been really fun. Yeah, definitely. Yeah, thank you, James. Thanks so much, yes. Thank you for joining us on this week's episode.

We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released.

If you want to interact with us, the guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being in. back next week.