add address_utils

[DangerousFreedom1984]

Tool to convert JamtisDestination to/from an human-readable address 'xmra...'

[vtnerd]

This is generally frowned upon, it defeats the purpose of namespaces entirely.

[DangerousFreedom1984]

Yeah. Thanks. Removed.

[vtnerd]

It was decided to switch to base32 for Jamtis? Interesting, I don't recall a discussion about it though.

[rbrunner7]

I think @tevador proposed a Base32 scheme together with a custom alphabet discussed here as integral part of his Jamtis spec, see here. There was some more discussion; e.g. @hyc asked why not Base64 here.

I had a chapter The Case for Base32 in my Reddit post about Jamtis addresses.

You could say that nobody opposed enough or came up with solid counter-arguments to topple Tevador's design decision, so we go along.

[DangerousFreedom1984]

Well, I guess you are referring to why use base32 instead base58 for general purposes, right?
So I just ran the test below to compare the performance of base32 and base58 to encode/decode a string of length 1 to 500:

    std::string encoded_32, encoded_58;
    std::string decoded_32, decoded_58;
    std::string test;

    std::string my_str{"a"};

    std::vector<double> v_32;
    std::vector<double> v_58;

    test = my_str;
    for (size_t str_len = 0; str_len < 500; str_len++)
    {
        test += my_str;
        auto t58 = high_resolution_clock::now();
        for (size_t i = 0; i < 10000; i++)
        {
            encoded_58 = tools::base58::encode(test);
            tools::base58::decode(encoded_58, decoded_58);
            ASSERT_EQ(decoded_58, test);
        }
        auto t58_end = high_resolution_clock::now();

        auto t32 = high_resolution_clock::now();
        for (size_t i = 0; i < 10000; i++)
        {
            encoded_32 = base32::encode(test);
            decoded_32 = base32::decode(encoded_32);
            ASSERT_EQ(decoded_32, test);
        }
        auto t32_end = high_resolution_clock::now();


        duration<double, std::milli> ms_double32 = t32_end - t32;
        duration<double, std::milli> ms_double58 = t58_end - t58;

        v_32.emplace_back(ms_double32.count());
        v_58.emplace_back(ms_double58.count());
    }

And the result is the following:

Fortunately, base32 is about 30% faster. I believe we could also use that for the knowledge proofs or to store stuff in a human-readable format later. If speed matters.

[DangerousFreedom1984]

Sorry, it was stupid, the result was obvious since my input was fixed. Anyway, if we come to a point where we should decide between base32 and base58 then I will do a proper benchmark. It was not my choice here.

[DangerousFreedom1984]

Sorry. I completely misunderstood your comment about the encoding as I thought it would suffice to serialize the keys using the standard serialization method. But to be according the specs, we need to do some bit management to use all 910 bits sequentially.
*Now the specs are probably outdated but the encoding idea is the same (fill last bit of each X25519 point with last bits of address_tag to encode and do the opposite to decode).

[vtnerd]

Why not return the std::string. There probably isn't any "memory re-use" with usage of the operator+ syntax.

[DangerousFreedom1984]

Yeah, I think it doesnt matter. I added another function so the client decides :p

[DangerousFreedom1984]

Talking with @jeffro256, we realized that since the X25519 points occupies only 255 bits, there may be cases where two human-readable addresses point to the same keys. I will look that case in a couple days.

[jeffro256]

Related: the addresses can be made 1 byte shorter by packing in the X25519 pubkeys 255 bits at a time.

[jeffro256]

Check the string length before indexing, otherwise you can segfault, or worse