2019-01-25 Meeting notes: Wallet discussion


Jan 25, 2019


  • @Kelly Foster

  • @Chris Boscolo

  • @Ovidiu Deac

  • @Artur Gajowy

  • @Dominik Zajkowski

  • @Former user (Deleted)

  • @Pawel Szulc

  • @Timm Schäuble

  • @Łukasz Gołębiewski


  • Discuss replay

  • Discuss nonce

  • Catch Ovidiu up

Discussion topics






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

Action items

@Chris Boscolo Ask the nonce question on #cryptography to get feedback from Kyle or Mike
@Ovidiu Deac consider over the weekend the conversation about periodic payments and replay prevention and the need for a block explorer related to auditing
@Artur Gajowy discuss with @Former user (Deleted) additional questions about the purpose and need for lockbox
@Kelly Foster make sure we capture requirement to define the format of the REVWallet address
@Chris Boscolo need to confirm Greg’s thoughts on how to audit.
@Kelly Foster validate need of a block explorer for Mercury