You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is various data that Monero wallet apps, especially the CLI wallet, can import and export. Examples are spend proofs, key images, unsigned transactions for cold signing, signed transactions for submitting them "manually" yourself, and partially signed transactions for multisig.
Some of them always have a textual format, like spend proofs as generated and written by the CLI wallet. Some of them are written in a binary format, e.g. exported outputs, unless you ask for a textual format by set export-format ascii in the CLI wallet.
A textual format is much more "transportable" than a binary format because you can use more or less any program that can send text somewhere. With a binary format you either have to use apps that can deal with binary files, e.g. e-mail programs, which are fewer in number, or you have to convert the data first to text yourself.
If the format is textuall in some cases Base58 is used, in other cases Base64.
I ask myself whether we should switch to Base32 for at least some type of data, or even set a standard that gets used for all such data and make Base32 part of that standard.
The pro arguments are basically the same as for the use of Base32 in the new Jamtis-style addresses. You find details in the chapter The Case for Base32 in issue #41. In short: Base32 is more "QR code friendly" than Base58 and Base64, and with Base32 we could use the same checksum algorithm like Jamtis addresses, based on polynomials, if a checksum is appropriate of course.
The text was updated successfully, but these errors were encountered:
There is various data that Monero wallet apps, especially the CLI wallet, can import and export. Examples are spend proofs, key images, unsigned transactions for cold signing, signed transactions for submitting them "manually" yourself, and partially signed transactions for multisig.
Some of them always have a textual format, like spend proofs as generated and written by the CLI wallet. Some of them are written in a binary format, e.g. exported outputs, unless you ask for a textual format by
set export-format ascii
in the CLI wallet.A textual format is much more "transportable" than a binary format because you can use more or less any program that can send text somewhere. With a binary format you either have to use apps that can deal with binary files, e.g. e-mail programs, which are fewer in number, or you have to convert the data first to text yourself.
If the format is textuall in some cases Base58 is used, in other cases Base64.
I ask myself whether we should switch to Base32 for at least some type of data, or even set a standard that gets used for all such data and make Base32 part of that standard.
The pro arguments are basically the same as for the use of Base32 in the new Jamtis-style addresses. You find details in the chapter The Case for Base32 in issue #41. In short: Base32 is more "QR code friendly" than Base58 and Base64, and with Base32 we could use the same checksum algorithm like Jamtis addresses, based on polynomials, if a checksum is appropriate of course.
The text was updated successfully, but these errors were encountered: