|
Could you confirm that coins are not BTC on the first address of the first account (m/44'/0'/0'/0/0)?
I have processed all the dates in the range you mentioned and checked addresses but without result - so coins are somewhere else or I did something wrong...
|
|
|
|
Remember also that not all seed words generated are valid, the 12th/24th are checksums, so if it fails the checksum test it's obviously not the right mnemonic seed/date.
D'oh! And here we are trying to derive all seeds formed by the date shift combinations...  I have no idea how I'm going to fit a checksum function in the code though. It does not matter - you create words by shifting and then you try to generate address - seed is correct and it works or incorrect - so you may skip it. I would not focus on that during shifting. Still the questions are: - which address (derivation path) should be used? - what is the stake? - why do we do it? |
|
|
|
It means it could be BTC or ETH or both.
Oh, so I gave up. I processed around 10% dates & BTC addresses - first ones from the seed in BIP44: m/44'/0'/0'/0/0, but if your coins could be anywhere and even we do not know which coins we look for - it is waste of energy. Unfortunately, the BIP39 wordlist is the same for both BTC or ETH but the paths are different: For eth it's m/44'/60'/0'/0'/0. Only the Coin Type (second) number changes with each coin so in the wacky situation he is also hiding e.g. LTC (and at this point I strongly doubt it's a meager amount less than $100 if it's stored across multiple cryptos) then you just have to change the coin type to the number for LTC paths to search it was well. Yes, I know all of that, the problem is that first we must check if any generated address contains coins, so for each seed you must generate several addresses. Anyway - it is doable, generation of shifted seeds is easy, the problem lies in fact that you do not know what to generate from the given seed - too many possibilities. If it would be known that is it (for example) BTC on first address - it would make it easy. The knowledge that BTC is created using BIP44 is already a lot. But I do not want to waste time not knowing the stake. Later maybe I will commit to github Worker I created (based on my LostWord program) to solve 'shifted' seeds. |
|
|
|
It means it could be BTC or ETH or both.
Oh, so I gave up. I processed around 10% dates & BTC addresses - first ones from the seed in BIP44: m/44'/0'/0'/0/0, but if your coins could be anywhere and even we do not know which coins we look for - it is waste of energy. |
|
|
|
Remember that you don't know which crypto wallet this is, or if the award is only on one or more crypto wallets with the same seed words.
Does it mean that award is not on the first address (from first account)? |
|
|
|
|
I have a working solution - knowing address would make it much easier (faster), now I am stuck on creating list of addresses and checking them against addresses with balance (I must transfer file between machines etc.).
|
|
|
|
|
Doable...
Could you at least say which address we should check (first?) and if it is BIP32 or BIP84 or... ?
|
|
|
|
Tbh, If i would try to crack the puzzle I would fix the OpenCL Bug and implement the various optimizations from different forks of BitCrack. Then I would modify the code and instead of incrementing the key, i would decrement the key. I mean... there are alot of people scanning the whole 2^63 - 2^64 Range and they already scanned about 10-20% of it from the beginning already. So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys.
Check: http://ttdsales.com/64bit/login.phpThat project splits the work and sends the region to check. They will probably not tell you which parts were already checked, but at least they show the progress in subsets. Instead of using random numbers i am using some logical numbers where i take only 8 character of keys and the other 8 are my computation. https://imgur.com/Sd93EOtfor example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff... hope this trick will do something or maybe not  If you assume that address has any correlation with private key (like alphabetical order or so), then you are wrong. Address is created from hash functions, which completely destroy any order or correlation. The fact that your example address comes from known private key means completely nothing and cannot be any proof or base to assume that other address is somewhere 'near'. |
|
|
|
cant load my wallet which is why i'm trying to get the private key this way, the wallet is corrupted. i have the public address that the coins been sent and about the ''malware on that computer, you'll probably lose your money'' i'll be doing it off line so i should be good but thank you for the heads up
If you use Windows, just ignore the warning. Or install Virtual box https://www.virtualbox.org/ and then any Linux from image ( https://www.linuxlookup.com/linux_iso) and Linux version of litecoin wallet https://litecoin.org/#download |
|
|
|
You may try to run my program, with configuration like that (just an example with 6 words, not to wait too long): PERMUTATION_CHECK
bc1qnrumjaex7wvzj3mlpngwnd8s5supq26maps7r7
6
general
usual
hockey
melt
online
width
m/84'/0'/0'/0/0 it works that way: Using script P2WPKH
Using derivation path m/84'/0'/0'/0/0
--- Starting worker --- 2021-05-04 10:41:55 ---
Expected address: 'bc1qnrumjaex7wvzj3mlpngwnd8s5supq26maps7r7'
Using 8 threads
Input: general usual hockey melt online width
Found address on the derivation path m/84'/0'/0'/0/0
--- Work finished ---
Found result!
general usual hockey online width melt Are you sure the address generated was the first one on the derivation path? |
|
|
|
Hey I have already solver for the use case like yours: PERMUTATION on https://github.com/PawelGorny/lostwordI will print (save to file) all the possible seeds, you must import them into program. There is also another solver (PERMUTATION_CHECK) if you know the address. Let me know if you need any help with running it. How is your tolls different from btcrecover tool, and can your tool also work with electrum type seed that is not exactly using BIP39 word list? It does look more simple to use than btcrecover, but would also be nice to run your tool without java installation. Currently not, but I plan to add Electrum dictionary soon. If you really need it, it will be an extra motivation for me  |
|
|
|
|
Let's wait for @aquatic_ to see if they may find a list of potential addresses.
|
|
|
|
I will print (save to file) all the possible seeds, you must import them into program. What is the format/layout of the file your program creates using PERMUTATION? To import such a file in to btcrecover for use against an address database, it needs to be in the format of a text file with one seed phrase per line. I think just using btcrecover is going to be the better option in this case. He doesn't know the address, so PERMUTATION_CHECK is useless to him. If he uses PERMUTATION on a 12 word BIP39 seed phrase, he is going to be left with a text file with ~30 million seed phrase combinations in it. Surely simpler just to use btcrecover from the start, unless you know of another simpler program you can import 30 million seed phrases to and check against an address database? Hm, so so say that I should add possibility to check agains a 'pool' of addresses? Hmm... doable. If he knows how many BTC is locked, maybe he may narrow the list of addresses... in the best scenario to one Just download https://gz.blockchair.com/bitcoin/addresses/ and look for his amount. |
|
|
|
Hey I have already solver for the use case like yours: PERMUTATION on https://github.com/PawelGorny/lostwordI will print (save to file) all the possible seeds, you must import them into program. There is also another solver (PERMUTATION_CHECK) if you know the address. Let me know if you need any help with running it. |
|
|
|
I'm not in the mood to tinker with Java code at the moment and since this basically breaks wallet importing for me can you make a patch to add the checksum characters
Done in version https://github.com/PawelGorny/WifSolver/releases/tag/v0.5.1And multithreaded processing ;-) (why previous post was deleted?) |
|
|
|
@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.
I think END is for single thread only, try to launch it with SEARCH, it is multithreaded. How many characters are missing? Maybe this weekend I will add multithreading to END, to be honest I never had a serious case for it, so I was too lazy to do it for myself Anyway, if only end is missing and you are sure about the part you decoded, maybe bitcrack would be a better solution. I'm missing 11 characters, but End mode is only putting 7 characters at the end of each private key. This has to be a bug, because these keys can't be imported because their format is invalid. The idea is that I ignore last 4 characters and do not process them - because checksum part could be 'generated' based on decoded existing part. In other words - I prepare partial WIF (without checksum - in my version 4, but I think it could be 5 characters), I add any "stupid" characters just to have 52, I decode it ignoring incorrect checksum and encode again, receiving WIF with correct checksum this time. This part: for (int m = 0; m < missing; m++) {
sb.append("1");
}
byte[] bytes = Base58.decode(sb.toString());
bytes = Arrays.copyOfRange(bytes, 1, bytes.length - 4);
if (len == Configuration.COMPRESSED_WIF_LENGTH) {
bytes[32] = 1;
}
String encoded = Base58.encodeChecked(128, bytes);Later I process this WIF. Of course it could be optimized somehow, like extract private key and test it as a key, not as a WIF, but as I said - I was never focused on this worker, so I kept it simple. |
|
|
|
@PawGo, slightly off topic but is your solver multithreaded? Default config is only using one thread on my machine.
I think END is for single thread only, try to launch it with SEARCH, it is multithreaded. How many characters are missing? Maybe this weekend I will add multithreading to END, to be honest I never had a serious case for it, so I was too lazy to do it for myself Anyway, if only end is missing and you are sure about the part you decoded, maybe bitcrack would be a better solution. |
|
|
|
OK that makes sense. The position where there was supposed to be the compression byte and checksum, and a small part of the privkey hex, is messed up because that portion of the private key was lost. I am trying to brute force the end of this guy's missing key. So I should chop off another two hex chars at the end too. Exactly. What do you have? WIF without ending? Let me know if https://github.com/PawelGorny/WifSolver would help. |
|
|
|
|
Show Posts
