So you can start at something other than 0. Also doesn't have to do a nil check every time. Requested in #1077
We should set this in InitChain
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?
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.
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
We require this in order to have replay protection under forking with the same chain id.
Non-malicious hard forks should not have the same chain-id.
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.
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
Can we do this @sunnya97? Seems pretty trivial.
Closing as stale and not important.