Doug 
All right, Luke, what's going on, man? 

Luke 
A lot! What time span are we discussing? 

Luke 
You know, nothing much. Home with the family for Christmas. I've been spending the past few days with them. And we kind of split up to do our own things today, including me spending this time to record an episode. 

Doug 
Fantastic, man. Are you? Thanks been with you. Oh, it's been a whirlwind over here. We had a baby about a week or so ago. You might hear some congratulations. Thank you, Matt. Thank you. I think you see to my face, very happy. It's been a fantastic journey so far, and I'm looking forward to the rest of it. She's amazing.

I won't go into too much detail, but to say we got the happy, happy, healthy baby we were wishing for. So yes, thank you, Matt. Thank you. And so I'll still be around, guys. Don't worry. I'm not going anywhere. You may see a little bit less of me or just kind of focus on things in different ways, but hope to continue this show and the Monero Topia show with the same vigor.

Definitely all the projects I'm working on will be full speed ahead. If I slack anywhere, it would be with Monero Talk and Monero Topia shows, but hoping to not do that either. And Luke, on your end, we'll get into things on your end. I know you had put up a post a couple of weeks ago about you, quote, unquote, stepping back. So we'll get into that, what you meant by that.

I think that caught a lot, perhaps caught some people off guard. Anything you say, right? We all listen very closely whenever Luke talks. And to hear you say those words, or there was questioning going around, what do you mean? Is he quitting Monero? Has Luke moved on to other projects? So we'll get into that. But yeah, I mean, where shall we begin?

If you don't mind, maybe we could kind of maybe start with full chain membership proofs where we're at with that. You got so many things on your plate. There's a couple of prime things I want to cover when I have you. I know you might get sick of talking about some of these things because everybody's kind of asking the same questions, but it would be nice to get an update of where we're currently at.

I know you recently put up a post. Yeah. 

Luke 
Fair warning though, on my end it says there's a recording error. Oh no. 

Doug 
Um, do you have that on your end? No, I think we're good. We're good. Maybe it's just you're Yeah, yeah, I think we're good. We're we're live. Um, everything's up. It shows. Uh, what is that? 

Luke 
If you're confirming it works and want to continue, I'm fine doing so, just wait for this to end up- 

Doug 
lost a time no no we're good we're good we're good at the end just just stay with me don't don't jump off the stream right away okay you should be good we should be good I appreciate that though and if it is lost 

Luke 
the time then this will just be extra special for whoever is watching live. So regarding full-chain membership proofs, I said at Moneratopia that I was hoping to have my work on that submitted by the end of the month with regards to what was known as the development CCF. So with full-chain membership proofs, specifically full-chain membership proofs++, there were actually two CCSs created for it.

There was the development CCS, which was to develop the new full-chain membership proofs plus privacy composition. And that was all of my work that I myself did as a programmer. And then there was the research CCS. The research CCS was to do the academia necessary for all of the development I did and also handle the audit of all of the development that I did.

So what's notably excluded from those two CCSs is the work that's being done on integration. And integration has been primarily led up by Justin Berman at this time. And then also Jeffro256 has been working on Carrot, which is a new addressing protocol, full thing. And Jeffro256 has been working on that. So it's not that there aren't other development tasks.

It's not that there aren't other audits which will be done outside of the scope of these two CCSs. But with regards to my work on full-chain membership proofs++, it is defined by these two CCSs. One for development, one for research. So when I said I was going to be submitting my work at the end of the month at Moneratopia, I was referring to the development CCS.

And that covers all of the libraries that are going to be necessary for the new proof composition.

That is the full-chain membership proof itself, which is what replaces the ring part of ring signatures and makes it so when you're spending an output, you're spending one of any output on the blockchain, not just one of 16 that have been randomly sampled from the blockchain, along with the new signature construction. Ring FCMP++ proof composition.

We have the membership proof, which replaces the ring half of ring signatures. And then we have the signature, which replaces the signature half of ring signatures. And the really great thing about separating these two is it gives us a lot of flexibility and just increased functionality.

You will be able to sign transactions very cheaply without having to do the entire full-chain membership proof on, say, a hardware wallet. Because, you know, the existing ledgers, not even the newer ledgers, just the existing ledger nanos, those can do Monero signatures.

Right now they can produce our current ring signature, a CL sag, and they will still be able to produce signatures under full-chain membership proofs++. But if you tried to do a full-chain membership proof on this thing, no. I'm not saying it's technically impossible, but for all intents and purposes, it's not going to happen.

So that's really the great thing about separating these two is that we can use this more expensive proof for the full-chain membership proof. But despite using this more expensive proof, we can still maintain support for these small and low power devices, such as hardware wallets. 

Doug 
All right. Yeah, for those just tuning in, I'm here with Luke Parker. If you don't know him, you probably don't really know Monero that well either. You're just discovering Monero for the first time. Luke is here. He's reporting on where things are currently at with full chain membership proofs. We'll be talking about that. We'll be talking about his work on Serai, what we can expect of that.

We'll be talking about his comments he made recently about essentially sounding the alarms for Monero's need to upgrade in terms of its quantum resistance. We'll be talking about that and what the path forward for that may look like. And then we'll also be talking about Luke stepping back a little bit with regards to his work in Monero land and allowing him to define what he meant by that.

Obviously, he's still doing a ton of work. We're talking about Serai, full chain membership proofs. So what that could even mean, I don't even know. The amount of work Luke has done and is doing for Monero is just unfathomable in terms of trying to quantify it in any real way. So yeah, sit back, enjoy the live show. We have 153 live listeners right now. Guys like, retweet.

Let's try to get some noobs in here. Let's try to get some people who don't really yet know about Monero, discovering Monero for the first time and no better way to discover it than through an interview with Luke Parker himself. So back at it here with Luke. Go ahead. 

Luke 
Yeah, I was just going to summarize real quick. So the development CCS was for all of my libraries that includes full-chain membership proof and the signature as I said those included a few other items such as multi-signature protocols for the new signature That was actually a bit fun because we actually need two of them There's the multi-signature protocol for existing wallets.

If you have a wallet that's been made today You can still use it will full-chain membership proofs plus plus exact same addresses exact same output set everything But that needs a specific multi-signature protocol So I also implemented that as part of my development CCS And then I also implemented a second one for newly created wallets At some point in the future full-chain membership proofs plus plus allows us to make these new wallets It's enabled from this moment full-chain membership proofs plus plus goes live But I don't believe any wallets will actually have this implemented and have the support ready for it yet So it's theoretical on the protocol level, but not actually implemented But once we have these new wallets We get this really great functionality of an outgoing view key where an outgoing view key can be used to determine your balance Without access to the private spend key as of right now we have incoming few keys, which let you see how much a wallet has received and In practice it also does let you find out how much a wallet has in its balance But technically it has you know, it's ninety nine point nine percent accurate instead of saying yep Here's your balance There are specific ways that you could cheat this if you knew what you were trying to do and so on and so on So outgoing few keys just let you With certainty know the balance of a wallet which will be great for you know charities and organizations which want to prove that Yeah, we're not just taking all of this Monero for ourselves You can actually see it present in this wallet and you can see exactly when we spend it So outgoing few keys will be one of these great features for new wallets But as they are a different type of wallet internally and this is completely internal ideally the user is never aware of this It does technically need a distinct multi-signature protocol so both of those were also done as my developments under my development CCS and That's the work.

I submitted At the end of the month or possibly, you know, December 1st December 2nd Which is all of these libraries so that we can integrate all of this new code into Monero and successfully deploy the protocol composition 

Doug 
Amazing. And so is your work then with Full Chain Membership Proofs essentially almost complete at this point? And it's kind of in the hands of the Jay Burmans of the world, people that are going to implement it, or are there other tasks for you to do first to get to the finish line with Full Chain Membership Proofs? 

Luke 
Yeah, so I'm still working on the research CCS, which is somewhat just pushing the paperwork around. It's soliciting academia, it's following up with the academics we're working with, it's ensuring that the work produced is correct, and then it's doing, you know, further reviews and audits of all of that work.

So that's what the research CCS is, it's just organizing the finalization of the academia at this point, and I'm still doing that, I'm still performing in that role. And then the other part of the research CCS will be auditing the existing code base that I built as part of the development CCS.

So we are moving into audits of all of the libraries I built, and not only will I be coordinating those audits, I will also be responsible for fixing any issues noted within those audits. So if any bugs or discrepancies are noted, it will still be my job to fix those. 

Doug 
All right. I'm probably not going to like this question. I don't think any developer does, but so when do we as the users, when do we actually get to use the power of full chain membership proofs? When do I open up my cake wallet, send a transaction, and it is by default using full chain membership proofs? 

Luke 
I believe Justin Berman is really pushing for the first testnet within the next month or two. I know it was a priority that they had leading into the new year. Not quite sure where that is. Yet they've already done a lot of work on building the tree, the new full-time membership proof. It technically proves the membership of an output within something called a tree.

I can get into a lot more technical details. It's not gonna be helpful if I do so. So basically we now have this tree and nodes need to build it. They need to say, here is my tree. It is built from the blockchain because it's built from the blockchain. Everyone agrees on what it is because we all agree on the blockchain. It is a very nice tree.

No, you cannot hang ornaments on it, but it's still a very nice tree. So they've spent a lot of time and effort on the code to build the tree and making sure it's performant and optimized and also secure, which is of course very critical. So now that we have the tree built, they've also spent the time making sure wallets build the tree.

The reason for wallets to build the tree is so that they can create full-chain membership proofs without communicating to a node. Right now, when we want to make a ring signature, we select 15 random outputs. So we have 15 random outputs and one real output. And we go to a node and we say, hey, here's 16 outputs. Can you give me the information on all of these?

And we don't just send the 15 fake ones, the 15 decoys. We don't just say, hey, can you give me the information on these 15 decoys? Because if we went to a node and said, hey, can you give me information on these 15 outputs?

And then 10 seconds later, a transaction appears in the mempool with those 15 outputs and one other, that node could immediately say, okay, that one other output is going to be the real one because the user had to request information on all of these other outputs, but they didn't have to request information on this last one.

So that means that they already knew that last output because it's their output and the other 15 are decoys. So our solution for that is just to request information on all 16 outputs. So as we move to full-chain membership proofs, the question was, okay, what's the equivalent of this? Do we just request how to spend the one specific output we're actually spending?

Well, no, because that tells the node, hi, I'm about to spend this output. Can you please tell me how to do so? And it's like, okay, so we could go back to ring-level privacy. Instead of asking, how do we spend this one output? We could ask, how do we spend these 16 outputs?

But now to the node you're connected, you would only have ring-level privacy because you're still only requesting how to spend 16 outputs, not requesting how to spend all over 100 million outputs present on the blockchain, which is too invisible to do. So the proper solution is as your wallet scans the blockchain, it locally builds the tree itself.

And because it locally builds the tree, it knows the state of the tree, it knows how outputs are placed in it, and it knows how to build proofs off of it. 

Luke 
So when it comes time to spend a specific output, it doesn't have to ask a node for any additional information, and it could just immediately spend it with full privacy. So I was expecting that to be done as of months ago. I was expecting that to be done after full-chain membership proofs plus-plus went live. I said, hey, this would be a great feature.

I don't want to cram it into this massive protocol upgrade. Let's kick it into another upgrade six months down the road or a year down the road, because there's already so much happening with full-chain membership proofs plus-plus. And then Justin Berman's like, no, I'm just going to do it. I'm just going to do it now, and I'm going to do a really good job at it. That's going to be fine.

