Daniel Lehnberg & Michael Cordner

Grin – Cypherpunk Mimblewimble

Three years ago, a mysterious txt file signed by a pseudonymous Tom Elvis Jedusor was dropped in the Bitcoin-Wizards IRC channel outlining a proposal called Mimblewimble. It proposed a novel way of combining many ideas from Bitcoin research in order to create a new blockchain protocol that will be highly scalable and increase privacy, while still using the same cryptographic assumptions as Bitcoin. A few months later this project was picked up by another pseudonymous individual who started working on an implementation he called Grin. Grin slowly began to draw attention from the Bitcoin community and got a lot of traction.

We join Michael Cordner (Yeastplume) and Daniel Lehnberg, two of the core developers of the Grin blockchain. In this episode we discuss some topics around Grin’s cypherpunk origins, privacy and scalability features, no-premine fair start, and interesting monetary policy.

Topics we discussed in this episode
  • Origins of the Mimblewimble proposal and the prior work it draws upon
  • Andrew Poelstra’s contributions to improving and fixing the original proposal
  • Scalability and fast sync times achieved through mimblewimble’s UTXO set compression
  • How UTXO compression when combined with the Dandellion p2p protocol can increase privacy
  • Changes in user experience from Bitcoin to Mimblewimble
  • Beginning of the Grin project as an implementation of the Mimblewimble protocol
  • Comparision to BEAM, a competing Mimblewimble implementation
  • Innovating on fair Proof of Work through dual Cuckoo Cycle
  • Grin’s Monetary Policy and the Mining Fair Start
Sponsored by
  • Microsoft Azure: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter.
Transcript

Sunny Aggarwal: Today on Epicenter we have on with us Michael Cordner and Daniel Lehnberg, two of the core developers of the Grin blockchain which implements this very interesting protocol called Mimblewimble and so throughout Epicenter we’ve briefly touched on Mimblewimble here and there, we’ve had Adam Back on before and Greg Maxwell and they’ve slightly touched on Mimblewimble, mentioned it in passing as  future scaling options, but we never really got a chance to fully deep dive in into Mimblewimble and it’s a very interesting protocol where in a way it’s very similar to the Bitcoin protocol, uses a lot of the same cryptography, uses a lot of the same intellectual basis, but brings a lot of these really cool features and it has this really cool backstory to it which you know will cover throughout the course of this episode, but before we jump into that Michael and Daniel, thank you guys for both for being on and Michael maybe you can introduce yourself how you got started into the space before even getting into Grin and Mimblewimble and then Daniel maybe you could do the same.

Michael Cordner: Yeah, sure. Okay. Well, thanks for having us. So my name is Michael Cordner and I go by the name Yeastplume in Grin circles, that would be my handle, and I’ve been working on Grin for I’d say we’re coming up on nearly two years maybe a little less than two years, at first just as a part-time developer contributor, but from about say February of last year I’ve been working on Grin full time using donations given to Grin by the community. So previous to Grin, I have about 20 years worth of kind of overall software development experience ranging from financial to games to educational software. So I think kind of a good broad background there. Immediately previous to to working on Grin I was doing a lot of low-level cryptographic work in the smart card industry, which has a bit of crossover with the cryptocurrency industry when it comes to hardware wallets and what have you, so yeah, so that’s basically my background and why I’m here today.

Sunny: Cool, and how did you get started with Bitcoin is Grin the first blockchain project you’ve worked on.

Michael: It’s the first one I’ve worked on properly. I mean, I’ve been following Bitcoin and derivatives for quite some time, but it was only kind of recently, as I got better at applied cryptography through previous jobs, and then the more cryptocurrencies tended to appeal to me because I realized it kind of pushes all my buttons when it comes to technical interests.

Sunny: I see very cool. And Daniel what about you? How did you get involved?

Daniel Lehnberg: Sure. Thank you for having us. I work as a product manager for a gaming company, I’ve been there for the past 12 years. Lately I’ve been doing new product development and I heard about Grin the first time I think a year ago and started reading up on it, starting to get kind of watch the space a little bit when I got a chance and so on and then becoming more and more involved mainly on kind of the project management side and the governance side, and I’ve been following the blockchain space for a long time. This is my first project, I heard about Bitcoin in 2011, dismissed it and then bought a Bitcoin in 2013 and then kind of been monitoring the space but being quite comfortable watching from the sidelines until I stumbled upon Grin and its structure, the ethos of the project was and you know the approach taken in developing it made it really attractive and made it really easy to participate. So I just kind of got sucked in.

Friederike Ernst: Wow that’s interesting. And so most of the great developers are actually anonymous right, but you guys are here on this show using clear names. You also go to conferences with your clear names. What made you decide to go public with your identities?

Michael: Well, actually I probably wouldn’t say most are anonymous now. I think there’s only two really who have chosen to remain completely anonymous and that’s Ignotus, the founder which I’m sure we’ll talk about it more later and then we have another developer Antioch Peverell, which in Harry Potter also chooses to remain anonymous, but the rest of us are fairly out in the open. I mean for my own perspective probably just didn’t know any better when I first got involved with the project. So that’s why I’m out the open but also because I’m taking funding from various sources. I feel it’s better to be out there so people know who they’re dealing with and you know, I can be out there on podcasts and promote without having to worry about that invisibility cloak.

Daniel: Yeah. It’s similar for my side. I mean, I was aware they were anonymous developers on the project, but the I just kind of did like a trade off in the sense that in order to be really anonymous you have to put in a lot of effort to do that and I just didn’t really see that, you know, either you do it the full way or you don’t do it at all. There’s no point in it because if somebody is motivated enough to find your identity they will and and I just didn’t really see a need for it. I think a lot of the reason why we might feel comfortable being out with clear names is also because the founder of Ignotus is anonymous, it might have been a bit different if it wasn’t for that.

Sunny: So you mean like over time some of the core developers who maybe were anonymous earlier have slowly started revealing their identities.

Daniel: No, what I mean is there’s only two who are actually actively trying to hide their identities. The rest are just using nicknames online, but that doesn’t mean that they’re actually trying to be perfectly hiding in their identities. You see what I mean?

Sunny: Oh interesting, okay.

Michael: Everyone except for the few who are anonymous we know personally and we’ve met a few times now, it’s actually quite hard to keep yourself  anonymous and do it. Well, it’s quite a time sink as well and you have to be really kind of dedicated to it to do it, to be able to know exactly what you’re doing online and be able to cover all your tracks in all cases is challenging. So it’s quite a lot of effort.

Friederike: It’s interesting that it’s different to the public perception that a lot of the developers are actually anonymous, but that’s probably just because you know, the founder himself or herself is anonymous. So yeah.

Michael: Yeah, that’s right.

