All righty, I'm going, I'm typing over here. Boom, set. Sean, what's up, man? Good morning. Morning, Doug. How are you doing? Good, good, good. It's an early one for me, early for you. I appreciate you doing it.

I'm just a little disrupted over here because sick getting back to Porkfest, I never got the studio back in order. So I was trying to scramble to get it back in order this morning. How was that? Or to obviously make my coffee. Porkfest was fantastic. It was great. You've been there, right? You've been to... 


Yes, I've gone many times. Not this year, I was busy, so what I've been. 


I don't think we've ever like linked up at pork fest in the times that I've been there and the times that you've been there Right. I don't remember us really hanging out of port. Oh 


Usually, I'll just show up for one of the days to see if I can get everybody together. But yeah, it's such a big location. It goes on for so long. There's so much to do there. I can only hit the highlights at most, so we may not have linked up at the same time.

Unfortunately, I was the other side of the world at this time. 


What yeah, you were at you're a Monero con how how was that? 


Oh, that was great. That was a really good time.

I've been to a couple of them. In this case, it's a really good young crowd. It's great to have some place in the middle of Europe there because we get very different, like it's easy to get everybody together. But the energy was really high this year. And there's a lot of talk about this. We had a, the talks and discussions were really good. We had a pretty huge diverse array of people coming in, many academics, many of the original OGs were there. And a lot of new discussions about what's actually happening in the entire crypto space. So a lot of, you know, toes in a lot of different bid pools. And we had a lot of different perspectives. And that was really fun. 


Yeah, MoneroKon is obviously always a fantastic time. This is the first one I ever missed on Fai Isunalei. But I felt like somebody had to hold it down at Porkfest, plus with the new baby and everything. Oh yeah, and we're going to Europe a little later this year. So for me, it would have been a lot to go, come back, all that jazz. So unfortunately, I had to skip, this was the first time.

So yeah, I was feeling it. Well, I was like, ah, this is the Monero, because it is a magical, it is a magical conference, right? You get all the, you know, all the OGs coming out. Get the European crowd. They don't always make it over here when we do MoneroTopia and whatnot. So I didn't miss that. Was there, was this your first, this wasn't your first MoneroKon, right? You've been to... 


I've given presentations at them, it's been a bit since I've been involved specifically in your development for Monero, so it's been a bit since I was... Yeah. Yeah, I was... 


there. And I know you from back in the day from the New York City Monero meetups. I mean, we know each other for a while now. It's been a few years, right? 


Oh yeah, I've been busy working in other areas of cryptocurrency and high-tech development during that time, but I've always been back here and always been keeping an eye on Monero. I just wanted to thank you for keeping everything up and running.

I've always been watching your shows and keeping up to date, so thank you. You've kept it from out and busy doing everything else. 


Yeah, of course, of course. And I'm hoping we can link up in person one of these days. That'd be great as well.

Yeah, why don't you go ahead and give the people a little bit of background in terms of what your involvement has been in Monero, and then we'll get into Greece and not the country or the petroleum products, but the name of the L2 that you invented, I think maybe in company with somebody else or that you're proposing. Very interesting. I think a lot of people are excited about that. Obviously, people have been talking about a lightning network on Monero, theoretically, for quite some time, whether or not we even need one, whether or not we want one, what one would look like. And now you've gone ahead and I, from my understanding, propose something that's potentially quite usable here. So we'll get into all that. But first, if you got to give us a little bit of background about yourself, your involvement in Monero from the early days and whatever you're willing to divulge. 


Well, I'm generally a cryptographic engineer programmer, so I've worked on cryptocurrency in the background, but also just any form of cryptography for quite a while. Since Monero has always had a very open and completely democratic viewpoint, it's easy for people who are interested in technology in general to investigate and join community. And so I did quite a while ago.

There's a couple of projects going on, COBRI was one of them, plus also the new developments for CL-SAG that have been released in the standard doubt. I worked on some of those at the time. Some of them went in live and worked out well, some of them, they were still waiting for some of the newer developments to happen. But yeah, I've been following the technology, it's wonderful. It actually helped me get interested in another term called zero-knowledge proofs, which were released after Monero, but have been really developing very quickly. And because the technology does have a lot of similarities, I've been able to work with both worlds and keep it forth. 


And what type of stuff were you working on with Monero previously, you said like, uh, C.L. Slag and... 


Yeah, some of the original proposals at that point in time. There was a lot of work that was going on. This is right at the beginning when chain analysis in other areas, other companies were looking to figure out how to analyze the Monero network and some other things. And so there was a lot of discussion about how to actually improve everything in both those things.

But as it turns out, with even all the updates and everything else that have gone on for the last five years or so, there was nothing that the analysis companies could do. This is an extremely well protected system, well thought out, improved over time. So even from an adversarial and networking perspectives, that was really good. The best part about this is even as critics who say that they're not happy with the way Monero's designed, they could say that it's still, number one, all the attacks are well known. These have been documented well in advance. There's many papers that have written on Monero's network topology and other things. Over the weekend, there was a couple of papers presented that were new analyses of Monero. But with that, all of the findings that they had always consistently showed that this is basically about as optimal as you can get as far as security and privacy are concerned. Nobody's been able to figure out how to beat it. And so that's wonderful after all this time. 


That's, uh, that's reassuring to hear, to hear from you actually. I mean, obviously we have the ring signature issue.

That's hopefully going away with the implementation of full chain membership proofs, but you're saying, yeah, even with, uh, the potential attack vector on ring signatures, you're saying things are still pretty damn, pretty damn good. 


Well, yeah, it's, uh, well, uh, these ring signatures are form of zero knowledge proof, and because you're selecting a decoy, there's always some information, your entropy, some information being lost each and every time you're performing a transaction. But the way that this entire system is built up is even the most, even with unlimited resources, an adversary will never get enough, never going to be enough information to really resolve everything. So that's, that's consistent across the board. No one's ever been able to figure out a way to even with perfect information and perfect knowledge, no way to get what somebody really wants to know an adversary just can't get what they want.

They can get a little bit closer, but they can never really beat the system. It's just too well-designed. It's just been improved so much over, over the years of the experience. All the gaps have been closed. It's a lot of people are competing. A lot of papers are being written, but nobody could ever get that, you know, the actual secret, there's no, there's no secret thought that gets the recipe that they can solve everything. So he has this great number of people working on it with a number of papers published. They still, they can't really get what they, an adversary can't get what they really want. 


Right. So even the known attacks on ring signatures, it's not determinant. None of them are deterministic.

They're all, you know, probabilistic, right? They could get some data, make some assumptions, but they can never. Right. Right? 


Yeah, absolutely. There's all sorts of discussions about how one could go about trying to get more information that they have. But the way that they bring signature power, there's so much decoy information, there's so many alternatives and so many potential paths. There's no way you can really definitively say, I have knowledge about this particular, this is what courage end to end. There's just too many alternatives and too many alternate universes, you could say, where something else completely different happened. You're never going to get something that is a smoking gun.

You can only see some small amounts of bits and pieces there. And that's fantastic. It definitely beats out pretty much any other cryptocurrency or most other privacy, the privacy preserving technology. This has shown such fantastic work, such success after all these attempts that it's really impressive. 


When you say pretty much any, what other ones do you consider interesting projects, things that are also, quote unquote, privacy coins. But before you answer that, we got about 75 live viewers right now. People are trickling in. We normally do these shows in the evening, so it's a little bit of a different time for people.

People are coming in. Guys, like and share, retweet. Let's get a nice crowd in here. Sean will be telling us all about Greece, the layer two proposal. Right now, we're just kind of talking about background stuff. But yeah, Sean, any other cryptos that you're interested in from the technological standpoint, things that are doing interesting things? 


There were a couple of papers released over this week, and the talks are going to be soon online if they're not there yet. I suggest anybody interested in this.

The talks are really good. A couple of them, I'd like to summarize. In general, Minnows, the technical design is actually given pretty low ratings on a couple of the papers, in that there's well-known attacks, they're documented, they exist, but because they don't use all the latest and greatest technology, they're not specifically designed to prevent some of the newer styles of attacks. So it actually is pretty low rating overall, but unlike the newer technology that they're listing, it's been proven in the field. Any adversary just can't beat this, so a really low security number that still has this much proven, that means the new tech better be really good. But Zcash is one of the better things to talk about. It does have a lot of new technologies, it's adaptive and growing. It has an extremely small number of transactions that users who are there, so that is the inverse of here. But the technology itself is pretty good, it's fairly well established, it's been around for a while. So if you take a look at that, Zcash was considered one of the higher security ratings just because of the technology in and of itself.

But of course, technology is never enough, you have to have an entire community and network. All the people who are doing analysis of this network are just amazed at how large the network is and how much support, the diversity of everything. So there's every paper you can think of that criticizes technology. Another one comes up and shows actually this is all, it's full of proof against that. 


Yeah, what are these papers? So you're saying at MoneroKon, there were some papers that were released or presented with us analyzing Monero and other cryptos as well? 


