About the post-injection LB controversy

Research and Development
1

I will try to bring some new perspective, from a core developer who created his own team because he was not happy with the past status quo. I write in my name only, other core devs will of course disagree with parts or totality of what is there.

I assume people are here in good faith, but that some are sorely misguided about how things work. I will pick some quotes to show that there are real misconceptions held by real people. But keep in mind that if I quote something, it is because I have seen the underlying misconception time and time again, not because I care about the particular person having written that particular quote at that particular time.

Summary for the people who don’t have a lot of time to dedicate to this

We have limited people. We know that things (eg, the governance process) are not perfect. But making things better costs people’s time!

As a result, making the governance process better either requires delaying other things that people are working on, or bringing new people to work on all of this. Bringing new people is hard and requires much more than money (most notably, a lot of time to onboard them). On top of this, most people usually prefer talking about things than actually doing things, even when they are paid.

So, if you bring something up after an injection, it better be an extreme emergency, like a critical bug or something.
My first thought when I see a huge amount of posts about a protocol amendment is not “Oh, I guess people just discovered a thing that has been on Tezos Agora for 5 months.”, it’s “Oh shit, was there a critical bug??”.

–

Now, to the main content, for the people who want to actually take the time to understand more about where I am coming from. :slight_smile:

0. About Controversies

And at this point we have 83+ Agora Posts, reddit / twitter chatter, and alternative proposals being injected. LB is a controversial feature - regardless of how little or much the community made that known.

Controversies should be perceived as suspicious by default. Something being controversial at some point in time does not mean that it deserves attention. You have the entirety of political Twitter as an example of this.

Something being controversial only means that it produced a lot of reactions. Polemics is an entire field dedicated to creating controversies with no substance, and to bring them salience solely on the merits of their controversial qualities.
A typical example from polemics is the Gish Gallop: a quick succession of low-effort questions that takes time to answer, after the which the asker quickly moves on to other questions. This is bound to provoke a lot of reactions, as there will always be at least one of the people in the audience who will have a partial opinion about one of these questions.

If people succumb to those dynamics and start to participate only when there is a controversy, then we will reward, foster and finally end up with the kind of insane and inflammatory environments that we see everyday on social media.

Instead, here is what I would suggest:

  1. Let’s say someone has an actual concrete and serious problem with the current proposal, as in, a deal breaker. They should now open a separate thread about that specific concrete and serious problem known, and then, I will personally address it.
  2. Let’s say someone has an actual concrete problem with the current proposal, but not a serious or urgent one. Then they should open a thread about it, and we can work out a solution, that could possibly be addressed by a change in the next proposal for instance.
  3. Finally, let’s say some people actually have the interest, time and energy to dedicate to more abstract problems, like making the governance process better. This is important, but not related to the current proposal. In that case, if they are willing to commit time to it, I invite them to write a Tezos Agora post with the ideas they have. Then, I will personally make sure:
    • That they are heard and replied to.
    • That if they have an actually good idea, and the time and energy to dedicate to it, I will do whatever is in my power to help them develop it. Whether this is giving them technical help, introducing them to the right people, or walking them through the (now simple!) Grant Request process.

1. The Governance Process: Technical Stuff

Both of these changes are non-invasive and one line changes.

Sure, costs, more and takes more time. But that seems like a small price to pay for this kind of optionality and a much more subtle way to propose something so new.

As explained by @arthurb, the protocol vote is a ratification step (basically making sure that a proposal is not rogue), more than a “deciding among X competing options” step. The reason is very simple. Maintaining competing proposals is hard! People might have in mind “one-line changes”, but consider the following:

  • Most amendments are not one-line changes, so no other part of the governance process is built around supporting this special case.
  • Even if you consider only 10 small independent one-line changes, you get 2^10 combinations of changes, which is ~1000 different proposals. Example of independent one-line changes: changing baker roll size, the fee rate of the LB contract, the pair traded on the LB contract, the code of the LB contract, the size of Tezos blocks. 10 is a very small number, very easy to reach.
  • You need to support the release, docker images, builds, distribution etc. of all the different proposals.
  • You need to rebase all of your changes on all the different proposals.
  • You need to motivate people to contribute to your testnets. Which is hard to do even with a single proposal.

But, yes. We could build a custom separate amendment process for constant changes to sidestep those issues, so that bakers could vote on this kind of stuff outside of regular governance cycles. But this requires a lot of work from people who have specialized knowledge, who are currently already working on other things! If someone wants to put in the time to build a team around this, I would of course be very interested in helping them. Having a lighter amendment process for lighter changes has been part of the things that I would like to see on Tezos for a while, but I personally haven’t had the time to do so.

