[Withdrewed] Request for Funding @davidtavarez: One-time use Slatepack addresses for Wallet (RFC and Grin++ Implementation)

[Grundkurs]

I have to agree. How the core council managed this request is disappointing.
Having a full node running on a phone without occupying all system resources and storage is awesome and let Grin genuinely shine in comparison to other projects. Instead of encourage this development it gets slowed down due to some odd requirements that the implementation must be in a specific language.

If it’s that important to u, just let David do its thing and let the implementation port by some enthusiast who think a Rust Version is crucial. If no one shows up willing to port it to rust, it may be a hint that nobody cares about the rust implementation, so why should it slow down the c+±version? I just don’t get it.

Oh wait, only the core council cares, of course, how could I forget. So it is the rust version or nothing.

Such mindset seems hurtful to the project in my opinion, especially against the background that the different implementations literally saved Grins Yellow Ass in the past (Inflation Bug in March)

[oryhp]

There were 2 arguments which I recall from the meeting:

1. RFC owner should also implement Rust version - refuted by @tromp during the meeting and we mostly agreed this shouldn’t be the case.
2. Rust implementation should be the go to for RFCs and hence have them implemented, in other words, we really don’t want to have the Rust implementation not follow the RFCs.

I don’t think the RFC owner should implement it in all versions. But I also completely agree with 2 - having the rust implementation not follow RFCs would be even worse.

Tavarez withdrew the request and said he will think about it, which is why it is in stale mode right now. I do understand @davidtavarez about Rust implementation, he definitely shouldn’t feel the need to do it. In this case, we’d need to find another person to do the Rust side, which is what I hope happens. We don’t want to block things. Perhaps splitting things in 3 parts <RFC, Grin++, Rust> and funding each one separately would make sense.

[vegycslol]

@Grundkurs

If no one shows up willing to port it to rust, it may be a hint that nobody cares about the rust implementation, so why should it slow down the c+±version? I just don’t get it.

Like you’ve pointed out, not long ago we had a case where the second implementation saved grin, so having 2 implementations is extremely important, especially in projects where amounts are blinded. Therefore it would be horrible if they would not implement the same stuff and iirc tavarez understood the arguments for the need to implement the rust part too. Nobody is forcing him though, it’s very hard to predict the time it takes to do something in a language you’re not familiar with and i don’t think anyone would have anything against tavarez if he decides not to do it. People should stop blaming the core for everything, they’re among the people who’ve invested the most amount of time and effort to improve grin and we should all respect that

@Grundkurs

Oh wait, only the core council cares, of course, how could I forget

I’m not part of the core and i care about it

[davidtavarez]

@Mactavish

david is a good developer and did a lot for grin

Thank you.

@noobvie

we now use mobile app for everything.

I agree with that.

@oryhp

Rust implementation should be the go to for RFCs and hence have them implemented, in other words, we really don’t want to have the Rust implementation not follow the RFCs.

Correct, I understood that argument and I agreed.

@vegycslol

tavarez understood the arguments for the need to implement the rust part too

Yes. Since I’m not a Rust developer it was hard (and it is hard) for me to say how much time it will take me to implement this in Rust. I said it before, it was not ethical to make a commitment without having an estimation. I decided to rethink this funding request, while I fix some issues, specially with the Android app of Grin++, then retake the work on this.

@oryhp

Perhaps splitting things in 3 parts <RFC, Grin++, Rust> and funding each one separately would make sense.

Well, yes but I’m not completely sure. After starting to code a bit, also sharing my idea and having few conversations and comments here and there, my initial idea of how this should work changed. Now, by actually working on separated branches and letting some users (from the Community and the Core) to test this before even moving forward, we could find the best approach for this feature. And when I say test this I mean at least having some visual mockups with the user flow description, this will help us to have an agreement on how this should work, so I could write the RFC and from here anyone could write the implementation. With a RFC written I can work on the Rust implementation.

The little detail with this is that it means that someone is already investing time on this only to have the RFC written, in this case: myself. It isn’t clear how this is managed from a funding perspective.

@Grundkurs

why should it slow down the c+±version?

And that’s a good question.

@Grundkurs

So it is the rust version or nothing.

