I investigated the use of an arithmetic checksum tree in Bitcoin private key storage. I found that this greatly helped to locate transcription errors and increase key recovery speed.







- Brief Summary
- Contents
- Summary
- Worked Example
- Generating The Checksum Tree
- Miscellaneous Details
- Writing A Bitcoin Private Key On Paper
- Writing A Bitcoin Address On Paper
- More Thoughts About Storing A Bitcoin Address
- Notes On Offline Storage Of Bitcoin
- Project Log







When writing a Bitcoin private key on paper, the goal is 100% accuracy. 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.

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.

Backup copies can help reduce risk, but you might make a mistake in each copy, or be worried that you had done so (and it is time-consuming to get a key out of storage and re-enter it into a computer to generate the address and thereby check the key's accuracy). Backup copies can also be lost or destroyed. It's good to plan for the scenario where you have a single remaining copy of the private key that is almost, but not quite, correct.

Storing an arithmetic checksum tree with a private key is cheap and dramatically improves key recovery time. 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.

If there is a random error in the private key, the checksum tree can be used to locate the group of 4 characters where the error exists. A program can be used to mechanically generate all variants of this group, and test all resulting variants of the private key. A group of 4 random hex characters can have 16^4 = 65536 possible values. On commodity hardware, this would take 3 hours.

If there are errors in multiple groups, we can use the checksum tree to divide up the problem. Each group could be varied to find the group values that generate the correct checksum character, and then the permutations of these group values could be tested to find the correct key. I haven't tested this approach in this project.

Transcription errors in the checksum tree can be identified by re-generation of the tree. If almost all the tree is unchanged, then a transcription error is the likely cause of the difference. In contrast, errors in the private key will produce further errors in the higher levels of the re-generated tree.

Final scenario: There are errors in both the private key and the checksum tree. In this case, a more inventive approach would be required. The checksum tree could be treated as "partial truth", and a more complex program could vary the groups until it found a partial match with the checksum tree. These partial matches could then be tested to see if they produce the correct address. I haven't tested this approach in this project.

A further consideration: These key-recovery approaches depend on having the correct Bitcoin address. The Bitcoin address is necessarily public, and can be shared with anyone without risk to the bitcoin held in it. It also has a hash-based checksum embedded within it, which permits mechanical error detection. Since the address is public, you can store multiple copies of it on network-connected computers, which means that it's not really as much of a resilience gain to design and use a checksum tree for it.

Bonus (assuming that there are no errors in the stored private key): When entering the private key into an offline computer, generating the checksum tree is a convenient way to discover and locate any transcription errors made during this process.









Here is a Bitcoin private key:



The corresponding Bitcoin address is:



We can generate a checksum tree and place it above the key:




Let's suppose that in the private key, in Line 3, Group 1, the first character "3" was accidentally written as "8".

When we enter the key into an offline computer, and re-generate a checksum tree, we would see this:



The checksum character at the top of the tree is different, which alerts us that there is a problem.

The third character in the checksum group on the second level of the tree is different, which tells us to look at the third group in the next level down.

In the third group of the checksum line, the first character is different. So: We know that the error is in Group 1 of Line 3 in the private key. We can then run a program that will vary this group until the correct key is found.











Standard human numbers are base 10 and the digits are:


Hex numbers are base 16 and the digits are:


Description of hexadecimal addition table: Two axes, X and Y. X runs horizontally along the top of the table. Y runs vertically down the left side of the table. Both X and Y contain the hex values 0-f. Each entry in the table is the hex sum of the relevant X and Y values. Examples: 0 + 0 = 0, 2 + 4 = 6, 5 + 5 = a, b + 7 = 12, f + f = 1e.

The minimum sum of a group of 4 hex characters is:
0 + 0 + 0 + 0 = 0

The maximum sum of a group of 4 hex characters is:
f + f + f + f = 1e + f + f = 2d + f = 3c

Algorithm:
- Sum the values in a group of 4 characters. Take the last character of this sum.
- Do the previous step for each group in a line of 4 groups. This will produce 4 checksum characters. Write this new group on a new line.
- Do the previous step for each line in the 4 lines that form a private key, writing each new group on the same new line. Result: A single new "checksum line" of 4 groups.
- Sum the values of each group in the checksum line. Take the last character of each sum. This will produce a single "checksum group" of 4 characters. Write this on a new line.
- Sum the values of the checksum group. Take the last character of the sum. This is a single "checksum character". Write this on a new line.











My work machine:

System details:
- Name: Shovel
- Specifications: HP 6005 Pro SFF. 3 GHz x86_64 processor (AMD II x4 B95 Quad Core), 4 GB RAM, 1 TB hard drive. Running CentOS 7.6.1810 (Core).
- More information: New computer: Shovel
- Installed items: GCC 4.8.5, Make 3.82, Vim 7.4, Python 2.7.5, Python 3.3.2, Gnome 3.28.2, gedit 3.28.1, GPG 1.4.10.











A Bitcoin private key is 32 bytes long. A byte can be written as 2 hex characters. The private key below is written in hex and is therefore 64 characters long.



I have found it easiest to divide the key into groups of 4 characters, and lines of 4 groups.

This division process can be automated:



So: The key is now a 4x4x4 grid of characters. This format makes it much easier to:
a) read on a computer screen and write onto paper
b) read from paper and write into a computer file
c) check the new copy against the old one