Sunny: Yeah cool. So let’s jump into a little bit of this founding story then and so I remember I was teaching a class on Bitcoin back in 2015 or something and I think that’s around the time we went to school or teaching this class we heard about, oh there’s this new proposal that’s been around that, I first saw it on our / Bitcoin, but can you tell us a little bit about this story of how this white paper got put into the world and who put it there.

Daniel: Sure. So basically there was this IRC group for Bitcoin developers. It was called Bitcoin Wizards. An anonymous person basically came in there and dropped the paper that sketched out the kind of the basic concept of Mimblewimble, which was then picked up by Andrew Poelstra and I think Bryan Bishop as well and they kind of had some interactions there and Andrew formalized some of the concepts in there into a paper and took it from there.

Sunny: Right because it from what I remember the original document was literally just a txt file that was dropped in there and it looked like just some quick thoughts on what this guy was thinking and some ideas and also, for the listeners, one of the cute little story things there the anonymous person signed it themselves using the name Tom Elvis Jedusor which is the French name of Voldemort like in the English versions, it’s Tom Marvolo Riddle. So it’s the French alias. So yeah, do you guys have any guesses as to who it may have been I’ve heard clearly in the text file a lot of these ideas were heavily derived from Greg Maxwell’s previous works like CoinJoin and confidential transaction. I’ve heard it posited that it may have just been Greg himself, do you guys have any like theories on who this was or is it not even of interest to you and you actually don’t even care to find out.

Michael: I don’t personally have any theories on it. As you just said there, I think that’s kind of key. The Mimblewimble paper builds upon a lot of ideas that were already there, I kind of developed by establish cryptographers. The actual kind of portion of it that makes up Mimblewimble is just kind of a small insight / addition to what was already presented before. So whoever it was didn’t necessarily have to be a great cryptographer. It was certainly a great flash of insight wherever it came from but no to me, I mean, I don’t think we’re ever going to find out who it is and even if whoever it is makes himself known no one will believe them at this point. So I think we just have to leave it as a mythical creation story that this point.

Sunny: Right, there’s no cryptographic signature or anything all over the file. So there’s not even any way to know, no one could even prove it at this point anyways. And so what was Andrew Poelstra’s contribution here. So, you know, this file was exposited and then what was the original kind of response to this, did people immediately realize that oh, there’s something big here, or was it more of people like, okay another proposal and did it take time for Andrew to realize that Oh, there’s actually something much more insightful in this document here.

Michael: I wasn’t around in the early days, but from what I can see Andrew Poelstra had to look over it just to make sure that it was sound, I think there was a mistake or two and there that he eventually corrected and I mean he was interested enough from that to write a further white paper on how an entire Mimblewimble blockchain would work and I mean, he published a further proper white paper based on that which is a little bit outdated at this point. But then he had some other kind of additions to it of that you may have seen some presentations of his about about how to do some additions to it script to script, because there’s no script in Mimblewimble. There’s a lot of things that you can do in Bitcoin or it’s obvious how to do in Bitcoin via scripting that you can’t necessarily do as obviously in Mimblewimble, but you can still do it. So a lot of kind of additions to the protocol like that some of them theoretical some of them real fixes to what was there and I think that was it, I mean after the publication of those papers, he hangs around if we need to get a hold of them to ask him any questions he’s there, but he hasn’t been too active now over I’d say the past year, either just busy or working on other things at this point. So, yeah.

Friederike: That’s interesting. So in a way, it’s unusual for someone to actually pick up a proposal by someone else completely and so deeply immerse yourself in it that you actually find mistakes and can add to it substantially and make it into a fully-fledged proposal. What would you say helped for this to happen? I mean do you think this is just a lucky break for Mimblewimble? Are there tons of those proposals out there that just someone needs to pick up and make into something great. Or did Andrew look at this and saw the gem in the dirt, how do you think about this?

Michael: If you drop a new proposal for something or a new idea in a place like Bitcoin Wizards, it will generally get looked at fairly quickly by some serious people in the industry. So I do genuinely think that it’s not just a matter of getting lucky or being filtered somehow it was genuinely a very very transformative insight on what was already there. So, yeah, like I said, we’ve seen plenty of papers, there’s actually another paper put down by someone claiming to be the same Voldemort in this in a similar style that was dropped maybe about six months ago and that was looked at and completely trashed by the community  as it made absolutely no sense. So this is probably not the same the same Voldemort or if it was he got lucky that one time so yeah, I don’t think there’s an element to that like, I think there’s a genuine, if you have a good idea and you’re presented in the crypto space it will get considered generally.

Daniel: Yeah and I think the original text file was far from perfect. As you said it had some errors in it as well, but it was actually presented very succinctly and in a very approachable way which also helps of course because it makes it easy for anybody who is reviewing it to understand whether there’s some merits to these arguments or not, and because it was building on already established concepts that were already popular in the space that also made it much easier.

Friederike: So, how did how did it continue on from there? So how fast was this proposal that was then transformed by Andrew Poelstra, how fast did it pick up steam, how fast did developers actually come on board?

Michael: Well Andrew wrote the paper and then I think it was kind of, not quite forgotten about but put aside for a couple of months. It was only when someone by the name of Ignotus Peverell, founder of the project, appeared again in the same channel, I think it was around December of 2016.

Daniel: I think even October, so it was quite fast. Yeah.

Michael: Yeah. Yeah, and then he said I’ve actually started a an open source version of this and uploaded the code and invited everyone to take a look and I think it was it’s clear from the early conversations that it was almost obviously apparent that this Peverall person knew what he was doing and was starting a really serious effort to put together a Mimblewimble blockchain.

Daniel: And then I think also a few months later towards December, the Mimblewimble mailing list was established, which probably also helps a lot in taking the project forward. There was a lot of discussion going on with a lot of noteworthy and well-known people in the field contributing. This also helped raise the awareness of the project itself.

Sunny: So we keep saying this Mimblewimble blockchain and this movable protocol, but what even is this Mimblewimble protocol? And so, maybe we can start off with, let’s assume our listeners are relatively familiar with the Bitcoin protocol. How would you explain Mimblewimble to them and kind of explain what’s going on here?

Michael: Right. Okay. Well, I think rather than just kind of jumping into the mechanics of it we should say what what the goals of that are and that would be to provide what I call a very good privacy intrinsic to the blockchain. So on some other coins that may have been made have been originally derived from Bitcoin, the privacy would kind of be bolted on in certain ways, so your other coins like Monero would have two different ways, but the core of the chain itself would be the classic Bitcoin chain as in a ledger transactions going back forever. With the Mimblewimble protocol you have the the privacy built right into the core level. So if I perform a transaction, what ends up on the chain basically looks like random data and the way this is done also allows some other interesting properties to come out of there such as a positive effect on the transaction size are on the chain size. It ends up you end up getting a much the same privacy as other coins with the much greatly reduced storage space requirements as well as some other kind of nifty features that are built onto it, all of which add together to enhance privacy without the bloat that you may get in some other chains. So that’s fundamentally what Mimblewimble itself is about.

