Metamask-extension: Incorrect (huge) balance running on RPC 127.0.0.1:8545, mainnet

Created on 8 May 2019  路  23Comments  路  Source: MetaMask/metamask-extension

Describe the bug
I am fully synced on Geth light mode, mainnet, connecting via RPC, though my ETH balance is far from what it was supposed to be.

./geth --syncmode light --cache 2048 --rpc --rpccorsdomain moz-extension://e582a415-cf54-468e-9b4b-f32b576f7bf7,chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn

To Reproduce
Steps to reproduce the behavior:

  1. start geth 1.8.27 with the aforementioned command
  2. Have it synced
  3. Have the account balance updated (generally open the expanded view and/or wait a little while)
  4. geth attach
  5. eth.getBalance('[MY_ADDRESS]') gives me accurate balance
  6. Reset the account
  7. Same huge ETH balance

Expected behavior
Correct balances shown.

Screenshots
Kapture 2019-05-07 at 11 53 25
image

Browser details (please complete the following information):

  • OS: OS X
  • Browser: Chrome
  • MetaMask Version: 6.4.1

Additional context
Add any other context about the problem here.

N02-needsReproduction T00-bug

Most helpful comment

My hunch is that metamask fails to handle this kind of response from Light Client, when it does not have the immediate answer

Thanks for including the error message, this will help us greatly to investigate/fix.

All 23 comments

I am getting the same behavior, my mainnet balance is 0.1915 ETH but it is showing 23570985008687907853269984665631340667420.7292 ETH via the Localhost:8545 network option with geth running with the above flags

I tested the same RPC method in Postman and MyEtherWallet CX, and values are correct.

Also happening in local RPC with Rinkeby
image

Using the console, I can see a bunch of RPC errors, will try to pinpoint the issue from here:
image

My hunch is that metamask fails to handle this kind of response from Light Client, when it does not have the immediate answer:

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32000,
        "message": "no suitable peers available"
    }
}

My hunch is that metamask fails to handle this kind of response from Light Client, when it does not have the immediate answer

Thanks for including the error message, this will help us greatly to investigate/fix.

Unfortunately, I was unable to get the issue outcome of large value, but I didn't get the no suitable peers available. Will try attempts to get this error message, might have to constantly remove my database and retry. Curious if you have every set up a private ethereum chain with your address and pre-allocate Ether to your account then swapped back to the main network?

Hi @tmashuang, do you have any test suite (or strategy) to mock RPC methods?

Since we primarily use Infura's API, I think we use https://github.com/nock/nock to mock those calls.

How to (hopefully deterministically) get the no suitable peers error:

Start geth light client with the --nodiscovery flag. It'll have no means to fetch account balances.

geth --syncmode light --cache 2048 --rpc --rpccorsdomain='*' --rpcapi "db,eth,net,web3" --vmodule="rpc/*=5" --nodiscover

{
    "jsonrpc":"2.0",
    "method":"eth_getBalance",
    "params":[
        "0xADDRESS", 
        "latest"
    ],
    "id":1
}

Curious if you have every set up a private ethereum chain with your address and pre-allocate Ether to your account then swapped back to the main network?

no, I haven't

I am getting the error,no suitable peers, now with --nodiscover. Still unable to get a large balance. I don't want to ask to removedb and resync, but I don't see where this bad balance could be coming from.

I just produced a local build of MM 6.4.1 (version tested in the first place) and I got the huge balance:
Screen Shot 2019-05-23 at 5 21 13 PM

I don't know what changes were made up to 6.5.3, and I tend to believe it might have been fixed. Can you take a spin on 6.4.1 just as sanity check?

No large balance for me on v6.4.1.

It does not even happen with all accounts, as shown:

so I guess this is either a super difficult issue to reproduce or it's gone for good. We can close it for now and should we run into that issue again, I'll revive it.

Thanks @tmashuang

Oh wait this is an imported account? Where was this account created from?

json file, created from geth

Ok I got it now from the account created in Geth, will investigate the root cause.

Friendly bump @tmashuang. any conclusion? LMK if you need any help from our side.

@evertonfraga We are currently investigating this issue, and have theories and potential fixes. Would you be willing to submit your state logs to [email protected] with this issue number? Or rather continue on this thread with specific Q/As?

Hi @tmashuang, I'd rather continue on this thread. please send your Qs :)

Dropping by just to say that this still happens. I 've tried to use a custom RPC pointing to my local geth light node and I am receiving distorted values on my ETH balance. Other assets (ie tokens) are correctly displayed.

I can see the correct value when connecting to DApps like zapper.fi, but have not checked if they are getting it through their backend or through web3 calls.

If you open the background devtools (guide here), you should be able to see the network requests that fetch the balance. This could allow you to confirm that MetaMask is receiving the correct value and the fault is with us. If so, you could also copy the request & its response here for us to look at, to see if maybe something about the payload causes a wrong interpretation.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

glitch003 picture glitch003  路  3Comments

danfinlay picture danfinlay  路  3Comments

rossbulat picture rossbulat  路  3Comments

kumavis picture kumavis  路  3Comments

whyrusleeping picture whyrusleeping  路  3Comments