Mimblewimble

Andrew Poelstra (andytoshi)

https://www.youtube.com/watch?v=aHTRlbCaUyM

https://twitter.com/kanzure/status/801990263543648256

History

As Denise said, I gave a talk in Milan about mimblewimble about a month ago (slides). This is more or less the same talk, but rebalanced a bit to try to emphasize what I think is important and add some history that has happened in the intervening time. I'll get started.

Many of you have heard of mimblewimble. It's been in the news. It has a catchy name. It sticks around. I should explain what it is and what it's history is. The origin of mimblewimble is that it comes from the #bitcoin-wizards IRC channel. In the middle of the night one night in August some person called "Tom Elvis Jedusor" showed up. This was a name of Voldemort in the French version of the Harry Potter books. It's a pseudonym. He showed up on the IRC channel and dropped a text document. It was just some dot onion link saying hey guys I thought I have this file you might be interested check it out. So this was some random onion link. A couple of us downloaded it, and we checked that it was a plaintext file with no funny business inside of it. So I rehosted it and for the next week or so on -wizards and in person I spent a while dissecting this and trying to understand what it was and how it worked. This was leaked to reddit, well I guess several people reposted the links that the Voldemort guy reposted. There were some public discussions on reddit to try to figure out what the original document had said, because the original document was written in Frenchglish and it was not very precise or detailed. We got through all that and we figured out what was going on.

I eventually wrote a paper about mimblewimble, which describes in more detail what mimblewimble is, how the crypto works, and gives an argument for its security. That's what I talked about at Scaling Bitcoin in Milan.

Since then, I guess about 3 weeks after this, another person showed up in #bitcoin-wizards under the name "Ignotus Peverell" which is a name of a character in the Harry Potter books who invented the invisibility cloak. And what Peverell said was that he was working on an implementation of mimblewimble. He started it and published it and posted a github link.

Cool. This is great. I had been hoping to do this and I had never found the time. Fortunately some Harry Potter character usurped me. This guy showed up in IRC. I got a phone call. I was just at home drinking tea in Austin as I do. My phone went off, as it doesn't. And it was Bryan Bishop. It was Bryan Bishop saying "Hey Andrew get on IRC this is important you need to see this". Okay, so I went on IRC and sure enough here was yet another Harry Potter character showing up doing mimblewimble stuff which was super excited. I was super jacked. I went for a long run around Austin to let my excitement out.

Over the next couple weeks, this project continued. There were even more Harry Potter characters. There's I think "Grendel" the wine maker I think has show up, as well as Voldemort's mom, Merope Riddle. This is a continuing github project, although it's not something you can download and run today. Hopefully it will be runnable in the future. There is on-going work and development going into this, which is great. I'm not Ignotus Peverell, I am not Voldemort, I am not Bryan Bishop, I am not any of these people. I swear. You have my word, and nothing else. But that is my claim, and I'm sticking to it.

What is mimblewimble?

So in all this history, maybe I should explain what I'm talking about. Mimblewimble is a design for a blockchain-based ledger. It's basically a replacement for the bitcoin blockchain. It's a proposal for a bitcoin-like blockchain which could be implemented as a sidechain where you have a completely separate chain and you could move bitcoins into it and bitcoins out of it, it's separate. Or potentially in the far future where we have tested and proven this technology, we could potentially soft-fork this into bitcoin itself as some sort of extension block scheme, which would basically be like a sidechain that is integrated into the system.

Where mimblewimble diffles from bitcoin is that rather than having inputs sign the entire transaction, like in bitcoin where you have a pile of inputs and a pile of outputs and every input has a key associated with it and it has to have a signature for a transaction with that key. In mimblewimble, this model is changed. Rather than having each input sign the transaction, you sort of create a multisig across all inputs and all outputs. If you take the sum of all the keys on all the outputs, minus the sum of all the input keys, you get an elliptic curve point which you can treat as a public key and what that public key represents is a multisignature public key for all the transacting parties, the owner of every input and the owner of every output. And so a signature on this represents that the transaction was authorized by everybody involved, roughly.

