proposal: Allow referring to accounts by its account number

[ValarDragon]

Currently accounts have an associated account number for replay protection purports in the scenario where that account gets pruned. We should allow directly referring to this account by account number, instead of just address. This could save roughly ~14 bytes every time you refer to an acct in (assuming < 2^40 accts, 20 byte addresses). (There will likely be between 1 bit and 1 byte overhead for being able to discern whether what follows is an account number or an address, but I think this overhead should have already been included in the amino encoding)

This can be a change that the end users don't need to consider. I.e. they can still use account addresses in the CLI / Voyager, but that will get converted into an account number when building the tx for increased spatial efficiency.

What would need to happen prelaunch is just double checking that we could upgrade the tx formats to allow account numbers instead of addresses.

[rigelrozanski]

Sure - we just have to then make sure we start at an arbitrary number like 1250623 just so we don't have any races for the cool account numbers

[ValarDragon]

The logical way to encode this would be as the identifier being a coproduct type between acc num and address. Unfortunately with the amino adaptation of protobuf, a coproduct type requires interface encoding a 4 byte prefix to get encoded. This is truly a oneof situation. With this in mind, the more efficient encoding is actually a second field thats uvarint encoded to 0 most of the time. That has a 2 byte overhead, vs a 4 byte overhead for a prefix.

[jackzampolin]

Going to close this.

[ValarDragon]

Why? This is a huge space savings... and overall I think its a mis-design to not be supporting this.

[jackzampolin]

I don't think the perf gain is significant and account numbers are a ux headache. I'm going to close this as #wontfix

[ValarDragon]

Let's have a discussion, or is your decision final? The correct design would still have end users using addresses and would have wallets handle this....

[alexanderbez]

Re-opening this for any further discussion. Other applications may even want to avoid identification via addresses entirely.