But in the meanwhile, the governance process still does not work that way, and as core developers, we expect consensus (even on smaller things for now) long before the injection. If we did not expect as such, it would be quite impossible for us to do actual development work.

2. The Governance Process: Social Stuff

I have obviously missed this Liquidity Baking: A Decentralized XTZ / TZBTC Pair - Part 1 2 . This was presented a good few months ago but discussion about it doesn’t seem to have taken off.

I do believe the time for that discussion was on the Agora thread / RFCs. [But …]

I have quickly explained why it is hard to technically improve the Governance Process. Now, I will dig into more spicy matters.

The process by which discussions take off or don’t is how bakers, and all the other actors in the ecosystem, contribute to the protocol. All too often, from everyone, be it bakers, tool builders, end users, or whatevers, I hear something along the line of either “Why do we still not have X?” or “Why do we have Y?” (in a complaining way). Quite often, the most honest answer that I could give is something along the line of: because I am one of only ones (sometimes the only one) who talk to the core devs about this. Because of this, they don’t feel like it matters enough, and they have 10 other burning priorities at a given time, as we can’t find enough people willing to build new core dev teams as it is extremely hard and not rewarding.

Liquidity Baking is one of the better cases! There was a thread on Tezos Agora, 5 months before, there were posts explaining what it was, the progress, and so on and so forth. It is one of the few things that targets end-users, that makes Tezos much more enticing, and that got merged at the protocol level. It was even started by someone outside Nomadic!

From my point of view, this is an epic win, and a strong mark of progress of the Governance Process and Development Process over the past.

So, I agree that there is a whole lot more that core teams could do to make things more open and to include people to the discussions. But publicly attacking one of the better things, after the injection, after it has been in the open, without asking the actual core devs about it in private first, is a huge step back and does not help this undertaking in any way.

3. The Governance Process: Neutrality Bias

I do continue to be concerned that we are picking winners and losers at the protocol level, and that these decisions are made opaquely. I have not yet heard rationale or a compelling argument for why this is.

“Liquidity Baking seems like a fantastic idea but the way it’s proposed to be implemented sounds like a top down business decision from someone high up at the Tezos foundation.”

The issue I see has less to do with what type of asset is supported but that there is a proposal by what ought to be a purely technical team to inject some type of “economic policy/stimulus” (beyond simple protocol inflation for network security). It amounts to a commercial decision by a “state actor”, instead of the “private sector”.

To everyone feeling like this, I would recommend taking a lot of quite some distance on the situation! You might be completely wrong, on two separate dimensions, at the same time!

First thing is, this is not an adversarial project. “The protocol level” is not “top down”, and is not “a state actor”. That’s also not the case for TF, Arthur, tool builders and bakers. I could count on the fingers of one hand the number of people that I worked with who did not have the best interests of Tezos at heart and who tried to impose what they wanted because of their interests.
Trying to frame it that way is fundamentally baker-centered. Consider the following:

  • From the core devs point of view: the bakers could just block everything they do and boycott them. TF could just withdraw all funds. Tool builders could just move to other blockchains.
  • From TF’s point of view: devs could just move to another blockchain with money and bakers could just liquidate their assets.
  • From the tool builders point of view: TF could just withdraw all funds, and core devs + bakers could just vote in amendments that are incompatible with their tools.

Yes, any critical group could blackmail/threaten/veto the others. But this does not mean they are necessarily on top of the others.
At some point, one has to realize that we are all in this together. Of course, if someone is a bad actor, we need to kick them out. But by default, one should just assume good faith and trigger the fire alarm only when there is actual smoke.

Second thing is, if you still want to frame it as a conflict between groups, with different groups trying to impose on each other, then keep in mind that you are likely in the wrong group! Core devs have very little direct feedback from other actors, despite constantly being open to it and having nearly everything they do out in the open on Gitlab.
Even with that little feedback, in practice, they still try to integrate everyone points of view, and do so with the double pressure of needing to move quickly and keeping everything safe. I know more than one core dev who burnt out over taking this pressure seriously. There is literally no other group in the ecosystem that takes things as personally.
Core devs know all the nitty gritty of the protocol, the actual low-level technical boring constraints, and have to actually do the stuff. You would be hard pressed to do more “bottom up” than “this came from core devs”.

