 |
Bitcoin paper pockets —- TL;DR Consumer purchased some BTC in 2014, and saved them on a so-called "paper pockets". They nonetheless had the handle of the BTC (that we might nonetheless see on the blockchain, unmoved since 2014), and the paper pockets with the personal key. Sadly, the personal key checked out as "invalid" (i.e. dangerous checksum) every time shopper tried to entry the pockets, for the final 10 years. Consumer offered us the picture of the paper pockets displaying the personal key, and a partial QR code. Consumer generated and printed the paper pockets utilizing one of many "BTC paper pockets generator" web sites that was common on the time to generate "BTC paper wallets". (components of the personal key picture have been redacted for privateness) We had been capable of finding the problem with the printed personal key and recuperate the BTC. The probably explanation for the problem is that the font knowledge was in some way corrupted on the pc that printed the personal key on the time. —- Lengthy model: Learn the TL;DR first. This picture was the one model of the personal key that shopper had. It’s not very sharp, however ok to learn all of the characters. And it contained a partial QR code. The personal secret’s in so known as "wif" format (Pockets Import Format), encoded in base58, with 51 characters. The "wif" format used for BTC personal keys is principally a uncooked BTC personal key, with 4 bytes of double-SHA256 checksum added on the finish, and encoded in base58. The partial QR code might have been helpful to determine what was unsuitable with the personal key. However we didn’t discover any free or opensource instrument that might simply extract usable knowledge from a partial QR code. So we determined that for now, it might be an excessive amount of effort to strive utilizing data from the partial QR code picture. Wanting on the personal key, most characters (together with people who we redacted) had been completely unambiguous. The primary questionable character, on the suitable of the primary X, seems like a round blob, however it could possibly solely be an "e", as the opposite lowercase candidates ("o", "s" and "a") seem afterward, and are clearly distinct. The subsequent character, simply earlier than the subsequent "X", seems like a vertical bar, so it could possibly be an "l" (lowercase L), an "I" (uppercase i), an "i" or a "1" (digit). Decrease case "L" and uppercase "I" aren’t allowed in base58. The digit "1" all the time has a component protruding on the top-left, so we determined it was not "1". The final risk is "i", however surprisingly there is no such thing as a seen area below the dot of the "i". However in case you look additional, you see a personality that’s clearly a "j" (lowercase J), and it too doesn’t have a visual area below the dot. So we had been fairly certain our "l" was the truth is an "i". The subsequent fascinating character, on the suitable of the second "X", seems like a "7" however with a vertical bar, as a substitute of the usually diagonal bar of the "7". However there is no such thing as a different base58 character that appears prefer it, so we figured that this font had a "stylized" form for the glyph "7". This "7" character seems at 3 areas within the string, as you possibly can see. The ensuing "wif" string we received was incorrect (dangerous checksum), and that was a string that our shopper had already examined. And even ignoring the invalid checksum, the personal key didn’t result in the account the place the BTC had been. So we determined to do a bruteforce search, assuming that as much as 3 characters within the "wif" string had been utterly incorrect. We wanted the code to examine {that a} "wif" string checksum was legitimate, and to generate the corresponding BTC handle (that we had in "wif" format too, i.e. a so known as legacy BTC handle). In reality, there are two codecs for the "wif" BTC handle: One is known as "public key (uncompressed), and the opposite one as "public key (compressed)", and from the BTC handle we had, it was not potential to know what format it was utilizing – with out realizing the personal key. So we needed to generate each addresses (uncompressed and compressed) for every personal key, to examine if certainly one of them matched our recognized BTC handle. Since we didn’t have the code to calculate the BTC public keys from the "wif" personal key, we requested ChatGPT to assist us:
All of the code that we received from ChatGPT was bogus (e.g. it forgot to name the elliptic curve operate!!), and we instructed it to the AI:
ChatGPT saved us a while, however we nonetheless needed to spend a number of hours debugging, fixing and optimizing ChatGPT's code, and testing that it labored accurately utilizing some test-cases. We then began the bruteforce seek for 3 unsuitable characters anyplace within the "wif" string (which was estimated to take a couple of days utilizing no GPU). Whereas the bruteforce search was working, we thought that the truth is, the one actually questionable character was this unusual "7" with the vertical bar. So we modified the bruteforce search to solely take a look at all potential base58 characters on the 3 positions the place these unusual "7" characters seems. After a couple of seconds, we hit our BTC public key! So we discovered the right personal key: The character wanting like a "7" was the truth is a "T", with the suitable a part of the horizontal bar lacking. So the probably clarification is that the font knowledge for the "T" glyph was in some way corrupted on the pc that printed the personal key on the time. All of the BTC had been efficiently recovered utilizing this right personal key. submitted by /u/loupiote2 |
