 Show Posts
|
|
Pages: [1]
|
Ok, it took me a bit longer to code this up than I expected, but here is a demo: https://youtu.be/kpZcXtww8UsThis 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 :]
|
|
|
|
|
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.
|
|
|
|
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."
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 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) |
|
|
|
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.
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. |
|
|
|
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.
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. |
|
|
|
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.
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: 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d
00001100 00101000 11111100 10100011 10000110 11000111 10100010 00100111 01100000 00001011 00101111 11100101 00001011 01111100 10101110 00010001 11101100 10000110 11010011 10111111 00011111 10111110 01000111 00011011 11101000 10011000 00100111 11100001 10011101 01110010 10101010 00011101
00001100 001 = 97 = armor 01000 111111 = 575 = element and so on. 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). |
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
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
|
|
|
|
|
