Let's create the ultimate Grin Wallet experience! (Grin++ UX/UI)

How about the following approach. Let me call it “Colloquial Grin”.

  1. We write a very down to earth description of ツ. What ツ is and what ツ is not. How does ツ differ from other coins etc. The principal rule here is it must be written from perspective of completely non-technical person. Not for bitcoiner or other coin enthusiast, just regular person who knows nothing about crypto.
  2. We “illustrate” the concepts from (1) by defining usage scenarios, again from perspective of regular user who has zero technical knowledge.
  3. Using community fund, we could sponsor bounties for graphic designers to turn the scenarios from (2) into little comic books, just to make it more visual.
  4. In the future we could also use Community Fund to hire animators from fiverr to turn what has been done in (3) into videos. The rule here would be to make it language independent so that we could re-use this material and translate into more languages.

My motivation here is, the tech that makes ツ work is pretty complicated. Improving UX would help a lot, but at the same time I believe that no matter how nice we make the slatepack exchange experience, for someone who does not know why slatepack is necessary it would still be confusing.

1 Like

What is Grin (ツ)?

Grin is a privacy-preserving digital currency built openly by people distributed all over the world and launched in January 2019. Grin is community driven effort, which means that Grin is not controlled by any company, foundation or individual. Its purpose is to serve as digital cash.

Grin a light implementation of a protocol called Mimblewimble. Mimblewimble requires only about 10% as much data storage as the Bitcoin network. This makes Mimblewimble highly scalable for storing the blockchain, significantly faster and less centralized. Furthermore, the nature of the protocol allows for private transactions that are highly anonymous.

Grin is designed for the decades to come, not just for tomorrow. To be used by anyone, anywhere.

What is not Grin (ツ)?

Grin is not Bitcoin, nor Bitcoin 2.0, Grin is Grin.

How does ツ differ from other coins?

Grin requires interaction between parties involved in the process of building a transaction. Well, addresses in Grin are used for two things, one, to encrypt the transaction information and two, to determine the Tor Urls of the parties involved in a transaction; this Tor Url is used to establish a secure and anonymous communication.

Grin scales mostly with the number of users and minimally with the number of transactions. Past transactional data can be pruned, making grin drastically lightweight compared to other blockchains.

6 Likes

Nice! I think it would also be good to mention the advantages of ツ fair distribution for an average person, any experts on that here ready to add their few words?

I would add the following:

Grin is not another commercial project. It is built by a community for the community. It has no CEO and no investors.

Great initiative @davidtavarez.
I agree with many of the suggestions above. I do think we can simplify the naming of the transaction flow while still showing clearly where we are in the process and where signatures are made.
To give some examples:
We can use:

  1. Propose transaction
  2. Sign/Accept transaction
  3. Finalize/broadcast transaction.

Now here is what I think is important for users is to show in a very simple way where we are in the process, so either 1/3, 2/3, 3/3, or use a double check mark just like most messaging APPs, where the color indicates if that step is finished. E.g. you have two grey check-marks on step 1/3, 1 green check mark the first signature in step 2/3, and you have 2 green checkmarks for the second signature in step 3/3 when the transaction is broadcasted.

By having checkmarks, we will still show if someone signed, just in a language that any user can understand and relate to. We could alternatively use two grey keys that turn green upon signing, but even there I think the user would much rather see two check-marks that are 1) both grey, 2) one green for signing, and 3) Two green check-marks for a double signed and broadcasted transaction.
What I like about this is that the checkmarks perfectly correspond to the number of signatures, so it is also respecting and showing the user how many signatures are there which is unique part of Grin that we should not hide but embrace @oryhp.

1 Like

Send : No need to explain :stuck_out_tongue:
Accept : grin users needs to understand that when using an interactive protocol you are not just receiving you are accepting to receive, you literally give your consent (except if your wallet is online :face_with_raised_eyebrow: )
Complete : Complete seems to be a more common word to me than Finalize

