Open Pitasi opened 2 years ago
How does the front get those different addresses ? From Keplr ?
isn't it possible to find them in the backend side, from a master address ?
Apparently the chain addresses are derivated from the public key
https://github.com/confio/cosmos-hd-key-derivation-spec#reuse-of-the-cosmos-hub-path-in-cosmos
So that means we could have a single endpoint that takes the public key and returns all the balances for all the derivated accounts. That would be nice I think.
That's a nice article, thanks, helped me shed some light on the derivation :D
The most interesting thing is the "hardened" derivation (in m / 44' / 118' / 0' / 0 / address_index
you see 44 and 118 are marked with a '
). See here https://wiki.trezor.io/Hardened_and_non-hardened_derivation.
Not sure if I'm reading this wrong but it seems that even if we do have the master public key (or any derived public key) we cannot derive children that are hardened:
With non-hardened keys [...] You can also derive public child keys from a public parent key
With hardened child keys, you cannot prove that a child public key is linked to a parent public key.
Even if it was possible, another important sentence:
This means that extended public keys must be treated more carefully than regular public keys.
I have a feeling that users might perceive this as lowering their privacy. If users only give us addresses there's not much we can do. If users give us entire public keys, they are sharing more informations than they did before.
I think you are right about hardened vs non-hardened, but here we don't want to create children public keys, we just want to derive a chain address from the public key, and I think it's not the same thing.
About user's security concern, afaik it's transparent for them: Keplr already gives access to the user's public key, here is the proof where I run this snippet in app.emeris.com
console :
You can see the public key in the output, and it's the same whatever the chain passed to getKey
.
So instead of passing the chain address, the front could give us the public key, and we do all the derivations according to the chains we support.
@Pitasi I did some tests today, and I can assert that it's possible to generate bech32 addresses from key.address
, which is apparently the raw address derivated from key.pubKey
(key
is the JS object returned by await keplr.getKey('cosmoshub')
)
This test passes:
pb := []byte{
// a key.address
177, 243, 71, 181, 77, 57, 172, 212, 184, 184, 174, 87, 29, 214, 159, 253, 244, 92, 248, 194,
}
adr, err := bech32.ConvertAndEncode("cosmos", pb)
require.NoError(t, err)
// the related cosmos adr in keplr
assert.Equal(t, "cosmos1k8e50d2d8xkdfw9c4et3m45llh69e7xzw6uzga", adr)
adr, err = bech32.ConvertAndEncode("osmo", pb)
require.NoError(t, err)
// the related omosis adr in keplr
assert.Equal(t, "osmo1k8e50d2d8xkdfw9c4et3m45llh69e7xzxp0j70", adr)
pub key derivation to generate the raw address : https://github.com/cosmos/cosmjs/blob/main/packages/amino/src/addresses.ts
Frontend is currently polling these endpoints:
https://api.emeris.com/v1/account/addr1/unbondingdelegations
https://api.emeris.com/v1/account/addr1/stakingbalances
https://api.emeris.com/v1/account/addr1/balance
but it does for many different addrs, since different chains have different derivation paths.
Let's expose some new endpoints that takes a list of addresses as a param so frontend can make a single requests and gather all data it needs!
DoD
[ ] add a new
/account/balance?address=ADDR1&address=ADDR2
endpoint that takes multiple addresses and returns an object like this:/account/stakingbalances?address=ADDR1&address=ADDR2
endpoint, similar to the previous one/account/unbondingdelegations?address=ADDR1&address=ADDR2
endpoint, similar to the previous one