What is the most critical problem of Grin?

41

Then tomorrow we can :champagne: again, and who knows maybe again the day after. Curious to see if a new low will be found or the old bottom will be cemented. Time will tell for our yellow time coin :clock4:.

42

I’ve heard the same words many many times before. These coins do not exist anymore.

43

Time will tell. But I am biased I admit.
I look at the intrinsic value of a project not the price. Even if Grin’s price would be 0 I would believe in those properties. The supply of 1 Grin/second creates inflation in the early years as we all know and knew when the project started. When a bottom has been found remains a guess for anyone. For me the emission rate is a property which I think actually adds a lot of intrinsic value to the project on the long run, no matter what the effect on the price in the short term price wise.
:thinking: Maybe one of the biggest problems of Grin is the lack of understanding and as such appreciation of the fundamentals by the masses. In any case, also that is a problem solved by :timer_clock:

4 Likes
44

No one sees the point in looking into this, because no one sees the problem that grin solves. People have no motivation. Because grin is complex and does not grow.

And they agree on the only conclusion - why do I need it?

This is a fundamental problem. Because we are approaching the stage when cryptocurrency is bought by people who believe that the whole world was created for them, do you understand? What they are shown, they will buy. They do not need to be taught, they need to be managed, because they do not know any other way.

Just look at Shiba Inu. This shit is up 500 million percent. Madness, stupidity and recklessness. We could get that kind of capz in grin. And the situation would have been radically different… But why look for something when you can subscribe to Elon Musk on Twitter and speculate on prices. Then withdraw this money with tax and buy a BMW by giving the money back to corporations. Mmm what a wonderful life. After all, now you have a BMW and a new girl who will show her breasts and say that you are her dream. What kind of slave can resist such temptations?

Forget the early days of bitcoin… the early evangelists and people who got curiosity learning and developing it.

Now this will not happen, because society has changed. The wealth generated by the rise of Bitcoin and other cryptocurrencies is centralized and channeled into speculation by a limited group of people to generate even more profits. It’s all just a giant bubble and nothing more…

They are just funny freaks who hide behind Bitcoin and talk of a change in the global monetary system, and on the other hand, make a bubble, collecting huge communities of sheep on social media and encouraging them to buy what they have invested in earlier and not realizing that it will not work in the future… Haha.

This is how those against whom we have rebelled see us. Who are these funny guys? Okay, let them play for a while, we will support this bubble, tax them, and then, when the time comes to leave, we will do it before they… Thus, forever undermining faith in cryptocurrency as a really working tool against the monopoly of banks.

Is Grin difficult? Yes, we can say that it is difficult, like everything else, until you figure it out.

Are there any stable working wallets? No. All they needed was money from the fund. They got them and left. 250K got one of them, right? People still say that it doesn’t work… Just think about it.

But, okay… Hard but you can use it. But again, people have no motivation or reason to use it.

3 Likes
45

It would be much appreciated if you didn’t have such an insulting tone. Grin has a very different transacting model and one that needs to be thought out much more carefully than in other cryptocurrencies. It’s incredibly easy to develop a wallet for other projects, but much harder to do it for Grin because of its multisig nature. At least not until we have figured all things out. It’s new and it takes time, but we’ll get there eventually. There’s nothing wrong with receiving funds. Bitcoin developers are also getting paid. It’s kind of hard to feed your family without an income and if it’s possible to enable high quality developers that are excited about Grin to dedicate their full time to it, it’s a win-win.

4 Likes
46

With the growth of crypto more and more such people come in this space but yeah, the ratio between such people and people who don’t understand this technology lowers over time which is expected. There are also more and more interesting projects, so it’s harder to bring these enthusiasts here

Are you referring to UX or understanding of how it works? I think the UX could be improved a lot, understanding of mw takes around the same amount of time as bitcoin or even less since mw has simpler design imo

The one who got 250k got them because it was very important to fix the issue and the council appreciated his help, not to mention his previous (for free full node implementation which actually spotted the bug) contributions

1 Like
47

It is hard but it is also not a valid excuse to not develop better. The current situation is the wallet is extremely unstable as compared to other crypto and least user-friendly among all. This also leads to only, say 2 or 3, exchanges supporting Grin.

48

which parts do you consider to be unstable and how do you think wallets could become more user friendly?

1 Like
49

Who’s making an excuse for what? also, to “develop better” does not mean anything at all. And yes, building something new is always hard; in order to succeed you must operate under assumptions and test those assumptions, learn, improve and test over and over again. That’s how things work. Even if you take a project like Bitcoin which may be way more established, nobody knows what could be in the future. I think that people are not fully aware of how dangerous is for them to have a public ledger with full transparency of transactions, amounts and balances. I hope people reject that, but I don’t know what will happen in the future, I can just assume.

