Monero Monitor

Episode 16: Mimblewimble with Andrew Poelstra

05 Dec 20170 Comments

In July 2016, an unknown developer going by the name "Tom Elvis Jedusor" dropped a link to a Tor hidden service on the bitcoin-wizards IRC channel. In it, he revealed a new protocol dubbed "Mimblewimble" after the tongue-tying curse in Harry Potter, because "it is used to prevent the blockchain from talking about all user's information".

In the time since, multiple researchers and developers have continued to flesh out and build on Jedusor's innovation, in many respects led by Andrew Poelstra, a Bitcoin developer and mathematician at Blockstream.

This deep dive with Andrew covers the technical details of Mimblewimble's scaling and privacy-enhancing features, discusses the real world logistics of using the protocol, and looks at some of the coolest features enabled by the technology. We discuss how Bulletproofs can help both Mimblewimble and Monero better scale, and also touch on how ValueShuffle might further improve privacy in Mimblewimble.

If you enjoy the show and want to learn more about Mimblewimble, check out Be sure to also check out our transcript, below!

Did you enjoy this episode? Please show your support by donating today.


Podcast Transcript:

~~ { Introductory Music } ~~

Mike: Hey everyone, this is Mike, and you’re listening to the Monero Monitor. One of my biggest motivations for this podcast and really my interest in Monero in general is to learn more about efforts that promote improvements to privacy and fungibility in the larger Bitcoin space. I think it’s pretty clear from most of my episodes that I believe Monero today is maybe the best option for doing that, protecting you from others learning about how you transact and then also how much wealth you might have…

But today I want to talk about a project that has kind of been on my radar lately and isn’t necessarily related to Monero, but is still related to this larger focus on privacy and might have some ties in with Monero as well. So, that project is called Mimblewimble. There’s actually been a lot of chatter about this in Monero channels recently, so some people might have heard of it, but in today’s episode I’m hoping to dive a little deeper and get a much better understanding technologically how does this work and how might it compare to other options that we have, with things like Monero or Zcash or whatever. 

I personally, I would say that there’s a lot of projects in this space that really bother me today, there’s a lot of activity that doesn’t seem to be terribly productive, but Mimblewimble I would say is one of the few projects that does really interest me and especially projects that haven’t quite launched yet. This thing is really probably some of the coolest technology that’s out there, that’s close to being ready to go.

And so with all of that in mind, today I’m joined by Andrew Poelstra, he’s a mathematician at Blockstream and really has kind of been the key person - or at least one of the key people - over the last like year and a half in researching and developing Mimblewimble.

And so, hopefully, with today’s discussion we can get a better understanding of what exactly it is, maybe a little bit of where it comes from, and kind of where it’s going and how that might impact Monero or relate to just privacy in general in this space. And so, with all of that Andrew, thanks for coming on the show today.

Andrew: Yeah, thanks for having me. As Mike said, I’m a mathematician at Blockstream; I work mostly on privacy and scalability research, particularly applied cryptography to improve scalability and privacy. So, Monero is certainly  a project that I try to keep a close eye on, as is this new Mimblewimble thing which I have been spending quite a bit of time researching. 

I’m also a developer for the libsecp project which is a crypto implementation that is used for digital signatures in Bitcoin and Ethereum and friends, not that Ethereum is particularly private or scalable, but they use my code. So, that’s sort of where I’m coming from. And as I happens, I wound up being the face of Mimblewimble, in some sense, I gave the first public talk about at Scaling Bitcoin in 2016 and from there, well, as one of the few people involved in pushing this forward who has a real name and a real face, people started asking me about, so I am always happy to talk about. It’s a very exciting project.

Mike: Awesome. Yeah, you mentioned some of the others things that you worked on and really I think it’s kind of key to note that a lot of what you work on tends to be things that allow Bitcoin to scale in the future, with people maybe not even realizing it because they don’t get hyped up a lot. So, you mentioned libsecp, and you know, without something like that new library that you all put together, Bitcoin has a much harder time even handling its current volumes and things. So, I find the work you do to be some of the most valuable work in the space, that’s why I asked you to come on, so I was really glad when you agreed to.

QS 03:56 Mike: So, you kind of alluded to it a little bit, that there’s an interesting backstory to Mimblewimble, but before we get into that, which I do want to talk about because I think it’s a little bit fun, can we talk just very high-level what exactly Mimblewimble is and kind of, you know, if we were to run into somebody on the street, what would it be that we would explain to them as the goal of a project like Mimblewimble? 

Andrew: Sure, so there’s two prongs to what Mimblewimble does. The first is the confidentiality, privacy aspect of it, the majority of its privacy comes from something called Confidential Transactions which Monero also has, which allows the amount of any transactions to be hidden and this is, this by itself eliminates a lot of the extraneous data that ideally, the public shouldn’t be aware of when they’re validating transactions. The public needs to know transactions are legitimate, they shouldn’t be snooping into everybody’s private affairs, or rather, it should be possible for people to have private affairs. 

And hiding transaction amounts is a big step forward on that front because it means that people can move money around without identifying for example which part of the transaction corresponds to change and which part is the real transfer. It makes things like paychecks, which are big round numbers that happen every week at the same time, less identifiable; it means for example that when you’re paying your rent, your landlord can’t trace back and see how much money you’re making, like, “Oh, did he get a raise? Maybe your rent should go up…” kind of thing.

Mike: Yeah, I was gonna say, I find that to be one of the most compelling things is that if I pay somebody, with Monero is a good example that’s actually out today, but really anything with Confidential Transactions, they can’t go and trace the other part of the payment that comes back to me, the change part and say, “Oh, how much does this person have? And maybe I want to increase their rent next month” or something like that, so I appreciate that aspect of it immensely I think. Sorry, I interrupted you, though.

Andrew: Yeah, absolutely. But there are also knock-on effects that also improve privacy, a big one being that you can improve CoinJoin quite dramatically with Confidential Transactions. So, CoinJoin is when different people come together who are doing independent transactions and they decide to combine those transactions into what looks like one big transaction. And when you have transactions where all of the amounts are visible, it’s really obvious without a lot of work, it’s really obvious what parts of aggregate transaction correspond to the original transaction. 

And in particular, it’s really obvious what is change because you might have a whole bunch of round output values, and then you have these weird numbers, there’s a whole ton of decimals points that are clearly just an extra thing that needed to be thrown in there that makes the transaction balance out, and that’s what change is. And then what Mimblewimble does, the real magic of Mimblewimble and what distinguishes it from something like Monero, is that it exploits a quirk of Confidential Transactions algebra to allow transactions to be cut through. 

And what I mean by that is if I send some coins to somebody and they pass those coins along, say I give some money to Mike and let’s say that you just give it back to me even, so there’s two transactions here, Andrew to Mike and there’s Mike back to Andrew. The intermediate step where Mike held the coins, Mimblewimble allows that to be completely deleted from the blockchain and in fact, if we do this before anything hits the blockchain, that intermediate step doesn’t even hit the chain. So, it just looks like I sent money to myself. And this is not only a good thing for privacy which I can talk about more later on, but this also greatly improves the scalability of the system.

