We could implement transaction outputs and inputs as a fixed amount of fungible tokens, limited to 2^{64}-1 tokens, using Safeint That will be future proof for a long time, but not forever.
Indeed, anything that does not use Zksnarks is not future proof for the indefinite future.
Or we could implement decimal floating point with unlimited exponents and mantissa implemented on top of MPIR
Or we could go ahead with the canonical representation being unlimited decimal exponent and unlimited mantissa, but the wallet initially only generates, and only can handle, transactions that can be represented bySafeint, and always converts the mantissa plus decimal exponent to and from a safeint.
if we rely on safeint, and our smallest unit is the microrho, that is room for eighteen trillion rho. We can start actually using the unlimited precision of the exponent and the mantissa in times to come - not urgent, merely architect it into the canonical format.
From the point of view of the end user, this will merely be an upgrade that allows nanorho, picorho, femptorho, attorho, zeptorho, yoctorho, and allows a decimal point in yoctorho quantities. And then we go to a new unit, the jim, with one thousand yottajim equals one yoctorho, a billion yoctojim equals one attorho, a trillion exajim equals one attorho.
To go all the way around to two byte exponents, for testing purposes, will need some additional new units after the jim. (And we should impose a minimum unit size of 10^{-63} rho or $10{-6} rho, thereby ensuring that transaction size is bounded while allowing compatibility for future expansion.)
Except in test and development code, any attempt to form a transaction involving quantities with exponents less than 1000^{-2} will cause a gracefully handled exception, and in all code any attempt to display or perform calculations on transaction inputs and outputs for which no display units exist will cause an ungracefully handled exception.
In the first release configuration parameters, the lowest allowed exponent will be 1000^{-2}, corresponding to microrho, and the highest allowed exponent 1000^4, corresponding to terarho, and machines will be programmed to vote “incapable” and “no” on any proposal to change those parameters. However they will correctly handle transactions beyond those limits provided that when quantities are expressed in the smallest unit of any of the inputs and outputs, the sum of all the inputs and of all the outputs remains below 2^{64}. To ensure that all releases are future compatible, the blockchain should have some exajim transactions, and unspent transaction outputs but the peers should refuse to form any more of them. The documentation will say that arbitrarily small and large new transaction outputs used to be allowed, but are currently not allowed, to reduce the user interface attack surface that needs to be security checked and to limit blockchain bloat, and since there is unlikely to be demand for this, this will probably not be fixed for a very long time.
Or perhaps it would be less work to support humungous transactions from the beginning, subject to some mighty large arbitrary limit to prevent denial of service attack, and eventually implementing native integer handling of normal sized transactions as an optimization, for transactions where all quantities fit within machine sized words, and rescaled intermediate outputs will be less than 64 - \lceil log_2(number of inputs and outputs) \rceil bits.
Which leads me to digress how we are going to handle protocol updates:
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.