Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Daniel Lehnberg & Michael Cordner: Grin – Cypherpunk Mimblewimble

Episode Date: March 12, 2019

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 covered 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 Episode links: MimbleWimble Origin Andrew Poelstra's Improved Paper Introduction to Grin Grin for Bitcoiners Grin Newsletter Michael Cordner on Twitter Daniel Lehnberg on Twitter Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Friederike Ernst and Sunny Aggarwal. Show notes and listening options: epicenter.tv/278

This episode of Epicenter is brought you by Microsoft Azure. Configure and deploy a consortium blockchain network in just a few clicks with pre-built configurations and enterprise-grade infrastructure. Spend less time on blockchain scaffolding and more time building your application. To learn more, visit aka.m.s.m.S.L.C. Welcome on Epicenter, episode 278, with Michael Kordner and Daniel Lamberg, two co-developers from the great implementation of the Wimble Wimble Protocol. I am Federica Ernst.

And my name is Sunnyaga Rawl. And so like Frederick here mentioned today, we have two of the developers from Grin. You know, I kind of, the Grin is this very interesting project that has a very interesting backstory that we'll get into today. And, you know, I kind of heard about them very early on in their, you know, creation with the Mimble Wimble Protocol first came out and kind of ignored it for a while. And then in the last couple months, like, you know, it just suddenly gained a lot of adoption. They launched very recently just last month in January.

They're one of like, I think, probably the few projects who've announced a launch date and actually met their launch deadlines, which is, you know, very cool. And just, you know, one disclaimer is I am currently actively mining grin. So just a little bit of a disclaimer there. Let's jump into the episode. Today on Epicenter, we have on with us. Michael Cordner and Daniel Landberg, two of the core developers of the Grin blockchain, which implements this very interesting protocol called Mimble Wimble.

And so, you know, throughout Epicenter, you know, we've briefly touched on Mimble Wimble here and there. A lot of like, you know, we've had Adam Back on before and Greg Maxwell. And they've like slightly touched on Mimble Wimble, mentioned it in passing as like, you know, future scaling options. But, you know, we never really got a chance to fully deep dive in. to mimble-wimble. And it's just very interesting protocol where like, you know, offers a lot of like, you know,

in a ways it's very similar to like the Bitcoin protocol, like uses a lot of the same propography and a lot of like the same intellectual basis, but, you know, brings a lot of these really cool features and, you know, it has this really cool backstory to it, which, you know, we'll cover it throughout the course of this episode. But, you know, before we get started, but, you know, before we jump into that, uh, Michael and Daniel, thank you guys both for being on. And, you know, Michael, maybe you can introduce yourself how you got started into the space, like, you know, before even getting into Grin and Mimble Wimble, and then Daniel, maybe you could do the same. Yeah, sure. Okay, well, thanks for having us.

Well, I just start. So my name is Michael Cordenor, and I go by the named East Plum 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 was, I mean, I have about 20 years' worth of kind of overall software development experience ranging from financial to games to kind of, to educational software. So I think kind of a good broad background there.

Immediately previous to working on Grin, I was doing kind of 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 our hardware wallets and what have you. So, yeah, so that's basically my background and why I'm here today. Cool. And how did you get, you know, get started with Bitcoin?

is like green sort of like the first blockchain project you've worked on? 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 kind of more of a got better at applied cryptography through previous jobs

and then the more kind of cryptocurrencies tended to appeal to me because I realize it kind of pushes all my buttons when it comes to interest. So technical interest rather. I see. Very cool. And Daniel, yeah, what about you? How did you get involved? 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, read the Gidditchats 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 way the ethos of the project was, and 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. That's interesting. So most of the Grand Developers are actually anonymous, right? But you guys are here on the show using your clear names. You also go to conferences with your clear names. What made you decide to go public with your identities? 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 Ignosis, the founder, which I'm sure we'll talk about him more later. And then we have another developer, Antioch Peverell, which in Harry Potter, Lor is his brother, who also chooses to remain anonymous. But the rest of us are fairly out and in the open. I mean, from my own perspective, I probably just didn't know any better when I first got involved with the project. So that's why I'm out in the open. But also because I'm taking funding from various sources, I feel. a bit, it's better to be out there so people know who they're dealing with and, you know,

I can be out there on a podcast and promote Grin without having to worry about that invisibility cloak. Yeah, it's similar from my side. I mean, I was aware there were anonymous developers on the project, but I just kind of did like a trade-off in the sense that, you know, 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, you know, the full way or you don't do it at all, there's no point in it because if somebody needs to, or wants, is motivated enough to find your identity, they will. And I just didn't really see my, 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

Ignatius is anonymous. It might have been a bit different if it wasn't for that. So you mean like over time, some of the core developers who maybe were not, earlier, I have slowly started, like, revealing their identities over time? No, I mean, what I mean is, I mean, 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, if you see what I mean. Oh, interesting. Okay. Everyone except for the people 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 sync 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. It's interesting that it's so different to the public perception that a lot of the developers are actually anonymous but that's probably just because the founder himself

or herself is anonymous. So yeah. Yeah, that's right. Yeah. Cool. So, you know, let's maybe let's jump into a little bit of this founding story then. And so, you know, I think there's, I, you know, I remember I was teaching a class on Bitcoin back in like 2015 or something. And I think that's around the time, you know, we, when this, we were teaching this class, we heard about this like, oh, there's this new proposal that's been around that was just like posted on like, you know, I first saw it on our slash Bitcoin. But, you know, can you. 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. Sure. I see me. He's a plum is amused. So I'll do that. So basically there was this IRC thread, IRC group for Bitcoin developers. It was what's it called, Bitcoin Wizards, right? I think an anonymous person basically came in there and dropped a paper that outlined kind of the sketched out the kind of the basic concept of Mimbo Wimbo,

