Design Session 7.24.18

[gavinmcdermott]

Design Session Notes

Date: 7.24.18
People: @permaetheus @mslipper @gavinmcdermott

---

Synopsis

1. In the early phases, Grin protocol idiosyncrasies can make it challenging for non-technical people to use. Requirements around synchronous txs and static IPs for identification require people to consider things they typically don't have to (until we learn otherwise, we believe we'll abstract these into the wallet background). To engineers these additional pieces of overhead are fine. But for the broader user base, this is not; we're going to explore ways to keep things simple and functional.

2. The design team is getting ramped into a new, complex project, as a result we'll need input from the core team and community as to what we can and cannot do as we get into the wallet design.

3. We are starting to create an emerging set of design principles for a Grin client. Everything is open to feedback and will evolve over time, but they present a starting point to align around and guide initial technical and UI/UX decisions.

---

Specifics

Design Process and Feedback Loops

Our focus is on the Grin user experience—which extends beyond sending and receiving from the wallet. Generally speaking, it involves identifying and designing the right metaphors for the Grin wallet, and considerations for how an ecology of supporting, easy-to-use services can interface with the wallet.

We will lean on the Rust implementation and its accompanying API/RPC calls to create the first designs. But as we are not yet fully up to speed with what can and cannot be done, we'll post designs and considerations for the desired use case / experience, and ask for feedback from the core team and community.

Input from the Grin developers will be necessary to guide and constrain the design process based on what is available today, and what is coming down the pipeline in the protocol.

As we ask questions, we'll build the wallet around what is possible, and also create a roadmap for the wallet and possible supporting infrastructure/services that will be needed or possible as Grin evolves.

Emerging Client Design Principles

1. We believe that the wallet itself can be a small kernel where the base functionality is relatively straight forward (e.g.: send, receive, etc.). However, we are starting to imagine bindings for services to plug into the wallet that make more advanced things possible (see the offline relay idea below).

2. Because of the various points requiring interaction, system-level notifications will be an important part of the design process and end experience. People may have:
   -- transactions waiting for them to sign and broadcast
   -- parties looking for them to come online in order to construct and broadcast a transaction
   -- transactions in various states that require their attention

Trustless Transaction Relayers for Asynchronous, Offline Transactions

We talked about the challenge—for the average cryptocurrency user—of having a static, shareable IP address and the need to be online. As a result we thought it desirable to initially have an HTTP-accessible transaction relay that would enable asynchronous, offline transactions between two parties.

The model (sketched out in the above photos by @mslipper) involves creating a trustless transaction relayer that would pass encrypted, partially constructed transactions between the wallets of Alice and Bob using a secure communication channel established using Signal's X3DH protocol.

Some design considerations:

• In order to identify what transactions are for which Grin user, it would be nice to have Alice and Bob sign messages with their Grin keys. This would allow relayers to be simple key-value stores for grin wallets passing transactions back and forth.

• The creation of the secure channel is handled in the background of the wallet

---

Questions

• What are thoughts on the transaction relay service mentioned above?

• The Grin client currently does not expose an API/RPC call for signing blobs of data. I realize that we can use the Kprv to sign data, generally, but is this something that would be explicitly exposed in the future?
  ^^ The above question was generated from the tx relayer dialogue above.

• How does a user know when another wallet wants to send them a transaction?

We're trying to get a solid understanding of the expected/supported interaction model between online and offline wallets. We'll post a few scenario questions as they arise. A first is below:

• Scenario: Let's say Alice belong to a mining pool, and her receiving wallet has been offline for the last day while several transaction payouts to her have queued up. As it is currently designed, what is the interaction that happens between the paying wallet and Alice's wallet—who has the responsibility for what? E.g.: Does the wallet for the pool operator generate, sign, and store a bunch of partial tx bundles as they occur, etc.?

---

Community Engagement & Feedback

The goal is to create the best possible open/public forum for collecting feedback during this design process. Please let me know if this format works for you all, or if you have suggested changes / improvements.

I saw Github issues work well for IPFS community coordination, so I picked this as a collaborative starting point.

Also note that new links to session notes will always be posted in the Gitter channels for the community to follow.

Look forward to hearing your feedback and advancing things, and thank you in advance.

cc: @yeastplume, @quentinlesceller, @ignopeverell, @antiochp

[lehnberg]

Nice, thanks for sharing this!

Couple of points first:

• A valid Grin transaction can be constructed in whichever way, and can then successfully be broadcasted to the Grin blockchain via your node.
• A valid transaction can be initiated in which ever order. Doesn't matter whether it's Sender or Receiver who creates the slate, it can also be passed along in the sequence they please. Also see Reverse transaction building discussion on forum.
• The current grin wallet does not support partial transaction building, i.e. async transaction construction, it's expecting a synchronous response. This will be supported in the future.

---

As for your question:

Scenario: Let's say Alice belong to a mining pool, and her receiving wallet has been offline for the last day while several transaction payouts to her have queued up. As it is currently designed, what is the interaction that happens between the paying wallet and Alice's wallet—who has the responsibility for what? E.g.: Does the wallet for the pool operator generate, sign, and store a bunch of partial tx bundles as they occur, etc.?

@bladedoyle actually answered this question a few days ago re the currently running, in alpha, grin-pool (em mine):

...The pool will not want to credit users with the rewards until the block is mature, which will be 1440 blocks (~24 hours) I think. The pool will calculate your share using some fair algorithm - coming soon(tm), please share your ideas grin-pool/grin-pool#6 - and the pool will track that in the database. The pool will have a minimum payout amount to minimize tx fees. Once the minimum payout amount is reached the pool will attempt to pay to your wallet url on some schedule until it succeeds. Planned later features include other payment methods and the ability to log into the pool ui and request an immediate payout attempt.

So at the moment, this is handled via synch tx only, and asynch tx or partial tx slates are not used in practice. Yet. It's supported by the protocol, so you could build a wallet that handles partial tx and then broadcasts them once completed to the blockchain and they will be accepted just like any other tx.