Which encoding format do you like for the addresses?

  1. BASE32

  2. BASE64

  3. BASE58 (bitcoin style)

  4. OTHER

    0 vote(s)
  1. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I have a question regarding the addresses in MicroCash. What do people prefer, an address which uses fewer characters combinations, but is longer, or one which uses more character combinations and is longer. Basically this question boils down to the use of BASE32 to encode addresses into a text format that people can use, or using BASE64.

    A MicroCash address is 32bytes in length, and represents 32 values which can vary from 0 to 255 (a byte). However when converting this 0 -> 255 into a text format that humans can understand we have to reduce the amount of possible combinations per "character" from 256 down to a lower number, most common is base64 (64 combinations per character , or 6 bits as 2^6 is 64). Another common encoding scheme is base32 (32 combinations per character, or 5 bits as 2^5 is 32).

    There is also Bitcoins format which is a modified base64, called base58, which excludes 6 certain characters from base64 which may be confusing.to users. Like the difference between the letter I (eye) and lower case L, l. This is an uppercase i and lowercase L together which shows the confusing aspect. Il

    So a base32 encoded address is these 52 characters :-

    And a base64 encoded version of the same address is this 43 characters:-

    And just for whatever, here is a base58 encoded bitcoin style version of the address :-

    Which do you prefer? Is the shortest one the best?

    Last edited: Feb 6, 2016
  2. maxalt

    maxalt Hey macarena!

    I chose base 64 because i think the shorter the better.
  3. MrSonic

    MrSonic New Member

    Short is good....
  4. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    Well BASE64 is shorter than BASE32...... though it doesn't seem that way just reading those names I know . :)

    I am torn at the moment between BASE58 and BASE64. At least the weird BASE58 bitcoin invented is now semi-used so it is not as weird as it used to be. And it does remove a few weird characters at the expense of just adding one more character to the address. Not sure myself just yet but I think it is one of those two.
    Last edited: Feb 6, 2016
  5. fellow

    fellow Member

    I think all versions are too long to type in or remember manually.
    From integration/adoption perspective I would go with base58 (people know it from bitcoin and have a good feeling by knowing the address encoding "by name" or they do already have tools for it).
    If someone does some really tough stuff with the addresses he would normally go binary and convert it to whatever base on demand.
    I think technically it is all the same so the way promising the simplest adoption should be choosen.
  6. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    I agree about too long to remember or type in. But Bitcoin is already that too, at least for me. The reason they are 32bytes is because this removes the need to have some "extra" registration system for an address, you basically just put your public key in there as the address and you are done. MicroCash was using a 80bit hash of that public key before, which required some account registration system to lock it to a certain pubkey. I don't know if users really want that extra step to register an address besides sending funds, even if it was automatic in a client, which is why I think just dumping the pubkey there as the address is the easiest option.

    I haven't yet done it but I believe a name system in MicroCash should be possible with minimal effort which would allow people to create their own names. Until I do the work and implement the solution I wouldn't guarantee it, however I do believe its possible even in the "Need to be very efficient" MC mainline code. The other way to do it is with a sidechain.
  7. necom

    necom Administrator Staff Member MC Developer

    I like the user-friendly improvements of base58 and do think they carry a lot of weight. We have the benefit of a bit of momentum on the side of devs using BTC for a while and adopting it, so on their end it's not something to adapt to -- same to be said for base64 from a wider dev perspective though, of course. I wonder if there's any reason to use 64 from that angle: developer tools & benefits from the non-crypto world? I'm thinking down the road in a mass-adoption side of things (why not think of that).

    Readability: +1 for base58 since it's shorter, feeling less like "yelling" due to lowercase chars. Font issues alone are a major pain for the simple set of "one, L, zero, oh" set alone. It's really forcing copy/pasting, rather than just being a little hard to read.

    Usability: +1 for non-base64 for double-clicking. Maybe a small issue, but try double-clicking these three address samples and see what happens. In my browser, I get sub-sections of the base64 example due to the special chars, but the other addies select the whole thing easily. Again, maybe this isn't a big deal, but if we're roughly forcing a copy/paste user experience, simple selection matters.
  8. Ryler Sturden

    Ryler Sturden Member Staff Member MC Developer

    What about the ability to use any of these encodings? We could just add a little prefix part which identified what it was. So we could allow HEX, BASE32, 58, 64, whatever, the code to support all these is nothing.

    eg. the three different addresess with a MCASH prefix, notice the 0,1,2 in front to specify what it is? You could also deterimine it by length and remove the 0,1,2 if you hardcoded the encodings by length alone.

    When I think about what is the use in standardizing this I can't really find a reason since all look not pleasant to humans, even Bitcoin addresses do which are half the size. As long as there is an API to get whatever format people want in their apps I don't see the harm necessarily, outside of more web work in identifying valid addresses client wise. I also think a MCASH- type prefix is necessarily regardless of whatever format, since people can just read that and get right away its microcash without bothering to decipher the jibberish behind it.

    And I think provided we allow some way to have a name system in MicroCash, where people can select addresses by name, then in the end it isn't that important. Anyhow some things to think about, the decision doesn't have to be made right away.
  9. edwardteach

    edwardteach New Member

    64, because maxalt is always correct. Allegedly.
  10. necom

    necom Administrator Staff Member MC Developer

    It's looking like BASE58 is barely squeaking a win for now. Short(-ish), but slightly more usable?

    With the ideas of doing custom naming support, maybe that negates the little preface number/code? However, if the full naming/customization support is implemented -- I've been thinking of that as "vanity addresses" -- if it's being done for an extra fee, maybe we have a simple free option like this little prefix?

    So maybe we'd have something like these choices?:
    • default: MCASH-[BASE58]
    • "Add a 1-char prefix for free": MCASH-[a-Z|0-9][BASExx]
      • [a-z|0-9] means "any character from a to Z, or number from 0-9", btw... I think it means that anyway :p
    • "Vanity Address": MCASH-[vanityAddress]
      • Charge a fee for this? ...the fee thing came up when someone was talking about some other currency doing vanity addies, which is why I'm bringing it up. It does make some sense though, if it adds any overhead.
  11. maxalt

    maxalt Hey macarena!

    I think you mean Bitshares
    In my head there is an option to buy/sell a vanity address, you buy at a network set fee (proceeds tbd) and sell on to google, microsoft and facebook when they want to adopt xmc.
  12. daemon

    daemon New Member

    would go for base64
  13. Mezzo

    Mezzo New Member

    base64, sounds good. Maybe the MCASH-idea and base64 together

Share This Page