And thanks to Justin Berman, yes, we now have wallets locally managing their tree state. We have the full privacy, and they have done a really great job with that. So very promising there. Sorry, there was an original question here of how do we get to users using this? The next step on integration is actually integrating the proofs. I have defined full-chain membership proofs. I have defined signatures.

We just need to extend transactions with, here's the field for full-chain membership proofs, and here's the field for the new signatures. And we just have to add in the calls to verify. So when you see a transaction using full-chain membership proofs, call verify on it, make sure it's valid proof. And then we just have to adjust wallets to actually create the new proofs.

So it's actually not a lot of work remaining, thankfully. I believe the plan is to do an initial testnet, which may or may not be the stressnet. I am not fully sure on if we're targeting a dedicated testnet built from the ground up or for targeting repurposing the stressnet for this initial testnet. After that, it will get deployed to the main Monero testnet.

And then finally, it will hit the Monero mainnet. So I would be hopeful within the next six months or so that this gets deployed to mainnet. But even if it's ready for mainnet and we tag the release and we tell everyone to update, we can't just immediately upgrade. We still have to give people time to update all of their nodes.

We have to coordinate with wallets and make sure all of the wallets have updated. We have to coordinate with hardware wallets and make sure they have updated. So while I hope within about six months, that actually hope for a bit sooner than that, but not too much sooner, it's really hard to make guarantees because when you have to coordinate all of these moving parts, delays happen. 

Doug 
Yeah, actually fairly reasonable is asking, once full chain membership plus is on mainnet, do we need to transfer to new wallets or is the process automatic? 

Luke 
All existing wallets work and all existing addresses work, and you can still transfer to existing addresses without issue. The wallets you're using, like Cake Wallet, will have to internally update which cryptography they use, because we're adding new cryptography to the Manera blockchain.

If you go to any existing Manera node or any existing Manera wallet, it's going to say, I have no idea what you're talking about, I only know what a ring signature is. These wallets just have to internally update what zero-knowledge proofs they use, but your existing seeds, addresses, outputs all work.

One of the really great things about Full-T membership proofs++ is that it's not defining a new privacy pool. Manera does actually have multiple privacy pools on its mainnet today.

We have the ring CT pool, which is what effectively everyone uses and really what we only discuss nowadays, but it also has the non-confidential transactions pool from when the network first launched and only had ring signatures and did not have private amounts. When the network first launched, amounts were public, and we defined a privacy pool for each amount.

If you wanted to spend one Manera, you would go to the one Manera privacy pool and create a ring signature that only had outputs that were also worth one Manera. That's how it was back in the day. And those outputs were never migrated into the ring CT system. Even today, if you use Manera when it started, what was that, seven years ago?

You might have an output that's not only worth one Manera, but says on the blockchain, one Manera and is public in that regard and has not been spent yet. And if you want to spend it now, you won't actually create a ring CT transaction. You will actually create a transaction solely with a traditional ring signature, which will then create an output, which is in the ring CT pool.

And all of this is completely abstracted to the user. But one of the great things about full-chain membership proofs++ is that we are migrating not only the existing ring CT outputs into full-chain membership proofs++, yet also all of the historic outputs, even with public amounts.

So if you do have one of these outputs from seven years ago and you go to spend it today, you will reveal that you're spending this output from several years ago. Sure, it will still be within a ring signature, but all of those outputs are several years old at this point. You can't beat the allegation that you're one of the Manera OGs who used it within its first couple of years being live.

But the great thing about full-chain membership proofs++ is once that goes live, no, you can spend those outputs from seven years ago without revealing you're spending an output from seven years ago. You will be able to spend even the original outputs created on the blockchain with a full-chain membership proof. 

Doug 
So, ironically, Monero's price will actually tank instead of going up as Nicholas Van Sabrehagen dumps all of his early, early Monero that he's been waiting to sell. 

Luke 
With how complicated the crypto history is, I don't even know if the crypto developers mind Manero. I would assume so, but I have no idea what the status of that is. 

Doug 
It is amazing though, right? I mean, I guess there are people who haven't moved Manero some old Manero. They probably have been waiting for those reasons, right? 

Luke 
I mean, I would just, I think there is, I think Jefro quoted me the statistic apologies if the statistic is wrong, or if it wasn't Jefro that quoted me yet. But I believe I saw this message that 2 million Monero exists with public amounts that have not been migrated.

There's still like 2 million Monero, which is, you know, a bit under 10% of the supply, which was just never migrated one spring CT one life. So I think that's probably just lost coins that are never going to be migrated. But yeah, technically, that moment full chain membership proofs goes live, those 2 million Monero could be, you know, updated into more modern outputs.

And we wouldn't know because there would be a full chain membership proof, you want to be able to distinguish, you know, one of these very old outputs from being spent from a recent output. 

Doug 
Amazing. So in your mind, what weaknesses remain at this point in terms of privacy? Obviously, there's other elements to Monero's architecture, but in terms of privacy, what do you then still see as Monero's weaknesses? 

Luke 
Uh, I think there's a couple of topics. I think one, um, poultry membership proofs plus plus one of the really great things is that it adds forward secrecy.

When I originally proposed that the original proposal didn't include forward secrecy, and I was looking at it and how to work with it and how to tweak it and how to modify it, and I can't remember if I was looking for forward secrecy at the time, or if I was looking to add outgoing few keys, uh, before I continue the story.

Uh, forward secrecy means that even a quantum computer cannot break the privacy, uh, of the transaction. So I don't remember if I was trying to extend my original proposal with forward secrecy or with outgoing view keys, but I was working on one and I added the other.

I think it was I was trying to see if I could make it forward secret, so even a quantum computer couldn't break the privacy of Monero transactions, and I realized we could do outgoing view keys, but I did not realize how to do forward secrecy. And then later I did crack the forward secrecy problem.

But in these initial discussions about the full-chain membership proofs plus-plus proposal, it was pretty unstable because Monero was being spammed at the time. There were concerns about the effective ring size being heavily decreased, and I said, well, what if we tried to do full-chain membership proofs now?

And I had this idea of how we could do it now, and that idea didn't end up being a good idea. Within a day or two, I had a much better proposal for how to do it then. But originally, it wasn't, you know, is this the next, you know, privacy protocol composition? It was just, is this full-chain membership proofs now? And then we still do Serafis later.

And then as I was, it was going to be this massive upgrade, and it was still going to be Serafis, and I kept poking with it. And as I kept poking with it, it became feature complete with Serafis, and it meant that we didn't have to do this now and then do Serafis if we wanted the benefits of Serafis.

We could just do this larger proposal now and get all of the benefits of Serafis, but without the migration. And with what I argued, which would be a much shorter time to make that. But it was this, you know, it's this entire thing. Oh, this is a very large proposal. And we would still do Serafis later. Oh, it's this very large proposal.

And now it's larger because you're saying it's feature complete with Serafis. And oh, it's this very large proposal. And now you're proposing adding forward secrecy to it. So it's pretty unstable back in the day. And originally, we were just arguing for full chain membership proofs without forward secrecy.

And in that case, it actually would not have been feature complete with Serafis because one of the great things about Serafis is Serafis theoretically could be forward secret. 

Luke 
There's an additional assumption made, but yes, Serafis with full chain membership proofs also would have been forward secret. But the version of full chain membership proofs I was proposing to add on to ring CT would never be forward secret, even though we were using full chain membership proofs, it just fundamentally was not going to be forward secret in this original proposal.

And I was saying, not only should we do this, but we should also add this additional bit for forward secrecy. So it's kind of on shaky footing at the start. But thankfully, we did kind of all agree forward secrecy isn't that hard to additionally include. And it's very much worth it, because of, you know, the risk of quantum computers learning the entire amount of blockchain someday.

So while it's great that we now have it within the protocol composition, and it's now possible in theory, there's still there was still additional work that had to be done for to actually be used. It's one thing if it's possible in theory, it's another thing if it actually ends up used and implemented and supported.

So that's what Jeffers work on carrot, among other things does carrot is a new addressing protocol, it looks exactly the same as existing addresses, and it still works perfectly fine with existing addresses. There's no concerns there.

But the great thing about carrot is that carrot actually makes outputs that have forward secrecy, all of the existing outputs on chain, no, they don't have forward secrecy. But once we adopt carrot, carrot will give you forward secrecy. So that's the really great thing about carrot for newly created outputs.

And yes, everyone is going to be using carrot with the full chain membership freeze plus plus upgrades, you don't have to worry Oh, is my wallet a carrot wallet or not? No, all of wallets are going to be moving over to this new addressing protocol.

But that doesn't change that if you are a user, and you do actually want to take advantage of forward secrecy, you have to spend all of your old outputs and create new outputs. And then unfortunately, there's still some caveats. If someone was to learn your address, someone was to see your address, they can see the public view key.

And if they have a quantum computer, they can find out your private view key. And that's part of the problem is that if an adversary ever learns your private view key, they can just scan the blockchain, they, you know, they can just scan the blockchain right now, if I have my public spend key and my private view key, I can scan the entire manual blockchain and find all of the outputs I received.

And it's the same if you have a public address and a quantum computer, you can take the public view key, you can recover the private view key, and you can just scan the manual blockchain in the traditional fashion. 

Luke 
So because of that, you know, for starting to discuss how to improve privacy, what I would love to see more discussions on is a an address format, which is not vulnerable to a quantum computer.

And if you publish this address, no, an adversary with a quantum computer can not in fact, sorry, can not in fact recover your private view key and scan the transaction, scan the blockchain as a classical adversary would. Another impact 

Doug 
At that point, they're still at that point, just so I understand at that point, they're also stealing all your Benero too, right? Because now they're unraveling the private key in general to get your I mean, 

Luke 
You also have to recover the private spend key. And one of the changes that are being made for new wallets. So this is only going to be for wallets made with compatible wallet software after the full chain membership proofs plus plus hard fork. And this is not going to be done with the full chain membership proofs plus plus hard fork.

At some point after we deploy full chain membership proofs plus plus, we are going to define this new wallet scheme. So if you have a seed, it's now going to drive to a different wallet. It's not going to drive the same as the existing wallets. And not only will it drive to a new wallet, but it is going to have certain functionality, including outgoing few keys.

So with these new wallets and these newly created addresses, the public spend key isn't going to have a single private key. It is actually going to be made up of two different private keys. And quantum computers don't handle that. You can give it a public key, which in mathematical terms is a point on an elliptic curve.

And you can say, hey, what's the relationship between this public key and this, in mathematical terms, generator? And it can say, oh yeah, the number that causes this public key is this very long number. And that would be your private key in our current system. Both full chain membership proofs plus plus, we actually support having two private keys.

And if you ask a quantum computer, hey, what's the first number and what's the second number? It can't answer that definitively. Because for every first possible number, there's a matching second number. So any number has a compliment. So it can't determine what the original numbers were because every number is possible. It's a whole thing.

So they won't actually be able to recover your private spend key now that there's two of them. They're only going to be able to recover the private few key. So they can still scan your outputs and they can forge out, they can forge the proofs.

Not only can they forge the zero knowledge proofs, but even if we replace the zero knowledge proofs with post quantum cryptography that would survive a quantum computer, they can still take an existing output on the blockchain today for one Monero and just say, nope, this isn't for one Monero. This is for 10 million Monero. I have an output here, 10 million Monero. Please migrate it for me. Thank you.

So quantum computers can forge outputs. They can inflate amounts. They can double spend outputs. They can do a lot of very screwed up things, but we aren't discussing recovering private spend keys and outright theft at this time. Though that does kind of lead us into the post quantum discussion in that at some point we will have to have a way for users to migrate from elliptic curve outputs.