Because of this design, mimblewimble does not support bitcoin script. Bitcoin script is used to do neat tricks like zero-knowledge contingent payments or tumblebit which is a mixing service design that came out of MIT. Another example is cross-chain atomic swaps, and non-interactive multisig schemes. All of this doesn't work with mimblewimble, because rather than having inputs that have meaningful signatures attached to it, the whole transaction has to sum and that sum has all the authentication in it. It's just a sum. It doesn't have a lot of features. You can't really modify it to have more features, although as we will see later in my talk there are some hacks you can do to get some of our favorite things from bitcoin to work.

Mimblewimble transactions

https://www.youtube.com/watch?v=aHTRlbCaUyM&t=6m15s

So let's try to be a little more precise here. A mimblewimble transaction like bitcoin is a list of inputs and a list of outputs. Where it differs from bitcoin is first of all that it supports confidential transactions, which is a scheme developed for sidechain Elements Alpha to encrypt the amounts of all transaction data. In bitcoin today, when you create a transaction, it's clear what all the output values are, it's clear what all the input values are, and if you want to check if the transaction is valid, you check whether the sum of the inputs is the sum of the outputs plus or minus some fee or something, but you can see all the inputs and all the outputs so you can see if the transaction is valid. In confidential transactions, it homomorphically encrypts all the values so that it's possible to add all the output values minus all the input values and verify cryptographically that this sums to zero. You can't tell what the individual values are, you can only see that they sum to zero. This is actually very close to how I described the entire transaction in mimblewimble. In mimblewimble, it extends this property of summing the outputs and inputs from just the values to the entire authentication for the transaction.

https://www.youtube.com/watch?v=aHTRlbCaUyM&t=7m35s

And the way it does this is through this "excess value". Every transaction has a bunch of inputs which is a reference to old outputs, and it has a bunch of outputs which are explicitly set. And then it has this difference, this "excess curve point", and a signature with this excess curve point. And this is what provides authentication for the transaction. I don't like that explanation, but I don't know if I can get into any more detail without directly reciting the paper I wrote. This is unfortunately a bit of a technical thing. The way to think about this is that the excess is a multisignature key, basically. It's a multisignature key with the owner of all inputs and the owners of all outputs.

What does this model get you? Here's my picture of a mimblewimble transaction. If I have two transactions like this, for this transaction to be valid, you need to be able to add up the iputs and ... check the excess value. Combining two transactions, two valid mimmblewimble transaction concatenated together, the result is another valid mimblewimble transaction. This is similar to bitcoin coinjoin, except in bitcoin coinjoin there's interaction between all participants. In mimblewimble, as long as you preserve the two excess values, you can combine any two transactions. This is like a non-interactive coinjoin.

One of these transactions spent an input from another output. If the difference between the input set and output set has to equal some value, it makes no difference if I add and subtract the same value. It's like the output never existed, and the transaction is still valid. If I create a transaction and I send a coin to someone, and then she passes the bitcoin on to someone else, these two transactions floating around the network can be combined and it will be like transaction cut-through. This doesn't mean that the intermediate recipients are removed, but rhater there's no evidence that they were involved. The excess value from the intermediate recipients are still valid and kept. The authorization is preserved. The evidence of intermediate steps in the chain of transactions are not preserved, though.

We can take this to an extreme. Within an entire block, we will combine all transactions. A block is a list of inputs, a list of outputs, and a list of excess values. It's the same as a transaction. If I have a whole blockchain like this, imagine that someone is joining the network for the first time. Mimblewimble runs for a whole year then someone new joins. In bitcoin, someone would need to do an initial block download and dowload 90 gigabytes of data and verify everything. They need to check thta the effect of every single transaction took place, to determine the correct current state of the chain. In mimblewimble, we can delete intermediate states, the entire blockchain. A new participant does not need all the data.