which was then picked up by Andrew Polstra, and I think Brian Bishop as well, and they kind of had some interactions there, and Rupolster, Andrew Poster formalized some of the concepts in there into a paper, and took it from there. Right, because from what I remember, like, you know, the original document wasn't even like,

you know, it was like literally just a text, a dot TXT file that was just dropped in there and it had like, it looked like, you know, some quick thoughts on, like what this guy was thinking and like some ideas and um also you know for the listeners one of the you know one of the cute little story things there is like it was signed like the anonymous person they signed them themselves using the name tom elvis jadosaur which is like uh you know the french name of Voldemort like in the english versions it's tom marvelo riddle um so it's the french

alias um so yeah do you guys have any like you know guesses as to who it may have been like you know I've heard like, you know, clearly in the text file, a lot of these ideas were heavily derived from like Greg Maxwell's previous works, like coin join and confidential transactions. So, you know, I've heard Greg, I've heard it positive that, you know, it may have to spend Greg himself or do you guys have any like theories on who this was or is it not even like of interest to you and you actually don't even care to find out? I don't, I don't personally have any theories on it. it would be interesting. As you just said there, I think that's kind of key. There were a lot of, the Mimble Wimble Paper, it builds upon a lot of ideas that were already there and kind of developed by established cryptographers.

The actual kind of portion of it that makes up Mimble Wimble is just kind of a small insight slash 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 clash 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 isn't. Even if whoever it is makes themselves known, no one's probably no one will believe them at this point. So I think we just have to leave it as a mythical creation story at this point. Right.

There's like no cryptographic signature or anything all over the file. So there's not even any way to know. Like no one could even prove it at this point anyways. Just a text file. And so what was Andrew Polstra's contribution here? So, you know, I remember, so this file was this positive and then, like, you know, what was the original kind of response to this? Where did people like immediately realize that, oh, there's like something big here or was it more of like people like, oh, okay, another proposal? And Andrew Polshaw was like, did it take time for him to realize that, oh, there's actually something like, you know, much more insightful in this document here?

It took, I mean, I wasn't around in the early days, but from what I can see, um, and Andrew Polstra had to look over it just to make sure that it was sound. I think there was a mistake or two in there that he eventually corrected. And, I mean, he was interested enough from that to write a further white paper on how an entire Mimble-Wimble blockchain would work. And, I mean, he published a further kind of a proper white paper based on that, which is a little bit outdated at this point. And then he had some other kind of additions to it,

that you may have seen some presentations at his about. about how to do some additions to it script-less-script. Because there's no scripts in Nimble Wimble, 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 Nimble Wimble, 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, I mean, he hangs around, if we need to get a hold of them to ask them any questions, questions and he's there, but he hasn't been too, too active now. We're at say about the past year, either just busy or working on other things at this point. So, yeah.

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 flesh proposal. What would you say helped for this to happen? I mean, do you think this is just a lucky break for Mimble Wimble? 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?

And, you know, how do you think about this? 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, you know, serious people in the industry. So I do genuinely think that this, it's not just a matter of getting lucky or being filtered somehow. It was genuinely a very, very, you know, transformative insight on what was already there. So, yeah, like I say, we've seen plenty of papers go.

There was actually another paper put down by someone claiming to be the same Voldemort in a similar style that was dropped maybe about six months ago. And that was looked at and completely trashed by the community. is going to know this makes absolutely no sense that this and you know to the point of this is probably not the same the same Voldemort or if it was he got lucky that one time so 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 presented in the crypto space it will get considered generally yeah and I think he was I mean the original text file was you know far from perfect as you said it had some errors in it as well but

it was actually presented very succinctly and and very important approachable way, which also helps, of course, because it makes it easy for anybody who's reviewing it to understand whether there's some merits to these arguments or not. Because it was building on already established concepts that were already popular in the space, that also made it much easier. So how did it continue on from there? So how fast did this proposal that was then transformed by Andrew Poistrar? How fast did it pick up seam? How fast did developers actually come on board? well the first i mean andrew wrote the paper and i think it was kind of not quite forgotten about but you know put aside for a couple of months it was only when um when now ignote someone by the

name of ignotius pevere who was the founder of the project um appeared again in the same channel i think it was around around december of 2016 roughly i think i think even october i think if i remember quentin's presentation so it was quite fast yeah yeah yeah And then he said, I've actually started an open source version of this and uploaded the code and invited everyone to take a look. And I think it's clear kind of from the early conversations that there was a, it was almost obviously apparent that this ignosis, Peverell person knew what he was doing and, you know, had put up, was starting a really serious effort to put together a Mimble Wimble blockchain. And then I think, I think also there was, yeah, a few months later towards December, the Mimble Wimble mailing list. was established, which probably also helped a lot in kind of taking the project forward.

There was a lot of discussion going on with a lot of noteworthy and kind of well-known people in the field contributing. It's also kind of helped raise the awareness of the project itself. This episode of Epicenter is brought to you by Microsoft and the Azure Blockchain Workbench. Getting your blockchain from the whiteboard to production can be a big undertaking. And something as simple as connecting your blockchain to IoT devices or existing ERP systems is a project in itself. Well, the folks at Microsoft had you covered. You already know about the Azure blockchain workbench and how easy it makes bootstrapping your blockchain

network pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTTTT for blockchains. Suppose you want to collect data from someone in a remote location via SMS and half that data packaged in a transaction for your HyperLedger Fabric blockchain. The development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface. Here's another great example. Perhaps you're an institution working with Ethereum and rely on CSV files sent by email. One click in the Devkit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Devkit can read, transform, and act on the data. To learn more and to build your first