What that means, is for somebody trying to verify the entire history of the system, unlike in Bitcoin or Monero or something where you have to download every historic transaction and basically replay them to see that the current state of the chain is correct, in Mimblewimble, you can take the blockchain, essentially treat it as one enormous transaction where originally all the money was in the hands of the miners, and now it’s in the hands of whoever has it now. And of course, in real life, the money changed hands, you know, a thousand or a million times between Bitcoins being mined and the coins winding up where they are now, but verifiers don’t need to check that. 

All they need to check is for each original transaction, just a single digital signature, just one signature and it’s not even signing anything, it’s just signing its own public key. And so basically, what Mimblewimble achieves is compressing all of these transactions into the single public keys and the single signatures that don’t really identify anything at all about what the original transaction looks like, how many inputs they have, how many outputs it had, what those outputs were shaped like, and so on and so forth. All of that just goes away. 

Mike: Awesome, I’m glad you bring up cut through without me even asking about it. The way I kind of always pictured this and this comes from me having previously taught high school algebra, and I know that obviously the math is more complex, but at the same time it sort of takes advantage of the same algebraic manipulations, is that if you pictured an equation and on both sides of the equal signs you had lots of different things that could all reduce down, or cancel out some people like to say, and so you might have +4B, -4B, +2B, -3B, +5B on one side and then on another side you might have a bunch of other stuff… in my mind, I always think of it as, you can kind of reduce all of that down to, okay, what’s the most simple state of this end state, and so we would have all of our inputs to it being all the coinbase transactions that the miners mine. 

And then the other side of the equation is just what’s the current state of the current coin holding, so anybody that currently holds a certain number of coins is going to be on that side, and anybody that used to all got canceled out. Is that kind of the general idea? 

Andrew: Yeah, absolutely. Yeah, I remember a term from grade nine or sometime in high school, we had a telescoping sum, which is a sum with a whole bunch of terms, and then each of the terms kind of match up and you can cancel them out and what’s left is just like the first term and the last term, something like that.

Mike: Yeah, and the equivalence still holds, whether it’s the complicated version or the simple version.

Andrew: Yes, exactly, that’s the critical thing. And in fact, it’s pretty much exactly the same. The complexity comes in is that the word addition here, rather than it meaning adding two numbers, the way that it would in high school, here it means some elliptic curve operation, but it’s an elliptic curve operation that we can think of as addition because it retains all of these algebraic properties that addition has. So, really, conceptually, it’s exactly the same stuff that you learn in high school algebra.

QS 11:01 Mike:  Yeah, cool. Okay, so I want to dive more into the privacy stuff, but before we do that, we kind of teased it earlier, let’s tell the story of where all this came from. You are not the original person behind all this. Back in, I believe it was July of last year, of 2016, a guy, my understanding of the story is, a guy who went by the name of Tom Elvis Jedusor - which is an important name we can get to - but he just popped into bitcoin IRC or bitcoin-wizards or something and just popped a white paper down, is that about right? 

Andrew: Yeah, that’s correct. I can say a little bit more, we should give a bit of context for this.

Mike: Sure.

Andrew: This is not the first time in the history of cryptocurrency that some anonymous researcher has shown up and just dropped something in the middle of nowhere. So Monero, as you know, is based off of Bytecoin which was some bizarre premine scam, but Bytecoin had this innovation, this Ring Signature, which is sort of the core thing that Monero has, that it uses for its privacy. This Ring Signature - or at least the original one that Bytecoin used, now Monero uses RingCT which has much better privacy properties - the original one was invented by somebody named Nicolas van Saberhagen. 

And all three parts of that name are different nationalities, French, German, Dutch combination name, it’s not a real person, we can’t find any evidence that there is a real person behind there. So, that was way back in December 2012. And that’s something that led to a real system, Monero. 

Mike: So, you know the interesting thing is its dated as December 2012, but there’s actually a lot of evidence that that paper was actually written either later 2013, or early 2014 and so that’s actually a story that I don’t think has been covered very well by people like CoinDesk or you know, something like that. 

But to add to the scam and the bizarre pre-mine, there’s a whole lot of evidence that the signature on that whitepaper was faked, and that it was signed with software that didn’t even exist in 2012, so yeah, that’s a whole ‘nother can of worms that I would love some investigative journalist to get into, maybe I can at some point in time have time to put together a story on it. But anyway, that does I think set some precedents for what happened here with Mimblewimble though, which I think you were about to say. 

Andrew: Yeah, so I did not know that, that’s spooky because my next example is basically a direct precursor to Mimblewimble, this is something called OWAS, one-way aggregate signatures. OWAS. This was a whitepaper that never was implemented anywhere, it was published by a person under the name Horas Yuan Mouton which was my best pronunciation. This is an anagram of “Anonymous author”. This was published on bitcointalk in September of 2013 and what this allowed to do was, it used pairing-based cryptography to structure transactions in a way that they could be non-interactively combined and cut through, which is exactly what Mimblewimble does using Confidential Transactions.

So, this paper predated Confidential Transactions, the transactions it had had explicit amount and it did not hide the amounts and it did not exploit any quirk or amount hiding crypto to do this, it just invented a whole new thing, a whole new signature type that allowed, well, one-way aggregation. It allowed signatures to be combined in such a way that you couldn’t then pull them apart. So, this was a very interesting whitepaper when it first appeared.

It didn’t get a whole lot of attention, the big reason being that it used pairing-based cryptography which at the time, and even now is quite slow to implement in practice with a high enough security parameter. So, pairings, they let you do a whole lot of cool stuff, but people rarely do it because it turns out in practice, with something on a scale of a cryptocurrency, they’re just not very usable. 

So, apparently that happened around the same time that the van Saberhagen paper actually seems to have appeared, which is an interesting bit of history. But then, I guess, several years later now, three years later, in August 2016, when our friend Tom Elvis Jedusor showed up, he signed onto the Bitcoin Wizards IRC channel, under the name Major Player from an IP address that is somewhere outside of Los Angeles. And he showed up, I believe it was 2 a.m. UTC, so I’m here in Texas, I guess that’s like 10 p.m. and I guess 8 p.m. in California if you want, and he posted a link, he said something like, “Oh, I had this idea for improving Bitcoin, some friends of mine said that this channel would be interested, so here you go.” And he posted a link, it was a .onion link to a Tor Hidden Service that was just a plain text whitepaper. 

It was just a plain text file with a bunch of algebra in it. And it was very poorly written, it seemed to be written by a French person I guess, and there are a couple of reasons that we think that that maybe you want to go into. And he disappeared, he dropped this link, he signed off and went away. And it wasn’t until the next morning that anybody really noticed this I think, myself and Brian Bishop who’s also here in Austin with me, opened up the link, downloaded it, checked it, it was actually a text file and not some weird malware or something and rehosted it. 