Finally, my point is not that core devs are perfect little angels. I literally left Nomadic and built my own team, I obviously have my reasons to do so. But despite having done so, I am still working together with them to improve on what exists.
So, my point is more that trying to improve on what currently exists more looks like what I am doing than not participating on Tezos Agora and then participating in a controversy.

4. Conclusion

To conclude, my message to people that were on the Announcing Granada thread would be:

  • If you got baited by the controversy on LB to this topic, move on with your day, there is likely nothing interesting for you there. As is the case with most controversies.
  • If you have a concrete and urgent problem with the LB proposal, make a new thread, short and to the point, dedicated to that problem. I’ll do what I can to make sure it is replied to and taken care of if needed.
  • If you want to help building a better governance process, make a new thread with your ideas and reach out to me! I also want to improve the governance process, and will help you if your ideas are good. If they are not, I will make sure to explain why that is the case.
  • Regardless of who you are, please participate more on Tezos Agora! For instance, if you build tools or DApps, you might be interested in Views TZIP :slight_smile:

Cheers,
Gabriel

23 Likes
2

But publicly attacking one of the better things, after the injection, after it has been in the open, without asking the actual core devs about it in private first, is a huge step back and does not help this undertaking in any way.

  1. I think it is quite a big problem if core developers view discussion or critique as an “attack”.
  2. You can’t blame people for not discussing things in the previous threads. Most people, even bakers, can’t read all of the Tezos forums full time. I’d say making sure there’s enough engagement is the responsibility of the proposal authors.
  3. For example, I brought up that it’s not ideal to use a centralized KYC asset in one of the LB threads, but of course there was no reaction. What should those who read the thread later take away from that? It creates the impression that inconvenient concerns are simply ignored, and makes people much less likely to care about the proposal, or to voice their concerns.
8 Likes
3

I have not had time to read and fully digest this posts content - and there are surely points i agree and disagree with. I will try to add some thoughts in the near future.

In the meantime - I would like to extend my compliments to @galfour for facilitating respectful and straightforward discourse. Your post shows great leadership and thoughtfulness during a time where there is disagreement in the community. :clap:

12 Likes
4
  1. I think it is quite a big problem if core developers view discussion or critique as an “attack”.

As explained, there is a strict difference between discussion/criticism, and Gish Gallops. The former lets us improve what we build and coordinate on better alternatives, while the latter mostly wears down everyone.

  1. You can’t blame people for not discussing things in the previous threads. Most people, even bakers, can’t read all of the Tezos forums full time. I’d say making sure there’s enough engagement is the responsibility of the proposal authors.

Sure I can, and this is what I am doing, among other things! It takes incomparably way more time to actually coordinate and develop things, than to just keep up-to-date with what has been neatly presented in well explained Tezos Agora posts. So doing the latter is like a bare minimum.

As core devs, we had to spend a lot of time on coordinating and propagating information between us. It was hard to do, it took us time, but we got there.

Now, bakers who care about amendments need to go through this too. Fortunately, to help people with this (including bakers), Tezos Agora was created, and core devs are now posting nice things there. At some point, people just need to put in the boring work of keeping in touch with the latest things, forming an opinion on what matters and what does not by themselves and spending time on what they care about.

As offered before, if someone wants to put in the time to build a project that addresses this and makes coordination easier, I will gladly help them. But even then, in the end, even with the best tools and processes, people will still have to put in some time to do boring work.

  1. For example, I brought up that it’s not ideal to use a centralized KYC asset in one of the LB threads, but of course there was no reaction. What should those who read the thread later take away from that? It creates the impression that inconvenient concerns are simply ignored, and makes people much less likely to care about the proposal, or to voice their concerns.

I agree we could have been more forthcoming, but back then, no decentralized alternative actually existed. You yourself did not offer any alternative, and did not even ask any question. So this was not really an actionable item. You knew so and admitted as much when writing that “Being able to launch this sooner might mean it’s still worth it to use tzbtc for now”.

Your part about inconvenient concerns is over the top. All the other questions on the thread, asking about technical details, were addressed there. If your concern was actually important, I would expect more than just a disclaimer that using a centralized asset is not ideal, which we already knew and factored in. And in that case, if it actually mattered, I would indeed expect that we would have caught it in time and changed our choice accordingly.

8 Likes
5

+1 on the civilized discourse! Thanks Gabriel for highlighting your thoughts. It improves the level of interaction tremendously.

