Feature request: derive public key from string address (for crypto operations) about go-algorand-sdk

[rotemh]

I guess it’s related to the encryption issue.
What is the actual need?
There is a reason for not exposing the public key and for using the checksummed address. Currently the main reason is to prevent errors but in the future the address may contain significantly more information (type / version / etc).

If there is a specific use case, we should consider implementing a similar functionality to sign and verify bytes but we should not expose the inner representation.

[EvanJRichard]

@rotemh This was logged at @JasonWeathersby's request - he might be able to provide more/better context, but he's working on a demo that involves:
taking some data
encrypting it and posting it in a Note field
reading that data back
and either verifying it with just a public key or decrypting it using the private key

[JasonWeathersby]

So the verifier should not have to have access to the private key. If I want to verify signed bytes, we have provided a function that does this with a public key. The problem is I do not see a way of getting the public key to verify the signed notes.

[rotemh]

I don't see a reason to expose the public key. It's the Algorand system and user should use their addresses, which is has a 1-1 mapping to their public key.

[fanyinghao]

I might have a case. When I have a key pair, I would like to use this public key to derive another public key and address. So that I don't need to generate a new key pair for the extended addresses. For example, the exchange company might have a wallet with a private key. The public key could be exposed so that it can compute a lot of address to the client for the deposit usage. And the exchange could use the one private key to sign all the transfer tx for collecting all deposits.
I have a similarity solution like GenPublicChild : https://github.com/blocktree/go-owcdrivers/blob/master/owkeychain/extendedkey.go

[rotemh]

@fanyinghao Thank you for the comment. I agree with the proposed use case but even then I believe that exposing the public key is not the preferable solution. The solution I would go for, which already exist in kmd, is to add the option to derive accounts (a pair of an algorand address and the associated sk) given a master sk.

[EvanJRichard]

Closing per above discussion.