Grin/Mimblewimble Meetup in London with Yeastplume

Daniel Lehnberg
Jun 11, 2018 · 18 min read

Notes from the Q&A session with one of the lead developers of Grin, Tuesday May 22 2018.

Image for post
Image for post
Photo from our first Grin meetup @ Zopa HQ!

A few weeks ago, 35 Grin enthusiasts got together for the first meetup of the Grin London community to catch up face to face over pizzas and drinks. As our inaugural guest, we were proud to welcome Yeastplume, one of the project’s lead developers, who gave a brief overview of the project and answered questions. We had a wide range of participants attending, some flying in all the way from Rome just to attend the session. Here are the notes from the discussion, edited for structure, brevity and clarity. A big thanks to Zopa for hosting us and to Yeastplume for making the time to fly over for this. Join us for the next meetup on August 1!

Quick overview by Yeastplume

Mimblewimble is a blockchain format that provides very good confidentiality built into the protocol. In order to verify a transaction in Mimblewimble all you have to do is to ensure the inputs and the outputs adds up to zero, which means your transaction is valid. Between the privacy and the scope for scalability, those are really the special things about the protocol.

Grin is the first project implementing Mimblewimble.

On Transactions

A: The format is interactive. Transactions cannot immediately be put on the chain like in Bitcoin; a Sender first needs to interact with the Recipient who has to sign the transaction with their key and return it to the Sender. The shortest possible path is this single round trip. In the wallet, this is implemented as one HTTP request and response and then it’s finished. The Sender will say “these are my coins that I want to put into the transaction, these are my inputs” put out the public version of the key that they are going to use to sign it, and send this to the Recipient. The Recipient takes that, create their own (single use) private keys, they say “here’s my output for that amount”, and ensure the amount corresponds to whatever the sender put in. And “here are my public keys”, sends that back, and the Sender can then combine all of this and post it to the blockchain from there. No private data has been exchanged in this process, and there’s no repudiation either. Those two wallets had to have been involved in the transaction, as the wallets with these master keys had to have signed on both sides in order for the transaction to work.

A: It does, in terms of somebody monitoring the network and tracing the path of the transaction. That’s one of the challenges that the Mimblewimble protocol has, but can be mitigated by traditional means through Tor or other secure services. We’ve also implemented another protocol called Dandelion to mitigate against this. Rather than sending a transaction directly into the pool exploding to every peer at once, Dandelion goes from one peer to another peer and to another single peer, until at some random point — poof! It explodes to broadcast the transaction. That goes a long way to obscuring where the transaction actually originated from in the network. So between this and traditional means of protecting your privacy, I think we’re okay.

A: No. A transaction needs to be interactive, the parties need to exchange information asynchronously. But this doesn’t need to happen on the internet–you could just as well write the communication down on a piece of paper and share it that way. One of the modes we’re going to be able to support soon will be emailing a transaction back and forth: Sender creates a transaction puts it in an email, sends it to the Recipient, who then can do their bit and send it back to the Sender who can broadcast it to the chain. It doesn’t need to happen over an HTTP connection, it can happen through any way information exchange is possible. The requirement to be interactive is a new one for a blockchain, there are upsides and downsides. We try to embrace the upsides with it as much as we can.

A: It’s definitely much harder, that’s one of the downsides. Since it’s interactive, you can’t just throw money into a wallet somewhere without that wallet’s participation. You need a public key from that wallet, but this needs to correspond to a private key that draws information from the transaction itself. So you can’t just say “here’s my public key, send me stuff”. You have to say “here’s a public key, specific to this transaction”, which the private key needs to generate. As for hardware wallets, it’s certainly possible to build them, and there are some thoughts and ideas on how. But it is going to be more of a challenge compared to other coins.

A: At the moment, there’s not a good answer for that built in. I’m building a lot of wallet library code at the moment to allow others to come along and help build solutions for this. Right now in my base implementation, I just have a transaction ID, and you identify someone through whichever way is used by your communication channel. This means your wallet can connect to any remote node, and this is not that secure at the moment. It’s very early days still for wallet interaction, and it’s something that we’re starting to focus more on.

A: It’s a simple JSON request, which is a reference implementation for now. There are a lot of ways this can be done in the future.

A: They sum to zero, but they can have any number of inputs or outputs. So there can be a transaction where 20 people are involved on one side and 100 people on the other side. This will work fine, it’s just that all inputs and outputs have to sum to zero. So it’s very flexible in that regard.

On syncing & scalability