I can give a new verifier the combination of every single transaction that has ever happened. Every single input comes from an old output, except for the white ones here which are just coinbase outputs that are paying miners. Every single input can disappear and every single spent output can disappear. This new verifier needs the following data: the chain of headers showing that htis is a valid blockchain. They need the list of the unspent outputs, and also the list of excess values for every single block, which is way less data than downloading the whole chain. We have managed to get rid of a lot of outputs. Outputs in a confidential transaction scheme are pretty big and they take a lot to verify, they are like 2.5 kilobytes or something depending on how large a range you want to hide and other tweakable parameters. Most bitcoin outputs are 30-40 bytes, so getting rid of confidential transaction outputs is a huge win. This is also a big win for privacy. In this data, there is very little left of the original chain. All of these excess values are still floating around, it's all there in the history. You can't pretend that an authorization didn't happen, because you would have to rewrite the chain. And there's a 32 byte excess value hanging out in the blockchain. You don't need all the other data. We have preserved bitcoin's security model without having to keep all the data around. You can't rewrite transactions without also rewriting blocks.

Trust model

https://www.youtube.com/watch?v=aHTRlbCaUyM&t=14m20s

So let me try to say again what I just said. This is very important. I've deleted a lot of data and I am claiming that I am preserving the same trust model. What does it mean for a transaction to be valid?

First of all it must not create or destroy any coins. In bitcoin, fee goes to the miner and the net is still zero. In a confidential transactions scheme, you might do something different but the point is that you can't destroy or create any money, the transaction amounts must balance.

Secondly, any inputs into a transaction must be outputs of old transactions. And these outputs must be signed off by their owners. They must have authorization. This is a transaction network, not a thing where you get whatever you want without any restrictions network. It's hard to make an economy based on that, is all I can say.

We preserve this. The excess value is a multisig of all the input owners and all the output owners. In particular, all the input people and all the inputs are signed-off on. And we have preserved this non-inflationary property where we can add up all the encrypted outputs and all the encrypted inputs and check that the result sums to zero. The excess value is a multisig but it's also a proof that the transaction adds up to zero at the same time. This is through a neat cryptographic trick of confidential transactions where if you have a commitment to the value zero, you can create a signature with that commitment as though it was a public key. You can't do this with any other value. Zero is special. If you see a signature with a commitment, then you know the commitmet is to zero. We can exploit this and kill two birds with one stone here.

Block verification

Now let's look at what happens when we put these transactions into the blockchain. Like in bitcoin, we want to say that once a transaction appears in the blockchain that the transaction cannot be removed or reordered without rewriting the block. And then there's some infrastructure to make the block difficult to rewrite. We want a transaction in a block to be as good as the block. In schemes where you delete data from old blocks, this can be difficult to preserve. One idea you might have to reduce the amount of data in the blockchain would be to say well what if we just threw out old blocks. And every block, we commit to the current state of the network and once blokcs are old enough, we throw them away. When new users show up, they download the blockchain from up to 3 months ago, and then they play transactions forward. This saves data. But it does not preserve bitcoin's security model. Somebody with the hashpower to rewrite 3 months of work would be capable of rewriting any transaction that happened prior to that 3 months of work, which is something that bitcoin specifically protects against. There is an incentive cliff where somebody who is strong enough to rewrite 3 months less a day could... someone powerful enough to rewrite 3 months of transactions would be able to rewrite all of them. So there's already a large incentive for somebody who is attacking at that rate to also rewrite just a little bit more. And mimblewimble does not have this problem, because all the blocks and all the blockheaders of the entire blockchain remain in play. What gets dropped is just the explicit old transaction contents.

Roughly what I said, what data do you need in total? You need the blockheaders, the unspent outputs from every block, and the excess values. You need range proofs for the unspent outputs. This is the bulk of a confidential transaction output. It's a proof that the output although encrypted does not represent a negative value or some value that could act negative when you add it to another value. The concern here is that the homomorphic commitments might be vulnerable to overflow, there's some value that you could think of as -1 which you could use to inflate the currency if you did this in a naive way. If you just did homomorphic enryption, you could take a transaction, put no inputs into it, you could put a -10 output and a 10 output and this will add up to 0, even though you create 10 bitcoins, which is bad. Anyway, we have added a range proof, and this is preserved in mimblewimble because it's an extension of confidential transactions.