Our current cryptography is based on elliptic curves which will not survive a quantum computer. And someday we will need a way for people to migrate their current outputs premised on elliptic curves to outputs premised on cryptography that is not solvable by a quantum computer. 

Luke 
And with this migration process, the simplest solution is to only run it for, let's say a year. We have all of these elliptic curve outputs and we add in a post quantum protocol and we say, hey, we don't expect a quantum computer to exist for 12 more months.

So for the next 12 months, you can still spend all of these elliptic curve outputs because we believe all of their cryptography is still valid and you can make outputs within this post quantum protocol. But after these 12 months, we think the risk of a quantum computer is sufficiently high. We're no longer going to allow spending elliptic curve outputs and if you didn't migrate your screw.

So the question for this eventual post quantum migration is how do we avoid that? How do we say that even if you don't migrate within this one year period, you can still access and spend your Monero at any point in the future.

And that's one of the current discussions on going within the Monero project is defining a specific wallet derivation scheme and handling some values in a specific way so that even when quantum computers can forge cryptographic proofs premised on elliptic curve cryptography, they will not in practice be able to lie about the amount present within an output.

They will not be able to lie about what its key images. That's how we detect if an output has already been spent. They will not be able to lie about what its key images. And because of that, they won't be able to. spend an output multiple times and they won't be able to change its amount and then the other thing we're working on is making sure that they can't lie about who the owner of the output is.

So we're also working on a scheme where you can prove ownership of an output even once a quantum computer exists. So that's an active discussion happening within the Monero community and it's had some interesting things and thankfully it's being done now because some of the discussions in it have impacted Carrot.

Carrot I've kind of said it's an addressing protocol that works with all existing addresses and produces addresses that look exactly the same. The important part about Carrot isn't the human readable addresses it generates. Again that's all the same. It's about what it does with those addresses.

When I send Monero to your address I don't just take your address and say here's your address on the blockchain. I'm gonna send one Monero to it. What I actually do is I derive this seemingly random value and that goes on the blockchain and you can't tell which address it belongs to. The whole you know stuff addresses.

So the important thing about Carrot is deriving those values in specific ways for specific features functionality benefits yet also deriving those addresses in specific ways so that it supports this inevitable post-quantum migration. 

Luke 
So ideally one year from now this is the ideal case one year from now you make a new Monero wallet it gives you a new seed it gives you a new address that address may even look the same as all your existing addresses but internally it's going to be a bit different and all you have to do is send your Monero from your existing wallet into this new wallet and then as long as you do that after a year from now you can spend that Monero for the rest of your life.

It doesn't matter if a quantum computer comes around it doesn't matter if a quantum computer can lie about amounts they will not be able to lie about amounts and outputs created by Carrot and they will not be able to lie about key images to spend an output multiple times and they will not be able to lie about who owns an output in order to steal outputs from honest users.

So that's the ideal case one year from now you make a new wallet you're covered for life. 

Doug 
So there is going to need to be this migration from the old wallets to the new wallets to get around the quantum issue. 

Luke 
Right. But ideally, it's not we only give you a year to migrate when both protocols are live. Ideally, it's we deploy this, we set up this migration scheme now.

So starting from, you know, ideally a year from now, don't quote me on that, I'm just saying ideally, starting ideally a year from now, you make this new wallet, and that while it's going to last multiple years, you know, if we think quantum computers are going to be a sufficient risk, we have to turn off elliptic curve cryptography five years from now, then as long as you make this new wallet anytime within after one year from now, before five years from now, you will be safe.

So we're discussing going from this one year migration period of mutual overlap between the elliptic curve cryptography protocol and the post quantum protocol into this, you know, roughly four to five year period. Once we set up this migration scheme. 

Doug 
Now, without going too far down this rabbit hole, but how does it look like in Bitcoin land versus Monero land in terms of trying to become quantum? 

Luke 
So it depends because Bitcoin has had a lot of different address types before, and they all have very different properties. Way back in the day, they used pay-to-public key, and pay-to-public key specifies the public key in the output. And if a quantum computer learns that public key, they can recover the private key, and they can just spend the output without issue.

Bitcoin is supposed to have pay-to-public key hash, and that's a bit different. With pay-to-public key hash, no, a quantum computer does not know the public key. It only knows the hash of the public key, and they can't recover the public key from the hash of the public key.

So a quantum computer can't spend those outputs currently, but the moment someone goes to spend it, they have to reveal the public key. And once they reveal the public key, a quantum computer can then calculate the private key and create another transaction. So that matters in one of two cases. That matters if you ever experienced address reuse.

You know, someone sent you multiple different Bitcoin outputs to the same pay-to-public key hash address, and you only spent one of them. If you only spent one of them, the public key for it is revealed. A quantum computer can calculate the private key and can spend the other output received to that address, and then it also matters due to the mempool.

You know, at some point, you're going to spend this address. At some point, you're going to reveal the public key, and at some point, it's going to exist in some mempool. It doesn't matter if it's the public Bitcoin mempool or either a private mining pool mempool.

You send it directly to the miner, because whether it be the entire Bitcoin network or just that mining pool, or even just the operators of that mining pool, they will know what your public key is.

And if they have a quantum computer, and they can calculate the private key and make an alternative transaction with a higher fee before your transaction gets included on the blockchain, then they can take your coins.

So Bitcoin kind of is more quantum resistant things to public key hash, or paid to public key hash, but it doesn't really achieve quantum resistance because at some point, you still have to reveal the public key, and the moment you do, you're at risk of theft.

Then there's the new outputs, which are paid to Taproot, and that's part of the Taproot protocol upgrade, and those, once again, just specify the public key directly. So all Taproot outputs are going to be vulnerable of theft when a quantum computer exists.

Though what I should note is because, of course, Bitcoin is a transparent system, they will not have risk of supply inflation or double spends, they will only be at risk of theft.

So at some point, they will have to deploy this, their own post quantum, sorry, excuse me, they will have to deploy their own post quantum cryptography, and they will have to make new addresses for that, and they will have to start creating outputs to those addresses. 

Doug 
they'll have to be in a migration in Bitcoin land as well. 

Luke 
Even if you say, oh, well, my Bitcoin fork or my cryptocurrency only uses pay the public key hash, you still have to reveal the public key at some point. If at any point you put an elliptic curve into it, you are going to have to have a migration period. It's just how it is. 

Doug 
Okay. So just to simplify things with the implement, what will Monero look like in terms of its quantum resistance once full chain membership proofs is implemented, whatever six months from now, and then what will it ultimately look like if we're able to achieve what you would like to achieve?

I know you kind of said it all, but if you kind of re-summarize just so we can understand where we'll be post full chain membership proofs and then where we ultimately want to be. 

Luke 
When Fulton Membership proves Plus Plus goes live, Monero will be forward secret to anyone who doesn't have your address. That means all newly created outputs at Quantum Computer cannot detect when they are spent. They will not be able to build the transaction graph. Compared to the current Monero, a Quantum Computer will be able to build the transaction graph.

Though notably, a Quantum Computer cannot actually break Monero's amount of privacy today. A Quantum Computer can, for the current Monero protocol, see when each output was spent and in which transaction, but they can't actually see the amounts transferred.

In the future, with Fulton Membership proves Plus Plus when that goes live, they will not be able to see when Fulton Membership proves Plus Plus outputs are spent, and they will not be able to build the transaction graph on these new outputs unless they know your address. If they know your address, they can recover the few key and they can just scan your wallet as you would today.

So the current discussion on the table is about setting up a post-quantum migration scheme so that if you do make a new wallet, you know, any point after, let's say a year from now, you will be counted as migrated. You will have already migrated to cryptography that will allow you to spend your outputs for the rest of your life.

And ideally, that gives us about a four-year migration period where anyone who makes a new wallet and moves their Monero over within that four-year period will not be at risk of losing their coins or having their coins become unspendable due to either a quantum computer or a risk of quantum computers.

Then there are some other further discussions, like one I was trying to open about making addresses, current addresses today, resistant to quantum computers. So even if an adversary with a quantum computer learns your address, they will not be able to recover your private few key and scan your wallet.

That discussion hasn't really started, but it would be another potential future upgrade to Monero before we do a full post-quantum protocol so that just to increase your privacy for when a quantum computer comes around. 

Doug 
Right. So what do you see as being the path forward to actually put this into motion to move us towards being more quantum resistant? I mean, are there any technical roadblocks or is it really just a matter of putting some funding towards it, having the devs rework Monero a little bit or are we potentially up against some pretty big obstacles here? 

Luke 
I feel like this is the moment where I, you know, pull out a board with a bunch of pins and various colored ropes tying them together and be like, well, if you look over here. There's also, you know, just the one word kind of a choke answer of money, money. No, it's a it's a lot of different things.

So full time membership proofs plus plus is already set up and gives us forward secrecy, even if we don't so long as the adversary doesn't know your address. And then this post quantum migration discussion, I think it's moving forward well, and it will create it so that we have roughly four years for you to migrate to a new wallet that will survive the transition.

And I think that's going really well. I think the next step towards a post quantum protocol will simply be an address that is resistant to quantum computers. And because we don't need to do that with a post quantum protocol, we don't have to do that at the time of a post quantum protocol. We just need the public view key within the address.

Right now, the public view key is premised on elliptic curve cryptography. We just have to replace the public view key with one premised on post quantum cryptography. So you would still have a public spend key based on elliptic curve cryptography. You just want to have a public view key premised on elliptic curve cryptography.

So I think that would kind of be the next step because it increases users privacy. You know, if it prevents a quantum computer that knows your address from seeing what outputs you control, and it forces us to start working on the user experience challenges. Because with this, basically, the smallest public view keys will get with a post quantum cryptography are still going to be roughly a kilobyte.

I think it might actually be closer to three kilobytes, but that doesn't change. It's going to be roughly a kilobyte. So that means addresses are going to get 15 to 16 times larger. Addresses are going to be 16 times larger. So if you already thought menorah addresses were a bit big, it's not going to get better. It's already going to get it's going to get significantly larger at that time.

So that's why it's kind of a good step to handle now because right now an address is two things. It's a public spend key in a public view key. And if we just replace the public view key with post quantum cryptography, it's going to get 16 times larger. If we also replace the public spend key, oh, it's going to get even larger again.

So doing this kind of half step just to increase privacy, not even to set up the actual post quantum protocol, I think it's going to not only increase privacy, it's going to force us to start handling the user experience of larger addresses.

It is also going to increase the size of transactions on chain a bit because you now have to do what's known as a post quantum key exchange and that requires a bit more bandwidth. So it's also going to have us increase the size of transactions a bit and start considering the implications there and making sure nodes can still scale and handle that load of transactions. 

Luke 
So I think that will be a good step. But eventually what needs to happen is a full post quantum protocol where not just we have post quantum view keys, but we also have post quantum spend keys. We have post quantum membership proofs. We have post quantum signatures.

We have post quantum range proofs and post quantum solution for checking that transactions balance that if they, you know, have 500 Monero as their inputs that they only spent 500 Monero. And we will need post quantum solutions for all of us.

And that is going to be multiple years of work, which is why if we expect, you know, quantum computers to be five years away, and that's the current predicted timeline.

It's why we need to start working on this now because if it takes us, you know, two years to develop and optimize a candidate candidate protocol that we're happy with, and then it takes us another year to audit it and make sure it's good. And then we have to talk to exchanges about why our addresses are now so much longer.