Mike: Yeah, it’s rehosted I think on, so I’m actually looking at it right now. So, if anybody does want to go and see what we’re talking about, you can just log on to

Andrew: .org or .cash?

Mike: It might be a .cash as well, but it’s certainly at .org. It’s funny because we’ve never heard from this person since, right? 

Andrew: That is correct, yeah. 

Mike: Or at least as far as we know, maybe they have a different name now or something.

Andrew: Yeah, they could. So, what’s interesting or frustrating, depending on how you look at it, there isn’t really any way that it’s him, he didn’t leave a cryptographic key or anything like that, the only possible way that he could identify himself would be by the key used in the Tor hidden service that he was hosting the file on and that hidden service went down I guess several weeks after the paper was dropped, once it had been rehosted in a million other places. 

So, at this point, that server is down, I don’t know what key was used, I didn’t think to download the public key or anything, well, I guess the URL is a public key in Tor, so maybe we don’t need anything more than that. But that would be his only way really of identifying himself, would be to rehost something on the same Tor service.

Mike: Yeah, which, you know, maybe that was the whole point, that this person didn’t leave a public key so that we would never know who it was. I don’t know, I find it interesting, so then the name, and I think this might be at least one clue why some people think he’s French, Tom Elvis Jedusor is an important name for I would say my generation, I think you and I are about the same age so our generation, because for English speakers you might not recognize it, but if I were to say the name Tom Marvolo Riddle, people might recognize it. 

QS 18:24 And so, Tom Elvis Jedusor is the French name of Lord Voldemort in the Harry Potter books and that’s the first clue I think for why he might be French. Is there other clues as well?

Andrew: Yeah, so one other one is that he used the word “voilà” in the middle of his paper. Although, he used the word “voilà”, but he used the wrong accent on the a at the end of “voilà”. So, that’s either evidence that he made a typo, or is only pretending to be French. And the other evidence I have is just in the way the paper is written. So I grew up in Canada, there is a lot of French speakers on TV, the Prime Minister for most of my childhood was a native French speaker and there are certain mannerisms that you learn to recognize or ways of speaking and idioms and stuff that French speakers have, that this paper seemed to project that same style of speech. So, that’s really my evidence, just the writing style.

Mike: Interesting. I guess I should go ahead and say this, a few of my listeners know that I’m actually part French-Canadian and I will go ahead and say that I’m not Tom Elvis Jedusor, I didn’t know that part of the story, so this is an interesting coincidence.

It’s funny, because then people have kind of taken this whole Harry Potter theme, which actually, Mimblewimble itself comes from Harry Potter, I believe it’s the tongue-tying curse or something, it’s the curse that keeps people from being able to tell secrets, and so I suppose that’s where this name from the protocol came from. 

But people have kind of embraced the whole Harry Potter aspect of it and run with it a bit. So, at the end of this, we can maybe talk a little bit about some of that stuff, because there’s a whole altcoin being developed and all, but I don’t necessarily want to spend a lot of time focusing on that. But yeah, I mean it’s funny, because even we can expand this whole Harry Potter metaphor a little more, it really seems like Mimblewimble was little baby Harry Potter dropped on your doorstep that you then had to nurture to where it is. That’s the origin story of Harry Potter himself, I just find that to be an interesting quirk.

QS 20:37 Mike: But what made, when you read this paper, what made you decide, “Hey, I’m gonna chase this down and work on it”? 

Andrew: So, I am one of the co-authors, co-inventors, what have you of Confidential Transactions, which Mimblewimble is heavily based on. Confidential Transactions was originally Greg Maxwell, and Pieter Wuille, and Adam Back. And I developed an extension to that called Confidential Assets - which wound up being announced several months after Mimblewimble was public but I had actually developed it several months before - which is a way to do Confidential Transaction-like hiding, but for a multi-asset blockchain, meaning that you can have transactions where multiple distinct types of things are happening, so like in a side chain situation, you might have Bitcoin and Monero both moving on the same blockchain, and not only are the amounts hidden, but also the asset type, also whether it is Bitcoin or Monero is hidden.

And the result is you can’t tell which transactions are Bitcoin ones, or Monero ones, you can’t even tell if there’s a transaction that’s swapping them, it’s just very, very good privacy in that sense. So, what I had been looking up in order to do this was I took a specific part of what’s called the Pedersen commitment, which is a way that we encrypt the amount in all of these transactions. I take one part of it that we call the “second group generator” which is a technical term, it’s not too important, I thought what if we re-interpreted that group generator as an asset type, so instead of being a fixed thing, we’ll have a different one for every single asset.

And in fact, we can have a different one for every single output and it will just be a reblinded somehow, encrypted form of a real, well-defined asset type. So, what Tom Elvis Jedusor did, was he took another piece of this, called the blinding factor and he said, well what if we reinterpreted that blinding factor as a signing key and use that for authentication instead of having a script system. So, it was sort of a morally similar extension of Confidential Transactions, as something I had been thinking about, at least on the algebraic level and what he did with it, was of course dramatically different from just adding different asset support.

So, it was something I had been working on at least algebraically, so I was able to pick up very quickly what he was thinking or what he was describing I should say, because it wasn’t totally clear. If you read the original whitepaper, the English is not super-great, and the algebra is not super-fleshed out, but I was able to see what he was doing because I was very familiar with that.

Mike: Yeah, in fact I think there was even a small error at one point, in algebra, in the paper, or there was some type of mislabeling or something, but you’ve developed your own whitepaper now that kind of explores this a lot deeper, I believe, right? 

Andrew: Yeah, so a couple of months after Valdemort paper dropped, I wrote my own whitepaper that I published at Scaling Bitcoin Milan in 2016. And at this point I kind of wish that I had taken a different tack with that. So, what I was doing was, at the end of Voldemort’s whitepaper, he had three open questions. 

The first one was kind of a denial of service prevention thing, what if somebody gives you the wrong final UTXO set and you have to download the whole blockchain that turns out to be wrong, you throw it out and replace it, how do we solve that? And it turns out we were able to solve that question pretty quickly on reddit, just going back and forth trying to make other parts of the system work properly.

But there are two other questions which were quite important. One was asking, well, these transaction kernels, these public keys, and signatures that have to stick around forever, is there any way we can compress those and make those go away? 

And the third question he asked was is there any way that we can have script support, can we somehow get smart contracts, can we get lightning, can we get atomic swaps and so on? 

So, the whitepaper that I wrote a few months afterwards is focused on the second question, about scalability, how can we compress out these kernels and I found a way to do this using pairings, our old friend from OWAS when back when, in a very aggressive way that allowed the blockchain to shrink, not only from like 80 gig to 15 gig, as Voldemort had done, but from 15 gig down to like 1 megabyte. Which is as very exciting development, but we depended on pairings now and it also has some really bad ergonomic properties. 

