Unlocked assets but unable to withdraw

1

Hello, I have a keychain with multiple sub-identities. All of the identities are working fine (I am able to ssh to a node, logmein, scan QR code (using the old mobile app), check balance, make transfers, sign the transaction, all is well) except 1 specific identity gives errors:

  1. when logging in to the terminal on any node, after scanning the QR code and being logged in, I type “balance” and received below error:

==========================================================
✅ SUCCESS:  Welcome 1UDCXDf787onwKinN6H3mGhVaVdkS9ihr 🙏
Welcome!🦄 Access to local security storage not granted.
You'll need to authenticate with GRIDNETToken🔑 on commit.
1UDCXDf787onwKinN6H3mGhVaVdkS9ihr:/ $ balance                                   
[Balance]: 71.640 GNC                                                           
Which accounts for 71640000000000003978 GBUs 💰
[GridScript VM]: Pre-Authentication Modes Failed.                               
Attempting FAPI Authentication Modes
1UDCXDf787onwKinN6H3mGhVaVdkS9ihr:/ $
==========================================================
  1. Then if I proceed to make a transaction, when I sign it with mobile app it gives below error:
==========================================================

█▄▄▄▄▄▄▄█▄▄▄▄███▄█▄▄▄▄▄████▄██▄▄▄█▄▄▄▄██▄▄█▄▄███▄▄█ 
⚠Warning: An INVALID QRIntent-Response received! :-( 
No valid QRIntent-Response received. Aborting transaction..
1UDCXDf787onwKinN6H3mGhVaVdkS9ihr:/ $

==========================================================

  1. Using the new mobile wallet, and loading the keychain into it, I am able to cycle through my different sub-identites, and sync to see their balance fine. However when I reach this specific key, it keeps “Syncing” forever and eventually Hexxi says she cannot connect to nodes.

  2. Note: The API is showing the correct balance

Identity causing the issue: 1UDCXDf787onwKinN6H3mGhVaVdkS9ihr

Thanks

2

This ticket is now assigned and pending evaluation, please allow for 24-48hours for additional information.

@Maximus next time you paste from Terminal kindly use a code-block.

3

@Maximus

  • have you tried sending assets through the mobile app from that particular sub-identity?
  • are other sub-identities working as expected? Identities derived from the very same Master Private Key?
  • so basically you are toggling through sub-identities and one of them does not work in the DUI/SSH , correct?
1 Like
4

That identity doesn’t sync in the app at all . So i cant send via app.
I dont have subidentities, each key is one identity only .
Some keys sync on the app instantly and log on the terminal normally. And some keys never sync and gives the attached errors when logging on terminal.
Worthy to say , that this issue started with the realease of the new app. Before that same keys were syncing normally on old app version

5

If the identity does not sync in the app, there is no way for the app to deliver a valid response to a QR Intent requested by DUI / SSH.

:warning:Basically: the identity corresponding to the private key which you’ve entered in the mobile app - it does not exist.

What is happening - you are attempting to use (in DUI/SSH Identity_X) but your mobile app -it provides a response (to the QR Intent) which is signed with an invalid private key corresponding to Identity_Y.

Hence, the error you are getting. To verify - check the wallet address corresponding to the private key you’ve entered in the mobile app, as seen by the mobile app. I bet it does not correspond to the wallet address you’re seeing in the DUI/SSH.

In your case Identity_X is 1UDCXDf787onwKinN6H3mGhVaVdkS9ihr (your desired identity) which you see in DUI/SSH.

But, the mobile app surely is displaying Identity_Y which is something different. Please confirm.

That would also explain why you’re unable to sync. Identity_Y simply does not exist.

As of now, by default, the mobile app employs ‘HD keys’ by default, meaning each identity generated by the mobile app truly is a sub-identity.

The mobile app no longer employs ‘flat’ keys. Where a private key corresponds to just a single address and/or identity.

By default, the app would use a sub-identity at index 0.

I presume you mean some Master Private Keys - the one you paste into the uppermost Secret field of the mobile is, is that correct?

Worry not, nothing is ever lost.

You’ve been around for quite some time, so it seems - let me ask - how have you exported these troublesome private keys and how are you importing these back into the mobile app? (QR Code / text ?)

Any discrepancy in between of how these keys were exported and/or between how these are imported back into the mobile app?

Let me explain - the keychain GridScript command has options allowing one to export a ‘flat’ key indeed.

Such a flat key has no sub-identities, indeed.

Maybe that’s what you’ve used previously (with the troublesome identities). To check the available options kind check the output of keychain - help maybe it would ring a bell in regards to how you’ve exported these identities (I presume there were identities you had been Operating with months ago).

Keep me posted

6

On the old mobile app, it would sync fine, show correct balance, let me logmein thru ssh, but failed to sign transaction.
On new mobile app it refuses to sync and show balance, but still lets me logmein thru ssh to the correct identity and again fails to sign transaction

Both the mobile app and the terminal are showing the same identity. The identity exists, has balance which can be seen from api, from terminal, and from old mobile app. It just fails to sync in new mobile app so I cannot see the balance, but it is the same identity for sure.

Actually the problem is with some identities in the same private/master/secret keychain.
Keychain X has 10 identities. I can cycle through them in the new mobile app, sync each one, and see the balance, login ssh, transfer, etc… except a couple of identities just fail to sync, succeed to login ssh, fail to sign transfer.
The export backup of key and re-import was done with both QR and master private HD key.
I also gave other Keychains (Y, Z) that have similar issues.

Note: The common symptom of all troublesome identities which might give an indication of the cause of the problem, is that when I ssh to terminal, logmein with the troublesome identity, then type “balance”, it shows the correct balance, BUT, it gives the error from Grid script VM: “Pre-Authentication Modes Failed.
Attempting FAPI Authentication Modes”

7

Please check Direct Message @Maximus

8

Sir, your mobile app secret (which is actually a base58-check encoded data structure comprising the Key Chain) has two additional fields besides the Master Private Key:

  • The depth up to which you’ve utilized the key-chain so far (in your case, it’s set to 6)
  • The current identity index (in your case, it’s set to 2)

Now, there’s one bug I can confirm with you already. The UI of the mobile app does not properly report (after the key is entered) that the current identity index is already 2. You can verify this by toggling to identity 2 and seeing the actual desired address reported (1UDCXDf787onwKinN6H3mGhVaVdkS9ihr).

The bottom line (for now) is that my initial suspicion of an invalid identity being used may hold, but that might have been due to a bug in the app, and you might have had no way of knowing.

You could have noticed if you had reopened the Settings View - you would then have noticed that the current address did not correspond to your desired one. Presumably, the mobile app was using identity 1KStfAoVGXFjCcNAgjc1nMEHHwGfpVRr58 while you thought it was using 1UDCXDf787onwKinN6H3mGhVaVdkS9ihr.

Let me explain further. As soon as you enter the Secret, the mobile app knows that you’ve entered a Secret with the current identity at index 2. The text field responsible for an address is updated appropriately, BUT the control responsible for showing the current identity index still shows 0 (when it should be 2).

Moreover, once you activate the identity, it doesn’t account for the initial (not shown) index 2. Instead, it saves the identity with index 0.

:point_up_2: for all the others, fragment of current assessment of the ticket through private encrypted channel. The issue is being ivnestigated.