 Let's get ready for the second session of Real World Crypto and we're gonna move on to cryptocurrencies. So we have three talks lined up for you in this session and the first one on MemoWimble and Scripless Scripts is going to be delivered by Andrew Polster from Blockstream. So I'm gonna ask Andrew to come on stage. Hello, my name is Andrew Polster. I'm the research director at Blockstream and I'm here to talk about a couple of things I've been thinking about over the last year called MemoWimble and Scripless Scripts, which some of you may have heard of, maybe not. I've given similar talks to this a few times before at more blockchain Bitcoin-oriented conferences. This is the first time that I'm talking to a general crypto audience. I'm gonna try to tailor it to a more general cryptographer kind of listener. First, as the first speaker of the cryptocurrency section, I should talk a bit about what blockchains are. A blockchain here is just a list of blocks, okay? So Merklei's list of blocks each block commits to the previous one. Each block commits to a pile of other data called transactions and there are certain rules about what those transactions are. So the real innovative part of Bitcoin is that they're the global consensus system on what the blockchain is. But for my purposes and for the purpose of the next couple of talks, we're going to just take that for granted. We're gonna say somehow everybody has the same view of the system and we're not gonna worry too much about how they achieve that. Okay? So Bitcoin is very simple. Every transaction contains a pile of inputs, a pile of outputs. The inputs are references to old outputs and essentially the only rule beyond that the transactions are valid is that each input can only be used in one transaction. You can't double spend. Okay? So if you are somebody joining the Bitcoin system, the design goal is for it to be trustless, publicly verifiable. Anybody can download the blockchain, this series of blocks and all the transactions. They validate all of the transactions. They check that each one is legitimate. It has valid signatures and so forth and also that there is nothing that conflicts. And what they're left with is a set of unspent transaction outputs called the UTXO set. And basically every single cryptocurrency that you hear about uses some form of this model. In Bitcoin, the system state is described by the set of unspent transaction outputs. Those are the coins that can be spent in future transactions. Zcash or Monero uses a different model where they track spent outputs because the unspent ones are not publicly visible. Ethereum has a much, much more complicated state, but essentially the idea is the same. You download all the transactions, you verify them all in a row and you're left with a state which you know came from a legitimate history. So Mimble Wimble, which was proposed a year and a half ago by this character, Tom Elvis, is a slightly different design where people can verify the state of the system without downloading all of the background data. Somehow it's possible to compress out all transactions, so a lot of the data is redundant and you don't need it to get full public verifiability. And one quick note before I move on, I said this character, Tom Elvis, were in Switzerland, maybe there are a lot of French people or French speakers who might recognize this name. It is the name of Voldemort in the Harry Potter books in the French translation. This is not a real name, as far as I'm aware. So this Mimble Wimble system was originally proposed in the form of a text document published on a tour hidden service and dead dropped on an IRC channel a year and a half ago, and that's where all of this came from. The author just dropped it, signed off a minute later, and has never come back as far as any of us are aware. So I want to talk about two things, Mimble Wimble and Scriptless Scripts. The first is Mimble Wimble, which is how do we get this kind of compression. And the second thing is Scriptless Scripts, which are given this compression, which comes as we'll see by restricting the transaction structure to be very simple and very highly structured. How can we still do anything interesting? So the cool part of Bitcoin is not only that you can send coins around, but also that you can attach various conditions to their spending. You can look for hash pre-mages, you can do multi-signatures, you can do all sorts of fun stuff like this that let you do smart contracts, I guess, is a buzzword about that. So let's get started with Mimble Wimble. So before I explained Mimble Wimble, let me explain confidential transactions. So confidential transactions is a scheme devised primarily by Gregory Maxwell at Blockstream a couple years ago, where you have a Bitcoin-like system, but all of the amounts are hidden. They're replaced by these homomorphic commitments, in particular these Peterson commitments, whose structure I've displayed here. And the nice thing about these commitments, being homomorphic, is that people who download these transactions can verify what they need to verify about the amounts just using the homomorphic property. In particular, they care that the sum of the inputs equals the sum of the outputs. That means no coins were created or destroyed. Verifiers don't care about anything else. All they're trying to do is verify that the system is working properly. And then as a second complication, you can see, and I've done this site of hand here, I said given a dollar value v in Zmod QZ, dollar values are not in Zmod QZ. You can't take a $0 bill to the bank and split it for a Q-10 bill and a $10 bill, unfortunately. So to make the system work, we have to restrict all of our amounts to very small values relative to the group order so that they'll behave mostly like positive integers. They won't overflow under any realistic scenarios. And for that, we need something called the range proof, which I won't go into in too much detail except to say that it is there. Okay, so our Peterson commitments consist of the actual amount, and they also have this other uniformly random blinding factor, R, which is used to hide the amount. And in order to reduce a transaction, you need to know the sum of the blinding factors for the inputs. And you can maybe see this by thinking about how you construct this and also knowing that the range proofs serve double duty in a practical system as a proof of knowledge of the blinding factor. So what this means is that you can't construct a transaction without knowing the secret. Well, in Bitcoin, we already have this rule that you can't construct this transaction without knowing secrets. The rule is you have to know the secret key associated to the public key every output is labeled by. So why have these two secrets? Why don't we just drop the secondary one, the one in what's called the script signature, and just use the Peterson commitment blinding factors as your secret. This almost works. There's a little bit too much structure here in the sense that in a real transaction, your inputs come from somebody, your outputs presumably are going to somebody else either to disparate distrusting parties who presumably should not know each other's blinding factors. So if you were to just use the homomorphic property, as I described, inputs, sum of inputs, it's equal sum of outputs, then you'd have this problem, which is the output owner would know the sum of the input blinding factor than vice versa. You're not really transferring anything in the sense that everyone involved in this transaction would know all of the blinding factor than therefore own all of the outputs. So the way Mimba-Wimba saw this is by adding a special zero-valued output called the kernel. The kernel cannot be spent, which means that to the extent that a sum of blinding factors and a kernel of blinding factor are known that's useless to somebody trying to create a transaction, they have to know a sum of actual spendable outputs. And this prevents those kind of attacks from happening. As a second feature, the kernel acts as a multi-signature key for all of the participants in the transaction. Okay, because what it is, really, it's a sum of all of the blinding factors from each participant, then multiplied by some generator G here. And you can think of this in two ways. One is as a sum of Peter's increments as a zero-valued output. The other way is as a multi-signature key. And these two things are complementary, and that's sort of the magic of Mimba-Wimba. So I'm going to switch now to pictures for the remainder of the first half of this talk to give you an idea of what the implications of this are. So here I've got two Mimba-Wimba transactions. I've got inputs, which are references to old outputs, and I've got outputs, which are new outputs. Okay, and the rule for these to be valid is rather than each input having some sort of signature attached to it, we simply require that the sum of the inputs minus the sum of the outputs equals the kernel. And these things are not really attached. You see the kernel, they're kind of free-floating there. The reason for that is that none of these things actually sign any of these other things. Okay? So that means that if I'm allowed to have a transaction with multiple kernels, say, I can just combine the inputs and combine the output sets, and now I've got this one transaction with two kernels, which is already kind of a neat feature. Right? This is, in Bitcoin, we call this coin join when you combine transactions that were otherwise unrelated. And you can do this non-interactively in Mimba-Wimba, because nothing is signing the complete transactions. But then, notice that this second transaction spends an output from the first transaction. Okay? And if my rule is simply that outputs minus inputs equals kernels, that means that I can just as well delete the input and the output as long as they're the same, and now I have a smaller transaction that is missing original transaction data, but still has the same net effect as those two transactions. And critically, because the kernel is still intact, and the kernels are each multi-signature keys from the two transactors, this entire aggregate transaction is still authenticated by everybody involved in the original two transactions. So somehow you're moving money from A to B to C. The intermediate step is deleted from the perspective of any public verifier, but you still retain A, the no inflation property, that the total input amount equals the total output amount, and also the authorization authentication property, which is that everybody involved in these transactions, or in any series of transactions that led to this output set signed off on everything that happened. There's no fraud happening. Okay? So here's where the cool stuff comes in. Suppose that we've got an entire blockchain of these nimble transactions, and you notice in this picture that every single block is a single transaction. The reason is that all the transactions in a block can be combined in the way I just described, so every block just has a set of inputs, a set of outputs, a set of kernels, and this picture I've only got one kernel per transaction, but there could be an arbitrary number, and that's what your blocks are, and it's hard to even describe these as transactions. They're really just inputs and outputs, and what we've got is a diff of the unspent output set. Now, suppose that I'm a new verifier trying to download the state of the chain. So normally in the Bitcoin paradigm, I download all the blocks, I download all of the transactions in those blocks, I verify them all, and so forth. In nimble-wimble, I can do that. What I can do, though, is download the transaction from every single block and combine them in this way that I showed before, because my validity requirement is just a sum property, and then observe that every single input, except for the coin-based inputs which create new coins, every single input is the output of a previous transaction, and that means that this telescoping sum property that I described can be applied across the entire blockchain, and now everything goes away. The only thing left is the coin-based inputs, which in practice are usually implicit, they're just a fixed, like, plus 50 coins every block kind of thing, and whichever outputs have not been spent, which is your final system state, the unspent output set, and these kernels. So every block has a pile of kernels, and this gives you the compression that I alluded to at the beginning of this talk. It's just this property that my inputs and my outputs cancel out algebraically. Now, this is pretty cool, but it makes more complicated things, more smart contract-y kind of things quite difficult, because when I deleted these outputs here, what I'm saying is that any new verifier does not see that those outputs ever existed. In principle, they have no idea that they were ever there, and in particular, if those outputs had weird requirements on them, things like, oh, X, like, M of N signers needed to sign this, or a hash preimage needed to be revealed, or something like that. There's no way that they can check that those conditions are verified, because there's no way that they can even see that those conditions existed. Okay, so it seems like this is a really limited thing, which, when the paper was published in August 2016, was more or less where we are, but in the second part of my talk, I will explain that we can actually, nonetheless, do some cool things, even though our verifiers don't see all of the data. So let me just give some numbers real quick about what we get from this compression. Okay, so in Bitcoin, we have roughly 150 million transactions, 400 million outputs, 65 million are unspent. So today, if you download the Bitcoin system, the Bitcoin blockchain, and you maintain a full transaction index, you get about 180 gigabytes of space on your disk. If you were to add confidential transactions, use these pedos increments rather than explicit values, this would more or less triple the reason being that the pedos increments need these range proofs attached to them, and these range proofs are pretty big. However, with Mimblewimble, because the intermediate outputs go away, along with their range proofs, we get a much smaller situation. We have about 18 gigabytes of transaction kernels, one per transaction, two gigabytes of the final unspent output set, which is just a bunch of pedos increments, they're just curve points, they're 32 bytes, and then 45 gigabytes of these range proofs. And those of you who have seen me give similar talks before, I might be surprised at how small all of these numbers are, that Mimblewimble, despite adding CT, leaves you with a total system that is much smaller than Bitcoin without CT. The reason is that thanks to Benedict Boone and Dan Boney at Stanford and Jonathan Boodle at UCO, we have a new very efficient range proof that came out in the last couple months called bulletproof, and the result of that is that the Mimblewimble system, including bulletproof, is much smaller than Bitcoin without any range proofs at all, which is a really exciting development. Okay, so let's move on to the next part, which is this is nice, but if all you can do is move coins from one place to another and you can't attach any conditions to this, this is not very exciting. However, Scripless Scripps, which is something that has been developed throughout 2017 and continues, sort of a very broad research project, is a way to use these kernels and these kernel signatures to attach conditions to them without modifying the system so that the verifiers need to understand these new rules. Okay, so what I mean by this is that somehow a set of parties can decide on some sort of contract that they want to execute, some sort of protocol they want to execute, and as a result of executing that faithfully, they will produce a valid signature and then the blockchain validates that the signature is valid. Okay, the blockchain does not need to know any of the details of the original contract. All right, and this came historically from Mimblewimble. We wanted, we wanted to be able to do cool stuff with Mimblewimble and we couldn't, but in fact any system that supports Snore signatures, in fact any system that supports some form of signature that is linear in some sense in the secret data can do this kind of stuff. Okay, and there are many reasons to do this. I described the motivation for Mimblewimble but even for bitcoin and friends, this is exciting. The reason being that the existing paradigm for doing this is to use what's called a script signature system where you explicitly lay out the rules that need to be validated and then you explicitly lay out a witness that those rules were followed and then everybody downloads all of this and they verify the witnesses for every single transaction. It prevents the compression that we talked about but it also means that anybody who wants to do cool stuff can only do it within a framework that the entire system is aware of. We've got a consensus system, everybody has to agree on whether or not some rules were followed so it's very difficult to extend this to do things that require primitives that did not exist or that do not yet exist in the system. As a secondary feature we care about privacy and fungibility for cryptocurrencies. Public cryptocurrencies have every transaction published and freely downloadable by everybody and this is very bad for privacy. It's very bad for commercial confidentiality especially if your amounts are on the blockchain. This makes it extremely difficult to do business when you're revealing all of your financial transactions. It's just it's no good. It really compromises the usability of any of these systems for real purposes. So using scriptless scripts we avoid a lot of that. We avoid revealing any contracts because all that hits the chain are these signatures, public keys and signatures. Okay so let me get into a bit more algebra and explain how this works. So probably most people here are familiar with Snore signatures or at least they saw them during school or something. Let me briefly overview how Snore multi signatures work. Where you have multiple parties, you want to create a signature that every participant needs to contribute to to produce a signature. Okay so these people all have their separate public keys, PI. They sum these up to get a joint public key P and they want to produce a signature which validates with the key P such that all of them together would need to produce that. So they do the standard Snore signature thing. You think of a nonce R which is actually K times G. You produce a signature S equals K plus EX where K is your secret nonce. X is your private key and E is somehow a hash of all of the data going into the signature. To do a multi-signature you just sum everything. So everybody chooses their own R equals K, G. Everybody passes around the different R values. They added up to get this joint R value and then everybody using that joint R value computes the hash, their hash challenge, and then they do the same thing. K S equals K plus EX except now E is the hash of their joint nonce and stuff and their joint public key and then they add all those S's together. So your nonces are a sum of everyone's contributed nonces. Your S values are a sum of everybody's contributed S values and the result is a multi-signature. Very, very easy, very simple. In practice I should warn people there are things called key cancellation attacks where people choose their public keys and nonces in adversarial ways. So you have to be a bit careful about this but this is not not an insurmountable problem and not a problem that will derail anything that I'm talking about here. So kind of a philosophical point is that these multi-signatures are already kind of a script-to-script by the definition that I gave earlier in the sense that you have a bunch of people who have all of their own independent public keys that they add together to get a joint key and what they publish to the wider world is just a joint key and joint signatures using that key. Public verifiers who weren't party to that don't know that the they don't know how many people were involved they don't even know that more than one person was involved they certainly don't know the original public keys and you can generalize this a bit there's a standard in the literature you look for threshold signatures you'll find a generalization of this to M of N signatures using linear secret sharing and and this nice property that because the multi signature came from adding up everyone's nonsense and adding up everyone's s values if you put a linear secret sharing scheme on there you can then you can basically do the same thing where you're contributing shares of signatures rather than entire signatures and it all just sort of works magically. Okay so I'm going to modify this multi-signature protocol a little bit to produce what I call an adaptive signature and that's going to be the building block for all of the script stuff that I've been working on so what we do here is that one party that let's just do the two-party case I talk about this more generally but it's much simpler for two parties so somebody rather than giving their nonce r and the multi-signature protocol they think of this blinding factor t and they send r plus t instead but they do everything else the same way and they're also going to send t this is kind of a weird thing to do because I'm not really blinding the nonce I'm not trying to hide it all I'm doing is offsetting it by some secret value that I know so we do all of this you follow the protocol the the same way that I described it and what you will get is a signature that is almost valid is valid if you offset it by some secret value t a little t here that only one party knows okay and it's easy for everyone involved in this to verify that this is happening correctly and so what you have basically is a signature or an adaptive signature I should say where knowledge of if you know the adaptive signature then knowledge of a valid signature with the same nonce which is enforced by the hash being the same and all this silly stuff knowledge of a valid signature is equivalent to knowledge of the secret value t little t here okay so this is a building block now we can do a lot of cool stuff with this is a really general thing when I said big t here I just threw the point over the wall and that will work and that will get you the system but if you attach any other auxiliary proof to t or if you're doing some other complicated multi-party protocol in parallel and this big t is something important to the protocol what you've got now is an adaptive signature that will let you translate correct movement of the auxiliary protocol into a valid signature and in particular if you're doing blockchainy kind of stuff you can create transactions that can only be completed by correct execution of this auxiliary protocol okay and this is this is extremely cheap to do so that's that's really exciting that means that a lot of like semi-honor systems where their incentive problem then you've got to add like a whole ton of auxiliary proofs maybe you can just stick like a monetary incentive for people to keep working like I I'm doing a multi-party protocol with someone I put up some coins that they can take I first put them into a two of two multi-sig output between me and my counterparty I then do this adaptive signature protocol such that the only way that they can complete the protocol and take their coins is by revealing the secret value which I then need for other reasons okay um so let me give one example of this um well before I do let me just emphasize this is really what I want to communicate to this audience is that this is a very general framework for attaching valid signatures to arbitrary discrete log-based protocols and more generally any protocol where your primitives are linear okay so there's a lot of really open surface for exploring this let me give a quick example um and then uh and then I'll close for questions which is the atomic swap and this is like your standard prototypical smart contract that you think about when you're doing blockchain stuff okay so we've got um Alice and Bob Alice has a coins on the the A coin blockchain and Bob has B coins on the B coin blockchain and they want to exchange these these two blockchains don't know about each other they can't verify each other's transactions but somehow they want to make this these two transactions happen atomically on each chain either they both go through or neither does so there's no no risk that Alice takes Bob's coins and then doesn't put up her own okay so there's a classical way to do this where you use the blockchain script system to put like a hash preimage challenge and then uh you have to reveal the same preimage on both sides and then basically Alice knows a preimage she reveals it to take her coins Bob copies it off of one chain onto the other chain it takes his coins it's how the atomicity works and here uh using adaptive signatures we can do something simpler where both Alice and Bob put up their coins on two of two outputs on each blockchain then Bob gives Alice adaptive signatures for each each side using the same t value meaning that for Bob to take his coins he needs to reveal t for Alice to take her coins she needs to reveal t and Bob actually knows t so they do this whole setup and then there's some ordering constraints here that I'm not going to go into if I had the full protocol but they do the whole setup and in the end nobody has an opportunity to take their coins without everything being set up such that when Bob takes his coins he publishes little t Alice can compute little t from the final signature that hits a blockchain and use that to get another signature giving her her coins and you get atomicity this way you still have this exchange of information but now we don't have explicit hashes on the blockchain we don't have explicit pre-images on the blockchain nobody can even see that this was happening and you have a much smaller system all that anybody needs to verify publicly is that these signatures are valid so that's pretty cool you basically just need change the support signatures you don't need any extra script properties and as a bonus you get this privacy and stuff so I have a list of open problems that the main one that I care about or the one that I'm thinking about most this morning is quantum resistance everything I've described just uses these really simple linear properties of digital signatures I think a lot of post-quantum schemes out there like NTRU and friends are using lattices which are also very linear objects and maybe there is a simple way to do all of this in a quantum hard setting which would be very exciting because as much as I love cyclic groups and discrete logarithms unfortunately it seems their days may be numbered and I'll have to start doing some real math so that is all I have thank you all right so we do have time for one or two questions so if you have one please walk to the mic I have a question so the blinding factor R becomes my private key yep how do I prevent other people come up with the same R so R here is a uniformly random point in the scalar in the scalar group so it's a 256-bit number so assuming the discrete logarithm problem is hard then nobody can compute R for the same reason that nobody can compute a secret key from their public key it is exactly the same security model here also I'm thinking about because the Peterson commitments if I actually know the discrete log between the two the group generator they will have like g and h yep yeah that's a very good question if I know g is xh I kind of like that's right okay so something I glossed over a bit if somebody knows the discrete log between g and h what we have is not a Peterson commitment but a chameleon signature chameleon hash I guess so when we generate these parameters we need g and h to be uniformly random points typically you have some sort of hash to hash to point function that you can use to get uniformly random points that basically come out of a random oracle and then assuming the discrete log is hard and assuming you actually have a random oracle you get two points such that nobody knows this discrete log and therefore nobody can compromise these Peterson commitments thanks all right so let's thank Andrew thank you