what if we replace slatepack message by grin message ?
we would have grin address replacing slatepack address, and grin message replacing slatepack message

to Summarize :

a user is sending a grin message to another user
and the other user is accepting that grin message

Where does your 10% come from? I think that should be 25% as argued in https://forum.grin.mw/t/scalability-vs-privacy-chart

Also, no summary of Grin is complete without mentioning its purely linear 1 Grin per second forever emission.

My guess it depends on whether you include the witness data or not in the calculation.
When excluding it you would end up with 25%, when including it you get something like 10% if i am not mistaken. I am more inclined to say 25% since you do not need the witness data for old Bitcoin transactions that have already spend their funds. So Grin has 25% of the Bitoin transaction size for historic transactions (400 bytes for Bitcoin, 100 bytes for Grin).

Yes, that’s exactly what it is. If you have a transaction you have signed that may or may not ever be published, you can resolve this “unknown” state by spending the same input - which prevents play attacks.

Agree. Grin is different because of its interactivity - I’m also of the opinion that we should take advantage of that instead of making a hybrid transaction building out of it. A hybrid doesn’t bring the benefits of ITX nor does it achieve NITX so you miss on the good parts of both world.

It’s probably safe to say that most of us believe the naming could be much better. There was a long discussion on the naming of rounds here Transaction Round Naming Challenge but we have yet to reach a conclusion.

I’m glad people want to improve this part, it’s something I was hoping more people would be interested in for a long time. I believe we could move the transaction building process to a higher level, but this requires us to think about safe-cancel, one-time addresses and possibly other things as well - to prevent creating a flow that looks good today, but when you want to make it safe it hold grounds. This is also the reason why I asked Gene if he would be interested in improving the wallet experience. We need to figure out what we would consider good though and for this we need discussions like this.

Offer/acceptance/deal

“Sending” can be perceived as a completed action on its own, whereas “offer” implies the next step - acceptance. Just my thoughts that may be biased ))

2 Likes

I really like this one, If I understand @oryhp correctly, the process doesn’t have the sender signature til the 3rd “finalize” step;

so it is like drafting the contract, sending it to the second party for review, they agree, and the drafter signs and seals.

Maybe propose/review/deal

Yeah, the finalize step is the “sign” step for the person that started the transaction. I really liked antioch’s steps here Transaction Round Naming Challenge - #52 by antioch