And we have to talk to, you know, hardware wallets and make sure they're updated and taking several months, ensuring the entire ecosystem is ready for this move. It could be four years until we deploy a post quantum protocol and that only gives us a year of headway. And yes, we should have these protocols running side by side.

We should not be waiting till the last minute for this post quantum protocol to go live. We should have that explicit year of overlap. So if you do have any elliptic curve outputs, you are able to migrate them regardless if you may regardless of if you made one of these newer wallets or not.

So yeah, it's just we have multiple years until quantum computers, but it's going to take us multiple years to get ready for them. So we should start research now. In my stepping back post, I not only called to start this research, I actually went a bit further and called for moratorium on development premised on elliptic curve cryptography.

I don't believe it makes sense to continue developing proofs and schemes premised on elliptic curve cryptography when it's going to be rather incremental progress, and it's going to be thrown out in just a few years. And there are some cool things we can do with elliptic curve cryptography.

I think we could decrease transaction sizes from where they will be after the full-chain membership proofs plus plus upgrade. I believe we could decrease transaction sizes 25% or so. I think we could potentially look at implementing something called an incremental verifiable computation scheme, which would massively reduce proof verification time, the time it takes to verify transactions.

What an incrementally verifiable computation, or IVC. Basically, if it takes 10 milliseconds to verify an output, which is far longer than it takes today, but bear with me, if it takes 10 milliseconds to verify an output and you have two outputs, it still takes 10 milliseconds. And if you have three outputs, it still takes 10 milliseconds. And you have four outputs, it still takes 10 milliseconds.

Basically, the time to verify the proof, it only scales with regards to the size of the proof. 

Luke 
So if you have to verify an output is valid, it does all of this work, and that's how long the proof takes to verify. If you throw more outputs at it, that doesn't actually raise the time it takes to verify. So there's definitely really cool things we can do with elliptic curve cryptography.

The issue is if it's two years of work and hundreds of thousands of dollars, and then we're trying to replace it and get rid of it. It's incremental progress, I would rather see focused elsewhere. What I'd really like to see is the development of a full post quantum protocol.

I'd like to see us bring on researchers, collaborators, other teams and enterprises to work on the design, implementation and optimization of a post quantum protocol. And that will take not only years, as I've said, it will just also take a significant amount of money. And at some point, someone will have to step up to be the architect of that and to be the manager and bridge between the two worlds.

Because while it is easy to talk to academics and say, hey, we want a post quantum protocol. If you then talk to the Manero community and say, hey, we built a post quantum protocol, the Manero community will say, cool, does it work for us?

So whoever is talking with these academics and is working with them, will need to successfully communicate Manero's needs, focuses and priorities and ensure that the built protocol is amenable to our specific use. 

Doug 
Do you anticipate playing a role in these aspects in building Monero's quantum resistance? 

Luke 
It's not something I'm completely against, but I stepped back as I did because I've had a lot of personal things going on that have been taking a lot of my time. And not only do I have those personal things taking my time, I still have work on Serai, which is ongoing. So between my personal things and Serai, my time is truly just at capacity right now.

So it would be multiple months before I could sign on for any new work efforts. So possibly, but I will have to see you in a few months. 

Doug 
I'll be praying. I'll be praying nightly. And yeah, like I always say, we greatly appreciate everything you've done already. I mean, you've already done more for Monero than anybody could ever expect of anybody or hoped for, for that matter.

How does Monero's, this path forward that you're proposing look like compared to other crypto projects like Bitcoin or I don't know, who else is thinking along these lines? Is what you're proposing, is it kind of drastic? I mean, you're saying let's no longer focus on elliptic curve cryptography. It's going to be moot eventually. Let's just start developing here, which in my mind, that sounds amazing.

I'm all on board for that. But what's the pushback you're getting and how does this compare to what we're potentially seeing in other crypto projects? 

Luke 
There is a flip side. I'm not sure I properly communicated. Sorry about that. And I do want to be clear about, it's not just that I think that, you know, all of this efforts on elliptic curve cryptography is suboptimal with regards to our resources and time.

It's also that I think with full chain membership piece plus plus the protocol becomes good enough, you know, we have forward secrecy on the chain itself. We have complete sender privacy. We have, you know, amount privacy as we currently do. We have receiver privacy, thanks to stealth addresses. And I think the performance of the blockchain will be good.

I think the work being done on the full chain membership proof itself and optimizing it, you know, not to brag, but it's something I'm really proud of. I'm really happy with. And I think I did an amazing job with personally.

So because we have all of the features and functionality we want on the blockchain itself, because we have the privacy goals we want on the blockchain itself and because we have performance that I believe is good enough. It doesn't need to be improved. That's why I'm saying I think all of this further work would be more incremental. It's not that it can't be better.

It's just that it's a lot of time and effort for it to be incrementally better. Once we get to, you know, full chain membership proof plus plus, I would say we crossed off all of the explicit goals we had, and then it's just making it faster and smaller, not actually making it stronger or more private. So with that in mind, I'm sorry, what was the original question? 

Doug 
I guess I was saying, how does that compare to other projects? And what pushback, if any, are you getting? So you're saying, let's ignore the incremental and after full chain membership proofs, this is going to give us a ton of inertia in that area. We can now focus on quantum resistance over here and try to get to that sooner than perhaps later. 

Luke 
Bitcoin, they're already discussing a BIP, I believe it's BIP360, it was recently assigned a number to add post quantum signature support so that you will be able to use a variety of post quantum signature algorithms to secure your Bitcoin. So the moment they have that, they can argue that that's good enough.

They can say, hey, we have post quantum signatures, you can move your outputs into a, to be controlled by a key that uses post quantum cryptography, we've done our jobs. Sure, a quantum computer, you know, five years from now, we'll be able to steal all of Satoshi's coins, but that's not our problem. That's Satoshi's problem.

They can say that and they can't be done with this if this BIP goes through. The BIP isn't my favorite because they selected four different algorithms, which is quite wide reaching. And I'm not even here to be mad at them for being wide reaching. I just wish that they chose a better four or also included a fifth. There was one candidate I would have loved to see for very specific reasons.

And it doesn't seem to be included in that BIP, unfortunately. So and I also do expect that a few years from now, they will propose no longer spending old outputs such as Satoshi's coins to prevent someone with a quantum computer from moving them without permission, quote unquote, without permissions and doing whatever they want. And, you know, market dumping five to six percent of the total supply.

So and that's via Satoshi's coins alone. That's not the all of the other coins on the blockchain that they would have the ability to steal. So I definitely expect such a proposal to be made. And I don't know what Bitcoin will do about it. I don't know if they will accept that proposal. I don't know if they will let so many coins be moved into the control of IBM or Google or the U.S.

government or whoever ends up with the quantum computer first. But at some point, I do expect them to propose no longer allowing spending of all these old outputs to prevent that. What happens with that? No idea.

So, with regards to Ethereum, just because that's of course the second biggest cryptocurrency, what I expect Ethereum to do, and this is my personal speculation, but I expect them to move forward with end-user accounts being smart contracts.

There's already been increased work on that, where if you have an account on Ethereum, there's already been work so that you don't actually have an account, you just have a smart contract. And the issue with smart contracts today is they can't pay their own fee. Someone has to pay the fee to invoke the smart contract to do whatever it does.

So this created a series of Ethereum improvement proposals called Relayered, or I forget exactly what they're called, but it established Relayered.

It established a standard for, I have this transaction, it's done via a smart contract, I don't want to pay, I don't have an account to actually pay the fee with, so I give this transaction to some service, there are several of them, and they pay the fee and my smart contract pays them back. 

Luke 
So they didn't allow smart contracts to pay their own fees or be accounts proper, but they did create this infrastructure for various entities to allow smart contracts to behave as if they were their own accounts. I believe there is further work to allowing accounts just to be smart contracts proper.

And the reason that matters is because then when post-quantum signatures are required, you can just make a smart contract that implements whatever post-quantum signature verification algorithm you want. So if they move forward with this, they don't actually have to make the end-user accounts post-quantum, they can just say end-user accounts are smart contracts, make them post-quantum yourself.

They will also have to do, of course, a lot of work on their consensus layer because their consensus is now proof of stake, which means it's no longer using hash power as in proof of work, which should survive quantum computers, but instead they're using proof of stake, which means they have validators, and those validators have public keys, and those public keys will break.

So yes, they will still have to do some additional post-quantum cryptography work, but thanks to their support of smart contracts, the user side is actually very interesting. With regards to Zcash, that was another coin you named, I haven't heard any developments of them regarding post-quantum.

I do know that their blockchain is forward secret, so long as no one knows the address of who you're looking for. But I would be an idiot to say that I don't think they've had discussions on it.

While I know the electric coin company does some things privately, and that is not my preferred modus operandi, I do prefer things to be discussed publicly, I would be an idiot to say I don't think that they've discussed this, to say I don't think they've started any considerations towards it, to say that I don't think their researchers are aware of it, and even if they haven't explicitly started development of a post-quantum protocol, I would imagine that some of them, at least in their off-timer, are considering candidates for it.

So at some point, I believe Zcash will create a new privacy pool that will be post-quantum, and just try to move entirely into that. I don't know if they'll try to allow migrating orchard outputs ad infinitum, or if they'll explicitly only say, nope, you have to migrate into this pool before we disable the old ones.

I don't know, but I do believe that they will have some solution at some point, just based off what I know of them already, and my respect for them as developers and researchers. 

Doug 
What will these post quantum protocols most likely be based on if it's not going to be using elliptic curve technology? What is it going to be? 

Luke 
uh yeah it's hard to answer this without getting overboard on the technicalities 

Doug 
Okay, yeah, yeah, there's a few different options. Go ahead. 

Luke 
Yeah, there are Starks, and of course, in the case of Monero, ZK Starks. And Starks aren't a great candidate for us, because they are and they aren't. They're advertised as hash-based cryptography, where they're just using hashes in order to build themselves. And you know, that's why it's post-quantum, because hashes are widely considered to be post-quantum inherently.

And that isn't quite true, because they also use generally read Solomon codes for proximity testing, which is a whole thing. It's not literally, if you give me a hash function, I give you a ZK proof. No, it's if you give me a hash function and some error correcting codes, I'll give you a proof. For all the great that ZK Starks do, the issue with them is just their performance.

The smallest Starks are still going to be, I believe, still over a megabyte, even with their recent improvements. There was this one very notable improvement recently. I believe it was W-H-I-R. They might have gone into the hundreds of kilobytes, but I think it's still over a megabyte. So ZK Starks exist, and technically they work also because ZK Starks can kind of do anything.

Once you have this ZK Starks, this very generic proof, you can say, okay, I want you to work as a range proof. I want you to work as a membership proof. I want you to work as a signature, and you can just build this one ZK Starks, then you can build these specializations of it, and you can say it's done.

So you just audit the underlying ZK Starks, you verify the specializations, and you have a privacy protocol. It just wouldn't be as efficient as we would want, and multisig would be very difficult. We could not really do a multisig premise on ZK Starks, if that's what we're using for our signature. Technically, you can, because technically you can do anything, but it would not be fun.

So then the question is, okay, so how do we make the signatures amenable to multisig? And then it's like, okay, so now we're not using ZK Starks, but we would actually be looking at lattice-based cryptography, and we'd be looking at one of two different cryptographic assumptions.

If we don't throw in both, it would be either the short integer solution or the learning with errors assumptions that we would be relying on. And both of those are just two different mathematically hard problems that quantum computers have not managed to solve yet.

