On reflection, using a serialization library is massive overkill, since we are serializing records that always have a record type identifier, and we are serializing hashes, signatures, and utf8 strings, which should already be in network order, so the only thing we have to serialize are ints, for which we might as well write our own serialization code, in an object of type serialization buffer
But all our money amounts will typically be around 32 bits or longer, maximum 64 bits, hence untranslatable to valid utf8. Might represent them as a decimal exponent and small integer.
We might need floating point for graph analysis, but that is a long way
in the future. Sqlite3 uses big-endian IEEE 754-2008 64-bit floating
point numbers as its canonical interchange format, (no longer widely
used by modern computers) but even if we do the analysis in floating
point, we may well find it more convenient to interchange the data as
integers, since the floating point values of groups of interest are all
likely to be in a narrow range, and we may not care to interchange the
graph analysis data at all, only the groupings and rankings. Really you
only care about one group, the cooperating group. We also need to
serialize signatures to human readable format, for embedding in human
readable messages – (the base 58 system used by this project,
src/mpir_and_base58.cpp suppresses the digit 0,
the uppercase letters I and O, and the lowercase letter l)
or base 64, which we get by including -+_$!* (permitted
in urls) For error check, prefix with enough hash bits to round up to
a multiple of six bits, and make the output fixed size. Human readable
messages that include sensitive records will always end with a hash of
the entire human readable message, truncated to a multiple of three
bytes, hence a multiple of six bits.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.