Sunny: So you see the primary benefit being the privacy side of things.

Michael: Yes. Absolutely. It’s built in, at protocol level it’s not optional.

Sunny: Interesting, because I remember when I first heard about Mimblewimble, I heard about it in the context of scalability and increasing the sync times of the chain, but I feel like I only started actually hearing about the privacy benefits later on so it’s interesting that, I just obviously haven’t been as involved with it so I guess I didn’t really hear about the privacy side of things until much later on.

Michael: It’s definitely a privacy point. It’s a confidentiality point, and that would pretty much be, from our perspective at least, the number one reason for it being. The scalability stuff is certainly nice to have and it’s something that we’re improving on as time goes on, you know finding ways to make it even more scalable, how do we reduce the size of UTXO etc. We’ll probably talk about some more technical details later on.

Daniel: Yeah, and maybe it’s good to point out that there’s the Mimblewimble protocol which we talked about which was kind of dropped on the IRC Channel and everything and then you have Grin which is an implementation of the Mimblewimble protocol but it’s so much more than that as well. Of course, it’s not only the protocol itself but a bunch of other things and different approaches and philosophies that add to that essentially,  and the key things that really stand out in terms of implementation wise for from Grin I think is that it tries to be very privacy-preserving to the greatest extent possible. It tries to be scalable and it tries to be minimal in the approach that it takes and its design as a blockchain in general, to be very lightweight and that contributes also to the privacy aspects because you don’t want to put a lot of information on the chain and so on, you want to do as little as possible basically. And that has some nice properties to it. There’s no address on the chain for example, and so on which it contributes to it being lightweight, but it also helps in the privacy aspects of it.

Friederike: So I see. The privacy aspect is the main feature of Mimblewimble but the scalability is also one further add-on benefit that you get. Could you briefly explain how it works on a technical level?

Michael: Yeah. It is a bit difficult to do without whiteboards and a bit of time and dealing with confused stares, but basically, how Bitcoin works is you have a ledger of transactions going back to the beginning, to the Genesis block basically, and you need to verify each and every transaction in order to start a new node. Mimblewimble works a little bit more mathematically. So rather than having to validate the ledger itself, you just need to validate the sum of what’s happened before so maybe I can try and walk through a transaction example.

If I perform a transaction, I have inputs and outputs and transactions are basically a load of inputs plus a bunch of outputs and it doesn’t matter how many there are it doesn’t matter how many participants there are, just the amount of the inputs that have gone in have to equal the amount of the outputs that have come out. Okay. So long as that’s true then the transaction is valid. Now on top of that we have something called an excess value which is used to enhance privacy as well as prove ownership of something. So, say I have a load of inputs and it adds up to a certain number, I will then choose a private key that represents another addition to that number and only I know that number and that’s my private key. So in order to validate that inputs plus outputs plus my private key that I’ve chosen which is an excess value, everything equals 0. I can do that without actually having to store the values of the amounts in there. Right? So validators can just add this all together, check everything equal zero and move on. So that’s fundamentally what happens on Mimblewimble blockchain. Does that make any sense?

Friederike: It does. So I think it’s actually really difficult to explain without a whiteboard as you said, but would you say it’s fair to describe it as being cryptography that is well known and it’s also used for Bitcoin with additional elements for obfuscation.

Michael: Yeah, absolutely. I mean we basically use the same library that’s used in Bitcoin. We use the same curve. It’s all based on the same fundamental mathematics. It’s just the way we’re kind of putting it together is slightly unique for Mimblewimble.

Friederike: Okay, and so this results in a blockchain where not only the transaction amounts are obfuscated, it’s it’s also obfuscated to where they’re coming from and where they’re going, and would you say that’s factually correct?

Michael: Yeah that is correct. I mean, I wouldn’t even say they’re all obfuscated, they’re just not there.

Daniel: Yeah, and also I should say, there are no addresses on the chain so of course, you’re not going to see from where it’s going but there is a chain of outputs of UTXO essentially on chain, but it’s very hard to derive making any sense of that. That’s basically the only information that is on there.

Sunny: So if there’s no addresses, how do signatures work in this system?

Michael: A signature basically proves that I had that excess value, what I was talking about before, because that’s what I use to sign the outputs that I put into a transaction. So the blockchain itself, it outputs all the way down. There’s no transactions on there. And in order to spend an output, I need to ensure that I have this excess value for each and every output that I put on there and then all of these added together become, I have to prove I knew the sum of all of these and then I can sign with that and validators are able to use that witness the thing and to prove that I had the right to spend it.

Sunny: I see, so essentially what’s going to happen here is, there’s some excess value in this last transaction that was sent to me and I am the only one who has knowledge of it and by proving that knowledge of that I’m the only one who’s able to spend this, but how did this excess value get into the previous transaction? So why is it in the outputs from the previous transaction. Didn’t that mean that whoever sent me the coins had to have known that excess value.

Michael: Right no they knew their excess value, but when a transaction happens, I create a new one which represents my things. So what happens is someone sends me a bunch of inputs for a certain amount as well as the signature will contain their excess value, and that gets sent to me and what I do is I create my own excess oil and create an output for that amount, and then I have one output that I know the excess value for and then I can validate all the inputs that came into the transaction from the other person equal that amount. So the sum is there and that’s how that’s validated.

Sunny: Right. So one of the key features or differences here with the Mimblewimble system is that in order to receive money I have to actually be part of the transaction making process, right?

Michael: That’s right. And we say that’s an interactive transaction. And it doesn’t mean you need to be online. It doesn’t have any of those connotations. It just means two parties need to interact to exchange information and that can be on the internet, can be via sending files to each other, it can be via a tin can on a string. It just has to happen somehow.

Friederike: Does this have any implications for the user experience as opposed to when you compare it to sending say Bitcoins?

Daniel: Oh, yeah tons of it. It’s a very very different experience and so it for good and bad as well, so it’s just different I would say, so as Michael said a full round trip is required to complete the transaction, which means that I as a sender need to send you some information, you take that information you process that, return it back to me. Then I can finalize it and put it on the chain. But that also means that in order for, unlike for example Bitcoin where you can just in the blind shoot transactions to addresses, here actually both parties need to participate in order to receive, which in some cases can sound like it’s a lot of hassle or work, but in other cases, it’s actually really good because then you can actually if you want to make sure ,you have to keep like an audit trail or keep your finances in order, you can ensure that you have full control of the funds that you receive because you’re actually actively participating in receiving them if you see what I mean. Nobody can kind of spam you with with a bunch of transactions.

