 Mikaela is giving the talk. Hi, thanks. So this is joint work with Georg, my advisor, and Yanik. We are hanging around all the conference, during the whole conference, so feel free to talk to any of us. So Mimbo Wimble is a cryptocurrency that allows you to make private payments without having to download the entire blockchain, without having to download 200 gigabytes of data when you start a new client. It was proposed in 2016 by an anonymous person, going by the name of Tom Elvis Giustor, which is the name of Voldemort in the French version of Harry Potter. And it was built on the top of three main ideas. It's a standalone cryptocurrency, but it was built on three main ideas that were initially envisioned for Bitcoin, and for which Gregory Maxwell should be credited, namely confidential transactions, which adds up privacy on the top of Bitcoin, coin join, which adds up anonymity, and transaction cut-through, which adds up scalability. After this publication, the author disappeared, never to be found again. And some people took over this work, mostly Andrew Poulstra. And a couple of months later, another anonymous person, going by the name of Ignotus Peverl in Yo, for France, developed an implementation, and it's now launched. So in other words, what happened is that Gregory Maxwell put some forum posts on Bitcoin Talk, and the random guy appears, puts this text file, and three years later, a cryptocurrency is launched, potentially worth billions of dollars, and there is no proof of security. So what we did together with Georg and Yannick was prove that this cryptocurrency satisfies some security notions. And we tried to see if we could improve it by means of obstruction. Even before talking about ImboWimbo itself, can I get a show event of how many of you know what is a UTXO? Oh, wow. So in Bitcoin, at some point, you have to inject money into the system. And the way you do it is that you create a transaction that only specifies some outputs. You put a value, and you associate this value, this credit, to some verification key. And if you know the signing key associated with this verification key, then you can spend the money. And the way that you do it is that you create a new transaction where you specify in the outputs how much of this money you are giving to which verification key, and you would sign this transaction with your signing key. Now, you would have the transaction to be balanced. If I forget about fees and stuff like that, I would have that the sum of the output should be equal to the value associated to this input. And then it goes on and on like that. So for example, if I want to send, if I have one Bitcoin and I want to send you to you two Bitcoins, I would have to create a transaction and I would have to find two verification key, was value adds up to the amount that I want to send you. And there is no reason for which in the output, the output should be only the recipient. It could be, for example, a change that I want to keep for myself. Now, on the other side, when I receive a payment, how do I avoid double spending? How do I avoid that this signing key has not been used twice? And the way that I do so is that I construct a list of verification key together with the associated values that can spend the money. And the way that I do so is that I look at the world transaction history and I see the outputs and I check that they have not been spent. So again, if I start, if I download, if I have a new Bitcoin client, the way that I should accept new transaction is I download the world transaction history, which a few days ago amounted to more than 200 gigabytes. I verify all the transactions and then I construct this list. And there is a great deal of difference between downloading this world transaction history and downloading only the list of unspent transaction output, this UTXO set that I mentioned. And which right now amounts to more or less four gigabytes. And there is no reason for which I would have to download the whole transaction history rather than this set. And this is what's very difficult to achieve and at the same time where, what in some form at least Mimbo Mimbo achieves. Now back to the improvements that I wanted to mention. So the first improvement that I mentioned is coin join, which is adds up anonymity. And the way it does so is by noticing that in the inputs, there is no reason for which all the signatures should belong to the same person. So if I were to get together with other friends that are making other transactions at the same time, instead of signing only my little transaction, we could construct together, by coordination, a bigger transaction that specifying the outputs, all our outputs, and we would sign instead this bigger transaction. And that means of shuffling, this would destroy the link that we have between the sender and the recipient. Now, if there are some contribution which are a bit more complicated than that, for example, if I want to hide to the other participants how much money, which are my recipients, but the bottom line of this is that with cooperation, I can achieve some form of anonymity and that is always good to our friends. Cut through is not really possible in Bitcoin but the fundamental idea is that if at some point I'm creating some money and attributing it to Bob and then Bob sends it to Charlie, the ledger itself has no need to record the fact that Bob at some point had some money. This can easily be forgotten and the way we call it is cut through. Finally, the last privacy feature that was an initial envision for Bitcoin is called confidential transactions and it's the most cryptographically consistent and the basic idea is that if you want to hide the value in a Bitcoin transaction, you can replace them with commitments. If you don't know what commitments schemes are, you can think of them as encryption. If you don't know what encryption is, whatever. But the basic idea is that commitments are really what we want. They are, in the case of Henderson Commitment, they are perfectly adding so they perfectly hide the values and they are banding in the sense that once I selected this commitment, they can really change my mind about how much value I put in there. And at this point, one problem would be how do I check that the transaction is balanced? That the sum of the outputs minus the sum of the inputs is equal to zero. And the way that I would do it is that the transaction, the person that's creating the transaction would select the opening so that they sum up to zero. And at this point, if the sum of the commitments in the outputs minus the inputs is the identity element, it would mean necessarily that the values add up to zero and therefore the transaction is balanced. Now it's a little bit more complicated than that because implicitly these values are not natural elements. They are elements in a finite field. So for example, I could have as input P minus one and one on the other side and I don't really want to have this problem of wrap around. So in order to fix that, I have to add a range proof. Simulation extractable, zero-knowledge proof that says that these values is, for example, 32 bits long. And this is sort of the starting point for Mimbo-Mimbo. So if I were to take back confidential transactions in the way that I explained it before, I would have, instead of these values, again, these commitments and I would have some sort of opening associated to them and a transaction would have, again, this signature and then the values were placed by commitments. Now there is another way in which I can check that this transaction is balanced and it's not to force the person to put the openings to be equal to zero but to let define the access, what we'll call the access as the sum of the outputs minus sum of the inputs and notice that this is our group element. And we can see this as a public key of which only the sender, which has the inputs and the recipient, which has the outputs, know their respective secret key. So in theory, they could get together and prove to anybody knowledge of these secret key by making a signature, for example, on the empty element. And this, in some sense, would prove that they know the discrete log of this group element and therefore that it was a commitment to zero. And if it was a commitment to zero, it was a balanced transaction, the sort of the way it works. And the crazy idea of Mimbo-Mimbo, what makes it beautiful is that it actually says, well, right now when I want to make a transaction, I have two secret keys. I have an opening to the commitment and I have also a signing key. What if I just get rid of the signing keys? What if the signature that I'm making would be sufficient both for proving that a transaction is balanced and for proving that I really know the openings to this commitment? There is no a priori reason for which this would work and this is what we try to prove. So, using these, if I were to go back to the initial slide where we saw the flow of transactions, how do I create some money? I would have to create a new transaction where the value is replaced with the commitments again and I would have to specify in something that I call the supply how much value I'm creating. And the signature would be valid under the commitment in the output minus the commitment with zero blending factor to the value that's being declared. And it will sort of prove that this commitment is really creating this value and that I know the secret key for it. How, once I created this commitment, how do I spend it? And the way that I do it is that I would create again a transaction, I would put as input my commitment, I would declare the change, how much value I want to take for myself and on the other side, the recipient would create a commitment to the value of the reminder, the value that we agreed upon. And together, using our respective openings, we would create this signature, right? So actually what we do in the paper is we show the way in which these you can do it non-interactively. So here when Mimbo-Wimbo sort of starts to shine and if I have two transactions, and again this transaction are just two lists of commitments, which can be verified with a signature and the signature is valid again under the sum of the outputs minus sum of the inputs, I can also consider what is called an aggregated transaction. And what does it mean in the addition here? It means that I take the inputs of the two transactions and I concatenate them and I put it in a new transaction. I take the outputs and I concatenate them. I consider the union of the two. And now what is the access of this transaction? Well, the inputs get added together and the outputs get added together. So it's the addition of the two accesses, of the two previous accesses. And we know of a primitive, namely aggregated signatures, which allow me, without knowing the signing key of any of the two transactions, to squash together these two signatures and have only one which accounts for both at the same time. And the beautiful thing about this is that it gives me some, I can then shuffle the transaction and I would destroy the link between the two transactions individually. And also I can do this any time. I do not have to, I do not need to wait for any party to be online. I can do it non-interactively and what I want. And there is another thing that is interesting to notice. And it is that, this is the scalability feature of WimbleWimble, is that if I have a transaction where the output goes back as input, the intermediate thing that we talked about before, well, at this point, the final transaction, what do we have? We have that the same coin, the same commitment will appear both as input and as output. And therefore it does not contribute to the final sum. What does this mean? It means that what if we think cut through is the way we thought about this before? What if we just remove these commitments? Then the signature will still be valid because the access again has these terms canceling out each other. So they don't really contribute, so I can really get rid of them and still have a transaction which is valid. So in a way, the only price that I'm paying for aggregating to transaction is adding these group element over here. And in the meantime, I get rid of all the intermediate things. And the way that this sort of fits together is beautiful. And very simple at the same time. And in WimbleWimble, they used to say that everything is a transaction. Even the ledger, at this point, you can think of it just as a list of coins that have been generated at some point and then squashed together. So it has only outputs. And the supply, the money that has been generated accounts for the total amount of money that is available in the system. And the signature accounts for all the past transactions. So instead of downloading, if you remember the picture of before, if I want to have some cryptographic notion of validity of the UTXO, I just have to download this, verify the signature and all the range proofs and I'm done. I don't have to download 200 gigabytes of data. So what did we do? We took WimbleWimble, we abstracted away the notion of homomorphic commitments, simulation extractable, non-interactive zero knowledge proofs and arguments and aggregate signatures. We provide some security notion that we believe describe the security properties that we want from WimbleWimble. Namely, it is not possible to spend more money than is available in the system, which protects the system. It is not possible to steal money from our users. We want to protect the users and the amounts are hidden. We are protecting the transfers of money from user to user. And then we prove the security of WimbleWimble and in order to do so, we have to introduce new security assumptions of compatibility between the signature scheme and the commitment scheme. This comes from the fact that, as you saw before, a commitment to zero acts as a public key for signing a transaction. And we gave also examples of a commitment and signature scheme that satisfy this property, namely Pedersen commitments and Schnorr signatures, which is what has been used in the green implementation of WimbleWimble right now. And we gave another example, Pedersen commitments and BLS signature, which acts better in terms of aggregation because in BLS signature, aggregation of signature is only one group element. More formally, what did we prove is that inflation, again, protects the system. It says that it is very difficult for an adversary to create a ledger and a transaction which is consuming more money than was available in the system. And intuitively, you can say that this can happen in two ways. Either the adversary is breaking something in the cryptographic primitives using the ledger. For example, the binding property of the commitment scheme or the inforgeability notion for the signature or the range proofs, or it's creating a transaction which is not balanced. And in order to create a transaction, creating a transaction which is not balanced means that the signature is valid under a commitment that is non-zero. And again, you see that there is this sort of a relation between commitments and signature which needs to be put in place and formalized. Then we prove that it is not possible for an adversary that is observing honest user interacting and is interacting itself with the ledger to steal at any point in time one coin that belongs to an honest user. This is much more difficult to prove. Finally, we prove transaction indistinguishability. And it basically says that if we have two transactions of the same length, then you cannot really distinguish one from the other in the sort of in-CPA game. And actually, this sort of a weak notion of privacy and we're working on a stronger notion that we're going to integrate in the full version because in fact, if you consider two transactions and these two transactions have nothing in common, then when you aggregate them, these two accesses, the public keys, sort of uniquely identify the two constituting transactions of these aggregated transactions because they are the subset sum of some of these commitments. So I can in some sense derive back which transaction made it. And this is a property that implicitly I do not want to be there. And there was a proposal, namely kernel offset from Andrew Poulstra that is now integrated into green that prevents this. And this is something we will put in the full version, strengthening the privacy game for transaction and distinguishability. This is basically all I have to say so far. And I'd like to add that I am at the end of my PhD and I am looking for a postdoc. So if you're looking for somebody that can tell you that your proof system is secure and I can go all the way down to implementing hashing into the curve or hashing into a field element, maybe I'm the right person to talk to. Questions for Michela? So this notion of transactional linkability is what exactly does it cover? Does it also cover user linkability when I spend it goes from a user to another user and so on? Is it something like the same level as Zcash or is it weaker? For now it covers the fact that if I created some money and then I sent it to some other user and I squash together all these transactions, then these transactions are indistinguishable. Okay, so it's really for a particular transaction, the amount of money. But what about could this money be traced? The money can be traced unless you add this kernel offset thing. And this is something that we will put soon in the full version. This relation between commitments and signature, is that standard notion or is it something that you need on top of when you implement your blockchain you actually need to take care of that? It's something that is proper of WimbleWimble that we introduced. So does that require, do you need standard commitments and signatures? Yes, but it's appropriate you need to prove on a pair of commitment and signature. You need to prove that these pair commitment and signature satisfy your property. Namely, for example, at least the fact that a commitment to zero is a valid verification key or can be mapped to a valid verification key. Alright, thank you. Let's thank Michele again.