Nobody is ignoring it. If people ask this question in a nice way, I’d be willing to give an open answer.
From which interaction did you get the idea we’re blinded by pride?
I’ll be speaking as a community member here and give the exact same answer as prior to being a part of OC. The OC was protecting Grin, but very few community members had a deep protocol knowledge needed to be able to tell this.
I have never had such an experience for my own proposals. People were willing to give me feedback on my ideas out of which many were not appropriate for Grin. I think people used “fork if you want” response only for the times when certain individuals wanted to push for changes and were hyping the community as if the change was a way to improve Grin. This didn’t make them right however. If OC had no spine back then, the protocol design we have would have driven off the cliff.
Some community members entertained this thought, but it was never really true. The OC welcomed my thoughts and helped me a lot writing this rfc. Let me share some things that were never talked about in public. Quickly after I joined the Grin community, I’ve started to extensively interact with some OC members in private by sending them a github gist of an idea which they went through and reviewed. It was my way of learning how things work. This happened over 30 times and never had I not received a response or one that would make me feel like shit. Did we disagree on whether an idea was good? Yes, we did, but in almost all cases I often found myself reflecting back and understanding why they were against it after I gained more understanding of Grin.
The OC and the community actually reacted very poorly. The situation back then was relatively transparent/obvious along with the consequences, but everyone was focused on picking a side and playing a vigilante against OC rather than trying to understand why there were different opinions. Along with that, many were defending the ongoing abuse with the excuse of “we don’t want to censor people”. The two have nothing in common. I’ve tried to explain what was going on and what future awaits if we don’t do something about it in these two comments.
You should know best that making Grin easy to use is a very hard task and thus creating a good product is as well. There clearly was interest in making a good product which the Slatepack RFC proves as well as many proposals that were denied which avoided making Grin mediocre.
A lot of us have invested many hours of our free time on Grin which suggests we care about it. Speaking for myself, there’s no doubt I’d rather see Grin die by failing to gather network effect than us adding features that would end up making the protocol mediocre and thus not stand out.
If people want to talk about this in real time, we can put it on the meeting agenda. The answers won’t be as well thought out because it takes time to describe these situations and thus forum may be more appropriate, but I’d be willing to share my views and experiences.
@Anynomous@vegycslol@oryhp you are actually proving my point right now. I also believe that good calls were made in regards of NITX specially, I am more and more in favor of interactive transactions. The fact that I am in favor of the interactive transactions and a minimalist approach, it does not mean that I will forget that Kurt, Burkett, gary, Guy and others, were treated badly and/or just ignored.
Like I said, I am not judging, and again, I agree that good calls were made.
The OC stopped interacting with everyone, what do you think was going to happen? what had to happen happened: they lost the Community’s trust, and it is unfortunate because we had very capable contributors, but no one will put a penny or a second behind a team that no one trusts.
Who among you has spent at least an hour supporting users? Who among you interacts with users? Yes, with those users who don’t understand the protocol.
How do you then prioritize the problems to solve if you don’t even know what the users are dealing with? Is that how you make a good product?
I have shared many times on Keybase direct feedback from the few exchanges that list Grin, what did we do with that?
How are you going to build a product for people you don’t even listen to, because you’re smarter than them?
That attitude is nothing more but pride, and no, just because you think you’re the smartest kid on the block doesn’t mean you’re building a good product. You have to get involved, you have to observe and understand how people are using your product, you have to understand what problems they are facing, including Exchanges, and make the correct trade-offs. But you don’t, sorry, but you don’t.
We need the Community support, we need the support of those who put their real world money mining Grin, for example. We need the support of those who are interacting with Exchanges. I am not saying that we should let moonboys change the protocol, but people losing money trading Grin are the one who push the few Exchanges to support Grin.
Yes, I am well aware of that. The Slatepack RFC is just beautiful. One of the last suggestions Burkett made on Keybase was to deprecate the RSR flow, which nobody, I’ll say it again: nobody is using. But it is ignore, why? because it’s always a fight of opinions instead of asking what’s best for Grin.
What do you think will happen when you only engage in conversations about things you already agree on? If you don’t know, let me tell you that you will lose support. So, in the future, when you share a proposal, those you ignored then will simply ignore you. How does this help Grin’s development?
I get a notification on my phone every time someone asks something about Grin++ in the Telegram support channel since 2019, I try to share what we have learned from that and from Exchanges as well, and I don’t see this influencing Grin one way or another.
Don’t get me wrong, the more I get involved, the more respect I have for all the current and past contributors and developers. What I’m saying is, yes, let’s ignore the moonboys, keep building our uniqueness and keep trying to unleash the full potential of the minimalist approach and interactive transactions. But we must also grow and learn from the mistakes of the past.
I hope we do so. Indeed many past discussion were to much about ‘who is right’ opposed to just agreeing to disagree. Sometimes the community, or at least I, bought to easily in ideas or entertained discussions that were not for the good of Grin on the long term.
The reality is there is no right or wrong. And many ideas that did not (yet) make it into Grin, were great ideas in their own righ. I am certain that on the long term, these ideas only help develop Grin, might be implemented in other project and some of these ideas will be revisited from time to time and might even be implemented in one form or another in Grin in the future. Hence, the energy spend on these ideas was not wasted. The energy spend on the emotion that went with these discussions is what wasted a lot of energy for everyone involved. The objective arguments themselves were and will always be of good use for the future of Grin and crypto in general.
I think if we had depreciated this flow, nothing really would have changed. The core protocol perfectly allows for RSR. So having that flow around only gives opportunity for times when it is needed, e.g. web shops. RSR has no negative cost the project, protocol or to uses. If payment proofs get implemented for RSR, it will have some added value to the project.
I think the new transaction contract by @oryhp is a step in the right direction to unify SRS and RSR.
This is rather important IMO. I think we never properly listed any arguments or grievances from exchanges. I at least do not think we have such a document around. You are right, real world problems need real world solutions and you probably have more knowledge of this than anyone else around in the project.
Lets started with listing these problems, quantifying them.
e.g. which exchanges how many list them as a problem, what solutions/work around did they use and if and how can we make more structural solutions to ease the burden on both exchanges and wallet developers who get burdened with support tickets. My guess is that most come from the memo system.
Payment proofs with RSR (in the future we will probably just call it a transaction contract) could for example be the solution, since the user would not even have to think about the proofs, they just follow the interaction from an exchange and the user would automatically have a payment proof with no possibility to make manual mistakes as is the case with the memo system.
You are so right. Lets list the real problems, think of real solutions. And lets not forget all that is good. Grin is on the right path IMO, yes we can still improve things, but even there I think there are a lot of good solutions being developed. Lets focus our energy on developing these solutions.
Let’s say i propose X, you say it’s not a good idea to implement that because of Y, i don’t understand why Y matters so i disagree. I keep pushing for X, what would you do? They didn’t want to fight so they’ve started ignoring. Although it might seem unfair it’s hard to choose a better way in this case imo.
You can’t, that’s why you and others who are, among many other things, dealing with user’s issues are invaluable. From the conversations I’ve had with different people i came to the conclusion that autoreceive is preventing them from understanding interactivity (and safe-cancel), that’s why (alongside losing some nice properties) I’m in favor of removing it.
What would you have done differently? My idea has been to try and make exchanges use manual copy/paste of slatepacks since it’s easier to integrate and works for everyone, i still believe that’s currently the best approach.
Nobody is saying someone is smarter than someone else. It’s important to listen to what the users want/need but solutions to those needs must not damage the protocol (there might be exceptions ofc). It’s easy to spot problems but hard to find good solutions for them and it takes time to implement them (especially with our currently limited dev resources).
What would you have done differently?
I have been telling people about RSR use cases for a long time, have also given an example of RSR real world usage to which I’ve not gotten any feedback as to why that’s bad or not needed. Nobody is using it because it’s not yet properly supported. Shops/services are cases where RSR makes the most sense but why would they implement RSR in their shop if the most popular grin wallet doesn’t support them? Sadly it makes no sense to do so.
Issues related to proposals were raised, ignoring came after people didn’t understand those issues and kept pushing, at least that was my observation.
Could you point me to the exact proposal that was ignored and unaddressed?
You suggest others ignore these, but if my memory serves me right, that’s not true. First, Kurt was the person I communicated (by far) the most with on Grin. We had private discussions daily around MW and Grin and were reviewing each other’s ideas (most of which were never public) and learned from each other a lot. I know that at least myself and tromp (iirc antioch as well) reviewed both of his kernel uniqueness proposals and some reviewed 2-step ideas as well. The discussions are all public I believe some happened on keybase. You’re talking as if they did nothing bad and were treated badly. I consider Kurt a friend and would be more than glad to see him return, but this doesn’t mean his behaviour was good, it most certainly wasn’t. I even remember him admitting that on some occasions. It’s not like one side was a saint waiting for a response and the other side ignored things. Things were heated because the individuals took a specific (unproductive) approach to things. I’m only talking about the first two names on that list here.
This is one of the reasons I wrote above the OC reacted poorly. But you have to look from the other side as well, how many people were defending them when they in fact did not deserve what they were getting from the community? You will now ask “and why did they not get the support?” to which my only answer is because people didn’t understand the context and implications of the protocol changes they refused to make and were easily convinced by the popular community members the changes were good.
Because David, Davies, Kurt (a little less so) and others convinced everyone that OC was wrong and wanted to start a rebellion against the OC using the words they will “destroy Core”. It’s extremely easy to convince people that an idea is good, I could probably convince most of the community the scripting method I described a week ago is great and everyone would believe me without a single person understanding what it actually does. There’s a very big asymmetry of knowledge regarding the protocol between the community and the developers and only a few would be able to see why this is bad. You can guess which ones would be able to see the flaw. I could organize a rebellion against them. Does this mean others are dumb or less intelligent? No, the knowledge asymmetry and the way people react to “shiny features” is just a part of the dynamics we live in. I could similarly be convinced something is good on a subject I’m not familiar in when in fact, it wasn’t good.
I have not. My experience comes from my own usage and protocol understanding. I’m not good at this and hence I don’t do it. But I can definitely tell what could be improved which is why I’m trying to get feedback on the contract prototype.
Who is “we”? I have stated many times that I don’t plan on investing my time in supporting a specific exchange. I’d rather have something that makes it simpler for them to make a robust integration. I believe a path forward is to unify the transaction building and integrate with manual slatepacks. Introducing an additional “network must be up” assumption (e.g. Tor), doesn’t seem to be a good idea if you want to make it robust. The user and the exchange already have a network connection through a website, any additional may make it faster, but also less robust.
That’s quite an accusation. Could you point to an example of when I (or others) didn’t listen to people because I thought I was smarter than them or where I had “the smartest kid in the block” attitude?
Are you sure that’s what’s going on and it’s not just me investing time where I believe I can contribute the most? For instance, the reason I didn’t answer to GrinTurkey above was because despite asking 3 simple questions, I received 3 separate answers none of which answered a single question I asked and on top of that he made unsubstantiated accusations all over. It simply felt I won’t be able to achieve anything if I engage in such a conversation so I went to do other things instead.
It’s very easy to say “you have to do X”. The issue is time, skill and motivation. I have a limited amount of free time. If I start being a support person for Grin, this means I’ll be less focused on other things. If I had done this for the past few years, it would mean we would have less or worse of the following:
the contract prototype or research in this direction
what is grin/why grin and other documenting of ideas on grinvestigation
some replay solutions and discussions
reviewing of other ideas etc.
It’s a tradeoff. I have no idea which one would be better for others, but I do know I’m not good at the things you accuse me of not doing and doing that would, for the specific case of myself, be a less productive path. Since I’m not good at that task, my approach to help on the front of making it easier to use (which is a passive support I guess?) is by eliminating friction when building a transaction by unifying concepts and making the process itself simpler. I believe the contract prototype to be a step in this direction. It’s not taking user experience into account (apart from mine), but it does seem to make the process simpler and more robust if done right.
This doesn’t mean RSR is bad and it certainly doesn’t mean removing it is a good idea. Was there any other developer that wanted to remove RSR apart from David who was clearly against RSR? Have you ever thought about what a 5 party transaction would look like on Grin? If you think about a SRSRSRSRSRS transaction with 3 senders, only one of these senders will be able to finalize it. I don’t see how the solution is to potential RSR problems is remove RSR because the same “issues” appear in a context of multiparty transaction. Would it not make more sense to separate the setup and sign step and generalize transactions over this to potentially get multiparty support and have a unified flow for a case of 2, 3, 5 parties? I can’t say this will come out, but it seems like a better direction to research than to just say “X is bad” without thinking about what the underlying problem is. The other suggestion was to turn RSR into SRSR which, again, doesn’t tackle the root issue.
Did we really do that? I don’t see this as being the case at all. As far as I remember, I personally have reviewed almost every idea that appeared regardless if I thought it was a good direction or not. This includes NITX, different kernel uniqueness proposals and many others. And as stated above, so did people that were on OC back then. The disagreements came from the fact that after the review, OC members said the idea was not a good fit for Grin. I was an outside observer, but it seemed that any non-engagement was a product of disrespectful communication on the other end and these discussions are public on the forum/keybase because I remember seeing this.
I think it’s great we have some people doing that. Did you have any specific change in mind here that you’d like to see and it’s not coming through?
I think everyone agrees on this. My view on the state is that those that are around work on and what they believe to be the best direction. Speaking for myself, if I reflect on the contract idea, I believe I initially explained the symmetry of the flows years ago and the idea didn’t move anywhere until I started coding the prototype myself. The time I have, I invest in this. Someone else will invest it in what they believe. If we’ll agree this isn’t a good path, I’ll drop it and start working on what I believe is the second most important thing. Of course there are other tasks everyone contributes to (e.g. reviews or new ideas), but time is limited and not everyone can do everything, so you have to cut some of the items off the list. The main thing we have to do is to keep supporting each other to contribute our free time to Grin in a productive and judgment-free manner. It’s incredibly easy to turn against each other, but things can always get resolved in a productive way if both parties are open to a constructive discussion.
In fact, the source of the problem is that it is a bear market and many people have lost a lot of money because they bought Grin at a high price, so they have created complaints. To be honest, I lost a lot of money too, but I am not complaining, it is my own choice and I have to take the consequences for my own choice. In the crypto world, every project is like this, there are always people who make and lose money. Especially for a project like Grin, the core developers are not responsible to any investors.
I’m a normal person with limited knowledge, and through my use I found that one of the real problems Grin is still facing is that the wallet is not easy enough to use. grin++ is a great wallet, but there is no way to use it in many places, for example in China it doesn’t work, you have to use a VPN at the same time, and only few VPNs can support it, users are torn when using it, green address or brown address? It brings an uncertainty to the user. When Grin++ address is green, you can directly trade at once is very convenient, and does not have the kind of complexity that people think. The Easy Wallet, developed by developers from China, is a much better experience in terms of using it, allowing the wallet to be online in real time and to check if either wallet is online, and if it is online you can send coins directly to that address, and if it is not online, you can do it by trading offline. It’s really convenient, friends can try it. The problem is that there is a loss of security.
So my suggestion is to combine the open source and security of Grin++ with the ease of use of the easy wallet to make a more secure and convenient wallet.
Easier for users to use and easier for exchanges to integrate, which should be one of the current issues to focus on.
Historically this has been the bigest cause of complains for Grin. We should keep this in mind. Often nothing wrong with the project, just people upset with the price. Not even worth us spending our energy on. We better use that energy to keep building Grin constructively.
Orihp, tell me, is there something you are wrong about? Why are you right about everything? You still don’t want to accept criticism. A few people make a decision, and what benefits have these decisions had for the Grin investor and the Grin miner so far? Arrogant and egoistic rhetoric keeps people away from this project. Tell me, how many of you have attended a seminar for Grin? (How many people promote Grin except Ipollo) How many people wrote a post on Twitter? How many people tried to get the attention of the BTC community? (I only know the Netherlands) How many people tried to reach analysts and promote Grin?Who came out and said hopeful words for this project? David is absolutely right!! Because of your silence, we are having difficulties introducing Grin to people.Look, I’m criticizing, you’re talking about the price! You are constantly tying the issue to the price. How many people started this project? how many people are left now? The issue isn’t just Grin’s price.People are right to reproach you. If you can get 1 million Grin with 3 BTC, don’t talk to me about success!
It is hard for me to believe we are learning something other than the less toxic is the environment the easier is to contribute. I will give you an example. Let’s take a look into the Coinswap Implementation request.
How can we mitigate the consequences of you disappearing in the middle to the process? simple: we need to make sure anyone could finish your work if you disappear.
Look at the PIBD work, we ended up without neither an implementation nor a RFC nor even a work-in-progress Pull Request. In advance or not, for me that is irrelevant if we can’t find a way to get this thing, or anything else, done. It is not hard to understand. Do we want to be in the same position again where we are left with nothing? I think we don’t.
And what we have today? neither the implementation nor a documentation to complete the work. We are in the same weaken position that I warned about and wanted to prevent. It happened on the first attempt of the Atomic Swap (from Jasper), it happened with the PIBD work, it happens on the second attempt of the Atomic Swap, and now it looks like it already happened again in regards of the Coinswap Implementation.
It is fair to say that we should re-think how we approach these things. The main reason we need clear and well explained documentation is for security, to make sure that no exploits are introduced into Grin source code, but the second reason, and especially important to us, is because we need to make sure that anyone can complete any pending work.
Protocol related topics are the core so to say, but Grin as a project is broader than that.
I swear I don’t want to be the pessimist here, but if you put yourself in the shoes of joe normie you can understand why an outsider might come to the conclusion that Grin is a dead project, and throwing out the popular cards - “it’s fomo”, “you’re a bot”, “you don’t understand the protocol”, etc., etc. won’t help… what joe normie sees is years without any significant improvement. Is joe normie unaware of the Grin protocol? Yes, but joe normie is not so dump as to ignore what’s in front of this face.
I’m glad you asked. I would have prioritized the reported problem that prevented one of the Exchange from updating its nodes. I would prioritize fixing the problem of the wallet stopping communicating with the node, and the problem of the nodes being out of sync. Both problems also reported by one of the Exchange. I would have also prioritized the issue with the node not removing the files from the tmp folder. Those are 4 examples of things that I would have differently that affect the experience of people, Exchanges, solo miners, and voluntaries running public nodes.
So let me be clear: I think past conversations became too toxic, and some comments made went outside the bounds of the civic exchange of ideas. Things were said that could easily lead to a fist fight in the offline world.
I do get you approach and honestly I have nothing bad to say about it, and nothing bad to say about you. I am not asking you or @vegycslol to start offering support on Telegram or something, what I am trying to say is that it does no good to reject everything other than what you see from your perspective. Want an example? I’ll give you one.
I personally prefer the TradeOgre implementation using the SRS flow by manually sharing the slatepack messages. Now, TradeOgre is the only Exchange so far willing to enable an unique UX only for Grin (thanks God). The rest prefer Tor because is easier for them and easier for their users to see the grin1 address as a Bitcoin like one, for example. What do we do then? Enable non interactive transaction because of that? Hell no! I agree, but then what?
This is just you saying. You are completely ignoring everything. I will say it again, I prefer to manually share slatepack messages. That said, why do you think TradeOgre has not implemented that flow, and only TradeOgre has enabled sharing slatepack message manually?
One would think that eventually more Exchanges will list Grin when there are more economic incentives to do it, God only knows when, but let’s take it as a valid statement. What we then should do is to make the current experience as pleasant as possible.
I am working on adding a tool to help users bypass this using Tor bridges. Hang there.
Look I have nothing against you @oryhp (or anyone really) I actually appreciate your constant contribution. I am not trying to divide. I want Grin to succeed.
Yes it makes sense, i kind of understand the protocol and still think grin will remain “dead” for the next few years. It just needs to fix existing issues and implement the right features for when inflation becomes low enough for people to speculate and hodl.
Agree with you, have noticed the same issue on my testnet exchange, that shouldn’t happen and fixing this should be a priority.
What am i ignoring? That’s what I’m saying yes and if you disagree with my examples i would appreciate if you would point out the mistakes in them (mistake in SRS flow that I’ve given? maybe a mistake in RSR flow?) so that i can see them and try to fix them. If nobody shows me, with some arguments, why I’m wrong and i can’t see it by myself then you can’t expect me to change my opinion. If you’re asking me why is tradeogre using SRS manual paste and not RSR then the answer is simple, they have no choice since grin++ doesn’t support RSR. To be fair i don’t mind if exchanges use SRS manual paste, that’s acceptable for me.
RSR makes most sense in shops etc and they can’t use it for the reasons I’ve already mentioned (same reasons hold for exchanges, but there the difference is not that big between SRS and RSR).
By saying that OC hijacked grin, that there was a lack of interest to create a good product, that core is not listening to the users and being overall passive aggressive leads to exactly that - division. I know you well enough to believe that your intentions are not bad, but sometimes we need to be careful with the words we choose to not create unnecessary conflicts. Let’s just focus on improving grin and hope that one day this beautiful project can be appreciated the way it deserves to be. On that day we will drink together and laugh at all the bumps we’ve had on the road
For what it’s worth, I feel the exact opposite. Only good things await Grin because the fundamentals are so strong.
One thing to keep in mind is that Grin is a trans-generational project. You shouldn’t compare 2020 to 2021, you should compare 2020 to 2030. The growth will not be linear but in fits and starts.
My area of interest is more on UX and products. I don’t know much about the core code. But I do want to learn. Sometimes I wonder if it could be beneficial for an expert in the core code to simply record a Zoom call with others where they walk through the codebase and explain very clearly how it all fits together and where things are located.
True, but this would move the ‘time’ issue to the one on call. E.g I could ask @Yeastplume to explain the flows of the wallet and node code and put that in an overview, picture or UML chart. But this would simply move the workload from me to him, while he already has a lot of work to do. Hence for now I keep it on my list of things of ‘nice to have’ if and when I have time.