One of them says, if I'm supposed to calculate five times seven, I can do five times seven plus one, or I can do five times seven minus one, or I can do five times seven plus two. And if you give that to a quantum computer, five times seven, but with this very small random number added to it, a quantum computer can't recover five, and it can't recover seven.

It can't determine what very small random number was added, it can't remove that, and it can't recover the original values. And not only can a quantum computer not do that, but a classical computer also can't figure out where that small random number was and what the original values were. 

Luke 
So that's learning with errors, which just says, if you add in this very small quote unquote, error term, this inaccuracy, you can't recover the original values. But despite that, you can still verify proofs, you can still make a proof, and you can still verify that, yes, whoever made this proof knows the original values, they just introduced a small error term.

And because of the small error term, I can't learn what the original values are. The other one would be short integer solution, which just says, if you have a matrix, you, okay, I can't really describe that one, I know how it's applied, but that academic has been passed me. But it basically just says, a computer can find solutions, but it can't find small solutions.

If you give it, you know, an infinite search base, if you give it all the numbers zero to infinity, oh, yeah, it can find a ton of answers for this mathematical problem, but it can't find answers that are less than 10. But if you actually know the values, you can find these very small solutions, because you knew what the solutions were from the start. It's a whole thing.

I'm probably bastardizing this, I'm so sorry to anyone with a PhD who happens to be doing this. But basically, there are a couple of different cryptographic assumptions that we could rely on. And we technically can use ckstarks, it would just be slow, and it would remove a lot of functionality from the current Monero protocol. So that's the challenge.

If we discuss spinning up the post quantum effort, and you know, spending the three to four years on developing this, the challenge is, you know, not only developing a solution, but developing a solution with all the features we want with all of their performance we want.

And then I said there were kind of these two different assumptions we could use with lattice cryptography, learning with errors or short-inverser solution. How do we get a protocol that only uses one? How do we make it so that we aren't reliant on both assumptions being secure over the next 100 years, but we only require one assumption to be secure over the next 100 years?

And these are the questions that just takes a lot of time, money and effort to answer and build a competent solution for. 

Doug 
And are any other crypto projects using any of this encryption tech yet that you brought up here? 

Luke 
There is famously one project which uses quantum resistant technology, debating if I want to name them. They've been around long enough that I don't have an issue naming them because they seem to, and I've actually talked with them at an event, I was at an event, they were at the event and I talked with them and they seem to be reasonable.

So no endorsement here, but quantum resistant ledger started using, from when their network started, they started with quantum resistant signatures. So if you have coins on quantum resistant ledger, assuming, you know, it's secure because we assume everything is kind of secure when we use it.

But, you know, assuming that they didn't make bugs, you know, like, you know, Bitcoin, when Bitcoin started, it had an inflation vulnerability where you could just make as many coins as you want. It was a whole thing, the value overflow incident.

But yeah, of course, assuming quantum resistant ledger was securely implemented, which is the assumption here, even a quantum computer can't steal your coins because they use post quantum signatures. And they've done that from the start of the network because they believed in the threat of quantum computers for years.

And not only I don't believe that they're going around saying, oh, we think it's possible a quantum computer exists now that can break Bitcoin. I don't believe they're being that conservative and paranoid about quantum computers, but they do realize it's a risk. They do realize that when a quantum computer happens, it will blindside people.

You know, I've been saying, I think a quantum computer will happen in five years. It could happen in two. And if it happens in two and Monero doesn't have a solution by the time it's operational, Monero is screwed. It's we're going to get blindsided and we're going to get destroyed. And that's the thing.

It's not even by the time it's announced, it's just by the time it's operational, which is not going to be announced. Not immediately. So that's kind of like the issue in question here is when will a quantum computer happen? We don't know. So we should move to post quantum photography immediately.

And not only that, we don't want to only give users, you know, a year to migrate, six months to migrate, one month to migrate. But we want users to be confident their balances are to be secure. And that's what quantum resistant leisure said several years ago when they built a network that from the start has only used quantum resistant cryptography.

I have heard of a couple privacy projects that are using post quantum cryptography to achieve its privacy. I haven't looked into the performance of them. I haven't looked into the security of them. I cannot vouch for their claims of privacy in effect. So I am not going to attempt to name any of those at this time. But I do know that there are a couple projects working on post quantum privacy. 

Doug 
As expected, as expected. 

Luke 
And of course, not just post-quantum privacy as in Ford secrecy, but post-quantum privacy as in a privacy protocol which only relies on post-quantum cryptography to achieve its privacy and integrity.

The important part is the integrity, because as I said, Monero will be using cryptography that survives a quantum computer with regards to privacy, but its integrity will not hold, and that's the important and difficult part. 

Doug 
Just to wrap up this topic, I mean, what can the community do to help push forward this initiative? Obviously, I guess just if a CCS comes out, we have to raise the funding. What can we do to help with the next steps? 

Luke 
Yeah, if a CCS comes around, funding it would be very important and valuable. But the main thing that's necessary will be someone to lead the efforts or a group of people to lead the efforts. With Serif is, we had co-leading the Serif is protocol with full-time membership for this plus, plus it was myself.

So while there doesn't explicitly have to be a single person, I'm sure a few people could get together and be the proper committee for it.

At some point, a committee or manager will have to step up and take on this role and create the CCS and raise the money and understand where it should be spent and how to allocate it and actually evaluate it and work with academics and be in such contact in order to successfully accomplish it. I myself, as I said, am stepping back from the Monero project, at least for the next multiple months.

And then I believe most of the other people within Monero are still hard at work on the full team membership piece plus plus integration or just the general work necessary on Monero. Even with this work on integrating full team membership piece plus plus, that doesn't change that there's been improvements to our peer to peer layer. There's been improvements to node stability and performance.

There's been improvements to a variety of things that, you know, you don't have to be working on the next big thing in order to have work on Monero. There's always the existing work. So I think full team membership piece plus plus is still going to be commanding our attention over the next however long until it's deployment or until at least it's ready for deployment.

But once that happens, potentially other researchers and developers in the community might be able to step forward into this role. 

Doug 
Let's talk about the stepping back just to properly define it. I mean, what I'm hearing is, you're still very much part of the Monero ecosystem. You're not disappearing. There's still work to be done with full-chain membership proofs. You've done the lion's share of what you need to do, but you'll still be participating in that as it's implemented. Obviously, you're working on Serai.

I guess you don't consider that working on Monero per se, but yeah, if you want to just define for everybody, for those that are panicking when they hear you say, stepping back. 

Luke 
I consider it stepping back because it's not I'm deleting all my accounts and leaving the ecosystem and deleting my repositories. No, of course not, but I was writing code for Monero. I'm no longer writing code for Monero. I was a member of the Magic Monero Fund committee. I have resigned from my position on the Magic Monero Fund committee. I was attending most of the meetings.

I don't think I've attended a single meeting since I stepped back. You know, it's been nice not to wake up early in the morning. It's been nice. 

Doug 
Yeah. Well-deserved. Well-deserved break. Go ahead. 

Luke 
It's not that there isn't still some task I'm doing, notably the research CCS, which is audit management. It's not that I'm not still talking with Justin Berman a bit on integration. It's not that I'm not still talking with Jeff Robert on finalizing carrot. It's that I don't have notable obligations to the project.

I have cut down my obligations to the project, such as via stepping, whether it be completing my development CCS or whether it be stepping down for my role in the magic Monero fund committee to whether it be there was this one project I was trying to get off the ground. It was going to be a contest to write code for Monero in order to win prizes.

The idea being that we get the fastest possible implementation of the code because we have people competing to write the fastest possible implementation. So there was this contest I drafted and was workshopping. And I'm stepping back from spending the time and effort on that. So if someone wants that contest to go live, someone else will have to do it.

So yeah, there definitely are responsibilities I've stepped back from. And not only are there responsibilities I've stepped back from, I'm not taking on new responsibilities at this time, as I did with full chain membership groups plus plus, you know, when it's not that I was required to make a new CCS to continue my work directly on the Monero project, of course.

But yeah, now that my development CCS is over, I could make a new development CCS. I could make a CCS for this post quantum work. I could keep working on that contest. But I've decided not to make a new CCS to increase my obligations. And there are a couple things I've stepped there are a couple roles I've stepped down from. 

Doug 
And just to be clear, I mean, is this, this is coming from, uh, constraints with time for, for personal reasons, or are there other issues at hand too? I mean, what are you willing to develop in terms of your, or is it just, uh, you know, finished full chain membership proofs, working on other stuff may come back around to development on Monero. 

Luke 
It really is time constraints. I do have some frustrations, and you probably could ascribe some level of burnout accordingly. But it is time constraints primarily. I feel like a lot of people did not get that and have been like, oh, was it because of this person within the community? Or oh, is it because of how this one specific event went? And it's like, no, it's not because of that.

As I said when I said I was stepping back, I wrote a whole post about it. It's just because I don't have a lot of time. And while I think there is some free time that I could still poke on Monero with, it's just not what I'm primarily interested in right now.

Like if I do have free time, I'd rather continue spending it on Serai just so that gets to launch rather than running down niche things within the Monero project.

And I think my choice for what little free time I have left to focus it on other efforts instead of trying to at least do something within the Monero community or preserve another role I had within the Monero community such as organizing that contest. Yeah, that's probably some degree of burnout. So it's not exclusively my lack of time, but also I've been working on Monero for a while.

I think I need some time back from it. Yeah, for sure. But largely, yes, it is just the time obligations and it's not a specific individual or event despite all of the people who don't seem to have read my post and are claiming otherwise. 

Doug 
Well, that's why I wanted to give you the opportunity to talk about that as well. Yeah, no, I appreciate it. 

Luke 
I appreciate it and I'm happy to clarify. 

Doug 
possibly not my position to say, but things like the magic grant thing, I think that that's an amazing project research resource. But I personally rather not see you working on that. I'd rather see you working on other things that somebody like only you can work on. Obviously, you may differ in opinion there.

And the contest, I mean, I'd rather see Luke Parker do things that only Luke Parker can do, which 99.9 repeating percent can't do. That's the way I look at it. But maybe a different there. I'm sure you don't want to just spend your time on things that only Luke Parker can do, right? 

Luke 
Yeah, I really like and support the Magic Manero fund, and I am happy with the contributions I was able to make there. I think there's definitely a lot of potential to do a lot more, and I think it's a bit unfortunate I won't be able to help steward that. Because that's the thing.

For the time invested in Magic compared to the potential payoff, it is really quite high, and that isn't my issue with the position. It isn't that I thought my time was better elsewhere, it's just I unfortunately don't have a lot of time and really do have to cut back wherever it is, no matter what impact that has.

But one of the goals I had for the Magic Manero fund was to actually bring on developers. And if I can spend a few hours a week and get someone to work on Manero for 40 hours a week, then yeah, that's really something that can be already worth it.

Especially as we're now discussing the potential for a post-quantum protocol, which will have to bring on a lot of new talent and not just new talent in that we will need a lot more developers and researchers. But we will be working with researchers who likely have never worked with the Manero project before. And I think the Magic Manero fund could serve a very important role there.

Cypherstack, while a private company, has also been doing a lot of work to ensure talent availability to the Manero ecosystem and really contributing to full-chain membership proof++. So Cypherstack, even as a private entity, deserves a shout out there. And then, of course, I still believe the Manero CCS itself has a good, improper role.

One of the things I noticed as I step back is I have really pushed the boundaries of the CCS over the years. I've made retroactive proposals when those are frowned upon. They're not explicitly banned. I made this giant CCS just to create a research fund.