It involves transactions that would expire, like they would become invalid if they didn’t get into the next block kind of thing, and later we realized there is no way to get these kind of transactions to work with scripting. So, this is the main reason that I’m not really a big fan of that old whitepaper, is that I later found a way to answer Voldemort’s third question, about scripting and maybe we’ll get into that a bit later. But it turns out it’s possible by tweaking these kernels in a certain way to add non-trivial conditions onto transactions and my original whitepaper which compressed up these kernels, it made them go away and compressed them to a megabyte eliminated that ability because the kernels were no longer there.

So, I’m no longer very interested in the stuff that I developed there, so it’s unfortunate that this whitepaper was where I tried to formalize Mimblewimble from, and it’s all mixed in with this thing I call sinking signatures, so most of the whitepaper I don’t really like and I wish I had done two separate papers, one that formalized Mimblewimble, the way that we think about it now which is basically true to what Voldemort originally proposed, and a separate one with sinking signatures which are kind of their own thing.

Mike: Yeah. You know, a part of it is that like, you’re right on the edge of kind of where technology is with all this blockchain stuff and so you’re gonna come up with ideas that sound great for a while, and then you realize hey, there’s actually a much better way to do this. So, I wouldn’t say you should be upset with yourself for how that came about or anything like that.

QS 26:35 Mike: But I want to build off little more of some of the things we’ve talked about, I want to touch on some of these scriptless scripts you alluded to or how you do scripts with Mimblewimble, but before we get to that, can we talk really briefly a little more in depth about what a transaction might look like? So, let’s say, I’m looking at my full node and watching traffic come through, or let’s say I’m looking at like a block explorer and some other people that I don’t know do  a transaction, what do I see? Because in Bitcoin I see here’s the origin, it’s an address, and here’s the destination and it’s another address and here’s the change, and that’s that. We already talked about how the amounts are going to be hidden, but from what I understand about Mimblewimble, the whole transaction itself is just completely different. And so can you talk a little more about that? 

Andrew: Yeah, absolutely. So, I’m first gonna answer your question for what if you’re looking at a block explorer, what if you’re just downloading Mimblewimble blocks which now have a whole pile of transactions in each one, what do you see? And what you will see is essentially a whole bunch of transaction inputs and a whole bunch of transaction outputs and a whole bunch of transaction kernels, which we remember are those public keys that really have the heart of the transaction in them, and there’s nothing really linking these things together. 

So, maybe these original transactions have a whole bunch of inputs that were destroyed and a whole bunch of outputs were created, the way they would be in Bitcoin or in Monero or what have you, but by the time they get into a block, because the transaction is structured as such that there is nothing really tying those things together, the miner just puts all of the inputs into a pile and all the outputs in a pile, and all the kernels in a pile, and the kernel retains the ability to cryptographically enforce that the transaction hasn’t been tampered with in any way, but the public validators don’t really see that. 

All they see that the kernel is valid, and they therefore infer that all of the inputs and outputs that wound up in the block are also valid because they couldn’t be there unless there was some valid kernel making them work out.

Mike: Yeah, and so what that then means is if I’m looking at these inputs and outputs and kernels, I might have 10 kernels that match 10 different transactions that were all cut through and there’s only maybe three inputs and six outputs and there’s no way for me to kind of like point to, “Oh, this kernel matches that input to that output.” But in general, I can look at all of the kernels together, and say, “This is a valid state of the blockchain.” Is that about right? 

Andrew: Yes, that’s exactly right. And that hits on an important point which is that you might not even see all of the inputs and outputs because some of them are cut through, but still whatever inputs and outputs existed, they were spent legally. Like, maybe an output existed and then a person who owned it spent it, well, they had to have done that for the whole thing to work out.

QS 29:27 Mike: Sure. Now, what if I’m NSA or you know, Interpol and I’ve setup a bunch of nodes that log all of the information that they see passing through the network, can they in doing that be able to break back apart, like okay, here are the actual inputs and outputs and how they match to each other, or is that still going to be something that’s difficult to achieve? 

Andrew: That would be difficult to achieve is the short answer. So, in the way that I described it, I had the miners collecting transactions and just throwing all of the inputs and outputs into a pile, I’m sort of assuming that the transactions themselves are coherent blobs that are on the network. And actually for peer-to-peer topology denial of service reason, it actually helps if the transactions themselves have some sort of signature or something that’s binding them together so they can’t be merged before they’re in a block.

And so that means that anybody who’s listening on the network can see all of the transactions and have a global view of the network I should say, it’s not necessarily true that all of the transactions are flooded the way they are in Bitcoin, then they would be able to see the original transaction. And what they would know is which inputs go to which outputs. 

Now, in Bitcoin and in Monero, first I’ll say Bitcoin, Monero is a bit more interesting. In Bitcoin, every output has an address on it and you can look at the address, you can see the amount and that’s got a lot of information about what the output is. In Mimblewimble, there is no address at all. Every output is only the amount and the amount itself is bound up in this Pedersen commitment object which is just a uniformly-random curve point. Any curve point is as likely as any other curve point, so it really doesn’t have any identifying information. 

And Monero achieves something similar, so Monero does have addresses and it does have something that looks like an address that lands in the blockchain, but it uses stealth addresses, meaning that person who sends money sort of derives a new uniformly random address for every transaction and the address that maybe was published on the internet or something never hits the blockchain, there’s no association between the final transaction and what the public address looks like.

So, the results of that are very similar, in both Monero and Mimblewimble, you have outputs that are essentially uniformly random objects, that don’t really have much information at all in them.

Mike: Yeah, so in my mind I kind of pictured it as if you took Monero and you got rid of the Ring part of Monero and all you had was the Confidential Transactions and you had the Stealth Addresses, you would be hiding who it is that’s receiving it, and then kind of in turn maybe you don’t know when they turn it around, you don’t necessarily know who that is that’s sending it, and you’re hiding the transaction amounts, but in Monero at least, you’ve got a blockchain that has a permanent history and you could do like a graph analysis of, “Okay, we don’t know what this address is and we don’t know what this other address is, and we don’t know what this third address is, but we can see that all three of those things were spent inside of a single transaction and so therefore we would know that all three of those things belong to the same person.” And that’s where the Ring part of Monero becomes a big, important factor, is that it hides where was that origin of a transaction. 

It sounds to me if somebody had a really good way of snooping on the Mimblewimble network, they could maybe do that same type of graph analysis of being able to say, okay, “There’s these three different transactions that their inputs all got spent and sent to this other output, and we don’t know who these inputs are, and we don’t know who those outputs are, but we can at least tie them together.” Is that kind of about right? 

Andrew: Yeah, that’s correct. So, in Mimblewimble, an omniscient observer, somebody who’s watching all the transactions go by from the start would be able to do this kind of graph analysis which is made much more difficult by Monero’s ring signatures. But, in both Monero and in any Mimblewimble implementation, there is still hope here, so the technology called ValueShuffle, that is developed by Tim Ruffing and Pedro Moreno-Sanchez and this allows you to CoinJoin Confidential Transactions. 