About half of the presentations were either about, let's see, non-technical items, discussions about the community and things like that. The other half were new development discussions about new things that are going on.

Something that was very particular is something I thought about, the Eclipse again, that we're taking a look at the nodes, the main devices that are connected over the Internet and how you could go about analyzing them. Even with really good analysis, it was possible to see that there's a lot of dedicated in diverse hardware. Then there are some other things to take a look at, some of the newer anti-observation systems. It's kind of easy, unfortunately, the people who are adversaries, we can kind of figure out pretty easy ways to identify them.

There's a lot of nodes that may not be trustworthy, and we can tell because they tend to be an entire IP address sub-network, the entire area that the last 8 bits, like 255 to the very end of the network, are all in the same, all the networks always know they're the same one. It's as though somebody's renting for cheap cost an entire server network where they have 255 machines all running there, and they're in all separate nodes. 


We see you NSA, we see you NSA, come on. 


They fear that problem because it's cheaper to do it that way, just to rent out one subnet. So it's like, why would they intentionally go over the cheapest bid or something like that? That doesn't make much sense.

But there's easy ways at that. Systems are already published. It's easy to identify. The ways to understand this, the mitigations against it are pretty easy once you have enough data to understand what's going on. 


like ruck neem's talk i assume you're kind of there yeah yeah okay there's 


There's a number of them, so I don't want to get into physics specifics. But if you listen to the theme, if you listen to multiple of them, you'll see that it's almost too easy to figure out what's going on. 


And then what was kind of the discussion around full chain membership proofs? We had Diego on your right before pork fest. Everybody's concerned that we're going, you know, things are getting stalled.

My understanding is not necessarily, you know, we hit a little bumps bump in the road with the divisors or divisor right properly, um, auditing them. But now it looks like they, they have been properly audited and there, there is a path forward. Maybe things will take like slightly longer, but we're not really off track. But yeah, what's, uh, what's kind of your overall take on that, especially, you know, since Monero Con, what's your, what's your assessment of a full chain membership proof implementation? Are we, are we on track? 


Well, for the entire FCMP++ project, that is the reason that newer technologies like Grease could go and actually be implemented really well. That's really going to be a game changer.

And many of the critics and people who are concerned about the Monero's design, they've actually appreciated that this is a really good upgrade. Its design, its implementation details, it really resolves a lot of open questions. So, one of the presentations showed that Monero had a pretty low number as far as the technology goes. And FCMP++ is really going to bump that up pretty fast. There's a lot of new, really good improvements built in there. So while the full chain membership groups are fantastic, that++ covers a lot of ground too. There's a lot of really good things that are going. That's exciting.

I'm going to love when that happens. As far as the actual implementation goes, the auditing was a problem. There's a lot of making sure that we can go back and forth because it's just from a community perspective, you have to have a diversity of who's going to be doing the audits, how it's going to be funded, and a bunch of other really minutia problems like that. The devil's always in the details, so getting everything done was taking a lot of time. And there's even a couple of open questions still, like how will this particular situation be affected? Those aren't completely resolved yet, but those are really small details compared to the overarching, like the huge amount of approval that's going to happen. But also, any major hard fork that's going to break the entire chain at this point, it really needs to go very slow and be very thorough because once this is implemented, it's going to be really hard to recover anything if it goes wrong. So it makes sense to really take time and make sure it's going to go right. 


Was, was Luke at Monericon? Because I don't think I saw him on the list of talks. Obviously I didn't get to sit and watch everything. 


I actually don't know, but the very end of the conference had an excellent tribute to some of the developers. It may not actually be on YouTube, but this is complicated.

If it's not on YouTube right now, if it's not available, it's not released. Maybe it's the best that we don't talk about that right now, but there was a fantastic tribute, a standing automation, I'd say. But you're going to have to understand why that happens. 


They're secretive as always with Monero and it's like you had to be there. You had to be there. Yeah 


I still want to ruin the wonder of that situation. 


But overall is your take that we're pretty much like we're on track. Obviously you're saying we've got to do things right, whatnot, we can't rush things.

But what's your kind of your overall assessment? I mean, are we- Oh, from what you're saying? 


I've reviewed and the technical information that's going on. I love the concept that technology is wonderful. The developers have done an excellent job. The organization so far is going to my mind, in my experience, is going quite well. It is going to take some time because things have to be conservative here because too much can go wrong if not handled exactly right.

So that's going on. In my opinion, from someone who doesn't have direct access to everything and staying away from the implementation, the actual specifics, I say I actually have very high confidence. Not only is this great technology, it's going to go. It's going to be here. I couldn't answer the specifics about what's going to happen this year, maybe. Maybe next year, I don't know. Okay. Yeah, I don't want to back you in the corner on that one. Well, I'm going first to the app. I could criticize the technology and understand what it's doing, but I'm not handling the implementation. 


Now, obviously, you said zero knowledge proofs is something that you're an expert in, right? And what you've done here with Greece involves some zero knowledge proof technology, full chain membership proof stuff. What I always find interesting is people talk about Monero as though it doesn't have zero knowledge proof tech, right? They talk about Zcash like it does, but Monero very much does.

I mean, there's different aspects of it that do, right? Bulletproofs, I think there's other aspects as well. Maybe kind of give us some knowledge there, right? I think there's a lot of miscommunication with regards to what zero knowledge proofs actually are, whether or not Monero already is a zero knowledge proof coin in ways and why perhaps people are confusing these things and say like Zcash has zero knowledge proofs, Monero doesn't. Just for the noobs out there, if you could kind of explain that all to us. 


Well, yeah, I'd just like to explain from a cryptographer perspective, zero knowledge proof is a way of saying that you follow one person as a pilot of protocol without revealing all of the information necessary for a complete audit, but you can still rely on the proof itself. And the information here is abstract. It could be this or that, but we're always talking about private keys. It's, I have a private key. I'm not gonna give it to you, but I can give you my public key. So from the basic perspective, I can say anytime you create a private public key pair, that's a zero knowledge proof. I can say, I have a private key here by public key. There you go. I have knowledge. I'm not sharing with you, the proof by public key that I have that. So we're very, very basic perspective. That's it.

That's all it is. But there's some newer systems where we can create, the problems with the zero knowledge proof system is that it's not Turing complete. If I were to just give you my public key, what can you do with that? Well, you can use it for certain things. Like you can send me an encrypted message. You can verify a signature and some other very specific things. So there's only a couple of things you can do with that. One of the newer systems that we have is creating an entire virtual machine. Not just taking this concept of a private key and things like that, but actually making an entire computer out of it. Some people have actually gone so far as in some of the block games, Minecraft, for example. Some people have actually gone so far as to actually create a processor. Some of the more simplistic like 1960s and 70s processor using the blocks that operate inside the machine. So you have an entire world of a 3D world where you can actually create a processor that runs. It has the simple inputs and outputs and it's able to data process, which is a bit abstract when you think about it. You're creating an entire virtual world where users can interact with that. It is inside the virtual world. This is all run by computers. You're actually creating a new computer. So the computers are simulating the fact that you're running another computer, but it works and it's kind of amazing. It's a very meta way of looking at things. And that's what's going on with this new Turing complete system. The first one to do this is called DK-SNART, which is a way of taking a Turing complete system, taking a bunch of mathematical equations, a bunch of public keys and tying them all together. So the actual operations that are going to multiply the additions, the simple ops, the XORs, those are all processing as though they are public keys on private information. So just as the same thing as you're saying, like I have a private key that can make a public key, I've also constructed this virtual computer using a series of different operations in memory. And I'm providing a bunch of public and private key information and it all processes out works. So you're constructing a virtual computer in memory using public private key cryptography. And the beauty of it, the mathematics is incredibly complicated, but the beauty is it all works. 


It actually works out. You can create a Turing complete computer and process pretty much any program just using public key cryptography. 


And so which kind of, so like kind of which cryptos already have are capable of that. 


There's the history of this is this started out as zero cash and eventually a lot of the people created Zcash out of that and that became the very first Crypto current kind of like a proof of concept But there was also trade-offs they had to go with at the time you you had to reuse a desktop or a laptop It wouldn't work on mobile and others makes it as the technology has matured in a lot of work spun into that Um, they're getting much more efficient so you can have those same spousal things run on mobile devices It's um, which is pretty good. Just the old computer old old for your pocket You can now run these really complicated virtual machine systems improve a lot of things.

So that's exciting well, Monero is based on you on some of the technology that wasn't as new as that but now it's based on basically couple of groups Which is a another way of doing a zero knowledge proof, but it's also very specifically tied into the technology It's try it's taking the same public private key systems and actually pushing it under kind of like hammering that in there So it gets exactly what you want out of it. There's a lot of let you do not it's very complete Like you can't prove everything but there's a lot of extra working to do with over zero There are the nice things there.

There are more mature technology to it. The nice thing about Monero is it's always using Technology has always been proving before this is a field path that system That's part of the reason why FCMP plug-plus is taking a long time The newer systems in place have to be proven out You you really can't go with something that hasn't been that could potentially have problems and it could be backdoor So you need to go in the field lock value with that.

