2019-01-18 Meeting notes: RChain wallet

Date

Jan 18, 2019

Participants

  • @Kelly Foster

  • @Ovidiu Deac

  • @Former user (Deleted)

  • @Former user (Deleted)

  • @Dan Connolly (invited)

  • @Chris Boscolo

  • @Lucius Meredith

  • @Adam Szkoda

  • @Artur Gajowy

  • @Dominik Zajkowski

  • @Kayvan Kazeminejad

  • @Former user (Deleted)

  • @Lilia Rusu

  • @Ned Robinson

  • @Pawel Szulc

  • @Sebastian Bach

  • @Timm Schäuble

  • @Tomáš Virtus

  • @Łukasz Gołębiewski

Goals

  • Capture critical questions about wallet features requirements and as time allows make decisions

Discussion topics

Item

Notes

Item

Notes

Resources

Controversial features

 

REV issuance

  • Requirement to support ETH-style address at launch of Mercury

    • Can we support this requirement and then make a step to move to a design that is different than an ETH-style address?

      • DECISION - this is an acceptable solution (Greg)

    • Do we have to transact REV with an ETH-style address after launch?

      • No, although this would support ease of adoption for users used to ETH-style transactions

      • DECISION - Do support ETH-style address for REV issuance and beyond, and we can support something else

Definition of ETH-style address

  • Truncated hash of the public key

  • Will ETH users be able to provide their public key, receive a truncated hash, and then use it?

  • I can send REV to an ETH-style address

Out of the box (Mercury)

 

  • With the address you can interact with the wallet contract

    • Idea that the registry implementation can support this

      • Today registry does not support ETH-style address

      • Today registry maps name to contract using different crypto than ETH.

      • QUESTION - do we change registry implementation to support ETH-style?

History and auditing

  • Various levels of audibility

    • 1st level - REV holders need to be able to verify transactions in and out of my wallet to myself, my transaction partner, and any third party

    • 2nd level - A random 3rd party can look at someone else’s wallet and verify transactions

      • Idea there are different classes of wallet classifications and that some wallets support this 2nd level auditability,

        • DECISION we do need to support different classes of wallets

  • RISK having differing levels of auditability, may impact trust in the platform

    • Discussion that this isn’t about trust in the platform and rather trust in the implementation of a type of wallet and it’s implementation

  • Different types of wallets

    • wallet A - wallet contract supports full audit by all

      • DECISION - this is a Mercury requirement

      • IDEA Auditable wallet is a wrapper around the wallet + purse to keep the transaction history.

        • Need to clearly communicate and support that once the purse goes in, that is does not come out

      • The auditable wallet comes with the ability to request a transaction log

        • IDEA - this is a method call that requires having the name and not the wallet primary address

    • wallet B - wallet contract may not support full audit by all, provides obscurity

      • wallet B does not prevent wallet A from functioning

      • DECISION - This is this not a Mercury requirement?

  • Are there any blockers to providing complete auditability when using purses?

    • RISK Concern that allowing for splitting purses will allow users to obscure activity

      • IDEA mitigate by not allowing users access to purses. Abstract by giving users an account, and keeping the purses below the user’s access

      • IDEA don’t worry about users having access to purses, because once a purse goes into a wallet, it doesn’t come out

  • Happy path to Mercury provides an auditable wallet AND does not ensure all transactions are auditable

Action items

Meeting attendees, if you heard something different during today’s conversation, please make a note here.

Decisions