Notes:
- 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 is best to take every opportunity to remove possible ambiguity.
- 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 run over onto thick line markings, as this could make a character ambiguous.











Here is the address from earlier:



The possible characters in a Bitcoin address are:
- 0-9 with no 0
- A-Z with no I or O
- a-z with no l

The 0, I, O, and l characters were excluded due to possible confusion with i and o.


When writing an Bitcoin address on paper, I have found it best to take these steps in order to reduce ambiguity:
- Underline every capital letter, taking care not to allow the underline to touch the character or any other nearby character.
- For a "1" character, include the extra bottom and diagonal lines (i.e. "1"), rather than writing only a single vertical line (i.e. "|").
- Add a tail to u/U to distinguish it from v/V.
- Cross the middle of z/Z to distinguish it from 2.
- Cross the top of a capital J, because you might as well do this.

Also, like a private key, it's easiest to write the characters in groups of four with a space between each group. Some letters will be left over that do not form a complete group of four.

The division-into-groups process can be automated:





Further notes:
- Be careful when underlining F, as if the underline is too close, it could look like E.
- Be careful when underlining 7. If you cross it with a horizontal line, it could look like Z when underlined. If you don't cross it, it could look like 2 when underlined.
- Make sure to close the loop properly on a 6, so that it doesn't look like G. Similarly, be careful not to close the loop on G, so that it doesn't look like 6.
- Underline 6 to distinguish it from b. This makes the overall underlining rule into "Underline capital letters and 6, and be careful of F and 7".
- Extend the tail in g so that it forms into a loop, preventing g from looking like q or 9.
- Add an upwards-diagonal tail to q, so that it doesn't look like 9.













Steps that can be taken to preserve an accurate copy of a Bitcoin address on an online computer:
- In a text file, don't just keep a single copy of the address. Keep several copies on a few consecutive lines. Some text editors, when you select a string and highlight it, highlight other identical strings in the document. This can be used as a quick test to confirm that all copies of the address are identical (i.e. that no copy has a typo).
- Keep a backup copy of the address-storage text file in the same directory.
- Backup the address storage data onto multiple external storage units.




Storing the address in offline storage:
- Write out the address next to the private key. This has several advantages:
-- The balance held by the key can be looked up via the address without re-calculating the address from the key.
-- A written-out address, kept offline, is a more resilient copy of the address. Address copies kept on network-connected computers might conceivably be altered by mistake or by third parties.
-- When the key is entered into an offline computer, the address can be used as an additional confirmation of the newly entered key's accuracy, by comparing it to the address generated from the entered key. If a transcription error has been made in the private key during the original storage or during entry into the offline computer, the generated address will be different.
- Design the offline storage in such a way that the private key is not exposed when you use it to view the address. Private keys can be stolen via cameras.
- Create a name for your own use for each private key and address combination, so that you can more easily differentiate between combinations. Store the name on the offline storage together with the combination. On a networked-connected computer, where you might look up the balance on this address, keep the name with the address.











- Make at least two copies of the private key.
- Use a waterproof container to protect against water damage.
- Use backups in two separate locations to protect against fire damage.
- Think about the risk of theft: How can the storage unit be made inconspicuous and/or difficult to steal?
- Do not open the offline storage unit near a camera or potential camera.
























Let's take this Bitcoin private key from an earlier article as an example:



