|
1
|
Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys
|
on: May 16, 2021, 09:39:56 AM
|
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'. |
|
|
|
|
4
|
Bitcoin / Bitcoin Technical Support / Re: Recovering a 12 word phrase
|
on: May 04, 2021, 08:43:44 AM
|
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? |
|
|
|
|
5
|
Bitcoin / Bitcoin Technical Support / Re: Recovering a 12 word phrase
|
on: May 03, 2021, 03:39:44 PM
|
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  |
|
|
|
|
7
|
Bitcoin / Bitcoin Technical Support / Re: Recovering a 12 word phrase
|
on: May 03, 2021, 09:23:22 AM
|
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. |
|
|
|
|
10
|
Bitcoin / Bitcoin Technical Support / Re: Compressed hex private key with 66 characters?
|
on: April 23, 2021, 05:05:26 PM
|
@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. |
|
|
|
|
11
|
Bitcoin / Bitcoin Technical Support / Re: Compressed hex private key with 66 characters?
|
on: April 23, 2021, 12:34:53 PM
|
@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. |
|
|
|
|
14
|
Bitcoin / Bitcoin Technical Support / Re: Compressed hex private key with 66 characters?
|
on: April 23, 2021, 12:00:53 PM
|
Hi guys, I happened upon a private key hex while I was decoding a compressed (beginning with L) base58 WIF 52 characters long, that starts with 80 f3 and is 76 hex chars long.
I proceeded with removing the 8 checksum bytes at the end and this left me 68 hex chars, when the 80 at the beginning was removed I got 66 hex chars of a private key beginning with f3.
But I don't think the length is right, no? Private keys are supposed to be 64 hex characters long not 66. Is the F3 some kind of magic byte of sorts?
EDIT: it begins with 80 f3 not 80 fe.
what about '01' at the end, which indicates compressed WIF? https://learnmeabitcoin.com/technical/wif |
|
|
|
|
15
|
Economy / Games and rounds / Re: Please steal my bitcoins
|
on: March 30, 2021, 08:50:57 PM
|
Brute-force algorithm would be:
1) Let's say WIF starts with K (later - repeat with L) - remove K from the set of letters
2) Calculate combinations from the rest of the letters (51) taking 45 letters (do not use 6 letters for checksum) (18009460)
3) Calculate permutations for each of 45 letters
4) For each permutation try to decode WIF: K + calculated result + fake checksum, which should be ignored (just extract privkey from WIF).
Ideas for optimization:
- check which letters are duplicated
- check min/max possible WIF (min: KwDiB..., max: L5o...)
Other remarks: Possible prefix & rest of letters: "Kw" "LP5U3WRLvPwDefz4FVMrAJVFtU4u8pj158VSpZF2aaPeY5Qix8",
"Kx" "LP5U3WRLvPwDefz4FVMrAJVFtU4u8pj15w8VSpZF2aaPeY5Qi8",
"Kz" "LP5U3WRLvPwDef4FVMrAJVFtU4u8pj15w8VSpZF2aaPeY5Qix8",
"L1" "P5U3KWRLvPwDefz4FVMrAJVFtU4u8pj5w8VSpZF2aaPeY5Qix8",
"L2" "P5U3KWRLvPwDefz4FVMrAJVFtU4u8pj15w8VSpZFaaPeY5Qix8",
"L3" "P5UKWRLvPwDefz4FVMrAJVFtU4u8pj15w8VSpZF2aaPeY5Qix8",
"L4" "P5U3KWRLvPwDefzFVMrAJVFtU4u8pj15w8VSpZF2aaPeY5Qix8",
"L5" "PU3KWRLvPwDefz4FVMrAJVFtU4u8pj15w8VSpZF2aaPeY5Qix8" Additionally, because of https://bitcointalk.org/index.php?topic=5327268.msg56676121#msg56676121 I think we may assume that "i" is not the last character. |
|
|
|
|
16
|
Economy / Games and rounds / Re: Please steal my bitcoins
|
on: March 30, 2021, 01:51:17 PM
|
|
Brute-force algorithm would be:
1) Let's say WIF starts with K (later - repeat with L) - remove K from the set of letters
2) Calculate combinations from the rest of the letters (51) taking 45 letters (do not use 6 letters for checksum) (18009460)
3) Calculate permutations for each of 45 letters
4) For each permutation try to decode WIF: K + calculated result + fake checksum, which should be ignored (just extract privkey from WIF).
Ideas for optimization:
- check which letters are duplicated
- check min/max possible WIF (min: KwDiB..., max: L5o...)
|
|
|
|
|
17
|
Economy / Games and rounds / Re: Please steal my bitcoins
|
on: March 30, 2021, 11:31:37 AM
|
This is my private key in a randomised order relating to this address: LP5U3KWRLvPwDefz4FVMrAJVFtU4u8pj15w8VSpZF2aaPeY5QIx8
'I' on the 50th place - wrong character, not from Base58 set. |
|
|
|
|
Show Posts
