Add starting account number to genesis file

[sunnya97]

So you can start at something other than 0. Also doesn't have to do a nil check every time. Requested in #1077

[ebuchman]

We should set this in InitChain

[ebuchman]

The relevant comment from #1077 I believe is:

Can we add an InitGenesis function to x/auth which takes an initial account number? I think we decided we wanted to start with a nonzero number so low-numbered accounts aren't specially valuable, this also makes the GetNextAccountNumber logic cleaner.

Do we really need to do this?

[ValarDragon]

This would make sense if we were var-int encoding account numbers. We're not (AFAIK), so in the current system there isn't a need to do it.

I am actually in favor of var-int encoding these though, as the trade-off point where var-int encoding costs more than normal encoding is 2^56. We shouldn't expect more than 2^56 accounts, so I think var int encoding makes sense. (For reference, 2^56 is 72,057,594,037,927,936, or 72 quadrillion) Using var int encoding is basically just using an int. (Based on my amino knowledge) I can spin this out into a more well written issue / proposal though.

[jackzampolin]

Going to close this cause we have moved from accounts to transactions for the genesis file per @alessio Please reopen if you feel I am wrong and direct all 🔥-> @jackzampolin

[ValarDragon]

We require this in order to have replay protection under forking with the same chain id.

[sunnya97]

Non-malicious hard forks should not have the same chain-id.

[ValarDragon]

Ah your right. Though if we go with a proposal like #1653 this matters more, as it may be your main identifier. I also think that its preferrable to reduce the amount of changes one needs to make their local signing devices.

[rigelrozanski]

If we do this we need to have a genesis check to ensure that no two account numbers are the same - this previously caused a headache of a bug

[cwgoes]

Can we do this @sunnya97? Seems pretty trivial.

[jackzampolin]

Closing as stale and not important.