We should fight the Grin = Rust mentality and this has been my main critic. I think we are not taking full advantage of having 2 implementations right now.

I think the problem was (or is) that it is not clear how we should deal with contributors like me, for instance. Let me explain myself. I’m not contributing to the Rust repository yet, but I’ve proved myself contributing mainly with Grin++ and it is clear that I’m not going anywhere, with or without funding. I do this on my “free time” which means that I don’t need to get funded to pay my bills, but getting funded could be seen as a good investment in the long term. I’m sure there are many people in this situation.

Now, from a funding perspective: what should we do with cases like mine? Well, from an idealistic point of view and taking old comments directly from Core and Community members, get funded should be considered as a strong option, no doubt. From a pragmatic point of view, it is understandable to protect the Rust implementation.

I don’t blame the Core at all, on the contrary I appreciate the opportunity given to me to contribute on Grin so far; also, during the meeting when we discussed this Funding Request it was clear that they wanted to help.

@vegycslol

People should stop blaming the core for everything, they’re among the people who’ve invested the most amount of time and effort to improve grin and we should all respect that

True, we should stop the “core vs everybody” thing, it is not helping Grin. That idea is hurting the already shrinked community.

Would I like to get funded? of course yes.

Will I open another funding request? I don’t know.

I’m here because I like Grin, and I like the idea of what Grin can become in the future.

[david]

@oryhp

having the rust implementation not follow RFCs would be even worse.

I disagree. The RFC process is to lay out standards for all implementations of Grin nodes, wallets, etc. Like BIPs, there should be no requirement that the rust version of Grin implement all RFCs. However, any implementation that does implement a feature for which an RFC exists, is expected to implement it in accordance with the specifications described in the RFC.

If RFCs must be implemented in rust, the rust version becomes a major bottleneck in supporting interoperability amongst the rest of the software in the grin ecosystem. For a concrete example, consider QR codes. I would love to see an RFC that defines the QR code format used by IronBelly & Grin++. But if an RFC is expected to be implemented by the rust code, then there can be no such RFC, and therefore no standardization, because the rust code doesn’t even have a GUI.

[Anynomous]

I miss one important point from the general assembly that is not mentioned here.
During general meeting it was also discussed that this this functionality and funding request would very much well fit with the objective of having a Community Council with funds to help grow the ecosystem.
As such the main idea was to delay the funding request till the community council was formed, polish the request and work towards a RFC and make a funding request to the Community Council budget. So there was no malice or negativity, the request was not even rejected, but withdrawn for these ‘strategic reasons’.
I for one would be very happy to work with @davidtavarez and others to polish the request so we can make it the first Community funded project, if the community agrees

[noobvie]

Good to know it was not rejected. From my viewpoint, currently we need more ecosystem to gain non-tech users in crypto community, and what davidtavarez did is really appreciated.

[david]

@Anynomous

the request was not even rejected

It wasn’t officially rejected, but it was clear it wasn’t going to pass, which is why David withdrew.

And it is not a “better fit for the community council.” When we originally agreed to the fund split, the proposal that was accepted was that both funds would be equal in focus, and cover the grin ecosystem as a whole. There is not a “rust” fund and “everything else” fund. Both cover rust and ecosystem projects equally, with the only difference being the makeup of the members.

[Anynomous]

@david

There is not a “rust” fund and “everything else” fund

You are right, there is no “rust fund”, nor does it automatically mean that anything implemented outside rust would automatically have to apply to the community fund.
The way I interpreted the conversation was that some members thought it would be a better fit for the community fund.
This is however me, reading through the lines and interpreting the nuances of what was said subjectively, meaning I might be wrong.
But in my interpretation this is the reason why the support was lacking (I do not think it was rejected), just people hesitating. Also, it is true that on the implementation side it would be good to have some more discussion on how exactly the derivation path should look like and how to avoid security risks such as reusing addresses by accident after losing the wallet. E.g. using some smart on-chain bookkeeping to avoid this from happening.

