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

[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]

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]

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.