Shorter BTC codes using more of unicode?

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: 🏰 TradeFortress 🏰 on August 15, 2013, 11:04:53 AM

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.

🏰 TradeFortress 🏰

vip

Activity: 1316

Merit: 1043

👻

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

/thread

r3wt

hero member

Activity: 686

Merit: 504

always the student, never the master.

Quote from: yakov on August 15, 2013, 07:15:39 AM

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!!!

yakov

newbie

Activity: 40

Merit: 0

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)

xeroc

sr. member

Activity: 345

Merit: 250

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

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: digit on August 14, 2013, 03:16:13 PM

I believe this would increases the size of transactions as

Quote

"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.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: tgerring on August 13, 2013, 06:18:48 PM

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.

digit

legendary

Activity: 1672

Merit: 1010

I believe this would increases the size of transactions as

Quote

"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)

tgerring

full member

Activity: 142

Merit: 100

Hive/Ethereum

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.

alan2here

hero member

Activity: 1778

Merit: 504

WorkAsPro

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.

Topic: Shorter BTC codes using more of unicode? (Read 890 times)