3 days of searching only found 3 addresses starting with 13zb1hQb, while finding more than 200 addresses starting with 13zb1hQ.
My first 13zb1hQb is in 203c0df74e49 next one is in 401f8aa ( lol was testing ). Third one is in 3b650e1d66a7.
I can't really tell how rare those are considering I'm using random mode. Have you found any of those rare addresses yet? Could this mean that 13zb1hQbW when found is the only address in the entire range? Maybe I'm wrong given the small ranges I have searched.
I am only searching full address, not partial string. I used to know how to try and figure out how many leading characters in address could be in a specific range. Maybe someone else can answer better/more accurate. Take number of characters, minus the leading 1, 13zb1hQbW has 8 characters. Multiply that by base 58 to the power of characters; 58^8 = 128,063,081,718,016. Now divide range size by that. 2^65 / 58^8 = 288,088. So there could be up to 288,000 addresses starting with 13zb1hQbW in the #66 range. Based on your calculations, i found a prefix that only repeats 4967 times in the entire 66 puzzle range: 13zb1hQbWV Is my math correct? |
|
|
|
Pub Addr: 13zb1hQbWVi8cYnLyEus3LFucU535Bm52s
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZwTz2AuZAUT3S519jUb
Priv (HEX): 0x00000000000000000000000000000000000000000000000345CCB1B178168878
Have you found any other similar addresses with private keys starting with 0x345CCB?
It doesn't work like that, there is a lot of hashing going on until you generate an address (or for our case, a prefix of that address). What i mean is, the process that takes you to a certain address gets completely random results once you change even 1 character. So finding this prefix in the range starting with 0x345CCB means nothing as a clue. In fact, the right private key will most likely reside way far from there. ------ Btw, based on your theory of "never a pvt key with all digits", if you somehow manage to remove those keys from the entire #66 range, and assuming key is not in the 20000000000000000:2ffffffffffffffff, you would end up with only around 10 million trillion keys instead of 18 million trillions. Huge progress, almost as if we're back to searching through #64 puzzle range. Like i said, this filtered range can be easily generated; problem is how to pipe it into a cracking program without having to modify the cracking program itself. |
|
|
|
you obviously has a thinking error here.
Prove me wrong! While you don't even know what I'm saying, just show me a private key generated by a wallet from an integer which has a hex representation consisting of only the 0-9 numbers with no A-F characters. Deep down every thing is 0 and 1, but on the surface things are different, and yet I'm waiting to see that wallet though. Again excluding only numeral private keys from a bit range has a potential of at least 60% less bit space to search since there are more numeral only private keys than hex only and mixed hexadecimal keys combined. What I haven't figured out yet is how to actually erase such keys completely from the search table in a way that as if they were never existed so the CPU could process the numbers without any hiccups. Maybe working on a code that doesn't allow integers which would result in all numeral private keys, this could significantly reduce the entire bit range of all elliptic curves narrowing down the search space.! it's easy to do. i can generate such ranges with crunch then filter results with Golang until all keys are a mix of digits and letters. the only problem is, what kind of hard drive space can hold these trillions of keys before you can check them one by one. and if you think you can use keyhunt or bitcrack etc.. to do this exact task for you, think again.
BTW, i found this prefix for puzz #66 when i woke up this morning, 10 letter match prefix. I kinda find this rare enough: Pub Addr: 13zb1hQbWVi8cYnLyEus3LFucU535Bm52s Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZwTz2AuZAUT3S519jUb Priv (HEX): 0x00000000000000000000000000000000000000000000000345CCB1B178168878 found by Vanbitcracken random version. [moderator's note: consecutive posts merged] |
|
|
|
Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys: He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now. Show me the public key of that address, I will use Satoshi's super computer to crack it. I'd say that the hacker knows that mixers are rigged and using them would endanger him, however I don't think it's fair to steal from others, that's what coward pussies do, I'm sure the real owners are willing to happily pay 20% as a reward, that 20% would be legit, but no matter what, he has to answer for what he has done some day. No pub key and not a dime spent. Coz whoever spends from this address will be chased down vigorously. |
|
|
|
Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys: He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now. |
|
|
|
Where is this keyhunt cuda? You mean the one you removed from your repo? Well I have been looking for any length prefix finder for rmd160, now you are telling me that my mentor had this tool all this time?🙂 please release the offline cuda version🥳. No it was not a rmd160 prefix finder, it searched for full rmd160. That particular one was archived because it was programmed specifically for a #64 pool we were running. Also, Zahid is no more on a goose chase than you are with this whole rmd160 prefix finder 😂 At least he is trying something and doing it on his own. There is no time trade off with rmd160 prefix, just a memory/input file size trade off. First of all ouch! Secondly, doing things on our own will never work, team work efforts is the answer, that's why it's called a community. Guess I will have to go for btccollider then. LBC was once great, but now It's abandoned 👋 i think if we can revive it nowadays we could reach over 1k TN keys / per 24hs (out of 36+ million TN keys in the puzzle 66 range lol) |
|
|
|
I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?
Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives. Agreed! I did exactly this about a year ago. The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used. I also did it with x points. I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives. I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all? No. Just less memory and size of bloom/input file. You could run a small test using python. So fundamentally useless. I would normally increase the bloom filter size and memory and get same speed and way less false positives by using the entire 40 hash160 characters. No wonder everybody loves keyhunt and keyhunt-cuda. I wish there was keyhunt-ocl as well though .. there is one on github but it's not passing my tests |
|
|
|
I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?
Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives. Agreed! I did exactly this about a year ago. The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used. I also did it with x points. I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives. I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all? |
|
|
|
And don't listen to some developers claiming their tools already do that, because they don't, otherwise why there is no option to set our desired rmd160 prefix? If you are merely talking a rmd160 prefix versus full rmd160, there would be no speed up. The full rmd160 is already generated from the public key. I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that? |
|
|
|
Hello I found this "puzzle" by a student who wondered if it is possible for the keys to be sequential, the answer to this is that it could be possible that a mathematical formula was used for this. but it is also possible that he only did this: n=1,256 r(2^n-1)) and then manually modify the values "randomly", It is most likely that he did so. In short, I would have to investigate with more time, honestly I do not have the computational power to use brute force, but I can give you some statistical advice on this. 1- brute force with large numbers is always better randomly.I will use the Monty Hall paradox as an example. Suppose you're on a game show, and you're given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what's behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice? At first the contestant has 1/3 chances, then when the host opens a door and gives you the option to change at first glance it seems that if you would have the same probability but no. The car has a 1/3 chance of being behind the door chosen by the player. The other door have a probability of 2/3 and not 50%. This is the reason why at this point in the "puzzle" a random search is always better than staying in a large range. 2- Is human randomness really random?playing with some statistical algorithms I made calculations that are close to the range where there is a greater probability that the private keys are found. Pn- range found 65- 30580000000000000000 30568377312064202855 66- 61230000000000000000 67- 137500000000000000000 68- 266900000000000000000 68- 459400000000000000000 69- 520700000000000000000 70- 978700000000000000000 970436974005023690481 Given that the range of the puzzles 65 and 70 of the formula that I use are close to reality, by statistics the ranges 66, 67, 68 and 69 exist the probability of being close to the real result. if the puzzle creator made manual changes pretending randomness or disassociating from 2^n-1 , he fail because humans are bad at it. we always tend to repeat sequences unconsciously by association. exercise: If I ask you to read 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 and quickly I ask you to say a color without meditating or thinking. The most likely thing is that you chose the color: "answer at the end of the comment" (don't cheat, just say the numbers and say the first color you think of quickly). my opinion I don't know what is the reason for this, it's my first approach to bitcoin, but if the creator is rich enough to do it because I don't just take addresses like mine  (  1 HUGxcudaxCdufCaYHRoNadeCa73i3hB2r) randomly and send money? Does he try to test if bitcoin can be hacked? Does he want to encourage the creation of brute force tools? Personally, I think it would be more likely to find a back door to the elliptic curve used by satoshi than to brute force 256. In any case, if I were to do this, I wouldn't do it because my resources are basic. I would use random numbers in a range I would search for known public keys to maximize the performance of the code by skipping various processes that slow down the search. I don't know if I'm wrong because this is a new world for me, if I am, please correct me. sorry for my English. answer: RED. That's exactly how i do my pvt key search. Random is the name of the game when it comes to big numbers. I'm surprised that although you're new to this, most of what you suggested was spot on. In fact, almost summed up the entire experience of this thread. Even the math algorithm part was once a thing to discuss in the early days of this puzzle |
|
|
|
Its probably as good as anyone else's guess lol  There's a prediction model based on statistics of previous puzzle keys. It is made by HomelessPhD and kinda sophisticated The repository is on github if you wanna take a look. |
|
|
|
Yeah that’s already a thing…for at least 2 years now.
So bitcrack and vanity can search for public key alone? Although there are tools for that, we are limited by the fact that you would have to know the public key of your target addresses. I have 250,000 pulic keys of the richest addresses, updated every month, but the problem is i would have to be searching for those in the 253-256 bit to ever dream of finding the private key. Since this is almost ALMOST impossible to achieve, pub key cracking should only be used on puzzle addresses and even those are in the high bit range i.e 125-160 bits . That's why i was originally talking about searching through pure private key cracking. Which gets me to the previous point of hash160 prefix. You're right, prefixing h160 would break the function. Looks like we're gonna stick to conventional ways. |
|
|
|
I found a way to speed up the brute force attack method, drop the hash160 conversion to address, because that conversion requires a SHA-256D, that is equal as mining bitcoin, now if we skip that part, what percentage can we gain in speed increase?
True. It's how Brainflayer and keyhunt in RMD160 mode work. Much much faster and results in the same output eventually. I wish bitcrack would update to rmd mode. Might double speed. Are y'all talking about loading/searching for hash160 versus address? I ask because this comment kind of confused me, "drop the hash160 conversion to address". Yes Then you are correct. This has been known and Vanity, KeyhuntCuda, do in fact already do this. I’m not sure about bitcrack; I’d have to look at the code. Yeah Bitcrack is a classic try-the-privatekey-and-convert-to-full-address-then-compare-to-input-address thingy. It's fast and works on all GPU types, although it failed test on all RX 500 series 8GB GPUs for some reason. There is a random search version of it that generates millions of random sub-ranges and start searching through them sequentially. Good stuff. Not fast enough compared to Vanbitcracken. If we can drop the convert-all-the-way-to-address process, this can save a lot of time by generating output faster. Keyhuntcuda is a great example for this. And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever. |
|
|
|
Doing some testing on 76 bit... KangaBGStrider v1.01
Range Start :0 (0 bit)
Range End :FFFFFFFFFFFFFFFFFFF (76 bit)
Public Key(s) :1
Creating Stride Table...
CPU thread(s) : 8
Stride Table Complete: Max Stride: 2^36
Stride Avg Distance: 2^34.09
Number of Striders: 2^13.00
Suggested DP: 22
Expected operations: 2^41.39
Simulated DP size: 32 [0x00000000FFFFFFFF]
[31.88 MS/s][GPU 0.00 MS/s][Total Collision Checks 2^32.97][05:04 (Avg 1.0d)]
Key# 0 [1S]Pub: 0x02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Priv: 0x865CE114686A1301A4C
Done: Total time 05:05
This code be revolutionary if stretched all the way up to say 128 bits. Might get speed that no one managed to reach before. Congrats WP, another great build. |
|
|
|
I found a way to speed up the brute force attack method, drop the hash160 conversion to address, because that conversion requires a SHA-256D, that is equal as mining bitcoin, now if we skip that part, what percentage can we gain in speed increase?
True. It's how Brainflayer and keyhunt in RMD160 mode work. Much much faster and results in the same output eventually. I wish bitcrack would update to rmd mode. Might double speed. Are y'all talking about loading/searching for hash160 versus address? I ask because this comment kind of confused me, "drop the hash160 conversion to address". Yes |
|
|
|
I found a way to speed up the brute force attack method, drop the hash160 conversion to address, because that conversion requires a SHA-256D, that is equal as mining bitcoin, now if we skip that part, what percentage can we gain in speed increase?
True. It's how Brainflayer and keyhunt in RMD160 mode work. Much much faster and results in the same output eventually. I wish bitcrack would update to rmd mode. Might double speed. |
|
|
|
A screen shot is an actual picture of your screen not the text that you put here (no offense !).
If you do not share at least the executable form of your program, it is hard to believe that with a few cpu cores you can beat the 2080 gpu.
Again, I do not mean to offend you, but seeing is believing.
I bet a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can, with publicly available programs. I hear you...however, it's fine, I do not have the energy to take an image and hunt somewhere to post it and then link to it LOL. I know the program is real and works. I do not need others to believe or not believe. This is a test program. Will it currently help with the challenge, no, it is currently limited to 72 bits. But I am trying to get to a point where it can help with my plan. Another point is for the people who have ideas and are always shot down by others on this forum that something "will not work" or "would take too long" etc. If you have an idea, work on it; if your initial idea wasn't great, maybe you will gain more knowledge along the initial journey. Shooters shoot! Ok. I get it. Just keep talking to yourself here and elsewhere. I gess all these years Jean Luc Pons ( https://github.com/JeanLucPons ) was on the wrong track  LOL...no JLP was never on a wrong track. He took existing theories/programs and made them better/the best. I bet he would agree that, "a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can". 100% (If you disagree with that, I will challenge you to a "race".) He took a lock step approach to the grand finale...his Kangaroo program. However, just because someone else creates/makes something that may be faster, doesn't mean it can't be. I bet albertosd would tell you his BSGS program is faster than JLPs, I think he has a video on it, I think. And your Vanbitcracken is faster than Bitcrack, that doesn't mean Bitcrack sux. This guy is clearly toxic. Ignore him and keep up the great work. Hhhh I am realistic not toxic Mr Evil ! But you're not though, if you are, you would have googled the guy and realized that he has a reliable repository on Github with at least two innovative programs for cracking puzzles. Next time try to combine skepticism with research 😉 I've seen all repositories, compiled, tried and compared almost all of them. Repositories where no source code is provided do not contribute much to research. https://bitcointalk.org/index.php?topic=1305887.0 https://bitcointalk.org/index.php?topic=1306983.0 https://bitcointalk.org/index.php?topic=5166284 and for up to date information, look here https://bitcointalk.org/index.php?topic=5218972.0 posted by Zielar (Thank you very much Mr Zielar) also look here https://bitcointalk.org/index.php?topic=5244940.0 posted by Jean_Luc (Merci beaucoup Monsieur Jean Luc Pons) All of you keep up with the good work. Oh so now posting links to puzzle-related threads proves someone is a good researcher?! Wow. I learned something new today. Not! I dunno what's your problem with compiled code. Millions of Windows users must be inferior to you then. |
|
|
|
A screen shot is an actual picture of your screen not the text that you put here (no offense !).
If you do not share at least the executable form of your program, it is hard to believe that with a few cpu cores you can beat the 2080 gpu.
Again, I do not mean to offend you, but seeing is believing.
I bet a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can, with publicly available programs. I hear you...however, it's fine, I do not have the energy to take an image and hunt somewhere to post it and then link to it LOL. I know the program is real and works. I do not need others to believe or not believe. This is a test program. Will it currently help with the challenge, no, it is currently limited to 72 bits. But I am trying to get to a point where it can help with my plan. Another point is for the people who have ideas and are always shot down by others on this forum that something "will not work" or "would take too long" etc. If you have an idea, work on it; if your initial idea wasn't great, maybe you will gain more knowledge along the initial journey. Shooters shoot! Ok. I get it. Just keep talking to yourself here and elsewhere. I gess all these years Jean Luc Pons ( https://github.com/JeanLucPons ) was on the wrong track LOL...no JLP was never on a wrong track. He took existing theories/programs and made them better/the best. I bet he would agree that, "a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can". 100% (If you disagree with that, I will challenge you to a "race".) He took a lock step approach to the grand finale...his Kangaroo program. However, just because someone else creates/makes something that may be faster, doesn't mean it can't be. I bet albertosd would tell you his BSGS program is faster than JLPs, I think he has a video on it, I think. And your Vanbitcracken is faster than Bitcrack, that doesn't mean Bitcrack sux. This guy is clearly toxic. Ignore him and keep up the great work. Hhhh I am realistic not toxic Mr Evil ! But you're not though, if you are, you would have googled the guy and realized that he has a reliable repository on Github with at least two innovative programs for cracking puzzles. Next time try to combine skepticism with research 😉 |
|
|
|
A screen shot is an actual picture of your screen not the text that you put here (no offense !).
If you do not share at least the executable form of your program, it is hard to believe that with a few cpu cores you can beat the 2080 gpu.
Again, I do not mean to offend you, but seeing is believing.
I bet a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can, with publicly available programs. I hear you...however, it's fine, I do not have the energy to take an image and hunt somewhere to post it and then link to it LOL. I know the program is real and works. I do not need others to believe or not believe. This is a test program. Will it currently help with the challenge, no, it is currently limited to 72 bits. But I am trying to get to a point where it can help with my plan. Another point is for the people who have ideas and are always shot down by others on this forum that something "will not work" or "would take too long" etc. If you have an idea, work on it; if your initial idea wasn't great, maybe you will gain more knowledge along the initial journey. Shooters shoot! Ok. I get it. Just keep talking to yourself here and elsewhere. I gess all these years Jean Luc Pons ( https://github.com/JeanLucPons ) was on the wrong track LOL...no JLP was never on a wrong track. He took existing theories/programs and made them better/the best. I bet he would agree that, "a CPU can find 1,000 pub keys (up to say 48-52 bits) before any GPU can". 100% (If you disagree with that, I will challenge you to a "race".) He took a lock step approach to the grand finale...his Kangaroo program. However, just because someone else creates/makes something that may be faster, doesn't mean it can't be. I bet albertosd would tell you his BSGS program is faster than JLPs, I think he has a video on it, I think. And your Vanbitcracken is faster than Bitcrack, that doesn't mean Bitcrack sux. This guy is clearly toxic. Ignore him and keep up the great work. |
|
|
|
Hi, very impressive
How about finding the 72 bit private-key this one following public-key
02FA7F31E5AC687CE1770159146899C390FBAA3395EE1B6EBDA07B4D7DDC6A519B
please provide a screen shot of the output with date-time stamp before and after execution.
Are you considering releasing your program soon?
I do not know what you mean by screen shot. KangaBGStrider v1.01
Range Start :0 (0 bit)
Range End :FFFFFFFFFFFFFFFFFF (72 bit)
Public Key(s) :1
Creating Stride Table...
CPU thread(s) : 6
Stride Table Complete: Max Stride: 2^34
Stride Avg Distance: 2^32.17
Number of Striders: 2^12.58
Suggested DP: 20
Expected operations: 2^38.60
Simulated DP size: 28 [0x000000000FFFFFFF]
[24.98 MS/s][GPU 0.00 MS/s][Total Collision Checks 2^29.76][46s (Avg 04:38:23)]
Key# 0 [1S]Pub: 0x02FA7F31E5AC687CE1770159146899C390FBAA3395EE1B6EBDA07B4D7DDC6A519B
Priv: 0xF5E786A2B6CDE7E881
Done: Total time 49s
A screen shot is an actual picture of your screen not the text that you put here (no offense !). If you do not share at least the executable form of your program, it is hard to believe that with a few cpu cores you can beat the 2080 gpu. Again, I do not mean to offend you, but seeing is believing. Shhhhh 🤫 |
|
|
|
|
Show Posts