application in less than 30 minutes, visit aka.ms.m.s. And be sure to follow them on Twitter at MSFT blockchain. We'd like to thank Microsoft and Azure for their supportive epicenter. Maybe now we can kind of start talking a little bit about like, so we keep saying this like mimble-wimble blockchain and this mimble-wimble protocol. But like, you know, what even is this mimble-wimble protocol? And so, you know, maybe we can start off with like, let's assume our listeners are, you know, relatively very familiar with the Bitcoin protocol.

How would you explain mimble-wimble to them and, you know, and kind of, you know, of explain what's going on here. Right. Okay. Well, I think it's rather than just kind of jumping into the mechanics of it, but we should say what the goals of it are. And that would be to provide what I call very good privacy intrinsic to the blockchain. So you know, some other coins that may have been originally derived from Bitcoin.

The privacy would kind of be bolted on in certain ways. So other coins like Minero would kind of have a few different ways. But the core of the chain itself would kind of be the classic Bitcoin chain, as in a ledger of transactions going back forever. With the Mimble Wimble protocol, you have the privacy built right into the core level. So if I put, if I perform a transaction, what ends up on the chain is basically it looks like random data. And this, 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 or on the

chain size, you end up getting the same privacy as other coins with a much greatly reduced storage-based requirements, as well as some other kind of nifty features that add onto it, all of which kind of add together to enhance privacy without kind of the bloke that you may get in some other chains. So that's kind of fundamentally what Nimble Wimble itself is about. So you see it as the primary benefit being the privacy side of things. Yes, absolutely. And I mean, it's built in. At the protocol level, it's not optional.

Interesting. Because I remember when I first heard about Mimble Wimble, I always actually usually, I heard about it in the context of, you know, scalability and like, you know, increasing the sync times of like of the chain. But then I feel like I only started actually hearing about like the privacy benefits like, you know,

later on. So it's interesting that like, you know, I guess I just obviously I haven't been as involved with it. So, you know, I guess I kind of heard, I didn't really hear about the privacy side of thing until much later on. It's definitely like it's a privacy point. It's a confidentiality point. And that would pretty much be the, from our perspective, at least the number one, the number one reason for it being. The scalability stuff is certainly nice to have. And it's something that, that we're, 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 the UTXO set, et cetera. We'll probably talk about some more technical details later on.

Yeah, and maybe it's good to kind of point out that, yeah, there's the Mimba Wimbo Protocol, which we talked about, which was kind of dropped on the IRC channel and everything, and then you have Grimm, which is an implementation of the Mimba Wimba 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 kind of really stand out in terms of implementation-wise from Green, 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 in its design as a blockchain in general to be very kind of light.

lightweight. And that kind of 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 adds to it, has like some nice properties to it. There's no, there's no addresses 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. So I see the privacy aspect is the main feature of Mimbo, but the scalability is also one further add-on that you, one further add-on benefit that you get. Could you briefly explain how it works on a technical level? Yeah, I mean, this is kind of, it is a bit difficult to do without whiteboards and a bit of time and dealing with confused stairs. but basically instead of how Bitcoin works is you have a ledger of transactions going back

to the beginning of to the Genesis block basically and you need to verify each and every transaction in order to start a new node. Mimble Wimble works a bit more mathematically. So rather than the ledger itself or having to validate the ledger itself, you just need to validate the sum of what's happened before. So when I put, maybe I can try and walk through a bit of transaction example. If I perform a transaction, right, 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 number of 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 prove, 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 zero, I can do that

without actually having to store the values or the amounts in there, right? So validators can just add this all together, check everything equals zero and move on. So that's fundamentally what happens on a nimbo-wimba blockchain. Does that make any sense? It does.

So I think it's actually really difficult to explain without whitewood, as you said. But what do you say it's fair to describe it as being cryptography that is well known and is also used for Bitcoin with additional elements for obfuscation? Yeah, absolutely. I mean, we basically used 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 Mimble Wimble. Okay, and so this resides in a blockchain where not only the transaction amounts are obfuscated, it's also obfuscated where they're coming from and where they're going. And that's, would you say that's factually correct? Yeah, it is correct. I mean, I wouldn't even say they're all these gated. They're just not there. Yeah. There's not. And also I should say, you know, that there's no, 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 UTXOs essentially on chain. Right. But it's very hard to derive making any sense of that. That's basically the only information that is on there.

So if there's no addresses, right? So, you know, how do signatures work in the system? Right. Well, a signature, it's a signature basically proves that I had that, that excess value that I was talking before. Because that's, that's what I use to sign the outputs that I put into a transaction. Right. So, I mean, the blockchain itself, it's kind of, it's 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've 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 will be able to use that to prove, you know, to witness the thing and to prove that I had the right to spend it. I see. So essentially what's going to happen here is like, you know, there are some excess validates. in this last transaction that was sent to me and I am the only one who has knowledge of it and I'm able and by revealing that, proving that knowledge of that I'm the only one is able to spend this. But how did this excess value get into the previous transaction? So, you know, how did, yeah, why is it in the outputs from the previous transaction if I did, like, didn't that mean that whoever sent me the coins had to have known that excess value? Right. No, they knew their access value. But when a transaction happens, I create a new one, which represents my thing. So what happens is someone sends me a bunch of inputs for a certain amount. And then I will create, and as well as the signature will contain their access value. And that gets sent to me. And what I do is I create my own excess value and create an output for that amount. Right. 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 how that's validated. Right. So one of the key features or differences here with the Mimble Wimble system is that in order to receive money, I have to actually like, you know, be part of the transaction making process, right? That's right. And the cryptographic trend.

