2019-01-18 Meeting notes: RChain wallet

Resources

• Previous meeting notes

• Mercury user stories

• Wallet ideas: https://docs.google.com/spreadsheets/d/1uN5hk6q008HpeEBoBq70OoEmYC5N4ybcajFb-_CmP6o/edit#gid=80188525

• https://rchain.atlassian.net/wiki/spaces/CORE/pages/651296816/Wallet

Controversial features

• History and auditing (Ed)

  • Consideration, could this be done with an ETH address?

• Which client platforms supported at launch time (Ed)

• Are multigs supported at launch time? (Ed)

• Design of how the contracts work? Locker idea (Ed)

• How Ethereum-friendly will we be? (lower priority, but related to adoption) (Ed)

  • Decisions needed

• How do we create a wallet for someone not in RChain (REV issuance or just joining w/o Phlo)? Are there any free transactions? How do you bootstrap new users? (Ovidiu, Ed)

  • Recommendation to first answer these questions for REV, and then think about other tokens

• Review naming convention (wallet, purse, account) https://rchain.atlassian.net/browse/RCHAIN-1529

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