Should we disallow nil argument in `set-key`?

[helins]

Currently, set-key accepts a nil argument for turning a user account into an actor.

For security reason, I suggest disallowing that and creating a new dedicated and explicit function such as become-actor. The chance of passing a wrong key and getting locked out is quite minimal, you would have to get it wrong the right way. However, the chance of being a bit careless and doing (set-key (:kw-with-typo x)) ;; nil instead of key is not low at all, it will happen for sure.

Even become-actor might not be optimal. We should design both functions to make sure that you can't do anything bad by mistake. It is tricky having a single one-liner that can lock you out of all your assets completely.

[mikera]

I'm not sure about this. set-key is already incredibly dangerous if you pass a value that you don't have a private key for!

I'm also disinclined to add new Core functions if we can avoid it. Suggested workaround is a user-defined safe-set-key function?

[helins]

It's just that we have to envision this kind of scenario:

(def foo {:my-key 0x0101...})

(set-key (foo :mykey))

And boom, you are locked-out of your account for ever and nothing that be done, because of a simple typo, that will happen to some people for sure. On the other hand, for setting to the wrong public key (for which you don't have the corresponding private one), your typo would have to point to another 32-byte blob ; a lot less common.

That's why I am strongly advising about some null safety here as default.

[mikera]

We could include a safe-set-key defined in core.con Convex Lisp that performs a non-nil check, though it does seem oddly specific. I'm generally unwilling to create extra Core runtime functions without a very strong reason.

[helins]

Yes it does not deserve a Core function and can be implemented in Convex. We can leave it open and ask for more opinions if you remain unconvinced.