Wallet

Owned by Kelly Foster
Last updated: Jan 25, 2019 by Chris Boscolo

Purpose of this page

The goal of this page is to consolidate documents and Jira tickets related to wallets for the purpose of supporting the team learning about this features, status of implementation, and open questions prior to the working session Jan. 23-25.

Action requested Please edit this page as needed to add or correct information and create a list of issues to address during the working session.

Mercury requirements

Please see features.md for user stories related to wallets. These are the priority and focal point for our work.

Relevant wiki pages

Other resources

Google sheet with recommendations and ideas from Dan and Ed

Relevant Jira issues 

key summary type created priority status assignee
Refresh

Open questions and ideas

Add your questions and ideas below

Jan. 23 charge to the wallet team

  • Bootstrap issue Provide recommendation for how to handle the bootstrap problem where someone doesn't have REV and wants to set up a wallet
  • Purse security
    • Concern - code in Dan's demo needs revision to assure accuracy of reporting correctly
    • RCHAIN-644 - Getting issue details... STATUS RCHAIN-2559
    • Miller recently discussed a formal spec for purses in his SFBW talk: 
  • Auditing
    • Be able to see a transaction log of all REV spent
  • Unforgeable name as the nonce
    • Purpose of the nonce is to prevent replay
    • Is this the right approach?
      • Concern that this will work with parallelism
      • Greg: Unforgeable names should be the nonce in all cases
    • See Ovidiu's write up Locker contract
  • Ticket created for replay issue  RCHAIN-2866 - Getting issue details... STATUS . No further action required today.


Recommendation and discussion following Jan. 23 session

Posted by Chris Boscolo in Discord

I wanted to give a mini recap of some decisions we made that are a pretty significant departure from the current purse/wallet paradigms that we have been working on.

We decide that for Rev on RChain would use a map to represent owner -> Rev account balance. This would be handled via the Rev Smart contract. With this approach there are a few simplifications to how we use and track Rev:

1. All account balances can be queried obtained via this map

2. All transactions (Rev Transfers) happen via this smart contract making auditing very straight-forward

3. owner map keys can either be a representation of their public key pair OR hash of an unforgeable name held by a multisig smart contract

4. Users can receive Rev simply by creating a EC keypair and sharing the pubkey-hash with the entity sending it.

5. Deployments can be signed with a key in this map to pay for the execution of the deployed code. (Handled by the Capser contract.) We believe this simplification to wallets will make it easier to build wallet/deployment tools as well as shrinking the surface area of code that needs to be audited for security flaws.

Discussion

ThemeQuestionAskerDiscussion
ConcurrencyWill this design create a bottleneck in terms of performance, because it would reduce the concurrency that would otherwise occur? Even for the same owner sending lots Rev transactions, we want to allow concurrency if possible.EdJoshy - Unless some fancy commutativity check is implemented, this will impose a total ordering over all rev transactions
ConcurrencyI've let it sink in for a little while, and I think my reaction is slightly sad to lose the concurrency model, but ultimately glad that decisions were made and we're moving forward. I'm wondering whether we could write the map-based rev contract to allow moving tokens in and out of the central map contract to and from purses/utxos. Wheels are turning in my head, and I'd be interested in writing some rholang if it sounds useful.JoshyChris - The dev team talked about using a concurrent map to preserve concurrency
Concurrency
If unforgeable names can also be used as map keys (I see no benefit from hashing them) then maybe the interesting security properties are preserved.
It does seem to impose a total order on transactions, but since we have postponed namespaces/sharding, maybe that's doesn't make much difference.
Dan
ContractHow large might this contract grow in terms of the memory and storage footprint it will need?EdJoshy -The contract will grow linearly in the number of keypairs used
ContractWill the whole contract need to fit in memory at one time?EdJoshy -This is probably not a good place to be optimizing storage, but I'm not really sure
ConsensusDoes the whole REV contract state need to achieve consensus as one block, or can consensus occur in sub-sections?EdJoshy -yes. consensus over the etire state every block. This means the dag will likely contain a chain-of-rev transactions e) If anything this will save space over the purse model by not having separate contracts for every rev wallet. Side question: does RChain store a complete tuplespace poststate in every block?
Consensus If as one block, does this imply most block sizes will be large?EdJoshy -If anything this will save space over the purse model by not having separate contracts for every rev wallet. Side question: does RChain store a complete tuplespace poststate in every block?
HistoryWill it keep its own on-chain history, or is that some DHT stored on-chain on the side, or derived by some other client or indexing service crawling through the block history?EdJoshy -history will be stored on-chain
How long will REV transaction history be kept?(edited)
EdJoshy -recent history will necessarily be kep back until the most recent finalized block. Probably validators will keep older history around much longer than that.
HistoryWhere will a wallet dApp retrieve the history of the user’s Rev sends, receives, and fees?Ed
HistoryHow will RChain systems architecture separate what the database industry used to call OLTP, OLAP, and near real-time analytics?Ed
History
One of the central requirement questions about the auditability of Revs is whether RChain needs to store Rev transaction history forever, or just for some amount of time. For the sake of argument, let’s say RChain needs to store it for years… I’ve been thinking a bit tonight about how a Rev history mechanism could be kept separate from the Rev balance map (as described above a few hours ago), so the primary Rev comm events are not slowed down. In some other domains, such as electric grid operations with which I’m familiar, transactional operational and historian systems are separated so the operational demands are never unnecessarily blocked. In those systems the historian software can buffer transaction logs and catch up with its writes to the history database after peak loads, except in extreme cases. Old history (after a few years if there is no business need to retain it) can be archived or purged. In the case of RChain, a separate historian mechanism (i.e., one or more contracts to keep history) for Rev could be created and receive from the main Rev contract a journal of each payment transaction (Alice pays Bob, or Alice pays fees to run code). The Rev Historian contract(s) would then write (journal) to disk at every block consensus. That set of “write to history” protocols could be contract-specific (e.g. only for Revs) and would be aware of block time, and clique depth could be computed. An index could be written on top of the historian to support queries, explorers, etc.
Let’s pose the following questions: How would one conduct an audit of Rev controlled in normal (single public key) wallet contract? How would one conduct an audit of the total amount of Rev? I know that in the more modern world with DHTs, systems can now scale more linearly. However, in the current RChain architecture, the burdens of tuplespace memory and storage are very big issues. So, if we can remove some of the burden of history off the tuplespace, it might have a better chance of scaling.
EdChris - It seems unnecessary to store in the tuplespace. We could use a block explorer approach