Q: What is the scalability like, in relation to other blockchains?

A: Compared to something like Monero, there’s a lot more scalability. Monero has Ring Signatures, Confidential Transactions, and a whole range of other stuff that adds a lot of data to be stored on the blockchain. Mimblewimble achieves scalability at the core protocol level. Because all transactions need to add to zero, the whole history of the blockchain at that point need to add to zero. That’s all that needs to happen, and gives you a lot of really nice options for scalability. You can cut through a transaction before it hits the blockchain, you can do it afterwards, or you can run a full archive node as well. There are a lot of options basically, because of the way Mimblewimble works.

A: That’s what we do. We have something called fast sync, which downloads all of the headers first, and then the transaction history. The transaction history is highly compressed, with most spent transaction details removed. Fast sync will only do validation of a specific window of the past, say the past 2000 blocks, that you then validate yourself. And then once that’s done, you don’t need the rest of that history. You just need to get your node to a point where you believe the transaction history is correct. Once you’ve done that you can throw all this out, and can continue to throw out every new block once it’s been verified. We have gotten the time to set up a new Grin node down to about ten minutes, and that’s unlikely to change much. The time to bring a new node up to speed should stay constant over time. That’s in stark contrast to some of the other coins.

A: Roughly 1.5 kilobytes. Every output needs its own range proof. Which is fairly chunky at this point. It does not grow based on the amount of previous transactions on the chain. The history can at any point be chopped out, except for something called transaction kernels. It’s what you need in order to verify the entire history up until a certain point in the chain. A minimal transaction would be: a number of inputs, two outputs and the two outputs are what have two range proofs associated with them, which is roughly 750 bytes each.

A: Miliseconds. There are some benchmarks around. Verifying the proofs is the largest part of downloading or syncing a new chain, but we’re getting the times down. They are fairly acceptable and there’s no noticeable delay in creating a Bulletproof.

A: It’s only relevant when you’re validating a new node, or when you’re validating a new block. So while it’s possible that something like a bloat attack could be done on new nodes, it would be temporary.

On Smart Contracts

A: There is no scripting language built into Grin, so you can’t use Smart Contracts in the traditional way. However, through something called Scriptless Scripts you could do some tricks with additions and subtractions to private keys in order to enable functionality that is very similar to smart contracts.

A: No arbitrary code execution, Mimblewimble doesn’t work like that. There’s basically no point where you can insert any superflous data in the blockchain.

A: It’s done via Schnorr signatures. As you create the transaction, all the three parties will have their partial sigs, their own public keys, they are are all combined togehter into one signature that validates the transaction but nobody knows anybody else’s private keys.

A: There has been some talks about atomic swaps between Grin and Monero being possible, as they use a lot of similar constructs, like rangeproofs and confidential transactions. You hear a lot of talks about atomic swaps but there’s not a lot of actual implementations out there yet. It’s very theoretical at this point. Andrew Poelstra covers this in some of the recent talks he’s given, he would be the person to discuss this more with.

A: Scriptless scripts are not implemented yet but it is coming, although likely it won’t be part of the initial production release. We have a hard fork schedule built in every six months for the first two years of existence where we’ll deal with upgrades. It’s worth noting that Scriptless Scripts that only rely on signature and commitment constructions don’t need anything special at the protocol level, so these are supported already. In the docs section there’s information about timelock transactions and vaults. We haven’t had time to work out the details for all of this yet. But most of the things that have been done with scripts so far, we think can be supported through Scriptless Scripts.

On Mining

A: It’s a Proof of Work (PoW) called “Cuckoo Cycle”, which was created by John Tromp who is fairly well known in the mining community. He worked on the equihash solver for Zcash, I believe. I won’t go into detail on how it actually works, but it’s a very memory-intensive PoW. At launch it’s likely you’ll need at least 8Gb worth of memory on your graphic card. It’s morphed a bit over time, at first it was latency-bound and then it was memory bandwidth-bound and now there’s been some talks about what we’ll do about ASIC-resistance in the future. But the PoW is very sound, I think. John wrote the first version of the solvers, and we’ve since had some other people come around and they’ve managed to decrease the solve time by a factor of 4. In this context we’re talking about number of searches through a graph per second, which is how Cuckoo Cycle works. What we’re looking for in a PoW is to try and keep it distributed. You don’t want to rush towards centralisation you want to make sure everybody has a chance to mine it, at least initially. And I think this PoW does a good job at that because even with GPUs and the work that’s been done recently to speed that up, CPU mining is still viable at this point. And you get a ratio, maybe CPU will be an 1/8th as useful or a 1/10th as useful as a GPU but it’s still useful and you can still use it. So if we can keep that up for a little while I think it will have done it’s job until you know, the big actors swoop in, build an ASIC and the game changes. You’d like to avoid it and keep this from happening for as long as possible and keep it non-centralised, but we’re planning for it to happen at some point. Because I think it’s probably inevitable. When there’s enough value, somebody is going to do it, there’s no doubt about that.