I am going to give some numbers on the Voldemort scheme that was posted in #bitcoin-wizards, although I can improve the numbers a little bit. In bitcoin, there's 150 million transactions leading to 40 million unspent transaction outputs. This is 21.6 GB of historic data. This would be 100 GB of UTXO range proofs, this would be 2 GB of UTXOs, it's a 50x amount of space required for the range proofs. So this doesn't look great--- it's 130 GB ofr a bitcoin-like system, and bitcoin today only takes 90 GB today. But consider that mimblewimble supports confidential transactions. If we added confidential transactions to bitcoin, since the beginning, and adding a 2 kilobyte range proof to every bitcoin UTXO, the amount of data would be about 1 terabyte. So mimblewimble's 130 GB is starting to look pretty good compared to that. This is a massive savings already versus bitcoin confidential transactions. Secondly, the rate of growth in this schemei s proportional to the number of UTXOs, not the total length of the historic chain. If someone creates a transaction that spends many inputs, but only a few outputs, this will actually shrink the blockchain. We wouldn't have a forever-increasing history size. In fact, we could incentivize the chain to not grow too wildly, we could put in an incentive to say hey there's a maximum number of UTXOs that can exist at any given blockheight or something. Annd then people would be incentivized to save fees or something to reduce the size of the UTXO set, which would be very cool and lead to a blockchain bounded in size.

There is a bit of cryptography we could use to shrink this. I'll talk about this at the end. These numbers are not the be-all end-all. Before I talk about new crypto, let's talk about where we're going with grin.

Grin

This Peverell guy who showed up and said he's working on a mimblewimble implementation... his implementation is called grin. You can find this on github. Right now the main focus is developing this. For the most part it's simple infrastructure, like setting up a p2p layer, figuring out encoding, setting up crypto that we need. It's not research-level work, it's just development work. A fair bit of this needs to happen before we can show this to people in a way that they can play around with. Part of that is nailing down the chain parameters. And finally, I've been talking since the Voldemort paper coming out, as implementing mimblewimble as a sidechain or as an extension block. The design philosophy of grin is to be as simple as possible. What this means is that right now it's implemented as an altcoin. I'm not very thrilled about this, if I was involved in this then that would mean I might be issuing securities or some other legal implications, and then you need to talk with exchanges and establish market makers and float and it's risk-prone to move into it.

What I would like to see is more research into extending Grin as a sidechain or both where a single chain would support multiple things. And that's something that I'm continuing to do research on. I have some cryptographic tricks that I think can be used to support this. I submitted a paper to Financial Crypto 2017 conference to talk about this in more detail. For now that's all I'm going to say. I have some tricks up my sleeve that I'm really excited about that I can hopefully talk about later when the time is right.

Next steps

That's the state of play for today. That's where we're at. Let me talk about some open problems. There's a pile of new crypto and some fun problems for those of you who are mathematically or cryptographically focused.

Unconditionally sound commitments and range proofs

The first open problem I want to pount is about unconditionally sound commmitments and range proofs. This is a general problem with confidential transactions which is if the underlying cryptography were broken, which would mean something like NSA revealing that they have broken all the crypto in the world, or a quantum computer or something like this, the consequences for confidential transactions today is that this would allow amounts to be forged. It would allow inflation to happen, where somebody could commit to some amount that adds up to zero, but later open it and reveal that the amount was much bigger. We would prefer this to not be possible. In the case of a mass crypto break, we would prefer that privacy be harmed but not inflation resistance and money soundness. And there is an inherent tradeoff here between unconditional soundness and unconditional hiding. Right now we have unconditional hiding which is cool but we would much rather have unconditional soundness. There's a tradeoff here. A few days ago I talked with Dan Boneh and he mentioned a scheme that can do this with about a 20% space hit which is pretty good. I think 20% is pretty small for the magnitude of the cryptographic assurance that it gives us. That's cool. I guess it's not an open problem anymore, but it's still a fun one.

