Using an existing DB results in ganache lying about accounts and balances.

[MicahZoltu]

First run ganache-cli with a mnemonic and a db path.

npx ganache-cli --db "./db" --mnemonic "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong"

Exit and then run again without a mnemonic, but with the same db path:

npx ganache-cli --db "./db"

• Notice that the accounts listed in the startup splash are different between runs.
• Notice that the second run indicates each account has 100 ETH balance.
• Notice that if you call eth_accounts against the second run it will list the accounts using the random mnemonic.
• Notice that if you call eth_getBalance against any of the accounts listed by the second run you will get a 0 balance (different from what startup splash shows)
• Notice that if you call eth_getBalance against the accounts from the first run you will see 100 ETH balance.

Expected Behavior

Accounts and balances correctly listed by splash screen and eth_accounts RPC when using an existing DB.

Current Behavior

The accounts/balances listed do not match the splash screen.

Possible Solution

I think the right solution here is to have the splash screen show the actual balances rather than assuming the accounts have a balance.

Another option would be to store the original mnemonic with the DB files so that it can be used in subsequent runs.

If the first solution is chosen, it would be good to display a warning to the user that an existing DB is being used and the original mnemonic is unknown, thus the original accounts cannot be referenced.

[kuzdogan]

I agree the first solution is the right one.

This caused me couple of hours to debug as I've kickstarted the blockchain with a typo in the mnemonic. (why is there no feedback for wrong input mnemonics, missing or non-matching words?)

Only after logging balances in truffle I could realize I have zero balance. For me, the solution was to wipe the db and start with the correct mnemonic. Now I know why it happened.

[dongmingh]

Thanks for reporting this bug and we will address this bug in #1030. Closing this as duplicate.