Incorrect Keys imported using "Create Account" from Unicove about anchor HOT 6 OPEN

Thanks for the detailed report, I'm going to start looking into this.

Looking at the accounts you listed (there was a duplicate, I didn't see a 3rd if there was supposed to be one):

• https://waxblock.io/account/vortecs.gm#keys
• https://waxblock.io/account/scetrov.gm#keys

It also appears as if the active permission on each of them is different as well, which makes me question if the Ledger is being used for those too.

Can you confirm via Tools -> Manage Keys, that you cannot search and find any of the following:

PUB_K1_6tRgFW17dg7C71iT8gyX7fpethyahZYsHBSk9HTYiDD2myTsTo
PUB_K1_5hoh9L595rVDXah2faksUs8EAZH2QZGP4FHS3AUx7TRJka1z11
PUB_K1_4vUcV2LD9AYMradJPmAChqKZL59QT4yP1ivQSdMyTTSeioNfcY
PUB_K1_75cKvCLAuTzekEf4fEt3GtjxuhHX3qZfhsTrK4h35MGYmopvn5

I'm wondering if any of them got saved 🤔

from anchor.

Alright I just ran through the process a few times, and it looks like there is a bug here with how the account gets imported after its created. The creation seems to work properly, with the owner permission being associated to the Ledger's key, and the active permission being assigned to a newly generated key that's then saved in Anchor. So the creation itself seems fine.

However, when the account is imported, it's set as a "Ledger" type wallet - when in fact it should be a "Hot" type wallet using the key stored within Anchor.

Out of the dozen or so tests I ran against the service, all of the keys did get saved into Anchor and were all viewable in the Tools -> Manage Keys section. Check to see if that's the case with yours too.

If so, you can:

• Remove the "Ledger" version of these accounts through Manage Wallets
• Export the key(s) from Tools -> Manage Keys
• Import the account again using "Import via Private Key" and paste in the key you exported

That should import the accounts properly and make them usable.

I have a fix for this issue and will include it in a 1.3.11 release, which should be coming out shortly which is now available in the releases section.

from anchor.

Thanks Aaron,

Can you confirm via Tools -> Manage Keys, that you cannot search and find any of the following

I've searched for all four of those keys, using the "Search by Public Key" function but that doesn't show the keys (is search broken?). Visually searching however yields the following:

Additionally, I created sketrov.gm:

https://waxblock.io/account/sketrov.gm#keys

The owner key for sketrov.gm and scetrov.gm are one and the same as each other which is expected assuming they came from the same derivation path (i.e. 0'/0/0), although it doesn't explain why the owner key for vortecs.gm ended up as a different key.

As an additional twist, the active key for vortecs.gm is uses a different Derivation Path in Anchor:

I did do some spelunking around pulling public keys from my ledger to try and work out which index/derivation path was used by anchor and 22 may well have been the last one I tried, at the time I thought this was a "Fault is between keyboard and seat" error.

To close this off, I have:

1. Remove the "Ledger" version of these accounts through Manage Wallets.
2. Exported and backed up the active private keys via Manage Keys.
3. Imported all three as new accounts (scetrov.gm, sketrov.gm and vortecs.gm).
4. All three now have working active keys in Anchor Desktop \o/, I could still not pull the owner keys via Manage Wallets -> Import Account(s) -> Existing Account -> Load from Ledger
5. Upgraded to Anchor Desktop 1.3.11
6. I can now "Load from Ledger" via "Import Account(s)", and using index 0 or 22.

I ran through the process once again with 1.3.11 and can confirm that this defect is now fixed, I'm happy to close this issue.

from anchor.

Follow on questions:

1. Is there a testnet address for create[.]anchor[.]link / unicove; that is publicly accessible - or would I need to run these locally?
2. What's the purpose of the "Identity Request" signing prompt as part of create[.]anchor[.]link, does this call back to the Web UI to complete the process?

from anchor.

Glad to hear they were all there! We did try to make sure anytime a key was generated during the creation process it was automatically saved to storage, to ensure if anything went wrong they'd exist somewhere for recovery - but I feared maybe that failed somewhere along the way.

As for the vortecs.gm account, I am honestly not sure how it ended up using a different derivation path on that one account. By default it should always uses 44'/194'/0'/0/0 during creation and I am unaware of any step in the process where it would even let you change that. I'll have to do some investigating on that end...

For some answers to your questions:

Is there a testnet address for create[.]anchor[.]link / unicove; that is publicly accessible - or would I need to run these locally?

This URL should work for any network, it's chain agnostic and we run all testnets/mainnets through this one URL. It's just a payload delivery service for delivering messages between app <> wallet, regardless of which chain.

https://github.com/greymass/buoy-nodejs

What's the purpose of the "Identity Request" signing prompt as part of create[.]anchor[.]link, does this call back to the Web UI to complete the process?

The Identity Request is a pseudo-transaction that comes to the wallet without knowing which blockchain(s) or account(s) the user has loaded in their wallet. Anchor receives the request and prompts the user to select a blockchain + account pair, and then signs the pseudo-transaction using the selected account. The signature can then be used to verify the user controls that account.

The Identity Request does also contains a callback request to cb.anchor.link, which is then triggered after signing, to relay the blockchain, account, signature, and other information back to the web UI. The UI then uses this information to complete the login and establish a more permanent connection with the wallet through that service.

If you want to get into the details of how it all works, here's a few good starting points:

• https://github.com/greymass/anchor-link
• https://github.com/greymass/eosio-signing-request

from anchor.

Thanks Aaron,

I shall have a read up, I know a little about ESR just from being around the chains and seeing the messages in the console. In terms of the identity request, from a UX perspective I found it confusing to use - I honestly wasn't sure what I was supposed to do given I had multiple addresses already in Anchor.

Thanks again for your help :)

from anchor.