Client Feature Suggestion - RFC1751 Key 'Export'

[JoelKatz]

I have an idea for a feature that could easily be added to the client. It would provide a simple way to backup private keys to paper. The basic idea is to add two RPC commands to the client -- an export command, and an import command. They would work as follows:

The 'export' command would take a BitCoin address whose private key was known to the client and export it in RFC1751 form. This includes a checksum, is case-insensitive, and is very easy for a human being to write down or read out loud. It will typically look like this:
BOGY CURE TIDE HIS DUNK GOOD FEUD GIBE FOUL FROM JOE NEST ADA SMUG FLAT MAKE MALI FAKE WINO ARK LAIN WERE TAN OVA

The 'import' command would take a private key in RFC1751 form and import it into the wallet, returning the BitCoin address and balance as well.

In the non-GUI case, you could use the existing 'listreceivedbyaddress' command to get keys to export. In the GUI case, we could include a way to get the exported keys for all addresses with non-zero balances in a form that could easily be printed. And, of course, a command to enter in a key and add it to the wallet.

This way, people can write their BitCoin private keys on a piece of paper (or print it), lock it in vault, or whatever. The idea is not to serve as a normal wallet backup for an active account. The idea is to serve as a long-term backup for balances that people do not expect to be using for an extended period of time. The biggest argument against it that I see is that it's too much effort for too narrow a use case.

[1715076010]

1715076010

[1715076010]

1715076010

[1715076010]

1715076010

[ShadowOfHarbringer]

+1, Excellent idea.

The same could be done to all kind of cryptographic information in Bitcoin - transactions, public keys, private keys and so.

This would make it possible to store your Bitcoin wallet entirely in Your brain !

[JoelKatz]

I came up with a few more use cases. Mailing BitCoins to someone on paper, communicating them to someone over the phone, and creating BitCoin 'cards' with a scratch-off code that would allow you to add them directly to your wallet.

[xanatos]

It seems to be something more funny than useful. These "words" don't add anything to simply using Base58 (and perhaps adding some huffman coding upon it to make it auto-error correcting). Two examples:

FEED and FEET. Their "distance" is one character (D and T) AND they have a similar sound (D and T are both dental consonants).
DIME and DINE. The only difference is a single segment. Are you sure an OCR will distinguish between them?

Another problem: the length of each "symbol" is variable (A, AD, ADA are three legal symbols), so the space is an important separator. ADADAD could be AD AD AD or ADA DAD.

[JoelKatz]

It seems to be something more funny than useful. These "words" don't add anything to simply using Base58 (and perhaps adding some huffman coding upon it to make it auto-error correcting).

They add pronouncability and case-insensitivity. Base58 is designed for machine consumption, RFC1751 is designed for human consumption.

Two examples:

FEED and FEET. Their "distance" is one character (D and T) AND they have a similar sound (D and T are both dental consonants).
DIME and DINE. The only difference is a single segment. Are you sure an OCR will distinguish between them?

Another problem: the length of each "symbol" is variable (A, AD, ADA are three legal symbols), so the space is an important separator. ADADAD could be AD AD AD or ADA DAD.

This isn't intended for OCR. There are better solutions for OCR. This is intended strictly for human use. I don't see how a human could lose a space. Humans do not think "therapist" is in any way similar to "the rapist".

In any event, the coding scheme doesn't have to be RFC1751. That's just nice, IMO, because it's a standard. But if people would prefer a BitCoin-specific method, maybe one that was more language neutral or added error correction and not just error detection, that's perfectly fine with me.

[xanatos]

Probably converting to Base36 and using the NATO phonetic alphabet would be better (alpha, bravo, charlie... one... zero). It's 5.16 bits/symbol, so only 0.7 bits/symbol less than Base58. Mmmmh secp256k1 is 279 + 65 bits. Base58 adds 32 bits for the crc (technically a truncated sha256) and I think 32 bits is the minimum we should add (but someone has noticed that sometimes you can change a single symbol and still the crc won't change, but if you save both private and public key this shouldn't be a problem... I think you can check if they are "connected" one to another so you could ignore the crc.), so it's 376 bits = 73 NATO "words" to save both public and private key together OR 352 = 69 NATO "words" without the "CRC". Made a test... Writing 4 "words" per row, 2 columns, on a Letter sheet with 0.5 inches of margin you can put 4 public/private "couples" at Arial 12 without any problem.

[JoelKatz]

You can store only the private key. I think a checksum is a pretty good idea. If the checksum doesn't match, you can easily search 'around' the checksum to make it match, checking all single-word replacements that pass the checksum against the block chain to see if they match any public key that appears there.

[xanatos]

Right. You can derive your public key from your private key with ECDSA. So it's 61 characters, and you can use 36 bits for CRC, or at least you could use a CRC-32 optimized for detecting errors, like the CRC-32C that is considered to be the best one.

[Pieter Wuille]

Private keys are 256 bit, public keys are 512 bit, signatures are 512 bits.

Encoded private keys are 279 bytes, encoded public keys are 65 bytes, encoded signatures are 72 bytes.

My showwallet branch has a patch that adds dumpprivkey and importprivkey commands, using base58 encoded private keys (only the actual 256 bit, plus 8 bits version number and 32 bits checksum), resulting in 51 characters.

[xanatos]

Even better then... I had trusted the comments on key.h . It's 56 "phonetic symbols" to codify 256 + 32 bits in base36.