And not only did I create a research fund to fund whatever academia and audits necessary, I did list exactly which academia and audits we would be seeking. That just doesn't change. That I didn't say, here is the exact amount for each of these items and here is the exact candidate and here's the signed agreement. I said, nope, we're raising these funds now and we have the list of things to do.

We don't have exact candidates. We don't have exact amounts. When we get a candidate, an amount will get community approval just via a Manero research lab meeting, not with a full CCS and additional fundraising period. And we'll move forward just to cut out the paperwork because I think we've now done seven payouts and if each payout took multiple weeks, I'd be very frustrated by that.

So I've already created this fund and that's kind of novel to the CCS, especially because of the condition on remaining funds. 

Luke 
If there's remaining funds, it doesn't get yielded back to the general fund. It actually gets yielded to the Manero research lab's discretion.

So I've definitely pushed the CCS over the years and that's actually something I'd actually love to see continue to happen in the future, is more people create these CCSs that don't necessarily fit within the existing confines and expectations of the CCS, but best serve the moment because as the CCS is this somewhat informal process, it is allowed to have that flexibility.

And if people believe it's best to raise a large amount of money to work on post-quantum research instead of itemizing it, that is something the CCS can do and is something I'd love to see happen. If we have more developers who would prefer to work for retroactive payment, I would actually love to see that happen. From the CCS's perspective, it's arguably better.

There's no, you know, raising funds for something that may or may not happen. We already have this fully delivered library and or app. There are already users who enjoy it. If, yeah, it can kind of serve as a, you know, we've already had this deliverable. It's already enjoyed. Why should we not pay the developer for it?

So I think there's a lot more that can be done with the CCS, and I encourage people who want to work on Monero but are concerned about how funding is handled to consider CCSs even if they don't fit within, even if they're not in line with most CCS proposals. 

Doug 
That's good advice. And I'm glad you're encouraging people to do that. And that makes perfect sense. I mean, if somebody has accomplished the work already and proven that it can be done and did it, that deserves funding. I mean, that's much less risky to fund that than somebody who's proposing something and has it done. 

Luke 
It is risky to the user or sorry to the proposer because the proposer is now saying hey I'd like to explicitly get tipped this much via the CCS hosting a fundraise so now and this is why the CCS has shied away from it prior because now the CCS has to argue about is this work worth this much as payment except it's no longer payment it's as a tip and there's the question oh well did the developer do all of this work expecting to be tipped for it you know expecting this retroactive payment and if the CCS now doesn't host this proposal are we taking away expected payment um so there definitely is risk to the proposer in that regard my personal stance is that no the CCS should not feel obligated into uh hosting these fundraisers and that it should be considered a tip and it should never be considered expected or demanded payment and if the CCS does not believe it's proper to host on the CCS or if the CCS does not believe the amount is proper respective to the work performed I believe the CCS should just unashamed uh without shame just close it out and not host it but yeah there are still some discussions it's not quite as clean as I initially put it 

Doug 
Well, I hope somebody steps up and posts a post quantum protocol CCS sooner than later. I'd love to see that. Or Luke, maybe, I don't know, maybe you get re-inspired. You can't help yourself and you go for it again. Obviously, that would be amazing. No pressure. I do want to point out some of the super chats because I've been ignoring them. I didn't want to interrupt Luke at all. What do we have here?

We have somebody, LordGainstip3dollars, very generous of you. Congratulations, Zug, to you and your family. I just had a daughter this month. I want to tell her, Daddy and Mommy love her. Luna Raine, we love you with all of our heart. Oh, that's sweet. What do we got here? We have, let's see, Internet Treasure Tip, the dollar. Monero ecosystem is no joke, amount of work and devotion.

I am assuming devotion on the table is almost no equivalent. Agreed, agreed, agreed. XMR cash tip $5. Thank you, Luke and Doug, for being here today and updating us. Thank you. Thank you, Luke, for taking your holiday time or taking time away from your holiday jump on here. PrivacyOG, tip 25 cents.

Can you talk about the influx of malicious notes hosted by chain analysis and government agencies which spy on Monero users, how this may affect Monero user privacy and anonymity? Also, are there any plans to address this issue? Luke, do you want to take that one? 

Luke 
Yeah, okay. So there's definitely a few different implications here. If you connect to a node and you publish a transaction with it, then that node sees, you know, that, hey, this IP address is the one to publish this transaction. So if it's your residential IP address, you know, if it's, oh, this transaction comes from the house of Doug.

Okay, well, Doug probably made this transaction, or Doug's family here, they all use Monero nowadays. But that doesn't change. Like you can connect a transaction to a person, if you are the one that's published via, if they use their residential IP, and if they connect directly to you, and they publish the transaction through you, then yes, you can see the IP of whoever's publishing the transaction.

If that's a residential IP, you can very quickly kind of see who it is. So the best solution to that would be to use a privacy solution such as Tor or VPN, so that the node you connect to doesn't know your IP address. And that isn't, you know, quite complete, then they can still fingerprint you as a Tor user or as someone using a specific VPN.

And at that case, then you're best left to running your own node. And if you do run your own node to publish transactions, the next consideration would be if Dandelion++ is secure, Dandelion++ means if a node broadcasts a transaction, other nodes can't see which node first broadcasted the transaction.

So a transaction, you know, does appear on the network, but it's unknown which node originally published it. So even if you're running your node, you know, at home with no VPN, not using Tor, so on and so on, other nodes on the network would not be able to see that you were the that your house was the one which first published the transaction. So that's the role of Dandelion++, which is great.

There are still some attacks on it, notably at the ISP level at this time. So like, if you're a government agency, or if you have access to, you know, most of the world's ISPs, there are some attacks on that. And it's one of the reasons why the Manera network is encrypting its peer to peer layer.

That was one of the things I was trying to kind of hint towards earlier, how, you know, even if you're not working on full stream membership proofs, plus, plus, there's always work within Manera, and encrypting a peer to peer layer is a very big part of that, not exactly sure where that is, but I believe that's close. So that will also be a big, you know, boon for privacy.

The other consideration would be how, if you know, a certain IP address published a specific transaction, and you know that certain IP address published a distinct transaction, you can work to break down rank signatures and find out exactly which outputs were spent, because you know, not only which outputs they created, and the outputs they created, presumably include a change output, which will be spent at some point in the future by the same user.

But then you also know a transaction made in the future, which is, of course, likely to use that change output. 

Luke 
So if you do have a consistent IP address, across multiple transactions, you can work on finding out which outputs exactly were spent. And full team membership proofs do make that, you know, effectively impossible, where you can only tell that the same user made multiple transactions, but you don't learn anything about which outputs were involved with that. 

Doug 
Okay, somebody else is asking the input output limit for full chain membership blue proofs plus plus was that decided I don't know 

Luke 
Okay, so for context on this, with full-chain membership proofs, we're discussing limiting the amount of inputs that can exist within a single transaction. This is just following how we already do this for outputs.

As of today, we limit Monero to 16 outputs, and the main reason for that limitation is because outputs use a single zero-knowledge proof, and that single zero-knowledge proof actually scales according to powers of two. So what that means is that if you have three outputs, you're doing a ZK proof that's as expensive to verify as if you had four outputs.

If you do five outputs, you're forcing people to verify a ZK proof as expensive as eight outputs. If you do nine outputs, you're forcing people to verify a ZK proof that's expensive as 16 outputs. So you can very quickly just force people into verifying these very large ZK proofs that can take hundreds of milliseconds to verify, and that can be disruptive.

If you get a transaction and you won't know if it's valid until you spend an entire second verifying it, that can be problematic. That's how you get cake to no longer offer public RPCs, because now anyone can send them, you know, a couple of kilobytes that they have to spend an entire second computation on.

So we already don't have a limit on the maximum amount of outputs, and with full-chain membership proofs, the inputs have the same behavior. If you have five inputs, you're forcing people to verify a proof that was the cost of eight inputs. If you have, you know, nine inputs, you're forcing people to verify proof the cost of 16 inputs. So there are discussions about how we should limit inputs.

I believe it's largely agreed that we should limit inputs as outputs are limited. The exact question is where that's going to end up. There was some benchmarking done to try to inform that discussion, but that benchmark actually primarily just identified regressions within my work. It used to verify at 25 milliseconds, which is a number I'm quite proud of, and now it's verifying at 80 milliseconds.

So before that discussion can move forward, I actually have to fix my performance regressions. I do understand what code I introduced and why it's so much slower. It's definitely something I can fix. It was just something that slipped through the cracks on my end, and that's why we have all of this testing and evaluation on it.

But once that is fixed, we should have exact numbers and we should be able to say that, yes, this exact amount of inputs causes this exact milliseconds of delay, and then we can discuss how many milliseconds of delay we want to accept.

Because the worst case scenario, again, is that if transactions are such a significant computational burden, if transactions are such a significant computational burden, nodes would have to limit their public RPCs. We might be looking at paid RPCs.

We might be looking at users doing proof of work to justify nodes handling their transactions, because even handling a transaction and checking if it's valid could be very expensive. 

Luke 
And it isn't something where, like, oh, well, you can have the transaction pay a fee to the RPC, because, no, the transaction might be invalid. And if it's invalid, it won't pay a fee to anyone. So it's just considerations about ensuring the stability of the blockchain. I think I was advocated in my post explaining all of this and going over some of the initial timings.

I believe I advocated eight and eight, eight inputs, eight outputs. And the reason for reducing from 16 outputs to just eight outputs is because actually that shouldn't have too much of an impact. Most people already aren't making 16 output transactions. It's mainly used by large services who already have to have a lot of code to handle such batch outputs.

And if you already have the code to handle so many outputs intelligently, the limit of eight outputs alone isn't actually that significant. So then the question is about handling. So then the reason we reduced from 16 outputs to eight outputs, it's not just because it shouldn't be that much of an impact. It's also because I personally don't want to allow more outputs than inputs.

If I can create a transaction with 16 outputs all to Doug, but Doug can only aggregate eight inputs at a time, then if I make one transaction, Doug has to make two transactions to consolidate. And if I make two transactions, Doug has to make four transactions to consolidate.

So it's just this annoying thing where someone can flood a wallet and the user who's doing the flooding has to make less transactions than the user receiving the flood to consolidate. So that's why it makes sense to have max outputs less than or equal to max inputs.

And for max inputs, eight was just my recommendation of something I found sufficiently, you know, this isn't too much of a delay, this should still be healthy for the network. So my personal recommendation there was eight. That is a significant decrease from where we are now, but it should only add roughly 20 to 40 minutes of latency.

Even if you have to aggregate a million inputs or a million outputs, if you have to aggregate a million outputs into just one output, this still only adds 20 to 40 minutes. It doesn't actually mean that, oh, well, you're making the amount of inputs allowed in a transaction 20 times smaller because you get 20 times less inputs. You have to spend 20 times as much time performing this aggregation.

No, no matter how many inputs you have, this would only ever add 20 to 40 minutes to your aggregation process. So if you're already aggregating a large amount of inputs and you already have to do it across multiple transactions, yes, this does add multiple transactions, but over a finite time period. You're not actually spending several hours or even days. 

Doug 
We want to move on to Serai, but I guess one last question with regards to full chain membership proofs. What is it going to feel like from... And you just touched upon this a little bit. What is it going to feel like from the user's perspective? Obviously, that now things are going to be more private than ever. There'll be no potential attack with ring signatures.