Many of your points are valid. I suppose, what my main issue boils down to is the fact that LB was not given as an option, i.e. 2 Proposals, one with LB one without LB. I remember in the past such options were given and Keefer’s suggestion of how to disactivate it from t=0, doesnt seem very difficult - as such I’m still slightly skeptical about the “ressource” argument.

Do you share my belief that two proposals would have created much less friction (while potentially getting the same outcome)?

2 Likes
6

I think the point he’s trying to make is that at this point this should have been discussed and figured out already. Tezos’ governance process is not meant to turn into a twitter poll at proposal time.

Nothing in Granada is a surprise. Multiple proposals at injection time should be saved for last-minute bugs or things that clearly would break an ecosystem. For any “I don’t like this” type opinions, bring it up in the 6 months of discourse that goes on before the release.

People have misconceptions about on-chain governance in general. Injection is not a poll, its more akin to a final vote on the US Senate Floor, and at that time the discussions around the bill have been had for months, the votes have been whipped, and its time to “inject” for voting. (Simplifying this obviously)

IMO participating in governance is a job that you do at all times, not just 1 day after injection. The way I see it, the legends at Nomades have been participating in governance at all times in good faith, on top of core dev work. More people should attempt to participate as well.

10 Likes
7

point taken. At the same time, I remember that in the past, options were given. So what has changed? In any case, at least this discussion will remind both sides (injectors and voters) to be mindful of the other side. If that is the outcome of this - this was a good thing.

1 Like
8

I don’t. It seems there is a general sentiment building that the solution is to inject multiple opinionated proposals and then wait and choose at proposal time. This will not scale, and “choices” should be saved for critical bugs and broken things. Which has happened in the past w/ Edo2.

Furthermore, the pessimist in me thinks there is a real possibility of the next proposal phase getting DDoS’d to shit because people want to make names for themselves, rather than collaborate with the core devs. Even if not, this is something new that core devs have to think about now, rather than focusing on extremely important protocol work. So that’s another L.

Crypto moves extremely fast and there is a high possibility of this Agora going back to a ghost town after the LB drama fades and the newest p*nzi comes out. Over the next 3 months, we’ll see if I’m proven wrong. It’s a long road and I’m just not sure we took a step forward. Still, I don’t think it was a step back either. Any gains have simply been offset imo.

But hopefully I’m wrong, and the governance process starts gaining a ton of participation, people pay their dues by staying up to date on development, and folks start respecting the core devs more. Like, not even a private conversation before sounding the “alarm”? Unreal lol

6 Likes
9

Nice and succinct way to put it.

7 Likes
10

Do you share my belief that two proposals would have created much less friction (while potentially getting the same outcome)?

I don’t! The reason why is that people have expressed many different concerns on that other thread, among which:

  • The dilution of baker rewards. So people might have wanted more options on the quantity baked. For instance, 3 different options: High, Mid or Low.
  • The traded pair. So people might have wanted more options. For instance, with two additional pairs, we would now already have 10 options : 3 different LB amounts * 3 pairs + no LB at all.

Many other concerns have been brought up that would make this number blow up even further. This suffices to show that voting (let alone on-chain voting!) is not the right mechanism to build such consensus.

The correct solution is instead to first have people both inform themselves and others about what’s going on, then discuss it together, and finally establish a consensus around which people can build stuff together.

If people do not participate in the discussions, then this is broken, as they can not even understand what is going on.
In the Granada thread, a lot of concerns could be answered by simply reading about previous posts and explanations by various people.

–

In general, I believe you (and a lof others, this is not about you personally) have the wrong reading on the situation.

What happened is not that bakers have been surprised by a stealth change to Tezos.
What happened is that some people read the content of the proposal long after the development, design and discussion of LB, literally after the injection, and felt bad when they realized they missed topics that they could have given their opinions on (as opposed to more technical stuff).

It is not necessarily that they disagree with the actual choices that were made, or would prefer an actual alternative. I expected the biggest drive is it feels bad to feel left out.

Unfortunately, it is 100% not the job of core teams to predict what each baker would care about, and then go after them. It is certainly part of core teams’ job to make their work open and clear, so that stakers (including bakers, among others) can keep themselves informed and can have informed opinions. But in the end, stakers actually need to do the work of keeping themselves informed and convey their concerns, in a timely manner.

–

Regardless, I am very happy that people are trying their shot at building proposals!
Now, I hope they stay motivated long enough to build an actual team to work on the protocol, beyond a short outburst. In which case, I expect that both Nomadic and Marigold will gladly welcome them :slight_smile:

