Resources

• Wallet proposal #2

• RChain wallets, lockers, and paying for deployment

• Locker contract

Wallet proposal #2

• Discussion about the proposal

• RISK Bottleneck - Logging in map creates a bottleneck because one contract receives all the messages

  • All proposals we’ve discussed so far have this issue.

• Mechanics of the authentication step

  • We need this to work for both multi- and single-sig situations

  • QUESTION Will the locker approach support this?

    • DECISION to try this in code

  • QUESTION What of the unforgeable name is the lookup into the REVWallet table?

    • Yes, this is how it will work (Dan)

• Bootstrapping the wallet

  • Bootstrap example in Wallet proposal #2 assumes Bob got REV at genesis

• Discussion about https://github.com/rchain/rchain/pull/2138
  

Walk through of slides

• Dan walked through slides (link above)

• Deployment slide: how is replay prevented?

  • Use private channel to receive the proxy. Signature authenticates you are the right person to receive the proxy.

• Discussion about the confused deputy problem

• Discussion about message.sender signing over a transaction that creates a risk for the associated public key

  • See deployment slide (#5)

• Discussion about nonce

  • CONCERN where to store it?

  • Rholang’s parallelism makes using nonce hard

Walk through of Locker contract

• Discussion of the diagram

• Discussion about confused deputy attack vector

Next steps

• Achieved common understanding

• Nonce - need to get comfortable that the deploy timestamp + public key (scalable) is the way to go OR introduce actual nonce value (scales poorly)

• Need to continue discussion about the lockbox and the confused deputy attack vector

• Discuss capabilities and ambient authority of message.sender approach with Kent