Smaller range proofs? Aggregation of range proofs?

What about getting rid of that 20%? Can we make range proofs smaller? Can we make a pile of range proofs smaller? Can we do aggregation of range proofs? Someone is verifying a block. A block has 1000 outputs. Each output has a rangeproof. What about if you could make rangeproofs 10x bigger you could get 1000 of them much smaller? We ca do this with regular digital signatures, this is something that has been in the news for bitcoin as aggregate signatures to shrink the size of bitcoin blocks. Range proofs are a fair bit more complicated and intricate than signatures, but if we could aggregate them, that would be a huge space sizing. They are by far the bulk of the data and validation time. There ought to be something here. Often there's a shortcut.

Peer-to-peer protocol that can handle transaction merging

Another open problem that I didn't talk about too much is something that Grin is facing right now. How do you design a p2p protocol where it is possible to just combine transactions freely? It turns out that if you just allow free combination of transactions, this causes serious problems at the p2p layer even without Denial of Service attacks or griefing. Suppose you're a privacy-minded user, and you want to sed a coin to someone, but you don't want anyone to know this is happening. You might wait for some other transaction to come along, and when it does happen you want to broadcast a combination to the network instead of just yours. What happens if I do that, and someone else has the same idea? So now I have a combination where two transactions are conflicting, where it's missing my part but it has other parts. So now there are two conflicting transactions that conflict, and only one can geet confirmed. This is pretty bad. In practice, we need something different probably a bit more complicated than a simple flood network where people are combining all willy-nilly. For example, this might look like people sending transactions directly to miners, and they give a variant of the transaction to each miner. And then one miner knows what the original transactions were in the block, but nobody else knows. This is pretty good privacy and it's a fairly simple model to reason about, but it does require a communication channel with a miner which is a little annoying.

Quantum resistance

A final thing would be quantum resistance. I talked about unconditional soundness, which is a step towards this. In the presence of a quantum computer, people lose their privacy but hopefully by then we will have moved on to something different, but the system would still be sound. We have to be able to do better than this. There's a whole field of cryptography devoted to the idea of crypto primitives that do not break in the face of a quantum computer. I know how to replace most parts of mimblewimble with quantum hard primitives. The big part I'm missing is the rangeproofs themselves. My friends at Stanford are convinced this exists and they just need to search the literature. Maybe this is also not actually opened. My heart is open, though.

Q&A

A: Yep?

Q: On the .. merge.. would something like... deposit... in this use case?

A: The question is dealing with merge conflicts, for people memorizing or memoizing transactions that come by, will that fix it? Not entirely. You may be able to... no. In the example I gave, where I attached a transaction to one floating by, nobody knows my original transaction. Nobody even saw it. The original transaction didn't even exist. It's not a complete solution, unfortunately.

Q: Signature of all the other signatures...

A: Am I making a signature of all the other signatures. And no, when you aggregate the transactions there's a signature hanging off the excess values, and all the excess values stay separate and all the signatures stay separate. We could compress the combination of the signatures, but they still remain independent separate signatures.

COULD YOU GUYS WAIT FOR THE MIC?

A: Thank you.

Q: Sorry for interrupting. How many transactions per second can you do?

A: In real time, mimblewimble does not give you any compression. It gives you compression on disk, when bootstrapping new nodes too. Beyond that, these are transactions that are confidential transactions so every output has a rangeproof hanging off of it. I don't have numbers for you, but it's not as good as bitcoin.

Q: if I have a million transactions per second...

A: Mimblewimble will not help you with this.

Q: I have just a... quick question from your paper online. It says that the mimblewimble shrinks the transactions... such that bitcoin's history... shrunk... compressing PoW blockchains to reduce 15 gigabytes to less than 1 megabyte. How did this less than 1 megabyte.. is that accurate?