Say that's an interactive transaction. And that's distinct. It doesn't mean you need to be online. It doesn't mean it doesn't have any of those connotations. It just means two parties need to interact, they need to exchange information somehow. And that can be on the internet via HTTP, it can be via sending files to each other, it can be via tin can on a string. It just has to happen somehow.

Does this have any implications for the user experience as opposed to, you know, when you compare it to sending, say, Bitcoins? Oh, yeah, tons of it. It's, you know, it's a very, very different experience. And so for good and bad as well, right? So it's just different, I would say. So as Michael said, there's a, you know, 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. Right? But that also means that in order for, you know, unlike, for example, Bitcoin, where you can just kind of 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 kind of 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 a bunch of transactions. Right. Some people actually may actually see this as a pro because I remember about a couple weeks ago. This is like YouTuber who I like kind of follow. His name is Tom Scott.

And he kind of got into an argument with Brendan Ike, who is working on, as you know, Brave or basic attention token. And he was kind of getting upset that in brave, in basic attention token. And so and really any most cryptocurrency today, Bitcoin, Ethereum, that people have the ability to send you money without your. like, you know, consent essentially and this could have like weird sort of legal or regulatory consequences. And so, you know, to some people, they might actually see this as a pro and like help the like adoption from like a legal perspective as well. Absolutely. And also from like, you know, from the from the point of like being a merchant, right? And you send, you know, instructions to your customer, how to pay you. It prevents a lot of user error as well. Because if the user does something

wrong, hopefully you'll detect that as part of building that transaction and you can reject those transactions rather than the user sending it to the wrong address, getting that process and then saying, hey, where's my money? Where's my stuff? And you have this kind of disconnect where you try to figure out what actually happened here. It's much easier to do that in an interactive protocol where the merchants can kind of sense check whether it's the correct behavior and this expected behavior from the customer. But it is also, like I should say, it's a different paradigm than like what's usually being done today in blockchains. So there is like a lot of kind of extra effort or thinking that goes into it from like merchant's perspective and also from users' perspective.

So it is a kind of a different approach that we're taking. Okay, so in Mimberwimble, wallet interact to create privacy-preserving interactions, how does it? us help with scalability? Right, there's a few things. I think most simply, in order to think if I'm a new node on the network, 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 seem to simply need to have enough of something 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 add up. So instead of, you know, if you sink a new Bitcoin No, 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 your sum or 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, like, the sync process is a few minutes. And that should, provided the header sync time kind of is fast enough,

the sync 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. There's other ones which are probably, they were mentioned in the paper, but they're probably in practice not quite as good for, or quite as bountiful, say, for scalability. One of them is the notion of cut through,

which is if I send a 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 off both sides of an equation. And yeah, Daniel may have something. Do you have anything to add as well? Yeah, I think you covered it.

But I wanted to point out that as part of that syncing process, this is not like a light client sync or anything like that, or SPV approach. it's actually like a full node sync and it gives you like proper security guarantees. And it's much faster than, you know, conventional approaches. Right. Yeah. I mean, so I've actually been, you know, dabbling around with like the grin nodes and like I've been trying to run a grin minor for the past like week or so. And so when I actually started, I opened up my grin node and it's like synced in a matter of like 30 seconds or so.

And not that like, you know, the grin blockchain has only been around for. a month anyway. So it's like it wouldn't have been that long anyways, but it kind of just blew me away that like, I'm like, whoa, did it actually just sink? Like, I'd probably mess something up. Like I need to try this again. Like it kind of blew my mind. Yeah. Again, it's early days for the blockchain, but it's even after a month, like it should take longer. If it were a traditional blockchain, it would be taking longer already. So right. Exactly. And so that really amaze me there. So with this cut through thing. So, you know, you're so you're saying we can, you know, kind of like to give some intuition for the listeners.

Essentially, what we can do here is once transactions have been spent, we can kind of like 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, and so does that mean it's constant, is there any like piece of data that has to stick around from the history? or does it all completely like 100% disappear? No, no, the transaction kernels need to stay around.

And that's probably the biggest point against scalability or something we'd very much like to see. There's no way to currently compress the kernels into, you know, and to sum them up basically that you can most other parts of the system. If you 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. Could you explain slightly what this could,

kernel is like right right so the signature i was talking about earlier um there's a few there's a few things and most importantly is that signature that proves the value and that's and that becomes part of a sum of a sum so if i i need to sum up all of the kernels in the blockchain i'm basically i'm basically summing up everything that's ever happened and so long as it equals zero it doesn't matter how many there were where they came from then i know the chain 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 to to get rid of at this point or some. I see.

And so that one question, another question here is, I'm sure you guys may have heard of a project called Coda, which is like they use sort of what they call a recursive snarks to achieve actually somewhat very similar properties to what you're achieving here. And so, but you know, the benefit here is with snarks, you kind of, you know, you can do more than just these like basic, transactions, you can kind of essentially, in theory, you know, you can essentially put any sort of computation into here, including like very complex smart contracts and whatnot. But, you know,

it seems the con here is, you know, obviously they're depending on somewhat more complex cryptography. And so what, how do you, how do you see the comparison between, uh, this Mimble Wimble protocol and these Koda recursive snarks? Yeah, Mimble Wimble itself, it's, it's, it's, it's, they, B can see this as a as a positive or a negative, but because it is so succinct, the cryptography that's used, it's basically algebra out top of cartography that there. And because it's so succinct and so kind of compact and kind of self-contained, it's difficult to kind of put any other stuff around it necessarily. So like there are no scripts in there.

But I mean, we were talking earlier about this notion of script-a-script. So there are ways, kind of 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.