Sunny: Right. Some people may actually see this as a pro because I remember about a couple weeks ago, there is this YouTuber who I follow, his name is Tom Scott, and he got into an argument with Brendan Eich who is working on as you know, Brave or Basic Attention token, and he was getting upset that in Basic Attention token, and so really most cryptocurrencies, Bitcoin, Ethereum, people have the ability to send you money without your consent essentially and this could have weird legal or regulatory consequences. And so to some people they might actually see this as a pro and help the adoption from a legal perspective as well.

Daniel: Absolutely and also from the point of like being a merchant right, then you send you know instructions to your customer how to pay you, it prevents a lot of user error as well, because if user does something wrong hopefully you’ll detect that’s part of building that transaction and you can reject those transactions rather than the user sending it to the wrong address getting that processed and then saying hey, where’s my stuff and you have this disconnect while you try to figure out what actually happened here. It’s much easier to do that in an interactive protocol whether merchants can kind of sense check whether it’s the correct expected behavior from the customer. But it is also different than what’s usually being done today in blockchains. So there is a lot of extra effort or thinking that that goes into it from merchants perspective and also from users perspective. So it is a different approach that that we’re taking.

Friederike: Okay. So in Mimblewimble, while it’s interact to create privacy preserving interactions, how does this help with scalability?

Michael: Right. There’s a few things. I think most simply, in order to sync up I don’t need to have the whole history of the chain behind me. I simply need to have the headers and I simply need to have enough of something what we call the transaction kernel which contains all of the signatures to date to make sure that they add up to zero, and I need to make sure that those all that up. So instead of you know, if you if you think a new Bitcoin node for instance, you’re downloading the whole history. In this case no, you just need to download the headers and then enough information to make sure that the sum of the entire chain equals zero and then you should be good to go. I mean it’s only early days for the Grin chain at the moment, but you can already see the sync process is a few minutes and that should, provided the header sync time is fast enough, the same time should remain fairly constant for a new node coming on no matter how big the chain is, so that’s certainly one advantage.

There’s other ones mentioned in the paper, but they’re probably in practice not quite as bountiful for scalability. One of them is a notion of cut-through, which is if I send transaction to somebody and they immediately send it to somebody else, I can actually cut out some of the outputs in the middle of that because everything will still add up. So I’m basically taking the same number of both sides of an equation. And yeah Daniel may have something to add as well.

Daniel: Yeah. I think you covered it. But I wanted to point out that it was part of that thinking process. This is not like a light client sync or anything like that or as SPV approach. It’s actually like a full node sync and and it gives you proper security guarantees and it’s much faster than you conventional approaches.

Sunny: Right. Yeah, I mean so I’ve actually been dabbling around with the Grin nodes and I’ve been trying to run a Grin miner over the past week or so. And so when I actually started I opened up my Grin node and it synced in a matter of 30 seconds or so, and not that the Grin blockchain has only been around for a month anyway, so it’s like it would have been that long anyways, but it kind of blew me away I was like woah, did it actually just sync or I probably messed something up. I need to try this again. It kind of blew my mind.

Michael: Yeah, it’s early days for the blockchain but it’s even after a month like it should take longer. If it were  traditional blockchain it would be taking longer already.

Sunny: So, right exactly and so that really amazed me there. So with this cut-through thing, so you’re saying we can, kind of like to give some intuition for the listeners, essentially what we can do here is once transactions have been spent we can delete them from the chain essentially. We’re aggregating everything that’s already spent. And so all we have is the current UTXO set and nothing of the history, right. Is there any piece of data that has to stick around from the history or does it all completely, a hundred percent disappear?

Michael: No, the transaction kernels need to stay around and that’s probably the biggest point against scalability, there’s no way to currently compress the kernels, basically you can most other parts of the system. If we do figure that out one day then we’re going to have a very very compact blockchain. I’m not even sure you can call it a chain anymore at that point,.

Sunny: Could you explain what this kernel.

Michael: So the signature I was talking about earlier, there’s a few things but most importantly is that signature that proves the value and that becomes part of a sum. So if I need to sum up all of the kernels in the blockchain, I’m basically summing up everything that’s ever happened, and so long as it equals 0 it doesn’t matter how many there were or where they came from, then I know the change is valid at that point. And that all has to be contained within the kernel which unfortunately we haven’t found a way to to get rid of at this point.

Sunny: I see and so one question here is, I’m sure you guys have heard of a project called Coda which is they use what they call  recursive SNARKS to achieve actually somewhat very similar properties to what you’re achieving here. But the benefit here with SNARKS you can do more than just these like basic transactions, you can in theory essentially put any sort of computation into here including very complex smart contracts and whatnot, but it seems the con here is obviously they’re depending on somewhat more complex cryptography. And so how do you see the comparison between this Mimblewimble protocol and these code of recursive SNARKS?

Michael: Yeah Mimblewimble itself, you can see this was a positive or negative, but because it is so succinct, the cryptography that is used, it’s basically algebra on top of cryptography, and because it’s so succinct and so compact and kind of self-contained, it’s difficult to put any other stuff around it necessarily, so there are no scripts in there. But I mean we were talking earlier about this notion of script to script. So there are other mathematical tricks, a lot of them still theoretical that could be employed on top of this. So that’s kind of the main difference I think that it’s so succinct and so compact that it’s difficult to sometimes add more functionality to it or to think of how you’re going to add functionality to it.

Daniel: And also, as you pointed out, it relies on minimal security assumption, but the discrete logarithm problem is hard and that’s it. And you know, that’s very very important and makes it a big difference.

Michael: Yeah, absolutely. I mean Mimblewimble is zero knowledge all the way through, zero knowledge proof the all the way through.

Friederike: We did episode on Coda a couple of months ago. So if you’re interested listeners, go check that out. So how would you say Mimblewimble compares to Zcash or Monero or other privacy first chains?

Michael: From what perspective? From a technology perspective?

Friederike: Yeah, so from a functionality and technology perspective.

Michael: I mean, both of them touch upon thing we’ve talked about, and again I don’t want to be disparaging to any of these projects, this is purely a point of comparison and we have a lot of respect for Zcash and Monero in particular. So Zcash it’s based on the SNARKS we were talking about earlier. It’s completely a trusted setup. Mimblewimble itself, any coin is going to be completely zero knowledge. So there’s not like a key ceremony or anything to start it up, it’s all completely trustless. And the case of Monero, they have probably more privacy features than what’s in Mimblewimble at the moment, but a lot of that comes at an expense so they use ring signature, but the only kind of different methods that have evolved in scaling transactions are kind of on top of a Bitcoin like structure. So and again Mimblewimble itself is just a very compact concise way of doing it. So those would be kind of the main comparison points.

