Monero Village - Monero's Release Schedule: we can do better
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48725 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 27303 / 335
8
9
12
14
32
38
41
58
60
61
72
75
83
87
92
96
108
115
128
132
143
152
158
159
191
193
218
230
268
271
273
276
278
295
310
320
321
335
00:00
CAN busBroadcast programmingPoint (geometry)BitProcess (computing)Data conversionScheduling (computing)Online helpGroup actionSelf-organizationMereologyChainConnectivity (graph theory)Level (video gaming)MathematicsLatent heatWave packetComputer animation
02:09
Broadcast programmingChaos (cosmogony)TelecommunicationProcess (computing)BitTerm (mathematics)Chaos (cosmogony)Binary codeState of matterFreewareLevel (video gaming)Ocean currentSmoothingRight angleOrder (biology)QuicksortData conversionTelecommunicationCore dumpMultiplication signScheduling (computing)Power (physics)Software developerData miningSoftwareComputer animation
03:47
Moment (mathematics)Process (computing)Core dumpLatent heatLattice (order)BlogScheduling (computing)Formal grammarProcess (computing)Basis <Mathematik>Cycle (graph theory)Type theoryLevel (video gaming)VotingCASE <Informatik>Term (mathematics)Computer animation
05:04
Spring (hydrology)ImplementationMathematicsCodeProcess (computing)SoftwareNumberFrequencyCASE <Informatik>Observational studyMultiplication signDatabase transactionParameter (computer programming)Software developerDecision theoryCore dumpLimit (category theory)Term (mathematics)DemonSpring (hydrology)Computer animation
07:58
Radio-frequency identificationBlogSoftware developerCASE <Informatik>Intrusion detection systemLattice (order)2 (number)IdentifiabilitySlide rulePosition operatorLevel (video gaming)BlogFrequencyDatabase transactionLatent heatAddress spaceMultiplication signForm (programming)QuicksortComputer animation
09:36
Type theoryGraphical user interfaceProcess (computing)Intrusion detection systemWeb pageLatent heatAdditionControl flowSet (mathematics)String (computer science)Flow separationDatabase transactionDefault (computer science)SoftwareMereologyArithmetic meanMultiplication signCASE <Informatik>Address spaceVideoconferencingData conversionComputer animation
11:47
Perspective (visual)Physical systemView (database)Point (geometry)MathematicsData conversionGoodness of fitDifferent (Kate Ryan album)Revision controlRight angleProcess (computing)Confidence intervalMereologyMultiplication signCategory of beingAreaComputer animation
13:08
CodeFeedbackSoftware developerHill differential equationCodeRight anglePoint (geometry)Software developerData conversionMathematicsType theoryEmailProcess (computing)Intrusion detection systemArithmetic meanMultiplication signCommunications protocolComputer networkLattice (order)Core dumpTask (computing)Self-organizationOrder (biology)Video gameConcentricElectronic mailing listProjective planeScheduling (computing)MereologyLatent heatGroup actionMultilaterationComputer animation
16:18
Software developerHill differential equationFormal grammarProcess (computing)Decision theoryDecision theoryDifferent (Kate Ryan album)RandomizationProcess (computing)Formal grammarMultiplication signComputing platformComputer animation
17:00
Process (computing)Complex (psychology)Direction (geometry)Shift operatorGroup actionCASE <Informatik>Latent heatRight angleMaxima and minimaLevel (video gaming)Computer animation
17:57
Inheritance (object-oriented programming)Term (mathematics)Electronic mailing listComputer fontComplex (psychology)Process (computing)Noether's theoremComputer animation
18:42
Process (computing)Normal (geometry)Decision theoryComponent-based software engineeringComputing platformCore dumpGroup actionPhysical systemComputing platformLattice (order)Cycle (graph theory)Core dumpMultiplication signReduction of orderMathematicsMessage passingProcess (computing)Formal grammarPlanningOrder (biology)Centralizer and normalizerFeedbackDecision theorySet (mathematics)Computer animation
20:17
Information securityPatch (Unix)FrequencyCore dumpProcess (computing)Latent heatProcess (computing)Core dumpCentralizer and normalizerInformation securityPoint (geometry)VotingPrice indexView (database)Sound effectOpen setLogicPatch (Unix)Lattice (order)Group actionMultiplication signSign (mathematics)Computer animation
22:15
Computer networkDecision theoryDifferent (Kate Ryan album)Type theoryData conversionGroup actionService (economics)Multiplication signRight angleExistenceComputer animation
22:57
TelecommunicationPlastikkarteDatabase normalizationComputer networkTask (computing)Web pageCore dumpKolmogorov complexityLatent heatCodeNormal (geometry)FeedbackCore dumpGroup actionData conversionTrailMultiplication signScheduling (computing)Point (geometry)Noise (electronics)PlanningStrategy gameChaos (cosmogony)1 (number)Dependent and independent variablesCASE <Informatik>SoftwareMathematicsExtreme programmingHorizonFeedbackProcess (computing)Hash functionComputer networkFormal grammarTask (computing)Water vaporDecision theoryChannel capacityFunctional (mathematics)Order (biology)Disk read-and-write headData structureSet (mathematics)Procedural programmingRight angleLatent heatStability theoryTelecommunicationMereologyPlastikkarteGoodness of fitLevel (video gaming)AlgorithmData miningWeb pageImplementationComputer animation
27:18
Latent heatCodeNormal (geometry)FeedbackEwe languageProcess (computing)MereologyPlanningCore dumpVideo gameNoise (electronics)Web pageSoftwareExpected valueIntegrated development environmentArrow of timeProjective planeRight angleComputer animation
28:44
Vector potentialCentralizer and normalizerPoint (geometry)Group actionReal numberStreaming mediaVulnerability (computing)Cycle (graph theory)BitIdeal (ethics)PlanningControl flowMultiplication signProcess (computing)Dependent and independent variablesData conversionDirection (geometry)Computer animation
Transcript: English(auto-generated)
00:00
Anyway, we've got another talk coming up. This is Justin Ehrenhofer here. He represents DV Chain and he'll talk with you about that. He's going to be talking about the woes of Monero. That's right, it's not all sunshine and rainbows here in Monero land. We're going to 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
00:24
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 yes, today 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
00:43
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 is in the Monero community. So as an introduction, my name is Justin Ehrenhofer. I work for DV
01:02
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 in Monero, I do compliance with them so I can walk you through our onboarding process. I also organize the Monero community work group. So that's what's most relevant to
01:20
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 take, you know, they appreciate doing that more
01:41
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
02:05
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,
02:20
sometimes two days before the actual upgrade is scheduled and needing 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
02:41
that to change but that has been a significant grievance in the past. And the idea of having updates in my opinion isn't the problem. It isn't the 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.
03:02
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 updates as smooth as possible, answering all the support questions. But ultimately it's not enough
03:24
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
03:46
our update cycle. So this is what Monero supposedly does for our update cycle and this was published actually from the 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
04:02
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 the core
04:22
team members are often, you know, have varying levels of activity and many of them are active 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 all attend and all vote on things. It hasn't really worked out that way.
04:41
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 a really hyped type, you know, completely overhaul 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
05:03
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
05:21
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 were a large number of ASICs on the Monero network and they indicated that they would
05:43
like to prevent this from being the case. So it was move 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 Monero Mu, who is a very active contributor, just posted in the dev
06:01
chat saying, hey, by the way, the actual update is this day. And everyone was 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
06:25
ODAT 14 software released on February 25th. But this ODAT 14 software did not include any of the changes that had been built up over the past six months, all the development that had been done over the past six months. It merely had very limited consensus
06:42
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
07:03
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 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
07:21
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
07:41
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.
08:01
So yeah, I'm going to 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 and know where money is coming from, since Monero is private, they have to give an identifier to the sender in the transaction so they know who's sending them money. There's three main ways to do
08:25
this. There's long payment IDs, there's short payment IDs, which are the 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
08:45
in the next slide why. I'm just covering the timeline here. Let's move past them, and let's 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. In January, I scheduled a specific payment ID meeting to talk about this. And in June 2019, DeBruyn, who's a main
09:06
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
09:21
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
09:41
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't 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
10:04
was on the same page there. That's fine. The benefit of sub-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
10:24
deprecation was just making the feature off by default and putting it in an 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
10:42
of TX Extra, if 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
11:00
sake of just hoping people switch over in the meantime? Or is this something that would be permanent and we're going to 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 going to 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
11:22
the Monero Ruyo 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,
11:40
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 want to 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
12:01
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 going to be debated for a very long time. I have confidence that perhaps second to Bitcoin, Monero has some of the longest
12:21
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
12:41
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, but those are very, very minor, and they're very rare, typically. And, of course, if we need to step back and say,
13:01
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
13:21
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 address everything on the core team, right? They're a volunteer organization, but they have these roles, and ultimately they need to decide or delegate how tasks
13:43
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 at 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
14:05
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
14:20
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.
14:41
We've 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
15:04
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, you know, life happens and things, and we need to have some flexibility,
15:21
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 poll requests where people will comment on their opinion on certain things that either
15:40
are in the process of being merged or are 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
16:03
it's going to be developed and that doesn't mean it's going to 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 so in my opinion, when you have such a chaotic, hands-off decision-making process where you're making decisions all
16:26
over the place on, you know, 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 know, you never know what to expect is more
16:41
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.
17:01
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, right? So with Zcash, 13 months before they plan to start the initial ideation process
17:24
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
17:44
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
18:03
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
18:21
a list of some things certain individuals are interested in, like I can tell you what I think is interesting. I'm sure Sarang Noether can tell you what he thinks is interesting. I'm sure that someone from Monero Moo 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
18:42
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
19:04
interact with more members of the ecosystem. It's not going to be a few close friends that are passing messages in 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 engaging with a small group. So by making more formal processes, Monero can provide
19:24
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 or what you should do. And we can communicate these changes in advance to people.
19:43
We can say, hey, this is what we came up with the meeting. 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
20:02
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
20:21
here because there are some people that are looking at this and thinking, I want to go too far. I want to be clear. I'm not trying to make Monero centralized. We determine what goes in and lose all the benefits. So what I do not propose is open voting for specific proposals because it's not a reliable indicator. You need to make
20:44
opportunity for people to come and express their logical point 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
21:01
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 every three months or whatever, or we need to go through an outrageous process all the time. I'm
21:21
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
21:42
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
22:02
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
22:23
know you're not able to read all those bubbles on there, but, like, 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 are very few other services. It was a really, really small group. And
22:43
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
23:01
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 past that noise. And there's no good way, like I mentioned, to keep track of thousands of conversations. I feel like
23:22
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
23:41
years in advance and your name needs to be Justin or whatever else. 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
24:00
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 Monero community. Smart
24:21
communication really is key in order to make the ecosystem function and make things happen. So I've listed some specific baby steps that I think would be a good stepping stone towards getting, like to testing the waters a little bit. So first, I would like us to actually commit to code freezes one month before the
24:40
releases. This is something that Monero has said it would do for the past two or three years and it's maybe happened 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
25:01
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. Monero core team member and large, you know, important community stakeholders sit down and
25:21
just write down where they see Monero in six months and two years and let's 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
25:42
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
26:02
reliant on the core team on anymore. Similarly, we need to make timelines for the major features. If we're looking to, you know, implement lightning network with Monero, we should say this is something that's in our two-year horizon or whatever else that might be the case, just speaking openly about those issues with timelines I think is really
26:20
important. And then having formal submission 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 Isthmus had his talk at the Con Franco where people are sometimes using weird fees, well then maybe we should actually organize a
26:41
discussion where the core team is involved, 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, we can always set and adhere to reasonable deadlines and ideally only change them
27:03
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 stability are predictable updates and I don't think we're really there yet, right? So in summary, right,
27:21
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, MRL does the science in the corner but like ultimately we're making software that people use and so we need
27:41
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
28:00
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
28:22
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
28:41
are realistic processes forward. And on that note I'd like to thank you for listening to my talk about Monroe's release cycle and I'd like to open it up for questions. I have about two minutes. Thank you. All right. Yes, Sonia. Yeah, so Sonia's
29:18
question to the stream is, is there
29:20
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 formalizing, 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
29:42
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
30:01
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
31:00
the question was on the vulnerability
31:02
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 Monero 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
31:22
an emergency upgrade if we feel that's a proper action. That's 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 of this conference. Diego, do you have anything else that you would
31:41
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.