Implement gaiacli init to persist cli settings

[adrianbrink]

Would it be a security risk if the CLI determines the chain-id itself so that user don't have to provide it as a cli flag?

[cwgoes]

If you trust the full node, this should be fine. If you don't trust the full node, you need to start from a local root-of-trust to verify proofs.

Rather than this, how about shipping gaiacli with common genesis files (now in this repository anyways) built in as options from which the user can select?

[ValarDragon]

How is this for the ui for when --chain-id isn't entered:

$ gaiacli send <flags>
Defaulting to the following chain-id: gaia-6002. 
Please enter [y/n] or another chain-id option. Other known chain-ids: [gaia-5001, gaia-5002]

[ebuchman]

We used to have an init sequence that we should bring back. Eg:

gaiacli init --chain-id gaia-7000 --node coinculture.net:46657

This information should be persisted so we never have to enter it again!

It will also require some additional input from the user for "weak subsjectivity initialization". Either:

• it will spit out the current validator set hash and height and ask if the user agrees
• the user can provide a known height and validator hash and the tool will verify it from the node

[ebuchman]

Another alternative is to be able to specify multiple nodes (of course over HTTPS !) and ask all of them for the validator set hash and only if they all agree do we move forward with it.

Of course if that set is malicious, they can conspire to screw the light client ...

[ebuchman]

related tendermint/tendermint#970

[jackzampolin]

Sounds like the only thing blocking here is a plan for how exactly to persist these CLI settings. I'm going to change this issue name to reflect that.

[mslipper]

Seems related to #1613 ?

[jackzampolin]

Yup! We should circle up on this.