Daniel: I would also describe Monero as more kind of mature compared to what Grin is, but Grin is simpler. There’s a lot of more privacy features in Monero, but still Grin is simpler and achieves a lot with a minimal approach. With Zcash you have with fully shielded transactions better privacy properties, but as Michael was saying requires a trusted set up and also has this problem of shielded versus unshielded transactions. So you don’t have actually privacy on by default in the protocol itself, which is very different from Grin and that comes with its own kind of problems. I know that Zcash company and the foundation is actively working to improve that and have more and more transactions going through the shielded ones which are more computationally expensive than the unshielded ones, but that’s a big difference. And then we have governance approaches of these two projects which are generally different as well.

Sunny: So when you think of the effectiveness of a privacy solution, how I usually like to think of it is what is the privacy anonymity set here? Right? And so what do you do when you use Monero’s ring signatures, you’re basically choosing a couple of other transactions to mix in with and your anonymity set is only the size of a few transactions, like I think the default was about five or something and then the idea is as you keep making more transactions gets muddled, but in Zcash the anonymity set is the entire set of all other shielded transactions, right? So clearly the anonymity set of Zcash is much much larger than that of Monero. How would you describe the anonymity set of Mimblewimble?

Michael: Right. So ring signatures in particular. I believe those are used mostly to cover up the the transaction graph as in if someone is monitoring nodes and is watching transactions they can kind of start to piece together information about what’s happening there. And then that’s an ongoing challenge of, we always have discussions about that. Right now we have a protocol in place called Dandelion, which is an attempt to hide, not completely conceal but certainly make it more difficult for someone to follow a transaction graph, and that works by instead of just when a node gets a transaction it doesn’t just burst it to every node it knows about, it actually follows generally what we call a stem phase, sends it to one node which sends to another node to another node and eventually, randomly one of them will then do the fluff phase which is broadcast to all of the peers it knows.

Daniel: In terms of the anonymity set, in Ethereum, because you’re dealing with Mimblewimble when will you support non-interactive coin joins, assuming that you can aggregate all the transactions but basically in a block or send out to an aggregated transaction, broadcast that out to the chain as well so there’s a lot of opportunities to improve that anonymity set as it goes out.

Michael: Yeah, I mean if you look at the blockchain, just looking at the contents of the chain of the UTXO set, you can get absolutely nothing from it. There is no way to get anything from it. And the points of the system and the anonymity set is very much based around how easy is it for someone to construct the transaction graph and reconstruct what happened and it’s something that we’re continually working on through research into various technologies and additions to what we’re doing.

Sunny: Once transactions have made it onto the chain, it’s essentially a coin join amongst all transactions that have happened and so it does kind of give you a very very large anonymity set, but it doesn’t solve the problem of observing the peer-to-peer network and anyone who’s trying to break privacy will definitely be doing that and I know companies have done this in the past like Chainalysis and whatnot. And so that’s where this Dandelion comes in and Dandelion is sort of this like privacy feature in Grin that is actually completely independent of Mimblewimble, it’s like a separate privacy feature. And so you described a little bit about this fluff thing, but can you describe it a little bit further.From my understanding you can kind of think of it as this mixed net kind of thing for transactions. Im I having the right mental model here?

Michael: I mean Dandelion itself, there’s a few things happening, Dandelion and Mimblewimble are very complementary technologies, because in order to perform this coin join type aggregation that we’ve been talking about, it needs to be done in one way and one way only before his the chain because you could have problems if all nodes everywhere are putting together transactions and lumping them together in different ways, and then you can end up with issues when they try to get reconciled. Now with Dandelion, because there’s a distinct phase where the transaction is being sent from one node to the next node to another node one at a time along the stem, as I was calling it, that gives us an opportunity to apply this coin join to transaction as we go along, so as a transaction goes through the stem phase it gets aggregated with other transactions as it goes along, until finally it gets to some random point where it says right no more aggregation and then explode, and then all of its peers know about it and it gets propagated that way.

Daniel: So basically when every node has something to broadcast it broadcast sit out to everybody connected to the network. And here the purpose of Dandelion is basically to do that but it’s just not you who does that kind of explosion, instead pass the transaction that you have through one of two directions and then there’s basically a coin flip for every node, whether they’re gonna spread it out or just pass it along to a single node, that makes it much harder for somebody who’s monitoring the entire network to figure out where that transaction originated from in the network, because just because it gets broadcasted out from a node, doesn’t mean that the transaction belongs to that node.

Sunny: Okay, so maybe we can walk through how this Dandelion process works. So what will essentially happen here is let’s say we have this large network and I’m the one who’s creating this transaction. I’ll go ahead and send it maybe to Michael, Michael you’ll send it to Daniel and then Daniel has this seed thing that tells him when it’s time to propagate it. And so he’ll be the one to push it to the rest of the network. But where is this aggregation happening? Is it that let’s say if it just so happens that two stems of a Dandelion intersect, then whoever had that intersection of two of the stems, they’ll like be the one who’s locally aggregating it.

Daniel: Yeah, so at every epoch there will be a couple of nodes that will be fluffing nodes and a lot of transaction are going to end up at those fluffing nodes. And at that point they get aggregated before they get fluffed up.

Sunny: Okay, so there is some mechanism, so the path of the stem isn’t just completely random to the peer-to-peer network. They are kind of moving towards some aggregator nodes who will do the aggregation there….

Daniel: But it changes after every epoch it kind of resets and everybody cannot do new connections, at least that’s how it’s done in Dandelion++ which I think we have a simpler version implemented in in Grin today. It’s like the original Dandelion paper and I think it’s version 1.1. I think it’s gonna come out in that approach.

Sunny: How are these nodes chosen exactly?

Michael: They’re chosen at random amongst themselves, there’s a coin flip on each side. Am I going to fluff it or I’m going to pass it along this time. And that’s just in the current simpler version, but I think the reason that there’s a 1.1 of this coming out is because it reduces the chances for any aggregation to happen. So for aggregation to happen, you need a transaction to come into one node and then to be stem through another node that has some other transactions in it, right? So what Daniel just described for Dandelion++ is a way of ensuring that more aggregation happens in the Dandelion network.

Friederike: So what happens if there’s not a lot of usage on the network and there are not enough transactions to actually compound.