A: That is accurate. That is more than my existing talk in content. In briefly, the signatures that are on every excess value, I have a way to combine all the excess values and all the signatures in a single block. Beyond that, I have a way to remove entire intermediate blocks inside the history using something called compact SPV proofs which is described in the recent paper Proofs of proofs of work and also in the appendix of the sidechains whitepaper from a couple years ago. What this gets you is a blockchain that gets you maybe 100,000 blocks compressed to only a few thousand blocks, and maybe there's only a sngle signature or logarithmically many signatures in the original size of the chain. You can compress out the vast majority of all the blocks. This involves a lot more crypto and a lot of new assumptions compared to what normal mimblewimble requires.

Q: Congratulations on coining the term "massively prunable".

A: Thank you.

Q: One of the benefits is pruning the blockchain and reducing the size. Do you have any thoughts about when the size of the blockchain will become a problem?

A: I don't. There's an ongoing debate about capacity limits about a globally scalable distributed database that can't be reversed. I have no thoughts about the practical requirements there. It's good to have more capacity.

Q: Would it be possible for mimblewimble to assist in... let's say you could reduce or I'm not sure if this is possible... can you reduce the UTXO set and improve sharding capabilities? Right now sharding is out for UTXOs. Could mimblewimble fix this?

A: Probably mimblewimble makes this worse.

Q: Because rangeproofs?

A: Yes. Because if any output had a negative value anywhere, then the whole chain is broken. You need to know that every single output is positive.

Q: What are the cryptographic assumptions required, compared to similar projects? How long does it take to verify and create a mimblewimble trasaction?

A: The cryptographic assumption is that the elliptic curve discrete logarithm problem (ECDLP) is hard. That's it. There are no new cryptographic assumptions compared to bitcoin in mimblewimble. As far as creating a new mimblewimble transaction, this takes as long as creating the rangeproofs for all the outputs. On the order of milliseconds. I don't have exact numbers. I do, but I don't remember them. On the order of milliseconds. Pieter is nodding, he also has these benchmarks. Other projects that do similar things is Monero, which blinds the identity of the inputs in all of its transactions. I think Monero has no new cryptographic assumptions but its scalability is not as good as mimblewimble and its transactions are similar to create. The other one in the news lately is Zcash. The cryptographic assumptions in Zcash are much more taxing than they are for bitcoin. In Zcash they use an elliptic curve that supports pairing, and in addition they require some technical properties of this pairing to hold, there needs to be some hard problem related to this pairing. Also zcash requires trusted setup which they are calling "toxic waste" where if anyone has that data they could silently inflate coins. As far as creating transactions, I've heard numbrs for the confidential transactions that they create are on the order of 20 or 30 minutes. It's significantly higher than something like bitcoin, mimblewimble or monero where it's pretty much instant.

Q: The signature to the commitment to zero... in terms of making the excess value?

A: Oh thank you.

Q: Yes it would be nice to have that in the paper.

A: Ah, okay.

Q: Could you comment on the tricks to make smart contracts stuff work?

A: Oh, I forgot that. Absolutely. A big thing is timelock transactions. It's possible to create payment channels, using nothing but multisig and locktime transactions. Rangeproofs on the output assert ownership of the output and it's possible to interactively create rangeproofs, creating a M-of-M rangeproof and nobody has written the code yet but it's mathematically possible. It's interactive multisig, unlike bitcoin. There is interaction involved. As far as locktimes, this is much simpler than multisig. The excess value signs a minimum blockheight. Every transaction has a minimum blockheight, and the excess value signs this, everyone signs off on it. So now the excess s doing a third thing, which is enforcing the locktime. And this can create unidirectional payment channels.

Q: ...

A: Does this break sinking signatures? Yes. Part of the reason why I didn't talk about sinking signatures this time. It's a lot of complexity. It also requires a pairing assumption. It also breaks the payment channel design I mentioned a moment ago. This would be bad for scaling. If you can't do off-chain stuff, even with the mimblewimble compression, well that's not great.

Q: Is the anonymity you talk about, is that a product of the netting of the inputs and outputs? Is it exclusively a product of that? If there was one transaction in a block, would there be no anonymity?

