Grin/Mimblewimble Meetup in London with Yeastplume
Notes from the Q&A session with one of the lead developers of Grin, Tuesday May 22 2018.
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.
[N.B. If you’re completely unfamiliar with the project but have a basic understanding of Bitcoin, this overview might be useful. There is also a more in-depth introduction available for those with a more technical background.]
On Transactions
Q: Can you walk us through a transaction? How is it structured, and can you prove that you’ve sent funds to a recipient despite the confidential format?
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.
Q: Does this approach bring privacy problems?
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.
Q: Do both parties have to be online?
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.
Q: Does the interactive format make things such as cold storage and hardware wallets impossible?
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.
Q: Other than your IP address, how do you identify someone you want to transact with?
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.
Q: What’s the message format?
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.
Q: Is finality different in Grin compared to Bitcoin as transactions have to sum to zero?
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.
Q: Does Grin support something similar to SPV nodes in Bitcoin, where you download only the headers of the blocks? Or will you always need to run a full node?
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.
Q: So how big are the transactions?
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.
Q: How long does it take to create a proof?
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.
Q: Does this open up for a DoS attack? The fact that creating the proofs is quick and verifying them is much slower?
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
Q: Does Grin support 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.
Q: Any support for execution of arbitrary code? Turing complete?
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.
Q: If there’s no scripting language, how do you achieve things like multi-sig?
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.
Q: Is it easy to interface Grin to another platform? Say connecting it to Ethereum as a platform chain?
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.
Q: Are Scriptless Scripts already implemented? Is it be possible to do timelock transactions for lightning-style transactions?
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
Q: What does the mining and creation of coins look like?
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.
Q: What about the emission rate?
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.
Q: Is there a difficulty adjustment with the mining?
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.
Q: Is there a pool protocol for the miner?
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.
Q: Is there something like a block-size limit?
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.
Q: And the block time right now?
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.
Q: What factored into the decision for one minute?
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.
Q: Can you have zero confirmation transactions that happen faster than one minute?
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.
Q: Why, is there a double spend possibility?
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.
Q: How are the fees calculated?
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.
General
Q: Do you see Grin as a proof-of-concept of Mimblewimble or do you believe in actual wide adoption of the coin?
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.
Q: Would Bitcoin need upgrades in order to be able to support Grin being used as a side-chain to it?
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.
Q: Would you say it’s more private than Monero, or similar?
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.
Q: Do you have any ideas on how to avoid censorship?
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.
Q: How do you see governance evolving in the long term?
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.
Q: What would you say are the key weaknesses or threats?
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.
Q: Is it possible at some point that a competing entity will just fork the code and launch their own implementation?
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.
Q: Do you have any idea of who [Grin project creator] Ignotus Peverell is?
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
Q: Who pays your salary?
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.
Q: How open is the community to external contributors?
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.
Q: Why Rust? What’s the advantages and disadvantages?
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.
Q: When do you expect mainnet launch?
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.
Q: So what’s there left to do? What takes the rest of the next year?
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.
Q: Is each testnet wiped clean of coins to start the next testnet?
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.
Q: What type of peripheral services do you think could be useful at this stage?
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.
Q: How can we help?
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.
Thanks once again to Yeastplume and thank you for reading! Our next meetup takes place in London on August 1, we hope to see you then!