See that it worked So Monero has always been a for lack of a better term a little more conservative Whereas the ZKPs are moving the entire industry is moving so fast if you blink you're gonna miss it But it also means there's there's always problems with newer proving systems like this There was a major Microsoft backs proving system that turned out a lot of the background assumptions they made turn out to be false and so there's a huge amount of effort that way to try to get that proven working and it's not gonna go anywhere because We get people discovered later that it's not gonna work. So


Yeah, something like crypto, you definitely don't want to be taking that risk, right? With like billions of dollars at stake here, people losing their money, being able to essentially print crypto out of nowhere, right?

If they find some exploit. Yeah, I mean, in the earlier days, right? Zcash, right? It was always said, oh, that's moon math, right? Like, that was kind of always the skepticism, right? Like, sounds great in theory, but hasn't really been tested. But I think at this point, people are feeling pretty good about the tech that Zcash uses.

And then full chain membership proofs, kind of similar in that respect. But that doesn't make Monero fully Turing complete, as you're saying, right? Because it's not that the whole chain is running off of it. It's just one aspect of its technology. I don't know, right? Maybe you could explain it all over, right? 


Well, there's a magical term that Venera is going to be using now called a Merkle tree or Merkle root ROT Which is in the in the 0.0 proof area is like the magic key.

The other chains like for example Ethereum has also been using a bunch of Adaptions of that. It wasn't necessary for Venera at the beginning because that while technically baked into some of the protocols It's really not that it wasn't that important. In this case, we're going to be having an updated Merkle root that occurs This is a way you can use Optimize some of the proving systems. And so the newer FCMP plus plus is actually using what's called the $0 proof circuit But it's also not turning complete which is some technical details, but you can throw it in there in case anybody asked Yeah, we're using a $0 proof now with a Merkle and that's basically the the magic It's getting much closer.

We're getting the Monero is updating his technology So it's matching a lot of the newer things not all the way it's not necessary But if you keep it there, so if you ever see the Merkle root you can that's the the magic term


Right. And you say it's not necessary, right? Because Monero is just running a digital cash. 


The term I think is called minimaxing. Ignore the things you're not good at and just focus all of your specialty on the thing you're really good at. It'd be the best in one particular field.

That's Monero's concept here. It's the best at privacy. So it doesn't have to be good at all these other ancillary things. It doesn't have to be good at very complete programs or scripts or anything else. Its focus is primarily in, you know, very heavily on privacy and it just, it does it so well there's no need to really change anything else. 


Do you love coffee and Monero as much as we do? Consider making gratuitous.org your daily cup. Pay with Monero for premium fresh beans and if you like what you taste, send a digital cash tip directly to the farmers that made it possible. Proceeds help us grow this channel, gratuitous and Monero. 


And do you think Monero stays on that track or do we eventually try to even upgrade beyond full chain membership proofs, try to become more fully touring complete overall? Or is that something that Monero really doesn't need to get involved in?

Or is that something that takes place on a layer too potentially? 


question yes this is this is my thought exactly now that FCMT plus plus is published in going into play now we don't necessarily what's gonna happen but with that and with a lot of the the the plus plus actually covers a lot of things there's a lot of ground there with some of the new features that are gonna be released there's a lot of it to add activity we can't do even though there isn't a terry complete or a script system built into Monero there's no reason we can't add something on that actually does use that what some of the nice things that the other black chains are doing there's a concept called blockchain interoperability or inter blockchain communication IBC and some other systems based on layer two there's a lot of work that goes into trying to connect two separate blockchains whether let call it layer one layer two or two separate things and there's a lot of technology that's been invented a lot of procedures that you can use just those are usable technically even right now it is possible to use some other technology that does exist it doesn't have to be zero knowledge proofs there's there's other systems for that you can use to kind of locking between different chains it is possible to have two systems communicate to each other there's already a movement to get Ethereum atomic swaps going on there's a work group dedicated that this last weekend how to have a Monero atomic swap work with Ethereum yeah it's well established on the narrow side how to do that but you have to do a bunch of smart contract development and things like that those actually don't technically need your knowledge proofs like turn complete ones but they would work fine so there's a lot of work going on elsewhere and the great news is that's so well developed it's so understood now we can basically just take a lot of a lot of that work and lift and load it right into adapting to work with Monero it is possible it's not exactly easy this is it's not yeah kind of like a cigarette lighter adapter those are standardized and a lot of cars still have those you can power your your bar your smartphone using those that's that's intended purpose it does we're supposed to have like for people who who does that know you just still have that adapter right there you can plug your phone in and keep powered even though you know it's old technology we still get it to work perfectly fine with a newer thing yeah it is possible now with this to get some of the newer communications working so yes it's possible to use what's called a payment channel now some people will call it a layer 2 it's not technically a layer 2 when you have a payment channel it's just a way of communicating between different parties it's specifically a channel because it's just two connection points two people communicating but that way you can bypass a lot of problems you have in a layer one Monero and then use that payment channel to communicate offline individually between those users and so yeah it there have been some designs to get a payment channel that works correctly and there's always a trade-off there always some problem and even a major PhD thesis paper that went out that looks really good but there's a lot of technical problems that just were ignored but giving the newer technology exists with zero doubts proofs in inter-block chain communication it's possible to actually resolve all of those and get it get something that works and of course there's always trade-offs because we're dealing with the blockchain trilemma there's no way to resolve that definitively but you instead of satisfying all of your different competing interests you can always satisfy you satisfy said you say we can always get good enough we get real close and so I've been working on an attempt to get pretty close really good trade-offs to get payment channels to work with the Monero as it exists right now with CLSAC but even better once FCMP plus plus comes out it'll really work really well so it'll it'll probably be something that people want to look at what's uh once that goes


Fantastic, fantastic, and I love that you're, you know, you're somebody is working on this, right? We're at almost 160 live viewers, guys, like retweet. This is exciting stuff.

We're talking about some potential Monero L2. Actually, like you said, maybe we shouldn't be calling it L2, right? It's payment channels, but I thought that's Yeah, but I mean Lightning Network is essentially and we'll get into this more is a payment channel, right?

It's not yeah by definition. So what what is it about full chain membership proofs? That is allowing us to perhaps more easily implement


Yeah, there's what Minero doesn't currently have and it's it's a technical hurdle that can be overcome but with a lot of trade-offs There's no easy way to do a system called a transaction chains For example, if I were to create multiple transactions each one requiring that the previous transaction have already been completed You can't do that currently in the current design So you have to in the case of let's say I wanted to have multiple instead of sending one transaction to multiple people I wanted to go back and forth between different people or slowly send off transactions other people that isn't possible But instead what it happens to is simply okay create one transaction Submitted over to the Minero a network wait for it to be confirmed on chain. Okay. Now that that's done Now this is actually the chain then I'm gonna now send my next transaction using the results of that first transaction to go on So there's no easy way to just create a bunch of transactions to be done with it. That isn't possible That's one of the reasons why users New Year's especially the better are having a lot of trouble with just simply the usability and design Limitation we have a 10 block 20-minute lockout timer So you can't really spend anything until this is confirmed on the chain after that's wrong There are no transaction chain.

That's included in the plus plus with FPM people So we're gonna have that live and that'll just make a lot of transactions a lot of faster is actually much easier to deal with Yeah, so it's such a


transaction chaining that comes with full chain membership proofs that's allowing us to create these payment channels. 


Well, there are ways around this. Um, it's just unfortunate the trade-offs around that are not very easy.

Um, yeah, there's always going to be a problem with that one. I can go into details about how we can get current CL SAC to work perfectly fine with payment channels, but it just requires a lot of like a trusted third party or a semi-trusted third party that acts as a middle, a middle person, middle party to actually get everything to work right. But that you, that's a trade-off that maybe is questionable. There are ways to actually get it a little bit safer too. So I'm still investigating those. 


And those, there have been other proposals for payment channels, right? Even the briefs, right?

We've seen so are those are those like ones that kind of like what you're referring to things that have tried to propose how it all is. Payment channels can be built on Monero as is even for a full chain membership groups. 


Most of the previous payment channel designs for Monero would require certain additions to the base layer, like for example, creating a variable time lock. Something to note, there currently is, with CLTAC, there currently is a version of the time lock that's on Monero, but it's not variable, and it's not adaptable, as in you can't add some information or change the way the transaction flows. It's simply a time-based lock, so it's very limited utility.

But even that one's gonna be going away with FCMP. It's simply not, nobody really needed that for the utility. So there really is no way. If we wanted to use DLSAG, for example, you would have to actually create a new time lock mechanism. That's been proposed for a while, and so it's been around as part of discussion, but it's not currently part of plans. It is possible, maybe it'll come back one day, but right now that just isn't on the board at all. So there has to be some system that doesn't have an entire consensus mechanism. 


And then once full chain membership is implemented, is there other changes that will need to be made to Monero before we could implement something like Grease? Or it would be pretty much... 