Anyhow, I noticed some community members jumped to the guns and interpreted hesitance (also by non-core) in a negative way, like ‘the core’ not supporting the idea since it is not implemented in the rust wallet. The way I see it this was not the case and thinking in terms of “core” “non-core”, or “rust” versus “non-rust” users is a bit outdated since we all agree that having more implementations of Grin is better for security and the ecosystem.
[rust][C++][Haskell > [rust][C++] > [rust]

[oryhp]

Thanks, the QR code is an interesting example. I do think you can print QR codes to stdout with some libs, but I’m not sure it makes sense in this case.

[davidtavarez]

@Anynomous

The way I interpreted the conversation was that some members thought it would be a better fit for the community fund

I see your point, but at the moment this Funding Request was discussed there was no community fund, actually still there is not a community fund, but also this would require a RFC; maybe the question is: what is a community project then?

@david

There is not a “rust” fund and “everything else” fund

Correct, the funds were never meant to be invested solely in the Rust implementation, I don’t understand why is this so hard to acknowledge.

@Anynomous

Also, it is true that on the implementation side it would be good to have some more discussion on how exactly the derivation path should look like and how to avoid security risks

Correct, that’s why this feature requires a decent amount of discussion, there is no reason to intentionally slow this but to assure that someone could pick this up and write the Rust implementation, it could be me or someone else; the problem here is there is nobody else at the moment and I personally did not want to make a commitment to something that I was not able to deliver at that moment in a reasonable period (the rust implementation).

Yes, I understand the importance of protecting the Rust implementation, but are we really going to embrace the experimentation stage of Grin or not? if we do so, we need to encourage people to do stuff. We have a post HF wish list that we actually agreed on, this Funding Request was not even out of the boundaries.

Is this feature something that we agreed that we want for Grin? Yes.
Am I a random estranger? No.
Have I proved myself before? sort of, yes I guess, I’m not a rocket scientist but I’ve been learning more and more about Grin and I think it is clear that I can build stuff.
Was I trying to bypass the established process? No way. I said I will write the RFC and I’m willing to discuss the implementation to find the best way to do it.

So why not support this? because we need to make sure the Rust implementation is not left behind by any RFC. I get it, I totally do. I’m not blaming the Core, it makes sense, right now we are a small hand of devs, we’re not in a position of taking many risks. I have so much respect for the Core and the Community, I’m not pointing out my finger to anyone.

The fact that for some reasons, valid or not, we are not supporting contributions through the funds that are not related to the Rust implementation, is incoherent. This doesn’t mean that the Core is some sort of Legion of Doom taken from the Justice League comics; at the end of the day we are all a bunch of random people trying to do our best for Grin and I’m sitting in top of giants shoulders.

@Anynomous

I for one would be very happy to work with @davidtavarez and others to polish the request so we can make it the first Community funded project, if the community agrees

Thanks, I appreciate that. Now I can see several ways to do this without slowing down contributions, but I would personally prefer to work on something base on what I said I want to acheive.

[Anynomous]

@davidtavarez

but I would personally prefer to work on something base on what I said I want to acheive

The way I see it you are a builder and you are good at it. So that is what you should be doing since that is what you enjoy and there is indeed a lot to do on your roadmap. I think it would be best if I and others (e.g. @oryhp @vegycslol, advice on how to deal with security) pick up the proposal and extend it by thinking of how a Grin HD wallet and one time use addresses should look like and work towards and RFC.
I do not think the RFC is something you should spend to much time on although your practical mindset and feedback will be very much welcome. Once there is an RFC, it is up to you to apply for funding and build it since you and @david are the only once capable of doing so.
Whoever wants to implement it in Rust is very much invited to apply for funding at whichever council

=> See here the beginning of the RFC, lets make this an awesome Community RFC

Grin HD wallet & One time use addresses RFC

I want to create this topic to further discuss the details of the “One time use addresses” idea created by @davidtavarez. Basically this idea need to be extended to create a standard on how Grin HD (hierarchical deterministic wallets) should function: https://forum.grin.mw/t/withdrewed-request-for-funding-davidtavarez-one-time-use-slatepack-addresses-for-wallet-rfc-and-grin-implementation/8707/52 We could assign it a GIPXX number (e.g. GIP44), just like how BIP (Bitcoin Improvement Proposals) …

[david]

@Anynomous

some members thought it would be a better fit for the community fund.

Again, what do you mean “better fit”? How can something be a better fit for another council if they’re both meant to be covering the exact same areas?

@Anynomous

(I do not think it was rejected)

It’s clear it would’ve been.

I understand you have a natural tendency to put a positive spin on everything, but the positive spin is just distorts reality, and makes excuses for poor behavior in this case. The council made a huge mistake, and should’ve funded David.

The way they argued we were pushing devs away for wanting better accountability from a council dev who lacked all transparency and made only the minimal effort during his funded period, yet chose not to fund davidtavarez, a dev who always over-delivered and always asked for minimal compensation for his work, was annoyingly hypocritical. It showed that the barrier for council funding was much lower than the barrier for getting others funded, when in fact the opposite should’ve been the case.

[Anynomous]

@david

I understand you have a natural tendency to put a positive spin on everything, but the positive spin is just distorts reality, and makes excuses for poor behavior in this case. The council made a huge mistake, and should’ve funded David.

I agree with you that if I would have been present at the meeting, I would have also reacted differently.
Just like I “like to put a positive spin on things”, I would have argued for conditionally granting this proposal and asking for other volunteers to help polish the RFC.

@david I notice that you sometimes have a tendency to “put a negative spin on things”, which is also distorted or subjective.
I understand where you are coming from since you have been frustrated with the conservative attitude of some of the Grin community and Grin council members for a long time. I think this is just a difference in personality and compatibility of your personality with theirs. Like @davidtavarez and also myself I think you are more pragmatic, meaning you want to move fast and be efficient, which does not always rhyme with conservative attitudes.

In any case, I think the Community Council will have a its own approach and will be positive, inclusive and supportive of active community members. Especially if they offer great value for their money, your services have been a bargain so far @davidtavarez

[dog]

@david

The council made a huge mistake, and should’ve funded David.

This is a bad way to fail. Not listening to peers after this failure would be another major one. The evidence here shouldn’t be ignored, it seems clear that David should have been funded.

This of course speaks to a larger management issue that @david mentioned in chats.

I’m confident that with agents of change like David, the GRIN community will continue to root out problems that persist for a while. If either GRIN council is not meeting goals, we should talk about these goals with the teams and/or others.

Don’t ever give up!

[Anynomous]

@dog We will keep going, with all characters and differences in attitudes that enrich the grin community and ecosystem
For anyone who wants to help push “one-time use addresses” to implementation, feel free to contribute to the RFC I just created :

Grin HD wallet & One time use addresses RFC

I want to create this topic to further discuss the details of the “One time use addresses” idea created by @davidtavarez. Basically this idea need to be extended to create a standard on how Grin HD (hierarchical deterministic wallets) should function: We could assign it a GIPXX number (e.g. GIP44), just like how BIP (Bitcoin Improvement Proposals) work. With Grin HD wallets here are additional concerns that should be taken into account: 1) security 2) wallet performance 3) blockchain bloat 4…