Maybe another way to look at this is that we're rolling WalletCheck into the mint/rev contract and expanding it to serve as a hitching post after Genesis.
But we can't move purses around independently... So not quite the same.
How does an entry keyed by name get created? I guess a key holder does a special kind of send...
I suppose this allows economic "side chains" that can use full concurrency
Oh... A key shouldn't be necessary to get in the map with a zero balance.
Maybe bundle0 should be used as the hashing function

Chris - an you expand on: Maybe bundle0 should be used as the hashing function

Dan - 

bundle0 is a one-way function to something that's good for comparison and not much else
I think it's cheaper to compute than a secure hash
And it's 100% guaranteed collision-proof
MapThe map tracks REV balance, but it's not the way to communicate your wallet addressChris

Ovidiu - For each wallet containing REV there is an entry in the map

Dan - Shared example of a contract https://github.com/Agoric/PlaygroundVat/blob/master/examples/contract/makeMint.js#L20


Who has access to update the map?Ovidiu

Chris - The REV contract. This replaces a component of the current MakeMint strategy

Dan - Need to assure you can do atomic updates.


Hardware wallet1. Does the current progress on the wallets make it easier to determine whether hardware wallets will be supported during the launch of Mercury? What are the expectations from the dev team? Mr. TEd -  The key management and signing capabilities of HW wallets are pretty distinct from the wallet dApp's interaction with the nodes. If the design of the transactions to be signed is similar to Ethereum (and @dckc: has done work on this), then HW wallet integration should be relatively straightforward. A wallet dApp prepares a transaction and sends it (or a hash of it) to the HW wallet (through a HW wallet-specific software integration) to be signed. Once signed, the wallet dApp sends it to the blockchain node. Note that the features.md list https://github.com/rchain/rchain/blob/dev/docs/features.md does not include integration with a HW wallet as a requirement for Mercury launch, and I agree with that. Integration with HW wallet can be added later by the co-op or a 3rd party wallet dApp provider.
Hardware wallet2. In case HW wallets are not supported, what would the process be like if you used multiple addresses containing RHOCS on a single HW wallet? Will a mnomic phrase be supported which will generate all underlying addresses? Maybe this is a point which could be clarified in the FAQ as well (support for mnomic phrases or not). Mr. T

Ed - HD wallets, whether HW or SW, can generate lots of key-pairs. These key-pairs can be regenerated by other wallets or standalone tools, such as https://iancoleman.io/bip39/ . HD wallets are currently not on the Mercury features list, and I agree with that. Similar to the above, 3rd party wallet providers can supply HD capabilities.


Dan - No, you can't get rev at Genesis without the private key of an Ethernet account with RHOC

Hardware wallet3. Would it technically be possible to sign a message to proof ownership of an address, instead of exposing the private key /mnomic phrase of a HW wallet? In this case the HW wallet wouldn't be exposed. Or is the private key necessary to create the JSON files/ wallets?Mr. T

Ed - Once a wallet dApp has integration with the particular HW wallet product, the private key does not need to leave the HW wallet. I expect that multiple wallet dApps will emerge after Mercury launch with various capabilities. The co-op supplied wallet must at a minimum support the import and use of a private key.


Mr. T - 

Cheers, thanks for the answers. #3 was meant specifically during Rev issuance. My question was if it's technically possible to generate a wallet with REVS at genesis without knowing the private key of the original RHOC address. As in, if a user can sign a specific message from the address with RHOCS (showing they control the private keys), a wallet with the REVS will be generated. I guess, this would be more like a token swap, instead of an "issuance".
Using 3rd party tools to generate the pairs from question #2 is indeed fair enough. Still, maybe a good point to add to the FAQ.
Keyspublic keys vs addresses, and ecrecoverDan

Chris - the entry in a map is always a hash of the public key. The public key is always provided at deployment. This is still TBD as part of implementation conversation.

Chris - we don't need ecrecover (like ETH). 

Chris - Discussion about which curve to use (ETH or ed...). We would still need the claim process at genesis to claim REV.

Recommendation and discussion following Jan. 24 session

After further discussion, there was some a lot of concern that the above Map based approach would not leverage the concurrent capabilities of the RChain platform. So we spent the day walking through how to satisfy the Wallet requirements using the original OCAP Purse composition.

Wallet proposal (Note: we decided to rename terms such that "wallet" is not used for on-chain components)

Next steps

  • REV contract 
    • Two parts need to be done in Scala
    • Need a Rholang primitive to support unforgeable name lock box (this can be added as a 2nd step if needed)
      • TO DO - add picture and description of lock box idea
  • Jan. 24 session - Team to sort out next steps for other aspects of implementation and sort out next steps
    • Block explorer (question)