Today I am convinced that Grin trying to appeal Bitcoin users was not a good move, we tried to use a suit or dress that does not fit Grin. This is my personal opinion. It is clear for me today, not in the past when some decisions were made. Now, we’re moving forward and we have the experience. And that’s how you make better decisions, therefore, now we can do better.

It’s time to embrace Grin.

6 Likes
50

Sorry, I just plainly disagree. Sending a transaction is simple. If the receiver is ofline, you just post the slatepack in a messaging APP. What is hard about that?

51

To my own suprise I am even contemplating 4 steps for RSRS for daily payments (meaning users are in physical contact).
In the end my conclusion is that the number of steps is not relevant at all as long as there are the right transport protocols the user will not know nor care.

1 Like
52

Not hard, but multiple steps that need to be understood and memorized:

First know how to create a slatepack message, then

  1. Identify and copy slatepack message
  2. Switch to messenger app
    2.1) find the right tab/contact if needed
  3. Paste message
  4. Send

Know how to use response and finalize tx.

That’s harder than, let’s say, holding your watch over a terminal for a second, but of course it is possible for users to adapt to such a process. However, I think users nowadays have pretty high standards for usability and integration.

Apple Cash is using a 4-step process that is shown in this video:

They have the benefit of being able to place a pay button directly under the chat of course. An equivalent Grin tx would have more individual interactions than Apple Cash, because their tx method is non-interactive and Grin has additional steps. If Apple would integrate Grin as a backend for Apple Cash, their demo video for the same scenario would have to be much longer than the one above, because they would at least have to explain how to respond to an incoming slatepack message. They also would have to explain what the other party needs to do, because this is necessary for finalizing a tx.

Mimblewimble steps and SRS vs. RSR are not complicated, once you wrapped your head around it, but it is hard to explain to people in a way that is quickly understood by everyone. I think it is also important to note, that in reality, a Grin tx is not just 3 steps, but a longer list of smaller interactions for the user. The 4 steps that are shown in the video are only the first S part of SRS.

1 Like
53

This is how i see RSR vs RSRS:

imagine you’re trying to make amazon use grin. Buying from amazon is just like buying from a store, so using the invoice flow makes sense, example of how it could work:

  1. user adds a new payment method (basically just states his grin address, this address includes a way to reach you - currently that’s TOR address)
  2. you fill up your basket and click “checkout” (or complete purchase or whatever phrase they’re using)
  3. you get notification on mobile of an incoming invoice, you check it (memo, amount, receiver) and click “pay”
  4. you wait for confirmations

That’s how user experience should work if they’re using TOR for example.

RSR

  1. you click “checkout”, amazon creates new transaction contract (step1 slatepack) whose memo has contents of your basket and sends it to you
  2. in your mobile app you click “pay”, this signs the contract and sends signed contract (step2 slatepack) to amazon
  3. amazon receives signed contract, signs it and broadcasts it

RSRS

  1. you click “checkout”, amazon creates an offer for transaction contract creation (i don’t know if this is how you imagine first step of RSRS to be, but i’m asuming that smth like step0 slatepack is used, so that the SRS code can be reused - correct me if i’m wrong) whose memo has contents of your basket and sends it to you
  2. in your mobile app you click “pay” but you actually don’t sign the contract since it doesn’t exist, instead you create a new transaction contract (step1 slatepack) and send it to amazon
  3. amazon verifies that the contract matches the state of when you clicked “checkout” and then signs the contract and sends it to you (step2 slatepack)
  4. your mobile app receives the slatepack, secretly signs it and broadcasts (without you knowing that - well you can show notifications etc but it seems a little weird to me)

Downsides of RSRS:

  • when you click “pay” in your mobile app you don’t actually sign anything, it’s just a “trick” because we wanted to have an easier implementation
  • the one broadcasting the transaction is the buyer, which is bad imo. Yes, there can be attacks (even when safe-cancel is implemented) if the user doesn’t understand contract/sign/sign procedure, but he will need to understand it in any case since SRS can also be attacked, just a little more work is needed. Now why is it bad if the user is the one who broadcasts in this situation? because it’s easier to make broadcasting work on the amazon side (they would understand mw, have high availability, is not moving/relying on phone battery etc) than to rely that each buyer will not lose connection before he broadcasts or to rebroadcast it if it got dropped in the dandelion phase. Also if amazon finalizes they know more about the state of the transaction (eg. it was already broadcasted) and they can easily rebroadcast it because they can automate that part
  • if one of the parties can’t use transport protocol (eg. tor) then you have 4 steps instead of 3, which is annoying. I also don’t think that a flow should be used based on where on earth the transacting parties are (eg. have physical contact or are on the opposite side of the world) but instead a flow should be used if it describes well what parties are trying to do. So if someone is saying “please pay me X for Y” then that’s an invoice flow, random sends (eg. sending some money to someone we know) or donations are payment flow