[vegycslol]

I think I’ve said it during that meeting, i would be paying tavares monthly for this. I know we would be partially paying him to study rust, but i don’t care, he’s one of the guys that could come in very handy on the rust side if he can contribute there and we all know he’s passionate about grin. Now some people might think it’s not fair to the other contractors but i would say it’s a good “business” decision and at the end of the day this whole funding thing is basically signing business contracts

[joltz]

To be clear, David withdrew this request before it was voted on. To say that the council rejected the request is disingenuous. There was feedback around concern about funding the writing of an RFC without any development resources available to implement this in grin-wallet. After the feedback, before a vote was taken, David withdrew his request and said that he would consider this feedback and maybe reapply. I hope to see David reapply, even if he can’t commit to writing the rust code, because this is a useful feature for Grin and he is a great contributor worthy of support.

[david]

@joltz

To say that the council rejected the request is disingenuous.

It was not rejected, but seemed pretty clear it would be without an implementation for grin-wallet:

[joltz]

There is a difference between saying “can you expand this proposal to include something I’d like to see” and “I’m not supporting the proposal because it doesn’t have a grin-wallet impl”. I think if David came back and said “I’m not comfortable with the rust work but think that my ask is still a good value for the ecosystem to get this feature in grin++ and an RFC to be implemented in the future” he probably would have had my support in a vote.