 Anyway, we've got another talk coming up. This is Justin Ehrenhofer here. He represents DVChain and he'll talk with you about that. He's gonna be talking about the woes of Monero. That's right, it's not all sunshine and rainbows here in Monero land. We're gonna be talking about Monero's release schedule and one of the ways that we can do better. All right, thank you so much Diego. There's no better person to introduce me than the person who talked about how Monero was so difficult and ugly to use earlier today. So I appreciate the honor. So yesterday I'm talking about Monero's release schedule and I'm specifically talking about some of the components, some parts of it that have been really frustrating to me to watch as someone who is trying to help organize everything and help get everyone involved in the ecosystem. It's been a recent significant sticking point and I think that as the community has grown and continues to grow, it's something that we're going to need to manage better in the Monero community. So as an introduction, my name is Justin Ehrenhofer. I work for DV Trading and DV Chain. DV Trading is a proprietary trading firm and DV Chain is an OTC market. It actually is the largest OTC firm for Monero. So if you're interested in doing large trades of Monero, I do compliance with them so I can walk you through our onboarding process. I also organize a Monero community work group. So that's what's most relevant to this specific conversation. I'm the one that tries and encourages everyone to show up and participate in community discussions even though they're all volunteers. So I'm saying, hey, so can I just book every Saturday that you have from now on? Because there's always things to do and some people appreciate doing that more than others or are more willing to do that than others. So just to give a little bit of background, Monero's had some difficulty with its release schedule over the past few releases where the releases have always been quite delayed or they've been very last minute and I think that there ultimately is a better way for us to handle releases just by making really small changes, being willing to formalize in certain ways. So I'm going to start the conversation actually with a summary and then work backwards. So I want to start with these high level takeaways which are that Monero's release schedule typically is nothing short of chaos. It's making the binaries built a week before, sometimes two days before the actual upgrade is scheduled and the entire ecosystem to upgrade in that process. It's the past precedent that Monero has had not only the nodes update, but also the miners that needed to update all of their software too. And so then we have a day or so of significantly lower mining power. I know hopefully we expect that to change but that has been a significant grievance in the past. And the idea of having updates, in my opinion, isn't a problem in this current state of Monero's ecosystem development. Updates are fine and we need to keep making Monero better but we sort of need to get our act together in the process of doing these updates. We need to be much better at them. We do them twice a year. Why aren't we better and more efficient at doing them? We have so much practice, we should be getting this right a little bit more. And it's not usually effort that's the issue. There are so many contributors that spend a ton of their free volunteer time making the Monero update as smooth as possible, answering all the support questions but ultimately it's not enough because at the core we're not doing the things we need to to set these contributors up to having the best impact on the ecosystem and setting them up for their best success. We really need to be better at communication in terms of expressing to the ecosystem what we're trying to do and why and just having better conversations overall in order to better our update cycle. So this is what Monero supposedly does for our update cycle and this was published actually from a 2015 year in review. So this is an old document. Two years after Monero was released, the Monero core team made a blog post that had this really long A through J process for coming up with decisions. And in it it documents some things like the Monero core team scheduling specific meetings and holding votes during specific meetings. And I think anyone who's really been around in the Monero ecosystem realizes this hasn't been the case for at least the past several years where core team members are often have varying levels of activity and many of them are active and in the meetings on a consistent basis. But it hasn't really been the case that the Monero core team has said, oh, we want to consider this update, let us schedule a meeting and I'll attend and I'll vote on things. It hasn't really worked out that way. So I think that things really have changed since 2015 and we need to take a look at our governance process. And I'm not saying in a really hyped type completely overhauled the way Monero governance is handled but I think we need to be more accepting of more formalization, actually more bureaucracy frankly in terms of approaching this process so that we can have a better outcome for everyone. So I want to walk through two case studies. Let's first look at the most recent spring update and this was an especially chaotic update which is why I'm mentioning it. But on February 10th and I'm going to start by walking through the timeline the Monero core team decided privately that they would like to push the update forward one month. So the update was originally scheduled for about April that's when it was previously communicated to the rest of the ecosystem and they decided that they wanted to have it in March. This is for several reasons but mostly it was because there was strong evidence that there are a large number of ASICs on the Monero network and they had indicated that they would like to prevent this from being the case. So it was moved forward but there was no discussion in terms of asking if the community felt that this was the right decision or really having a nice open discussion about it. It literally was not even a Monero core team member it was MoneroMOO who's a very active contributor just posted in the dev chat saying hey by the way the actual update is this day. And everyone's like okay why, how did this happen? Who made this decision? How is this like a real decentralized community generally if these things just happen, right? And so I was not completely against it but I was concerned because I know that updates are a difficult process. So yes, the early release date happened on March 9th and we had the ODOT 14 software released on February 25th but this ODOT 14 software did not include any of the changes that had been built up over the past six months all the development that work that had been done over the past six months. It merely had very limited consensus changes that wanted to be made but it had none of the really cool updates like pruning and faster and more efficient transactions. All of that was delayed and it was not until July 17th that the 14.1 release came out that included all of those features that we were waiting for. So by moving the release forward one month we actually delayed three months of development in the process and I think that most people who were involved in the development process more intimately than I was during the time period can generally speak to that the difficulty of those complications. Furthermore, this was just the official Daemon CLI software this is not even talking about the GUI software which was delayed on top of this because they basically need to wait for all the Daemon software to be done before they go with their own update process. So everything was delayed and it was just a total mess and we can argue that perhaps it was worthwhile for the benefit of forking the network to remove the ASICs from the network and I think that's a valid argument but we have to be more efficient than three months after our original expected release was. Really it was four months after the actual hard fork occurred that we brought all the features that we were anticipating to come in April and these are features that people legitimately would benefit strongly for. So yeah, I'm gonna look at the second case of payment IDs. To give a small background, payment IDs are used in Monero as one way for a recipient to identify where money is coming from since recipients can't just look at a transaction nor money's coming from since Monero is private. They have to give an identifier to the sender in the transaction so they know who's sending the money. There's three main ways to do this. There's long payment IDs, there's short payment IDs which are on a newer form and there's sub addresses. All three have varying levels of advantages and disadvantages. But in May 2018, I opened a discussion on GitHub and this was after some previous earlier discussion to say, hey, long payment IDs are not super great. And I'll discuss in the next slide why I'm just covering the timeline here. Let's move past them and let's sort of have a discussion in regards to this. So in December 2018, it was the main topic of the developer and MRL meetings during the time period and January I scheduled a specific payment ID meeting to talk about this. And in June 2019, De Bruyne, who's a main contributor to Monero, published a long payment ID deprecation blog post that expressed that Monero wanted to deprecate long payment IDs for the October release, which of course is happening this October. And this discussion was a really, really difficult one because many people had completely valid and understandable logical positions for why they felt a certain way, but it was super, super difficult for us to come to consensus and agreement in the Monero community, even though we largely agreed on what we ultimately wanted to do. So first, everyone agreed that long payment IDs were bad. Using them is really poor for your privacy because if you're presumably making deposits at the exchange several times, let's say, with one specific string that everyone sees, it's a super, super easy way to link transactions together. So they're very bad, in addition to just being another type of transaction that can stand out. A few people argued for the removal of short payment IDs. I was one of the individuals that argued for it, but not everyone was on the same page there. That's fine. The benefit of some addresses over short payment IDs is much smaller than the benefit over long payment IDs. So that's fine. And so we had a lot of discussions based off that, but ultimately the really, really difficult part is that we struggled so much about what deprecation meant. Some people argued deprecation was just making the feature off by default and putting it in advanced settings of the wallet. Other people felt it was appropriate to remove it entirely from the wallet, but not do anything on the consensus layer. And other people felt that some type of consensus filtering was appropriate, even if we couldn't ban all of TX Extra. We just did some consensus filtering with how people were using payment IDs in the TX Extra. You can see how this really gets into the weeds for something that should be a relatively easy high level discussion. And then also we didn't agree on how we wanted to deprecate it. Is this something that would be temporary for the sake of just hoping people switch over in the meantime? Or is this something that would be permanent and we're gonna continue doing these things forever and each had their own set of trade-offs? So this was a ridiculously long process and ultimately what is gonna happen for the October update, deprecation means where it's going to be removed from the Monero-Gui and Monero-CLI wallets, but we can't speak for them in Monero-Ruio wallets. We can't speak for the Cake wallet wallets or any other wallets in the ecosystem. They can continue using the long payment IDs. So deprecation means, in this case, just removed from the Monero-Gui and CLI official software. So in my opinion, that wasn't going far enough. Some people felt that was appropriate, but it was such a difficult conversation and I needed to take a break after going back and forth for so long here. So I wanna take a minute though and really say that it's not all bad, right? Monero has many really interesting areas of success because its decentralization gives it a lot of really awesome properties that we love to talk about, right? So first, it has a strong decentralized passion. It's very unlikely that controversial changes to Monero or that are proposed for Monero will be implemented if it's a really dumb feature that's gonna be debated for a very long time. I have confidence that perhaps second to Bitcoin, Monero has some of the longest deliberation process in these regards because the community is so large and there are so many different stakeholders involved. And the best part is that these stakeholders all generally care. They all express really important points of view and they're typically doing it from good intentions. They're not coming in for the sake of trying to force their way through these discussions. Generally we're able to have really, really good productive conversations even if people have wildly different points of view on how they want systems to proceed. There have been a few conflicts in the past those are very, very minor and they're very rare typically. And of course, if we need to step back and say like ultimately we're doing the right thing we can see the Monero community continues to grow so at least we're doing something right here. That's some of the good news. But of course, the whole point of this talk is that I feel that there's room for improvement, right? And this is one problem that every project has not just Monero but we'd love to have more code reviewers of course. We can have all these changes and people will look at them but we always need more people looking at them. So that's not my main concern but ultimately it's everything else that's involved, right? It's that historically the Monero core team is a bottleneck and I don't want to dress everything on the core team right there a volunteer organization but they have these roles and ultimately they need to decide or delegate how tasks or how specific updates are going to be involved or implemented. And so we need the core team buy-in. If we do not have core team buy-in there will be a bottleneck because I can schedule my own meetings in certain times and invite everyone else to show up and we can all perhaps come to some type of consensus but then we need to talk to the core team and make sure that they're okay with whatever the people we previously spoke to are okay with and it's just difficult to have so many different conversations. So just the requirement to have all those conversations is quite difficult. In my opinion, we need to have more formal processes and a more concentration of these discussions in order to make sure everyone knows first of all what these discussions look like so they can participate but also so we're not repeating discussions hundreds of times over as we did with the payment ID discussions. There weren't really any new discussions, new points that people were bringing up six months into the discussion but we were still arguing with each other and it was just really, really frustrating. We have tried to do this but we really need to make sure that we're reaching all the appropriate stakeholders in the Monero ecosystem. We've historically struggled to speak with exchanges to see what their opinion on payment IDs are, for example. And we've tried to use the Monero mailing list but we don't really know how many people are actually on this mailing list. So it's just something to keep in mind that we need to actively keep trying to make sure that these individuals are engaged with the Monero ecosystem as we're making or doing these discussions and in my opinion having a simple process that we can point them to will help get them engaged. And then finally, I think that Monero needs to commit to many, not all changes because life happens and things and we need to have some flexibility but we should be planning the changes in advance. I'll talk more about that later. So what are we doing right now to do community consensus? Like what does it look like? Well, it's a ton of stuff and it's all over the place, right? We have GitHub issues and pull requests where people will comment on their opinion on certain things that either are in the process of being merged or an idea that people are discussing. We have scheduled community developer, MRL meetings, you know, meetings for every specific work group you can think of and they all have their own discussions and they communicate with each other but ultimately they can't necessarily speak for everything that's happening in Monero. MRL might suggest a change to the Monero protocol but that doesn't mean it's gonna be developed and that doesn't mean it's gonna be implemented on the schedule that they feel is most appropriate. There's many moving parts here. On top of that, you have Reddit discussions, you have IRC discussions that happen ad hoc, you have Telegram discussions sometimes. These things are all over the place and in my opinion, when you have such a chaotic hands-off decision-making process where you're making decisions all over the place on dozens of different platforms all the time, at random times of day and the participants are popping in and out and it's never predictable. In my opinion, having such a process where you never know what to expect is more centralized than just having a clear formal process. Having a clear formal process doesn't mean that it's centralized or one person just suddenly makes an adverse dictator decision. It means that there's more exposure to this decision and people are more able to participate in the discussions that ultimately lead to a decision being made. So let's take a look at what some other groups are doing. So Zcash has this remarkably complex process and I'm not saying we need to jump to this level but I wanted to highlight a few timelines just to show how different it was with the Monero community where often things are merged like the day of the release sometimes. So with Zcash, 13 months before they plan to start the initial ideation process and about eight months before they want to freeze the specification. So by this they mean eight months before they want to know what's going into the update that will happen in eight months. We are nowhere close to that. We're at best case scenario six months for the huge features and for the little everyday things it's like a week at minimum, right? It's very, very sudden and so again, I'm not saying we need to jump to necessarily this extreme but some small shift in this direction is probably for the best of the ecosystem. SIA for example does a public feature roadmap where they at least outline everything they would like to work on in the short, long, medium term and things that they've recently done and again it's not a super complex process. It's literally just saying these are the things we are working on and would like to work on. We don't really have a list like this for Monero at all. We have a list of some things certain individuals are interested in like I can tell you what I think is interesting. I'm sure Sorang Noether can tell you what he thinks is interesting. I'm sure that someone from like Monero Move is working on recently but we ultimately haven't taken the step back and say like this is what we envision Monero being like in six months or in two years. We're not there yet which is kind of remarkable. Again in my mind having the formalized process does not equal the same thing as centralization. You can say that in order to participate in this discussion we want you to submit feedback ahead of time and we're all going to commit to be here at this one time. That's in my opinion not bad centralization. I think in fact it's more likely that you're going to interact with more members of the ecosystem. It's not going to be a few close friends that are passing messages on IRC and then are going to themselves schedule a meeting that isn't widely distributed to stakeholders because they never thought about them in the process because they're just engaged with a small group. So by making more formal processes Monero can provide more clarity in the decision making process because people know how to participate and they generally know how these decisions are being made. We can engage a wider set because we can invite people to specific things and tell them these are the specific actions you need to do and what you or what you should do and we can communicate these changes in advance to people. We can say, hey, this is what we came up with the meeting, you know, in six months we hope to do this. Plans can change but it's good to give people that headway and we can actually reduce core team influence by giving others a clear platform to actually communicate these things. And in my opinion that will offer better and less chaotic release cycles because we're more likely to be able to point people to a system, a process which again doesn't need to be like law, there can be some flexibility but just approaching it from the idea of having this initial process in my opinion should be pretty helpful and it has large benefits. So to be clear, there's a few things I do not propose here because there are some people that are looking at this and thinking I want to go far, I want to be clear, I'm not trying to make Monero like the centralized, you know, we determine what goes in and make it lose all the benefits. So what I do not propose is, you know, open voting for specific proposals because it's just, it's not a reliable indicator. People, you need to make opportunity for people to come and express their logical points of view and so forth but you can't just leave it up to an open vote just because the ecosystem is so variable. Similarly, I do not encourage delaying critical security patches, right? If there's a security patch that needs to go in you shouldn't look at your timeline and say the next release is in six months and we can't move or budge on that. We need to be able to budge on that and I'm not saying we should just point to a chart and just wish the rest of our problems away. And I'm not saying that we need to upgrade it like every three months or whatever or we need to go through an outrageous process all the time. I'm just saying we need to take a step back and plan things out better. And I'm also not saying that the core team needs to run every aspect of this process. They can delegate these things to people but it is critical that the core team buys into it, that they're involved in this process. If the Monero Community Work Group, for example, independently tried to do a lot of these things and the core team completely ignored it, it's not to a large effect. We're able to perhaps try and bring a lot of this ecosystem together but if it's not used in a good way it's a lot of wasted effort. So I would love to see a solution where the core team is able to interact very closely with the individuals that are scheduling these meetings that are doing all the daily administrative work so they're not handling that process but the core team feels comfortable in the process that ultimately has been created because the core team will ultimately need to sign off on whatever gets merged anyway so we might as well have an open process that everyone is comfortable with. I want to stress like the Monero ecosystem has grown so much since we've last had these type of conversations. I know you're not able to read all those bubbles on there but they represent the different work groups and exchanges and companies and things. Back in 2015 when we had that last post about community consensus and decision making it looked like this, right? The community work group didn't exist. There were very few other services. It was a really, really small group and so as we've expanded, as Monero has grown we can't rely on someone to be able to follow every discussion that is happening all the time. It's just way too much for a single person to handle. I can't handle it and it's kind of my role. So with such a diverse set of stakeholders the core team and community really need to embrace formalization in some capacity or else there's going to be way too much noise and there's no good way to make decision and ultimately then it will just be the core team making a decision anyway and there won't be a good way for people to argue with past that noise. And there's no good way like I mentioned to keep track of thousands of conversations. I feel like the task should be delegated to work groups as needed as according to a process that the core team and others feel comfortable with and we need to be open about what those processes look like and ultimately I think that bureaucracy is good if it helps get people on the same page. Again, I'm not suggesting that you can only suggest a proposal like three years in advance and your name needs to be Justin or whatever else. Like don't go to a full extreme here but just very, very basic. Just like the super simple stuff. Just a taste of bureaucracy in my opinion is all right. And so the core team needs to embrace these responsibilities because ultimately they are the ones that determine what gets added and what doesn't. So in my opinion, if they want to be engaging a wide set of stakeholders and if they want to be able to cut through the noise that happens and to be able to make nice quick decisions they need to be able to delegate or abdicate these responsibilities so that we can continue to be adaptive and make important decisions within the narrow community. Smart communication really is key in order to make the ecosystem function make things happen happen. So I've listed some specific baby steps that I think would be a good step in stone towards getting, like to testing the waters a little bit. So first, I would like us to actually commit to coat freezes one month before the releases. This is something that Monero has said it would do for the past two or three years and it's maybe half of once. Just there is a ton of chaos going on but we haven't really been able to plan for several reasons including the last minute mining algorithm updates. But now that after October we're not planning to do those anymore and we know what the one in October will look like let's actually commit to a month before this one in October. Similarly, let's actually plan out what we want to go in the release six months before. Just some basic high level picture I feel like would be really important. Narrow core team member and large important community stakeholders sit down and just write down where they see Monero in six months and two years and let's make it have an open discussion from a high level strategy point where Monero plans to improve. Let's also be open to the idea of frequent and scheduled minor feature updates. Now that we have reproducible builds we don't necessarily need core team to be releasing these small updates that don't impact consensus all the time. Maybe it could be that a work group for example is in charge of maintaining these releases and other trusted members of the community which could also be core team members just test the binaries and make sure that they have the same hashes and so forth. This doesn't need to be such a, this doesn't need to be a process or completely reliant on the core team out anymore. Similarly, we need to make timelines for the major features. If we're looking to implement lightning network with Monero we should say this is something that's in our two year horizon or whatever else it might be the case just speaking openly about those issues with timelines I think is really important. And then having formal submission prop procedures for large changes are really important to having open conversations about them. So next time Monero wants to let's say change the way that it has its fee structure based off the way Ismus had his talk at the ConFrenco where people are sometimes using weird fees. Well then maybe we should actually organize a discussion where the core team is involved or where the community is able to organize and have these discussions where people submit feedback ahead of time and it's a much more clear process for everyone involved rather than hopping all over the place. And then we can always set in here to reasonable deadlines and ideally only change them if the situation also changes. If there's no reason to delay a feature we should do our best to really try and stick to these deadlines because one critical part of Monero's stability are predictable updates and I don't think we're really there yet, right? So in summary, right? Plans may change, shit happens, life gets in the way, right? We're part of Monero and one of the reasons like something Sarang said that really resonated with me is that Monero is like an engineering project, right? We, the MRL does a science in a corner but like ultimately we're making software that people use and so we need to keep reality in check and so with this talk I'm not trying to say that we need to plan everything out that we're gonna do for the next 10 years because it will change. But if startups are trying to get VC money they don't go into the room typically and say we have no plan, right? We have no idea what we're gonna do, please give us money. Instead the expectation is to outline a plan and the understanding also is that it will change. There's no requirement that what's on the paper is exactly what will happen because it's a very flexible startup environment and so ultimately what matters is that we make these goals we're willing to change them as needed but also that we're communicating them clearly and we're on a better initial page for a lot of these discussions so that the community can scale, can continue to grow because otherwise the community will become so large the community will have so much noise in these discussions that the core team and others will not be able to make adequate assessments about what are realistic processes forward. And on that note, I'd like to thank you for listening to my talk about Minero's release cycle and I'd like to open it up for questions I have about two minutes. Thank you. All right. Yes, Sanya. Yes, so Sanya's question to the stream is a pushback on formalizing slightly. In some ways I think people are open to it but there is certainly some concern that by trying to make a formal process that we're introducing a potential point of centralization where someone's ultimately making a process that could be exclusionary, that could be for the furtherment of certain ideals and that just by having such an open discussion that I mean that's not a risk but to my point I feel that we're actually opening ourselves that no one can make a realistic conversation no one can have a realistic voice if there's no way to filter things. So I would say that there is certainly some pushback I don't think it's all like a hard no or a hard yes either way. I'm trying to push the community in this direction a little bit though. Yeah, and we encourage everyone to form their own work groups. Anyone can form their own work group, right? Any other questions? Yes. Yeah, so the question was on the vulnerability response updates and I will say it completely depends on what the vulnerability is and what the situation is. I'm likewise not advocating that Minero needs to immediately update every time there's a flaw because perhaps that might not be the best course of action. I'm merely stating that just because we had a six month plan does not mean we should exclude the idea of doing an emergency upgrade if we feel that that's a proper action. That is the main point I'm trying to get across. All right, and it's been over 30 minutes so I really appreciate your time. There will be a 15 minute break before we move on to Alan Stavo who's giving another talk, second one so he's the real champ in this conference. And Diego, do you have anything else that you would like to mention? Oh yeah, party. So stick around after that talk there will be an announcement for the party. So there's a pre-party and a party so get ready. All right, thank you everyone.