Update council_member_election_guidelines

[Anynomouss]

Approved by: Anynomous Mojitoo Mac Cecky

Would appreciated extra approvals/reviews by: David T MCM-Mike

[davidtavarez]

It does not seem to me that the entire contents of this file should be discarded. I consider that there are some very valid points; I have marked them with a LGTM. Having said that... I am strongly opposed to any "democratic" direction. It would be a disaster especially at this time, and for a long period of time.

Right now, as I write this:

• The Community is not that big, and there are no efforts to grow it.
• The Community is shrinking day by day and it looks like it will continue to do so.
• Grin's economics is still not attractive.
• Even during a bull market, Grin has not increased its Community.
• Grin inflation is still too high, there is no need to pretend that this does not affect the popular interest, even if one support tail emission.
• The default Toxicity of Crypto scene is still too high, Grin is not inmune to that.

For that and many other reasons, my opinion is that the right approach should be the "conservative" one. No one should succumb to the herd of fools, if you do you will end up with under qualified and overly stubborn people who do nothing but write hate, running Grin, a project that barely breathes.

Grin doesn't need to rethink over and over again how to manage a group of 10 people, let alone complicate things, what Grin needs to focus on is building. If the current 10 people can't get along and work together to lift Grin, then there is not enough bourocracy that can save Grin.

My suggestion is to keep things simple, focus on constructing, reject drama and move on.

[Anynomouss]

@mojitoo @future3OOO @Anynomouss @cekickafa are ok with the above document 👍 @davidtavarez has some reservertions as he stated above, count it for now as a 👎 Your opinion @MCM-Mike

To me the above document is not a big step away from what were in practice already doing which can be summarized as, swapping appointed members by elected members but only those the existing members endorse/approve of based on their track record. While we listen to all ideas and feedback, arguments counts, not who shouts hardest or the multitude of accounts.

For me the above document is just formalizes the way we have been dealing with changes in CC members and decisions in general. Yes, we should be conservative and protective of the funds to some extends as David argues while still allowing fresh people and ideas from the community. IMO the document is simple enough and keeps this balance, but I would like to have your opinion on this as well, especially the parts that deal with security of the wallet and the selection criteria for CC candidates in an election.

[MCM-Mike]

General feedback:

Based on input from the community, it was decided to move towards a fully elected council.

Based on what happened in the past, we also got elected by the community as we had to undergo similar process:

• https://forum.grin.mw/t/call-for-grin-community-candidates-for-additional-fund-granting-control/8521
  • e.g. my public statement: https://forum.grin.mw/t/call-for-grin-community-candidates-michael-aka-mcm-mike-from-grinnode-live/8527

More important feedback:

• Managing the CC Multisig wallet

a maximum of two keys can be shared by with new council members by their predecessors before generating a new Multisig if deemed safe by the CC

In a Bitcoin multisig setup, someone with access to the public keys can generate a transaction from the multisig address. After creating the transaction, they'll need to share it with the private key holders to collect the necessary signatures. Only after gathering the required signatures can the transaction be considered valid and be broadcasted to the Bitcoin network. Without these signatures, the transaction cannot be processed.

This could be applicable to new members of the CC?

Therefore new members could create and draft transactions and the CC can sign them. This would reduce the workload of creating a new set of keys to incorporate new members of the CC.

additional information: Currently we hold old keys from 'Arad' which are known to some of the CC members. If three or more CC members are leaving I would strongly suggest to generate new keys for security.

[Anynomouss]

@MCM-Mike You can directly edit in the document. The documents states we can swap up to two keys from old CC members with new members before having to regenerate a new Multisig wallet if we deem it safe. I agree this is more or less the maxim um we can safely do. If CC member feel there might a risk to the funds in any way, they can opt to generate a a completely new wallet earlier. But only if needed. Not only does it consume significant time from CC members but also for the backup key holder in the OC, old CC member or other trusted member.

What you describe of letting old CC members sign is what I envision for the representative system. It is another way to more easily let community members be part of the CC governance without directly needing to create a new wallet. In general, do you think the security measure and conditions on new CC members are sufficient to safe guard the funds? If you do, think it is sufficient in terms of security we can merge and get the election going.

[MCM-Mike]

In general, do you think the security measure and conditions on new CC members are sufficient to safe guard the funds?

currently I think its in a safe position and CC can handle the funds and keep it secure. We do no need to move to a new multi-sig for now.

We can proceed, I just wanted to add an option that new CC members can also create transactions while having only access to the public keys.

[Anynomouss]

Incorporated the feedback from MCM-Mike to allow new CC members to get access to the public-key for the CC Bitcoin wallet, so they can draft transactions, but no need to replace the wallet each time.