A Bitcoin private key is 32 bytes long. A byte can be written as 2 hex characters. The key above is written in hex and is therefore 64 characters long.



When writing a Bitcoin private key on paper, the goal is 100% accuracy: A single mistake could lose all the bitcoin. Backup copies can help, but you might make a mistake in each copy, or be worried that you had done so (and it is laborious to re-copy the key into a computer to generate the address and thereby check the key's accuracy).

I have found it easiest to divide the key into groups of 4 characters, and lines of 4 groups.

This division process can be automated:



So: The key is now a 4x4x4 grid of characters. This format makes it much easier to:
a) read on a computer screen and write onto paper
b) read from paper and write into a computer file
c) check the new copy against the old one

Notes:
- 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 is best to take every opportunity to remove possible ambiguity.
- 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 run over onto thick line markings, as this could make a character ambiguous.

Unfortunately, despite all this effort to avoid inaccuracy and ambiguity, a mistake will almost certainly be made eventually while writing a copy of a private key. Let's suppose that the other backup copies have been lost or destroyed in accidents, and that there is only one remaining copy. A single inaccurate character in this private key could cause the loss of all bitcoin stored in the corresponding address. Reason: 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 a valid private key by brute-force mechanical address generation.

However, if the location of the error can be found, then the characters in that location can be mechanically varied, and candidate addresses generated from these variant private keys until one produces the desired address. As long as the location comprises only a limited number of characters, a small-scale brute-force approach can work.

Hm. Now that I think about it, if you started with a private key that you are quite sure is 95%-99% accurate but has a mistake (or several) somewhere in it, whose location is unknown, you would not have to brute-force the entire key possibility space. You could proceed in this manner:
- Assume that 1 character is wrong. Vary each character in the private key through the possible 16 hex values. See if the desired address is generated.
- Assume that 2 characters are wrong. Vary all possible pairs of characters in the private key.
- Assume that 3 characters are wrong, etc.

This approach is time-consuming, even if programs are written to automate a lot of the work. However, it is still feasible, and the reward would likely be worth the effort.

Anyway: Let's plan for a mistake to be made, and try to store the key in such a way that this mistake can be easily located.

After some thought, I've decided to use an arithmetic checksum tree.

Approach:
- Sum the values in a group of 4 characters. Take the last character of this sum.
- Do the previous step for each group in a line of 4 groups. This will produce 4 checksum characters. Write this new group on a new line.
- Do the previous step for each line in the 4 lines that form a private key, writing each new group on the same new line. Result: A single new "checksum line" of 4 groups.
- Sum the values of each group in the checksum line. Take the last character of each sum. This will produce a single "checksum group" of 4 characters. Write this on a new line.
- Sum the values of the checksum group. Take the last character of the sum. This is a single "checksum character".

The advantage of this approach is that, if necessary, the checksum tree can calculated manually using pencil and paper. This would be much less feasible if a hash tree was used instead of an arithmetic sum tree.

So: Store the private key with a checksum tree. If, when a copy is made, there is a mistake in the private key, then the checksum tree can be used to locate the group of 4 characters where the mistake exists. A program can be written to mechanically generate all variants of this group, and test all resulting variants of the private key.

Let's work through this approach and thereby test it.

Standard human numbers are base 10 and the digits are:


Hex numbers are base 16 and the digits are:


We'll be doing arithmetic in base 16.

I'm using a useful hexadecimal addition table that I found here:
www.tutorialspoint.com/computer_logical_organization/hexadecimal_arithmetic.htm

Description of hexadecimal addition table: Two axes, X and Y. X runs horizontally along the top of the table. Y runs vertically down the left side of the table. Both X and Y contain the hex values 0-f. Each entry in the table is the hex sum of the relevant X and Y values. Examples: 0 + 0 = 0, f + f = 1e.

The first group in the private key is:
7972

7 + 9 = 10
10 + 7 = 17
17 + 2 = 19

The sum of the first group is 19. The last character of this sum is 9.

The second group in the private key is:
b641

b + 6 = 11
11 + 4 = 15
15 + 1 = 16

The sum of the second group is 16. The last character of this sum is 6.

Group 3: 101c
1 + 0 + 1 + c = e
Last character: e

Group 4: 0ad6
0 + a + d + 6 = 17 + 6 = 1d
Last character: d

So: The first group on the checksum line is: 96ed