So obscuring the signer will be better than ever. So in terms of privacy, it's going to be amazing. But in terms of usability, is the user going to see any impact? Obviously, we're saying transactions are going to be heavier. From the user's perspective, will they notice these things or it's not going to really be... 

Luke 
At the start, users shouldn't really notice anything different. There's going to be some impact to, potentially, there's going to be some impact to scan time because now you're not just scanning outputs, you're also locally building a copy of the tree.

So that would probably be the most notable thing that we also are working on optimizing not only building the tree, yet also scanning itself to compensate for that. There are going to be potentially a greater limit on the amount of inputs you're allowed and potentially a greater limit or heavier limit.

We're potentially reducing it from 16 outputs to eight outputs, but most users shouldn't be affected by that. There might be some services who are affected by that, but if they already have code to handle a large amount of inputs and outputs, it should largely be unaffected.

And then what's really significant isn't what's going to be at the full team membership proofs plus plus hard fork, which I don't believe is going to affect most people, but what happens six to 12 months after that when we not just have all of these new features, but we start taking advantage of it.

There's a lot of new features introduced that should greatly simplify the wallet UX, notably transaction chaining. So if you do want to pay out hundreds of people, hundreds of people, the great thing about transaction chaining is that you can make all of the transactions to pay out hundreds of people and you can sign them all in that very moment.

Even though there's a 10 block lock, that's not changing, you can still sign all of the transactions to pay out hundreds of people in that very moment. And then your phone just has to save those transactions. And even if you block your phone, your wallet runs in background mode and it does not have the private spend key in memory, and it doesn't even have the private view key in memory.

So there's no risk of someone stealing your phone and accessing any of your funds in memory or even your private view key in memory. Your phone running in the background can take these already signed transactions and just when the time comes for them to go on the Monero blockchain, it can just publish them in the background.

So there is actually a lot of really cool things we can do things to transaction chaining to enable wallets to handle more things in the background and not just handle more things in the background, but reduce how much the user has to interact with and work with their Monero wallet.

So that I'm really excited to see not at the full team membership for this plus plus hard fork, but as wallets start taking advantage of the new functionality introduced with. 

Speaker 2 
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. 

Doug 
Here we go. We got Luke back. So we spoke about full chain membership proofs. We spoke about the need for Monero to move towards being quantum resistant on the protocol level and the need for some group of people to take charge and take the lead on that effort. And now what I wanted to finish up was on Serai.

Luke has mentioned that he is stepping back in some ways, but obviously he's still going to be hustling and working on things related to Monero, one of those things being Serai, which ignoring all other things, if full chain membership proofs didn't exist, if none of this other stuff that he's working on didn't exist, this alone is just a tremendous, tremendous improvement, will be a tremendous improvement in the Monero ecosystem, basically a decentralized exchange that will allow people to move in and out of Monero fluidly and in a user-friendly way.

So Luke, if you want to go ahead and give us the update on Serai, let us know where things are at with that. 

Luke 
So I read a post about this recently about where Surai is at and where everything is as we move more towards auditing. Recently, there was a CCS file to audit Monero Surai and Monero Wallet. Monero Surai is something that I started building years ago as part of the Surai project, and it isn't Surai's integration of Monero, it's a general purpose Monero library in Rust.

There was already a Monero library in Rust that was just titled Monero. If you access it via the Rust package manager, if you go on its GitHub, it's titled Monero-RS, RS standing for Rust. But in Monero Surai, I actually internally used Monero RS. It did internally use it, because when Monero Surai started, it was initially just multi-signature for Monero transactions.

And Monero RS said, we don't want to handle signing transactions. And I said, well, I need an efficient multi-signature for the Monero project. And unfortunately, the Monero project itself does not offer in a minimal multi-signature protocol.

Even after all of the work that was done on securing it and making sure that it is viable for users to use, it does not meet Surai's use case or constraints for a variety of reasons, which is a bit technical to go into here.

But years ago, as part of Surai, I started building Monero Surai, which was a widely usable Monero library by Surai, in order to sign Monero transactions, build and sign them using multi-signature.

And it originally used Monero RS internally, just for all of you know, the transaction type definitions, like here's what the transaction looks like, here's the fields it has, here's how you read and write it over the network, etc. But what I ended up doing is completely removing Monero RS because it didn't flow well with the rest of the library.

Monero RS existed for specific reasons, and they set their bounds. They did not want to build a Monero node in Rust. They did not want to implement transaction signing. They did not want to build a full wallet in Rust. They just wanted to support this degree of working with transactions. And they did a really solid job with it, and I don't mean to criticize or hate them for that.

They did a solid job with it. They also did support some wallet functionality, like you could scan Monero outputs using Monero RS, which was great. That saved me a bit of work when I was implementing atomic swaps for Monero.

But the needs of the work for Serai was completely re-implementing Monero transactions in Rust and a way very ergonomic to the rest of my work, along with the code to create the range proofs, along with the code to sign the ring signatures and the multi signature protocol for it. And that was all done under Monero Serai until a few months ago.

It was actually, it might be several months ago by now, it was split between Monero Serai and Monero wallet. So Monero Serai is just all of our, you know, Monero transaction implementations.

So if you want to work with Monero transactions, if you want to verify them, as you would if you had a Rust node, such as the cup rate project, cup rate is attempting to rewrite the Monero node in Rust, doing its complete original implementation. 

Luke 
And they use Monero Serai internally for their transaction definitions and verifying the zero knowledge proofs within transactions. So that's what Monero Serai does. And then Monero wallet is our Rust library built on top of Monero Serai that supports building, signing, working with transactions, scanning all of that.

And it's what if you wanted to build a Monero wallet and you have access to Rust, it's what you would pull in as a dependency to actually scan and sign transactions with. And that is actually not only being used by the Serai project at this time, but there is a hardware wallet that is also using at least some parts of it. So it definitely is starting to get adopted, which is great to see.

And I did submit a CCS for both of these to be audited. Not only all of the Rust definitions of the Monero types and our proven verify functions, yet also the wallets, building a transaction, signing, etc, etc. So those audits were generously funded by the Monero community, something I'm thankful for. Thank you to anyone here who's viewing if they donated. And those are moving forward.

Those will not resolve until March. See, it turns out as part of re-inventing Monero transactions in Rust and building my own multi signature protocol for them, which is efficient, scalable, secure, all of that good stuff. There It's something that will take multiple months to be audited. It was the expectation moving into it, that just doesn't change, that won't be resolved into March.

The goal with the rest of the CI code base has been exactly that, cleaning and finalizing it for audit, and that's where we're currently at. The posts I wrote went into a lot more detail. I think we've managed to build over a hundred different libraries at this point, and that's not incredibly significant because some of them are small. Also, some of them are very large.

I believe the Soraya project is 60,000 to 80,000 lines of code at this point, which means, yes, a quarter of that work was just the Monero integration, or the libraries for the Monero integration. We're not even auditing our Monero integration at this time. We're just auditing the libraries usable by anyone, which we built our integration on top of.

But yeah, it's been a lot of work over multiple years, and it's preparing everything for audit and moving forward with audits.

Not only are we auditing our Monero libraries, usable by anyone, we're looking at auditing our Ethereum contracts next, which is used by our Ethereum integration, and we're also looking at auditing the distributed key generation protocol that I derived from a DKG in existing literature, specifically the quote EVRF paper. 

Doug 
Very exciting, very exciting. So once again, the annoying question, when will Anub like myself be able to actually use Serai, swap some Monero into Bitcoin or vice versa? 

Luke 
It largely depends on the audit timelines. Right now, we're trying to get the medical officer in progress and that won't be done until March. We're also actively trying to audit the Ethereum smart contracts and our distributed key generation protocol. As I just said, the next set of audits will be over, what will they be? I'm sorry, I have a whole list of things to audit.

I made a list of every single item. I don't have it in front of me. But basically, there are follow-up audit topics even after that. There are things that we're finalizing for audit, there are things that we have ready for audit, and there are things actively being audited, and the question is just when it's all going to coalesce together.

I don't really have an immediate answer for when, and I could give estimates, but unfortunately, I have now officially been burned before on estimates. I'm going to refrain from doing so at this time, sorry. But instead of saying hopefully in however many months, what I'd rather just say is every few weeks, here's the next thing that we got audited, which means we're that much closer.

Here's the next thing we got audited, which means we're that much closer, so on and so on. 

Doug 
close TM soon. Who else is involved in this with you that you could mention? I mean, obviously, you're doing the lion's share of work here. Do you have a team of people helping you out with Serai? 

Luke 
So, for a while, I was also working with a developer known as Akil, and they were good to have around. They did a lot of good work and helped out. They also worked on significant parts of our on-chain code. So, Serai, it's a very large project with a lot of moving pieces, but one of the things it has is its own blockchain.

Technically it has multiple, but for right now we're just discussing kind of the main blockchain where the swaps occur. And, you know, we decide who are going to be the validators, and we organize all of that.

So, on, quote-unquote, the Serai blockchain, where all of the swaps actually, you know, get ordered and we see how much each swap is worth and what the output is, and we say, yep, this amount should be sent to this location. They did a lot of work for that, which was great. They also worked on the client a bit. They also fixed bugs throughout the project.

So, I was working with them for a while, though currently they are not working for their Serai project just because of how things continued with timing and so on, and then I also occasionally work with some developers in the Monero project, Justin Berman reviewed Monero Serai and Monero Wallet, and they also helped resolve a lot of fingerprints we had.

Because that's the difficult thing about making Monero transactions is you don't just have to make the Monero transactions and have valid ZK proofs. You can make a Monero transaction and have a valid ZK proof, and the network will accept it. But if I'm trying to send you money, you're going to be like, what the hell is this? I have no idea what you're trying to do here.

Because a Monero transaction isn't just a list of objects and ZK proofs. It's also an informal messaging protocol. If I want to send you money, I don't literally just create an output for you and publish it to the blockchain. I also include in, quote unquote, transaction extra, this arbitrary data field. I also include everything you need to scan that output.

So when you see the transaction, you don't just see that it's a transaction that's valid with an output, but you also see, oh, there's this bit of randomness, which may mean it's a transaction to me and I can do all of these operations and oh, it is a transaction to me and I can double check with all of these various methods.

But that also means in order to send Monero, again, it's not just create a bunch of ZK or knowledge proofs, it's also speak the language that Monero wallets speak. It's not just the on-chain protocol. It's also what I refer to as the wallet protocol, which is how wallets communicate and interact with each other.

So now you have this challenge of building a Monero wallet that sends transactions as all other wallets do. But not just so they can talk to each other, but also so they appear identical. So if someone looks at the Monero blockchain, they can't say, yep, this transaction was made by CakeWallet. This transaction was made by Serai's Monero wallet. 

Luke 
This transaction wasn't made by Monero Ruyo. So you not just have to do the on-chain protocol, but you also have to do a wallet protocol and then you have to be indistinguishable to all other wallets and it is a lot of work. So Justin Berman went through a code base and resolved a lot of fingerprints and they did a really great job there.

I've also asked them to review some other parts of the SCRI code base. And then there is another Monero developer who's agreed to do some review and contributions to the project, which I'm excited for when work eases up on the Monero project itself. So it's not that there aren't other developers, but at this time I am the sole person actively working on Serai. 

Doug 
All right. All right. For those that want to get involved, that want to be a validator, that want to provide liquidity, that just want to acquire Serai Coin at the first chance they get, what do people need to do to kind of get in line and be ready to participate? 

Luke 
Right, so the Sorai Discord, the Sorai Matrix, the Sorai Twitter, all of those are good places just to stay up to date.