// SRS flow
send <addr> <amount> -o slate1.gtx       /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx         /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx             /* outputs 2/2 signed
// RSR flow
receive <addr> <amount> -o slate1.gtx    /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx         /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx             /* outputs 2/2 signed

It either:

  1. creates an empty “slate” or a “deal/offer” if we prefer to call it that or
  2. signs an existing slate passed through -i (input) to produce a new slate and save it to file -o (output).

If the output is not defined, the output slate is printed to stdout. I’m not sure if the above format is good, but we likely want to have small commands that are composable and do one thing only because these make integrations simpler and add flexibility to integrations - the alternative could be unix-like behaviour with expecting the input through stdin and doing cat slate1.gtx | sign > slate2.gtx but I’m not sure how this works on other operating systems.

Note that there is no broadcast in the above flow. This is because we want to clearly separate the signing from broadcasting. The two can happen even on different devices e.g. hardware wallet signs, but doesn’t broadcast because it doesn’t have a connection to external world e.g. a node.

Since signing of the last signature is often accompanied with a broadcast, an alias command composition sign -i slate2.gtx -o tx.gtx && broadcast tx.gtx would be available.

1 Like

Nice, yeah maybe the simplest verbally and represented by some kind of gui, would just be an old-fashioned contract with two signature slots.

Contract, sign, sign

Thinkibg about Adobe PDF forms; both parties sign the blanks, the initiator (like leasing office or hr) then has the form to process at its leisure (broadcast).

I think that could be representated easily graphically and cognitively

1 Like

I’m not familiar with Adobe Forms, but this contract, sign, sign idea has been floating around for quite some time e.g. Possible interactive transaction flow which was later implemented as a testnet exchange example (though it supported only rust wallet due to the RSR deposits).

I do agree that the word contract is scary though. On the plus side, it makes people more aware that signing in Grin matters for both sides.

1 Like

Sweet thanks, thinking about it this way really helped me understand the process. I have been thinking sender was signing on the first round.

I can understand some people’s reservation with the use of “contract,” But similarly it has a connotation of security and finality.

All things considered I would go with proposal, sign, sign, and then still with some kind of graphical interface to “hide” The slate pack altogether, as suggested in the linked thread

Self-descriptive UI (SRS flow)

I decided to draw a bit. I think these screens could describe better the process and maybe it feels natural for Grin. I think this flow is more descriptive and clear than trying to do everything under the hood, also I think this could also be implemented on the CLI easly.

This is the first step, to fill the receiver address, the amount and the strategy.


*(The Receiver’s address is not mandatory but recommended)

Now, as is defined in the RFC015, if an address is provided, we try to establish a connection via Tor. A happy path would look like this:

If something fails, we should manually complete the transaction, maybe like this:


From here the Sender can either Cancel the transaction or try to complete the transaction manually.

Now the user can import the Transaction agreement signed by Receiver.

The Transaction is now Complete.

Auto-Finalize (?) Flag

If we want to go with this flow, we might need to add an extra flag to the response from the Receiver. This can an optional configuration, true by default. This also will help if we want to have multiple addresses listening at the same time. I will go in detail later.

SRS flowchart

A simple SRS flow would look like this.

6 Likes

Receiver-Sender-Receiver flow

Invoice transactions are built much the same way, but with a different order where the receiver initiates the transaction by asking for a certain amount of coins.

  1. A slatepack address is provided by the sender (optional).
  2. Receiver creates an invoice, requesting to be paid the specified amount. In practice he starts building the transaction slate and writes a pre-determined amount into it.
  3. Sender decrypts the slate to confirm the amount he is about to pay, and adds his own data and signature.
  4. Receiver finalizes the transaction building process and posts it to the chain.

You can see this flow in action here: Possible interactive transaction flow

Receiver

The first step is to create an invoice, which again, it is an unsigned transaction agreement too since the sender must agree on the amount to send.

Now, the receiver can share the invoice with the payer or sender. From here, the receiver can either cancel the invoice or continue to collect the payment.

To collect the payment the receiver just need to import the agreement signed by the sender and sign it.

If everything goes well, the payment is collected by the receiver.

Sender

For the sender, things are more easy, the sender just need to accept, add signature and send back the transaction agreement.

RSR flowchart

A simple RSR flow would look like this.

5 Likes

NOTE: If someone wants to add/edit something to the draws, you can download the mockups from here: misc/ – Keybase.pub and install Pencil to modify it.

1 Like

Thanks for taking the time and creating these mocks!
SRS:

  • in step 1 I would probably put strategy under some advanced section (so hide it away from 99% of the users who don’t need this) and only if u click it you can see strategy and in the future probably some other settings as well. Should the input list be displayed when the default strategy is selected?
  • not sure whether we will ever support manual confirmations but if we do, it might be that Sending Unsigned Transaction Agreement went through, but the response from receiver’s wallet is Waiting for user's manual acceptance
  • how does the sender import the receiver’s signed transaction? Does he have a global import or does he click on the related transaction (from some tx list) and then click continue tx or smth?
  • in the flow does Is Address a valid Grin Address mean that it also needs to be reachable through TOR?

RSR:

  • I would probably have RSR go through TOR and business would create a memo committing to the content of the payment (explained a bit more here)

You can ignore the memo/manual confirmations if we don’t go with it

1 Like

Let’s think about when we use cash to pay for a coffee… what do I do? first, I open my wallet to get a $5 bill to pay for the coffee, then I realize I’m poor so I have no money in my wallet, then in a desperate move I check my pockets and I find an old bill (thank God :raised_hands:), I take the bill from my pocket, the cashier double-checks the bill (with all reasons), accepts it, and keeps the bill.

What did we do? Interact with each other, and if we want to emulate that, wouldn’t it be nice if could “establish the communication” with the cashier in the safest way possible?

Interactivity… well, what can I say about interactivity that hasn’t been said before? I personally have a mixed feeling when it comes to the Interactivity discussion… but if we agree on that one of the Grin’s purposes is to serve as digital cash, interactivity is actually a core characteristic of all transactions based on cash. So, for the sake of this experiment I’m going to assume that Grin is like Cash and then I’m going to (re)imagine the flow from a Receiver perspective.

How should receiving grin look like?

Grin uses Tor to establish a communication between Sender and Receiver, something like: Channel?Tunnel? Avenue? Route? Canal?

I will discard the word “Channel” since it can be confused with Payment Channels, which allow users to make multiple transactions without commiting all of the transactions to the blockchain. I personally like: Route, because we can say something like this then:

Grin uses Addresses to encrypt the transaction information and to establish a secure route via the Tor network, where Sender and Receiver can anonymously communicate with each other.

And let’s be honest, that’s a really cool feature! With that in mind I can make the next assumptions:

  • Addresses could be disposable.
  • Reusing an address should be the exception, not the rule.
  • Sometimes I would like to be able to run several “listeners” or “encrypted routes” or addresses at the same time.

It doesn’t make sense not to generate a new address every time I receive some grin, but I get if you don’t want to. We could even generate a new one after every send, but it would be a big mess. We want to provide users with flexibility without making things confusing.

Now we can think in these terms: Disposable addresses and Reusable addresses.

Disposable means that I can not use that address anymore after completing the receiving process because it is a one-time use address. Reusable means that I can use this address at any moment. For example, If I’m mining in two different pools, I can create two addresses, one for one pool and another one for another pool and I could start an encrypted route for each address at the same time.

But, we also want, one, to keep the compatibility for current users, and second, we want to keep things simple for those who don’t care about these things. In this case we can have a Default address, this address is always listening by default, and then it can be replaced manually by a new one.

“Ok, David, but what about the Dust?” you might ask; Jameson Lopp recently wrote an article explaining the Bitcoin Dust Attack, I will cite him for the sake of giving context.

What Is Dust?

Bitcoin dust refers to UTXOs with tiny values that are so small that they are economically unspendable. That is, it costs more (in transaction fees) to spend than the value of the UTXOs. It’s possible to end up with dust in your wallet due to poor UTXO management. It’s also possible to receive dust deposits that you did not request. This is because you can’t stop someone from sending funds to a valid bitcoin address and every bitcoin address that has ever received funds is publicly viewable on the blockchain.

He also said that “while it’s technically possible it’s incredibly unlikely.”, I also believe that but anyways we can solve this in Grin by:

  • Manually deactivating a listener and generating a new address.
  • Disabling the “auto finalize” behavior.
  • Rejecting transactions below an amount.

This can be also solved in a non-interactive scheme, but the point that I would like to make is that it can also be easily solved with the interactivity.

Do we want wallets to automatically generate a hierarchical tree-like structure of private/public key pairs? Probably, yes.

Do we need on-chain bookkeeping? I’m not sure what pains we are solving with that.

Do we want all enabled addresses to be listening automatically? I don’t think so.

Do we want any of our wallet to be automatically on? I’m not sure, maybe I just want to transact off-line.

I feel it worth experimenting with this. I think about this as an opt-in feature, people are not forced to make use of these capabilities but they could at any moment.

Screens

Initially the screen could look like this
addresses_001

One could manage the have extra addresses like this.
addresses_002

7 Likes

I like it, except that I am favour of putting reusable adresses under an account.
E.g

  • m/0/0/1’/1’ bet1
  • m/0/0/1’/2 bet2

In this way even with 1000 bet adresses, the user only has to remember to ditch that 1 account branch. Even without online bookkeeping reasonably safe.