Topic: Propose human readable format for private keys (Read 360 times)

A better experience??!?

That just looks horrible and clunky... I understand what it is that you're attempting to achieve (that is to say, preventing transcription errors when writing/entering private keys)... but this system is NOT, in my opinion, a "better user experience".

Aside from attempting to write words in mixed case... you're also added in extra "checksum" words. So, now my private key of "L1zK6x6HnrT9kjcuqpQf1WQZHYBhucBEuZ5qZdPrFkCgJQ6eh6EN"

becomes something like:

LIMA one zulu KILO seven
six xray six HOTEL GOLF
november romeo TANGO nine DELTA
kilo juliet charlie uniform delta
quebec papa QUEBEC foxtrot sierra
one WHISKEY QUEBEC ZULU five
HOTEL YANKEE BRAVO hotel ALPHA
uniform charlie BRAVO ECHO XRAY
uniform ZULU five quebec nine
ZULU delta PAPA romeo MIKE
FOXTROT kilo CHARLIE GOLF papa
JULIET QUEBEC six echo one
hotel six ECHO NOVMBER TANGO

I'm very familiar with the NATO phonetic alphabet... I use it all day, every day at work... and typing all that just now was painful AF. Not to mention that it is visually quite jarring to look at.

Personally, I think that a system similar to BIP39 is the way to go. You'll end up with 24 words instead of 65... and it won't matter about case... because I can guarantee that someone will write them down incorrectly and write them as "lima one zulu kilo seven six xray six hotel golf november romeo tango nine delta..." or vice versa. Make something foolproof, they'll just start making better fools!

Ok, it took me a bit longer to code this up than I expected, but here is a demo:

https://youtu.be/kpZcXtww8Us

This shows what it looks like when you type in the private key or seed from paper.

I'm not doing a great job communicating this. Let me get a demo published online so you guys can play with it and see how I envision using it. Thanks for your patience :]

Now that I've read the OP or original post again, you could fork the code and make your own version that includes this "human readable" format. There still wouldn't be a standard that will easily be followed by everyone else until your fork gets used. It's not a fork of the protocol, just how private keys are displayed.

This isn't actually necessary, as you can copy the private key to another program which you can make yourself to spell out the entire private key the way you like. You could even just use a look up table in some spreadsheet to do this.

It's a lot of words for a private key to dictate, presumably over a voice channel ... so the other side can write it down. Unless that channel itself is secure, then you expose the private key anyway, so might as well just send an encrypted message of the key, or the QR code, or the seed words for a wallet. (hardware or software wallet, same thing.)



While you're at it, maybe you just want to make some sort of diceware passphrase instead, then use one of those deterministic brainwallet things, like warp wallet. I'm not sure what the end goal is. You don't need the Core wallet to display that, you can create your own third party app that will accept an arbitrary input and spit out what you want "FOXTROT echo GULF". Then do a reverse "translation" if you really want to type out "FOXTROT echo GULF" to get "FeG".

The whole point of the NATO alphabet was to improve communication on low quality and long distance telephone circuits. Voice. Vocal. There's no point using it to display anything. You can read it out if you want if you are dictating to another person, and that's what most call center agents do when they want to spell out your name or something.

P.S. It should be GOLF.

I am not proposing we use it for vocal communication. I am proposing that when bitcoin core displays a private key it is optionally displayed in this format "FOXTROT echo GULF" rather than "FeG" and that when entering a private key the user can type "FOXTROT echo GULF" instead of FeG.

Also, bitcoin core does not support "apple house car teabag" it only currently supports FeG. "apple house car teabag" was rejected for reasons I think I have avoided.

But the seed that represents thousands of keys is currently accepted as "FeG" in bitcoin core so I would like it to accept "FOXTROT echo GULF" as well.

A. yes, that makes sense, but I'm not proposing to follow that format of phonetics. I'm proposing that FeG would be FOXTROT echo GULF.
B. Bip39 is not supported by bitcoin core. I'm not asking core to adopt bip39 because I think there are probably good reasons it hasn't been already and this has some additional advantages.
C. Yes, this scheme works equally as well for the xPriv that represents the top of the key tree.
D. Good point. This will be mitigated by two things. First the user will need to re-enter their words to verify they were written correctly. Second, in addition to the existing WIF checksum there are lower quality checksums every 4 words to catch most errors in a user friendly way.

(sorry for the lag on this thread)

Agreed. Paper is fragile and unreliable, but still a lot better than electronic copies. That can be partly mitigated by this proposal because it is a more redundant way to record on the paper (easier to discern damaged words that are pulled from a small dictionary).

You can only save the seed words or the private keys to a qr code if you connect to a printer (something I would avoid for cold storage).

The other things this proposal addresses is transcription errors a more pleasant user experience for bitcoin core that does not support bip39 and both of those things can still apply even if your paper is totally intact.