to go. Greece is designed to work as is, so we can go without anyone who would like to finalize the implementation can go about implementing that, so it is possible right now. 


even without full chamber breakers. It'll work out. 


Yeah, we can get it to work, right? It's there's certain costs and consequences of that. And I can get to the technical detail, which I love, but it would work. Yeah, there's nothing that stops this from being done.

It's just, there's always going to be a trade-off no matter what you do. With, and then we have to get the full statement of how this trade-off, so you go away. 


Okay, I got it. So theoretically, we could implement grease today without even making further changes to the layer warning protocol.

But once the full-chain membership proof is implemented, the trade-offs go away and it becomes obviously more desirable to do. 


And I do want to be specific about one thing, the Greece is implemented to have what's called a bidirectional payment channel, meaning that there are some ways you can get something that work either directionally, like we could have communication where I can send you some point payment in the future. But if that, let's say, for example, you wanted to refund or you have a discount or something like that, there's no way to do it bidirectionally. One party could pay the other party, but the other party, you have to start over from scratch and everything. That's kind of the piece of point.

Having a really good bidirectional, specifically also another technology, unlimited time, using this technology in Greece, you can have a channel that's open between two parties and you can stay there forever for as long as you want to. There's no time limit on that. It'll just keep functioning as long as you want to. And all of that transaction will occur off-chain. There's no way for anybody to even tell that anything's happening from the chain side. 


So people hear grease and they're like, Oh, layer two, it's a layer two narrow. Does it need a layer two? Monero is built to scale on chain. That's why we have dynamic blocks. Um, you know, layer twos can lead to us being co-opted. We don't want to end up with Bitcoin.

Right. What's your response to that? I mean, I guess number one, do you think Monero can scale well on, on chain on layer one is, or do you think it can't, and that's why we need this? Or is this something, even if Monero can scale on chain, this is still useful for other use cases, um, you know, that allows us to do things that we can't do on, on the layer one. 


Let me jump to the end really fast. From my opinion, I will say that there's zero threat to the base layers mining capabilities. There's no scenario in which this or any other payment challenge will threaten any form of fee processing or any of the markets for the actual mining. So there's basically zero threat at all to anything to do with that. So yeah, I don't see that as being an issue at all.

But the question is, will there be any impact on them? There may be some use of this case. It's important that we're developing a protocol, not a very specific implementation. There's been some other nodes, node systems and payment channels that have gone in and just not really done very well because of how complex their requirements were. The protocols for Bitcoin Lightning, for example, are so different, so onerous, and so specific that it's simply not adaptable to any change in the way people want to use that. It's just built in and there's a lot of problems because of that. But if you define this as a protocol where we're not really, we're saying there's different ways you can implement things. That allows people to have more creative ways to resolve this. If you go in with just specifying the technology that have to be used in these particular ways, you're locked in in time. And much of what we're trying to do here is actually make things more adaptable to change the market.

So as long as you follow the protocol, you can implement this in any number of different ways. So the text that exists right now has some notable trade-offs. SCMT++, once that goes, then that'll change a lot of things. So even the very design of grease itself might change, and the implementation might change because of that mineral changes. So as pain in newer technology has developed over the years, that's easy to just throw right in. It's really easy for me to say that and say this is something that'll be done in the future. But the reality is there are very specific use cases where you do want to have, for lack of a better term, an NL2, a payment channel system that's relayed between different users. But the use cases we have right now, they exist. There are problems that people have with Monero, and they can be resolved with this right now. So there's nothing keeping that back.

So if you want specific examples, I can give you those because this is needed right now. Yeah, let's see. 


So what would you say, though, to just the people who are like, well, I thought Monero can scale on layer one. That was the whole point of dynamics blocks, all that stuff. Why do we even need this? Right. 


I say that every argument about keeping an L2 away from the network, and every argument about adapting the base layer of L1, those arguments are all correct. Everything they have to say about that is correct.

Monero is a dynamic blockchain. The block header itself will expand when necessary. And one of the papers released over the speaker was details on a very specific orchestrated attack, which was actually more of a white hat attack, as it turns out, than anything else. It was an attempt to just stress the network to see what happened. So there was a very specific attack, and then the paper was released on that. Basically, the design was to test to see how fast the Monero network would adapt to an overwhelming amount of transactions that occurred for a short period of time. This occurred a little while ago. It was interesting, because not specified in the paper was how the community reacted to that. It was specifically about what did happen. And so, yeah, this exact situation occurred. What happened was the network is overwhelmed with the amount of extra transactions. So the blockchain, the block header started expanding out to the point of being a problem. There was a flood of new transactions that didn't actually do anything, but they were just there. And so the network was stressed, and the paper was released, and you can see the results. As it turns out, actually, everything worked quite well. So yeah, that's fine. We already have this definitive proof in the fields of actual, in actual real world evidence that this fine scalability is not really as big of a threat to Monero as it could be to some other blockchain. So yeah, I'm confident that's fine. 


Right. So at the end of the day, it's not really about trying to solve the problem where we could have more transactions on the base layer. Like that should be fine. We can continue to grow based on demand.

But it's in these use cases where I guess it's more so trying to save time when people are sending transactions, not so much the amount of transactions. It kind of explains what problem Greece will solve. Right. If we're saying none, they already had. 


go ahead. If you, if you've ever brought anyone onto Monero to show them some of the wallets, any form of wallets, if you try to send to help them send their first transaction, just to show them what it's like. The very first question you're going to have is, okay, I sent one transaction. Why can't I send another one? So every time you send the first transaction, you have to wait for the 10 block limit to happen. You got to wait another 20 minutes and people who are new to Monero, that's going to be the number one thing that they run into.

They're going to be stuck at that point saying, well, why can't I send another one? I just sent one. Why do I have to wait 20 minutes? And so they're going to see the error on the screen on their wallet and they're going to wonder what's run. Did I break it? I don't like this better. So, overwhelmingly, that's the most common problem people come into. We have very specific reasons why we have to have a 20-minute lock to prevent, you know, a second transaction. It was even mitigations. A lot of the wallets will keep a lot of spent outputs and split up into smaller amounts, but there's so much extra work you have to do. And usually, the very first experience with a blockchain is going to be the most, by far, the most important one. So, if people are getting turned off by the fact that you can't even send a second transaction for 20 minutes, that causes a lot of headaches.

And if you have a payment channel, that's not even an issue at all. So, that's an easy thing to do. 


It would just be the opening of the payment channel, which you'd still have to wait for that lock time, right? 


Oh, that's that's built into here. So yeah, there's the currency lastly, you know, currency stack, you'd have to wait with for at least one block to occur.

And at that point, you can go that point, you can then undo the transaction, just have it ready to go at any point. So


And at that point, you can just send, send, send as much as as many transactions as you want, essentially, without having to worry that you have enough spendable inputs or whatever sort of outputs, you just be able to go and flow. 


You can send as much as you want to. I try to calculate an upper bound, like some bit number 2 to the 249 or something like that. It's not infinite, but it's a very, very large number, so yeah. But you can do it.

Yeah, if you want it with no impact on your own, no one will see it. It's completely private at that. 


Right. So I saw people, you know, obviously posting about this on Reddit, so like a potential use case is if, I don't know, you're using some, let's say like a gambling website, right? I mean, there's obviously a ton of different examples, right? Sure. Rather than doing what people are kind of traditionally doing now, perhaps, which is like buying points on the website, which then allows them to gamble, and then they keep re-upping their points by sending in more Monero occasionally.

With this way, with like a payment channel, you'd be able to essentially connect, you know, open up a channel with them. Once that channel is open, then you can just seamlessly send them any amount of Monero as much as you want. Small payments, large payments, just going through the payment channel pretty much instantaneously, back to back to back. So you could just gamble all day long, right? Or whatever it may be. You're making micropayments to watch some content where you pay, you know, per minute, per second of whatever it is you're watching, right? Things like these ideas that people have often talked about with what the promise of crypto may bring, which really is not possible on Monero's layer one. Now with opening up a payment channel, those types of ideas become possible, right? Is that... 


Yeah, there's basically three use cases that I've listed out, but there's some more you could add in. The first one is to simply bypass that 10 block lock at the very beginning. If users are turned off by that limitation, if you have a payment channel between somebody who funds a user for the first time and the other, so you can just send input and amount back and forth. They won't have to have a headache.

The second one is a terminology that's common in decentralized exchanges called TVL, total value locked, which is to say that one party can show to anyone else if they'd like to work with it. They do have a certain amount of a token available. It's available. It cannot be used anywhere else, so it's exclusive and it's there, so you can prove at any given point in time that that fund does exist. That's useful for DEXs and other things, but Monero doesn't support that inherently. But if we do have a payment channel, even if there's no actual payment set between any two parties, you could say, I have now locked in this amount of XMR between each other. At that point, both parties will know that's the actual amount that's there. It can't be spent elsewhere, and it's actual XMR, Monero itself, locked specifically.

