2019-01-25 Meeting notes: Wallet discussion

Resources

• https://rchain.atlassian.net/wiki/spaces/CORE/pages/652640311/Wallet+proposal+2

Do we need more replay reinforcement?

• Understanding - Today on RChain you have to submit a deploy request with owner and timestamp of the deploy. And RChain enforces that this deploy can never be deployed again.

• QUESTION - Why do we need additional support in the wallet to prevent replay?

  • Challenge is imagining all scenarios that include withdrawal authorization.

    • IDEA require a signature for every transaction mitigates risk.

      • CON

        • Requires multiple, signed deploys to achieve multiple transactions

      • PRO

        • Mitigates the risk of replay

• Does the nonce provide enough support to prevent replay?

  • Dom and Artur say yes

  • Ovidiu to think about

  • Chris to add question to #cryptography

Periodic payments

• Concern about supporting periodic sending of REV (ex I want to pay every 30 days)

  • BLOCKER There is no concept of calendar time on the blockchain, so this is not a possibility

  • RISK running the contract multiple times is an attack vector because its replayed.

    • IDEA review code carefully to assure the replay is what you want.

  • CONCERN how do we store this type of contract to support periodic, desired replay

• Example - There is a rental contract that is not connected to the wallet. There is a separate send to this contract (“rent contract”) from the wallet to authorize payment.

  • RISK - delegating authority to your wallet

    • Mitigation idea - Don’t give away the wallet. Give away control to the wrapper of the wallet that authorizes the interaction (amount, cadence, etc) with the 3rd party

  • QUESTION - How do you set up a process where you delegate authority to your wallet and control what the other party does?

  • RISK - you could empty the wallet before withdrawal is made by 3rd party

Signature authority

• Any code you deploy is signed with your key. You can only execute code that’s been signed. Keys must match: wallet and code.

• You need authorization to withdraw. You do not need authentication to send.

• “lock guard”

Review of wallet proposal #2

• https://rchain.atlassian.net/wiki/spaces/CORE/pages/652640311/Wallet+proposal+2

• This came out of the proposal for relying on a map.

  • Greg argued for using the OCap approach over the map

  • Proposal #2 incorporates the OCap model

• Chris walked through definitions.

• IDEA - consider revisit of nomenclature if/when there are challenges with user adoption

• Discussion of order of operations

• QUESTION - What is the “lockbox”

  • Greg calls it witness to a value

  • Requires a primitive

  • Implementation of the REVWallet

  • Why do we need it if there is signature approval?

    • Lockbox supports multisig scenarios

    • Rholang needs a way to see the signature. Lockbox provides this capability.

    • This is the way you communicate who signed the transaction on the code requesting a transaction against the wallet.

  • QUESTION is the witness called to approve transactions?

    • This is an API or protocol detail related to authorization for the transactions

Bootstrap scenario

• Described on wallet proposal #2 page

• Chris walked through

• REQUIREMENT need to define the format of the REVWallet address

• QUESTION - Where do we store the record of the transaction for auditing?

  • REVWallet support the doing, but how do we store information to support audit?

  • IDEA we don’t store it in the contract or the tuplespace. Use a block explorer to audit (Kent)

    • Only look for this information in finalized blocks

    • Related to Mercury timeline, it may be more efficient to deliver a log to support audit rather than a block explorer

  • RISK we don’t have confirmation of agreement on this strategy with Greg

• QUESTION of how Alice gets her wallet; as a validator herself or via an intermediary validator

  • Observation that most ETH users rely on Etherscan rather than run their own nodes