Bip 39 encodes doesn't encode a key, but encodes the entropy used to generate keys.

We could start with a base58 version of the private key instead of the WIF encoded private key, but encoding twice has these advantages and I don't see any disadvantages yet:

1. WIF includes a much more robust checksum. What I'm proposing is a very weak checksum every 4 words as a UX improvement, but it's not strong enough on its own.

2. In cases where we don't need a human readable private key WIF is more compact and easier to work with and it would be a shame I think to mess duplicate the code path rather than just encode WIF.

We could use that way to encode the WIF (using the bip39 word dictionaries), but that has some disadvantages itself.

The first is that you need to maintain a dictionary for each language. Maybe that dictionary will be available, but maybe bip39 will fall out of favor and you are using an less popular language. This scheme does not have that risk or complexity.

The second issue is that the dictionary is large. This means that words are rarely repeated and that if a word is messed up it will be harder to identify it. With the nato phonetic alphabet you have fewer words so you need to use more of them, but you can use autocomplete when entering them so its at worst a break even on user experience and a significant gain from not being dependent on a dictionary and being easier to read (due to few words that could match the thing you are reading).

Keep in mind that WIF is an encoding of a private key. I think it would be a better idea to base your encoding on the key itself rather than the WIF encoding of the key, such as the BIP 39 encoding that every else has suggested, though you could improve it by replacing the checksum with error-correction.

Take care of your paper? Paper is fragile, it can get wet and smudge all the ink or toner, it can burn to ashes.

Properly stored paper lasts for years and decades. Even centuries.

I think you should worry more about the medium and the method of storing, rather than the format of the private key or seed words.

Individual private keys can be saved as QR codes, and also printed or written down manually on paper.
Seed words, typically are between 12 to 24 words, and represent your entire wallet which can consist of thousands of addresses and private keys.

When I said BIP39 I was talking about the initial step which is only a simple encoding of binary into words and has nothing to do with key derivation:

00001100 001 = 97 = armor
01000 111111 = 575 = element
and so on.

You can always convert your private key to words yourself. You can come up with your own algorithm or simply just use the letters as words that you make up because the majority of people will be able to import their seed into alternative clients and get their addresses. Bitcoin core although it is probably the most recommended software to use is not the only option that people have when importing a private key.

The 52 characters of a WIF key and the additional proposed 13 checksum words make a total of 65 characters/words. This is not about pronouncing words, but about viewing on, and inputing the words into, bitcoin core to reduce errors and create a better ux.  Seeds are usually 24, so half as big, but that comes with other tradeoffs, was rejected by bitcoin core, and isn't about private keys (that for example can be used in multisig).

One place where copy, paste and qr codes don't help is when you want to backup your private key on an offline device that doesn't have a printer. Similar use case to writing down your seed on paper with a hardware wallet, but using a private key and bitcoin core instead.

your 52 characters converts to upto 156 vocal words ('upper case x, lower case x')

private word seeds are only 12-24 words.
but as for transfering info. copypaste, qr codes or just spending funds to the recipient is much better then the human flaws of trust and eyesight.
again no code needs to be added to bitcoin if you really want to use phonetic alphabets, your tongue is fully yours and in your control to spell things out without the need of code

edit
replying to below as no point bumping topic
a. FeG  in phonetics is 1.upper 2.case. 3. foxtrott 4.lower 5.case. 6.echo 7.upper 8.case 9.gulf
so its 9 vocal words not 3 that need to be pronounced

b. if trying to make it easier to read for hand writing a paper wallet again seeds are easier

c. as for say backing up private keys instead of a seed, do you know core try to use new keypairs per tx, thus thats alot of keys. also its presumed satoshi himself has upto 20,000 keypairs for his mined coins before seeds were a thing. imaging displaying backing up 20,000 * 52-156 words. or backing up just on set of 12-24words

d. many people filling out questionaires/exams that say 'write using a black pen and using CAPITALS ONLY' still forget to use capitals after a while so when writing things on paper 52(156) words long. you wont know its wrong if you make a mistake until days/months/years later when its time to do the labourious work of keyboard typing the paper wallet words back into the software and being presented with 'error'
however seeing just 12 words is easy to human eye error check when backing up, rather then reading 52 words

Just noticed this:

"I like the idea of checksum within private key, but without error correction part, error detection feels useless since user wouldn't access their Bitcoin anyway."

Even though there is not error correction with error detection after every few words the user interface can provide an immediate error and let you know, within only a few words, where you error is located. If you accidentally capitalized a word or changed the order of words it should be much easier to correct than if you provide the entire 52 characters and then just get an error that the key is invalid as you would now with WIF in bitcoin core.

Combined with using entire words I the liklihood of not being able to see the error is pretty slim. It is easy to misake "b" for "o", but difficult to mistake "bravo" for "oscar."