9 Likes
11

Ok - I am tempted to go with your POV, especially wrt bakers having the responsibility to stay up to date and discuss BEFORE injection. I cannot comment on how much effort was made to involve bakers at the time. I didn’t see it but happy to mea culpa that.

1 Like
12

Tezos’ governance process is not meant to turn into a twitter poll at proposal time.

It turned into a Twitter poll because only one proposal was injected.

I don’t believe it would have turned into a twitter poll if at least one more proposal, which would have separated the technical upgrades from the economic upgrades, was presented as an option. Technical upgrades and economic upgrades are NOT the same, and while a proposal with only technical upgrades does not need a decoy proposal, I would argue that having options to maintain the status quo would be healthy when presenting economic upgrades.

Case in point: Currently, disregarding the 18 spam injections, there is a competition between Granada with LB and without, with LB leading by a healthy margin. If those two proposals would have been injected together, the result would likely be the same, but many bakers would not feel disenfranchised and the core concept of the “Digital Commonwealth” would not have been put in question. Not having choices also reduces the public appeal of Tezos and if the discussions are exclusively to happen before injection, then we are not much different to other chains and bakers are rubber stamping. People still discuss during elections/law presentations irl, too – and people can change their minds.

I also understand that this proposal has a limited time period for the economic change. This was a smart move that almost negates the need for a protocol injection without this change. But only almost - for the reasons outlined above.

I want to reiterate I am not in principle against LB - it is a very innovative way to solve the liquidity issue that POS coins have and which may deter big players from entering.

3 Likes
13

You have already mentioned that the proposal contains both a natural sunset and an escape hatch if bakers disliked the result of it.
This is enough to show you that a proposal without LB is beside the point: this option is already part of the current proposal.

It turned into a twitter poll simply because people got hyped into controversy. People can always complain. Even with two different proposals (it looks like you still don’t understand the costs of building and maintaining an infrastructure around this), people could have complained! Why can’t bakers vote on the pair? Why can’t bakers vote on the inflation rate? Why is it only yes/no?

Fundamentally, this ask for one proposal with and without LB is just people coming at the end of the entire process and asking to make a late and uninformed choice. People (including bakers, or state citizens in the wider world) don’t become magically informed about what is being built and voted on solely because of “self-interest” or “alignement”. Being informed is a long-term process that takes time.

Asking for the procedure to be a simple choice between A and B leaves the protocol 100% vulnerable to PR’s manipulation of the bakers. Which is what meaningless controversies show.

There are choices! Literally, everything was in the open for 5 months. People just didn’t put in the time to understand what was happening and give constructive criticism. It was their choice to not participate.

On chain, bakers can veto, and even make their own proposals! You are witnessing this.
The question is, when is it actually legitimate to do so?

If some bakers were ignored, censored, excluded from discussions or if the work was closed source, with no communication whatsoever on what was going on, I would completely understand.
But well, after 5 months with no participation whatsoever in the open discussions, and after the first injection. An alternative proposal is a 100% adversarial move, banking on controversy.

Tezos having public appeal is good, but it is not a thing you should blindly optimize for at the cost of everything else.

The need to keep yourself informed and to participate on the discussions on the public forums might drive away people who only want a choice on a silver platter at the moment of the injection. This is good! Not everyone need to participate in all the discussions, but the people who are ready to create a controversy should have at the very least participated on the discussions, or made any effort to contact any of the other actors (any one in the core dev team, in the TF or even Arthur) if they did not know where discussions happen.

For instance, in the same way, bakers need to maintain a some infrastructure to keep the protocol safe. In the past, this might have reduced the “public appeal of Tezos”. As in, this might have driven away people who only want to click on a single button that reads “BAKE”. But this is a good thing! You want people who are involved. You don’t want baking to only be about clicking on a “BAKE”-button and click on “A” or “B” after reading a short blog post at injection time.

More generally, from a core dev perspective, this completely breaks trust. Our job is already hard enough, and we already have trouble recruiting. If on top of this we have to offer a white glove service to people who don’t take the time to participate to critical discussions, but still feel entitled to create a controversy, we might as well already stop, I can tell you it’s not worth it for anyone with our skillset, at any price point.

By white glove service, I am referring to stuff like offering the feeling of a meaningful binary choice in the protocol after all the hard discussions and problems are already resolved. Most have already admitted that adding a proposal without LB or with a different pair wouldn’t have changed anything, as it is was indeed the best choice.

