Minimalism in spending of the Community Council?

Governance
1

Why we need to have this discussion

This week the Community Council prepared their funding for 4 months for David T.s work on Grin++ (API and client so Grin++ can run as client on Raspberry Pi’s), funding for 4 months for two fine groundskeepers full of new ideas. Since the start of the Community Council, we made sure those who needed funding had access to them, we are funding the CoinSwap implementation, bounties for Grin Telegram chat bot, we bought a lot of community miners and the ground-keepers made sure information news and accounting went fine. So everything is the Community Council working as intended then?..well yes partly… and in other parts not completely the way I hoped it would. I will explain below.

Grin is a distributed project

In general since the Community Council was started, the aim was to encourage more voluntary contributions to the project, work in subteams and have more contribution on a voluntary basis. This is happening to some extend, people make great contributions to discussions, marketing material, their own websites on Grin and many people use their free time and energy to contribute, not to forget, the Community Council (CC) members and Original Council (OC) members work on a voluntary basis.
However, if I look at the spending of the Community Council, I cannot help but feel we should be even more minimal and more strategic in our spending especially in a bear market like the one we are having. Find below an overview of the Community Council’s BTC wallet:
https://bitinfocharts.com/bitcoin/address/bc1qmdhmgmhd6j89225hzdh7dxqgmen3y2q0g4vgpez0tw9tkp4ae39qsqvuyl

Financial status and long term health of the Community Council funds

As can be seen, we the Community Council started with a fund of 33 BTC and now has some 25 BTC left. As also can be seen in the transaction this month, a simple 4 months payment to David and our Groundkeepers takes a significant amount of our remaining funds. If the current low BTC price would hold (unlikely), no new donations come in (possible) the Community Council would spend all its funding in 3.7 years.
Now as I said, those 3.7 years assume a worse case scenario, however we need to discuss as community if we should not be more minimal and saving since these 33 BTC granted to use by OC, community and its generous donors were meant to fund Grin for the long run, and not only for the next 3.7 years. Every Bitcoin we spend in the bear market, could be used to fund 10x as much work in a bull market. To be clear, what I state here is my own pondering and concerns. I did not have any discussion with other CC members on this topic before posting (@mcm-mike, @davidtavarez, @Neo, @Mokhtar, @hendi), nor is there any existential crisis. The OC still has plenty of funding left, as does the CC at this moment. I just want to address this topic now while all funds are healthy since we need to have this discussion if we want to be responsible and true to the long term goals of the project and the long term financially health of the CC funds.

Why I timed this discussion now

I on purpose timed this discussion while having our ground-keepers and @davidtavarez funded for the coming 4 months, so we have time for this discussion and there will be no direct threat to the continuity of their work or personal dis-convenience

We need your input since these are your funds

Let me know what you think, should we become more minimal and strategic in our spending?, should we minimize our spending in a bear market? What should be our short term and long term strategy? If we should be more saving, where should we spend and where should we save on spending? What about certainty and continuity for long term contributors?

7 Likes
2

Worst case is far worse imo. If binance or tether fails then we might see another huge dip.

Other than that i agree with what you’ve said.

4 Likes
3

If its about reducing spending of the remaining CC funds one should elaborate:

  1. Does such tiny project like grin with ~ 100 forum-visitors per month really need 2 Groundkeepers?
  2. Funding of David T. is super important and should be ensured as long as possible.

Such considerations are speculative and likely counterproductive. It assumes that BTC will go up 10x in the future. How can anybody know if such thing will happen? BTC price evaluation might also go 10x down from current evaluation for the next 20 years and might never recover.

Consequently, any financial support would be reduced to a minimum in a bear market and increased in a bull market. I don’t see how this is compatible with an open source project. BTC volatility is as it is. The only effective way to get around BTC votality to ensure an uniform financial support of the existing projects would be to convert the BTC to some shady stablecoin which i would consider a no-go.

However, i appreciate the discussion since the considerations are valid and the raised questions concerns future problems that might arise.

1 Like
4

