Go-ethereum: `geth accounts` inits a chain

[karalabe]

When creating a new account with geth --datadir=xyz account new (to eventually make a custom genesis block and private network), this method creates and inits a live chain inside the provided datadir. This is annoying because users then try to init their chain with their custom genesis, which fails, requiring to manually delete the old chain (which most people don't know how).

The solution is quite straightforward, none of the account subcommands should create their own chain database (or I'm guessing entire p2p node), since there's no need.

Side effect issue of this: https://github.com/ethereum/go-ethereum/issues/15354

Hint for implementers: we want to get rid of these calls https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/accountcmd.go#L294 and replace them with one that only creates a keystore, but not an entire network stack (or alternatively, one that avoids starting up eth inside the stack).

[manicprogrammer]

If no one else grabs this one I will take it as a first submission and create the PR etc. I will wait a bit to defer to anyone else that prefers it.

[jakegsy]

@manicprogrammer Would have loved to grab it but since you've already announced you should take it!

[manicprogrammer]

early PR #15384 needs to be labeled 'In Progress' but don't think I can apply a label to a PR in this repo.

[manicprogrammer]

Can someone please verify that this issue is correct or rather verify this is incorrect. I do not find the scenario as noted in this issue to be true.

If I run geth --datadir=xyz account new I only get a keystore directory created. No data directory is created.

Looking at the code that was referenced it does go through and create a node struct in memory to reference in terms of getting configuration values but until an init is run the data directory is not being created and no init is run. I'll double check on other account command calls but certainly is the case on account new

Funnily or sadly I didn't verify this was the case out of the gate. I refactored the code so that it would not call New() on Node and build the stack definition for the node when running the account command(s) but would create the needed config info for accessing the proper datadir and have access to the AccountManager under Node then as I dug in deeper I could not find how even calling New() would have created the db directory. When I hopped back out to a cmdline and ran the command sure enough no database dir.

tagging @karalabe

[manicprogrammer]

In the meantime I will try to duplicate #15354

[manicprogrammer]

propose closing this issue as unreproduced unless there is further information that expands on the initial entry or contradicts the prior entries showing that a datadir is not created not an init run when calling the account command of geth.

[karalabe]

Hmm, this is indeed unfortunate. We had so many issues about users playing with custom genesis blocks and account inits - always failing due to pre-existing chains - that I blindly assumed there was a bug causing the node to spin up. I'm sorry for wasting your time. Closing as a non-issue.

[manicprogrammer]

Not a waste at all. I learned more. I'm going to start digging in deep investigating the Genesis block issue. There has to be a reason.

I too made assumption that the issue existed.

[manicprogrammer]

I'll dig into these issues and find the root.

[karalabe]

Perhaps people sometimes start with accounts new instead of account new, which doesn't fail as a non-existent subcommand, rather starts a node up. That might cause issues later. Maybe we should explicitly disallow non-existent subcommands as a remedy for this.

[manicprogrammer]

That is an interesting thought and a high probability. Even if it were to not end up being true in all reported cases it is still a good idea. I would have not expected for the command to function in such a case. Interesting.