Meaning that you can have two transactions that have inputs that go into certain outputs and you can combine those and now you have a whole bunch of inputs and a whole bunch of outputs and there’s nothing mapping any of them to any others, because remember, they’re uniformly random now. It’s not like in Bitcoin where some are round numbers and some are not, some have addresses that are on the internet and some don’t, and all that. And that gets you very similar properties to the Mimblewimble situation in blocks where you’ve just got a whole bunch of inputs and a whole bunch of outputs and nothing really linking them together. 

And ValueShuffle is an interactive protocol, the miners can’t just do this themselves, the way that they can with Mimblewimble blocks, but if the participants are online and they’re willing to do this, then they can absolutely do this and get dramatically stronger privacy than they otherwise would against this kind of transaction graph analysis. 

Mike: Yeah, this actually brings up an interesting reason why I think Monero happens to be better than another coin that claims to be a privacy coin, Dash, which has something that’s not ValueShuffle, but it tries to achieve the same goal with their CoinJoin implementation. And when I hear CoinJoin - and this is why I don’t like Dash, and you, I would love to hear your input on this - when I hear about CoinJoin implementations that require active participants, I always worry that that is something that can be Sybil-attacked by somebody who wants to unmask someone. 

QS 35:03 For instance, let’s say that I knew that you were going to be sending Adam Back a transaction, and I for some reason had a desire to know about that transaction and where it was, if I know you’re gonna be doing that, then I can try and Sybil attack the active coin shuffling going on and basically be, I don’t know, 85% or 90% of the participants for the next half hour in coin shuffling and in doing so, I can kind of unwrap what’s going on with the coin shuffling because I now know all of the parts that were my parts, and there’s just not a whole lot of other parts left.  Is that something to actually be worried about and is there anything that Mimblewimble… Do I need to consider that when I’m thinking about something like a ValueShuffle?

Andrew: Yeah, so there are a couple of parts to that. One is that there’s sort of an inherent anti-Sybil property to CoinJoin which is that as long as a transaction is actually completed and sent to the network, that requires a Sybil attacker to put up some coins and actually spend them, and they can only do that so many times at once because they only have so many outputs to spend. 

Mike: Right.

Andrew: And so, the worry that you have then is what if somebody joins a CoinJoin, they join as somebody, but they don’t finish the final stage, they just back out? And that way, they can reuse their outputs a whole bunch of times, they aren’t limited in any way. And ValueShuffle gives you the ability to detect who is screwing around and to eject just those people, eject just the inputs that belong to the participant who didn’t complete the protocol properly. 

So, you have this inherent anti-Sybil or I should say Sybil-resistance caused by the fact there’s only so many outputs in the world and you have to tie up some of them uniquely to deal with or just to join in the CoinJoin. The other part is that, although this is some Sybil-resistance, it is obviously not the strongest thing in the world, if you have a low-volume CoinJoin system, it’s still possible to become 80 or 90 percent of the participants. 

Mike: Right. 

Andrew: In that case, basically, the privacy of the real participants reduces to that of what it would be without CoinJoin. Which is just to Confidential Transactions, just uniformly random things went in, uniformly random things went out. So, there is still some… so this is still pretty good privacy and there is still some benefit to the CoinJoin in a sense that this person is now de-anonymized to the specific Sybil-attacker, maybe NSA or something, but they aren’t de-anonymized to anybody else who isn’t privy to the NSA’s information. 

Mike: Yeah, I mean I kind of look at it as like, in Monero, and Zcash too, the optimization there is to basically not even allow these types of targeted attacks to happen and in doing so, ensure privacy for a 100% of the people. It sounds to me like in Mimblewimble it’s saying, well, if some rich actor really wanted to try and target an individual person, they might be able to squeeze out a little bit of information about them, but other than that rich actor doing this, basically you’re going to have a chain that is completely opaque to information on it if you’ve implemented something like ValueShuffle.

And so to me, that means that we have maybe 99% of the privacy with this as we might have, or maybe 95% or something, I don’t know what the percent is, as we might have with Zcash or Monero. But the trade-off then is that we have far better scaling and potentially other benefits as well, is that kind of a fair assessment?

Andrew: Yeah, I think so. It’s hard to quantify this stuff, but yes, that’s exactly it. The scalability wins are just so enormous here, that that’s really the value proposition for Mimblewimble. And I should say that this isn’t entirely just like a pure trade-off, like oh, we’ve got to sacrifice privacy so it’s a bit more efficient. 

What we’ve seen for example with Zcash, is that to use Zcash’s strong privacy features, you have to make transactions, these so-called shielded transactions that involve proving a general zero-knowledge proof that you’re updating a cryptographic accumulator in some way. And producing these transactions, I think initially there were some horrible numbers, I heard like 10 or 20 minutes, but now it’s down to just one or two minutes.

Mike: Yeah. And I think they have something in the pipeline that’s supposed to make it a little more efficient than that, but yeah.

Andrew: Okay, that’s great news, with these multi-minute transaction production times, in practice, nobody uses shielded transactions, only like 1 or 2% of all Zcash transactions are shielded because people are not producing them, because it’s too expensive to do on a phone, it’s too expensive for an exchange to do a 100,000 times a day. So there really is value in making this stuff more scalable because with all of this technology, the more users you have, the better your privacy is, because if you want to be hidden, you need to hide in a crowd. You can’t be the only person wearing a mask in the middle of a field; you’re not helping yourself at all by doing that. 

QS 40:24 Mike: Right. And you know, the other thing that I’ll throw into this whole discussion is that the scalability aspect of that becomes so important, when you consider that something like Zcash or something like Monero, you really only benefit from the full privacy of it if you’re running your own node and in order to run your own node with those two technologies, you have to maintain the entire history of the blockchain and you have to deal with all of the management of the data and the management of the throughput of the data. 

And with Mimblewimble, what I find just fascinating about it is I can start up a new node and almost instantly have a fully synced node because I don’t need to know all that history, and then I can turn it off and then two days later, turn it back on and can instantly basically just do like, sort of the equivalent of a single block update to now have another fully-synced and fully-validated node, which means then this is something that could be run on your smartphone without taking up a lot of computation power or a lot of storage. 

It’s something that could maybe even be run on its own little hardware device, but as a full node instead of just as a wallet. And so you know, it gets back to then what you’re saying where you end up with a much larger anonymity set because you can have so many more people actually running these full implementations of the software rather than relying in Monero’s case on something like MyMonero or on a remote node or something like that. So, it made this trade-off, but at the same time, maybe that trade-off actually still ends up being better from a privacy standpoint anyway, which is interesting. 

Andrew: Yeah, I agree with almost everything you said. The big, I guess the big thing that’s too optimistic right now is this comment about “instant”… it’s not quite instant, it’s still slow, it still requires a bit of time, the big reason is that every output in Mimblewimble, so outputs that are spent just go away, that’s great, you don’t have to think about it, but every output that is unspent at the time that you validate it, so maybe you’re syncing after a couple of days and you miss all of the transactions that happened in those days, that’s great, and you only see the final state…