The best part about this is it's adapted. You can unlock it at any point in time, get the full refund, or you can do whatever you want with it. But you're proving that you do have a TVL. There are some other ways, like you give somebody else your view key and you hope that they can see some of the inputs and outputs, not all of them, and you hope that they don't just double spend attacking, things like that. There's ways that do work where you can kind of get that to happen, but it's simply not as good definitively saying, I have a definitive lock. I know as two parties here, this XMR, this is stored, it's definitive. It's not going to be unlocked unless I choose to have it unlocked. It's just there. There's other technologies, like a cross-chain communication is going to become much easier because you know that two parties are going to be there. So yeah, something like, for example, in your case of where you have gambling, if you want to prove reserved, you actually do have a certain amount of XMR before you enter it. That's there. Very cool. Very cool. 


And then, arguably, Monero on its base layer is built better than Bitcoin in terms of adding payment channels, right? Because in Monero, it is always super cheap to transact, so there isn't this high cost of even opening a payment channel.

Because of its dynamic blocks, you could have a bunch of people opening up payment channels at any given time, so the onboarding process, right? Because that's always the criticism with Bitcoin too, right? Like, all right, LN, Lightning Network sounds great, but it would take 100 years or whatever it is to get everybody to open up payment channels. With Monero, you wouldn't have as much of a bottleneck there ever either, right? Because you have the dynamic blocks, so people can always open up payment channels that haven't to wait in line. It would always be cheap to open them up because Monero will always be cheap to send. Give us some insights there on Bitcoin versus Monero with regards to how payment channels will be effectively working. 


Well, I just wanted to know something about Monero. The transaction fees for any transaction are so low that, yes, theoretically, using a payment channel, you won't have to update. You don't have to have the minor fees occur, but generally they're so low. It's like not even really that big of a deal.

Of course, we say that as people who are familiar, you know, have some, the actual transaction fees usually are about like four cents US dollars or something along those lines, but if in a different environments, different locations, that actually might be a lot. So this could be valid for that. But really, because of all the advantages that currently exist with Monero side, it's, there's no costs from doing this. The whole point of the major entire process here, where we're dealing with a payment channel, is that there's the channel open and the channel closed. In between those, anything can happen. But we always know the very first transaction is the very last one. And so basically what's happening whenever you're updating this, you're always getting ready to send the closing transaction at any point in time. You're always ready to release that, but just not yet. And both parties have to agree to finally release the channel update, which closes everything. So yeah, it's really the clothes that we're racing for. 


Lucifer is asking, can this L2 come under someone's control, right? That's always one of the criticisms of Bitcoin's lightning network. Now that you've moved to a second layer, people have to run these hubs, right? Who's running them? Is it only going to be a few parties, like large exchanges? Give us some insight into there.

I mean, is there any concern that a layer 2 makes Monero more susceptible to being co-opted, especially if everybody starts moving over to the layer 2 and leaving the base layer? 


The nice thing about calling this a protocol, not an implementation, is that there's going to be many different implementations. And so there's no one particular, there's no one L2. Much of the problem with baking everything, the entire network into the standard, like the other L2s, the ones that are there, is that you have, you now have introduced a point of centralization. You can increase the amount of speed or speed and things like that, but now suddenly you're centralizing. And that's true.

You have a trade-off there any time you're doing some implementation there for payment shows, like how much centralization you're going to. In this case, the centralization is about as close to zero as you can get, but it's got to be there somehow. As far as an adversary taking over a particular implementation, yeah. Any two people can at any point create a new payment channel, whether one of them is an outside agent or not, I can't say. But the same agent could be connected to multiple people. You can't really say, you'd have to communicate for everyone. At any given point in time, you're going to have to have two peers connect somehow. This doesn't define how people connect. You just have to have them connect somehow. At that point, it's like if you don't trust the other person, you really don't have anything here. This isn't a magic. It's not a magic solution. You have to already be in agreement with the other person you're going to be communicating to. Once that happens, you can make the actual payments occur really quick and easy, but there has to be some trust there.

If someone does, it is possible, I even mentioned this in the talk, it is possible to take the current design of Lightning and actually put it into play using grease. At that point, all the path riding problems, all the issues that Lightning has just become a problem. At that point, yeah, I'm sure any issue that anybody else has will happen. You could do that, but I don't think it's a good idea. This is a very specific case. You're going to want it from very specific situations. It'll work quite well for any of those specifics, but you don't need some overarching centralized system. That's not easy. 


Give us a little bit more insight there. How is Bitcoin's Lightning Network designed in such a way versus what we're proposing to do here?

How are you avoiding these issues and what is it specifically about Bitcoin's Lightning Network design that makes it problematic versus what you're proposing here? 


specialist in Lightning, but I only know some of the major critical points, that Lightning is a proof of stake, meaning that's people who have a particular amount in their channel, in their communication network. You have evidence, you have proof that that particular channel was open using a certain amount of Satoshi. And at that point, whoever has that amount locked in there become kind of the more important note because they have more to lose if this routing happened. And the major issue they're having now is called intractability of routing.

Given any particular entry into the one Lightning network, how do you actually get to somebody else? So you're gonna have to have problems, you have to have, there's a bunch of different technical solutions like a, what do they call it, distributed hash table and other things. It just becomes very difficult. So even entering into the network can be a pain. Again, I'm not the best person to describe this, but it just becomes a complete headache when you're trying to enter in, find somebody else you can connect to and get to the nodes. So it's a combination of Lightning, a combination of payment channels, but also proof of stake protocols, and also routing protocols for mixed debts. So there's so many different things going on concurrently that any problem with one of them just magnifies all the other issues that you're having. So I can't be an expert and say this particular thing would change, but yeah, all of those things going on concurrently while you also have to have to have timeliness and availability.

One problem in all things goes collapsing down. So there's a lot of extra work in that. Like if there's a bunch of variables, they have to constantly be connected online, which is not that great of a requirement. So yeah. 


Right, the real issues come with kind of this hub and spoke, spoke model where it's not just me and you opening up a payment channel, but I'm trying to go through you to get to somebody else to get right. That's, that's where you're really running into issues with lighting with what you're proposing here.

It's really just between two people that are opening up payment channels, which Lucifer's asking. Yeah, I'm asking you about a third per, you know, is there any situation where there's like a third party involved in this, but it's, it's really, it's, it's going to be between two peers that open up a payment channel, just between the two of them. Right. 


Yeah, that's the major design, and I think that's going to be the most of the standards. But there is a third, you know, the whole point of this in theory, the beauty of payment channels is you can simply begin acting as a relay between other two parties. Let's say if we did want to have a party, excuse me, a third party involved here, Alice, Bob and Charlie, Alice is communicating to Bob and also communicated to Charlie. Suddenly they let Alice know, hey, we'd like to communicate with each other. We want you, Alice, to act as a relay. And in that case, yeah, that could happen.

You could have a central hub that's unable to magnify. The beauty of that is you don't even actually have to have a mineral transaction between Bob and Charlie in that case. The third party Alice here can simply change the amount inside the pre-existing payment channel and say, now you owe this other person this amount so you can split up what's currently there. That's the beauty of the bidirectionality here, too. You can just keep updating back and forth on behalf of someone else. Those updates would be atomic and you can handle that. And that's basically what I think people are asking for when they're talking about like having an L2. Like you'll have a third party that acts as the next level up as relay. It is possible to do that now. There's there's costs and consequences. So there's a lot of lively guarantees. You have to make sure that whoever's there, like Alice, for example, would have to be live. Bob and Charlie, they don't have to be live, but Alice should be because of communications frequency and a lot of requirements to make sure everything occurs. They're going to start being entered into this. Whereas any two parties you could or could not be live, you don't have to be. This can go on forever. But with a third party, you have to have guarantees that somebody isn't holding the whole thing hostage. So it just becomes a little more complicated.

But with the design that exists, it's doable. And I see that being as another thing. Like if you want to have someone who has this, the concept that the TVL is actually, I think, really important here, like you mentioned before, instead of buying tokens or something else, which can then become another point of failure. If you have a way of two separate parties proving that they have a TVL between each other, you could have a third party come in and act as a communication expert who then handled the relaying of those updates back and forth to each other. And then you can simply advertise, yes, I approve. This is my total value lock and this is my total value lock. So now with that together, you can share and begin transacting for something. If I see some sort of market being able to handle that, but that's just for that one case, that would only be for that one market. There wouldn't have to be a huge amount of overhead communicating to every other node everywhere else. That simply isn't necessary. 


Sounds good to me, man. So when do we start?

Oh, well, what other kind of, you know, what feedback have you been getting on Reddit and at MoneroKon? Are you getting positive feedback? What did the devs say? What are the smartest people in the room saying? Your peers, not people like me, not the, the Hoi Po Loi. He was like, no, no, no, no Lightning Network for Bitcoin. It'll be, you know, it'll be take it over. What are the smart people saying? 


