Proposal: EFF Diceware encoding

[fancsali]

Similarly to #2 and #7 (and sort-of consolidating them) a way of making thing a bit more compact and much less error-prone, if one needs to write it on a paper by hand and then type it back in.

Pros/cons for base58

• PRO: Much better than base16, but still not-quite compact (less than 6bits/char)
• PRO: Widely known and published
• CON: It's still gibberish, so error prone for humans to write and read -- using words (especially the curated EFF list) has "built-in error-correction"

Pros/cons for BIP39

• PRO: It's based on words, so has "built-in error-correction"
• CON: Not meant for such big pieces of data; not compact enough
• CON: Not as widely known as the others

The case for EFF Diceware

• Very widely known and published
• Although not as compact as base64/base58 but I reckon people prefer words as compared to gibberish -- I personally would write a few hundred words as opposed to few hundred hex characters (a test I ran gives me 600 words vs 1000 hex bytes)
• The most compact variant is the long list, having a bit more than 12bits/word -- would be able to encode 3 hex chars nicely

Other honourable mentions

• Diceware short list(s) -- only ~10bits/word but shorter and with unique prefix; won't nicely fit bytes and nibbles though
• S/KEY -- 8 bytes (64bits) translate to 6 words, so about 10bits per word; on par with EFF short word-lists, but as widely known method

[jcgruenhage]

One more honorable mention: PGP word list. The origins of this make it a nice option as well.

Aside of that though, I'd say that this doesn't really matter that much, as paperkey can already has raw for input and output, which can then be chained to any encoder you'd want.