Mike: Yeah.

Andrew: Each of those final outputs is still there and it has what’s called a range proof hanging off of it, and this is a way to prevent the encrypted amount from effectively being negative, because without these range proofs, with the possibility of creating negative outputs, the system just wouldn’t work. It would be possible for example to put one on Monero into a transaction and create two outputs, one of them had 11 Monero and the other had negative 10.

And of course that’s going to add up, 11 plus negative 10 does equal one, but you’ve created 11 Monero out of thin air, because you’re just going to delete the negative output. So, to prevent that, we have this thing called a “range proof” which right now is on every Confidential Transaction in Liquid or Elements where it was first created or in Monero as part of RingCT and in any Mimblewimble implementation, you also need these range proofs. 

So, right now, those are pretty hefty to verify, they are the equivalent, I mean, let’s say if we’re doing 64-bit range proof, we’re having numbers between zero and two to the 64. The result is something like 100 signature verifications in time, so on my system for example it takes about 8 milliseconds per output to validate these range proofs and these range proofs is going to be something like 4 or 5 kilobytes in size. 

Mike: Okay.

Andrew: But, there is some exciting news on this front, if we want to be able to be running full nodes on smartphones and all of that good stuff, we really need to deal with the size and the verification time of the range proofs. So, another project that I’ve been working on in conjunction with Dan Boneh and Jonathan Bootle and  Benedikt Bünz, who are the real masterminds behind this, all I do is write code on this project. The project is called Bulletproofs. And this is a way to make these range proofs much more efficient. 

And there are two pieces to this. The first is, for individual range proofs, this 5 kilobyte size goes down to about 750 bytes. The massive space decrease, but it’s better than that. For individual transactions and something like Monero where it’s already known which outputs come from the same transaction, you can combine these range proofs and the resulting combination is only logarithmic in the size of the number of range proofs that you have.

So, I said that one range proof is 750 bytes, well, to put two of them together, you could do that with only 64 extra bytes, not another 750. And it’s logarithmic, so every time I double it, there’s another 64 bytes. So suddenly you can do like, if you’ve got a transaction of a 100 range proofs, you could put all of that stuff together and the whole thing is only a couple of kilobytes versus a 100 times 5 kilobytes which is what it would be otherwise. 

So, the space-saving is absolutely dramatic, it’s incredible here. The verification time unfortunately does not shrink so dramatically, but it does shrink dramatically. So I mentioned that a 64-bit range proof would take around 8 milliseconds on my computer, on the same computer I can do a 64-bit Bulletproof range proof and that takes something like two and a half, I think 2.2 milliseconds. So, for a single output, there’s about a 3.5 times improvement.

And once again, if I combine outputs, I get even more than three and a half times, it would go up to 4, and then 4.1 and so on. It’s not super-great, it will eventually plateau, but it’s still a pretty dramatic performance improvement.

Mike: Yeah, and I’ve heard people in the Monero Research Lab talking about how, I think you alluded to it to, this is also going to benefit Monero and I assume anything else that uses Confidential Transactions as well where transactions will be much smaller and verify - I think in Monero’s case, they said a little bit faster - it sounds like you’re saying in some other cases it might be quite a bit faster. 

Andrew: Yeah, so the numbers that we’re hearing out of the Monero Research Lab are not as dramatic as mine, but that’s purely an engineering facet. I think that if we did enough of the background structural work in particular there is something called the multi-exponentiation algorithm that we have in libsecp, Bitcoin’s library, for unrelated reasons, for aggregate signatures, which is something we’re hoping to build for Bitcoin. 

If you have an algorithm like that and a few other optimizations that I’ve developed for Bulletproofs, you should be able to get similar performance numbers, similar improvement. I would expect we can get two to three times just with that extra engineering effort. But I mean, don’t go bugging Sarang and Smooth, “Andrew said you could get three times…” But I am cautiously optimistic that these are optimistic numbers that we can have in Monero at some point.

Mike: And you know, what’s interesting in Monero, so much of the development over the last few years has been focused on getting something that is usable and maximize its privacy, sort of at the expense of, okay, we’re not trying to optimize this yet, and it seems like, especially with some of the things the Monero Research Lab is doing and with the codebase getting a little more fleshed-out in terms of what RingCT looks like and things, in the future I think that those optimizations can start to happen, and so, maybe Monero starts to get that as time goes on.

QS 47:59 Mike: It sounds like, do you spend much time conversing with Monero Research Lab guys or is it just more like an in-passing thing? 

Andrew: From time to time I’ll show up in the Monero Research Lab channel. It used to be they had their own private IRC server, and I was invited into that, and then I lost my credentials or something, I forgot how to get in, so I stopped. But now they moved to Freenode, so that now I can actually idle there. I keep half an eye on what’s going on in the research lab channel.

My main focus is on Confidential Transactions and the hard crypto stuff. They spend a lot of time talking about cool things I’m sure are on this podcast, things like how is the blockchain structured, can we use any of these threading or braiding or whatever optimizations… Those, I don’t think too much about that, that’s not really my focus, but whenever something like Bulletproofs or something like RingCT shows up, then certainly I’m in touch with them and trying to make sure that we’re sharing ideas and nobody is making silly mistakes that just need a couple of extra eyes. 

Mike: Yeah, that’s good, I guess because this whole industry is so new, there’s like the Ledger Journal, but there really… a lot of what goes on is just heavily reliant on whitepapers and all of the different developers kind of peer-reviewing each other informally. And I come from an academic background where peer review is very formal, so it’s always interesting to me to see how this is a little bit different than maybe something you’d see in science or you know, in medicine or something like that, with how all of the peer review works. So, it’s good to hear that you and I know Greg Maxwell is another example, don’t just totally ignore Monero because it’s not Bitcoin, but instead try and build off of each other’s research which I think is super helpful for everybody involved. 

Andrew: Yeah, certainly. Greg and I are very friendly with the Monero people. And it’s funny, you mentioned how formal and how much infrastructure is around scientific peer review because pretty much every classic area of science did start something like this where there were individual researchers who were discovering, like magnetism, you’d have Faraday writing letters to… Oh, I forget now who Faraday was communicating with, I’m going to say somebody who’s a hundred years later… 

But everything sort of starts out with a very small community where everybody knows each other and they’re directly corresponding with each other and that’s how peer review works. In mathematics we see this a lot as well. Even modern-day mathematics, there are certain corners of esoteric subjects where before there are papers and journals, they are just emailed to various people. And then even in the journals, some field that is narrow, that is only a dozen or so people in the entire field, then everybody kind of knows who’s writing stuff and who’s reviewing it. 

I should mention for all the scientists listening in, mathematics is much less dangerous than it is in other fields because everything in math is sort of self-validating, we don’t have a need for double blinding and stuff like that, not nearly as much.