Let's proceed through line 2 of the private key:
7b0e 401b 800a 9b6f

7 + b + 0 + e = 12 + e = 20
4 + 0 + 1 + b = 5 + b = 10
8 + 0 + 0 + a = 12
9 + b + 6 + f = 14 + 6 + f = 1a + f = 29
Last characters: 0029

Line 3 of the private key:
3225 c97f c6b8 1150

3 + 2 + 2 + 5 = 7 + 5 = c
c + 9 + 7 + f = 15 + 7 + f = 1c + f = 2b
c + 6 + b + 8 = 12 + b + 8 = 1d + 8 = 25
1 + 1 + 5 + 0 = 7
Last characters: cb57

Line 4 of the private key:
42cf 6696 8c2f b2e5
4 + 2 + c + f = 6 + c + f = 12 + f = 21
6 + 6 + 9 + 6 = c + 9 + 6 = 15 + 6 = 1b
8 + c + 2 + f = 14 + 2 + f = 16 + f = 25
b + 2 + e + 5 = d + e + 5 = 1b + 5 = 20
Last characters: 1b50

So: The checksum line for this private key is:
96ed 0029 cb57 1b50


Detour:

The minimum sum of a group of 4 hex characters is:
0 + 0 + 0 + 0 = 0

The maximum sum of a group of 4 hex characters is:
f + f + f + f = 1e + f + f = 2d + f = 3c


Next: Calculate the checksum group from the checksum line:
96ed 0029 cb57 1b50

9 + 6 + e + d = f + e + e = 1d + d = 2a
0 + 0 + 2 + 9 = b
c + b + 5 + 7 = 17 + 5 + 7 = 1c + 7 = 23
1 + b + 5 + 0 = c + 5 = 11
Last characters: ab31

So: The checksum group for this private key is ab31.

Next: Calculate the checksum character from the the checksum group:
a + b + 3 + 1 = 15 + 3 + 1 = 18 + 1 = 19
Last character: 9



Here is the original private key:


Using the checksum line, group, and character, the key can be written like this:




Let's automate the generation of the checksum tree.







And now run this program.





This matches the earlier manually-generated result.



Let's sketch out a scenario where we make use of the checksum tree.

Let's suppose that:
- We have written out the key and the checksum (in the form shown above) onto a piece of paper.
- Without noticing it, we have made an error. Location: Line 3, group 1, character 1. We have accidentally written "8" instead of "3".

So: We discover the error when we manually copy the key from paper storage onto an offline computer and run generatePrivateKeyChecksumTree.py on it. We look at the checksum character on the first line of the tree and see that it is different. This alerts us to the problem.

Let's simulate this by generating the checksum tree for the altered private key.

Here's the altered private key:



Remove the whitespace:



Use this altered key as input for the python program:





Next: Compare checksum trees:


Original key and checksum:


Altered key and checksum:



So:
- In our scenario, the original checksum tree is written on our paper storage system. The altered checksum is displayed on an offline computer where we have generated it from the altered key.
- We look at the top of the checksum tree. Instead of "9" as expected, we see "e". Therefore, we investigate further.
- We look at the checksum group. Instead of "ab31", we see "ab81". The third character is different. This indicates that the error is in Line 3 of the private key.
- We look at the third group in the checksum line, which is "1b57" instead of "cb57". The first character is different, which indicates that the error is in Line 3, Group 1, of the private key.
- We've narrowed down the location to 4 of the characters, out of 64 in total.


Let's get the address that corresponds to the original key.


We got the key from this earlier article:
Bitcoin transaction test set

Searching for this private key in the article leads to a record of the corresponding address, which is:
16ASCUS3s7D4UQh6J9oHGuT19agPvD3PFj

Let's double-check this.

Follow this recipe to generate the address from the private key:
Recipe for generating a Bitcoin address





Compare equality of the two addresses.

Original address from earlier article:
16ASCUS3s7D4UQh6J9oHGuT19agPvD3PFj

Generated address:
16ASCUS3s7D4UQh6J9oHGuT19agPvD3PFj



Cool. They're identical. This is the correct address.




Next: Vary the hex values in the error location until the desired address is generated, showing that we have found the correct private key.

We'll only vary one character at a time.

There are four characters in a group.

Number of variants: 16 (values per character) * 4 (characters) = 64 variants.

We could try each variant manually, but instead we'll automate it from the beginning.







And run the program.





