Shorter BTC codes using more of unicode?

[alan2here]

The keys and the longer private one, this includes PGP codes too, when using combinations of letters and numbers to represent numbers more concisely, why not use more charecters?

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

But then ...

ᎧᏍᏜᏯᎦᎭᎹᎾᏆᏌᏠйцyкгшфпджэячью

And then maybe chunks from long eastern alphabets.

[tgerring]

You could achieve space savings with a larger dictionary, but it'd be at the expense of readability, which is already poor.

I don't think you could ever shorten them enough to be usable/memorable, but a DNS-like system could be implemented, as outlined in BIP 0015.

[digit]

I believe this would increases the size of transactions as

"UTF-8 uses one byte for any ASCII characters, which have the same code values in both UTF-8 and ASCII encoding, and up to four bytes for other characters. UCS-2 uses a 16-bit code unit (two 8-bit bytes) for each character but cannot encode every character in the current Unicode standard. UTF-16 extends UCS-2, using two 16-bit units (4 × 8 bit) to handle each of the additional characters."(taken from https://en.wikipedia.org/wiki/Unicode)

[edmundedgar]

You could achieve space savings with a larger dictionary, but it'd be at the expense of readability, which is already poor.

It might actually be more readable for people who know a language with a lot of characters to convert it into that. For example, if you start with a Base58Check-encoded Bitcoin address like:

1NYcRLuPCTd6Lamxf1mZTdpjo6ubs4pKL2

...you could plausibly turn it into something in Japanese like:

印可基 口合宗 出具隅 終上 占西前 杉獣淑

...which I think is probably an improvement. It's certainly easier to tell different addresses apart using that scheme than the original base 58.

But it's still too long to memorize or reliably type without screwing it up, and if you have to copy-paste the thing anyway it's not really obvious that it's helping with any actual problems.

[edmundedgar]

I believe this would increases the size of transactions as

"UTF-8 uses one byte for any ASCII characters, which have the same code values in both UTF-8 and ASCII encoding, and up to four bytes for other characters. UCS-2 uses a 16-bit code unit (two 8-bit bytes) for each character but cannot encode every character in the current Unicode standard. UTF-16 extends UCS-2, using two 16-bit units (4 × 8 bit) to handle each of the additional characters."(taken from https://en.wikipedia.org/wiki/Unicode)

Presumably this would just be the way you'd encode the address to communicate it. Your Bitcoin client would end up putting the data in the blockchain the same way it does now.

[xeroc]

one of the nice features of base58 is that whenever you doubleclick a base56 encoded addresse you select the whole address .. not just a subset ...
makes copy&paste much easier

[yakov]

A problem with this is then you cannot type in an address containing letters than don't appear on most keyboards.
Many paper wallets are handwritten onto paper (because printers are not to be trusted)

[r3wt]

A problem with this is then you cannot type in an address containing letters than don't appear on most keyboards.
Many paper wallets are handwritten onto paper (because printers are not to be trusted)

yes, printers are the DEVIL!!!

[🏰 TradeFortress 🏰]

Great, so there will be unicode homoglyph attacks on addresses.

/thread

[edmundedgar]

Great, so there will be unicode homoglyph attacks on addresses.

/thread

If you were using non-Latin characters to encode addresses for humans you wouldn't want to use the whole unicode set as is - you'd use a subset to do equivalent of Latin -> Base58Check. As well as characters that looked the same, you'd need to filter out things that people didn't have reliably have font support for.