And also, as you pointed out, it relies on minimal security assumption that the discrete logarithm problem is hard. And that's it. And that's very, very, very, important and makes it a big difference. Yeah, absolutely. I mean, I mean, Mimbo Wimble, it's zero knowledge all the way through. Zero knowledge proves all the way through. We did an episode on Koda a couple of months ago, so if you're interested, listener, go check

that out. So how would you say does Mimbo Wimble compare to Zcash or Monero or other privacy first chains? From what perspective? From what perspective? From a technology, technology perspective? Yeah, so from a functionality and technology perspective. I mean, both of them kind of touch upon things 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 ZDCash and Monaro in particular.

So ZDCash, we were talking about it's based on the snarks that we were talking about earlier. It's a completely trusted setup. Mimble Wimble itself and any Mimble Wimble coin is going to be completely zero. knowledge. So although there's no not like a key ceremony or anything to start it up, it's all completely trustless. And the case of Monaro, I mean, they have a lot, I can probably say more privacy features than what's in Mimbo Wimble at the moment, but a lot of that comes out an expense. So they use ring signatures at some point. They use what's coming to mind right now. But all of the kind of different methods they have about cascating transactions are kind of on top

of a Bitcoin-like structure. So, and again, Mimba Wimble itself is just a very compact, concise way of doing it. So those would be kind of the main comparison points. I would also describe Monero is more kind of mature compared to what Green is. But green is simpler. There's a lot of more privacy features in Monero, but still Green is simpler and achieves kind of a lot with a little space. and kind of approach, minimal approach.

With Zcash, you have with fully shielded transactions, better privacy properties. But as Michael was saying, requires a trusted setup 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 Grend and comes with its own kind of problems. that Zcash companies 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, big difference. And then we have governance approaches of these, of these two projects, which are generally different as well. So when you think of like, you know, the impact, you know, the effectiveness of a privacy solution, how I usually like to think of it as like, you know, what is the privacy set, the anonymity set here, right? And so when you, when you use Monaro'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, you know, 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 how would you, what's the, and so clearly the anonymity set of Zcash is much, much larger than that of Minero. Where do, how would you describe the anonymity set of mimble, Wimble? Right. With ring signatures in particular, I believe those are used mostly to, to cover up the transaction graph, as in, if someone is following, you know, 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 something that,

that's an ongoing challenge. We always have discussions about that. Right now we have a protocol in place called, called Dandelion, which is an, you know, an attempt to, to hide, not completely concealed,

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, to every node it knows about it, actually follows during what we call a STEM phase,

send it to one node, it sends to another node and to another note, and eventually, you know, randomly one of them will then do the fluff phase, which is broadcast to all of the peers it knows. In terms of the anonymity set, in theory, because you're doing with Mimble Wimble, you support non-interactive coin joints,

assuming that, you know, you can aggregate all the transactions, basically in a block or, you know, send out an aggregated transaction and broadcast that out to the chain as well. So you have a lot of, kind of, there's a lot of opportunities to improve that anonymity set as it goes out. Yeah, well, like I say, I mean, if you're looking, if you look at the blockchain data,

you have nothing else to go on, you're just looking at the contents of the chain of the UTXO set, there isn't, 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 for someone to construct the transaction graph and reconstruct what happened. And it's something that we're continually working on through various, you know, research into various technologies and additions to what we're doing. If like, you know, 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, you know, a very, very large anonymity set. But it doesn't solve the problem of, you know, the what of observing the peer to peer network.

And, you know, anyone who's trying to break privacy will definitely be doing that. And, you know, I know companies have done this in the past, like chain aliasis and whatnot. And so that's where there's like Dandelion comes in. And Dandelion is sort of this like privacy feature in Grin that is actually, you know, completely independent of Mimbo Wimbo. It's like a separate privacy feature. And so, you know, you described it a little bit about this like fluff thing. But can you like describe it a little bit further?

From my understanding, you can kind of think of it as this like, like Tor, MixNet kind of thing for transactions. Is that like a, am I having the right mental model here or? I mean, I mean, Dandelion itself, there's a few things happening. Dandelion and Mimba Wimble itself are very complementary technologies. Okay. Because in order to to perform this, this coin join type aggregation that we've been talking about, it needs to be done in one way and one way only before it hits 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 to be reconciled, we get applied to the chain. Now with Dandelion, because Dandelion, there's a distinct phase where a 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 that we go along.

So as a transaction, as a transaction goes through the stem phase, it gets aggregated with other transactions as it goes along. Until finally, since, until finally it gets to, you know, at some random point, one node or random, you say, right, no more aggregation and then explode. And then all of the nodes, all of its peers know about it and it gets propagated that way. So in Bitcoin, you do, you do, because like you basically, every node kind of just immediately when they have, something to broadcast, they broadcast it out to everybody they're connected to in the network, right? And here, the purpose of the And the underline is basically to do that, but it's just not you who does that kind of explosion, the gossip protocol. You instead pass the transaction that you have through one or two directions. And then there's basically a coin flip for every node,

whether they're going to 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 that node, that the transaction belongs to that node, if you see what I mean. Okay. So, you know, maybe we can like kind of walk through how this dandelion process works. So what will essentially happen here is, let's say, you know, we have this large network

and I'm the one who's creating this transaction. I'll go ahead and send it, you know, maybe to Michael. Michael, you'll send it to Daniel. And then Daniel has this like seed thing that like it tells him when it's time to propagate it. Right. And so he'll be the one to like push it to the rest of the network. But where is this aggregation happening? Is it that like let's say if it just so happens that the two stems of a dandelion intersect, then that person, whoever had that intersection of two of the stems that they'll like be the one who's locally aggregating it? Yeah, so there will be, you know, at every epoch, there will be a couple of nodes that will be fluffing nodes. And a lot of transactions are going to end up at those fluffing nodes. And at that point, they get aggregated and before they get fluffed out. Okay, so there is some mechanism of like, 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 aggregator.