We see that the program has replaced the "8" in Line 3 Group 1 with "3", thereby producing the correct private key.




Let's consider another scenario. We've located the error in a group, but we don't know how many mistakes are in that group. All four of the characters could be wrong.

A group of 4 random hex characters can have 16^4 = 65536 possible values.




My work machine:

System details:
- Name: Shovel
- Specifications: HP 6005 Pro SFF. 3 GHz x86_64 processor (AMD II x4 B95 Quad Core), 4 GB RAM, 1 TB hard drive. Running CentOS 7.6.1810 (Core).
- More information: New computer: Shovel
- Installed items: GCC 4.8.5, Make 3.82, Vim 7.4, Python 2.7.5, Python 3.3.2, Gnome 3.28.2, gedit 3.28.1, GPG 1.4.10.




Copy findErrorInPrivateKey.py to create findErrorInPrivateKey2.py.

Change the function to be:






Run the program.






Time taken: 10:12:35 - 09:33:54 ~= 38.5 minutes


We found the correct key after searching 20% of the keyspace.

So to search the entire keyspace would take approximately:
38.5 minutes * 5 = 192.5 minutes ~= 3.2 hours


Ok. So, although it will take a little time and effort, a private key is retrievable in the event of an error that can be narrowed down to a particular group. The entire group can be wrong.

Note: Using a faster language than Python for the Bitcoin address generation subroutine would speed this program up quite a lot.

Even if multiple groups are wrong, we can use the checksum tree to divide up the problem. We could iterate over each group until its last checksum digit matches the checksum value on the next level, then check the entire key.





Another scenario: What if there is a mistake in the checksum tree?


Original key and checksum:



Let's suppose that the checksum group is incorrectly written down on paper as "a631". The "6" should be a "b".

Then: We then manually enter the private key on an offline computer. We re-calculate the checksum tree. We notice that the checksum group is incorrect. If the generated checksum character and the checksum line are identical to the written copy, then we know that the discrepancy is due to incorrect copying.

The same applies to the checksum character having an incorrect value.

If the error were instead on the checksum line, this would narrow down the location of the error to:
a) a copy error in the group on the checksum line
b) an error in the corresponding group in the private key

(a) is easily checkable - calculate the checksum of the group in the private key.
(b) can be approached with the method we used earlier for varying an entire group.




Let's suppose that there were 2 or more errors, in both the private key and the checksum tree.

Well, in this case, a more inventive approach would be required. A more complicated program could be written that would vary the values of several characters, in both the key and the checksum tree, to try to find the correct key variant. We would expect the correct key to produce a checksum tree variant that is nearly identical to the recorded checksum tree. Essentially, we would treat the checksum tree as a partial / probabilistic truth, rather than an absolute one.






Final scenario: Let's explore how long it would take to search a private key for a) 1 error b) 2 errors c) 3 errors, without relying on a checksum tree. The error locations are random.


For 1 error, we're going to vary each of the 64 key characters through the 16 possible hex values. This is 64*16=1024 operations.

For 2 errors: For each of the operations in the 1-error scenario, we would hold our current character constant, and then we would have to vary the other 63 characters through the 16 hex values. 63*16=1008 operations. So in total, we would have to perform 1008 * 1024 = 1032192 operations.

For 3 errors: Similar approach. For each of the 1032192 operations in the 2-error scenario, we would do 62*16=992 operations. In total, 992 * 1032192 = 1023934464 operations.

Well, essentially, we can see that each extra error that we search for increases the search cost by a factor of approximately 1000.




We'll start from the same altered key as before, and write a program that implements these approaches.







Run the program.



So: Approximately 1.5 mins to find the correct key.

The keyspace was 1024 variants in total. We've processed about 50% of the keyspace.

So: To iterate across the whole keyspace would take ~1.5 * 2 = ~3 mins.


Let's test with
varyPrivateKeyForMultipleErrors()
instead of
varyPrivateKeyForOneError()

Uncomment lines 35, 36, and 46. Comment out lines 34 and 45.





Same time taken. This indicates that the recursive function works, at least for numberOfErrors = 1.


Let's try with numberOfErrors=2.

Change the last character of the key from "5" to "6", so that there are now 2 errors. In the settings section, set numberOfErrors=2.

