Reverse transaction building

Development and Technical Discussion
1

As you may know, a Grin transaction is currently constructed the following way:

  1. S initiates
  2. S -> R
  3. R -> S
  4. S finalizes
  5. S broadcasts to blockchain

Where S is Sender and R is Receiver.

Consider the following reversed transaction construct:

  1. R initiates
  2. R -> S
  3. S -> R
  4. R finalizes
  5. R broadcasts to blockchain

This was prompted by thinking about commerce use cases. Say that Alice is buying a pair of socks for 100 grins in an online shop. Today, it would fall on Alice (her wallet, to be precise) to do the majority of the work, like initiating a transaction, waiting for a response from the merchant, and then broadcasting the transaction.

Conversely, with the reversed structure, the merchant first initiates the transaction (ā€œsend me 100 grinsā€, essentially having the message ready for Alice to interact with as part of the checkout process on the merchant website) and then as soon as Aliceā€™s wallet has responded to the merchant, her obligations are complete. And then itā€™s up to the merchant to broadcast.

Taking this a step further, if the merchant is using a third party processing service to do all the heavy lifting for this, this processor would likely be quite good at handling these interactions reliably, at scale, compared to Alice and her personal wallet which may be of varying quality (and an unknown to the merchant). This processor could also be doing neat things such as cut through on transactions across many different merchants before they are being broadcasted.

Questions:

  • Q1: Is this reversed format a valid Grin transaction?
  • Q2: Could this format be supported on the protocol level today without changes?
  • Q3: Does it make sense / Is it useful?
2 Likes
2
  1. Yes
  2. Yes
  3. Thatā€™s quite likely. The interaction is very similar to the bitcoin payment protocol that was designed to avoid phishing among others. So from a usability standpoint in a merchant scenario, it would already be better than bitcoin addresses.
2 Likes
3

Letā€™s take this one more step towards practical usage.

Say Iā€™m in a self-checkout space with several checkout stations and no usable wireless anything. How does the payment request come to my device? No Apple-style centralized location and identity layers welcome. Oh, and my device probably already leaks most of its identity and some private key bits by its variations in its RF and light emissions.

Fairly sure Iā€™d have to ā€œaimā€ my wallet at the payment request.
QR? NFC? Narrow-band IR or LIFI?

What amount of bytes are needed to be communicated?

4

Iā€™ve only seen self-checkouts at my regular supermarket, Dutch Albert Heijn. Your privacy tends to get lost there because they make you scan your ā€œbonus-cardā€ in order to get certain discounts. Of course, having a bonus-card means you do regular business, so we would assume you have a Grin lightning channel funded for your grocery shopping.

What amount of bytes are needed to be communicated?

A channel update would be a new spend of a 2-of-2 output, in which you need to communicate your single new output and its associated rangeproof, so letā€™s say about 3/4 KB.
It would also be instant, so the supermarket need not worry about customers waiting for the required number of on-chain confirmations clogging up the space:-)

5

Could step 2 be over qr code entirely? How much data is it?

Iā€™m still fuzzy on the details on if this is going to work day one or not

6

Could step 2 be over qr code entirely? How much data is it?

Sure; a pair of commitments and some additional data takes on the order of a 100 bytes, which fits easily in a QR.

7

The next advance in QR artwork is to just an image of the item, logo, place or person itself.
Itā€™s possible to instate the GRIN logo art for instance as the ā€˜barcodeā€™ that links to github, dev site, grinbox or wallet.

If you can photograph it then you can pull up and pay the invoice in GRINā€¦ Art is the answer.

1 Like