If the truism that you only learn from errors and mistakes, if that's true, then cryptocurrency in general has a lot of learning to do. There's a lot of mistakes that have been made in the past, and the beautiful part is whenever something doesn't go right, which is common, we can learn from that and make sure it doesn't happen again. So there's been a lot of sensitivity to make sure that the same mistakes that have happened with Bitcoin and Lightning don't happen again. That is a deep concern, and it's very intelligent, the right way of looking at this.

So the major question has been on this, like, is this going to be an L2? They're going to cause all the same problems with Lightning. Why would we need this in the first place? So those are very good questions, and they're straightforward, and they're good, and I think this is straightforward. Those questions are saying, you know, result. This is not going to become Lightning. There's no scenario where you want to have something like that. So yeah, the lessons that we're learning there is enough to say we're just going to avoid that entirely and not go down that path.

It's not necessary. It didn't improve anything. Yeah, that's the big issue, and it's good. I'm glad everybody's asked. But then now the next question is, like, how do you use it? We didn't want to do this. And so that's part of the implementation. Who does want to use it? We know that the wallets are always having pain points with new users, that there's just people complaining because they don't know any better. The first time they get some XMR in a wallet, they want to go spend it out to a bunch of people kind of for fun. They suddenly they can't. And they're going to be confronted with, well, do you want to make this a small, like, sub-sex? You want to receive this as multiple separate V-outs and things? They won't know. They just simply don't have the ability to understand this. The users want something that's a UX easiness that it just happened. So the first time a wallet goes in, maybe it's going to help them set up a payment channel to say, hey, this way you can send a value out to a bunch of different people. That could just simply be another pop-up that shows people how to navigate through that. So that way they'll at least have a path where they can go down and where, hey, you didn't do it the right way because you're just brand new, or alternatively, you can help us kind of, like, we'll hand-hold you and make sure you're doing it right the first time. So if that path exists, I'm sure a user experience would be very much improved.

So we just don't have that problem where people are complaining about that 40-minute wait time. And if they get more expert, then they can abort the event in the first place. But that's kind of, that's, that's, you can't expect brand new users to understand all this. 


Slave blocker saying you just have to wait one block about reorgs. Would that not invalidate the the layer 2s transactions? I don't have more for super guys. No worries.

They blocker and others though We do ask that, you know, if you're gonna send a question, please use XMR chat You don't have to send a lot. We just want to we want to use it guys We want to use the network so you can send 10 cents send your Monero based super chats Via XMR chat comm slash Monero talk.

We have one that just came in But yeah, if you go ahead and answer that question, how can it only be One block that you have to wait when you open up a payment channel and then I'll bring up the next question


Oh, yeah. Oh, by the way, well, I mentioned that this does work with the current CL sag design, but unfortunately, there are trade offs like, for example, that's a trade off, the way that this works is the 10 block limit, the 20 minutes is there for reasons there to make sure that re herbs don't happen. So in a payment channel situation, if we do set this up at currently feel sag, what we can do is we we technically have to wait until at least one block half. So you have to have at least one block because of the way that's the effect. So you're gonna have to wait at least like basically two minutes or however long that is. And even then you're it's it's precarious.

You have to assume that's the case, which is why the design for sales, I have to include a bunch of extra safety protocols in the background, you actually in generally what we're doing here, just the technical info is we're creating a choo choo wallet, you have to have two, two signers go there. And that's what your peers are. But in this case, we're going to need a third party. That is a backup. So you need to create a two or three wallet in case your actual funding doesn't work right. We have to refund those and go back in. But yeah, that's that's going to be necessary. With the current design transaction chains, get rid of that entirely. You don't need that. But yeah, if you're waiting for one block, you have to wait for the two minutes if you're gonna wait for 10 blocks, you're gonna have to wait 20 minutes. So however much time that takes, that's the trade off for using the current field size. And there's no way around that technical. So if you're asking it, like, what, how can you be sure about the rear not happening? Well, just wait 20 minutes, make sure it requires at least a 10 block exploitation, then you're good. But you're saying with weeks design, how much risk you want to have in that case, that's an implementation detail. 


Okay, okay, so you're saying you know so with opening these payment channels theoretically It's open within one block, but for security reasons you may want to wait the full ten blocks, right? 


Yeah, so that's up to you. It depends on your situation. If you're relaxed and you don't necessarily trust everybody else, just add time. Add time to the system, wait for the actual block to be committed, then you're good.

But if it's somebody you know, it's a small amount, et cetera. One block's fine with the currency. And I also want to agree, once FCMP Plus comes out, we don't need that at all. That problem goes away entirely. 


How could something like this be implemented? Let's say like at Monero topia, we have a big marketplace going on. We have a hundred vendors. We have every hundred people there to all looking to spend Monero.

Is there some way we get, you know, obviously opening up a payment channel with each separate vendor wouldn't solve the problem, right? Cause now you're just waiting to open up a payment, but is there some way to kind of all go into one market system, one Monero topia market system? And then from there, it may be exactly what I mentioned. 


about being the market situation. If you have a market, literally everybody's there. You can have a semi-trusted, the Alice that is the semi-trusted person who says, okay, I'm going to open a channel with all of you. And by the way, I'll relay things on your behalf. So you don't even have to hit Monero L1 at that point. You don't. You already have everything locked. You're good. It's all there. So I'll just simply relay everything for you. Because at that point, the semi-trusted authority, Alice is known to everyone that you simply go through there. That's perfect.

That way, you don't have to worry about all these distributed hash table updates or anything. You're literally right there. So it's just so much easier that way. And nobody ever hits a chain except for the very first establishment with Alice. 


during this. So practically speaking, if Greece were to get off the ground, when can we potentially see Greece get implemented, get off the ground?

Is it all or after full-chain membership proofs? It doesn't make sense to try to get it going now pre-full-chain membership proofs. 


right? That's an awfully good question. Imagine there's some form of event going on early next year where we have a semi-trusted market system going. Even with current CL site, even with the problems that were just mentioned about the one block confirmed, that's still doable. We can still get this to happen.

There's no technical limit for that. There's a lot of UX limits. I mean, there's a lot of headaches you have to deal with. Like that waiting for that block is going to be a pain. Like people are going to be waiting, okay, I got to wait, I got to wait, and eventually it'll show up. But as long as we can get past those UX limits, then yeah, it is possible. There's nothing different. Monero won't change so much that it's like suddenly you've got it massively possible. It's just getting rid of those headaches. 


And what would the implementation of obviously the wallets would have to do things on their end, right? 


or this little has to be baked into the wallet. And that's one of the things I wanted to talk about the concept of the protocol.

Every wallet can have its own unique design. Like Monero's you write the unofficial version of the wallet in order to avoid those payment problems that actually splits up your outputs to a whole bunch of different small ones at any given time you have a whole bunch of transaction. That has problems in itself too. It becomes really easy to identify when somebody's using the mobile wallet there because you can see, you can actually on the blockchain you can see how many inputs they selected and how many outputs they have that's something to be identified. So from an operational security perspective, it's like not ideal, but if you're walking around the wallet you really probably care about that anyways. Yeah, there's different ways and so every different wallet would have a different user system that they don't want. So you're gonna have different requirements and different implementation details like that. 


Potential privacy concerns or being able to identify people that are using this versus people that are just staying on the base chain. Are there kind of attacks that could happen in that regard? 


Oh yeah, whenever you're dealing with something that's going to go over the event, you're going to add a bunch of extra exposure. Um, the whole point is to try to minimize things.

Um, just on that, an appointment, you're like one of the ways around, um, making things more convenient from your perspective, you can actually sacrifice identifiability on Monero, so you can have a bunch of the end of the, all, all sorts of different, extra larger transactions, those pick out like a sore thumb and block explore. Uh, in this case, what the goal is to do is to make it as the most common possible. There's a two in, two out, I think is the standard terminology here. Uh, so even in that case, no, again, you can implement this differently, but generally we want to have a two in, two out to make it look like any other random Monero transaction to make it completely baked into the background. That's the better off deck. In that case, if we can do that, yeah, let's do that. So yeah, there are some, there are some scenarios where it might be a little more complicated, like if you, if you're refunded transaction, you're going to have to do some extra work and it's going to look a little bit different. But, um, uh, whatever you refunded channel is going to look differently. But, uh, generally the standard payment channel is going to look like any other random, you know, the most common transactions that go on the background. That's great from every perspective. 


Uh, I don't want to miss this Monero based super chat and we're told to four cents is the third party chains necessary for Greece with bull chain membership proof. Plus plus update or will the Monero chain be enough?

My question was meant to be centered. Okay. Yeah. 


There is a major, there's always gonna be a trade-off with the blockchain trilem. There's always something that has to be sacrificed no matter what you do.

Monero's so good at the base level of security. There's certain types of things we know. There's no way, our fundamental rules, we cannot violate Monero's security. So there's nothing in here that would allow that. There's no way anybody can identify anything from the Monero perspective and there's no way any users can have anything lost on the Monero side. Like you're not gonna show your entire history of your transaction at any point, anything like that. But there's gonna be some trade-offs. So what we did is we chose the centralization issue.