I generally like code reuse, i just don’t think the downsides outweigh the benefits in this case

3 Likes
54

It kills the logical steps of “create contract, sign sign”. This is the same with SRS and RSR. RSRS kills this symmetry. If you have SRS then at step2 the receiver will confirm they want X coins which can be thought of as “I accept a payment of X coins” while fulfiling it at the same time. The real benefit is preserving symmetry in the transaction building flow from either direction. I can’t really think of a single case where you’d want RSRS tbh. Unless I’m missing something obvious, having RSRS adds complexity without really solving anything.

55

If we get the hardware wallet support soon, user will hopefully become included in the signing step.

1 Like
56

Not sure if I even should call it RSRS, or just SRS where the offer/contract is provided in a QR code.

E.g.

  1. you pay in a store, the shop owner asks for payment using a QR code on his phone. The user checks the contract and clicks pay. Transaction happens over tor or using audio waves. The point is, the sender gets the power over finalising and signing in the last step, which could be automatic as long as the contract matches the one when the sender clicked send.
    The innitial QR code contains information on the transfer protocol to use, such as try over tor, if no responce within 2 seconds, switch to audio protocol.

  2. You scan a qr code with you phone on Amazon when checking out. Same as above, only this time the transfer protocols are, try over tor. If no response, switch to sending over a chat APP such as Signal, predefined by the user when creating his account. In an ideal future, there would be a button in Signal or widget linking to your wallet. Again, ideally one click should suffice confirming you commit to the contract, but finalizing is done by the sender in the back, so basically it is SRS.

Not sure if we need this. Maybe for easier payment proofs? But I am more and more getting convinced we should focus on the transfer protols and integration with existing APPs (or copies of them, e.g. Singnal modified for wallet integration, we could even call it Hedwig) and not focus on reducing steps since in the future interactive crypto and payments will become more and more common. The trick is to avoid making these steps manual where possible. E.g. confirming a contract only once in the payment process and only asking to reconfirm if the commitment to the contract is longer than 1 week ago.

The QR code I am talling about should be another layer around slatepacks, so a (encrypted) json that contains all the settings and ordered preferences on how to transfer the transaction. So first try transfer method A), if that does not work, try method B etc.) The purpose is that in this way it can be much easier avoided that the user has to manually copy and paste slatepacks, reducing steps for the user. And if all these smart transaction protocols fail, the transaction defaults again to copy pasting slatepacks.

2 Likes
57

This a valid point and indeed a reason to prefer RSR over (R)SRS🤔. It is just that I like the sender to be signing last and as such controlling the transaction

58

Exactly this. This is why I believe it doesn’t bring anything new because it really is SRS with an additional step at the beginning. I don’t think payment proofs would get any easier because of this. It’s important to distinguish automatization of the slatepack processing from automatization of the transport. For instance Tor, QR, NFC, copy/pasting slatepacks or audio waves is a transport protocol - it handles data transfering but doesn’t really know anything about the data. So the transfer can be automated e.g. audio waves, but NFC and QR still require some manual work (as does copy/paste) because you have to scan images, but it’s work that people are used to. I agree transporting slatepacks would best be done behind the scenes if possible and for that many transport protocols would ideally be available. I’m not convinced about automatization of slatepack processing (specifically, blindly signing amount) though.

1 Like
59

I think I agree with you, about seperating the transfer protocol from the cryptographic steps. After thinking about it more, actually if we would ever user RSRS, all should be automated except the last step. This would be the time to ask the user to Sign/confirm the contract. One good reason for (R)SRS, is the receiver telling how to most efficiently reach his wallet. E.g. in a store you do not want to ask the sender to enter a settings menu and chose the transfer protocol, so this additional first step of scanning a QRQ code from the receiver just has the purpose of telling the protocol, which indeed can also be done in RSR. I just thought there where more attack issues with RSR and more difficulty with payment proofs. If those problems are not there anymore, RSR would ofcourse be better than (R)SRS.

60

The person that is contacted (the one at step2) already has to share their grin address because the slatepack needs to be encrypted for them. It happens that in Tor the grin address is enough to also derive the “address” in the Tor space. Perhaps a more flexible way than introducing new steps for that would be to define a scheme for grin address sharing e.g. <scheme_version>:<protocol>:<grin_address>:<metadata> e.g. 1:qr:grin1asbasdf: in case of no metadata. This may very well be a bad thing to do, I’m just improvising.