It is as you said speculative, but at the same time I think it is being realistic. I just cannot help but think that for every 1 month funding of a developer or ground-keeper we spend now, we can get 10 months of funding if not more in a bull market.
To me there is no shame in laying a bit low in a bear market. My own company which is crypto related does the same and I look for income outside of crypto in the bear market. It is purely pragmatic as a business owner. As far as I know most open source crypto projects do the same and minimize spending in bear markets
I think as project we also have to be pragmatic. For example, we can ask our-self how pressing is adding a new functionality right now, or can that functionality wait?

I personally think that after funding the API and client part for Grin++, we only need PIDB to be added to Grin++ and maybe in due time CoinSwap. Apart from that we only need to fund minimal maintenance to Grin++.
As far as I know, @davidtavarez also has a job outside of Grin, so maybe it is not a big dis-convenience as some might assume to work less on Grin and more on his regular job in the coming 2-3 years. I think funding is not the basis of @davidtavarez long term dedication to Grin. Similarly, not adding new functionality to Grin++ does not inconvenience Grin users. We have multiple working node and wallet implemantations. Maybe we need to just save some juice/finance to go full steam ahead with the project when we can have more impact/value for these funds.

7 Likes
5

I appreciate you forming such a thoughtful post on this.

As a simple community member, my support is for minimization.

On Grin++: Maintenance of an operating alternative implementation is important as we are all aware. However, I do not see the point in something like Raspberry Pi support. The usual idea is that this is supposed to support accessibility or something, but I have never bought that. I don’t believe there are actually users who have an RPi but not a regular computer. They are more like a toy for people who already have computers, but also want a low cost way to run some always on networking function. How many actual nodes does anyone think this is going to facilitate at current activity levels? Maybe 5 I would guess. I would much rather see any development effort above strict maintenance go into existing UX/UI problems. “Waiting for peers” is still the single biggest new user experience hurdle in all of Grin right now imo. And if it doesn’t get decisively addressed soon then grin-gui is likely to completely replace Grin++ as the recommended client for new users. Or how about a Tor on off toggle? A new user is most likely wanting to withdraw from Tradeogre and does not need an address ominously turning yellow or green and confusing them (broader issue I have with Tor addresses completely, not just Grin++).

On the newsletter: To put it harshly, who’s reading this? Only us, who already know what’s in it. I cannot imagine the Grin user who is not interested enough the follow the slow pace of developments on the forum and keybase but is interested enough to keep up by the newsletter. I also don’t believe any of these updates are going to change anyone’s mind about Grin, ever. The world is either going to come around the idea that our base layer and economic model is superior or they won’t.

1 Like
6

This is in regard to the already funded funding request of David T for CLI version of Grin++ and unification of the API with grin rust. The idea is that one can use either one of the nodes and wallets Clients with exactly the same calls, meaning any downstream programs do not need to chose between building on top of grin rust or grin++ node and wallet clients. So it is not only about Raspberry Pi support, it is just an example of what the client version could be used for.
In general I agree with your thinking, we have to prioritize what really maters, for that feedback such as yours is important so we can cut down tasks to maintenance and other simple UI tweaks the user really needs right now.

1 Like
7

The reason I appreciate raspberry pi support in general is because it allows for pre-packaged devices easily distributable to new users without too much hassle in setup. This use case has already been somewhat proven with Jameson Lopp’s work with Bitcoin nodes on RPi.

Additionally, Grin Network can always use more full nodes with incoming connections. One of the posts I intend to create will be an overview of the general process and why it is important especially for emerging blockchains. Some users who run a full node on laptop or desktop will not have it running all the time, where as Pi is easy to set and forget with, I think, maximum 12 watt overhead on Rpi4.

So it’s a fusion of both novelty and utility.

8

Just one note on the CoinSwap. I know Scilio has already mentioned wanting to take on the wallet integration after completion of the three milestones. It might make sense to prioritize this as well since we don’t know his/her timetable or future circumstances in regards to commitment to Grin Project.

I would really hate to see CoinSwap, which has been years in the making, become a stagnant or incomplete project in the way of atomic swaps. And is this not being funded from the main OC fund?