aggregation there. But it changes after every epoch it kind of resets and everybody kind of do new connections. At least that's how it's done in Dandelion Plus Plus, which is I think what we're actually in I think we have a simpler version implemented in in Green today. It's like the original Dandelion paper. And I think with version 1.1, I think it's going to come out in that approach. How are these nodes chosen exactly? They're chosen at random amongst themselves. Like there's a coin flip on each side, am I going to fluff it or am I going to pass it along the stem? And that's just in the current simpler version. I think the reason that there's a one point one of this coming out is because it kind of reduces the chances or the occurrence, the chances for any aggregation to happen.

So for aggregation to happen here, you need a transaction to come into one node and then to be stemmed through another node that has some other transactions in it. Right. So what Daniel just described for dandelion plus plus is a way of ensuring that more aggregation happens in the dandelion network. So what happens if there's not a lot of usage on the network? And there are not enough transactions to actually compound? Yeah, if there's not a lot of usage, then transactions don't get aggregated. I mean, you'll see, I mean, it's early days for the chain. So I mean, you see a lot of blocks there. It's, you know, one transaction and number two transactions and number one plus the coin base.

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 amount of usage on the network. But I mean, that's also why we're building it. I mean, we're not building it for kind of like low usage and see where we go. We don't really have any interests in doing that. There's nobody kind of that gets better off for doing that. Instead, you know, everybody's kind of working towards this idea that this is going to be, you know, a big, well-use. protocol, that's the assumption.

Sure. So as you just briefly mentioned, Grin actually launched January, that was last month. So Grin is actually the implementation of Wimber Wimber that both of you are working on. And we kind of skipped over about this, we skipped over this like a little bit. There's also another implementation named Beam. Can you tell us how Beam and Grin actually differ from each other? The Green was launched in October 2016, I think. And Beam is a second Mimbo Women implementation that was announced, I think, in May or June, something, 2018.

And they take a different approach, governance structure, organizational. There's a development company building that. Does it in different language. Has adopted some of the approaches that we do. doing grim, but they are on their own kind of separate path. It's not like a fork or anything. It's their own separate project. And, you know, we, we in general, you know, of course, there's going to be many different bimba bimble implementations. Anybody who wants to can put one together. So, so I think that's, that's it. But it's very kind of, it's a very different structure in terms of

how they are organized and what their approach is to some of the things. So is there like, you know, what is the, sort of the relationship between the teams is there like a lot of information sharing because i know for example you know the grin team is that one who kind of came up with this idea of dandelion and so then beam kind of adopted it but i know there's also some like interesting innovation happening from the beam side where you know i was reading some of their documentation and they have like a mechanism of sort of these uh the kernels we were talking about that are being left in the chain they have a method of like kind of pruning those out and incentivizing the pruning of those um they also have this like

bulletin board thing that they were talking about where like it helps with this interactivity needed. So is there any like what is that kind of the communication between these teams and like you know any plans to kind of like port over some of their features back into Grin? Right. So just to point out that you know, Dandelion is not our invention. It's Julia Fanti and some other researchers that have put together that protocol. And yeah, there are different you know, in general the the Grin project. interact with any team or any kind of any individual or researchers that want to interact and want to share knowledge in like an earnest way.

We do have some kind of communication with the Beam team as well. They donated to our fund. We don't have like a good relationship with them. Generally though, what kind of I think Grin is focused on is to do this very kind of minimal implementation that doesn't have a lot of overhead and doesn't have a lot of 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, you know, if they're good, we adopt them. Any thoughts on the current, like some of the ones that they've already started on, like this

bulletin board or the kernel fusion and stuff? maybe the kind of the fundamental difference here I think is that the grin is as 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 it's a way of dealing with the the interaction problem that we were talking about earlier how do you how do people interact how does it work if someone's not available how do you send funds to somebody without without them being around or online to perform the transaction And I mean, Grin has a, or being it rather, has a, what I could you say, prescriptive approach to this, right? You've built a bulletin board and you do your transaction here and this is a 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 put them 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 add a solution like this on top of Mimba Wimble, you're also adding, you know,

you're actually lessening the security and confidentiality a bit as well. So that has to be taken into consideration. So I think like a fundamental approach is community. We're trusting the community to take Grinn as the core layer and then build, build custom solutions or whatever suits various groups on top of that. 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, you know, 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, you know, for full disclosure, I'm involved in the Vollets 7-1-3 and the Grimbox 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 now, you know, many, you know, there's another team now doing,

building on top of grid, right? And I think if you look at it, you know, 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 like a single entry point. It's a single central company or whatever organization it would be. I don't think that's a scalable approach

because it becomes, you need to let like many attempts to solve the same problem and see which one works, basically. It's like the bazaar versus cathedral discussion, right, in software development. So, you know, we talked a lot about mimble, Wimble, and this dandelion stuff. But, you know, I know another area that, you know, the Grin team has been kind of like developing heavily is, you know, kind of innovating on this like, you know, proof of work algorithm as well as, like, you know, experimenting with like new issuance models and inflation models.

And so, you know, I know you guys are using this proof of work. algorithm called Kaku cycle and like you know it kind of started with this like desire to try to create like an ASIC resistance hashing algorithm but then over time it seems that like the goals of this hash proof of work algorithm design have changed heavily and now there's this like you know complex like MOTU system version and can you kind of explain to what's going on here? Sure. So it's like a high level kind of summary of, there's like a family of proof of work algorithms created by John Trump called the, you know, the cuckoo cycle family, which basically the algorithm, the whole objective is you