A: Right now it’s planned to be linear. 60 grins every minute for the rest of eternity. We can argue about this one way or the other. We hear people coming new into the project and saying “well Bitcoin has a successful model, why don’t you just follow that?”. I don’t think Bitcoin’s model is actually that successful, not as a currency. I think the approach taken by Grin is fairly unique amongst other coins. The rate of inflation is not going to look as bad as it does on paper–as you need to take into accounts for the amount of lost coins. The inflation rate will cover the amount of lost coins, and that’s about it. In fact the inflation rate actually approaches zero over time. So if anything there’s going to be too few grins going out. There are a lot of people with a lot of opinions on this topic, people seem to be passionate about it. We are aware of both sides of the argument and try to take them into consideration, like we do with most things on the project. We all believe the work and technology is important. But you’re not going to find any ideologues on the project. People are listening to arguments, listening to reason. And we make all decision knowing that whatever we decide is probably going to be the wrong thing to do, but there’s no way of knowing right now. So you try to design your code to make sure you can handle eventualities when they come in.

A: Yes, it’s based on Digiwave/Digishield algorithm. It’s dynamic, looks at the past 60 blocks, finds the median and does some calculations and adjusts up and down from there. We think this is a good approach that makes us less open to attacks.

A: A version of Stratum has been implemented, there’s a stratum server running now. I did some work to split out the mining out of the core code. There’s been some interest in shown for running a pool.

A: We do it by weights as opposed to a particular block-size limit. So if you’re creating an output, it would give you greater weight in a transaction, as you end up creating a range proof which adds to the block size, which adds to bandwidth needs. There is a formula that weighs the number of inputs/outputs in the transaction. It’s not set in stone, it’s not like there’s a constant. I don’t expect to see a big political debate about big blocks versus small blocks in Grin. The way that the protocol is built has a natural disincentive to create big massive blocks. We’ll have to see if there’s something we would need to address further down the line.

A: It’s aimed at one minute. It is more than that at the moment as there’s so little mining power for Testnet grins of no value.

A: It makes for a nice, useable chain. It does creates challenges as it obviously creates more blocks. You’re more than likely going to have a lot of orphans going on. But it’s not the minimum it could be. I think one minute is fast enough for the most part. Again this is another philosophical debate that I don’t have a strong opinion on. Everybody has opinions and they are probably right at the same time.

A: You can, yes. You can do zero confirmations and cut them right through. If you just sold a porsche you’d probably want to wait for a confirmation or two though.

A: No, but you could have two people with the same wallet key putting up a transaction at the same time. It’s unlikely but it could happen. So you do want to wait for at least one confirmation.

A: They are adjustable, there’s a minimum fee calculation. It’s a consensus decision, based on the number of inputs and outputs. Outputs creates stress on the chain. And you can choose to include a larger fee if you wish to get prioritised by the miners. It’s up to the miners to figure the right fees out.


A: I believe in the technology itself. I do think that Grin has a good chance of becoming something that is widely used, with the hope of reaching the profile of Monero at some point perhaps. Again, we’re not ideologues, we’re interested in the technology. There’s no “we’re going to be the biggest coin in the world, and here’s our ICO”-paper. Everyone involved is very much into the technology and trying to make it as good and useable as possible.

A: Quite probably. It’s not really my area of expertise, but it certainly couldn’t be deployed to Bitcoin without some additional work, and that’s not necessarily going to happen. Bitcoin is very difficult to change. That’s one of the reasons why Grin was started as its own completely separate blockchain. There were some early talks about the project being a side-chain to Bitcoin, but the amount of effort it would take to make that working well was very high, it’s much easier to just start form scratch and prove the coin’s worth while not being held back by another project’s decisions.

A: Monero has a lot of things implemented to achieve their degree of privacy. I wouldn’t say more private than Monero, I’d say Grin achieves similar privacy at a much lesser cost, more efficiently. One thing that Monero has that we do not is Ring Signatures. We don’t do that. But again, this can be mitigated by Dandelion and HTTPS.

