Oh yeah, I forgot we’re using 2 lists pgp style for error redundancy, IMO a proper checksum is defiantly a better than 2x tables. and this application could work universally across crypto addresses most Hex or encoding of hex, we add then base58check >> hash140 and would instantly work for bitcoin.
This might be the safest way to transmit a wallet address over the phone today with 16 words +distinguishable +checksum!
Great idea, I looked up the subject there is 8% of men with color blindness!
I’ve just added a Dictionary that supports color-blindless, and it dosn’t look bad at all!
ex. random 0xbdd8fe2a864cfa165b1266649996e976dcc99483 >>
As a first step, I don’t understand why wallet addresses can’t at least start with the currency code: BTC1Co7WbQJzesUgLuQtr7bFWEUfnDFuBS2nm or ETH0xa5b7d615c99f011a22f16f5809890ca6911200a3, etc. so that new users to crypto have some easy way of making sure they’re sending the right currency to the right address.
Very well done @osolmaz this is useful for matching and comparing as well as for transmitting addresses over the phone, (btw have you considered the odd/even error detection scheme, similar to PGP word list cc @gluk64? this would be really useful!)
@Cygnusfear Emoji checksumming is but as visual checksum only, and I can’t envision several use cases? possibly for etherscan like your chrome extension, however, I still prefer your color highlighting approach.
I’m working on an appealing Square/Circle visualization of momcode to test for identicons…
and some addresses format has explicit prefix structure like XRP addresses start with " r " as rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh, EOS start with " EOS " as EOS8RTr8MFSP37tUQCZspPCDpyphed9noU6zTKjqHh93U2DThjdVr and CashAdd of BTC start with " q " as qpm2qsznhks23z7629mms6s4cwef74vcwvy22gdx6a litecoin L etc
With 1024 emoji you can do something similar to the bijective mnemonic @osolmaz proposed (for example: https://github.com/keith-turner/ecoji), but with icons (so you can communicate the icons verbally). Emoji are supported by most chat applications so there’s native support for the visuals.
The 3 emoji checksum is not bi-directional. With a 1024 emoji list you can get a public key down to 15 characters and still allow decoding. Biggest issue here is similar emoji. Probably should implement a last character that allows the decoder to checksum the input.
address: '0x03236033522cdCBaC862afBeb56a951649082b78',
emoji: '☀️ 👨 ☀️ 😄 🆎 🐅 📫 Ⓜ️ 📷 🛫 🎈 📐 ⏮ ⛲️ 👁 😩',
text: 'sunny man sunny smile ab tiger2 mailbox m camera airplane_departure balloon triangular_ruler black_left_pointing_double_triangle_with_vertical_bar fountain eye weary'
I quite like it actually! I really think a different set of words than BIP39 would be required. I cringe thinking about someone inadvertently copy/pasting their seed. I know you design it against that, but it WILL happen lol. At least an input field can reject the word list as invalid (although sizes do the same thing)
So for public stuff, we need to come up with a different set of 2048 words. If we want to introduce the even/odd scheme, that would be 4096 as far as I have understood. That’s a lot of words to glean on one’s own.
I scraped some sources and started to make my way down to the list. Here is the HackMD in case anyone wants to help:
I obtained the list by scraping sources and removing words that are in the BIP39 list. There are errors, declensions of the same word and words with similar spellings that need to be picked out. I think once picked out, we will end up with ~1600 words, so I will have to repeat the process.
Or use 16-32 symbols with 6-8 colors encoding 40 char into 20 symbols which is the concept behind Momcode (it is base 256 as well 1 byte = 1 symbol further using colors (+/- underscore) we reduce dramatically the size of enoding dictionary symbols pool…
The bigger the base (and the size of your encoding dictionary) the less easy/memorable/transmittable/describable its constituents -symbols-, and shorter output.
btw you can go all the way to Base 65536 (Unicode) and encode the same 40char /160 bits wallet address in only 10 Unicode codepoints. but that is a terrible idea for wallet address (or anything else maybe)
Back to original question, is it better to encode from a dictionary of colorful most used 16-32 symbols to express a 40 char wallet address in 20 symbols, or add 1000 symbols (emojis) to the dictionary and reduce the size from 20 to 15?
I can’t think of use cases that required the complexity of proper extra bytes checksum for this, I’m more keen to even/odd simple error correction (which allows for brain manual decoding).
I just had the chance to read @gluk64’s proposal and see that we were not on the same page. Now I get it.
As far as I understand, a PGP word list like scheme would protect against
transposition of two consecutive words,
duplicate words,
or omitted words.
and not
transposition of any two words
accidentally typing another word from the list (which may very well happen. Look at BIP39: trip-trim, aim-air, awake-aware, etc.)
AFAIU the first 1024 words would be for even and last 1024 would be for odd. The bad thing is that we lose the two-three syllable pattern which lets the listener know immediately something is wrong. If we wanted to build such a list, we could have a hard time finding words easy to spell and pronounce for laymen. (Also, I still think we should use separate word lists for public and private stuff, which would make the task even harder.)
What I was suggesting: Don’t partition the bits like @gluk64’s proposal, and treat the whole thing as a number. If we use a check word at the end, we get away with 15 words + 1 check word.
I propose something like ISBN-10. 2053 is nearest prime to 2048, we could add 5 more words to the list to be used only in the check word. Then we would have a scalable error-detecting scheme that not only works for 20-byte addresses, but for numbers as big as 2048^2053. It would detect 100% of transposition and mistyping errors.
Slight disadvantage: implementations will have to use big integer libraries (if integers not bigint by default like in Python)
Do let me know which one you think is better and why.
I took a second look at BIP39 and came up with a way of reducing the number of words to 14 by using a list of 4096 words, and doing the checksum with hash functions like in BIP39. It’s in the same page I posted before.
I have a question, it may seem a bit unrelated and I’m sorry, I’ve been asking this all over… but it’s an idea I’ve been thinking on for a while. I’m no expert as some to you will come to see in my somewhat crude question and the fact I use a bitcoin library to present the question, I have no bias, just more familiar with the library, but bear with me.
This is a bit of a general question, knowing already of HD wallets and the mnemonic system for creating, backing-up and using the bitcoin blockchain.
However say you have for example a cold/paper wallet, with just one Bitcoin Private Key.
Say I use bitaddress.org’s code to securely generate a paper wallet. Then import it using the library I used above, and export it to it’s integer wallet format, and I turn the resulting integer into an exponent of whatever number that’s exactly equal to the exported integer value. Say its 10^98, that’s pretty easy to remember, and I generated securely no?
Wouldn’t an easier way to back-up/save/remember that address be simply be figuring out where the key lies within the range of possible bitcoin keys and taking note of the exponent of said number?
The private key below is generated from the number 2^65
from bit import Key
# The exact position of this key is 2^65 in int form: 36893488147419103232
privKey = Key.from_int(36893488147419103232)
# or simply
privKey = Key.from_int(pow(2,65))
print(privKey.address)
print(privKey.segwit_address)
this output the addresses: 1LgpDjsqkxF9cTkz3UYSbdTJuvbZ45PKvx and 3FC7umZDWPvTskbVwG7mn72M8RtW8yFSy7 for segwit. All I’d have to remember is just that exponent to import this private key for example…
but as visual checksum only, and I can’t envision several use cases? possibly for etherscan like your chrome extension, however, I still prefer your color highlighting approach.