Thanks for responding.

Bip39 is not supported by bitcoin core (the bip status is rejected) and when using mulisig I believe the best practice (at least when using bitcoin core) is to write down each private key used not just the seed. Writing on paper is important due to bit rot, etc (I think all hardware wallets recommend a paper backup).

While it is certainly possible to just write down private keys using the phonetic alphabet without making code changes to bitcoin core a lot of the advantage of this scheme is that you type in the recorded words into bitcoin core when entering a private key. And when recording a private key the software (bitcoin core) displays the words for recording. The purpose of this is not to vocally share private keys, but to take advantage of words that are both easy to identify when spoken and written. In this case it is for reading and writing those words instead of easily mistaken letters.

As I understand the checksum feature in Bech32 addresses it is similar to WIF for private keys in that the checksum is for the entire address. In this scheme we have smaller checksums after every 4th character to allow a user interface to provide real time error detection and point out exactly (within 5 words) where the error is occurring.

It would also be possible to accept one part of this proposal (displaying and accepting the nato phonetic alphabet for private keys) without the other (introducing more checksums into the private key).

NATO phonetic alphabet is only useful when you want to spell something out, otherwise for writing things down (such as the case with printing a private key as paper wallet/cold storage) they have no advantage. If words is desired instead of a private key, the raw bytes of a key could simply be converted to a mnemonic phrase using a similar approach as BIP39.

As for the rest of your idea (error detection/correction), I suggest you check out the Bech32 encoding that is already in use for SegWit addresses, if you haven't already. The usage of BCH codes improves error detection of this encoding. Although it is not yet used for private keys, it could be.

firstly people can already convert a private key into a word seed/phrase

secondly the military phonetic alphabet is much much slower to speak out all the characters of a private key than a 12word seed

thirdly who would be having voice conversations to transmit a private key using a phonetic alphabet. let alone why would a phontic alphabet be needed for a written copy/paste technology such as computers

..
here is the thing.
the representation of a private key is actually binary, but then made simple to view by putting it into alphabet form.
using vocal phonetics is for the human eye to read, and the human mouth to voice. .. not a concern for software/coding

but things can be made much simpler take the privatekey, backward convert it to binary and then forward convert it to 12 words using the method bitcoin wallet seeds do it

but i still fail to see why anyone would want to vocally share private keys. as thats when if 2 people have access to the funds. one can steal from the other. usually people just send the funds to someones public address as a transaction where the receiver created their public address solely on their own thus no worry of the originator having access after transfer(hint: its called private for a reason)


if you want to voice out the phonetics of your private key, you just ned your tongue not code
by the way ALPHA alpha sound the same vocally, so to separate the two makes vocal communication even longer
'upper case alpha' 'lower case alpha'. which as you can see is voicing 3 words just to pronounce a single character
word seeds seems to solve your issues. not phonetic private key code added to a wallet

Hey Guys,

I’d like to propose a feature to bitcoin to solve the following problems:

- When people read (view) or write (type or handwrite) private keys it is very easy to mistake a letter or number.
- When entering (typing) a private key into bitcoin core a mistake isn’t identified until the entire key is entered.
- When an error is made in typing the private key into bitcoin core the location of the error isn’t indicated within the private key.
- Private keys written onto paper can be made useless if a single character is damaged or poorly transcribed.

The solution I’m proposing has two parts.

First provide an option to use to the NATO phonetic alphabet when bitcoin core displays the private keys or when the user types the keys into bitcoin core. To indicate lower case the word should not be capitalized. Capital letters and numbers should be capitalized.

The nato phonetic alphabet is a long-standing international standard (as international as the use of letters and numbers already used in base58) and has been designed to make each letter easily distinguishable when spoken and written.

By using whole words, that are easily distinguishable and from a very short word database (58 well known words that are either the English numbers or words that begin with the letter indicated) the likelihood of errors in recovery are reduced.

The second part of the solution is to insert checksum letters. If every 5th word is actually a checksum for the previous 4 words, you end up with 13 sentences such as:

ALFA tango THREE SIX bravo

In this case bravo is actually a checksum for the previous 4 words and can be calculated and verified as the private key is entered. If the user accidentally trumped BRAVO instead of bravo the checksum would immediately indicate an error within these 5 words (in most cases) making for a greatly improved user experience.

An additional side effect of this is that even if an entire word is lost on multiple lines, the  checksum would probably make guessing the correct words relatively easy.

I realize some of these issues have been discussed in relation to bip39, but I hope this is more likely to be adopted by bitcoin core as it uses existing private keys, has no impact on keygen, does not require a standardized and well known word list for every language, and is essential just a display format that hopefully wouldn’t require invasive code changes.

Thanks in advance for your feedback.

-JW