ganache-cli doesn't really lock accounts

[NicsTr]

Expected Behavior

When using --secure, ganache-cli should not allow transactions from locked accounts.

Current Behavior

Transactions are done as if the accounts were not locked.

Possible Solution

Steps to Reproduce (for bugs)

1. npx ganache-cli --secure --deterministic -p 8000 -a 11
2. After right configuration of web3js' provider to ganache : web3.eth.personal.sendTransaction({from: "0xFFcf8FDEE72ac11b5c542428B35EEF5769C409f0", to: "0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1", value: web3.utils.toWei("1") }, '')

Context

Unless I wrongly understood how locked accounts should work, this seems like a pretty serious bug.
Please not that I figured a not so elegant workaround by using --db option and by relaunching ganache-cli with a smaller -a argument, causing it to initialize the 11 eleven accounts as expected but forbidding every transactions from an address that is not present in the second execution log.

Your Environment

• Version used: v6.7.0
• Version of Truffle/Remix/Other tools used: ganache-core 2.8.0, web3js 1.2.2
• NodeJS Version: 10.16.3

[davidmurdoch]

Because you are using personal.sendTransaction with a password of '' (the default password when locking accounts via the --secure flag) you are temporarily unlocking the account for this transaction. This is by design.

With that said, I think I agree with you that it shouldn't work this way. However, I'm not sure what the default password for accounts locked with --secure should be. What are your thoughts and expectations?

[NicsTr]

Oh, I surely didn't expect that kind of default behavior.

IMHO, It'll be less strange to add a command-line argument to set the password or use the seed to generate it (and display it) as for the private keys.

[davidmurdoch]

For ganache v7, let's rename the --secure flag to --lock and --wallet.lock (while keeping the --secure flag for legacy reasons)

We'll also add a --passphrase flag. The --passphrase {string} flag by itself (sans --lock/--secure) will not automatically lock accounts and will not be an error. This enables using personal_lockAccount(address) to lock the account (with the user-specified default passphrase) after start up.

Using --lock/--secure without the --passphrase flag will continue using "" (empty string) as the passphrase.

Implementation detail:

We store account private keys that were created by personal_ methods in their encrypted form, but really don't need to do this for accounts created with the default "" passphrase, so let's take advantage of this and optimize for better start up time by storing the private key directly (unencrypted).