It will also serve to boost utility and visibility of Grin and one step closer to fulfilling its full potential. I see it as an investment in the future as well as necessary promotion surrounding its significance to the crypto space overall, but that’s probably for a post for another time.

1 Like
9

I also support minimalism. Since CC funds are finite, I would prefer to see funds spent on finite projects/tasks, and less focus on recurring dev/groundskeeper work.

E.g. David has done great work, and I don’t want his efforts to cease, but I would prefer to see Grin++ move to an independent funding strategy, rather than draining CC coffers indefinitely.

Similarly, our groundskeepers are great, but this project is small. We do not need two groundskeepers on payroll. If that really is a need, perhaps we can come up with an independent funding strategy for them too.

Tl;dr: Projects with indefinite funding requirements need to raise funds independently. CC cannot pay salaries. IMO CC funds should be reserved for bounties, finite tasks, or kickstarting a new project until that project can become self sustaining.

7 Likes
10

The grin rust node and wallet run smootly on a Raspberry Pi. So it is not really a novelty in that sence, but it adds more freedom for users. Chose whichever node you want, whichever wallet client and whichever GUI you want. Also for developers since Grin++ will now implement the V2 API from grin rust, whatever they build can be used with both nodes and wallets. All in all it should help downstream developers and remove dependecy on either grin rust or grin++ since they will be interchangable.

1 Like
11

I don’t think anyone’s suggesting pulling the existing Coinswap bounty. But I would be extremely surprised if Scilio ever completes it, let alone anything beyond that.

13

Really, what makes you say that? He replied not a few weeks ago saying he was nearly complete with milestone 3…

To be clear, I’m not talking about the existing bounties, but when he mentioned on keybase a few months back that he is interested in taking on the wallet integration after the completion of the milestones.

I guess I’m on the exact other side; imo he/she has delivered commendably so far and I don’t see any cause for concern at all

14

There have been sporadic updates for over a year now with very little action in between. Successful projects usually go in entirely the other direction.

15

Time will tell. In any case, funding is and will be available for important additions to the project and to either grin++ and grin rust to implement such features such as CoinSwap.

16

I believe in decentralization and I think it is important for people to begin to understand that crypto facilitates a culture where P2P could one day become something truly important. The fewer centralized services are used the better, this applies to everything: nodes, wallets, cloud services, finance, etc.; the fact that anyone anywhere in the world can run their own services and barely consume 5W is the advantage of portability. There is no need to trust a third party anymore.

I don’t think the Grin++ user has to share my vision, but my vision directly affects my focus, whatever I want to devote time to is my decision.

What are those “existing UX/UI Grin++ problems”? Please share so I can work on them as I work on every single problem reported in Telegram.

What do you mean by that? Since v1.2.8 you are able to enable Tor bridges directly from the UI, I also shipped support for all type of bridges, and anyone can use the UI to enable it or directly using the API.

At this point, I can’t remember how many times I repeated that I’m working on every single problem reported by users via Telegram since years ago, David B. did the same and I continued to do it. People DM me on Telegram and I answer 100% of the time. People report something on the support channel and every time the concerns are answered until the user is able to fix the problem. Now faster and better thanks to Satoshocrat, Danila and others. I want more people to report problems so that I can prioritize them.

Do you say that based on what? What I have found by asking users personally over and over again and using surveys on the telegram channel when the channel was more active, is that people prefer the synchronous transaction method. This is also confirmed by me based on my experience in supporting exchanges and developers, they refuse to implement asynchronous transactions because they think the TO is more difficult. Don’t get me wrong, I usually prefer asynchronous transactions, but you are completely wrong. And that’s why I made easier to enable bridges via the UI, for those users having problems with Tor.

And you know why this happens? 99% of cases, the problem is solved by using the high-speed node list from the community, which you can also do via the user interface and the API. The rest 1% of the time is because data corruption can also be repaired with one click. I have gradually introduced corrections to the synchronization code, and I will continue to do so until the problem is completely solved, if I continue to do so, it will no longer be a problem sooner or later. I haven’t had this problem since v1.2.5 on any of my test nodes that run around the clock, nor on my donation wallet, which constantly runs from an old phone.

