edgecase_datafeed 156 2020-07-22 This is the date at the time of creation of this datafeed article. A checkpoint article containing a hash of this datafeed article may be created on this date or at a later date. 144 9 2020-05-28 bitcoin b27618deae05910f529240cc6960aeb87f017b12d302327253ee893825ce2bd4 632100 1HtwyqFWNVDoSEVqZwjBRRAV2oEsi8aQXr 13MfGs39pR5aEK4iKdoLjVYXKwi6Y3uyPq
How_to_write_a_Bitcoin_private_key_on_paper stjohn_piano 2020-07-21 yes 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. 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. 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. You can use a shorter key, but then it will be left-padded with '0' bytes until it is 32 bytes. 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 article Edgecase_Bitcoin_Storage_Toolset_version_2 edgecase 148 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 article An_investigation_into_recovering_from_transcription_errors_in_Bitcoin_private_keys edgecase 143 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 article Tools_for_storing_a_Bitcoin_private_key_with_a_checksum_tree edgecase 152 Tools for storing a Bitcoin private key with a checksum tree . This article consists of information originally published in article An_investigation_into_recovering_from_transcription_errors_in_Bitcoin_private_keys edgecase 143 An investigation into recovering from transcription errors in Bitcoin private keys , re-edited to focus on the titular problem.
iQIcBAABCgAGBQJfGCPZAAoJEC8RP+HmG9MXKIYP/jXg0UNnqqP29l35MnmJkn1o MXpvexpm+nbr9NYuxzMyPGdNvHMLjYnt6bA+BUuPHLwiyWjDtZF4Nua1aOXtsimP RxVJyqCPSFuf+C3xLr5rPArfAIxjDHbvyrwnyJ8LVtoRgh1EOgpgk0unpfk0NbOU 2ynzcIKcoVSHqJ6eontScOGj9o3kZbhe3Q0A9Xe5O7JJxhuUO+x/UMTrsm9F5GE9 uX5DAbxjw2nWqd5vQhs1vhJrprU1+Ol3+ygnfowigzRCVOiUIrVvXcWfmOkl6xK0 6b9Dh6kgTFYVWc7s1dB5VH7KzMW0jLpg9I7v8k2n/bTlSFY2XIiBLGM1B4yW8zgr 3AyEGHTEerbkXmLNz4QyAqgPA0CQ4Q0kGay+rHMpVTddAY3HEJ5P7lVH2zGNKP61 uUJFAIFxnxI9iqGy+nUd/65OH0lFggqD7JuLx+QSDEkAqY6gITbMXLAVsFq/yGKX BizG7vsEiTshRIN+FCwjgiaVr79mKbAd0CTe5xthc0iiIWPJPV2OeJcBzecORUxU Ro7FoQ/VLS9ol30W/wmh73GlaslS0s18FAoqSSo1us2Yfqc2Bc/xF+wjEdLppUqM Ov8SNCEg3D/wAuC7U7EPmoviUiMHfz8G8zTczkCt0ChVDwYwJkCJRs7/rn4HbtIu AwoiB8emHLU3mkKA/lnh =PvX+
iQIcBAABCgAGBQJfGCQrAAoJECL1OzZgiBhwFuIQAJ4pJsX0p71Aop5IEIsb8dPd OFZsKvLF74NVJt6sqNeCS/jNtw/1fWQBqRa9Y07Fd/sWQVHQhH4d6JCzfLWhjSq7 pMQeqTP7Un7VT0+kAvd424tBfCIgEZssR+sMPf4Rb45aWDOBZG79IMJ4xohu0q5P kwWs+qC2gVUczW4Fm5iKhJBrKzRAIQkPg7pnFzUsbkIwAMhffvbIV9K2cEIOu4YS gzC4qmHyodyvPXa+KuPELaRBNtNnzsrFvVOuFH2Mx9ul19Bn49tjhGsa764p3Ku1 NFxLCbtXPpFD8wtJsiqbyfjGZZOAu7q/KaLIPaYqQq6oesxD5mtrLz2rQQKMYYiK L1YZ+d4NkzAq8iOYmGIV37mjcdYKpSOYEnXbvcF3euYzHC+iW921FRMSgRmpw9xT yI5TJOYKCs9+wXZzzNBYX+ug2BYx2459M9tFfGeg6BbcT8ly3kavVkje4QVgstXp 5rIGkt/RLp2Lsv82BBDJpnQwh9HnnpS2jJnzkjtFhRXn3VQmgB+fgxG6jsrB7qKc ivZmP2SvS3peE7RUpt/BhN7hu7JZ7/iE843/s6Dsh1cxnpeRsFLGb9OkhzMM3xHA QG0trgolwQl7mJ710PewMcF4mkj8vkPLigcX4xmtzdZnhTc+HYtpSJnrlyiGYm1L 2tgrf8uKnLboFhPhLqdX =dEsW