I will just comment (Keybase, Telegram) on a few points from my perspective:
Signing transaction:
We as the CC have setup a Bitcoin multi-sig address where each CC member holds on key to it.
More details here: GitHub - grincc/security: Repository for keeping track of the quaterly updates related to Grin Community Fund
If we draft a transaction, one from the council takes on the task and drafts a transaction for us to sign. We then have the responsibility to double-check the transaction and sign them in order for the transaction to get broadcasted.
Each of the CC members has to do their own due diligence on the
- transaction itself
- the amount we sending
- receiving address of receipent
- and double-check the return address.
Therefore I made sure we had the receiving addresses all prior to the draft of a transaction in the past.
I created a private project on (https://github.com/orgs/grincc/projects/1) where we stored all recipient addresses which where double checked and confirmed by the recipient. So we would not send to a wrong address by accident.
As this is not public I made a small screenshot without revealing to much private information from any recipient:
This process made sure we had the correct addresses and we made no mistake.
Also David wrote a small script, which helped us calculate the BTC amount as well as the GRIN amount, which was always helpful in the process.
After drafting the transaction, each CC member had to sign the transaction and following their own process. Signing a multi-sig address, where I had to make sure we not loosing any funds as well as sending the right amount, was not a 3min task.
How each CC members stored his private key is not up for public discussions, but I can elaborate a bit about the possible choices:
- Software wallet on computer (encrypted, password protected)
- Hardware wallets (Trezor, etc )
- Virtual encrypted drives, with a client on it.
- offline signing wallets
- etc
In my case, as I am following the (CCSS) C4 code of ethics, as well as some of their technical procedure, was not a quick task to sign a transaction. Also additional personal technical and organizational processes are in place to sign a multi-sig transaction, which takes time to do and follow it accordingly.
CC Inactivity of members:
It is true , some of us are inactive currently at least for the public eye.
We definitely need to work on this front and need to find solutions on how to be more active and helping the GRIN community.
Possible solutions?
- Replace some GRIN CC members by more active community members
- add one more person to our CC to let the community know about our internal status?
- community input
- ???
Future:
At tomorrows GRIN meeting, let us vote on what possibilities we have and let us publicly discuss these. Agenda: Community Council (CC), 22 November 2022 Ā· Issue #72 Ā· grincc/agenda Ā· GitHub
ā
I am well connected with a lot of GRIN community members as well as some exchanges where we are making progress. There is more I do in the background then I am sharing publicly and I want to keep it that way.
I donāt want to hinder the CC in any means just making a few statements about our structure and processes.
There is a lot more than I can describe here, feel free to ask questions or get involved with us.