While the program is running, let's do a little maths:
- 1 error: 3 mins to get through the keyspace on this machine, using a Python codebase.
- We assume that each extra error that we search for increases the search cost by a factor of approximately 1000.
- 2 errors: 3 mins * 1000 = 3000 mins = 50 hours ~= 2.1 days
- 3 errors: 3 mins * 1000 * 1000 = 3000000 mins = 50000 hours ~= 2083 days ~= 5.70 years
- 4 errors: 3 mins * 1000**3 = 3 * 10**9 mins = 50000000 hours ~= 2083333 days ~= 5704 years

So... 2 errors is the tolerable margin of error in copying a private key. It's feasible to contemplate searching the keyspace for 3 errors, if you invested effort into a faster codebase and machine.










I've stopped the program and run the command again immediately after stopping. We've gone far enough (2%) to make an estimate.


Time taken:
12:53:47 - 11:51:14 ~= 62.5 minutes for 2% of keyspace.


To process the entire keyspace would take approximately:
62.5 minutes * 50 = 3125 minutes ~= 52 hours ~= 2.17 days


This matches our earlier estimate of 2.1 days.






Another consideration: These key-recovery approaches depend on having the correct Bitcoin address.

The Bitcoin address is necessarily public, and can be shared with anyone without risk to the bitcoin held in it. It has a hash-based checksum embedded within it.

Since the address is public, copies of it do not have to be kept offline.

Because we can store multiple copies of an address on network-connected computers, it's not really as much of a resilience gain to use a checksum tree for it, although obviously you could do so if you wish.

Steps that can be taken to preserve an accurate copy of a Bitcoin address:
- In a text file, don't just keep a single copy of the address. Keep several copies on a few consecutive lines. Some text editors, when you select a string and highlight it, highlight other identical strings in the document. This is a quick test to confirm that all copies of the address are identical (i.e. that no copy has a typo).
- Keep a backup copy of the address-storage text file in the same directory.
- Backup the address storage data onto multiple external storage units.
- Write out the address next to the private key. This has several advantages:
-- The balance held by the key can be looked up via the address without re-calculating the address from the key.
-- A written-out address, kept offline, is a more resilient copy of the address. Address copies kept on network-connected computers might conceivably be altered by mistake or by third parties.
-- When the key is entered into an offline computer, the address can be used as an additional confirmation of the newly entered key's accuracy, by comparing it to the address generated from the entered key. If a transcription error has been made in the private key during the original storage or during entry into the offline computer, the generated address will be different.
- Create a name for your own use for each private key and address combination, so that you can more easily differentiate between combinations. Write the name on the offline storage paper. On a networked-connected computer, where you might look up the balance on this address, keep the name with the address.
- Design the offline storage in such a way that the private key is not exposed to view when you use it to view the address. Private keys can be stolen with cameras.




Let's go over possible problems with storing an address.

Here is the address from earlier:
16ASCUS3s7D4UQh6J9oHGuT19agPvD3PFj

The possible characters in a Bitcoin address are:
- 0-9 with no 0
- A-Z with no I or O
- a-z with no l

The 0, I, O, and l characters were excluded due to possible confusion with i and o.

When writing an Bitcoin address on paper, I have found it best to take these steps in order to reduce ambiguity:
- Underline every capital letter, taking care not to allow the underline to touch the character or any other nearby character.
- For a "1" character, include the extra bottom and diagonal lines (i.e. "1"), rather than writing only a single vertical line (i.e. "|").
- Add a tail to u/U to distinguish it from v/V.
- Cross the middle of z/Z to distinguish it from 2.
- Cross the top of a capital J, because you might as well do this.

Also, like a private key, it's easiest to write the characters in groups of four with a space between each group. Some letters will be left over that do not form a complete group of four.

The division-into-groups process can be automated:





Further notes:
- Be careful when underlining F, as if the underline is too close, it could look like E.
- Be careful when underlining 7. If you cross it with a horizontal line, it could look like Z when underlined. If you don't cross it, it could look like 2 when underlined.
- Make sure to close the loop properly on a 6, so that it doesn't look like G. Similarly, be careful not to close the loop on G, so that it doesn't look like 6.
- Underline 6 to distinguish it from b. This makes the overall underlining rule into "Underline capital letters and 6, and be careful of F and 7".
- Extend the tail in g so that it forms into a loop, preventing g from looking like q or 9.
- Add an upwards-diagonal tail to q, so that it doesn't look like 9.





Good. That's the end of this project.