A: There are two pieces. There's the netting of the transactions. We would prefer to have a p2p layer where not everyone is broadcasted to everything. If there is one transaction, and then everyone knows all the inputs and outputs correspond. Another part of mimblewimble privacy comes from confidential transactions and "no hair" -- no scripts. Every mimblewimble output looks like a uniformly random curvepoint and has no other features. You retain the transaction graph, but it retains much less information than in the bitcoin case. There's no scripts. No outputs. That's it.

Q: You talked about anonymity and also block size. What is the strongest feature of mimblewimble or something else? What makes it compelling?

A: I think right now the scaling is most compelling, because the scaling I know how to do. It doesn't involve p2p architecture or things I haven't touched before and would require outsides to hold my hands with. They are both pretty compelling, though.

Q: Do you think the required communication with miners, that you were alluding to, in some situations. How serious do you think that's a tradeoff? It seems like a big tradeoff.

A: It's a big tradeoff if you have very few miners. It's not as bad as it sounds, if you were to do this in bitcoin today. One is that you could have miners broadcast how to contact htem inside a block. There doesn't need to be a central directory. Secondly, it's possible in bitcoin today, but not very common as far as I know, for individual miners, meaning people who control th ASICs, to define the contents of the blocks using getblocktemplate. The people who create the block when they submit shares to their pool, rather than the share being a hash of the block, it could be a hash of an arbitrary block with a merkle proof showing that it pays the pool. The pool knows it is getting money but it doesn't know anything else about the block. This increases decentralization about what gets into blocks. You can communicate transactions to miners around the world. If you have 10k or 1 million miners and you communicate to some random subset and you give htem all random different transactions, then the resulting block with high probability, nobody will know what the original transactions were, with high probability.

ANY MORE QUESTIONS?

Q: So you can't create an alternative currency to bitcoin with this?

A: It's possible.

Q: It is possible?

A: Yes.

Q: Scaling is its main significance?

A: I guess so. The privacy too. There's a lot to this. If you are asking me whether the scaling is better or the privacy is better, it's like peanut butter and jelly. Pieter just said, you get one without trading off the other. In the past, you had to give up decentralization or privacy or something and give up scale for privacy. But here we get both in one package.

Q: So for a sidechain, what about the size of the sidechain?

A: Only the resources of the people validating it. That's the best answer I could give.

Q: What is the best application for this?

A: Mimblewimble, because it doesn't have scripts, basically only supports value transfer where somebody is sending money from one person to another. Bitcoin can do a lot of cool neat things with Bitcoin script like zero-knowledge contingent payments which is a trick... it was Sean Bowe, right. He sent a bitcoin or a test bitcoin to Greg Maxwell in exchange for a solution to a sudoku puzzle, on the bitcoin blockchain, during Financial Cryptography 2016. This was a neat trick. You can't do anything like that in mimblewimble. You can't do lightning payment channels. You can't do multi-hop magic lightning hashlock stuff. You can do simple payments only.

Q: ... are quantum computers.. an enemy or an advantage to this system?

A: For now, they are an enemy. The quantum hard systems that I know about are currently the data is a lot larger by some constant factor. I don't know if that's necessarily something that must be true. Perhaps the aggregate range proofs could be shrunk with quantum hard crypto systems, that would be cool. But for now, yeah it would be bad. There's no reason why this should be the case, it's just a matter of research t get a better answer.

Q: This is more philsoophical than technical. Can we curb inflation with these kinds of transactional exchanges?

A: To the same extent that you can curb inflation with bitcoin. If you were making an altcoin with mimblewimble, you would define a clear inflation schedule. In a sidechain, you would just copy the money supply from bitcoin and you can't effect the money supply at all if you're using an existing token. In this respect, mimblewimble doesn't add anything over bitcoin.

THANK YOU ANDREW FOR YOUR AWESOME TALK ABOUT MIMBLEWIMBLE YOU MAY NOW APPLAUSE

http://diyhpl.us/wiki/transcripts/grincon/2019/scriptless-scripts-with-mimblewimble/