And you have to realize that at the same time I am writing this, core devs are taking time away from burning priorities to actually review these alternative proposals done at the last minute. Even though a non-trivial amount development, review and testing time were already invested in the current proposal so that bakers could opt out.

I guess it is just really hard to convey how meaningless and like a waste of time and attention this all feels.

3 Likes
14

While I agree with this, I also think that our community, even if everyone properly informs themself and follows the progress, will likely not always come to a consensus beforehand, there is such a thing as informed disagreement (not sure we have much of this in the current debate), so it will always make sense to offer multiple proposals, also at some point, if the people who participate in gov is not the same set as people who read tzip’s, we got to be pragmatic instead of shaming people for not reading what we think they are supposed to read, or start communicating more effectively.

Yes, we should try to build consensus beforehand, votes are here for when that’s not possible or we failed to do so, if people don’t inform themselves yes you can call them out for it but more productively figure out why that happens too. To cling to some utopian vision of how the process should work is pointless, especially since this is a community where people come and go all the time and one does not need to pass a tezos-governance exam to hold Tez, this will never be perfect, and as every engineer knows people will always find ways to use your thing in the “wrong” way.

I hope this doesn’t sound too harsh, I do very much appreciate this thread and the well-thought-out comments by @galfour and others.

4 Likes
15

You pointed out how hard it is to maintain multiple proposals with different features and code, in the current proposal, would it be really have been that much overhead to include a feature switch, something like “liquidity_baking_enabled=true” and propose one with that, and one without? yes, it would be some dead code until the next update, but I am assuming the effect on performance would have been negligible and it removes the need to maintain multiple codebases, good tradeoff?

1 Like
16

No worries, same here. Thanks for engaging in good faith.

There is such a thing, but as you’ve said, this is not what is happening.

When we get to actual informed disagreement, I would love including the core teams in them, and seeing how we can manage building multiple proposals to reflect that informed disagreement. It is the kind of stuff that we already started to work on, but it is complicated.

This is wrong and does not follow from what you said. Informed disagreements being merely possible don’t mean we should always invest resources in covering for them.

We have limited resources, investing resources to cover for a possibility that is far from being realized is nothing but a waste, and delays actual important things.

There were TZIPs, threads, and blog posts. This was not developed in stealth in a weird corner of Tezos.

The pragmatic is what is already done: devs (core devs and tool devs) make a best effort to integrate everyone’s interests, to be as open as possible, and then are the ones left to do the actual work of developing the thing.

If someone in good faith is unhappy, or has some questions about the thing, they can exchange with core devs.

What is happening here is not a failure of the process where bakers interested were not accounted for or whatever. It is just a controversy being steered using all the typical tools from polemics and rhetorics. (Us vs them, making it about power, asking 10 questions and discarding all the answers, stating that stuff is symbolic when it is shown to be practically meaningless.)

In the current process, bakers do not spend too much time informing themselves about everything because they trust core devs. They trust core devs because core devs have improved the network and never abused that trust.

So no, the consensus was built, the processed work well. Again, what happened is not a failure of the process. It is just a controversy steered after the actual process, literally after the injection.

This is how it has worked since the beginning. I am not sure why you describe it as utopian.

When someone disagrees with, or is confused about, a thing, they inform themselves first and ask around. This happened a tremendous amount of times in the past, this is the normal course of action.

This is not specific to Tezos, this is common courtesy when you are working with people and they never deceived your trust. You don’t just create a public controversy whenever you dislike something. If you get the habit of doing this, you end up with massive bureaucracies where everyone is too afraid to make a move.

5 Likes
17

Yes. And I have explained this multiple times, including in the Original Post of this thread.

But, and I will repeat it one more time: this does not matter! There is already an escape hatch in the current proposal, that bakers can use to stop LB whenever they want. It was developed with

2 Likes
18

In Florence, there was no clear consensus on baking accounts, as seen by the fact that it was developed, injected, and rejected by bakers, so no, I would not say that’s how it worked before, how can you tell you had consensus before the injection, if not by the result of the on-chain process? I am worried that what is advocated for here (in good faith and for good reasons) will result in some kind of ethereum style core-dev “consensus making” hidden underneath on-chain governance to make it look decentralized.

1 Like
19

Exactly, there was no clear consensus on BA before injection because people took part in the governance process and debates that went on before, and the matter clearly was still a hot topic.

3 Likes
20

Alright, I understand the nuance now…

1 Like