Add support for the PUB_K1 public key format to v1/chain/get_fio_names

[aaroncox]

It'd be very helpful of the FIO specific API endpoints that deal with public keys also support the PUB_K1 format of keys, which is what eosjs v20+ deals with internally for the most part. The endpoint I ran into where this was unsupported was the /v1/chain/get_fio_names endpoint, though there may be others that accept public keys as inputs that this would also help support.

For example, this does not currently work:

curl https://fiotestnet.greymass.com/v1/chain/get_fio_names -d '{"fio_public_key":"PUB_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di"}'

I discovered the v1 history plugin endpoints already support both, likely because the conversion is happening. Examples as follows.

Using a PUB_K1 public key:

curl https://fiotestnet.greymass.com/v1/history/get_key_accounts -d '{"public_key":"PUB_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di"}'

Using a FIO public key:

curl https://fiotestnet.greymass.com/v1/history/get_key_accounts -d '{"public_key":"FIO6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgakgqCeb"}'

[0xCasey]

The following API endpoints could be modified to support this:

• get_fio_balance
• get_pending_fio_requests
• get_sent_fio_requests
• get_obt_data

However, the signing and the responses will still be in the FIO format.

[0xCasey]

@aaroncox would this type of fix be beneficial to BPs despite the response data being in the FIO format?

[aaroncox]

I believe so. At that point it might require some validation logic to be changed (if it exists), but will at least allow results to be returned to the client.

[0xCasey]

PR Submitted

[ericbutz]

Resolved by #64

[cc32d9]

You can't just replace FIO prefix with PUB_K1 because they are encoding the public key differently, You can see the difference here:

https://github.com/EOSIO/eosjs/blob/master/src/eosjs-numeric.ts#L272

[cc32d9]

here's a better example in c++ https://github.com/EOSIO/abieos/blob/master/src/crypto.cpp#L134

[lukestokes]

Someone floated the idea of just adding a prefix since we still have to use this as a human-readable address people can send to. Is that doable? Something like FIO_PUB_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di?

[aaroncox]

It should be. Another option would be to use FIO_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di (without the PUB portion)... though you could realistically do either way. The various SDKs would just need updated to support it.

The code @cc32d9 mentioned would need updated, eosjs/fiojs would need updated in the same way, and eosio-core would all have to be updated. It's not a comprehensive list, but those are a few areas I immediately recognize that would need updates.

[lukestokes]

Yeah, I like FIO_KY vs. FIO_PUB_K1. I could think of it this way: "PUB_..." is a generic public key. "FIO_..." is a specific public key.