have like this bunch of nodes, connections between different units in a hash table, the cuckoo hash table. And the objective is basically to find like a 42 loop, loop that connects 42 notes 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 an 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, 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 is all, this is this balance is going to shift completely so that 100% 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, Cucousycle, and when John first initially revealed the proof of work algorithm, it was believed that it could run, you know, 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 there was like big advantages for ASIC minors.

There was a lot of opportunities to build efficient ASIC miners using the KU-Cycle algorithm. Now, the reason why we moved away 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 a 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 the entire mining, which we didn't really want.

We don't even think that was a good idea. We do, however, see that because of all these, you know, 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, you know, A6s are inevitable and there will always be a way to kind of do

optimizations. And even if you're not going to optimize on the you're going to be able to optimize, you know, the guy mining with a GPU at home is not going to be as efficient as the person who's connected to a dam in China and has, you know, 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, you know, 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 ASICs. It was a very kind of long answer, but that's kind of my view on it. Michael, you know, if you have anything to add. about the grain and our proofs that work is A6 are going to happen anyways and that doesn't matter you can you can try and avoid it you can try and design an algorithm that you know 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 it your algorithm simple to specify for A6 manufacturers

to allow more of them to allow a market I mean A6 themselves aren't necessarily evil they're actually, you know, the closer you get to some, this is something again, we're back to Andrew Postra, a paper called the thermodynamic limit. If you had a machine that was absolutely the most optimized it could 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 AC development, and hopefully there will be a few options to choose from, they'll be readily available, this should actually help secure the network. Yeah, I lost my point there. ASIC mining, 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 we can to develop ASICs, then we're hoping for a more fair market. So you went with the two proof of work system 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 green developers as well? Are you firmly committed to proof of work? 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 it is entirely fair. Like 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. Yeah.

As someone who's been working on proof of stake for like, you know, two years now, I actually completely agree with you. I don't think there's been any evidence that like proof of stake can properly secure a network. And especially it seems that like, you know, grin seems to be one of, I've heard this where it's like, you know, Grin seems to be like the next best bet at money other than Bitcoin. And like, you know, if you want to create decentralized money, you know, you need to have had a similar origin story and anonymous founder. And like, and so if you're creating, I just don't think proof of stake works properly as an issuance mechanism. So, you know, who knows what will be in 10 years of time.

In general, the team and the community in general is open to any new technology as long as it's kind of 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 proof of mistake 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. So speaking of this initial distribution and issuance, so I guess two-part question here. One is, you know, this issuance mechanism, you know, you guys have an experiment, like a new monetary policy, that I haven't seen, the only other coin I've seen this like similar monetary policy in is Dogecoin, but essentially this idea of unlimited supply where it's, but constant issuance.

So it's like, you know, you have this like it's fun like little time is money meme going on where it's like one one grin per second or 60 grin per minute. But until the end of time. So like there's no fixed cap like there is in like Bitcoin or like coin or any of these other money, currencies that are trying to become base money, for example. And so kind of what led you down to, who made that decision of like trying this new policy? As to you may, I think it's something that the team arrived at actually fairly early on in development when we're talking about various models and schedules of how to do this.

I think most importantly, okay, a few things. I mean, this is a big kind of worms and you get all sorts of hate mail for any time 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 Bitcoin. It's going to be an entirely deflationary system. That's great and all. 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 problem with that approach, and you've seen that in Bitcoin.

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, the, the fees from Bitcoin become too low. So we think that the approach you've taken, which is just a constant block emission,

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 zero, you know, 30 years on and you're barely minting. Imagine if you can only print 60 US dollars a minute, like you'd have hyper deflation, you know. This is actually a rather conservative approach and you know 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 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 it's going to be worth far more tomorrow

so yeah so that's that's kind of where we can't speak for the entire team, but that's basically where we stand on it at this point. And ultimately, it's very simple, right? It's very easy to explain, very easy to understand. It's hard to kind of, I haven't seen a lot of arguments as, you know, well, well constructed as to why it is a problem. And since then it is, you know, very simple structure.

We like it. It's elegant. 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, you know, I think there's a lot, it'll be very interesting to see how this fair start plays out.

Like, you know, I don't think we've, I think the last time we saw something similar to a fair start, but clearly not as fair was like the Zcash start. And even that was, you know, they have their whole like developer side of things. But, you know, and I remember like what happened, what I remember my roommate, uh, my ex roommate, she like, you know, was really hyped about the grin mining. And I know like there was like I don't know I've heard like crazy figures about like VCs like putting hundreds of millions of dollars or something into like I don't know that much but crazy amounts of money into like you know mining ventures very early on in Grin when it like 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, you know, just want to talk maybe asset. a few one or two questions a little bit about, you know, a bit about the future of Grin and what the future roadmap is and whatnot. And so one of the questions that, you know, often comes up about

grin is that in order to make this mimble-wimble feature work, we kind of had to remove Bitcoin script because, you know, you can't, it's not part, it doesn't work with aggregation. And so how will we, what is the plan here for, you know, does this mean that, you know, is it possible to do multi-sigues, on grain, will it be possible to do HTLCs, atomic swaps? Is any of this possible on the roadmap? Absolutely. As a matter of fact, atomic swaps with both Ethereum and Bitcoin have been done before. Multi-sig is definitely, it's 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 kind of the foundation in there to do that. Other stuff, you know, smart contracts, we've talked about script to scripts a bit. Those are essentially ways of kind of enforcing, 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 kind of look through our site and what we have there, you know, 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 is going to be, for us, will be, you know, building the tool to support community building on top of Grin and on top of

