Cannot create a wallet using the account public key returned by the API.

[Melraidin]

Just checking...

• This is a cardano-wallet bug.
• I am using the latest cardano-wallet release.
• I am using the correct cardano-node version for that release of cardano-wallet.

Version

v2024-11-18 (git revision: 0000000000000000000000000000000000000000)

Platform

Ubuntu 22.04.4 LTS

Installation method

Binary from GitHub release page

Network configuration

Preview testnet

Context

API docs: https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/postWallet

Third-party API docs: https://bump.sh/hal-cardano-foundation/doc/cardano-wallet-backend/operation/operation-postwallet#operation-postwallet-body-application-json-shelley-from-xpub

Description

Steps to Reproduce

1. Retrieve an extended account public key from https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/getAccountKey:

curl 'http://localhost:8090/wallets/1f8[...]/keys?format=extended' | jq

The response is a 404 containing:

{
  "code": "not_found",
  "message": "I couldn't find the requested endpoint. If the endpoint contains path parameters, please ensure they are well-formed, otherwise I won't be able to route them correctly."
}

2. Repeat step 1 retrieving the account's extended public key adding v2 to the path:

curl 'http://localhost:8090/v2/wallets/1f8[...]/keys?format=extended' | jq

The key returned will look like acct_xvk[...], just as the docs describe in the 200 Ok response.

3. Attempt to restore a wallet using this extended account public key using https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/postWallet:

curl -H"Content-Type: application/json" -XPOST 'http://localhost:8090/wallets' --data '{"name": "test 1", "account_public_key": "acct_vk[...]"}' | jq

The response is a 404 containing:

{
  "code": "not_found",
  "message": "I couldn't find the requested endpoint. If the endpoint contains path parameters, please ensure they are well-formed, otherwise I won't be able to route them correctly."
}

4. Repeat the restore operation adding v2 to the path:

curl -H"Content-Type: application/json" -XPOST 'http://localhost:8090/v2/wallets' --data '{"name": "test 1", "account_public_key": "acct_vk[...]"}' | jq

The response is a 400 containing:

{
  "code": "bad_request",
  "message": "Error in $['account_public_key']: Invalid account public key: expecting a hex-encoded value that is 64 bytes in length."
}

5. Repeat the restore operation, adding v2 to the path and using the account_public_key shown in the request example here: https://bump.sh/hal-cardano-foundation/doc/cardano-wallet-backend/operation/operation-postwallet#operation-postwallet-body-application-json-shelley-from-xpub

curl -H"Content-Type: application/json" -XPOST 'http://localhost:8090/v2/wallets' --data '{"name": "test 1", "account_public_key": "1423856bc91c49e928f6f30f4e8d665d53eb4ab6028bd0ac971809d514c92db11423856bc91c49e928f6f30f4e8d665d53eb4ab6028bd0ac971809d514c92db1"}' | jq

The response shows the wallet is successfully restored.

Expected behavior

I expected that the extended account public key retrieved from the API would be the correct form to use to restore the same wallet.

Actual behavior

The extended account public key retrieved from the API is in the documented form for the response but is not in the correct form to restore the wallet. It seems the term extended account public key is being used to refer to two different things or that the docs should not be using this term for one of these two endpoints.

It does appear that a wallet may be restored using the sample data from some other (linked above) docs but this only begs the question of how to retrieve this value for my own wallet.

[abailly]

Thanks for reporting the issue @Melraidin. I agree this discrepancy is annoying, and to be honest it's not the only place where the output of the API is not directly consumable by the API: I just found out it was also the case for mint/burn of assets, as one input asset names in human readable form but they are output hex-encoded.

I am not sure we are going to change the behaviour at this stage, but we can definitely improve the documentation and provide users with instructions on how to convert the account extended key's output into the right format.

[Melraidin]

I understand the hesitation to change the API's output. That makes sense. But please do provide instructions on how to convert from the response format to the format the API can consume to restore the wallet later. I'm currently at a loss as to how to do so.

If it helps and you're able to provide instructions here I could submit a PR to update the docs once I have my head around the process.

Thanks for your help with this.

[abailly]

It's actually pretty simple and you're definitely right this should be properly documented. You need to find the bech32 binary and then do:

curl http://mac-mini:22110/v2/wallets/2269611a3c10b219b0d38d74b004c298b76d16a9/keys\?format=extended | jq -r . | bech32

[abailly]

A PR would be much appreciated if you are willing and able to do it 🙏

[paweljakubas]

hi, This is the flow that should work:

1. Let's assume we have mnemonic wallet. We can call https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/getAccountKey
   (here we need extended account public key as we need derivation capability, ie. query parameter format=extended)

2. Then we can delete the wallet via https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/deleteWallet

3. Then we can create wallet from the extend account public key from point 1 via https://cardano-foundation.github.io/cardano-wallet/api/edge/#operation/postWallet
   (option shelley from xpub). This wallet is able to follow its resources (ie. addresses) but it is not able to sign tx as it is lacking extended private key being the parent (ie. root_xsk, or acct_xsk)