Attacks on Grin’s governance. Governance is a massive security risk for any blockchain project. Example of possible attacks:
- Sibyl, bribing, or collusion attacks on any kind of voting or signalling by community.
- Attempts to gain control of mu-sig wallet.
- Subversion of decision making process in order to gain unduly influence for personal gain, for example through changing emission, pow, and so forth.
it might be important to understand why there’s such limited participation, and whether this is something we can improve upon as a result of any governance changes that may take place.
To explain my intention a bit better, I listed the lack of participation as something that should be taken as a given, to avoid proposals for some new system that would rely on a large and active community of contributors, as this is unfortunately not realistic today.
It would be great to see proposals that can lead to improved engagement and contributions, perhaps this could be motivated as part of the actual proposal itself.
What makes you say this? I’m one of the largest critics of our current governance structure, and money has only ever been a secondary concern for me
Because to me, “what do we do with the mu-sig?” is the hardest question to answer, and I can see how it can become infected.
Adding to this, there’s been a lot of back and forths about
- “Why didn’t you fund the grin++ audit?”
- “Why are you not funding GUI wallet development?”
- “Why don’t you hire a cryptographer?”
- “Why are you not doing any of the above, while paying yourselves?”
All of the above, relates to money, and the fact that the core team has control of some, which means we need to make (sometimes tough, sometimes easy) spending decisions. If we had no money, there would be no decisions to make, and less contention as a result.
The question “who decides what gets merged in /grin and /grin-wallet” seems to be way less contentious, and has easy solutions if it’s not working as it should: Developers can fork the repos or write their own implementation from scratch.
The question “who decides what Grin’s consensus rules should be?” is more complicated, but still much easier to reason about (at least right now) than Bitcoin - there is a process in which to propose and introduce consensus changes. And given that there’s been some clear design decisions and directives set out very early in the project’s life cycle (like emission, minimalism, scalability), there is definitely some kind of “checklist” for how we can reach agreement amongst ourselves for that.
Furthermore, regardless of the outcome of this thread, there are larger questions that we will need to figure out at some point. Right now there are two Grin implementations. What happens when there’s three, or four, or five? How do we reach agreement amongst implementations about the right rules, when to make changes, and how to do so? The current governance model doesn’t really account for this, there is no governance process between implementations.