For example, when encoding large amounts of data, it is 2% less efficient than base64. While Base58 does have a number of beneficial usability features, it is not always a good choice for an encoding format.
This specification asserts that there is just one simple encoding mechanism for Base58, making implementations and developer interactions simpler.
Finally, Base64 has eleven encoding variations that lead to confusion among developers on which variety of Base64 to use. Fifth, unlike Base64, there is no byte padding making many Base58 values smaller (on average) or the same size as Base64 values for values up to 64 bytes, and less than 2% larger for larger values.
Fourth, social messaging systems do not line break on alphanumeric strings making it easier to e-mail or message Base58 values when debugging systems. Third, by using only alphanumeric characters, easy double-click or double tap selection is possible in modern computer interfaces. Second, the non-alphanumeric characters + (plus), = (equals), and / (slash) are omitted to make it possible to use Base58 values in all modern file systems and URL schemes without the need for further system-specific encoding schemes. Doing so eliminates the possibility of a human being mistaking similar characters for the wrong character. First, similar looking letters are omitted such as 0 (zero), O (capital o), I (capital i) and l (lower case L). It is different from Base64 in that the conversion alphabet has been carefully picked to work well in environments where a person, such as a developer or support technician, might need to visually confirm the information with low error rates.īase58 is designed with a number of usability characteristics in mind that Base64 does not consider. The Base58 encoding scheme is similar to the Base64 encoding scheme in that it can translate any binary data to a text string. For example, encoding data using a human alphabet in a way that a person can visually confirm the encoded data can be more beneficial than encoding it in binary form. When trasmitting data, it can be useful to encode the data in a way that survives lower fidelity transmission mechanisms. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Copyright NoticeĬopyright (c) 2019 IETF Trust and the persons identified as the document authors. This Internet-Draft will expire on May 30, 2020. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. The list of current Internet-Drafts is at. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document specifies the base 58 encoding scheme, including an introduction to the benefits of the approach, the encoding and decoding algorithm, alternative alphabets, and security considerations. The Base58 Encoding Scheme Internet Engineering Task Force