A: Nothing non-traditional at the moment. Tor services etc. Everything is so new, so we haven’t had time to dig into these things. What are we going to do for a P2P layer etc. We do HTTP for now because we have a lot of other things to worry about at the moment. Rather than writing our own layer 2 network. It will evolve over time.

A: It’s hard to say. We need to talk about governance fairly soon, especially before it goes live. There might be a need of a foundation of some description. Mostly to protect the developers at this point I think. I don’t think anyone has actually been sued for losing money on a blockchain but that’s a risk that needs to be addressed. It’s hard to say what form it’s going to take. Obviously you try to keep it as fair and as open as you can, the realities are that people developing the code are the ones who make the decisions, or have an easier time influencing what happens. We need to talk about this some more.

A: The need for transactions to be interactive is a threat. Not so much the interactivity itself, but the mechanism by which it happens. The fact that wallets for practical reasons often will need to be online, talking to each other. We’ll be mitigating that in a few ways. Other than that, and what’s already been discussed, I can’t really name something specifically. The data that ends up on the chain through Confidential Transactions is so perfectly hiding. Even if the Discrete Logarithm problem was solved one day, you still couldn’t look at the data and figure out what the amount of that was because it could be a number of correct answers.

A: Yes, and I invite anyone who wants to take the code and copy it and run their own project to do so. That’s the nature of open source, it belongs to everybody, and it belongs to nobody. If some other group or company wants to they can take it and run their own version, and they will, if there’s any success it’s going to happen. All we can do is stick to our guns. We’re not looking for popularity, we just want to build a good solution and put it out there.

A: No. I’m not going to speculate, he clearly wants to be left alone. What I do know is that Igno is very knowledgeable about blockchains. He’s very good at guiding the project. I’m still getting my education in this.

On development process & Contributing

A: The community pays my salary. I’ve done two fund raises so far and they’ve both been successful. There’s no ICOs, no backers, no VCs involved.

A: It is very open. Everyone who started on the project just started by contributing code, basically. This is the same way I did, I just started contributing code a year ago. There’s a very active Github with issues, a gitter chat, and a mailing list so anyone who wants to get involved can do so. It’s very merit based. If you submit code, and it works and it’s fairly straight forward to understand what you’ve just done, then it’s going to be merged, basically.

A: I think Rust is a good choice. The nice thing about it is that it’s one of the only languages I’ve ever used where you write some code and it always works exactly the way you thought it was going to. In comparison, using something like C, you would have to think of all your infrastructure, how you are going to handle bounds checking. This is all built into Rust. I would say it’s very annoying to work with at first, because it comes with a lot of expectations that you don’t usually see with programming languages. You have to think about Object ownership. Life times of the object you’re using. Once you get your head around it though, it produces correct code reliably. There are no surprises. It will work as you think it will. You can spend a lot more time focused on getting the code working, and a lot less time chasing the obscure bugs and putting together your framework like you would in a C project.

A: It feels to me about a year away. From a feature standpoint, it may be 70% there. We have a working blockchain, a working P2P network, a fast version of the sync working. I’ve been working on refactoring a lot of the wallet code. I think we need to launch with a nice and usable wallet, which we don’t really have at the moment. It will be a case tidying it up, refining and polishing a lot of the stuff that’s been built. And we need to allow for some time for testing, mature code is code that has been out in the wild for long enough to be mature. So that’s where we are at the moment.

A: Right now, there are refinements being done to the chain. We’re currently on Testnet 2 (TN2). There are some consensus-breaking stuff that we want to launch on a Testnet 3 (TN3), which is probably a few months away. We haven’t announced it yet. Again this is refinements we found through TN2, changes we want to make to the protocol. Bulletproof implementation improvements among other things.

A: Yeah. We need to start practicing hard forks, so while we will do this for TN3 and obviously for Mainnet launch, we will hopefully not see another wipe of the testnet, and we can instead just hard fork next time.

A: We have a couple of block explorers at this stage which is very useful. Wallets will become the most important thing because it’s the user facing portion. It doesn’t matter how good the tech is–if you have a poor user experience, you will not have users. 99.9% of people aren’t developers they just want things that work. So any kind of stuff around that is invaluable at this point I think.

A: If you’re a developer, just contribute directly. If you’re a VC, we can’t offer any ICO or pre-mining or anything like that. If you have the financial means, when the money runs out in a few months I’ll be running another campaign and if you know anybody willing to support they can contribute there.

Grin & Mimblewimble

Covering the Grin project & Mimblewimble protocol

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store