Now one of the problems is Lightning, for example, chose to centralize a lot. And so in this case, that centralization problem, it's an issue. Here, we have to have some way of resolving that. So we're gonna have to have some trusted part. Like I said, in the case of CL-SAG, for example, if you wanna get this to work correctly, you're gonna have to have a third party that becomes a third entry inside this wallet because you'd have like two out of three wallets to make sure that third party then monitors and orchestrates your input. So somebody can't come in like a greasing attack, try to not send you something and then close the channel. You have to have some way of refunding something correctly with CL-SAG. In the case of FCMP, you don't have to have that aspect. That's just one centralization aspect. There's another one. The big issue we have here is that in a payment channel, because there's no timing mechanism, there's no lock on the main layer. There's no way to say that we can undo this particular transaction after a period of time.

So we have to have some way of saying, okay, because two peers are communicating. Eventually at some point, one of them's gonna say, okay, I'm done, let's close this channel. And you can gracefully send the information they need to actually finally send up that closure transaction on the Monero. But it's possible either intentionally to do a brief attack someone by never releasing that information they need to close everything. It's a hostage situation. Or more likely somebody just lost their device and so they can't actually figure out what's going on. They wiped or something. Or they forgot their password or something. So at some point in time, you need some form of live in the studio. You need to have some third party that comes in and says, okay, let's actually unlock this process. And so what we've created is this thing called the Key Estro Service, KES, which we think is gonna work on a ZK enabled blockchain, like Ethereum or any other ones you want to use. We were using Aztec as our, just a base example, but it could be implemented a bunch of different ways. 


I happen to be a fan of TES, that trusted execution environments, which they're good for very high scalability and things like that. You could use that. You wouldn't need a blockchain in that case.

Because if you're gonna go with a separate blockchain, you're gonna have to do things like create a new wallet and stuff like that. All of these issues are addressable. We can always resolve that. There's gonna be some third party outside device that can then verify what's going on. In this case, you need that third party. If it's powered by, let's just say it's powered by Aztec, a ZK world chain. You'll need somebody actually reserves gas on that network and is able to say, hey, store onto this data. You need to, so somebody have to fund that. In the case of our example, we're saying somebody goes into a merchant, a customer and merchant, the merchant has all the systems up and running and the customer just needs their phone to scan. So the merchant would be responsible for setting all this up. So they'd work with the chain and the smart contracts and all that would happen. And basically what'll happen at that point is you have a timer. Whenever the last transaction occurs, the communication is we're gonna now have a timer after a day, a week, where if the two parties, the two people don't interact with each other, somebody loses their phone or they intentionally are harassing others, not updating things. After that period of time, the smart contract is then active and any of the two users can provide evidence that this person is not communicating with you. They went offline. And then that third party, the key express service will then use a judgment call based on the evidence provided and say, oh, in that case, I'm gonna reveal some critical port of information that you can actually close the channel and they'll reply back with that. But of course, what this means is that two parties in that sense need to monitor that somebody isn't doing a false attack where they're saying, oh, I wanna close this channel. And the other person has provided, they provide the evidence that I didn't communicate, but I'm still here. So every once in a while, you're gonna have to need to monitor for that. The important thing to understand in this case is that even in a case where somebody actually does an attack where they close the channel unwillingly on you, they can't ever get your coin. This is intentionally designed to make sure that nobody ever loses anything at a given point. You can't get rid of anything you've already updated. So whenever an update occurs, it's set in stone. So at any given point, your last transaction is ready to be committed to Monero. And at any point in time, you can either willingly close it or they can go through a separate effort and try to get it to that point where they can then close it. But the worst case scenario is you just, your coins get refunded to you at Monero. 


So even if you say lose your phone, the whole thing occurs and you come back later, you find your phone again, oh, I can log in. Well, my channel is closed, but my coins are still there.

So even in the worst case scenario, your own is just getting your coins back. So nothing damaging. 


Uh, somebody said, would this support something like LN URL pay codes that can be used standard ad for, for standard NFC, similar to Bitcoin's bolt card? Yeah.

A nice admin aeropopoeia with your little, you know, Venera, Venera topia card, ding, ding, ding, paying, paying the vendors installation. 


Like in that specific case, that would be fantastic. If there was an easy way to do that.

I imagine this being baked into the wallets. The wallets can come up with their own standard and if the wallets are all cooperative, we can crawl up with a pretty good network that does that. But it'll, it supports that, but it just hasn't defined exactly how that happens. So it could, that's the best answer I can give you. Awesome, man. Who else is involved in this with you? Well, me and CJ were the ones over there talking about it. And that's pretty much it, yeah. 


That's us. But in terms of contributing to the proposal, whatnot, it was really just you and CJ. 


Yeah, we have a meta that based on just what we came up with, which is some really good idea. This, this is based on a paper called MoNet, M-O-N-E-T, which was based on some new technology that came out a couple years ago. It was a PhD thesis, and the math for is actually wonderful, beautiful. We, because of the design, it wasn't very specifically tied in to Monero, it's somebody who understand the math very well, but nothing that works very well.

And so they needed a lot of implementation because there's a lot of blocking the bedroom can waving, or they just said this, this happened. So this the math, while beautiful was used, it was used to, well, more classical technology. It's a prime factorization group of unknown order space, it's complicated, but it just wasn't the latest and greatest. As like I said, like the whole zero knowledge proof systems been advancing so fast. And that's also been proven to work, you might as well use some of the newer things that you can bypass a lot of those, roll your own crypto problems that some some papers have. So instead of using the new and innovative mathematics that we're using, we're instead using taking their concept or protocol and putting it into play with some of the more well established turn complete circuits. 


Yeah, I mean, if you want to give us maybe a little bit more insight then into like a texture of how this thing is functioning under the under the hood. 


Right, yeah. The basic implementation, the default information we're doing is we're taking, we took Sarai DEX's wallet implementation, it uses the froth standard to create a two of two wallet, meaning that the two peers then each have the ability to cooperate, and both of them get like the public keys, the private view key, but not the private spend key. So you can always take a look at it online on the transaction and take a look at whatever's going on. But you can't cooperate, you can't actually spend anything from that until you combine both of your, both of your wallets to actually say, yes, I'm going to sign this. And that's all nice and good.

The problem with that is you can never guarantee that the other person, like if you if you cooperate in a signature and stuff like that, you can never guarantee that the other person is going to sign a transaction that you want. So what we've done is we combined that with another tool that's useful nowadays called an adapter signature. So what we're doing is we're have Mr. Rai DEX's two out of two wallet in his after signatures, which each user is going to have at any given point in time, any given transaction, you can take it and split it up to basically one transaction and become a two and two transaction. You need that. You need two pieces of information to submit that transaction. You always need the signing, the private signing key in this case, because you're using an adapter, so you need the adapter secrets. So what you do is you take one transaction, split it up into two or two key. But because we have two or two wallet, we actually have a four or four system. So any given transaction requires four separate pieces of information to be released. And the way that the after signatures are, this is wonderful. It's called the commit, prove and reveal protocol. I think in point in time, you're actually setting up to your adapter signature. You're providing the person who's looking at this with proof. You're saying to them, this transaction will work. And I have this secret behind the scenes. It's a private key. And you could submit it, but you can't submit it right now because the signature that I have with my, um, had to have 19 PC. It would work, but you can't do anything with it yet because you're missing the one critical piece of information that would just immediately get it to work. So transaction as an adapter signature is great because you know it would work. You can prove it would work, but it just doesn't work until you get the last, last bit of information. So with that, this two out of two while it's not becoming a four out of four wallet, they didn't give important time. Any party has three of the four pieces of information. They're always tantalizingly close to actually closing the channel. I didn't give a point. You just need one more, one more bit, one more little bit of information. And that's kind of being held in reserve by both parties. You're keeping that part secret. So the transaction is ready to go in any instant. Once both parties have that adapter secret, they just need that one last bit and then you can submit it over to Manara close. 


So what you're doing is you're constantly changing the transaction close any given any given layer. You're saying, okay, that was the previous one, but now we want to update. We want new output so that the same XMR as Laxer goes, different people at a different amount. That's our update.

We're changing that Delta and then we'll sign the whole thing, prepare to release it. We just won't have that last bit of expertise to go out. So that last bit that you just that one little thing you need, it's always there and ready to go. But you just didn't release it yet. So there, but once one party has it, they could just push that right to Manara when they're done the transaction. So the containment channels closed transaction. 


Sean, this hour went really fast. We're almost at actually an hour and 20 minutes already. And I think we covered a lot.

To round it out, and I kind of asked this already earlier, where do you see this going at this point, given the feedback you're getting, given the current state of Monero that we're waiting for full chain membership proofs to be implemented? Like you said, it could theoretically already. We could start to play around with it now, potentially implemented now, even pre full chain membership proofs. How do you see this all playing out? Does Greece eventually get implemented? When? In what form? What's your current kind of take? 