QS 51:05 Mike: Yeah, well cool. Okay, so can we talk just a little more then about… I think there’s one other kind of major distinction, I know we’re getting a little long on time, so stop me if you need to go, but I know if I’m running a Mimblewimble node, let’s say that it’s implemented in some sidechain on Bitcoin or something and for my podcast, let’s say that I want to accept donations in Mimblewimble or maybe I have a store that I want to accept payments in that, in Bitcoin or in Monero or most everything else, I can very minimally publish an address that people can then just in their own time select the address and send things to. 

But we’ve already talked about how Mimblewimble doesn’t even have addresses, but it also doesn’t really have as far as I understand that same non-interactiveness, so can we talk a little bit about, let’s say we got this going and I want to implement it in a store, how does that look like from the way that somebody buying from me is going to interact with my server that’s running the store and running my wallet to build this transaction?

Andrew: Sure. Let’s use the store example. I’m buying something; I’m going to buy this for one coin. You might think just from my descriptions of Mimblewimble that you could do this non-interactively in kind of a gross sense, where I make a transaction that doesn’t quite balance because it needs an extra one coin output, the store makes a transaction that does quite balance because it spends an extra coin that it shouldn’t, and then those two transactions combine, they can combine non-interactively and the result hits the blockchain as a fully-balancing transaction.

This is in theory possible. There are two problems with it. The first is that this transaction is going to have two kernels on it, it will be twice as big for future validators to deal with, which is not the end of the world, the other problem, much more seriously is, suppose I produce a transaction this way, now I have one coin that I spent, I produced half a transaction, I sent it to the store, the store finishes the transaction and publishes it to the blockchain. Now, the store adds its own one coin output and that’s just a uniformly random point, there is nothing about that that I can identify as belonging to the store, meaning that if I buy this item, I pay for it, and the store later says that I didn’t pay, and a grocery store wouldn’t do this, but a landlord might…

Mike: Right. 

Andrew: I have no recourse, I can’t go to the blockchain and say, “Hey, look, here is this transaction on the blockchain that has a store’s address in it.” Like, I clearly paid and they received the money because that’s what the blockchain says. So, in Mimblewimble, the store and you, the payer, need to interactively produce a transaction. What they do is they make one transaction that fully balances and the kernel will then be, I’ve been calling it a public key, it’s actually a multi-signature public key that both you and the store have to interact to sign. 

So, your wallet will make a connection to the store’s wallet, they’ll produce this transaction and jointly sign the kernel. And it turns out that this joint signature itself - and that will go in the blockchain - is evidence that you paid the store. So, you retain this proof of payment, but at the expense of now requiring that your wallet be online, it connects to the store’s wallet which has to be online, and they have to do a bit of a dance in order to send the money.

So, essentially everything in Mimblewimble except highly trusted scenarios like maybe you’re sending some coins to your own cold wallet or something like that, need to be interactive. And more than that, even in the non-interactive scenario, it’s not like the store can just make an address which is some small 30-byte thing and throw it over the wall. The store has to make half of the transaction and that half has to be unique per payment, you can’t reuse transaction halves in Mimblewimble. The system… very bad things will happen if you do that. You’re putting your own coin at risk if you’re doing that, even if it’s technically allowed, which it shouldn’t be. 

Mike: Yeah, interesting.

Andrew: Yeah, so it is much more involved. Transacting is much more involved in pretty much all the scenarios. Although in the case when people are both online and they both have software that knows how to talk to each other, things will work out. So, maybe for common, simple, small payments this will be perfectly fine, but for a lot of the kind of store of value or massive value transfer applications that Bitcoin supports very easily or Monero supports very easily, these things are much more difficult in Mimblewimble.

QS 55:41 Mike: Yeah, yeah, okay so then with all of that in mind, let’s say I am running this store, if I’m running it with Bitcoin, I might have something that knows my Bitcoin addresses and is checking the blockchain to see if payments come in, and when it sees that a payment comes in, it says, okay, this is now a fully complete transaction and it sends whatever the thing is that my store has. And I can do that without having my private keys on the store. Is there any way to achieve this without having your, kind of… basically to have the ability to receive payments with Mimblewimble, but not send payments so that you can have some type of storefront with a wallet running, but it’s not one that you’d have to worry about getting hacked and having your funds stolen? Does that make any sense? 

Andrew: Yeah, that does make sense. Hmm… You can do this, but it’s difficult. So, what you would do, and ultimately, some - well, it can be zero - but some amount of money has to be controlled by the store front. So, what you could have is you have your cold wallet in some sort of vault, and I mentioned how when you’re doing the non-interactive thing, the cold wallet produces half of the transactions, a bunch of outputs… Now suppose the cold wallet produces a whole bunch of one coin outputs and then it maybe attaches some kernels to those, now the storefront is able to take those halves of transactions and it takes some that won’t quite add up to a full transaction, so for example say customer is paying 10.1 coins, then the storefront might take 10 outputs that the cold wallet created that morning and shipped out, put those together and then the store adds it’s own 0.1 to it to complete the transaction and it would also complete the signature.

So, you could do stuff like that, and I haven’t… Please don’t go implement that protocol that I just made up on the phone, but you can do stuff like that. So it winds up being awkward, it requires your cold vault to produce a bunch of outputs in advance and to make it very precise or efficient is quite involved. So, I’m not going to say, no, it’s impossible, but in practice, it’s much more difficult and there are certainly engineering and operational security problems that aren’t yet solved around it. 

Mike: Sure, sure. Okay, just kind of something that I had thought of and I’ve never seen anybody really talk about it, so I figured you’d be the one to know.

QS 59:10 Mike: Okay, well, then there’s kind of like one last aspect, and we might not have a ton of time to talk about it, but all of this is interesting because it enables these peer-to-peer payments that are private and such, but Mimblewimble itself, as far as I understand doesn’t really allow scripts, but you have come up with a way that things like multi-signature or things like maybe time-locked contracts, I’m not sure, I’m just throwing something out there, might still be possible… And then building off of that, you already mentioned Confidential Assets in regards to just normal Confidential Transactions, but perhaps also that might be possible with Mimblewimble as well. 

So, I’ve heard people talk about using a Mimblewimble chain to then have pegged assets that might peg to Bitcoin or peg to Monero or peg to Litecoin or whatever, and sort of creating this secondary token on the channel. I’m just sort of throwing a bunch of terms out at you because this is kind of getting to the edge of what I fully understand about the protocol, but can you talk a little more about some of these more complex type of interactions beyond just simple payments? 

Andrew: Sure. So, unfortunately, I’ve only got two or three minutes for you.

Mike: Okay.

Andrew: I’d like to explore these in more depth and perhaps I could come back another time. 

Mike: That’d be great.

Andrew: And talk about this more technological stuff. But, first of all, Confidential Assets is completely compatible with Mimblewimble, I mentioned back when I was talking about the history, Confidential Assets tweak this thing we call the second generator, Mimblewimble tweaks this thing we call the blinding key, and those are separate things, you can tweak them both. And then you have Mimblewimble plus assets, basically. 

