edgecase
Author: StJohn Piano
Published: 2020-07-22
Datafeed Article 156
This article has been digitally signed by Edgecase Datafeed.
This article has been digitally signed by its author.
1060 words - 233 lines - 6 pages




When you are writing a Bitcoin private key on paper, the goal is 100% accuracy. A few errors can make it effectively impossible to recover the correct version of the key - it could take thousands of years to check all the plausible variants of the incorrect key. [0]

So: It is crucial to focus on writing the key in a way that removes any possible ambiguity.

Making multiple copies of a key will help, but this is not a complete solution. Backup copies can be lost or destroyed. It's best to plan for the scenario where you have a single remaining copy of the private key. Therefore, it's also best to make each copy as unambiguous as possible.

Here is an example Bitcoin private key:

7972b641101c0ad67b0e401b800a9b6f3225c97fc6b8115042cf66968c2fb2e5


This key is written in hexadecimal ("hex" for short). Hex is the most convenient way to write byte sequences. Each byte is written as two hex characters. Hex characters consist of the ten digit characters "0123456789" and the lower-case alphabetic characters "abcdef".

A Bitcoin private key consists of 32 bytes. [1] A 32-byte private key is 64 hex characters.

The corresponding Bitcoin address for this private key is:

16ASCUS3s7D4UQh6J9oHGuT19agPvD3PFj





Approach 1: Single line

Write down the key in exactly the form shown here:

7972b641101c0ad67b0e401b800a9b6f3225c97fc6b8115042cf66968c2fb2e5


This is the key format that a Bitcoin software tool would accept.

Problems:
- It's difficult to tell if you've written out exactly 64 characters. You might skip one by accident.
- If you are making another copy of this key (by writing it out again on another piece of paper), then it will be difficult to compare the two copies against each other and confirm that they are the same.




Approach 2: Grid pattern

I prefer to divide a key into groups of 4 characters and lines of 4 groups.

7972 b641 101c 0ad6
7b0e 401b 800a 9b6f
3225 c97f c6b8 1150
42cf 6696 8c2f b2e5


With this format, it's easier to:
- See at a glance that all 64 characters are present (i.e. that the 4x4x4 grid does not have any gaps).
- Read on a computer screen and write onto paper.
- Read on paper and type into an offline computer.
- Compare two keys and find any differences.

The division process can be automated:

[spiano@shovel ~]$ echo -n "7972b641101c0ad67b0e401b800a9b6f3225c97fc6b8115042cf66968c2fb2e5" | fold --width 16 | sed 's/.\{4\}/& /g'; echo "";

7972 b641 101c 0ad6
7b0e 401b 800a 9b6f
3225 c97f c6b8 1150
42cf 6696 8c2f b2e5


In a similar way, the grid pattern key can be turned back into a single line. You would do this in order to pass the key to a Bitcoin software tool (e.g. in order to create and sign a transaction offline).

[spiano@shovel test]$ echo -n "7972 b641 101c 0ad6
7b0e 401b 800a 9b6f
3225 c97f c6b8 1150
42cf 6696 8c2f b2e5" | tr '\n' ' ' | sed 's/ //g' ; echo ""

7972b641101c0ad67b0e401b800a9b6f3225c97fc6b8115042cf66968c2fb2e5





Notes on writing a Bitcoin private key clearly on paper

- Although hex characters are clearly distinct on a computer screen, the characters "6" and "b" can sometimes be difficult to distinguish when written on paper. Therefore, underline the "6" character, taking care not to allow the underline to touch the character or any other nearby character.

- When writing a "1" character, include the extra bottom and diagonal lines (i.e. "1"), rather than writing only a single vertical line (i.e. "|").

- It can be convenient to write the key on squared or lined paper. However, if you do, then be careful that the written characters do not cross any thick line markings, as this could make a character ambiguous.




Approach 3: Grid pattern with arithmetic checksum tree

In this format, an arithmetic checksum tree is generated for the key, and added above it.

9
ab31
96ed 0029 cb57 1b50

7972 b641 101c 0ad6
7b0e 401b 800a 9b6f
3225 c97f c6b8 1150
42cf 6696 8c2f b2e5


Advantages of this format:
- Storing an arithmetic checksum tree with a private key is simple and dramatically improves key recovery time. Errors in the private key can be narrowed down to specific groups of 4 characters.
- It is much easier to compare two copies of a key. Focus most of your attention on the top of the tree, and work your way down. This is particularly useful when you transfer a key from paper storage to an offline computer, and want to confirm that no errors were introduced during the transfer.

Note: As long as the single digit at the top of the tree is always correct, any errors can be mechanically located and resolved.

For more detail, please see the project An investigation into recovering from transcription errors in Bitcoin private keys.

The generation of the checksum tree can be automated (and performed on an offline machine), or it can be performed manually on paper with the help of a hexadecimal addition table.

I have written tools that allow a user to easily:
- Add an arithmetic checksum tree to a Bitcoin private key.
- Validate the checksum tree and remove it.

These tools can be downloaded from the article Tools for storing a Bitcoin private key with a checksum tree.










[start of notes]



This article consists of information originally published in An investigation into recovering from transcription errors in Bitcoin private keys, re-edited to focus on the titular problem.


[end of notes]











[start of footnotes]


[0]
There are 2^256 possible private keys, and one of the security aspects of the Bitcoin cryptosystem is the enormous infeasibility of trying to find an unknown valid private key by brute-force mechanical address generation. Even if you know most of the key already, it can still be very difficult to recover it.

If you write a Bitcoin private key on paper and make 1 random transcription error (i.e. 1 character is incorrect), the key can be recovered in 3 minutes using commodity hardware.

If you make 2 random transcription errors, the key can be recovered in 2 days.

If there are 3 random errors, recovery will take 5 years. A faster codebase and machine, or cluster of machines, could bring this time down to something more tolerable.

Recovering the key requires testing variants of the private key, to see if they produce the correct Bitcoin address. Each additional random transcription error multiplies the number of required tests by a factor of approximately 1000.

[return to main text]

[1]
You can use a shorter key, but then it will be left-padded with '0' bytes until it is 32 bytes.

[return to main text]

[end of footnotes]