But I know for certain that a lot of people would want this in their wallets right off the bat that way You can set up a payment channel as an example for somebody else So anybody new to the experience can simply start going live with real value at XMR and just immediately interact with someone So I see this is kind of like a my intro to Monero If you're with your friends if you want to introduce them a wallet instead of having them, you know Send them some XMR, but then instead of having it so that they have to like go through the UX headache of trying to send You know wait 20 minutes or so immediately establish a payment channel with them say hey We can send things back and forth good that'll work You know just because somebody doesn't actually have any lack mirror the original chain doesn't mean you can't actually establish something I left that a little We decided to leave that a little bit open where just because there's a party there as long as they actually have a Monero key They don't actually have to have any lack XMR You can have a value of zero and at that point you just basically start sending with people even if they haven't actually got


Oh, that's important. I know somebody who has no Monero can open up a payment dental. 


Yeah, because they just have to have something that's as valid as the release Monero address. And that's good.

They don't have to have any input that they don't want to. We left out a list. It says you could optionally do this, but we don't expect it to be the case. It could be that way. Because what will happen is the end of the output when everything is unlocked is that transaction will close in that other address. The person who had nothing on the blockchain at all, that will have its first payment at that point. And it looks just like any other two-in-two-out payment. So it's as though they just were a new user at that point. 


And so, but like what would the path forward look like? What would the first implementation of this look like?

Is it getting the wallets on board? How do we move this forward and start to see it out in the wild live? 


Uh, the, the possibilities are endless. Maybe I, uh, this is called, this is court requested as far as it going live. I, I don't have that info. I'm so busy with the technology and having my heads out and trying to get it to work that I don't, I don't know where it's going to go.

I, there's plenty of business cases. I imagine this is going to be part of the, yeah, they're called atomic swaths right now. There's a lot of headaches that go into that, but I imagine Dex is going to want this because they want to implement this. We'll have a total value lock, a TBL, something that they need without having to go through a bunch of other headaches. If they can get a TBL, it's going to be very easy to set up some form swaths right through the existing deck. They're going to want that. Um, as far as the markets. 


like a Sarai Dex would want to potentially. This would be very useful. Yeah. 


Okay, because you know before in generally is really difficult to prove how much whenever you have because even if you give a private view Key which by the way, that's another one of the plus pluses that's coming up You're gonna have a private view key that then you guys should look at output So you can always get a good balance But even in the case of that's the MP plus plus you can never guarantee That's the other party isn't gonna take sure they can show the view key But they already have a bunch of transactions ready to go So right after you're done like if there's a few seconds do something else is gonna don't double spend there You're immediately gonna get rid of the transaction. You can't lock anything currently.

I'm an arrow So this system would allow you to have a value that is locked and that's that's different That's different than anything else that's happening. So even under the worst case, you know, you don't guarantee they can't spend this It's not going anywhere unless they authorize that which is it really is unique There's nothing else that's doing that right now unless you have a trusted third party that has a separate wallet and all these other things It's a it's a very low trust way of being able to do its UBL And so that I see that going that's gonna go somebody gonna know you down Very cool. Very cool. And then hard the markets. Yeah a local market where you can actually have the out You know the Alice be the relay, right? I I Want to see that happen. No one says it happened. Yeah, that'd be beautiful


That'd be awesome. But that's really going to take the wallets to step up and partake and implement. 


This is the wallet level system because you do need to have, based on the requirements, you do need to have a way of the two parties actually making sure you get your transaction. There is a wallet implement, but the way it is right now is just independently, it doesn't have to be integrated into a wallet. It could work with a separate system, like you could just have some interaction and it would work out. But you do need one of the peers, it does have to be connected to Monero to check to make sure that everything is there.

The way CLSAC works currently, you have to select decoys, so everything has to be live and there's some other headaches with that too, but it couldn't work. So you just need one party connected to the internet to a Monero node and that's it. So it's probably much easier to do this inside of the wallet than anything else, but even if let's say another chain has a DEX or something, they're going to have a no connection. 


And to clear something up, because you talk about the scenario where it's great for onboarding a new because now you open up a payment channel with them, send them Monero. As soon as they have it, they could send it back to you, start to use it.

But can they go and turn around and start to use it somewhere else? Or that's... 


Oh, when you're, when you're in the channel, you're only talking to the other peer that's in rail. 


Right. So that doesn't really solve, obviously, that problem. It's just now you can flow back and forth with that one other user, right? 


Yeah, but once once you close that channel, once you, you know, willingly close that transaction will go back up and in your regular wallet, you can just see if the funds are there, you can do what you want with them. Of course, you have to wait 10 blocks.

It's so that doesn't sell that headache. It makes it so yeah, right bypass. 


Right unless we're doing like we're talking about with this marketplace, and you have everybody going into one Wondering hub right and then right then you can send things off All right, man. Yeah any other information you want to get out there with regards to Greece or anything else


Oh, I just, to me, this is the, this is Monero growing and keeping up to date. It's dusting off, you know, the, so there's somebody who was like the state of the art before coming back in and showing the kids what's going on. This is getting Monero to work with all the latest things. I mean, both with FCMP plus, but which really even the critics are now saying they really like that. That's great news.

And then also with this, this can be the first of many other new technologies that keep Monero keep it going. Oh, by the way. So one of the, one of the questions was, I'd heard, it's actually pretty intelligent. Like why choose DK Starks instead of DK Starks and some other post quantum favorite things. Monero as, you know, as it's designed, even with the updates, it's getting better, but there's still, you know, quantum computing problems. They haven't gone away. So the concept of like, you know, post quantum things, that isn't necessary to solve right now. It's still a while away.

But in theory, you could have a newer wallet design and this wouldn't be affected by this. Nice thing about not baking the technology into the protocol. It can be virtually upgraded at a later point. So to use that. 


Oh, yeah, yeah. So from a quantum perspective, would this be quantum proof, the payment channel itself? No. 


Um, because there's no implementation details, it could be there is technology. That's that allows for zero knowledge groups called Starks with a key. That's where you see the team. You get that right.

Okay. In that case that you can just upgrade everything right to that. It's fine, but it also means that the existing payment channel would have to close and get upgraded, but yeah, whatever that's just the conditions. 


Okay, awesome Sean anything else you want to get out there? I'm so glad you picked up the ball and started to run with this I mean what what yeah, what really inspired you to say you know what it's about time somebody Creates a payment channel implementation for Monero.

What was kind of the inspiration there? 


Well, uh, the talk had been going in the background for quite a while. I mean, this paper that's based on, at least, at least two years ago. And it was wonderful, but we just, nobody figured out if it's worth the effort.

Like what would happen? How do you get to specific? And so after a while now, there is just a lot of, it's just too many headaches to deal with certain cases. And there's so much opportunity that the technology did adapt. I'd been hoping to get something like this happening for a while. It's like a personal passion of mine that I wanted to happen. And a bunch of people got together and you know, we agreed, Hey, let's do this. Yeah. Um, it's, it's in the air. It's in demand. It's possible in the technical solutions are very reasonable right now. Um, the other technology that we needed just finally caught up is there. So everything's going. Let's get it done. 


Sean, man, thank you so much. Really enjoyed talking to you, as always. Hope to see you in person.

Mind it. Count on it. What's that? Count on it. Yeah, yeah, yeah, for sure, for sure. Looking forward to a Hangout session. Thank you so much, man. Yeah, once again, anything else you want to get out there where people can follow you? I know you're not super active on X, but now we kind of put your handle out there for those that want to engage with you. Other places people can find you, or just keep up with the developments that are going to be happening with Greece. 


Well, you might see me around maybe maybe sometime in February. There might be somebody I've been showing us some place So no, there we go. I'd I try to keep my future plans. I'm adaptable.

I'm gonna be around you'll see me more


Okay. Yeah. We'd love to have you at Monerotopia in February. That would be fantastic.

I don't think we'll have Greece up and running and the market running on it by then. I think that might feel a little aggressive, but perhaps there'll be some new insights on the path towards actually implementing it by then, right? Right. 


The project's looking for feedback, so if you have any issues you'd like to report, go right ahead. But it's definitely on a technical level right now.

It's going to be some time before this actually fully gets implemented by anybody, but that's up to me. 


And here's the best place for many people to provide feedback, I guess just on the 


It's on GitHub right now. Yeah, just look up grease-xmr and it will help right there. And grease with an S. 


All right, Sean, thank you so much. Greatly appreciate you taking the time. Love that you're working on this. And yeah, I'll see you around, man. Great. All right. Take care, Doug. All right. Adios. 


Hi, Monero Land, thank you for joining us on this week's episode. We release new episodes every week.

You can find and subscribe to our show on YouTube, Odyssey, iTunes, Spotify, or wherever you listen to podcasts. Go to MoneroTalk.live for a full list of places where you can watch and listen. If you want to interact with us, guests, or other podcast listeners, you can follow us on Twitter, Mastodon, or any of our social media platforms. MoneroTalk is also made possible from contributions by viewers and listeners like you, and supporting us is easier than ever by typing in MoneroTalk.crypto in your Monero.com or cake wallet send address field to send us a tip. Once again, thanks so much for listening and we look forward to being back next week.