Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Item

Notes

Resources

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

  • 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

Action items

  •  Need pseudo code for showing the unforgeable name is the lookup into the REVWallet table
  •  Chris Boscolo Discuss capabilities and ambient authority of message.sender approach with Kent

...