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 we discussed 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
- Microsoft Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.
Friederike Ernst: Welcome to Epicenter. This is Friederike Ernst. I have with me …
Sunny Aggarwal: Sunny Aggarwal.
Friederike: Today we’re speaking with James Prestwich who is the founder of Summa and is talking with us about Cross-chain auctions and how to improve the smart contract development on Ethereum with ideas that come from the UTXO world.
Sunny: Yeah. I actually met James first time about probably 2016, I think. I’d actually given a talk at blockchain at Berkley on Storj, which is a project he worked on in the past. He actually saw my talk. He reached out to me. He said like, oh wow, this is one of the best, quick explainers of Storj I’ve seen. Then I invited him to come give an even more in depth talk. I brought him at Berkley. He gave this like really cool talk about how Bitcoin scripting and stuff works. At that time, they were going to this process of actually moving Storj from a counter party, which is like built on Bitcoin, and moving it over to Ethereum. He was actually, for very early on, I knew he was super into the whole relationship between smart contract and paradigms and what not.
Friederike: Yes, and he will tell us all about how they recently did a first auction, reverse auction, auctioning off NFTs on Ethereum for Bitcoin on the Bitcoin network. That was super interesting.
Sunny: Yeah. Summa, they’ve been working on like all sorts of different cross-chain contract. Obviously, I, working on Cosmos, I’m very interested in cross-chain stuff as well. But we focus more on the side chains work side of things. Summa is more on the atomic swaps, like trading Bitcoin for Ether, like atomically or let’s say I’m selling something. This whole new cross-chain auction stuff that they’re working on where it’s like, I can sell a crypto curry or ether or some ERC 20 on Ethereum for Bitcoin. Because they’ve been using like a Dutch auction system which Friederike, you’re obviously very familiar with. That was very cool. We got a chance a little bit to talk a little bit about the differences between what are the benefits of cross-chain that’s auction, versus like a fully on Ethereum auction, which is cool. Then just for full disclosure for all the listeners, actually my roommate or flatmate rather, is actually Rachel, who is one of the lead engineers at Summa. I’m quite familiar with Summa. I do have a little bit of indirect personal relationship with that. Just as a forewarning.
Sunny: Welcome to Epicenter. Today we’re here with James Prestwich who is the founder and CEO of Summa. According to their website, a fairly young start up offer in cross-chain financial services. Welcome to the show James? Could you 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?
James Prestwich: As you said, my name is James Prestwich, founder of Summa. Previously I worked with Chia on BLS implementation a little bit as well as on Chia’s script. Before that I was the co-founder and COO at Storj, a decentralized cloud storage system for about three years. I got involved in the blockchain space back in 2013 and has been working here full time since 2014. I guess what really got me interested in it at first was the consensus aspect is that we can use proof of work and we can use blockchains to bring thousands of notes to consensus on something. I think we’ve spent the last four, five years trying to figure out what that things should be, and it’s still kind of an open question. But it’s fun.
Friederike: What got you interested in decentralized cloud storage?
James: It’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. 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. Trying to solve that problem is what got me interested in the first place. I got involved in storage because I was living in rural Japan and had way too much free time to think about things like this. Yeah, I guess I kind of stumbled into it mostly.
Sunny: Speaking of rural Japan, I actually saw on your LinkedIn that your bachelor’s was in Japanese and then you just jumped right in to building decentralized storage market places. How did that leap come in? What was the relation there?
James: 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 the language as an elective, and ended up spending four years on it and then moving to Japan. I think what they have in common is that you have to be constantly learning, and all of the problems are hard and interesting. Learning the language is difficult. Learning blockchain is very similar. You have to go into all of these intricacies and these special, rules that only apply in certain situations. It’s half memorization, half investigation, and the third half is just like spending the time.
Friederike: Yeah, for sure. You spent three years at Storj and then left. What happened? What made you leave?
James: I think a few of us were looking to leave for a while. We went through the whole token sale process. We set the company up for success in the future. They’re doing great. Then we decided it was about time to move on.
Sunny: From there you moved on to, you mentioned you were working with Chia a little bit. Especially working with them on, I know Chia was really, they are focused on how to improve Bitcoin script and updating it. You were helping a bit on that. How did you get involved with that, I guess?
James: Yeah, I ran into Bram Cohen at, let’s see, it must have been scaling Bitcoin at Stanford end of 2017. We got talking about the advantage and disadvantages o Bitcoin Script and the Bitcoin consensus mechanism design. We 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 ELS signature implementation and on designing Chia Script. Of course it’s been almost a whole year since I left. They’re still doing going 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 the scripting language. I’m very excited about it.
Friederike: 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? What made you three set out and start Summa? What your vision is?
James: Yeah. Barbara and Matthew and I all work together at Storj. We already knew each other. We had a lot of experience working together in high pressure situations. Around the beginning of the year, it just all made sense. We had all taken some time off and worked contracting on other things. Around January, February, we got together and started looking to raise money to work on cross-chain financial contracts. That’s how Summa started.
Friederike: What got you interested in cross-chain financial contracts in the first place?
James: Yeah. Towards the end of last year, I had a lot of spare time to spend on learning about the intricacies of Bitcoin, learning how blockchains work in practice. All of the implementation details and the left over bugs from Satoshi. One of the things that I spent a lot of time on was atomic swaps. Back then, I wrote a little blog post about how frustrating they are and how bad the user experience of atomic swaps is. I thought it would be just a little one and done blog post complaining about stuff. It kind of got me thinking about it a lot more, if you actually want to use these things, how can you improve them? How can you take them from something that’s six hour synchronous protocol with the free option problem, which will put each rolling issues, and turning it into something that people would actually, usefully use. After that, it was, I think I woke up one morning with a few ideas, like two weeks later, and started just writing it down. Very few people have worked on this and practice. Almost no research has been done into how you extend the protocol or modify it. At this point, we have four, five good variations on the atomic swap, which I’ve talked about some in public, but mostly just have notes on. We’re building out software, seeing what works, seeing what people want to use, and trying to put product out there people would use.
Sunny: I see. 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 month, maybe even a year ago, you actually had a post talking about why people should be less excited about atomic swaps. What changed?
James: I spent a bit of time on it. Part of it was thinking on a few ways to improve the atomic swap construction. Part of it was realizing that people were just trying to use it to do the wrong thing. It’s really poorly suited to exchange it. It’s actually pretty well suited to options. I mentioned the free option problem earlier in an atomic sway. One of the participants has a choice to complete the trade or to cancel it. They have that choice for several hours. They decide what happens. In that sense they have an option the upper point, right? 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. It’s not really that’s something’s changed. It’s that my perspective on it went a little bit.
Sunny: Essentially, you know, what you saw, what you originally saw as the bug in this atomic sway, what you saw was like getting free options. You decided to sound like, let’s turn that into the feature. Let’s make the cross-chain auction itself the product that we are selling.
Sunny: Cool. Maybe you could explain to us a little bit about how that atomic swap works and why this whole option situation exists?
James: Yeah. The atomic swap is a two player game basically. We want to exchange my Bitcoin for your Ether. We want to do it at a rate that we decide between us, say maybe 20 Ether for 1 Bitcoin. I don’t follow price much, so I may be way off. But we want to agree on this rate, and we want to do this trade with no third parties involved all on chain. We can make it completely trust less. What we’re gonna do is I’m going to make a secret and tell you the hash of that secret. I’m going to make a Bitcoin contract that’s payable to you if you learn that secret. Otherwise, it will refund the coins to me after a certain amount of time passes. I’m gonna 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.
Sunny: Now when you say same contract, but it’s like a similar design contract on a different chain, right?
James: Yeah, it’s the same terms, but on a different chain. You’re paying into an Ether smart contract here. The smart contract enforces basically the same terms. But obviously it doesn’t end solidity on chain and Ether which is completely different from Bitcoin script. 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. 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. The free option comes in if I decide not to reveal the secret. Because we do this on chain, it takes confirmation time. Any time we want to change the state of this contract, we have to wait a whole block confirmation cycle, an hour give or take. I have at least one hour where I get to choose whether or not to reveal the secret. That means I choose whether the trade happens or whether we both get a refund. If the Ether rate moves against me, if Ether drops 50% in that hour, I can choose just not to complete the trade. You get stuck with the Ether, and I keep my Bitcoin. In this sense it works like an option contract. I have the choice, and you are just along for the ride.
Sunny: Essentially what’s happening here is like normally what I do in options contract with you, I have to pay some sort of premium on that right?
James: Whoever has the choice pays the premium.
Sunny: Right. Here I’m getting it for free.
James: Yeah. In the real world, that would be paying you money and here I’m getting it for free. That’s not really a sustainable situation. One of the other major concerns in, 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. You are supposed to send Ether into this atomic swap contract. But you could just walk away. This is the liquidity drawing 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. You lose nothing and it cost me, well, a lot of annoyance and probably some money. There are a few ways to fix these things. The liquidity drawing is pretty complex to get into. But the free option problem, you can add a premium payment. We can embrace the fact that this is an auction.
Sunny: I know I saw one of your talks at a conference a few months ago NSF, I think. It was my favorite talk, because it was like right in the middle of a bunch of ICO pitches and stuff. You had this like 15 minute time slot. You went in, explained about architectural concepts and just got off the stage. It was the most efficient technical talk I’ve ever seen. But yeah, in that you actually talk about, the talk was actually, you title it Better Atomic Swaps. There you talked about mechanisms where you can play with the time outs and include some additional constraints that actually make this atomic swap process better. Can you explain a little bit about, a short gist of that talk that you gave?
James: Just gets pretty technical pretty quickly. But what I was talking about that day was a quick solution to the free option problem. Unfortunately, it can’t be used with every chain. This is basically like doing an atomic sway inside out. It’s 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. This kind of gets rid of the liquidity trolling issue. Because I have this period where if you don’t fund, I can just back out and get my money immediately. It gets rid of the free option problem because once an hour gets past, there’s no more optionality. It just happens. The downside here is that it can only be used with certain chains. At least one of them has to support specific transaction feature. That’s the things you can basically only do with Ethereum or other smart contract chains right now. You might be able to do this, improve atomic swap between Ethereum and Bitcoin, or Ethereum and Litecoin, but you can’t do it between Bitcoin and Litecoin. This is really interesting to me because I came up with this when I was really investigating the differences between all of the 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 up the liquidity problem.
Sunny: I see. You mentioned also a few minutes ago that there’s different ways you can create, you can parameterize these atomic swaps in order to create different financial instruments or derivatives. We talked about, we talked so far mostly about options. I’ve been told that it’s possible to also create things like futures or other sort of instruments. Can you explain about, you mentioned you had four different designs that you have? Could you explain a little bit about how each of these work, or what they are?
James: Yeah. We worked on a bunch of things that are based on atomic contracts, and we worked on some things that are based on SPV purse, which we can talk about a bit later. Talking about atomic contracts, we’ve covered a lot on auctions, and we’ve covered some mandatory exchange. You enter into a contract and then it must happen. 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 on Ether. For example, we can pay Bitcoin for ENS domains. Or we can pay Bitcoin for cheese. One of the prototypes that we build is paying Bitcoin to issue Nutopians from an ERC-20 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 with Bitcoin.
Friederike: Maybe to make this a little bit more concrete, you did this recently, right? Basically, you actually had this contract that actually sold a number of NFTs on Ethereum for Bitcoin. How does it work exactly? What actually happens to the Bitcoins that I pay?
James: We’ve actually done this two completely different ways now. We’ve done minting using the atomic construction. We’ve talked a lot about options. When we’re talking about minting something fresh, we usually call it a warn, it’s the same as an option, just on fresh mint and tokens, instead of some Ether that already exists. The other thing that we did very recently was a cross-chain auction on some NFTs. This doesn’t use the atomic swap construction. This uses something new that we came up with called stateless SPV. I’m not sure where to start explaining this. Atomic swaps have to be pre-negotiated. Me and Sunny have to agree on this exchange, or this contract that we’re entering into. Then we have to agree on that 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 lets someone come in and pay me. This is gonna get real technical real fast. But the basic way it works is, I want to sell 20 Ether. I have an asking price of 1 Bitcoin. Anybody can come in and pay me a Bitcoin and submit a proof that they did so. This proof comes in the form of a Bitcoin transaction that pays me, a proof of inclusion and a Bitcoin block header for that transaction. Then a bunch of headers that come after that that have a lot of work done on them. Anybody can come in and show this proof to the smart contract. The smart contract will validate it, which validates that Bitcoin was paid to me. If the transaction and the proof and the header chain all check out, the smart contract will distribute the Ether or the tokens, or whatever.
Friederike: How do you make sure that this only happens once? 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 we need a number of, we need to wait out the number of flux 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?
James: 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. 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 spend didn’t? Obviously they can’t be 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. As a result, Bitcoin is really, really good at preventing double spends. It’s literally, the only thing it was designed to do. What we do is we make it so that everybody trying to pay me is also trying to double spend Bitcoin. When I list my Ether for sale, I will attach to it a tiny, tiny little bit of Bitcoin. Right now we use 550 Satoshis which is something like .3 cents, something like that. 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. The smart contract checks that those specific coins were spent in the transaction that’s included and approved, that’s included in the block, that’s included in the chain. Anybody can come in make a bid. They’ll all use those coins to do it. Bitcoin will ensure that only one of those bids going on chain.
Sunny: Yes, I understand now that Bitcoin, you get so model, make sure it’s only one person can spend a certain amount of one UTXO. Two transactions from the same UTXO, they won’t both make it on to the chain. But given that, now how do you apply that to making bids in an auction? Not everyone’s bidding with the same Bitcoin. Everyone has their own Bitcoin that they’re trying to bid with.
James: In Bitcoin we have inputs and we have outputs. Unlike Ethereum where you have an account with a balance, in Bitcoin you just have a bunch of coins with serial numbers on them. You spend specific coins as your inputs, and you get new, specific coins with new serial numbers as your outputs, right? 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 that 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. Then they take the seller’s preferred output that one Bitcoin on one we paid, and they add their own other output to it. Each bidder submits a Bitcoin transaction with the seller’s input and output, and their own inputs and outputs. In order for them to do this, they look at the Ethereum contract. They see the seller’s input and output there. They extend that transaction. They add more inputs and they add more outputs, and they sign it and they broadcast it to the network. 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 you own inputs, add your own outputs. What we’ve been doing recently is Dutch auctions. That’s a falling price auction, right? We do this stepwise. It’s not a continuous price unfortunately. Though I think we can do that later. The way we do this is using another Bitcoin protocol feature, which is time blocks. 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. 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. I’ll sign that with no time lock, and then I’ll make another one that’s 500 Satoshi in, and .9 Bitcoin out. I’ll add a time lock for five blocks down the road. That won’t be valid. Nobody can pay me that way for five blocks. I’ll make a third one with 500 in and .8 out. I’ll say that that’s valid in ten blocks. I can make as many of these as I want. I can setup a falling price auction by saying, one Bitcoin now, or .9 in five blocks, or .8 in ten blocks. When you want to bid, you see, okay, what’s the latest valid transaction, or the lowest priced valid transaction? I will, if that’s an acceptable price, add my inputs, add your own outputs, and broadcast the network.
Friederike: I pay a price that depends on time. For that, I actually get something on the Ethereum network, is that correct?
Friederike: Basically it’s always the same thing that I get on the Ethereum network, is that correct?
James: Yeah. We’re selling say 20 Ether for one Bitcoin. But after five blocks, the price will fall to .9. You still get the 20 Ether, but you pay .9. After five more blocks, it will fall to .8. That point you’re paying .8 Bitcoin for 20 Ether. So the price will fall this way until someone out there in the worlds wants to buy those Ether for Bitcoin. Until it reaches some market price, right?
Friederike: How does it look from the other side? How does the Ethereum smart contract now know that it can release the Ether?
James: 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. Somebody needs to tell it about this transaction and about the 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 gonna build it into the client pretty soon, so that it will just happen automatically. I will construct a proof. I will submit it to the smart contract. The smart contract will check it. What it does to check is that it sees that it’s a validly formatted Bitcoin transaction. It checks that they’re 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 tree, by validating a miracle proof of inclusion. Bitcoin typically has 2500 transactions in a block. That means 12 to 13 hashes in the miracle proof. It validates that the transactions included in a block. Then it starts checking work. The nice thing about proof of work is that you can check it. We take this block header, and we check the hash of that block header and we compare it to the difficulty target. 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. We hash it and compare it to the work target. We repeat that four, five more times. 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.
Friederike: Exactly, in the main chain. Because otherwise you could just use an anchor chain and try to build blocks on that. That would be counteracted by the fact of the workers, is that correct?
James: Yeah. Work is expensive. When we’re making six Bitcoin block headers, it takes quite a bit of electricity, a small margin of A6, and quite a bit of time. The Bitcoin main chain makes block headers about every ten minutes. If I have 10% of the Bitcoin hash rate, and I want to make some fake headers, I can only make one every hundred minutes. If I spend 10% of the Bitcoin hash rate, I’ll get 10% of new Bitcoins on the main chain. But if I spend it on fake headers, I won’t get any Bitcoins. We never actually check that this SPV proof is really included in the main chain. What we check is that some of these spend an awful lot of money building it.
Sunny: What is the benefit of doing this, like stateless model over, for example, using BTC relay, which tries its best to follow the Bitcoin, like have the entire history of the Bitcoin header chain?
James: I think there’s a few different advantages. One is that I can write stateless SPV proofs in about two days, while writing weird logic and solidity takes weeks or months. One is that BTC relay relies on relayers. Historically, relayers have failed to appear. The last time I looked, BTC relay hadn’t been operational in six months. Although 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. Where stateless SPV proofs are basically predicates. They can just be evaluated immediately and then discarded. Storage is probably the most expensive things you can possibly do in solidity, besides your knowledge proofs. 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 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.
Sunny: Doesn’t this like set some sort of limit on how valuable of an auction you can do? Because let’s say the cost of me creating six blocks on Bitcoin is like a million dollars. That means I can’t auction that one crypto curry that went for like 1.8 million or whatever.
James: You parameterize a little bit, it’s about $500,000 right now to create six block header chain. Fortunately, that’s not the only defense we have. 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 ten hours to make a six block header chain. If it’s 25% of the Bitcoin hash rate, it’s still gonna take you four hours, right? Unless you have, almost enough hash rate to 51% Bitcoin, it’s gonna take you a very long time to make a fake proof. Any honest buyer will beat you to the punch. Because they will have the main Bitcoin chain making headers for them every ten minutes. It’s not just a dollar value here. It’s also a level of confidence that a dishonest party cannot make any proof in a reasonable amount of time.
Sunny: 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 secure fall back is that there will be a time out. Let’s say you’re trying to defend against up to someone with ten percent of the hash rate, for them to create a six block chain, it will take them 600 minutes. You can say, okay, this auction times out in 300 minutes. That basically means you’re kind of secure against someone with up to at least 10% of the hash rate?
James: 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 deadliness 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. You can end up in a situation, if you’re not careful, where an honest fire paid Bitcoin. But the auction timed out before he was able to submit a proof. There’s a lot of timing related cases there. which is why we haven’t implemented time outs in this version. Right now, the safest thing to do here is to have the seller cancelled. This is something that can be done very trustlessly. If the seller spends their own UTXO, then nobody else can spend it. They’ve effectively cancelled the auction and can reclaim their Ether.
Friederike: I have a follow on question here. Basically, you said that creating a six block chain on Bitcoin right now is half a million dollars. That 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 at any one time, right? So basically, if you had, if you used Bitcoin network as an anchor, if you had a lot of outgoing auctions at the same time, this would no longer hold, is that correct?
James: 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. 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. In the future, it’s conceivable, but we can be proving many transaction, many Bitcoin transactions for different auctions in a single Ethereum transaction. There’s a lot of different ways you can do that, and a lot of different trade-offs there. I think we haven’t sat down and mapped all those out yet. But I’m competent there’s something good there.
Sunny: I can somewhat buy this model for something like Bitcoin, right? Have you thought about how this security model works for things like minority, hash rate chains and what not?
James: Well, it really doesn’t for a few reasons. Obviously with things like the verve of the Bitcoin, 51% attacks. It would be pretty trivial to create eight proofs just by renting hash rate. In that sense, it’s pretty broken for small chains. The other things 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 Chai 256, which the EVM conveniently has a precompiled contract for. It’s actually really cheap to do a shot of D6 and the EVM. But if you look at Litecoin, they use S-crypt, Zcash uses Equihash, Decred uses Blake-256. None of those can be done in the EVM efficiently. For all of these like minority hash rate chains, I think it’s not even an issue because we just can’t do it anyway. Bitcoin is really the only chain that this can work with right now. 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 as Zcash SPV proof, than you got paid. But that would be really painful for everybody involved, I think.
Sunny: I see. It all seems like a lot of very complicated smart contracts. You’re writing stuff on like the Ethereum side of things. You’re writing stuff on the Bitcoin side of things. Rachel has been always complaining to me about how complicated a lot of this stuff is. I know that you guys have this other project called Riemann. I guess the goal here was to make all this, in the Ethereum world, there’s a lot of tooling around solidity and what not, that makes it, not a pleasure but at least useable to write the complex smart contracts. Is this what Riemann is? Can you actually just give a brief rundown of what this Riemann project you guys have is?
James: Sure. This is something that we started back in March. It’s basically a transaction construction library for Bitcoin and other similar chains. Right now it supports 20 chains including Bitcoin, Bitcoin cash. I need to update it for the new Bitcoin cash children. But it supports Zcash, Decred, Vertcoin, Monacoin, Evercoin, Groestlcoin, and like 15 other coins that I don’t know. 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 Zcash stuff. I have long ten page blog posts about how these things work. But the goal of Riemann 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 ten minutes. It’s a tool box for building Bitcoin transactions. If you want to, you know, as the seller make this partial transaction and sign it. Then the bitter new to come in and parts that look at it, validate it and then add their own stuff to it, no wallet is gonna do that for you right now. Electrum won’t do that, Jack certainly won’t. Most wallet won’t even know what you’re talking about, or what any of these stuff does. We went and built a whole library for just building Bitcoin transactions simply and quickly. We use it for everything we make now, just because it’s the, we built the tool we wanted to use.
Sunny: I’m quite familiar with a project called IV, which is something one of my friends Dan Robinson wrote while he was working at Chain. What he was doing there is he created a higher level language that declarative smart programming language that compiles to Bitcoin script. It basically makes it very easy to write interesting financial contracts and have them compile the Bitcoin script. Is that similar to what Riemann is doing? Is it something a little bit different? Are these complimentary things? How do these two pieces fit together?
James: These are definitely complimentary things. I’ve looked at and used IV a little bit. It’s very good. 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. For language transaction it’s in the witness. What the script does is it validates that you’re allowed to spend those coins. It’s kind of a smart signature scheme. In Ethereum, you just use ECDSA digital signatures. One key, one account. In Bitcoin, we can set up smart signatures with additional spending conditions on them. You can say, this signature is valid only after next week. In addition to having a signature, you must also know the pre image of a hash. IV 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 here.
Sunny: Would it be fair to almost categorize it, given that people are probably more familiar with Ethereum development environment, would it fair to call IV sort of like Solidity, and Riemann sort of the Web-3 library?
James: I think that’s a pretty fair analogue. Generally speaking, everything in Bitcoin is going to be a bit smaller and tighter than stuff in Ethereum. Riemann has a lot fewer features, just because Bitcoin has features. But I think that’s a pretty fair analogy, is idea is a language that complies down to the EBM white code, or I guess IV doesn’t compile the EBM white code yet. IV compiles down the Bitcoin script. Then dream on helps you get that script on chain.
Sunny: I see. I guess going on from there, kind of where we started this episode. We talked a little bit about how you were very interested in this Bitcoin script style stuff. I follow you on Twitter. We track a lot on different telegram groups. You often take a lot of issue with how the EVM model works for smart contracting. You really like the more stateless and UTXO model of Bitcoin style systems. Could you tell us a little bit of your pitch of why you really heavily favored this style of smart contracting?
James: Definitely. 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 spend this whole time talking about my system for connecting Bitcoin, Ethereum and improving both of them. 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. We provide a signature and other forms of cryptographic proof that we’re allowed to make that change. In Bitcoin, we say, I’m spending these exact coins, these UTXOs and I’m creating these UTXOs. This transaction is valid after this date, and here is my signature. What we do is we commit to an exact state change that we want. 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 will do. I think that Ethereum developers have run into this repeatedly over the last few years. I was around for the Dao, I was around for the parity wallet that we features 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. This opens up doors where people like minors and other users can interfere with your transactions for profit. If you’re buying something in an on chain exchange, like Ether built, the miners can get in ahead of you and interfere with your order. Another user can pay more gas and get into the block ahead of you and interfere with your order. Because you don’t know what your order is gonna do, you’re gonna end up losing money that way. Whereas in Bitcoin, once I have signed this transaction, it’s all or nothing. It happens exactly as I want, or it doesn’t happen at all. I think that’s a much stronger security property. It’s really something that I rather prefer in my money. I like my money to be very predictable.
Sunny: This kind of goes back to that thing you were talking about earlier about, it’s not that transaction and Bitcoin can’t ever conflict, right? It’s, for example, I could have, let’s say there’s one of two multi sale between me and my buddy. We both had a transaction trying to spend from the same multi sale. We didn’t realize the other person also sent that transaction. We have a transaction, but the difference is that only one of them will ever make it on to the chain. While in Ethereum, both transactions will go on to the chain and up to the smart contract to decide which one is valid. One of us will lose some gas even though we ended up doing nothing.
James: In Bitcoin, conflicts are resolved at the main pool level. They’re resolved before consensus happens. In Ethereum, they’re resolved after consensus happens. Every conflict in Ethereum, except for account nonsense, happens in a smart contract somewhere. It’s all happening on chain. It’s being executed on chain. As a result, everybody involved pays gas. That’s the best case for happens in a conflict. It’s everybody pays gas. In my opinion as well, this is a Bitcoin main pool level conflict resolution is a better property for programmable money.
Friederike: I completely understand. Basically what you’re getting is that in an Ethereum transaction, you never know which stage the transaction you sent out is actually acting on, right?
Friederike: Do you think there’s a way to ameliorate that without switching to UTXO model?
James: I think that people have done a lot of research into smart contract patterns and best practices that minimize this. In Solidity development, we usually teach people something called the CEI, checks, effects, interactions. Which is that we make a bunch of required statements, and then we change local state, and then we call another contract. That minimizes the problem here because any failed conditions that cause a conflict and error out get caught immediately. There’s been some lose discussion of other consensus layer resolution to this. 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 issues of Ethereum. The great thing about Solidity contracts is that a bunch of users can interact very quickly. They can all interact with the same stage. That causes a lot of problems, but it also lets us have nice things. All of these smart contracts that we use. If each transaction commits to its starting stage, and is invalid if that state changes, what you get is basically a one right curb block per contract. Where once somebody has gone to Ether delta, well now Ether delta’s state has changed. Everybody else who is going to interact within that block can’t anymore. All of their transactions go away now. I think it’s really difficult to fix this issue without severely impacting Ethereum’s smart contracts utility.
Sunny: Actually there’s some trade-off going on here between like the security of how users interact with the system, and the actual functionality of the contracts.
James: Yeah. I totally agree. There’s a trade-off there. You either get this guarantee that you know exactly what will happen. Or you get to interact with other users in useful ways. 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. I don’t see like one model winning. I don’t hear. I think we’re gonna find a lot of different used cases for built models. We’re not going to end up with one dominant chain. We’re going to explore the trade-off space a little bit.
Sunny: Yeah. I saw another one of your blog post where you talked about how you can write declarative smart contracts in Solidity using a series of required statements. This is your proposal of how do you do more, increase the security model. It kind of makes it act a little bit more like the UTXO system. Is this something you use in your smart contracts right now?
James: It’s not currently. It’s a little gas inefficient. To add a little more context here, we talked about checks affects interactions earlier. You can think of declarative smart contracts and checks, checks and also more checks. The core idea is that instead of having effects, we just make the user provide an end stage. We check if that end state is valid, given our current state. 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. I have the wallet check it it’s valid, and check if there are enough signatures on it. the goal here is that instead of having 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. This is a bit of a middle ground between the hard core Bitcoin all or nothing. The current state of Ethereum where it’s a free for 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.
Sunny: Just to help some of the listeners visualize this paradigm that you suggested here, it would be like in an ERC-20, instead of me saying a transaction saying, send five wETH from Sunny to James, it will instead be the current state is I have ten wETH and you have zero. I send a transaction saying, update state to five and five. The system will say, well, you know, what’s required to make this happen is 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, let’s execute it. That’s kind of like, you’re declaring the end state rather than saying, the imperative version which is, send something.
James: Yeah, and in the contract you’re declaring what’s allowed. Specifically for that token you’re gonna send in a new state. Your new state is Sunny has five, and James has five. The contract is going to check that the sum of our balances has not changed. James plus Sunny is still ten. We didn’t create or destroy any tokens here. It’s gonna check that you haven’t approved someone else to move those tokens around. It’s going to check your signature. That’s all it need to know. We didn’t create or destroy tokens. You were authorized to move them. Just write down what you set to do. Whereas an ERC-20 contract normally is going to actually go in and adjust your balance minus ten, and adjust my balance plus ten. This just writes down what you say to write down, assuming it passes over the chance.
Friederike: Thank you, that was super interesting and certainly very interesting perspective on smart contract design. We’re coming almost to an end. We skipped over one very crucial question earlier on, namely, what’s actually the business model of Summa?
James: 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. As I mentioned earlier, we ran an auction a few weeks back for ten 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, 5 percent below coin basis price for ether. The people who bought Ether from us got a pretty nice discount. What we’re gonna do is keep running auctions every two weeks for the next several months, and then step it up to every week. We’ll pull 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 SPV based swaps. In order to have a business model, you have to provide some amount of utility to users, right? That’s what we’re focusing on first, is what useful product we make. Get out there, build users, build out a real marketplace. Then the business model is going to be a natural result of that.
Friederike: Okay, so the business model is certainly determined.
James: It’s flexible.
Sunny: What’s next for Summa? You guys have launched this cross-chain auction. You’re gonna continuously launch cross-chain auctions. What are some of the next steps? Are you going to be rolling out some of the auction systems? What’s next for Summa?
James: 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 stage. We don’t have any tools for other people who has auctions. The smart contracts out there are on chains. 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 road map for us. I think 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 for words and auctions. Someone actually uses the simple stuff.
Friederike: I agree that liquidity is everything on a platform like this. People need to be showed that they can actually get a decent market price. Currently, are you enforcing this in some way? Basically if no one turns up, do you fill the auction yourself? How do you currently handle this?
James: We haven’t run into that problem yet. We want the previous auction close at a discount. 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.
Sunny: Very cool. Well, that’s our time for the show today. To all of our listeners, I heavily suggest reading a lot of James’ blog post. Some of the like the most technical blog post, but very well written. We’ll definitely link that down in the show notes. We’d like to thank you James for joining us today. It’s great having you on the podcast. I learned a lot about Bitcoin script and atomic swaps. Part of the world I never really touched, and I always wanted to learn more. That was really cool. Thank you.
James: Yeah. Thanks for having me. If we ever have more time, we should probably go over an inter blockchain protocol versus statelessness PV verses state less PV versus atomic. I think it would be fun.
Sunny: Yeah, definitely.
Friederike: Yeah, thank you James.
James: Thanks so much.