So, you could have a blockchain that supports multiple different asset types that is still a Mimblewimble blockchain and then from there, it’s a small, but quite involved step to have a side chain that supports multiple different currencies, all being pegged in from various places. And now these peg-ins will need to have some sort of proof of validity on other blockchains and that’s a very involved proof, and that won’t be able to be pruned in the same way that ordinary Mimblewimble transactions are. 

But the result is that you’ve got a blockchain that has a very compressible, very scalable Mimblewimble chain and then kind of attached to it has got this parallel blockchain, or an extension block if you want, tracking peg-ins and peg-outs from various other currencies and the whole thing fits together quite nicely. And I’ve given a high level description of this in a mailing list post about a year ago of how you might do this with Grin.

As far as scriptless scripts, this is really the more exciting thing and I hope that I can talk about it some time when I have a little more time. But what this lets you do is attach more elaborate conditions to transaction signing than just everybody involved signed it. So, as a quick example, you can do atomic swaps with this. So, what we could do is suppose I’m sending you money, and I want to receive some Bitcoin in exchange for it, and we want to do an atomic swap, I’m trying to send you these Mimblewimble coins, you’re trying to send me some Bitcoin, what I want is that as soon as I sign to give you your money, somehow, I also receive my money and you want the same thing. 

So, the problem is of course which one of us is going to go first, and which is going to be left holding the bag. And the way that you do this in something like Bitcoin that supports hash pre-images is you have some sort of hash challenge where nobody can take their money, except by revealing the pre-image to some cryptographic hash. And so the first person to do it reveals the pre-image and the other person just copies the pre-image off the other blockchain and that way as soon as one transaction is doable, the other one automatically is because there’s some secret data that’s exchanged using the blockchain. 

Monero can’t do this because Monero doesn’t have scripts and Mimblewimble certainly cant do this because Mimblewimble doesn’t have scripts, but there is a way by tweaking signatures that we can achieve the same effect. And what that is, is we essentially produce a multi-signature on a transaction, so I’ll put up some coins that you and I both need to sign in order for you to take, you’ll put up some coins that you and I both need to sign on the Bitcoin side for me to take, and now, before I sign to give you some coins, I ask you to sign both sides, the part giving you coins and the part taking the coins, but don’t tell me the signatures, you subtract them, you give me the difference of the signatures. 

And this really is the subtraction that you dealt with in grade school. You give me that through a little bit of crypto-magic, not like grade 9 linear algebra, I subtract the two verification equations; I can prove that this is a different and valid signature, even though I’m one of the signatures. At that point, I sign to give you your coins. And now I sign the blockchain at both sides, you signed to take your coins, I take your signature, add the difference that you gave me, it cancels out just like before, and what I’m left with is a signature giving me coins.

So, now your signature is what communicated to me the extra data that I needed in order to take my coins and it replaces the hash pre-image. And we could do much more powerful things with this, you can attach almost arbitrary data to signatures using tricks like this. And what’s very cool like this is that it works even on a blockchain without scripts, so you can do this on Monero, you can do this on a Mimblewimble chain with the kernel signatures. You can do it in Bitcoin, well, you will be able to soon, soon meaning hopefully in the next 12 months. Everything is slow on Bitcoin.

Mike: Sure.

Andrew: With something we call Schnorr signatures and you don’t need consensus support for it, you don’t need any fancy features, and the result also doesn’t look remarkable. What hits the blockchain is just an ordinary signature; it’s no different from any other signature. So, it’s much better for privacy and for fungibility because now nobody can see that there’s something funny going on with these transactions, that they’re somehow linked with other blockchains or anything like that. 

And you also get a scalability benefit because now validators don’t have to learn the detail of this complicated contract that you setup, all they see are signatures and they say, I know how to validate signatures, I’ll do that. And that’s what scriptless script is, and that you can use to build atomic swaps, you can use it to build kind of lightning channels, you can use it to do zero-knowledge continuous payments, all these kind of neat things that have been coming out of it the last few years, you can do with these scriptless scripts.

QS 1:04:49 Mike: Awesome. Okay, I don’t want to hold you up any longer, one last really quick question, there’s a coin that’s trying to implement this, I guess it’s gonna be the first Mimblewimble implementation called Grin, are you working on that at all or are you just working on all the protocol stuff? 

Andrew: Neither, so I’m certainly not contributing code or really pushing the project forward in any way. I’m not even following it that closely anymore because it’s moving so quickly. So, this is run by a whole bunch of Harry Potter characters, particularly Ignotus and Antioch Peverell, the two Peverell brothers from the Deathly Hallows. So, I keep an eye on what they’re doing in the same way that I communicate with Monero, just on the research front, and try to give them some cryptographic guidance, but certainly they’re moving much faster than I can keep up with and it does seem like they’re going to be the first real life instantiation of Mimblewimble that people can play with and use. 

Except possibly, possibly, possibly Blockstream’s Elements, the Elements project, which was the first showcase of CT. This actually supports Mimblewimble and it has since day one because Mimblewimble is just CT without scripts, right?

But it doesn’t have wallet support and it does have like a node that knows how to do the compaction and all that kind of stuff. So, in theory, somebody could go write a client for Elements today and have Mimblewimble going and that might be a faster way to get deployment of the basic idea. But Grin is certainly the first independent project to be taking this idea and running with it. 

Mike: Interesting. Okay, well then, is there any way if anybody wanted to get in touch with you about all this, what’s the best way to kind of get in touch and chat? 

Andrew: I’m on IRC, on Freenode, my handle is andytoshi, and you can email me, I don’t know, say, [email protected], anything at will eventually reach me. Okay, there are some that I blacklisted for spam reasons, so don’t make something up, but let’s just say, [email protected] 

Mike: Okay, well yeah, thank you for chatting with me and I would love to chat again sometime, maybe a couple of months down the road when all of this has fleshed itself out a little more. And otherwise, I’ll let you get going.

Andrew: All right, yeah, I’m afraid I’ve got to run, so thank you for having me.

Mike: Yeah, it’s been a pleasure. Have a good one.

Andrew: Yeah, you too!

Mike: Okay. Well, I definitely learned quite a bit there, I hope y’all found that as interesting and educational as I did.

If anybody wants to dive deeper into Mimblewimble, go to the page that Andrew mentioned in this show, I just went back to it for the first time in a while, and it has links to all the various papers that have been written about Mimblewimble, as well as the Mimblewimble mailing list and other discussion places. So, you should be able to find any information you want by going through that site. 

If anybody wants to hear more of our episodes, or read a transcript from today’s show, check out our website, or just look for our show in whatever your favorite podcast app is. Just want to also say that this show is run entirely on donations, we don’t do any advertising or anything like that, and so if you enjoyed the show, please consider donating on our website. Y’all can follow me on Twitter, I’m @MoneroMonitor, and with that, have a great day everybody!

~~ { Closing Music } ~~