If you want to be a validator very early on, my recommendation would be to also participate in the test nets because the test nets will have you run a validator and you'll kind of see what's that like, what the flow is, how the different pieces all connect to each other and give you experience there and also enable you to start criticizing me for how I organized it.

So if you have experience with system administration, you can suggest better ways to organize it.

So yeah, if you want to run a validator, it's definitely participating in the test nets, but something I want to be clear about is I appreciate anyone who wants to participate in the test nets just to be there or to help out, but unless you have some experience administrating Linux servers, I'm going to ask that you do not submit your name for consideration because yes, it is expecting that you know how to manage a Linux server as will running a validator when the time comes on a mainnet.

It's not something that you should be doing casually and while someday it may be so abstract, it could be run on like a Monero Nodo or something, it's definitely not there yet and that's not the current conversation and that would be a lot of effort to be done in the future to even start discussing that. 

Doug 
I love the fact that you even said it though, that would be a beautiful thing. 

Luke 
Right, I'm just trying to be clear like what the expectation is for if you want to run a validator and be part of the test nets, which again will give you experience running a validator.

The next consideration, if you want to provide liquidity, that should be really simple just because Cake Wallet agree to integrate us at launch and not just integrate us as a swap provider, yet also including what's providing liquidity and so on.

So if you have Cake Wallet or any other wallet that integrates us at launch and you want to provide liquidity, it's just be aware that the time to provide liquidity has come and have a compatible wallet.

And then if you're a developer, the main thing I would ask is for people to help review the existing code base, make sure it makes sense, make sure it's sufficiently readable and easy to understand because there are some parts of it that are never going to be easy to understand. I don't think you ever get an easy to understand implementation of ring signatures or faulty membership proofs.

There's always going to be a degree of complexity to these things. But obviously, I have served in to have very clean, understandable and reviewable code. So if you are a developer and you want to contribute by helping to review code, look for issues or just have further confidence that yes, the protocol is secure and will work as intended, that would be greatly appreciated. Awesome. Fantastic. 

Doug 
Fantastic. We're almost at two hours. Luke, thank you so much for your time, man. I do want to maybe just finish off with... Obviously, you have the floor if there's anything you want to bring up, but just a general question of how are you feeling about Monero these days? I think there's a lot of excitement out there among us normies that are just Monero users. But how are you feeling about it?

It seems like it's being more used than ever. Obviously, we have full chain membership proofs that's right around the corner. That's going to be a major, major improvement upgrade. We have Serai coming out soon. That's going to be a major improvement in terms of people being able to access on-ramp and off-ramp into Monero without KYC. In general, how are you feeling about the Monero project these days? 

Luke 
Um, yeah, I think there's a few different considerations. Um, I think full team membership proves most plus is very important, um, because it gets, as I said earlier, it gets the protocol to be good enough. Um, but I think one of the clear things about that is I don't believe the Manaic protocol is good enough today.

I do believe that we need the protocol to be, uh, not only have complete sender privacy, but I also believe it needs, uh, forward secrecy. So I'm very excited for Monero to reach that good enough part and where it's sufficiently private that even I'm happy and confident to use it. Um, just because I think at that point, you know, Monero can truly claim to be a privacy coin.

Is it a privacy coin if it's not good enough privacy? And obviously I recommend Monero. I'm not trying to say Monero isn't a privacy point yet. 

Doug 
And not a positive over here 

Luke 
But I really think full team membership for us plus plus is just incredibly important and I'm very excited to see it Go live because it resolves a lot of questions and uncertainties That I will be happy to see gone and it's something I'm really happy to be able to have contributed to the Manero protocol I'm unsure, you know, if we'll continue to see G listings, obviously There's political ties that are changing with Europe getting harsher and America predicted to ease up a bit I don't personally celebrate exchange listings.

I think Manero should be accessible However, that access is to occur and if decentralized exchanges are so superior Then they will naturally kind of start beating out centralized exchanges in this role So I don't think we have to be delisted and I don't personally celebrate the listings but you know, it's obviously great that solutions are being built whether it be basic spawn Pavano or Serai to Ensure access to Manero, which is something I'm going to be I'm really happy about and it's great to also be contributing on I think I kind of Ended up working on I think what is Manero's two biggest problems, you know full team membership proofs and then also access to Manero So it's great to see both of those things and it's gonna make me feel a lot better about Manero's Place in the world place in the ecosystem and its ability to continue Giving people everyday people access to privacy when they want it Regardless of where they are or what means they have access to and I think that's really what it's important and what's what it's about 

Doug 
How do you feel currently about the adoption that we're seeing? I mean, do you think Monero is actually being used? Do you think we're doing well in this area? Do you think we could do better in this area of actual use, actual adoption? 

Luke 
Adoption isn't my area of expertise. It's not something that I actively track. But I always hear about people having a lot of successes with Monero and whether that be because they're, Monero supremacists who try to use Monero at every moment and even ask their waiters, hey, can I pay in Monero and try to get them to download a Monero wallet?

Or it's just because they use Cake Wallet and Cake makes it extremely easy to get a variety of gift cards for any place they shop, whether it be Chipotle or I believe they even do have prepaid credit cards, which are kind of just literally anywhere for whatever reason, like if they're just using Cake Wallet to be able to spend their Monero, I think that's great.

I think it demonstrates that yes, Monero is usable on a day-to-day basis, which is incredibly important. And even if Monero isn't the world's number one currency and it's not being used by everyone in every country, if people who want to use Monero are able to use Monero, then I believe it's been sufficiently adopted and that makes me happy.

And I think there are a lot of people today who want to use Monero and do use Monero. 

Doug 
Why have you chosen to devote your precious time to Monero, man? You're an Uber genius. You could have been focusing on other crypto projects or just other things completely. I mean, why? Why did you devote your precious time to Monero? Why Monero? 

Luke 
For me, it was the ethos, and the other impact was Monero was where I could make a change. I really liked Monero's ethos about not having transparent transactions, about always having private transactions. I think that's incredibly important. I really liked Monero's ethos of not having the pre-mine and being decentralized.

And that's decentralized not just on the network layer via proof of work, but that's also decentralized in how it's organized with the IRC rooms, the matrix rooms, the lack of closed-door development teams. Monero just had a really great ethos. And well, just factually, Zcash's on-chain privacy technology is much stronger, and it has been stronger for several years.

I wasn't a fan of the trusted setup. I wasn't a fan of the development fund. I wasn't a fan of how the electric coin company operated. And while significant changes have happened, the development fund is being reworked. I don't believe it goes to any centralized entities as of the most recent hard fork, with some discussion on how decentralized the new setup is.

For right now, I think it just goes to a box. I don't think it goes to anyone. I think it's just earmarked away in the protocol itself. I'd have to double-check.

While they've removed the trusted setup, which has been great on that role of Zcash, while there's been new leadership at the electric coin company who's really making a lot of very positive changes, the other impact I wanted to note is simply that when I worked for the Monero protocol, I was able not only to tap into this ethos I already liked in a community vibe I already supported, but I was able to advocate for changes to what I didn't like and didn't find acceptable to create this Monero today, which has full-chain membership proofs plus-plus almost out the door.

But if you wanted to discuss my work on Zcash, well, I can't make Zcash more private because it's already accomplished its privacy goals. I was not going to be intelligent enough to build the new ZK proof systems that they were using to remove the trusted setup. And while with full-chain membership proofs, I did create a system without a trusted setup.

It was building on a lot of existing technology and academia over the years to the point where I had to put the pieces together. And while I think I did a very good job putting the pieces together, I wasn't designing new ZK proof systems entirely. And that's what Zcash was doing when they were working on removing the trusted setup. So I just wanted to be able to contribute there.

And while you can then discuss, you know, if I wanted to contribute to Zcash, like if I want to contribute to their ethos, I don't believe if I had spent the time I worked on Monero working on Zcash, I would have been able to get them to deprecate the transparent transactions and move exclusively to the shielded pool. 

Luke 
I think that is a very complicated subject, and it requires swaying community sentiment incredibly significantly because you need the community to sign off on it. Not just the community, but all of the organizations involved with it, you know, the Electric Coin Company and the Zcash Foundation, all of their partners.

And that is not someplace I can effectively work, nor do I believe I could have done that even if I spent all this time I developed on Monero working as a Zcash influencer. So that's why I picked Monero. It's because I like the ethos, I believed in its goals, and I believe that I could fix the issue I saw with it achieving its goals. 

Doug 
What do you think should be done needs to be done to make sure we maintain that ethos? 

Luke 
Yeah, I can bring up some niche discussions, like one discussion is transaction uniformity. Instead of every transaction having a variable amount of inputs and outputs, like some transactions might have two inputs, two outputs, some might have five inputs, two outputs, some might have one input, 16 outputs.

One of the proposals is for every transaction just to have eight inputs, eight outputs, every single one. And there's a lot of discussions about how to handle the performance of that, how to implement that practically. And it does increase privacy, because now you can't tell if it's a service who's paying out eight people at once, or if it's a user paying out a single person.

You will no longer be able to discriminate transactions based off their amount of inputs and outputs. You know, I could argue, well, it makes everything more private if you can no longer tell how many inputs and outputs a transaction has. I don't think it's a pressing need, and while I think it's a long term goal that should be worked for, I don't think it needs such explicit prioritization.

So really, it's just, I think the next step is surviving the quantum computer hurdle. You know, it's our arguable great filter in the world of cryptocurrency, where a lot of cryptocurrencies aren't going to cross the filter. So the question is, how do we ensure Monero crosses the filter, and not just that it crosses the filter, but it remains usable after the fact.

And that isn't just about, well, we can't have transactions via gigabyte. No, it's not just about having, you know, reasonably large, reasonably efficient transactions, but it's also about the functionality that makes Monero what it is today, about how we handle addresses and incoming and outgoing view keys and how we handle membership proofs.

Because if we want to do a post quantum cryptography, if we want to move to post quantum cryptography, one option would be to revert back to ranks, to drop full sender privacy and revert to ranks, because there has already been protocols posited for ring signatures with post quantum cryptography. We should not revert back to ranks, that would be such a bad idea. I would not be happy about that.

But that's the thing we're going to have to put in this effort in this work to make sure that we don't revert back to rings and we maintain full chain membership proofs. And then the next question is going to be how do we handle signatures? Will the signatures be amenable to multisig? Or are they going to force users into fully homomorphic encryption, which is a mess?

And if anyone proposes that for a multisig, there's your protocol, you know, they're only proposing it because they have no other options. So they're just picking the worst option possible because it is the best option possible because it is the only option possible.

So like there's all of these impacts to surviving quantum computers, not just to build a protocol, but to build a protocol which preserves all of functionality we have today. And that is what I think is going to be very important and why we need to start planning these efforts now. 

Doug 
All right. We'll leave it at that. Luke, Matt, thank you so much. Anything you want to put out there that we didn't cover? Any info you want to get out there while you have the stage? 

Luke 
No, I think after two hours we've done a very comprehensive thing. 

Doug 
Extremely comprehensive greatly appreciate your time and all the efforts you put into Monero. Yeah 

Luke 
I mean, thank you for your time. I'm the one who had a few hours that my family wasn't asking to do anything with me for. You're the one who just had a newborn. I think your time's a lot more in demand right now, Doug. 

Doug 
I got Sunita giving me the stink eye over here. I got to get back to the newborn. Of course. Say hi for newborns. All right, Luke. Will do. Luke, thank you so much, man. Greatly appreciate everything and hopefully we'll be in touch. Thank you, man. Yeah. 

Luke 
It's been great. Thank you.