Imagine that this does not happen, just imagine. How many people are working on Grin++, including maintaining the C++ repository, adding new features and fixing problems, but also the UI code (typescript) and the mobile application (C#)? Just one, me. Imagine that the grin-ui does not replace Grin++; I actually expect this to happen, if that doesn’t happen, I’ll be very surprised to be honest.

Correct. And like I said before: the CLI is right now to test those changes before updating the GUI, more like a playground before introducing new changes to the desktop application.

I agree, and that’s my mentality: I will stop working on Grin++ at some point, if I feel I’ve made a significant contribution, this could be in a year or two or three, but at some point I will stop.

Thank you. Now, let me ask you. Do you believe that I am draining the CC coffers? The funds are literally there to support the development, that’s why the funds exist. Why are my contributions different from the Rust repo? Especially since Grin++, it happens to be more than 50% of the nodes of the network. Don’t you think it should be a priority to continue its development by supporting the only contributor?

I wish I could stop participating on the funding request process because I honestly hate it. I don’t like having to deal with random people in the public space that don’t even pay attention and want to impose their values on my work and judge my work based on purely nothing. I do not like that at all.

If someone is willing to support my work outside the CC, I promise that I would be very happy. Please help me.

2 Likes
17

It seems to me like 100% of new users have a computer, and maybe 1% have a Pi, so I don’t see the accessibility or decentralization benefit tbh. But I don’t disagree that you are free to work on what you want to work on.

Waiting for peers is the primary UX problem imo, and has been for a long time. Could it be as simple as needing a seeds update? If grin++ relies on DNS seeds same as rust node which I imagine it must then it could indeed be. I’ve put my actions where my mouth is and started a PR for that but I noticed a comma typo in it today I will fix and reopen.

2 Likes
18

Literally, yes, payments to you do reduce CC coffers, but thats not a criticism of you. I feel the same for any recurring dev salaries, e.g. Yeastplume, and just used you as an example.

I think the investment in your time has been worthwhile, honestly. I only mean to suggest it would be better if there was an alternative funding source for indefinite tasks, such as Grin++ developement/maintenance. That way Grin++ can become self sustaining, and we can reserve CC funds for bootstrapping new projects. I don’t have a suggestion how to achieve this though :sweat_smile:

19

Thank you for the answer, I appreciate the honesty and I think you brought an interesting topic here.

My point is that the funds are there exactly for that: to keep the development train moving, not only Grin++ I would like to dedicate myself to Grin as much as I can, so it is a win-win situation for everybody right now, for me and for many more people.

One of my suggestion is to keep the focus on the Post 5.0.0 wish list:

And secondly: let’s keep the development train moving.

Side note: I don’t think Grin++ is in a state that would allow me to focus on another project, but some people think otherwise. I’m a bit flattered.

2 Likes
20

Let me be more precise about my opinion and suggestion for our spending strategy for 2023.
I think any feature except Parallel Initial Block Download (PIDB) implementation, even the ones on the post 5.0.0 wish list, can wait till Bitcoin is above 30k$. Basically these are all ‘nice to have’ features.
Grin++ works fine apart from the p2p connection sometimes dropping (at least in my case). I hope that + PIBD can be implemented sometime in 2023, anything else I would consider as a feature that can wait till the condition of a > 30k$ Bitcoin is met. Grin rust appears to very stable since the 5.2 alpha and will be funded by OC.

Any running bounties will be fully funded as promised. For groundskeepers, I would suggest to either stop funding after this funding period of 4 months, or move to a very minimal system of only minimal administration for 500$ per month, the rest is voluntary work or will be dropped. Ones Bitcoin rise above 30k$ or another threshold we define, we can slowly increase spending again on ‘nice to have features’ and groundskeeper work.

3 Likes
21

I agree mostly, i think we should consider supporting projects like python implementation for an enhanced dev work and better adoption. Python implementation can kill 2 birds with one stone.

  • Will attract More developers.
  • Offload the existing developer work and financing.
4 Likes