Possible interactive transaction flow

1

I’ve been trying to come up with an interactive flow which i would personally feel confident using. There are a few improvements that i think we can make to the transaction building process. Whatever you will see in the videos below is not implemented behind the scenes (no node/wallet api calls), it’s just a wishful thinking UX. The UX presented here won’t please everyone as we each have our own ideas of what’s the right path forward. I would not like this to become a debate about nitx vs interactive transactions as this isn’t the point of this post. This post tries to share some ideas about the interactive flow and any constructive criticism on why this is bad or how we can make it better is welcome.
Here are some of the things which i believe should be thought about:

  1. Perhaps we should minimize the number of times the user sees a slatepack message. This is because it is unreadable data and therefore doesn’t give any information about the transaction whatsoever. Looking at the slatepack is unavoidable in some cases, so the user should still recognize its format.
  2. Unlike many in the community, i would like to have a choice to reject incoming coins that i don’t expect or don’t want to receive. I’m not completely familiar with the payment proofs but my understanding is that in automated receive you would sign any message. Is this the case? If yes, does this make the “message” field in the payment proof worthless because it was auto-signed?
  3. I’m going to think a bit ahead now but i think it’s important. If our signatures are tied to real life identity then what does this signature mean? Are these signatures legally binding?

Intro

I’ll try to present a flow that (assuming the things work this way, i don’t know the details) i think is easy enough for people to learn. The transaction building process is called a transaction contract which has some information about the contract (amount, sender, receiver, message, signatures…). The user has 2 options:

  1. create contract - used to create a new transaction contract. The user can choose the transaction type (payment or invoice), inputs the amount, other participant’s address and a message (what the transaction is about).
  2. open contract - open a window where the user can paste a transaction contract and view its content. If the party agrees with the contract they can sign it and send the signed contract to the other party if any party still has not signed the contract. The last signature automatically sends the transaction on the chain.

Below are some examples based on these definitions.

Exchange Deposit

Here the exchange creates an invoice transaction contract, gives it to the user who then opens the contract, verifies its content and signs it. The user then gives the signed transaction contract to the exchange which signs it and broadcasts the transaction.
Note: withdraw has completely the same flow except that instead of an invoice transaction type we are dealing with the payment transaction type.

Exchange Deposit flow video.

Create Transaction Contract

The person starting the transaction creates a transaction contract as can be seen in the video below.

Create Transaction Contract flow video.

P.S: i don’t think copy should be automated like it is in the video to avoid overriding clipboard content of the user unless manually requested.

3 Likes
2

No, we do not sign arbitrary messages in payment proofs.

The idea of hiding the slatepack messages from the UI is a really good one. I like the way that looks. The “contract” wording is too complex and formal for most people who are just thinking about sending money, not entering into contracts.

2 Likes
3

Not sure i understand, what happens if i create a payment to you and include something in the message field? Will auto-receive deny it?

Thanks for the comment, i picked the contract word because it’s easy to present to people the connection with the signatures

1 Like
4

The message field isn’t part of the payment proof. It doesn’t really serve a purpose at all. It was only ever a half-baked concept, and tbh, I thought we had removed it already.

Edit: You’ll notice there’s no mention of a “message” at all in the RFC: Payment Proofs - Grin Documentation

1 Like
5

Agree, contract sounds too scary for frequent use

1 Like
6

I forgot the current payment proof doesn’t include message, recently I’ve read tromps RSR payment proof rfc which commits to a memo so i got confused

7

Is offer - accept better than contract - sign?