Item
Notes
Resources
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)
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