If you thought the plan was wrong you should have voiced that opinion at that time in the many discussions on the forum and on KeyBase. There it was decided by the majority to buy so many, way more that there were volunteers even when compensating electricity. So if you want to influence decisions, join the discussions and meetings that lead to these decisions.
1 Like
I came up with the original idea, lead the discussions, joined the meetings. I also did the same when the idea resurfacedā¦ Iām not blaming anyone or anything like that. Iām correcting your factually inaccurate suggestions that they are hard to maintain (you plug them in and point them to the stratum server) or that there was some kind of lack of discussion or participation.
The moral of the story of this entire thread is that people with the keys spending large sums of money need to be accountable to at the very least keep an accurate record of spends. I donāt think key holders are responsible for bad spends (unused asics, MIA grounds keepers, unfinished dev), that is unproductive hindsight conversation and they were decisions made by the entire group. But key holders are being asked to fix their poor accounting and consider better spending practices.
4 Likes
Thank you to those who spent time to read and reply productively, you shared many different opinions and I will try to summarize your suggestions for the next CC meeting or the one after that, I encourage you to join us there to take part in the discussion.
Letās start from the end, the topic most of you replied about is the miners and I probably could have explained it better in the original post.
I mentioned 2 different issues regarding the community miners, transparency and responsibility:
- Transparency:
This issue can be easily resolved if @Cobragrin as our GK will be able to gets access for the relevant information, itās not too complicated, the information is just not transparent at the moment and it requires active action from CC members to make it happen.
Later we can discuss what it should look like or a template structure for āCommunity minersā reports under the GrinCC repo and the GrinCC website.
- Responsibility:
I mentioned this issues under āCC role definitionā because it was never clearly clarified who is responsible for the ongoing maintenance, mainnet/testnet, reports, tech issues and the rest of the list I mentioned above, is it the community? If so, how? because it is impossible without full transparency and clearly definition of the roles.
The decision-making process itself was public, long and many members of the community participated and expressed positive and negative opinions. In the end the decision was passed because of the community support.
And the question āHave we really considered the long term responsibility of running a mining community farmā¦?ā was for us, āweā as the community members.
@Anynomous explained it (CC meeting 2022-12-6) before:
ā¦ I think it is important to clarify that these miners are in fact ācommunity minersā. We bought them as community council, but the decision and responsibility is for the whole Grin community, similar to how this council is also just a representative body for the whole community. As such the council members should cut ourselves some slack and not always take the burden upon ourselves.
4 Likes
Any idea how much was mined? If you know when they were delivered, we could try and figure out what should of been mined and compare it to what is reported as mined. If there is a significant difference, then those who are mining and those who authorised it should explain themselves.
1 Like
I really appreciate the updates you provided, and thank you for sharing them on the Telegram group.
Iām eager to assist in translating the information for Chinese community members, but I have limited English proficiency.
If possible, I kindly request that you consider sharing the updates in both English and Chinese after the meeting. This would greatly benefit the Chinese community members who may have difficulty understanding English.
Thank you for your understanding and assistance.
I want to make you aware that I use a translation tool to communicate, so please let me know if any part of my message is unclear.
TLDR:
1) Feedback on the governance and the need for the CC and community to better check deliverables will be take to heart.
2) Respect our long term developers, but let @davidtavarez first wrap up his deliverables for the previous funding request, before moving to funding the next request.
3) Give biweekly bullet-point update/follow-up on progress
4) Explain to the community the relevance of features like PIDB and Nostr, their benefits for users. When a feature gets enough up-votes, move to a funding request for and a vote for the request. In this way we are certain the community is supportive of the funding request.
I want to post some suggestions here since there has been some criticism on how the CC checks the deliverables of funding requests and one how developers updates their progress on the deliverables of his funding requests.
Let me start with saying that some of the criticisms is deserved, although I think we should keep it general since criticism is on governance and procedures in governance and not specific to @davidtavarez who only happens to be the only full time developer governed by the CC.
he has contributed greatly to the project both as a developer and as a CC member and we should give him some slack and credits for that and not target him. But to get back to the criticism, yes we should be more strict in putting value to deliverables and checking deliverables and perhaps even move to paying per achieved deliverable, although I want to keep that to a separate discussion.
In his recent funding period, @davidtavarez got distracted by all the enthusiasms in the community for implementing Nostr as an alternative to tor. Nostr has many potential benefits. Not only is tor sometimes unreliable and requires bridges to work in some countries, but it also does not serve as a buffer/bulletin board to store transactions when a receiving wallet is not online. Wanting to work on Nosr is therefore understandable and might bring a lot benefit to the community, but it was not in the deliverables of his funding request.
Back to those deliverables. It is true that @davidtavarez got distracted and did not finish the client implementation and API part + documentation. I would therefore propose he works to wrap-up these deliverables to his and the communities satisfaction before applying new funding. Does that mean the work on Nostr goes unaccredited/unpaid? Not at all. I discussed it with @Mokhtar and he proposed we will first discuss which functions the community wants to be implemented and explain there relevance and then let the community up-vote if they want a feature and which to implemented first. I am quite certain that Nostr implementation will be funded at some point in the future, so all work done by @davidtavarez on Nostr will save him time when the funding request for Nostr gets approved. Below I will shortly discuss the two main functions that I think are relevant to be implemented in the near future. We will create separate posts to discuss them with the community and see if they want to support their funding, here I will give a short summary of them.
1. Partial Initial Block Transfer (PIDB).
PIDB is currently on testnet implemented for grin-rust and hopefully is soon stable enough to be brought to main-net. The benefit is that users will be able to download blocks when they first install their wallet and node from multiple peers. Many users experienced having to wait in some cases for a day to fully download the grin blockchain, or having errors when first syncing and needing to restart the whole process. Considering the Grin blockchain is < 3GB this means the current system of initially downloading the blockchain as .zip file from a single peer is slow and unstable. PIDB will allow nodes to sync with multiple peers making initial syncing more robust, decentralized and in the future with some tweaking it might become faster since you can benefit from the upload speed of multiple peers. Of couse we do not only want PIDB working for only a part of the nodes (the rust nodes), but for the whole network to reap its benefits. Therefore implementing it in Grin++ is important for the whole network
2. Nostr.
Nostr is a decentralized network protocol for distributed and free social networking system. Posts are particularly resistant to censorship and are cryptographically validated. As of April 2023, Nostr has 1.1 million users. One of Nostrās main innovations is its concept of relays, software that sends, receives, and stores text messages. In the case of Grin this would mean that if a wallet is offline, that he download transaction slates when going online from the relay. So Nostr not only serves as an alternative transfer protocol but also serves as sort of a bulletin board.
Regarding follow-up and updates on developments. As agreed in previous CC meetings, he can keep us updated with a few bullet-points update each two weeks or so. Apart from that I think @davidtavarez should be free to work in whatever way he wants, as long as the final deliverables get merged on Github in the end. Yes, it would be great to work with commits, but in the end who cares as longs as the final code is released.
This is my personal opinion and proposal to move forward while taking in consideration the recent criticism on governance by the community, feel free to give feedback.
4 Likes
I like this post, well done putting it together.
I think the biggest issue with the whole project is the lack of direction. People have their own interpretations of what Grin is, so we get pulled in different directions and itās hard to come to a consensus on many aspects, including development. Which I guess is also the beauty of the project.
Re CC Spending guidelines/ CC Role Definition
-
Spending guidelines should be reviewed. Happy to see suggestions made here. I like what @renzokuken has suggested. For me, the key thing about spending is that itās inline with the original donors request:
-
My opinion re the CC role is still what youāve quote me saying
I would also suggest a periodic review of CC members, so being on the CC becomes an elected role with a ātermā period ( This in itself should be more motivation for CC members) new members then have the opportunity to join at the end of each term. We donāt want the CC to turn into some old boys club where the wider community feels let down and is questioning our transparency. This would also make the whole community more accountable as a whole.
I also think the CC should have an elected President or someone incharge of overseeing everything, including the GK duties. Like a stripped down role of what Daniel used to do( which for reference was more than what the CC paid for the trial period with 2x GKs and one of the reasons why I approved the requests). Having someone akin to a President seems the best way to improve transparency and hold the CC more accountable. It would be great if we had people step up and do mundane admin tasks without funding, but the reality is most projects pay people just to manage their discord/ telegram groups. Although clearly Grin is vastly different to most projects.
Spending/ bad decision making
-
For me the purpose of CC having funds was so the community could fund development outside of the core protocol and to allow Grin to be more experimental. But outside of Grin++ there hasnāt really been any direct funding requests for dev work( CC picked up the funding for CoinSwap, but this was something OC would have (likely ) funded aswell, we just took action on it)
-
The Miners have turned into a logistical nightmare and was poorly executed by CC and ultimately a mistake on our behalf( at least so far) . It was a large financial outlay aswell, fortunately BTC was at much higher price when this was executed. Itās also not as large of an outlay when you consider weād previously paid the equivalent of 120k per year for a fulltime rust dev. Part of the logic with the mining farm was that we wanted to encourage funding requests in Grin or atleast in a % of Grin ( Many used to complain about all the funding being granted in BTC, that it was misaligned and that devs should be funded in Grin). The intention of having the miners, was so we would have Grin available to do this, as opposed to having to buy it on market.
-
Even with clear guidelines, Itās still be hard to gauge on what should be granted funding, especially with the ongoing funding to Grin++. How do we ascertain what is justified/ what is best for the project? It seems many are split on their opinions here and thereās no right or wrong answer.
Commitment/ Engagement/ Decision making
Itās hard to find community members who actively engaged in the project, motivated enough to always been around to offer their opinion and actually take action. On a personal note( As someone in the Grin community) Iād like to see people like @renzokuken @vegycslol @johndavies24 on the CC, perhaps even yourself. CC needs more technical people to help make better funding decisions and needs long term community members with conviction to help shake things up.
^Obviously @Cobragrin aswell
10 Likes
As requested by @l33d4n in the CC meeting of 24th of May, I will post this summary here:
Summary on Governance improvement
1) Finance reports were not up to date and need fixing.
This should be taking care of now since @cekickafa will get admin rights to the GitHub page. CC members have merged the finance overview pull requests.
2) Spending guidelines, are they followed?
Yes and no. The spending is properly done, but the CC and as community should do a better job at defining and checking deliverables. I discussed this with @l33d4n and we want to make some changes to the Grin CC description, clarifying which responsibilities council members have (key-holder and preferably active community members), but decision making, checking deliverables and reviewing are a community effort. Clarifying this should avoid differences in expectations.
3) Checking deliverables
In case of recent Funding Requests, like the one from @dtavarez we did not yet check the deliverables, while a new funding request was made.
I therefore propsed to first finish the deliverables before moving to any new funding request.
4) Change the way we move to funding requests
After discussing it with @mo5ito and also as part of what was proposed by @renzokuken, we will first discuss features on the forum, only if they get enough support from the community, we will propose to move forward with a funding request. For example, we will discuss Nostr and PIDB in separate posts with the community to see if there is support for implementing them in Grin++
5) Community mining farm. Update for transparency and clarify who has the responsibility for the farm.
In short, all miners except G1 are now in a professional mining farm where we pay 30% of mined Grin for electricity and housing. A fair and honest deal, in practice this means we pay something like 0.04$ per kWh + free housing.
6) Funding Requests VS Bounties OR something in between?
We will have to discuss again the funding models, Funding Request versus Bounties. Should we put bounties on deliverables and only pay afterwards or is this the path to lose the few developers we haveā¦? That is something we should not easily change. A lot of previous discussion on the topic needs to be red in order to shape oneās opinion. Feel free to reopen this discussion in a separate forum post
2 Likes
Bounties will make it much easier, also whole process can be more transparent, CC projects just need better management to understand status, I am sure we will come back to this topic again when more projects will come, this is why I suggested to create Kanban board for CC projects at Github to know who is working and where.
It opens some kind of hackathon format: everybody can come to help anytime if some part of project is slowing down or has problems, having all information at one place is much better for project management and transparency for whole community.
It can be based on project I guess, if developer needs hardware for example. As we said before actual development cost is zero, only result matters.
This increases responsibility and motivation, cause developer knows he will just not get his reward if work will not be done.
I still think we need some kind of Code-Of-Conduct for CC projects with rules, it deserves single separate post, I agree.
6 Likes
Thank you again. Iāll address to @Neo and @Anynomous replies together about the issues from the original post first to keep it short, hope itās not mixing things up:
CC Role definition / CC Spending guidelines:
@Anynomous pushed PR that defines the role of the CC members:
Grin Community Councilm members are primarily representatives of the community and are keyholders of the community funds. ā¦ Decision making on funding request as well as defining, checking and reviewing deliverables is a community effort.
We (as a community) will have to take a more active part as mentioned above but I think It is important to add a clarification that the responsibility of the CC members (as the keyholders) is to approve only expenses that meet the spending guidelines.
Just to make sure that the āfinal wordā is the spending guidelines to avoid misunderstandings what can/cannot be funded. It makes sense?
@davidtavarez explained it better a year ago:
GK duties:
if we clarified the responsibility of the CC members as keyholders, itās basically transfers most of the responsibility to the community, and the GK as part of his duties will publishes regular updates to keep the community informed about the mentioned topics:
Right now Iām just trying to solve the issues from the original post without additional expenses or changing the rules so I think the one GK role covers it. Let me know if you think we should add or change something.
Transparency reports:
I asked @Cobragrin about the GRIN wallet report, he explained to me that he does not have access to the GRIN wallet and he got the records from the CC members, butā¦
I tried to verify it again after the last merged PR from 2023-05-24 (2 days ago) but when calculating the total revenue - total expenses we get -240,478 GRIN while the stated current balance is 128,307 GRIN
@Anynomous Can you please update the GRIN wallet missing records first to solve this issue?
Mining reports:
Can we add āMining reportā under the Docs repo or maybe a new repo?
Paying 30% of the base currency makes the accounting work easier, so basically this is a one time task (info file + list) and then only requires a regular updates from the GRIN wallet report so it doesnāt add any ongoing administrative work but solves all the transparency issues.
Decision making:
The engagement with this post is an good example how the community members share their opinion and engage if they understand the topic or if itās enough important to them.
For example, we can improve the community engagement as suggested in the replies of this post:
Personally, Iām not sure what is the ābest wayā, but we can be sure that once the information are more transparent and accessible, the community members will be able to share an opinion and contribute to the discussions.
Some of us may even be able to contribute code or take part in other things.
Funding requests vs Bounties:
I think that this post proved that the funding requests method is much more complicated, especially when we canāt enforce it, make sure what the end result will be or what will go wrong along the way as happened several times. It worked, until it didnāt.
The question that needs to be asked is, why put community funds at risk in the first place?
Bounties reduces the risk to zero and simplifies the whole process with a clear definition for the end result, so we can avoid unnecessary arguments and dramas:
There are still issues that need to be discuss (thanks to @renzokuken who explained above) but I think the community supports the need for changes, at least in this post.
6 Likes
I am aware the total does not add up, I also tried to find the mistake before. It is unfortunately not so easy to find the problem, but the total amount is always correct and verified since there are two CC members with access to the wallet. My guess is that I forgot to put a minus somewhere, but that is just a guess.
I had to recover the Grin CC wallet multiple times due to errors in the wallet. Each time I recovered, I lose the whole history of transactions that involve spend UTXOās. Since we actively use the wallet, this means most historic transactions cannot be seen after a restore. Grin wallets do not have a record of all transaction on the chain, unless you run a archive node which does contain a record of spend transaction outputs.
The solution for the long run is clear, but involves some work that I do not have time fore right now.
- I have to setup an archive node
- write some code to convert the transaction history (JSON) to a .csv and drop all the fields that are not relevant or privacy leaking.
- Manually merge the automatically generated transaction table with the current wallet overview which contains the metadata/descriptions for transactions.
I just updated the description to specifically mention that spending have to be in accordance to the Spending Guidelines
1 Like
Source: Trust me Bro.
1 Like
I will take care of the mining reports once I get access to the Github repo, as mentioned at last meeting.
I think irregularities has happened becuz of piling up review of reports. Short time intervals for ex. 3 months period will solve this.
. Tust two CC members 
. But working on getting that archive node running.
So because we have stuff to release, and I agree with you that they are very important features, that means we should not look into the opacity from the past expenditures and disregard Leedanās work? I really respect your work for grin and your intellect but I really canāt understand why you think these missing reports and shady expenses are not extremely important to get to the bottom.
Iāve just found Firo funding management that looks good at my first vision, I think Grin can learn something from it:
Example:
- Firo - Open Collective open for recurring donation by USD via tradditional gateway. Itās not only good for getting more attention but also good for not letting people forget us. We can start like from $1/monthā¦
- https://funding.firo.org/ to track all the task requirement/progress/ideas, I know Grin CC also has same feature but better to have something more visible.
2 Likes
Yes, this is amazing example. Simple tracking at Github board is also can be a case.
2 Likes
Grin CC mining farm updates:
The CC farm is not online and all devices are off, due to complications with the facility, last payout was on the 30th of April.
Timeline to make it clear, we could have prevented it at every point along the way:
04-29-2023: I asked @davidtavarez where are the ASICs and what is the current status, he confirmed:
05-16-2023: I published this post, mentioned the mining farm, the missing GRIN wallet reports and asked again:
05-21-2023: I replied to this post and suggested:
06-06-2023: I mentioned the issue at the CC meeting, asked again for transparency (full notes):
l33d4n : In the end itās money from the CC fund that went out to buy āmoney printersā that we as a community have no way to know how much they print.
l33d4n : The CC members who hold the wallet, can update the GK after each payment or once a week?
@Neo suggested:
future3000: ā¦ but Iām not sure how often the Grin CC wallet gets paid out. That needs to be clarified first. Also, If you really want to audit it then you need to monitor the pool address.
at the time I thought it was an accounting problem, @Anynomous tried to solve it (and still trying afaik) but it was just a symptom of a bigger problem, no one knows what is happening with the payments from the miners, and we never got the pool address (the link below) to be able to monitor it.
07-05-2023: Update from the CC meeting yesterday:
I have 2 questions:
-
During these 2 months since I first asked about it, none of the CC members noticed or checked the status of the miners? how itās even possible to ignore the issue after it has been mentioned (here/CC meetings/TG/Keybase) so many times by many community members?
-
How @davidtavarez confirmed āRunning except for the G1ā (04-29) just 1 day before the last payment (04-30) and all the āwent offline sometime in Aprilā ? and none of the CC members got any update during the last 2 months?
4 Likes
Oh noā¦ Itās not just that: āDavid no longer wantedā. Everyone in the CC knows that David never wanted to manage it. That should be very clear, as well as the fact that David had long ago shared absolutely all contact information with the people at the center. Furthermore, David warned dozens of times, from the beginning, that David was not going to be in charge of the matter. At least 6 months in advance David warned again that David was already going to completely disassociate himself from the topic. To say that: āDavid not longer wantedā¦ā is an understatement, to say the least.
David screamed for help for months, no one listened, no one helped. David suggested that someone from the āCommunityā be found, but no one intervened. I suggested pausing or dismantling the CC as, in Davidās opinion, responsibilities should be clear. David believes there should be a specific person in charge of specific things. The consensus was that the CC is just a ākey managerā (not my words, but others) and that no one in the CC was responsible for anything.
While everyone else was minding their own business, David did everything he could for many months to help make the minis work. And so he did. David repeated over and over again for months the same thing: āIām not going to handle this,ā he gave details of absolutely everything, contacts and every information required. But the consensus was clear: āThe CC only handles the keys.ā.
One might still ask āhow come nobody noticed?ā, but the simple explanation is to follow the consensus that: āThe CC only handles the keysā. Whether one agrees or not, at least that explains the situation. It is coherent: since nobody is responsible for anything, nobody is aware of anything.
David recommends the CC to deal directly with the facility because David shared all the information a long time ago. David does not have access to the CC wallet, nor has he ever had. Again, from the beginning David said dozens of times, āI am not going to deal with the management of thisā. David clearly said, āfor personal reasons, I really wonāt be able to spend one more second on this after x date, itās not a drill, itās for real.ā, and David said it 6 months in advance before x date. Not 1 month, not 2 months, not 3, but 6. Anyway, David is waiting for the CC to share management information with anyone else in the CC. The CC has direct contact with the owner of the facility, and the technician. Any issues I know can be resolved with them.
5 Likes
Hi guys,
I have some ideas about the solution for our inactive G1-miners that CC turned off recently. I donāt know how many miners that CC is holding but we can call some volunteers around the world to receive 2-3 miners for each trusted person.
-CC will define one Grin address for each person, miner can be pointed to pool like 2miners.com, it will be easier to track the balance every quarter.
- Scenario 1: Grin price below $3, volunteers pay the electric cost or facility themselves, I could say it will like a donation to CC in easy way. One G1 mini can cost electric bill around $10 each month.
- Scenario 2: Grin price above $3, we can share 50/50 of total mined coins between volunteers and CC.
If CC agree this proposal, we can call volunteers in forums or on twitter to take his miners and mine Grin as donations. Although there are some risks to believe unknown people, I do not see any better solutions.
If the electric devices keep inactive too long, it will be easily malfunction due to nearby environment.
Who will pay shipping fee can be discussed later.