Wimble Wimble, as well as, you know, slow and steady research as to, you know, other technologies we can be putting in here. Again, like atomic swaps, scripts, some, you know, lightning-like network on top of that. So, yeah, that's kind of very briefly what our future looks like. And so back to that question about the fair start and like, you know, so, The Zcash team with their fair start, they funded themselves by giving themselves a developer cut of all the block awards. You know, Satoshi funded his fair start by like, you know, do it like mining like crazy when like Bitcoin first came out and because it just wasn't very popular. But like I said, you know, 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? There's no pre-mine, nothing like that. So Grin is 100% community funded. We live by, I mean, Michael is funded through donations. There is a dev fund and a security audit fund that raises donations for specific purposes. But it relies 100% on. donations from the community and from minors and other companies active in the space to contribute. And I think, you know, you touched upon a very important thing there that, yeah, you know,

what is fair and, you know, what is a fair launch? And I think Grin has probably been one of the more fairest launches that have been around because simply because of the fact that, you know, 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 in mind, you know, whether they're VCs or not or whether they're users. And we welcome anybody to come and participate in the project. And that's his strength, I think.

It's the reason why I got involved a year ago, because it's very easy to participate. it's very easy to become active in the community when there's nobody else kind of making, you know, having an advantage of you, earning more money or something because of your contribution. Anybody who's here and want 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. And it becomes also a self-selection exercise. I've noticed like 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, I'm not, some people ask, you know, there's always this kind of quick 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, you know, maybe there will be fewer developers and less development going on. If nobody cares about that, then I guess it wasn't very popular in the first place. But if people do care about that and they want to actually take a grin forward, then anybody can participate and do that. So it's like a non-issue for me in a way. So you don't see any issues with, I mean, I can see how the story right now is super appealing. So it's quite currently no one actually makes huge amounts of money building businesses on Grin. But once they're actually active people who actively benefit from

the GRIEN network and build businesses on it, do you think the volunteers will still be there to actually build the infrastructure or will they feel exploited and will this turn into a tragedy of the common situation? I don't know. I think it depends a little bit. I think it depends on the businesses, how they act in the community, what kind of how they operate. If I was starting a business, you know, and, you know, the stuff we're doing, for example, with Grimbox and Vult 713, it's all fully open for anybody to use. If you're a business and you make money off grid, it's kind of in your interest to contribute to the debt fund, right? Because, you know, it's your protocol that you're making money from. So it kind of makes sense for you to ensure

that somebody's looking after the protocol on the protocol level. And so far, what we're seeing is that exchanges, mining pools, you know, 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 else, everybody involved to actually, excuse me, to contribute. And I don't, I'm not too worried about it. And, you know, 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 to contribute if they want to

on their spare time on something else, some other corner of the protocol. But the differences, I guess, with other setups is that if we, for example, as developers, we're taking 20% tax on all coins, ever mind, that creates a very weird relationship between us and the rest of the community, right?

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 20% of all the coins, then it's really in our interest to just raise the price of the coin all the time and kind of focus on that. Whereas maybe what we should be looking at is adoption

or making more users using the coin. That doesn't necessarily drop up the price of the coin, though. Do you see what I mean? It kind of has like a weird incentive alignment. Yeah, I agree that it's really difficult to find models that align incentives well. But saying you trust in the good in companies, to me that seems a little naive. I mean, if you look at the off-chain world, 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 pays taxes. And Apple chooses to not pay tax. So basically, this is like major corporations have ways of circumventing paying tax. And I mean, in principle, they're liable to pay tax, but somehow they still end up paying very little or close to no taxes, right? 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 of green. in as a project was to be very minimal on the top layer protocol, right? In order for that to kind of make sense, intuitively it means that, you know, other entities underneath need to kind of step up to the plate and deliver products and services to help 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, you know, needing 20% of all the coins of the mind to sustain itself, right? It's the whole, that's the kind of the whole idea out there. I appreciate the idea and I think it's super idea and I really hope it works.

So I'm not holding against you. I'm just, yeah, I'm just asking whether you're working. Yeah, and I get also like, you know, as I tell companies, because there are a lot of companies that kind of approach us, and they're going to say, hey, we want to get involved, we want to do this, want to do that, how can we do, how can we get more involved in it? And I say that, like, if you contribute to the community debt fund,

it's like the greatest way to create goodwill and marketing for your company in the community, right, by just kind of making active contribution. And of course, companies can choose not to do that, but I mean, that stands for themselves. And I know, you know, 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 like a debt tax or something. I don't think that's going to lead to longer-term success for Grin and what its long-term objectives are. 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 in to make someone else, to have someone else profit off the end of it? I know it kind of sounds a bit naive and there seems to be, I've seen criticism on the internet and know it's not going to work because you need to pay developers. But I think it's been around for two years now, and the interest is still growing.

Personally, I mean, I've been funded for the past year and I'm funded again for the next six or seven months to work on a full-time, you know, at a regular developer salary. And I think, and this is early days, before the chain has even launched and people had their businesses that they were going to build on top of green. So I think the early signs are encouraging, anyhow. Take what we're seeing with exchanges as an example, right?

We're not actually, I mean, 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, exchanges list us without us asking and without any preconditions. But if we had like a pot of gold that we were sitting on, which was like equating to a chunk of the total coin's mind, then I think the story would have been very different. Yeah. So, I mean, and certainly there have been open source projects that have been going going on for tens of years, and they're still around. So I'm interested to see what the future holds for you guys.

Thank you for coming on. Okay. Thank you for having us. Thank you very much. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts.

And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter. dot TV slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back

next week.