Michael: Yeah, if there’s not a lot usage then transactions don’t `get aggregated. I mean it’s early days for the chain so you’ll see a lot of blocks there with one transaction and there were two transactions, one plus the coinbase. So yeah, I mean the more users there are on the network the more transactions that are going around the greater the chances of there being aggregation. So it is definitely related to the the amount of usage on the network.

Daniel: That’s also why we’re building it. I mean, we’re not building it for low usage and see what we go. We don’t really have any interest in doing that. There’s nobody better off for doing that, instead everybody’s working towards this idea that this is going to be a big well used protocol. That’s the assumption.

Friederike: Sure, so as you just briefly mentioned, Grin actually launched in January, so it is actually the implementation of Mimblewimble that both are both of you are working on and we kind of skipped over this a little bit. There’s also another implementation named BEAM. Can you tell us how BEAM and Grin actually differ from each other?

Daniel: Grin was launched in October 2016 I think, and BEAM is a second Mimblewimble implementation that was announced I think in May or June something 2018 and they take a different approach governance structure, organizational, there is a development company building that, does it in different language ,has adopted some of the approaches that we do with Grin, but they are on their own separate path, it’s not like a fork or anything. It’s their own separate project. And we in general, of course it’s going to be many different Mimblewimble implementations, if anybody wants to put one together, so I think that’s that’s it but it’s a very different structure in terms of how how they are organized and what their approach is to some of the things.

Sunny: So what is the relationship between the teams, is there a lot of information sharing. Because I know for example the Grin team is the one who kind of came up with this idea of Dandelion and so BEAM kind of adopted it, but I know there’s also some interesting innovation happening from the BEAM side where I was reading some of their documentation and they have a mechanism of these kernels we were talking about that are being left in the chain, they have a method of pruning those out and incentivizing the pruning of those. They also have this like bulletin board thing that they were talking about where it helps with this interactivity needed. So what is the kind of the communication between these teams and any plans to port over some of their features back into Grin?

Daniel: Right. So just to point out that Dandelion is not our invention. It’s Giulia Fanti and some other researchers that have put together that protocol and yeah, in general the Grin project interacts with any team or any individual researchers that want to interact and want to share knowledge in like an earnest way, we do have communication with the BEAM  team as well. They donated to our fund. We have a good relationship with them. Generally though, what Grin is focused on is to do this very minimal implementation that doesn’t have a lot of overhead and keeping things simple and we’re definitely open for influences and new ideas when they come out and when they do we evaluate them, we vet them and then if they’re good we adopt them.

Sunny: Any thoughts on some of the ones that they’ve already started on like this bulletin board or the kernel fusion and stuff.

Michael: Maybe the fundamental difference here I think is that Grin has adopted a community approach to to a lot of things. So for instance, like the bulletin board that you just talked about is basically it’s a way of dealing with the interaction problem that we were talking about earlier. How do people interact? How does it work if someone’s not available? How do you send funds to somebody without them being around or online to perform the transaction? And BEAM has a prescriptive approach to this, you built a bulletin board and you do transactions here and this is the solution. Grin’s approach is to leave that up to the community and other authors. So for instance for that particular problem, our approach is to provide a very decent set of wallet tools to do the fundamentals of building transactions and putting wallets together, and then let the community come up with different ways of handling solutions to these problems according to different needs, you know, some people might only want to meet in dark alleys with bits of paper and that’s how they want to do their transactions. And that’s fine we can support that. Other people might want to come along and build some solutions on top of that, like there’s an open source project called Wallet 713 that has another solution built on top of that. Each time you build a solution like this on top of Mimblewimble, you’re also actually lessening the security and confidentiality a bit as well. So that has to be taken into consideration. So I think a fundamental approach is community, we’re trusting the community to take Grin as the core layer and then build custom solutions or whatever suits various groups on top of that.

Daniel: Yeah, and I mean it’s exactly as Michael says and I mean that’s the beauty of it because it’s not prescriptive and it lets basically the community figure it out and try different approaches and see what is the one that’s going to get traction and usage. I’m for full disclosure. I’m involved in the wallets and the Grin box transaction protocol that we’re doing and the reason why we did it was because we saw a need for it, an opportunity to do it that would make sense and add some value. So we do that and as a result, there’s another team now building on top of Grin and I think if you take like a macro view on it, it has to be many different development teams trying to solve specific problems that they have, make things better in the usage of a chain rather than this reliance on a single entry point, a single central kind of company or whatever organization it would be. I don’t think that’s a scalable approach because you need to let many attempts to solve the same problem and see which one works basically. It’s like the bazaar versus cathedral discussion writing software development.

Sunny: So we talked a lot about Mimblewimble and this Dandelion stuff, but I know another area that the Grin team has been kind of like developing heavily is innovating on this like proof-of-work algorithm as well as experimenting with new issuance models and inflation models. And so, I know you guys are using this proof-of-work algorithm called Cuckoo Cycle and it kind of started with this desire to try to create like an ASIC-resistant algorithm, but then over time it seems that the goals of this hash proof-of-work algorithm design have changed heavily and now there’s this complex two system version, can you kind of explain what’s going on here.

Daniel: Sure. So a high level kind of summary, there’s like a family of proof-of-work algorithms created by John Trump called the cuckoo cycle family, which basically the algorithm, the whole objective is you have this bunch of nodes connections between different units in a hash table, the cuckoo hash table, and the objective is basically to find a loop that connects 42 nodes and that’s a solution for your proof of work. And as a description of what we do today, we have basically two proof of works, one is the ASIC resistant algorithm, which is kind of optimized towards GPUs, and the other one is an ASIC targeted algorithm, which is optimized towards ASIC development. And when we launched the balance between these two proof-of-work was that 90% of mining rewards was going to the GPU and 10% of mining rewards are going to the ASIC tuned algorithm. Over time in the course of two years, this balance is going to shift completely so that a hundred percent of mining rewards are going to ASIC tuned. So in two years time the idea is that everybody’s going to be mining on the ASIC tuned algorithm. Originally, as you pointed out, there was one proof-of-work, Cuckoo Cycle, and when John initially revealed the proof of work algorithm, it was believed that you could mine efficiently or competitively using a mobile phone. But over time optimizations were discovered that basically meant that CPU mining was ruled out as efficient and it was a big advantage for ASIC miners, there was a lot of opportunities to build efficient ASIC miners using the Cuckoo Cycle algorithm. Now, the reason why we moved away from from a single proof of work into two proof of works was that this algorithm was known and it was available widely known before we launched the coin, and we had received several very credible indications that ASICs were being built for this algorithm which would at day one of the launch of the coin completely taken over the hash power and kind of centralized entire mining, which we didn’t really want. We don’t even think that was a good idea. We do however see that because time doesn’t stand still and what we’ve learned since, you know, John first published that algorithm and since the beginning of Grin, is that ASIC is inevitable and there will always be a way to kind of do optimizations, and even if you’re not going to optimize on the ASICs, you’re going to be able to optimize. So the guy mining with a GPU at home is not going to be as efficient as as the person who’s connected to a dam in China and has 10,000 GPUs. So there’s going to be a lot of efficiencies and that’s inevitable. However, trying to launch a coin in a fair manner in 2019 puts a couple of problems to that. So you need to have a way to basically bootstrap the network in a way that gives people some chance to mine fairly to the point where over time you can gradually shift over to this ASIC friendly algorithm and give ASIC manufacturers enough leeway and enough time to prepare for that and have multiple ASIC manufacturers maybe build at the same time in order to create as competitive of a marketplace as possible for these for these ASICs. It was very kind of long answer but that’s my view on it, Michael if you have anything to add.

Michael: The thing is that ASICs are going to happen anyways, you can try and avoid it you can try and design an algorithm that can’t be done. It won’t happen. They’re going to happen at some point. So the best thing you can do is try and make it as fair for everybody and try and actually make your algorithm simple to specify for ASIC manufacturers to allow a market. I mean ASICs themselves aren’t necessarily evil. They’re actually, the closer you get to, again we’re back to Andrew Poelstra called it the thermodynamic limit, if you had a machine that was absolutely the most optimized it possibly could be for proof-of-work algorithm and everyone has one of those machines, then that’s actually the best case for mining there is, so by encouraging ASIC development and hopefully there will be a few options to choose from That’ll be readily available, this should actually help secure the network. I lost my point there. ASICs themselves aren’t evil, it’s when they’re all under control of a single entity or a single corporation, then that’s a centralization pressure. So by trying to encourage as many hardware developers you can to develop ASICs then we’re hoping for a more fair market.

Friederike: So you went with the two proof of work systems in order to ensure continuous decentralization throughout the life of Grin, but there are disadvantages that come with proof of work. And this is why many people are talking about switching to proof of stake for many different chains. Is this something that is in a concern for you as Grin developers as well. Or are you firmly committed to proof-of-work?

Michael: No we’re very firmly committed to proof of work at the moment. Nobody has proven that proof of stake will secure a network as well as proof of work. Nobody has proven that you know, it is entirely fair, like it it very much rewards people who already have a stake, hence proof of stake in it. So no the Grin team at the moment is very much proof of work only.

Sunny: Yeah, as someone who’s been working on proof of stake for two years now I actually completely agree with you. I don’t think there’s been any evidence that proof of stake can properly secure network. And especially it seems that, I’ve heard the story where I was like Grin seems to be the next best bet at money other than Bitcoin and if you want to create decentralized money, you know, you need to have had a similar origin story and anonymous founder and so I just don’t think proof of stake works properly as an issuance mechanism.

Daniel: Who knows what will be in 10 years time, the community in general is open to any new technology as long as it makes sense. And at this stage proof of stake doesn’t make sense, as you correctly pointed out as well we couldn’t have launched with proof of stake because it creates huge problems of how you distribute the coins fairly, and at that point in terms of actually initial distribution of coins, as far as I know I haven’t heard of any better ways to do it fairly than proof of work.

Sunny: So speaking of this like initial distribution and issuance, so I guess two part question here – one is this issuance mechanism, you guys have an experiment, a new monetary policy, that the only other coin I’ve seen this like similar monetary policy and is Dogecoin, but essentially this idea of unlimited supply but constant issuance, so you have this fun little time is money meme going on where it’s like one one grin per second or 60 grin per minute  until the end of time, so like there’s no fixed cap like there is in like Bitcoin or Litecoin or any of these other money currencies that are trying to become base money for example, and so who made that decision of trying this new policy?

Michael: I think it’s something that the team arrived at actually fairly early on in development when we were talking about various models and schedules of how to do this. I think most importantly, okay a few things, now this is a big can of worms and you get all sorts of hate mail any time you you start talking about this. The model that came up originally by Satoshi in Bitcoin, as in there were going to be a fixed number of Bitcoins, it’s going to be an entirely deflationary system, that’s great and all, but there seems to be a widely held belief out there that this was handed down to him on a tablet from God at some point and this is the way it should be for all time. There’s a lot of problems with that approach and everybody’s seen this with the hyper deflation that you see in Bitcoin. Now, you know, the paper said it was supposed to be a digital cash and it’s turned into a store of value and that’s the story now, so that approach is quite problematic. The other thing is nobody yet knows whether a fee market on its own is going to be enough to secure a network when the fees from Bitcoin become too low. So we think that the approach we’ve taken which is just a constant block commission, 60 grins per block once a minute forever, and by the way this is actually quite conservative as far as putting a currency out there. I mean the inflation rate becomes 0, 30 years on, imagine if you could only print 60 US dollars a minute, you’d have hyper deflation. This is actually a rather conservative approach and it is new in the cryptocurrency world. I don’t think it’s that radical. I think it’s easy to understand. I think it will help secure the network when fees run out, it will help people to use Grin as as money as opposed to hoarding it because they’re afraid is gonna be worth far more tomorrow. So yeah, can’t speak for the entire team but that’s basically where we stand on it at this point.

Daniel: And ultimately it’s very simple right. It’s very easy to explain, very easy to understand, I haven’t seen a lot of arguments well constructed as to why it is a problem. And since it is a very simple structure, we like it. It’s elegant.

Sunny: Right. Yeah, you know, I think this whole time is money meme, I think actually it will work. I think it’s easy to explain, and it’ll be very interesting to see how this fair start plays out, I think the last time we saw something similar to a fair start but clearly not as fair was the Zcash start and even that was, they the whole developer side of things, but I remember my ex-roommate she was really hyped about the Grin mining and I know there was, I heard a crazy figures about like VCs putting hundreds of millions of dollars or something into, I don’t know if that much, but crazy amounts of money into mining ventures very early on in Grin when it started with zero supply, so it’ll be very interesting to see how this new fair start and issuance mechanism works out. So now that we’re kind of drawing towards the close of the episode, I just want to talk maybe ask one or two questions about the future of Grin and what the future roadmap is and whatnot. And so one of the questions that often comes up about Grin is that in order to make this Mimblewimble feature work, we had to remove Bitcoin script because it doesn’t work with aggregation, and so does this mean that it’s possible to do multisigs on Grin? Will it be possible to do HTLCs, atomic swaps, is any of this possible on the roadmap?

Michael: Absolutely, as a matter of fact atomic swaps with both Ethereum and Bitcoin have been done before. Multisig is definitely possible. We know how to do it, it’s just I don’t think it’s been implemented in the code, but we certainly have the foundation in there to do that. Other stuff, you know, smart contracts, we’ve talked about script a bit, those are essentially ways of enforcing the usual conditions you’d be enforcing in a contract without having to have a contract in particular in place. So yeah, they’re definitely possible. I won’t say we have the answers to all of them at this point. There’s certainly a lot of research outstanding and if you look through our site and what we have there, you know, there’s a there’s a list there of technologies that we’re looking into and researching how to do this. And yeah, that’s basically the future, I mean the future for us will be, building the tool to support community building on top of Grin and on top of Mimblewimble, as well as slow and steady research as to other technologies. Again like Atomic swaps, script some Lightning like network on top of that. So yeah, that’s very briefly what our future looks like.

Sunny: And so back to that question about the fair start, so the Zcash team with their fair start, they funded themselves by giving themselves a developer cut of all the block awards. Satoshi funded his fair start by mining like crazy when Bitcoin first came out and because it just wasn’t very popular. But like I said, lots of outside money was poured into Grin mining from very early on and so what is the funding model here now for the Grin developers, how is this going to be sustainable?

Daniel: So Grin is a hundred percent community-funded. Michael is funded through donations. There is a debt fund and a security audit fund that raises donations for for specific purposes, but it relies a hundred percent on donations from the community and from miners and other companies active in the space to contribute and I think you touched upon a very important thing there that yeah, what is fair? And what is what is a fair launch and I think Grin has probably been one of the more fairest launches that has been around simply because of the fact that it’s had a lot of attention, a lot of eyeballs on it, from day one, which a lot of other projects really didn’t have, including Bitcoin early on. And equal opportunity doesn’t mean equal outcome. And we welcome anybody to come and mine, whether they’re VCs or not or whether their users, we welcome anybody to come and participate in the project, and that’s the strength I think. It’s the reason why I got involved a year ago ,because it’s very easy to participate, it’s is very easy to become active in the community when there’s nobody else having an advantage of you, earning more money or something because of your contribution. Anybody who’s here and wants to contribute is actually just doing that because they believe in the project and they want to do so, and that makes it very easy for new people to come in and get involved. It becomes also a self-selection exercise. I noticed we have a great community and I think part of it is because there’s no get-rich-quick scheme here and we don’t have to pay people to do work, it takes care of itself. And ultimately as well, some people ask, you know, there’s always these kind of questions. Is it the right way? Is it sustainable? Will it last and so on. Well it’s completely up to the community right? If nobody wants to fund us, then maybe there will be fewer developers and less development going on. If nobody cares about that, but I guess it wasn’t very popular in the first place, but if people do care about that and they want to actually take Grin forward then anybody can participate and do that. So it’s like a it’s like a non-issue for me in a way.

Friederike: So I can see how this story right now is super appealing. No one actually makes huge amounts of monies building businesses on Grin, but once they’re actually active, people who actively benefit from the Grin network and build businesses on it, do you think the volunteers will still be there to actually build the infrastructure where they feel exploited and will this turn into a tragedy in the current situation?

Daniel: I don’t know. I think I think it depends on the businesses, how they act in the community, how they operate. If I was starting a business, the stuff we’re doing, if you’re a business and you make money off Grin, it’s kind of in your interest to contribute to the fund. Because it’s your protocol that you’re making money from so it makes sense for you to ensure that somebody’s looking after the protocol and so for what we’re seeing is that exchanges, mining pools, proof-of-work mining software providers, are contributing and they’re making contributions. I can’t say whether it’s going to be enough or not. It’s very early days. We’ll see about that. But you know, it really is up to everybody involved to actually contribute, and I’m not too worried about it and just because there are companies there that make money, rightly so they should be doing that if they’re offering value to the community, that shouldn’t preclude a community member to contribute if they want to in their spare time on something else, some other corner of the protocol, but the difference is I guess with other setups is that if we for example as developers were taking twenty percent tax on all coins that are mined, that creates a very weird relationship between us and the rest of the community because also suddenly we have a stake in improving the value of the coin which is not necessarily what is in the interest of the community, right? Suddenly if we get twenty percent of all the coins, then it’s really in our interest to just raise the prices of coin all the time and kind of focus on that. Whereas maybe what we should be looking at is adoption or getting more users using the coin. That doesn’t necessarily drive up the price of the coin though. It kind of has like a weird incentive alignment.

Friederike: Yeah. I agree that it’s really difficult to find motives that align incentives well, but saying you trust in the good in companies, to me that that seems a little naive I mean if you look at the off chain wide for instance, Apple massively builds on public infrastructure and Apple can only exist because there are structures that preceded it like the judicial system and the road infrastructure and the internet and Apple chooses to not pay tax. So basically this is like major corporations have ways of circumventing paying tax. And in principle they’re liable to pay tax, but somehow they still end up paying very little or close to no taxes, right?

Daniel: I mean, I can’t comment on that and I can’t comment on whether Apple pays a lot of tax or not. But I guess the point is that generally speaking the whole purpose is Grin as a project was to be very minimal on the like the top layer protocol. n order for that to kind of make sense, intuitively it means that other entities underneath need to step up to the plate and deliver products and services to facilitate that because it’s very minimal on the top layer. Because it’s very minimal on the top layer it shouldn’t be needing twenty percent of all the coins of the mine to sustain itself. That’s the whole idea of it.

Friederike: I appreciate the idea and I think it’s super idealistic and I really hope it works. So I’m not holding against you, I’m just asking whether….

Daniel: As I tell companies, because companies that approach us and say hey we want to get involved, we want to do this want to do that, how can we get more involved in Grin? And I say if you contribute to the community dev fund , it’s the greatest way to create goodwill and add marketing for your company in the community, by just making active contributions. And of course companies can choose not to do that. But I mean that stands for themselves and I understand that you might think it sounds idealistic or naive, but I actually don’t think there’s a better way to do this. I don’t think it’s better to establish a dev tax or something. I don’t think that’s gonna lead to longer term success for Grin and what its long-term objectives are.

Michael: If you start off with a dev tax and that’s how you’re going to fund, then you will always be paying developers to work on the chain for those reasons. Like why am I going to put my time into something to have someone else profit off the end of it. I know it kind of sounds a bit naive and I’ve seen criticism on the internet saying it’s not going to work because you need to pay developers, but it’s been around for two years now and the interest is still growing. Personally I’ve been funded for the past year and I’m funded again for the next six or seven months to work on it full-time, on a regular developer salary, and this is early days, before the chain was even launched and people had their businesses that they were going to build on top of Grin, so I think the early signs are encouraging anyhow.

Daniel: Take what we’re seeing with exchanges as an example, right? We welcome and encourage all exchanges to list us that want to and if they have questions we’ll help them and so on, but we’re not really chasing exchanges. We’re not applying for exchanges. We’re not filling out any documents. There’s no legal entity. Nobody can give any money for listing fees or anything to exchanges because we’re broke. We don’t have any money, right? So instead of changes list us without us asking and without any preconditions. But if we had a pot of gold that we were sitting on, which was like equating to a chunk of the total coins mined, then I think this story would have been very different.

Friederike: Yeah, certainly there have been open source projects that have been going on for tens of years and they’re still it around. So I’m interested to see what the future holds for you guys. Thank you for coming on.

Michael: Thank you for having us.

Daniel: Thank you very much.