|
Title: Keyhunt - development requests - bug reports Post by: albert0bsd on March 06, 2021, 02:13:56 PM I want to open this thread to talk about the tool that i develop Keyhunt (https://github.com/albertobsd/keyhunt) available on github.
https://github.com/albertobsd/keyhunt (https://github.com/albertobsd/keyhunt) Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed. Current Version 0.2.230430 Satoshi Quest Lastest changes on development branch (https://github.com/albertobsd/keyhunt/tree/development) How to use Download and build Run againts puzzle 66 (addres mode) 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so (https://mempool.space/address/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so) 6.6 BTC Code: ./keyhunt -m address -f tests/66.txt -b 66 -l compress -R -q -s 10 You need to add -t numberThreads to get better speed Run againts Puzzle 130 (bsgs mode) 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua (https://mempool.space/address/1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua) 13 BTC Code: ./keyhunt -m bsgs -f tests/130.txt -b 130 -q -s 10 -R You need to add -t numberThreads and -k factor to get better speed Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: escobol on March 06, 2021, 08:00:03 PM Hi nice one !
How to use pfile? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 06, 2021, 08:23:30 PM you can use the bPfile.c to generate your .bin file ( this is the baby step table)
Code: ./bPfile 1048576000 Pfile.bin This process can take some time, please be patient, maybe some hour depent of your speed. Once that the file is already created, execute: Code: albertobsd $ ./keyhunt -m bsgs -f 120.txt -r 800000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -t 4 -k 250 -R -p ./bPfile.bin -k 250 is new factor of speed, 250 use some more of 17 GB of RAM. But the speed will be huge: Quote Total 155574970875904000 keys in 180 seconds: 864305393755022 keys/s 864 Terakeys/s Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on March 06, 2021, 09:20:23 PM Work on windows?
Without running it, just from the speed you say, seems a little bit slower than what is already out there. But I like to learn different programs in different languages. And you say speed will be huge with higher RAM Quote maybe some hour depent of your speed. so are you factoring that in to the total time?I can run through 72,057,594,037,927,935 keys in less than 2 minutes, that is start to finish. And that is using only 1.8Gb of RAM. I am most interested in how you will setup network/pool version as I have been wanting this for the version I use for some time now. When you start development, let me know and I can share some ideas. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 06, 2021, 09:37:21 PM Work on windows? Only with the Ubuntu shell for windows, or maybe some cgywin enviroment. Yes speed is a little slow, but is CPU and RAM only, i can get the double of that speed wit the double of threads and RAM but my server is running some other things. I can reach to some 2 Petaleys/s and some other friends with highend servers can reach more that 10 Petakeys/s. I'm working in some other approach and trying to get a better performance but is still a work in development. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: dextronomous on March 07, 2021, 06:06:49 PM hi albert0bsd, great pieces you got, thanks for giving, but hey was wondering,
Work on windows? I'm working in some other approach and trying to get a better performance but is still a work in development. Best regards! is it available as working to test sir.? Title: Re: Keyhunt - development requests - bug reports Post by: escobol on March 09, 2021, 05:42:41 PM Im testing.
Your first BSGS version (the one before bpfile) got few core dumps. Actual version works great (tested with one pub and multi pub). Waiting for new updates for tests :) Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on March 10, 2021, 08:50:09 AM just try BSGS version if anyone use keyhunt and compile mission gmp.h try install libgmp3-dev Code: apt-get install libgmp3-dev Recommend to put sample address.txt and 120.txt setting puzzle 120 to github for easy copy setting because first time I found Invalid length Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on March 10, 2021, 09:13:36 AM
Require sample file addresses.txt (just for new user not yet to know) Can possible I turn off this line message, if can possible have option for hide this display?
this display over 10000 message Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on March 10, 2021, 09:21:46 AM Ok,
Sorry, I got how to turn off display message from help
Usage: -h show this help -a file file is a binary raw file with the aMP points precalculated. Just work with -m bsgs -b bits For some puzzles you only need some numbers of bits in the test keys. This option only is valid with the Random option -R -c crypto Search for specific crypo. < btc, eth, all > valid only w/ -m address eth option is under develop sorry :( -e The file is already Sorted descendent. This skip the sorting process. Your file MUST be sordted if no you are going to lose collisions -f file Specify filename with addresses or xpoints or uncompressed public keys -g count Just for the stats, mark as counted every debugcount keys -k value Use this with bsgs mode, k value is factor for M, more speed but more RAM use wisely -m mode mode of search for cryptos. < address, xpoint, bsgs > default: address (more slow) -n uptoN Check for N secuential numbers before the random chossen this only work with -R option Use -n to set the N for the BSGS process. Bigger N more RAM needed -p file file is a binary raw file with the bP points precalculated. Just work with -m bsgs -q set quiet the thread output -r SR:EN StarRange:EndRange, the end range can be omited for search from start range to N-1 ECC value -R Random/Secuential this is the default behaivor, can't use this with range option -r -s ns Number of seconds for the stats output, 0 to omit output. -t tn Threads number, must be positive integer -v va Search for vanity Address, only with -m address -w Mark the input file as RAW data xpoint fixed 32 byte each point. Valid only with -m xpoint Use the hexcharstoraw tool to create a raw file from your current hexadecimal file Example keyhunt -t 16 -r 00000001:FFFFFFFF -s 0 This line run the program with 16 threads from the range 00000001 to FFFFFFFF without stats output Developed by AlbertoBSD Tips BTC: 1ABSD1rMTmNZHJrJP8AJhDNG1XbQjWcRz7 Thanks to Iceland always helping and sharing his ideas, Tips to Iceland: bc1q39meky2mn5qjq704zz0nnkl0v7kj4uz6r529at Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 10, 2021, 02:16:59 PM is it available as working to test sir.? Most of those test version doesn't work (those are crazy ideas), The only version available is the the github version. Ok, Sorry, I got how to turn off display message from help Code: -q set quiet the thread output add -q to your command line. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on March 11, 2021, 04:39:23 AM Thanks now ok quiet option already
turn off display make program work fast that show it display other program is same turn off is make it work faster and What mean keys, it is mean 1 private key or 1 key character Total 2163563847226549600256 keys in 69000 seconds: 31355997785892023 keys/s Total 2164516112257133838336 keys in 69030 seconds: 31356165612880397 keys/s Total 2165465615314509103104 keys in 69060 seconds: 31356293300239054 keys/s Total 2166412549912721883136 keys in 69090 seconds: 31356383701153884 keys/s Total 2167356300325260623872 keys in 69120 seconds: 31356427956094627 keys/s Total 2168303551582822203392 keys in 69150 seconds: 31356522799462360 keys/s Total 2169249254728011874304 keys in 69180 seconds: 31356595182538477 keys/s Total 2170192670889015771136 keys in 69210 seconds: 31356634458734514 keys/s Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on March 11, 2021, 04:44:19 AM it is normal. I think it is too fast. 1086000828893888512 keys in 30 seconds
Total 2176681179275591680 keys in 60 seconds: 36278019654593194 keys/s Total 3263473656541478912 keys in 90 seconds: 36260818406016432 keys/s Total 4346941210644971520 keys in 120 seconds: 36224510088708096 keys/s Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 11, 2021, 05:53:17 AM and What mean keys, it is mean 1 private key or 1 key character That is the keys checked in a range from A to B by example some range from/to in the 120 bit space: Code: from: 0x800000000000000000000000000000 Difference: 0x100000000000 Decimal: 17,592,186,044,416 That is the number of keys in that range, the BSGS algorimth can check that range in a few Operations, then that number of keys are already checked, and added to the total counter
Edit Already Solved: Commit a0a60ede57890c5f46e711628f52de2d7becd270 (https://github.com/albertobsd/keyhunt/commit/a0a60ede57890c5f46e711628f52de2d7becd270) Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: Markzuberg64 on March 21, 2021, 01:01:22 PM Hi ,
Glad to see this project here on bitcointalk . I am using it from last many days and its quite impressive . I found it via iceland2k14 comments on his bsgs repo. Anyways i have some questions for you. 1. What exactly are BP points and AMP points in your code. How are they calculated. Any specific formulae. 2. Where can i find BP file and Amp file after it gets calculated in your program. I am not able to locate any 1920 MB BP file generated for -k 30 im the directory. 3. -a how to make this file of precalculated amp points. 4. A question not related to this tool , i am supposing that this tool is calculating different key pairs at different spaces in a range. And matches the pubkey generated with the input pubkey - keyspace*G , my question is that since its comparing one single key from a keyspace of trillion keys then the output that its showing like 30 trillion keys scanned means that it actually matched 30 precalculated results from 30 trillion private keys. Right ? Or it is 30 trillions keys are converted to 30 trillion pub keys and matched in 30 second. And what are K factor related to M , what is M here. Thanks in advance. Title: Re: Keyhunt - development requests - bug reports Post by: Markzuberg64 on March 21, 2021, 07:57:26 PM it is normal. I think it is too fast. 1086000828893888512 keys in 30 seconds
Total 2176681179275591680 keys in 60 seconds: 36278019654593194 keys/s Total 3263473656541478912 keys in 90 seconds: 36260818406016432 keys/s Total 4346941210644971520 keys in 120 seconds: 36224510088708096 keys/s Not just fast. With my system i get 14 trillion per sec , that on -t 8 -k 30 , with 8 GB ram , BP point allocation took around 2 GB . What are your specs , BP point allocation seem to be on default with 1 thread only. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 22, 2021, 02:13:59 PM Hi everyone, i will update the code today with a new version, this new version is a little more faster and use less RAM, using less RAM meaning tha you can load a bigger bP Table with a bigger K value.
Glad to see this project here on bitcointalk . I am using it from last many days and its quite impressive . I found it via iceland2k14 comments on his bsgs repo. Anyways i have some questions for you. Thanks 1. What exactly are BP points and AMP points in your code. How are they calculated. Any specific formulae. bP points are G values, G, 2G, 3G, etc... aMP points vary with the the values -n value or -k value check this link to see a good explanation of the BSGS algo: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ 2. Where can i find BP file and Amp file after it gets calculated in your program. I am not able to locate any 1920 MB BP file generated for -k 30 im the directory. My program dont generate that file by default, i really dont want to sature the HDD of the users of my program. If you want to generate the bPfile by your own use the bPfile program is already compilied in the last version of keyhunt. https://github.com/albertobsd/keyhunt/blob/main/bPfile.c Code: ./bPfile <bP items> <output filename> 3. -a how to make this file of precalculated amp points. aMP Points change if you change your -n value or -k value. I can publish the tool to generate that file, but i need to add some "self-test" in the main program just to avoid that some user load a different or wrong files. 4. A question not related to this tool , i am supposing that this tool is calculating different key pairs at different spaces in a range. And matches the pubkey generated with the input pubkey - keyspace*G , my question is that since its comparing one single key from a keyspace of trillion keys then the output that its showing like 30 trillion keys scanned means that it actually matched 30 precalculated results from 30 trillion private keys. Right ? Or it is 30 trillions keys are converted to 30 trillion pub keys and matched in 30 second. And what are K factor related to M , what is M here. The program only do one math operation to check if one publickey is in a especific Range https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ So only one publickey is generated from sustractions and additions and that is compared agains all the bloom filter (bPTable) If you read the link you will see that if we have a Range N we get an M value getting the squaredroot of N, the K factor was an Iceland recomendation, we can load in the bloom filter kM elements from G to kM, and we only are going to need M/k operaions instead of the orginal M operations sugested in the link. Title: Re: Keyhunt - development requests - bug reports Post by: Markzuberg64 on March 22, 2021, 06:12:25 PM Hi everyone, i will update the code today with a new version, this new version is a little more faster and use less RAM, using less RAM meaning tha you can load a bigger bP Table with a bigger K value. Glad to see this project here on bitcointalk . I am using it from last many days and its quite impressive . I found it via iceland2k14 comments on his bsgs repo. Anyways i have some questions for you. Thanks 1. What exactly are BP points and AMP points in your code. How are they calculated. Any specific formulae. bP points are G values, G, 2G, 3G, etc... aMP points vary with the the values -n value or -k value check this link to see a good explanation of the BSGS algo: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ 2. Where can i find BP file and Amp file after it gets calculated in your program. I am not able to locate any 1920 MB BP file generated for -k 30 im the directory. My program dont generate that file by default, i really dont want to sature the HDD of the users of my program. If you want to generate the bPfile by your own use the bPfile program is already compilied in the last version of keyhunt. https://github.com/albertobsd/keyhunt/blob/main/bPfile.c Code: ./bPfile <bP items> <output filename> 3. -a how to make this file of precalculated amp points. aMP Points change if you change your -n value or -k value. I can publish the tool to generate that file, but i need to add some "self-test" in the main program just to avoid that some user load a different or wrong files. 4. A question not related to this tool , i am supposing that this tool is calculating different key pairs at different spaces in a range. And matches the pubkey generated with the input pubkey - keyspace*G , my question is that since its comparing one single key from a keyspace of trillion keys then the output that its showing like 30 trillion keys scanned means that it actually matched 30 precalculated results from 30 trillion private keys. Right ? Or it is 30 trillions keys are converted to 30 trillion pub keys and matched in 30 second. And what are K factor related to M , what is M here. The program only do one math operation to check if one publickey is in a especific Range https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ So only one publickey is generated from sustractions and additions and that is compared agains all the bloom filter (bPTable) If you read the link you will see that if we have a Range N we get an M value getting the squaredroot of N, the K factor was an Iceland recomendation, we can load in the bloom filter kM elements from G to kM, and we only are going to need M/k operaions instead of the orginal M operations sugested in the link. Thanks for the link to article and explanation. It helped a lot in understanding the algo. It would be better if you can provide tool to generate amp points as well to better understand the algo and if option to choose BP file and Amp file can be provided in program itself for testing purpose. I think -amp option is already available. Title: Re: Keyhunt - development requests - bug reports Post by: Markzuberg64 on March 22, 2021, 07:28:51 PM Hi again ,
If i need to find key in a single range say -b 65 and for fix value -k 250 , then wouldn't it be beneficial to save sorted amp points to one file and later on use same file for multi pubkey search. Like for searching 1 million key it seems easy and productive to search in 1000 keys chunks. In that case it will take too much time to again calculate bp points , Amp points and sorting them. if Amp points so generated will work fine on different pub keys ? I see that it generates same number of amp points regardless of inserting 1 pub key or 5 pubkey. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 22, 2021, 08:24:34 PM if Amp points so generated will work fine on different pub keys ? I see that it generates same number of amp points regardless of inserting 1 pub key or 5 pubkey. Yes those point will work well with another publickey, Yes if you dont change the values of -k and -n then those points are always the same number and have the same value. aMP points are not a problem to calculate it those values are less with biggers k values. The problem are the bP values, those values can be calcualted with the bPfile, already in the keyhunt directory. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: whanau on March 29, 2021, 07:51:00 PM Hello Thank you for making this code public. I really like it. :)
In BSGS mode, if you do not specify a range, will the program default to the entire key range or some default range? Thank you Title: Re: Keyhunt - development requests - bug reports Post by: dextronomous on March 30, 2021, 01:10:13 AM Same likes from me for your progs man, really nice stuff,
wanted to ask if for -rmd mode u can also use the -k or a larger ./bpfile keep up with your great work. :) Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 31, 2021, 09:04:43 AM Hello Thank you for making this code public. I really like it. :) In BSGS mode, if you do not specify a range, will the program default to the entire key range or some default range? The default range is from 1 to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 Same likes from me for your progs man, really nice stuff, wanted to ask if for -rmd mode u can also use the -k or a larger ./bpfile keep up with your great work. :) Sorry no, -k is only for mode bsgs, i will add it in the readme. best regards! Title: Re: Keyhunt - development requests - bug reports Post by: whanau on April 04, 2021, 05:14:47 AM Hello,
Using this command, I am trying to search a range with BSGS. ./keyhunt -m bsgs -f tests/120.txt -ra00000000000000000000000000000:bfffffffffffffffffffffffffffff -k 512 I get
and after some time maybe an hour,
Is it supposed to start in the middle and work its way out? What is happening? Thank you Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on April 04, 2021, 06:44:46 AM How can I create bPfile.bin? Can't open file Can't open file I try make bPfile.bin +] Reading 4294967296 bP points from file bPfile.bin Can't read the file seen you have less items that the amount needed Can't read the file seen you have less items that the amount needed Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on April 04, 2021, 07:24:00 AM How can I create bPfile.bin? Can't open file Can't open file I try make bPfile.bin +] Reading 4294967296 bP points from file bPfile.bin Can't read the file seen you have less items that the amount needed Can't read the file seen you have less items that the amount needed Ok. I got infomation from post on first page ./bPfile 20000000 bPfile.bin How much number create recommend? Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on April 04, 2021, 07:43:13 AM
What recommend when I run on Linux Subsystem on Windows 10? and limited with low memory Title: Re: Keyhunt - development requests - bug reports Post by: Markzuberg64 on April 04, 2021, 07:55:59 AM
What recommend when I run on Linux Subsystem on Windows 10? and limited with low memory Depends on your choosen K , t and b value (Or range choosen ) , if you want to create bpfile yourself then run the program first with desired config and note value of BP points that program is generating. Then terminate the program and run bpfile.bin with that value. Bpfile so generated can be used as long as value of K , t and b remain same. For low memory you can roughly calculate yourself. For around 1 million BP points , bloom filter takes 15MB in memory. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 05, 2021, 08:18:27 PM Is it supposed to start in the middle and work its way out? What is happening? Is working, what is your doubt?
What recommend when I run on Linux Subsystem on Windows 10? and limited with low memory You need to create a bigger file, with more than 2147483648 items. The file need the next amout of items (4,194,304 * K) So if you are planning changing you K a lot of times, again and again please stop to that, chose a K value and make your file once. Sorry for make the program in that way. best regards Title: Re: Keyhunt - development requests - bug reports Post by: seoincorporation on April 08, 2021, 04:23:40 PM Great work albert0bsd!
I'm running the code now, lets see if it doesn't burn my old craptop ;D I was looking at the source code and as some other users already commented, it would be awesome to run it with Cuda cores or OpenSL, that way we could try tons of keys with the right GPU mining rig... But looks like a complex task. If I hit that 64 jackpot y will share a tip with OP, Odds are null but the only way to do it is trying. Title: Re: Keyhunt - development requests - bug reports Post by: dextronomous on April 09, 2021, 11:13:19 AM hi albert0bsd, this one is for iceland, kangrand
i keep getting 0x02D822FAC57DB1CA1E060581969B0247A388C46F331FEC84307121328B08FD4E66 Aborted ! and now for you albert0bsd i keep getting false collisions with the same pubkeys MK/s][Count 2^37.92][Dead 2][34:17 (Avg 29:02)][2.0/4.0MB] Key# 1 [XX]Pub: 0x02A46B582948835B0D715E5F5EAA34ABADB8C1E221C8E1A5FD3773CDC3EC1C2C5B Aborted ! A False collision ignored, just the 64th bit keyspace scanning. bsgs_hybrid thanks for the help i guess it fixed itself. thanks for your great software, Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 09, 2021, 01:21:53 PM I was looking at the source code and as some other users already commented, it would be awesome to run it with Cuda cores or OpenSL, that way we could try tons of keys with the right GPU mining rig... But looks like a complex task. I will add it later, long later, first im solving some bugs and improving the general speed in CPU If I hit that 64 jackpot y will share a tip with OP, Odds are null but the only way to do it is trying. Good luck, actually we have better chances to hit the #64 with some megakeys/s than the 120 with Petakeys/s A False collision ignored, just the 64th bit keyspace scanning. bsgs_hybrid thanks for the help Yes he told me something about that issue, i will send him your message. BTW guys i just publish a video on youtube about keyhunt. https://youtu.be/k3698rhRUzg (https://youtu.be/k3698rhRUzg) I hope you like it. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: whanau on April 10, 2021, 03:21:51 AM Is working, what is your doubt? Not doubt, just not understanding. Thread 0: 0000000000000000000000000000000000a000000000000000d4a00000000000 Thread 0: 0000000000000000000000000000000000a0000000000000011bb00000000000 Why are right hand bytes always zero on update ? Is it because the program just displays at that range and everything in between d4a00000000000 and 11bb00000000000 is not shown? Thanks again for a great program Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on April 11, 2021, 07:47:21 PM Been doing some testing. I have a CPU only setup/program that takes an input file of full BTC addresses and randomly searches user defined keyspace.
I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop? Also, I read your page and I have a suggestion for you. You say that searching RIPE is 2x faster than full address; why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE? Then you only have to have the one user option...to search for full address while under the hood, the program converts to RIPE and searches for RIPE. That's how my program works, C++ based off of VanitySearch (but CPU only). Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 12, 2021, 08:41:25 PM Hi WanderingPhilospher, thanks for test the program.
I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop? Keyhunt use a Bloom filter to check if the generated address or hash is on the list, this will lead in some false positive collision (Error rate is one in a million or something like that), so if the the bloom filter return a positive result, it use a second check, this is a binary search over all the address or items in the list, it can dertermine if one item is on the list perfoming only log(N)/log(2) (https://www.wolframalpha.com/input/?i=log2%2815000000%29) operation, for 15 Milllions of addres this process only take 24 comparations. This is like the hash table but i prefer keep those separated becuase there are some trick with the bloom filter that allow you use a little less ram in the case of the BSGS mode. And no, in keyhunt there are no key drop or anything like that. why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE? Yes you are totally right this will be changed soon. Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boost all the modes speeds, address, rmd160, xpoint and bsgs mode in the code. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on April 13, 2021, 02:31:33 AM Quote Yes you are totally right this will be changed soon. Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boots all the modes speed, address, rmd160, xpoint and bsgs mode in the code. Good deal and good work you've done with your program. 4x 5x times faster? Now you just need to code for Windows users :) Title: Re: Keyhunt - development requests - bug reports Post by: unclevito on May 12, 2021, 08:12:40 PM Program works great but one question. On the BSGS function puzzle 120 only goes to
+] Setting mode BSGS
I tried the -r but it had no effect on increasing the range. Is this the limit of the space the program can scan? how do I increase the range to the end of the keyspace FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? Title: Re: Keyhunt - development requests - bug reports Post by: unclevito on May 19, 2021, 11:31:53 PM I want to open this thread to talk about the tool that i develop Keyhunt (https://github.com/albertobsd/keyhunt) available on github. https://github.com/albertobsd/keyhunt (https://github.com/albertobsd/keyhunt) Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed. To try to find the privatekey from the 120 puzzle you need to add this publickey "uncompress" to a txt file: How to use
120.txt Code: 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 you can run the tool agains that file: I am confused if 120 address and public key are compressed why do you say we need to use "uncompress" for 120? Title: Re: Keyhunt - development requests - bug reports Post by: gitman on May 20, 2021, 06:13:20 AM Would someone explain please, what's the point of generating the bPfile.bin file? I run tests with it and without, the speed performance seems to be about the same.
Thank you. Title: Re: Keyhunt - development requests - bug reports Post by: hskun on May 21, 2021, 12:48:33 AM I think you can try xor filter, it's more faster.
https://github.com/FastFilter/xor_singleheader Title: Re: Keyhunt - development requests - bug reports Post by: gsciservices on June 07, 2021, 10:19:17 AM I think you can try xor filter, it's more faster. https://github.com/FastFilter/xor_singleheader You are supposed to tag & challenges mores faster of tools : https://github.com/FastFilter/xor_singleheader.git I just want ensure you to that it is cracking brute-forcing private key from public key or anything else.......... Title: Re: Keyhunt - development requests - bug reports Post by: batareyka on June 21, 2021, 02:42:19 PM Hello
I'm trying to run the program. ./keyhunt -m pub2rmd -f tests / puzzleswopublickey.txt -q -b 19 In the file puzzleswopublickey.txt I use only this key ebfbe6819fcdebab061732ce91df7d586a037dee And find the public key. It takes a long time. Nothing found. What could be the problem? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 30, 2021, 11:17:59 AM I am confused if 120 address and public key are compressed why do you say we need to use "uncompress" for 120? Sorry that was a mistake, the program accept now both compress or uncompress. Would someone explain please, what's the point of generating the bPfile.bin file? I run tests with it and without, the speed performance seems to be about the same. Thank you. If you are goin to stop and restart the program to often is better to have the bPfile already precalculate to save some time between stop/restart the program. I think you can try xor filter, it's more faster. https://github.com/FastFilter/xor_singleheader I need to make some test but Im pretty sure that the speed will be closer. BTW the bottleneck is the ECC Operations not the bloom filter And find the public key. It takes a long time. Nothing found. What could be the problem? You don't have idea of what are you doing right? pub2rmd was a experiment it have the same difficulty of crack a 256 bit key. regards! Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on July 24, 2021, 11:21:04 PM I'm just now seeing this, is this worth trying to use?
Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on July 30, 2021, 05:38:51 AM 1. I launched:
Code: ./bPfile 3355443200 bPfile.bin ___ 2. A 100 GB file was created. Code: ./keyhunt -m bsgs -f 50bit.txt -b 50 -R -k 800 -t 12 ___ 3. I run: Code: ./keyhunt -m bsgs -f 1-63.txt -R -t 12 -r 0000000000000001:8000000000000000 -k 800 more than 1.5 hours passed, nothing went wrong, although if you make one public key of 63 bits, it finds it quickly. upd. Understood, it was necessary to remove the -R parameter It remains to understand whether the bPfile.bin file is necessary, since I did not notice any benefit from it, except for the 100GB of space on the ssd. Title: Re: Keyhunt - development requests - bug reports Post by: Unnameduser77 on August 08, 2021, 01:41:57 PM trying to build it on Win10 with Cygwin and getting following mistake:
Code: $ make Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on August 09, 2021, 01:52:44 PM What am I doing wrong?
Code: ~/keyhunt$ ./keyhunt -m bsgs -f pubkeys.txt -r 1:fffffffffffff -t 12 -k 800 How many lines can a file with public keys contain at most? Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on August 09, 2021, 03:02:28 PM trying to build it on Win10 with Cygwin and getting following mistake: can anyone help me? I recommend putting WSL2 and not bothering, a very convenient thing. https://docs.microsoft.com/en-us/windows/wsl/install-win10 Title: Re: Keyhunt - development requests - bug reports Post by: Unnameduser77 on August 10, 2021, 08:59:42 AM trying to build it on Win10 with Cygwin and getting following mistake: can anyone help me? I recommend putting WSL2 and not bothering, a very convenient thing. https://docs.microsoft.com/en-us/windows/wsl/install-win10 Title: Re: Keyhunt - development requests - bug reports Post by: johhny.shark on August 13, 2021, 06:09:07 AM anyone wondering if this is legal, or nah... ? :)
Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on August 13, 2021, 10:07:32 AM Legal.
Cryptocurrency rule: Whoever has the private key is the owner. Title: Re: Keyhunt - development requests - bug reports Post by: johhny.shark on August 13, 2021, 11:54:08 AM Well, in this case, is 100% legal! ::)
Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on August 13, 2021, 08:47:35 PM He who owns the private key, owns the cryptocurrency and that's a fact.
Title: Re: Keyhunt - development requests - bug reports Post by: johhny.shark on August 14, 2021, 01:31:34 PM Ok, I hope you get lucky and get the keys for some nice wallets, like microstrategy's or tesla's, and then I wish you luck in the court ;D
Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on August 29, 2021, 07:44:32 AM Is it possible with the help of a key hunt to make base58 > hash160?
All functionality is available, someone even created it for windows. https://github.com/kanhavishva/b58dec This can be useful for preparing a bloom filter for Brainflayer. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on August 31, 2021, 02:51:15 AM Is it possible with the help of a key hunt to make base58 > hash160? Are you wanting to know if the program keyhunt, can add this capability?All functionality is available, someone even created it for windows. https://github.com/kanhavishva/b58dec This can be useful for preparing a bloom filter for Brainflayer. Title: Re: Keyhunt - development requests - bug reports Post by: Alpaste on September 01, 2021, 12:54:12 PM Hello guys, please help
I'm having compile errors and bugs using linux..... Please help me someone post me a link to download keyhunt.exe file i would really be thankful! Thank you guys! Title: Re: Keyhunt - development requests - bug reports Post by: stilichovandal on September 01, 2021, 02:29:42 PM Trying to make on Ubuntu(WSL)
can anyone help with the below error? gcc -O3 -c bloom/bloom.c -o bloom.o g++ -O3 -c sha256/sha256.c -o sha256.o gcc -O3 -c base58/base58.c -o base58.o gcc -O3 -c rmd160/rmd160.c -o rmd160.o gcc -O3 -c sha3/sha3.c -o sha3.o gcc -O3 -c xxhash/xxhash.c -o xxhash.o g++ -O3 -c util.c -o util.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Int.cpp -o Int.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Point.cpp -o Point.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/SECP256K1.cpp -o SECP256K1.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/IntMod.cpp -o IntMod.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Random.cpp -o Random.o g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/IntGroup.cpp -o IntGroup.o g++ -o keyhunt keyhunt.c base58.o rmd160.o sha256.o bloom.o xxhash.o util.o Int.o Point.o SECP256K1.o IntMod.o Random.o IntGroup.o -lgmp -lm -lpthread /usr/bin/ld: cannot find -lgmp collect2: error: ld returned 1 exit status make: *** [Makefile:15: default] Error 1 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 09, 2021, 12:06:05 AM I'm just now seeing this, is this worth trying to use? No it not worth the time or effort Code: ./bPfile 3355443200 bPfile.bin each bP item is 32 bytes in disk. In RAM is about ~24 Bytes 2. A 100 GB file was created. Code: ./keyhunt -m bsgs -f 50bit.txt -b 50 -R -k 800 -t 12 The only performance is the time to generate the bPitems in runtime or read those from disk, anything else (Final speeed) is going to be the same Code: ./keyhunt -m bsgs -f 1-63.txt -R -t 12 -r 0000000000000001:8000000000000000 -k 800 more than 1.5 hours passed, nothing went wrong, although if you make one public key of 63 bits, it finds it quickly. upd. Understood, it was necessary to remove the -R parameter The mode bsgs works with each publickey individualy, this mean that 1 publickey give you some speed but 2 publickeys give you the half of that speed and so on... It remains to understand whether the bPfile.bin file is necessary, since I did not notice any benefit from it, except for the 100GB of space on the ssd. When people stop and rerun the program so many times the bP file is good but is you are going to let it run for months then the file is useless. anyone wondering if this is legal, or nah... ? :) I made this program for the puzzles. Is it possible with the help of a key hunt to make base58 > hash160? All functionality is available, someone even created it for windows. https://github.com/kanhavishva/b58dec This can be useful for preparing a bloom filter for Brainflayer. there are some tools that can do that. Trying to make on Ubuntu(WSL) can anyone help with the below error? /usr/bin/ld: cannot find -lgmp collect2: error: ld returned 1 exit status Install libgmp Title: Re: Keyhunt - development requests - bug reports Post by: hskun on September 09, 2021, 04:27:13 AM Hi WanderingPhilospher, thanks for test the program. I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop? Keyhunt use a Bloom filter to check if the generated address or hash is on the list, this will lead in some false positive collision (Error rate is one in a million or something like that), so if the the bloom filter return a positive result, it use a second check, this is a binary search over all the address or items in the list, it can dertermine if one item is on the list perfoming only log(N)/log(2) (https://www.wolframalpha.com/input/?i=log2%2815000000%29) operation, for 15 Milllions of addres this process only take 24 comparations. This is like the hash table but i prefer keep those separated becuase there are some trick with the bloom filter that allow you use a little less ram in the case of the BSGS mode. And no, in keyhunt there are no key drop or anything like that. why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE? Yes you are totally right this will be changed soon. Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boost all the modes speeds, address, rmd160, xpoint and bsgs mode in the code. Best regards! Hi albert0bsd, have any progress about the program? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 09, 2021, 01:39:34 PM Hi albert0bsd, have any progress about the program? Sorry there is no progress yet. Title: Re: Keyhunt - development requests - bug reports Post by: ByteFan on September 11, 2021, 06:32:20 AM Hi there,
Successfully straightforward built on Ubuntu 16.04.7 LTS. Wondering one thing. In bsgs mode with a range -r is there a way to log an intermediate state of the calculus so that you can stop everything than start again from such intermediate point without losing previous computation ? Thank you Title: Re: Keyhunt - development requests - bug reports Post by: alipostaci2002@gmail.com on September 12, 2021, 12:20:14 PM why zero?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 13, 2021, 11:21:23 PM Wondering one thing. In bsgs mode with a range -r is there a way to log an intermediate state of the calculus so that you can stop everything than start again from such intermediate point without losing previous computation ? Not yet im working in that. why zero? Because you add 100K publickeys, that is why it take some time in update the speed counter.
Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on September 14, 2021, 11:10:55 PM I think I saw a Window's version/release but I could not relocate it so I decided to make a Window's exe and put it out publicly in case any Windows users wanted to try out this program.
I tested via Windows 10 and all modes work. https://github.com/WanderingPhilosopher/keyhunt/releases (https://github.com/WanderingPhilosopher/keyhunt/releases) Code and exe files are on github. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 16, 2021, 01:02:52 AM I tested via Windows 10 and all modes work. Code and exe files are on github. Thank you so much Title: Re: Keyhunt - development requests - bug reports Post by: stilichovandal on September 20, 2021, 03:23:50 PM hi,
I have a file Pfile.bin file generated for 1B points. which is almost 30GB I get an error which states " Can't read the file seen you have fewer items that the amount needed" does this mean I need to have 25Gb+ ram for a 30GB Pfile.bin file ? :/mnt/d/crypto_repos/keyhunt$ ./keyhunt -m bsgs -f tests/120.txt -b 64 -k 256 -p ./Pfile.bin -t 4
Title: Re: Keyhunt - development requests - bug reports Post by: stilichovandal on September 20, 2021, 03:32:31 PM hi, I think I found the issue., the program looks for 1073741824 points in the Pfile.bin file.I have a file Pfile.bin file generated for 1B points. which is almost 30GB I get an error which states " Can't read the file seen you have fewer items that the amount needed" does this mean I need to have 25Gb+ ram for a 30GB Pfile.bin file ? :/mnt/d/crypto_repos/keyhunt$ ./keyhunt -m bsgs -f tests/120.txt -b 64 -k 256 -p ./Pfile.bin -t 4
The file I generated contains less than 1073741824. I think still one question remains ie is it faster of entire Pfile.bin can be loaded to the RAM? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 20, 2021, 06:24:17 PM How do you create the bPfile?
The best way to correct it is delete you current bPfile and create it again with the correct amount. Each item in the file is 32 bytes, but in ram it need to be processed to store ~4 bytes in bloom filter and 20 bytes in the array table. Title: Re: Keyhunt - development requests - bug reports Post by: tonylinux2008 on September 21, 2021, 02:34:14 PM would keyhunt be used for ethereum publickey?
I lost my 12.7 eth,and want get them back. here is the eth address:0xa42181ac82065d34095a3590c90cc56ac390ab5b Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on September 21, 2021, 03:15:43 PM would keyhunt be used for ethereum publickey? Do you have the pubkey? If not, but you had outgoing transactions, I or you could find the pubkey. Having the pubkey greatly reduces search time. You can use a variety of programs to help find your private key, especially with public key.I lost my 12.7 eth,and want get them back. here is the eth address:0xa42181ac82065d34095a3590c90cc56ac390ab5b Title: Re: Keyhunt - development requests - bug reports Post by: tonylinux2008 on September 21, 2021, 03:22:32 PM would keyhunt be used for ethereum publickey? Do you have the pubkey? If not, but you had outgoing transactions, I or you could find the pubkey. Having the pubkey greatly reduces search time. You can use a variety of programs to help find your private key, especially with public key.I lost my 12.7 eth,and want get them back. here is the eth address:0xa42181ac82065d34095a3590c90cc56ac390ab5b so keyhunt can be used for ethereum,only if i have publickey. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on September 21, 2021, 07:47:36 PM would keyhunt be used for ethereum publickey? Do you have the pubkey? If not, but you had outgoing transactions, I or you could find the pubkey. Having the pubkey greatly reduces search time. You can use a variety of programs to help find your private key, especially with public key.I lost my 12.7 eth,and want get them back. here is the eth address:0xa42181ac82065d34095a3590c90cc56ac390ab5b so keyhunt can be used for ethereum,only if i have publickey. Who is sb and how did they steal your eth? Title: Re: Keyhunt - development requests - bug reports Post by: tonylinux2008 on September 22, 2021, 02:40:36 PM would keyhunt be used for ethereum publickey? Do you have the pubkey? If not, but you had outgoing transactions, I or you could find the pubkey. Having the pubkey greatly reduces search time. You can use a variety of programs to help find your private key, especially with public key.I lost my 12.7 eth,and want get them back. here is the eth address:0xa42181ac82065d34095a3590c90cc56ac390ab5b so keyhunt can be used for ethereum,only if i have publickey. Who is sb and how did they steal your eth? Title: Re: Keyhunt - development requests - bug reports Post by: Kostelooscoin on October 03, 2021, 04:22:33 PM For 32gb ddr3 k = ???
Title: Re: Keyhunt - development requests - bug reports Post by: stilichovandal on October 11, 2021, 04:50:12 PM Hi albert0bsd, have any progress about the program? Sorry there is no progress yet. Thanks for the updated Beta version. It looks amazing. can you please tell what is the optimal value of n and K for 256GB RAM? thanks. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on October 11, 2021, 07:48:49 PM For 32gb ddr3 k = ??? maybe -k 2048, you need to test. can you please tell what is the optimal value of n and K for 256GB RAM? I don't know maybe you need to test with -n 0x400000000000000 and some values some values of K upto fill all the memory. The program tell you more of less how much mamoery is going to need, so test one value and press ctrl C if you that it doesn't fill your RAM Title: Re: Keyhunt - development requests - bug reports Post by: adaris on October 13, 2021, 09:56:34 AM I have a question about the operating mode -M matrix screen
It increases the chances of winning in random mode? this seems to be a bug because I can't see the speed counter in -M mode constantly jumps to the next line Quote ./keyhunt -m rmd160 -f tests/64.rmd -l compress -s 10 -b 64 -R -t 24 -M Quote Base key: b446a02fd6f5381f Base key: cae8a89843ee4ee8 Base key: 82fc18d395467fd4 I do not understand why the creation Bloom filter, became very slow almost 10 times slower. I used the -S key and -M. as I understand the key -S Bloom filter is created on disk/ from here creation Bloom filter the speed drops The previous version of the program directly created bloom in RAM And now it’s impossible? Title: Re: Keyhunt - development requests - bug reports Post by: adaris on October 13, 2021, 12:37:34 PM small calculation of how much RAM is needed to solve 120 puzzles
-n 0x100000000000000000000000000000 -k 1 Bloom filter for 288230376151711744 elements = 1.21755226 exabytes ram :o if Bloom filter for 13967032320 elements = 59.5GB if I didn't mess anything up Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on October 13, 2021, 04:17:58 PM I have a question about the operating mode -M matrix screen It increases the chances of winning in random mode? That options just a test, is to show the full output line by line. And no it doen't increment anything in chances. I add that option -M just because some users need to see the program "working" if they don't see lines running out the screen it they think that the program is stuck or freeze. I do not understand why the creation Bloom filter, became very slow almost 10 times slower. I used the -S key and -M. as I understand the key -S Bloom filter is created on disk/ from here creation Bloom filter the speed drops The previous version of the program directly created bloom in RAM And now it’s impossible? Yes that is a bug, i already correct it, i will update the github repository today. small calculation of how much RAM is needed to solve 120 puzzles -n 0x100000000000000000000000000000 -k 1 Bloom filter for 288230376151711744 elements = 1.21755226 exabytes ram :o if Bloom filter for 13967032320 elements = 59.5GB if I didn't mess anything up Seems tha the calculation is correct. That is why that puzzle is not solved yet. We all try it by our selfs just hopping for luck. By the way i made some videos about keyhunt: keyhunt - Why the program show 0 keys/s? (https://youtu.be/MVby8mYNxbI) Keyhunt Solving the 63 bit puzzle, just testing (https://youtu.be/6on-v-Cp8O8) Regards! Title: Re: Keyhunt - development requests - bug reports Post by: math09183 on October 13, 2021, 06:03:04 PM Did you observer any increase in memory usage with a new version?
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on October 14, 2021, 04:25:57 PM Seems tha the calculation is correct. That is why that puzzle is not solved yet. We all try it by our selfs just hopping for luck. By the way i made some videos about keyhunt: keyhunt - Why the program show 0 keys/s? (https://youtu.be/MVby8mYNxbI) Keyhunt Solving the 63 bit puzzle, just testing (https://youtu.be/6on-v-Cp8O8) Regards! Title: Re: Keyhunt - development requests - bug reports Post by: therealbtcdave on October 15, 2021, 05:31:23 PM How is the "-r" range supposed to work? I ran a test using keyhunt in address mode but set the range limited to 1:10.
I expected keyhunt to find the first 3 address only and stop searching due to the range I set. keyhunt found the first 3 addresses and more! I was confused why it found more than the first 3 addreses and continued searching past the range that was set? Test: ./keyhunt -m address -f tests/1to32.txt -r 1:10 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on October 15, 2021, 06:21:25 PM Albert, I think your videos will help people understand, especially the "0 keys" question! yes that is why i do it, any request for a new video just tell me :) How is the "-r" range supposed to work? I ran a test using keyhunt in address mode but set the range limited to 1:10. I expected keyhunt to find the first 3 address only and stop searching due to the range I set. keyhunt found the first 3 addresses and more! I was confused why it found more than the first 3 addreses and continued searching past the range that was set? Test: ./keyhunt -m address -f tests/1to32.txt -r 1:10 -r 1:10 is too small, i need to check the code but i remeber that the limit is something like 65K keys there are some internal limits for the number of operations, the minimal number of keys is 1024 but the code doesn't limit it, i need to chage it to show a warning in screen. Title: Re: Keyhunt - development requests - bug reports Post by: therealbtcdave on October 15, 2021, 08:58:16 PM Albert, I think your videos will help people understand, especially the "0 keys" question! yes that is why i do it, any request for a new video just tell me :) How is the "-r" range supposed to work? I ran a test using keyhunt in address mode but set the range limited to 1:10. I expected keyhunt to find the first 3 address only and stop searching due to the range I set. keyhunt found the first 3 addresses and more! I was confused why it found more than the first 3 addreses and continued searching past the range that was set? Test: ./keyhunt -m address -f tests/1to32.txt -r 1:10 -r 1:10 is too small, i need to check the code but i remeber that the limit is something like 65K keys there are some internal limits for the number of operations, the minimal number of keys is 1024 but the code doesn't limit it, i need to chage it to show a warning in screen. Ok I am following on the range being too small. I will try with a larger range and see if keyhunt works correctly. It would be helpful to know exactly what the minimum range limit is. So since I did not get the results I expected I held off on doing additional tests. A warning in the console would definitely be helpful if you use a range that is too small. Thanks for the quick response too. Title: Re: Keyhunt - development requests - bug reports Post by: adaris on October 24, 2021, 07:15:54 PM is it possible to add a mode -B dance to xpoint mode?
Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on October 24, 2021, 09:01:32 PM Is xpoint mode sequential or random when searching for keys?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on October 25, 2021, 08:13:26 PM By the way guys i just add support for
- Ethereum - Minikeys Also i double the speed for rmd160 and add stride option for xpoint, rmd160, address, and ethereum. is it possible to add a mode -B dance to xpoint mode? I need to make changes in the code to work with those new modes. Is xpoint mode sequential or random when searching for keys? That depend if you enable the flag -R, with that it is random. without it is sequential. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: physis11 on October 27, 2021, 04:41:11 AM Hi, is it possible for you to consider making a video, or even a step-by-step note on how to test find ethereum's private key, using a known public key.
I couldn't find a step by step about it and I couldn't do it. By the way guys i just add support for - Ethereum - Minikeys Title: Re: Keyhunt - development requests - bug reports Post by: physis11 on October 28, 2021, 09:37:53 AM Do you have the pubkey? If not, but you had outgoing transactions, I or you could find the pubkey. Having the pubkey greatly reduces search time. You can use a variety of programs to help find your private key, especially with public key.
[/quote] Hi, I'm new to this research. I know it's practically impossible to look up all the private keys. But with the public key is it possible? How much time? i have been playing with bsgs but to no avail single address ./keyhunt -m bsgs -f tests/1to32.eth -b 120 -k 640 -t 3 -q -S -B dance Title: Re: Keyhunt - development requests - bug reports Post by: dextronomous on October 28, 2021, 02:05:52 PM Dear alberto,
how is this not ok? or is it ok? how much time should this last processing take, already a long few hrs. passed,. thanks ./keyhunt -m bsgs -f pubs.txt -b 120 -k 1024 -q -t 6 +] Version 0.1.20210412 secp256k1
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on October 29, 2021, 01:59:29 AM Dear alberto, how is this not ok? or is it ok? how much time should this last processing take, already a long few hrs. passed,. thanks Hi, that is not OK but i seen that you are using an old version, that problem is already solved in the newest version. But with the public key is it possible? How much time? i have been playing with bsgs but to no avail It can take from one day to one trillion trillion years or more. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on November 11, 2021, 11:35:36 AM While specifying bit rage with -b in bsgs when giving 30 bit range -b 30 its throwing error "range too small". Do i need to change anything in the code or just use -r instead.
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 11, 2021, 04:52:21 PM In those case you need to use a small N value, like 0x40000000 (30 bits) or 0x1000000 (24 bits)
Code: -n 0x40000000 Code: -n 0x1000000 the default N value is 0x100000000000 enough to cover some 44 bits in a single operation using only some 1 or 2 MB of RAM Code: -n 0x100000000000 So i dont see the necessity to specify a lower range, unless you are doing some test for your self. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on November 11, 2021, 06:00:33 PM In those case you need to use a small N value, like 0x40000000 (30 bits) or 0x1000000 (24 bits) Exactly. i was testing the code, if i have compiled it right and the code is working.Code: -n 0x40000000 Code: -n 0x1000000 the default N value is 0x100000000000 enough to cover some 44 bits in a single operation using only some 1 or 2 MB of RAM Code: -n 0x100000000000 So i dont see the necessity to specify a lower range, unless you are doing some test for your self. Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on November 14, 2021, 05:26:03 AM In those case you need to use a small N value, like 0x40000000 (30 bits) or 0x1000000 (24 bits) Code: -n 0x40000000 Code: -n 0x1000000 the default N value is 0x100000000000 enough to cover some 44 bits in a single operation using only some 1 or 2 MB of RAM Code: -n 0x100000000000 So i dont see the necessity to specify a lower range, unless you are doing some test for your self. please guide me my pc for 80 cpu 256 GP ram, 1TP stroage ./keyhunt -m bsgs -f 120.txt -b 120 -S -t 2 - k 10 >>>>>>>>>> k value i am increaae system bloom filter error why :-[ :-[ :-\ only one public key use 2 petakeys / per seconed :'( how to reached 10 Exabyte keys per second please solve my problem Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 14, 2021, 05:09:31 PM Please post here your error
Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on November 15, 2021, 12:13:09 PM Please post here your error my question updateedit: https://bitcointalk.org/index.php?topic=5322040.msg58715394#msg58715394 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 15, 2021, 06:50:34 PM Something is not right with your errors
For K = 1024 the bloom filter is only 4294967296 elements and your error show 110010218577920 that is something more, DID YOU EDIT THE CODE? Another question is WHY THE FUCK are you using YELLOW COLOR TO POST TEXT? Are you retard or just one more troll? I hate python and i will never going to write one python. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on November 18, 2021, 04:00:30 PM Is using intel optane persistent memory has any effect on the speed compared to the regular Dram? Has anyone tested with it ?
Is using intel optane persistent memory has any effect on the speed compared to the regular Dram? Has anyone tested with it ? And one more thing dose the refersh rate of the RAM effect the performance in anyway[moderator's note: consecutive posts merged] Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on November 20, 2021, 05:49:58 AM albert why my post deleted auto
i need some tips for subtract i am not understand how to work to point subtract any easy example please dont remove my post again Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on November 20, 2021, 05:59:42 AM witch method use your code ./keysubtract and ./keymath
./keymath 03d01115d548e7561b15c38f004d734633687cf4419620095bc5b0f47070afe85a - 3 Result: 03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe ^ how to behind work ./kemath sub(-) i know tow point add,multiple ,but subtracter not understand https://github.com/albertobsd/keysubtracter/blob/main/keysubtracter.c please atleast this c code https://github.com/albertobsd/keysubtracter/blob/main/keysubtracter.c decode to mathematical explain :) ??? for example : c = K(qy-py)/(qx-px) rx1 = K(c^2-px-qx) ry2 = K(c*(px-rx)) #sorrymybadenglishspeak Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on November 21, 2021, 11:19:10 AM adding more than one pub key to the input file in BSGS mode is severely decreasing the performance like halving for every one extra pub key added to the input file. but somewhere in the thread i read that more pub keys dosent really effect the performance adversely. did anyone test. with one pub key i am getting 8pkeys/s add one more to the input file it drops to 4pkeys/s and so on.
Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on November 21, 2021, 10:02:19 PM adding more than one pub key to the input file in BSGS mode is severely decreasing the performance like halving for every one extra pub key added to the input file. but somewhere in the thread i read that more pub keys dosent really effect the performance adversely. did anyone test. with one pub key i am getting 8pkeys/s add one more to the input file it drops to 4pkeys/s and so on. You just answered your own question then, I only see people complain about if you add more public keys to BSGS it will decrease the performance. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 22, 2021, 04:19:52 AM ./keymath 03d01115d548e7561b15c38f004d734633687cf4419620095bc5b0f47070afe85a - 3 Result: 03acd484e2f0c7f65309ad178a9f559abde09796974c57e714c35f110dfc27ccbe ^ how to behind work ./kemath sub(-) i know tow point add,multiple ,but subtracter not understand Subtraction is the same operation that addition. A = C + B But instead of using a positive value for B, B is negative A = C + (-B) did you see it now? It is the same Point Addition operation but with some value Negated Title: Re: Keyhunt - development requests - bug reports Post by: toinou21 on November 30, 2021, 12:18:07 PM hi guys,
Im running WSL2 and still got an error ~/keyhunt$ make g++ -O3 -c oldbloom/bloom.cpp -o oldbloom.o make: g++: No such file or directory make: *** [Makefile:2: default] Error 127 Did I miss a step ? nevermind....it is working now, and I have no idea why. ??? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 30, 2021, 12:46:23 PM nevermind....it is working now, and I have no idea why. ??? Maybe you installed the build-essentials packages. Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on December 14, 2021, 06:47:23 AM hi my all questions...? please reply.
btc private keys brute force other tool compare best for ./keyhunt i am recommended for ,all cpu user i use ./keyhunt tool i am reach 990 Pkeys/s 120Puzzle.txt its good ??? i am see other people ./.keyhunt speed for 100 to 200 Ekeys/s its good :) :) Questions: 1. i am not gpu user, you can show ./keyhunt gpu speed screenshot 2. how to increase speed for my target how many cpu i need 3. my site show 64 puzzle result https://hashkeys.club/64/results/ all pepole show your 120puzzle final range :) easy to find me 4. share with me how to learn bloom filter quickly for 3 days form the scratch :) C,C++ java and Python #i_am_fast_learner :) :) 5.@albert0bsd your code limited Ykeys/s why? any update tips for my target 1000000000000000000000000000000000000000000000000000000000000000 #1+63zero my target One Novemdecillion/persecond 1000000000000000000000000000000000000000000000000000000000000 #1+60zero your reply write for question number specify like 12345.. #my_bad_english Something is not right with your errors hi albert solve my problem For K = 1024 the bloom filter is only 4294967296 elements and your error show 110010218577920 that is something more, DID YOU EDIT THE CODE? Another question is WHY THE FUCK are you using YELLOW COLOR TO POST TEXT? Are you retard or just one more troll? I hate python and i will never going to write one python. my question k value i am increaae error bloom_init error why?.. my pc upgrade for 160cpu 256ram 1Tp stroage 990 Pkeys/s ./keyhunt -m bsgs -f 120.txt -r 0:fffffffffffffffffffffff
usermanu111@root:~$ ./keyhunt -m bsgs -f 120.txt -r 0:fffffffffffffffffffffff -k 1024
usermanu111@root:~$ ./keyhunt -m bsgs -f 120.txt -r 0:fffffffffffffffffffffff -k 512
./keyhunt -m bsgs -f 120.txt -r 0:fffffffffffffffffffffff -k 160 -n 0x10000000000000
./keyhunt -m bsgs -f 120.txt -r 0:fffffffffffffffffffffff -k 160 -n 0x400000000000
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 16, 2021, 04:40:49 PM 1. i am not gpu user, you can show ./keyhunt gpu speed screenshot No because my keyhunt is only for CPU 2. how to increase speed for my target how many cpu i need What? 3. my site show 64 puzzle result https://hashkeys.club/64/results/ all pepole show your 120puzzle final range :) easy to find me What is the question here? 4. share with me how to learn bloom filter quickly for 3 days form the scratch :) C,C++ java and Python #i_am_fast_learner :) :) Check the code of the bloom filter that im using, it is pretty easy to understand. https://github.com/jvirkki/libbloom Also this video is pretty descriptive: https://www.youtube.com/watch?v=Z9_wrhdbSC4 5.@albert0bsd your code limited Ykeys/s why? any update tips for my target Because no one ever will reach more than some Exakeys / s in this century. Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on December 17, 2021, 08:19:55 AM keyhunt not find this public keys try why?....
i use this verison https://github.com/albertobsd/keyhunt/tree/9f33eda2354249ea984db37613f4a0a6869c9114 ./keyhunt -m bsgs -f 120.txt -r 900000000000000000000000000000:a00000000000000000000000000000 -t 2 i test some keys 039c069f5b3d1e4ac53e7c93b4b9cbc2a8b520ad25b227ecd5222f5f73e7ef8c92 private key 90000000000000000000f000000000 02b33f524226b0db26cb8bcb2b374100bd1b3e07900f0be5402d1277e80d392479 private key 90000000000000000000000f000000 028445b96038e322d51c173b19f3def3113e228d948fbaa0d4ebe6fdf1f21f834d private key 900000000000000000000f00000000 guys try this publickey https://brainwalletx.github.io/ edit: can not find try this ./keyhunt -m bsgs -f 120.txt -r a00000000000000000000000000000:ffffffffffffffffffffffffffffff -t 2 02ea7309a8087be07f2b303bf274ce9d1749ced28807fd23c12f14eab57a441556 private key a00000000000000000000f00000000 031df078c3f87ac4aec65597106906c88edaeb45a5ba2ea49eca2d80ca8e5a42b6 private key a000000000000000000f0000000000 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 17, 2021, 09:37:51 PM Well i try to find those keys and it only found one of the first three.
Code: albertobsd $ cat test.txt Thanks for report it The weird thing is that if I look for the next publickeys it found all: Code: 021fc9e584dc824cb5b566bb7125aef1e31c95fb2fbabc7c315686b3c211d69ed8 # 90000000000000000000f000000001 Code: albertobsd $ ./keyhunt -m bsgs -f test1.txt -r 900000000000000000000000000000:900000000000000010000000000000 -S -k 128 -q Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on December 21, 2021, 05:43:06 AM @albertobsd
iknow r s1s2 value i need z1z2 how to calculate i read this post explain testnet ,i am not understad https://bitcointalk.org/index.php?topic=5327054.msg56686056#msg56686056 https://bitcointalk.org/index.php?topic=977070.msg10669517#msg10669517 #read 1,3page please explain stepy by step calulate z1z2 from bitcoin mainet or write code Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 22, 2021, 09:02:14 AM @albertobsd iknow r s1s2 value i need z1z2 how to calculate please learn algebra if you have doubt of those post, please write your doubt there NOT HERE. Title: Re: Keyhunt - development requests - bug reports Post by: Alpaste on December 22, 2021, 02:07:52 PM Hello albertobsd i have a Questions outside and inside this awesome program that you have made.
i've been looking for correct answers for weeks, but everyone says differently so your the one who to ask, because you're a bitcoin expert here. :) Questions: So total possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right? ========== Another Question related: So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct? ========== Last Question. Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ) Hex-Range with high number of Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck) ========== if you could answer all this three Question, then i really appreciate it! Best regards. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 26, 2021, 06:30:02 AM So total possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right? In theory there are 2^96 privatekeys for each bitcoin address. Yes! that is correct. And each one of those 2^96 private keys will generate a different publickey but all those 2^96 publickeys will generate the same rmd160 hash. Also one address can be generated from compressed or uncompressed publickey But actually no one has ever found one example. So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct? All addresses of bitcoin exists only 1 TIME from the range... there are no proof of that "ONLY ONE TIME..." maybe yes but repeat there is no proof of that. There are the possibility that one address have 1 or more private keys under the range of 2^0 to 2^160 If my previous sentence is correct then that means that there are ranges of 160 bits that can haven't a specific address for example the "1111111111111111111114oLvT2" hash rmd160: 0000000000000000000000000000000000000000 We haven't enough computer power to prove or disprove that, proof of that is that the puzzle 64 is still there. Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ) Hex-Range with high number of Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck) Not really because there are 2^256 publickeys different for each other so unless that publickey was under that 2^160 range, only in that case it will be found. But we still can't solve the publickey for the puzzle 120 Times to solve the puzzle 160 at specific speeds: Code: Puzzle 160 @ 1 Megakeys/s (10^6): 23171956451847141650870193314248525 years Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on December 28, 2021, 09:58:04 AM Also one address can be generated from compressed or uncompressed publickey Did you mean "one private key may generate two different addresses, depending which public key is used"? All we may talk about are only numbers, and that's true that using hash which may produce maximally 2^160 results limits somehow the number of addresses. BUT: nowadays we do not have power to try each of them. We know there are collisions, but we cannot USE them. And that's true that one private key produce public key which may be used in any of two forms, and that's true that it would be possible that uncompressed public key from one priv key generates the same address as compressed pubkey from another priv key. But we have only assumptions, no tools. If one day we would create addresses based on other transformation of public key, we would be in completely different situation. One remark - people have problems with exponentiation, as it is not in common use in every day life. We add, multiply... But in general it is no obvious to understand what is the difference between 2^10 and 2^11 comparing to 2*10 and 2*11. And then to realize the difference between 2^60 and 2^64... Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 28, 2021, 01:00:44 PM Did you mean "one private key may generate two different addresses, depending which public key is used"? No, i mean the other thing that you said after: and that's true that it would be possible that uncompressed public key from one priv key generates the same address as compressed pubkey from another priv key. Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on December 28, 2021, 01:49:19 PM Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120?
Title: Re: Keyhunt - development requests - bug reports Post by: mynonce on December 28, 2021, 06:26:31 PM Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120? #120: private key is between 2^119 and 2^120 - 1 ... and the last key #160: private key is between 2^159 and 2^160 - 1 Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on December 28, 2021, 07:06:27 PM Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120? For puzzle ranges are coming one by one and each range is bigger (wider?). But you do not launch search from the beginning (key=1), but in the specific range, which is in fact result of previous ranges. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on December 29, 2021, 11:36:25 AM Hello albertobsd i have a Questions outside and inside this awesome program that you have made. You keep hearing different opinions because people have different understanding of public key. If someone assumes that wallet address itself is public key he will tell you that the key space is 2^160 remaining are just collisions. But if your are talking about actual public key then you have to search in the space of 2^256 to find a private key. If you are randomly using a public key in BSGS mod then the key space is 2^256. Here is the tradeoff if your using BSGS the speeds are in typpical pkeys/sec but the range is too large and a good ram will help you. But if you are hasing the public key to ripemd-160 the typical speed is mkeys/sec a good GPU will help you. But BSGS is best for solving puzzle. And about the luck part no offense but you are not understanding the odds, if you think you are that lucky pick up a rock outside your house and it will turnout to be a meteorite in which case you will earn millions.i've been looking for correct answers for weeks, but everyone says differently so your the one who to ask, because you're a bitcoin expert here. :) Questions: So total possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right? ========== Another Question related: So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct? ========== Last Question. Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ) Hex-Range with high number of Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck) ========== if you could answer all this three Question, then i really appreciate it! Best regards. -- by the way this is my understanding of bitcoin if i am wrong please correct me i am eager to learn Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on December 29, 2021, 03:00:23 PM Alberto,
Is there any road map for the project? Do you want to focus on new features or do you prefer to focus on improving performance of the existing code? What about splitting code to avoid unnecessary ifs/switches? Any plans to introduce stride? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 30, 2021, 11:38:40 AM Alberto, Is there any road map for the project? Do you want to focus on new features or do you prefer to focus on improving performance of the existing code? What about splitting code to avoid unnecessary ifs/switches? Any plans to introduce stride? https://github.com/albertobsd/keyhunt/discussions/142 What about splitting code to avoid unnecessary ifs/switches? Yes that will be nice, the problem for that is that if I change some behavior in the main cycle of the process i will need to edit all those separate functions. Any plans to introduce stride? There are already stride, but it is not working properly i need to fix it. BTW there are not stride for BSGS. Title: Re: Keyhunt - development requests - bug reports Post by: Alpaste on December 30, 2021, 01:48:20 PM Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68? if we get the publickeys, the puzzles would be solved in less than minute. Thanks in advance. Title: Re: Keyhunt - development requests - bug reports Post by: CoinMagus on December 30, 2021, 06:20:13 PM Dear albertobsd, can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68? if we get the publickeys, the puzzles would be solved in less than minute. Thanks in advance. I just know little python and I did something like this: https://github.com/sezginyildirim91/keysubtracter If it is adapted to the C language, it can be very productive. Title: Re: Keyhunt - development requests - bug reports Post by: Alpaste on December 31, 2021, 10:52:25 PM Thank you for posting your idea!
but this idea is really rare to success and to happen, and it takes a lot of time to do searching in a such huge range space. We need a better algorithm to target public keys. Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on January 01, 2022, 02:27:10 PM hi albert
@cixegz this user question https://bitcointalk.org/index.php?topic=5379443.msg58874670#msg58874670 its posible algebra and math tricks use to guess y odd is small or big range y even is small or big Roll Eyes range Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on January 02, 2022, 02:22:07 PM Dear albertobsd, can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68? if we get the publickeys, the puzzles would be solved in less than minute. Thanks in advance. He already has that, its called pub2rmd mode its under Experimental modes https://github.com/albertobsd/keyhunt#pub2rmd-mode Title: Re: Keyhunt - development requests - bug reports Post by: CoinMagus on January 02, 2022, 10:36:03 PM Dear albertobsd, can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68? if we get the publickeys, the puzzles would be solved in less than minute. Thanks in advance. He already has that, its called pub2rmd mode its under Experimental modes https://github.com/albertobsd/keyhunt#pub2rmd-mode Keyhunt searches the whole range in pub2rmd mode. It searches in the range given in the link I shared above. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on January 05, 2022, 12:26:17 AM hi albert @cixegz this user question https://bitcointalk.org/index.php?topic=5379443.msg58874670#msg58874670 its posible algebra and math tricks use to guess y odd is small or big range y even is small or big Roll Eyes range No there is no way to do that... Title: Re: Keyhunt - development requests - bug reports Post by: cryptoQueez on January 07, 2022, 05:48:30 AM I want to open this thread to talk about the tool that i develop Keyhunt (https://github.com/albertobsd/keyhunt) available on github. https://github.com/albertobsd/keyhunt (https://github.com/albertobsd/keyhunt) Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed. To try to find the privatekey from the 120 puzzle you need to add this publickey "uncompress" to a txt file: How to use
120.txt Code: 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 you can run the tool agains that file: Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R output Code: [+] Version 0.1.20210321 K*BSGS Speed: 1 Terakeys/s Well in that example (same in github) we can reach 1Terakeys/s with one thread. Wan to more speed? use the "-k value" param to boots the speed Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R -k 20 Output: Code: [+] Version 0.1.20210321 K*BSGS Speed: ~23 Terekeys/s Tips
Do you still want to more speed? Well Use more RAM, the -k 128 will use some 2.5 GB of RAM This file will take some minutes for the value -k 128, but the speed worth it! Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R -k 128 -p ./bPfile.bin Output: Code: [+] Version 0.1.20210321 K*BSGS Speed: ~146 Terakeys/s one single thread OK at this point maybe you want to use ALL your RAM memory to solve the puzzle 120, just a bigger -k value I already tested it with some 24 GB used with -k 1024 and I get 1.16 Petakeys/s per thread. Using the same configuration with 4 threads I get 4.5 Petakeys/s total Image: https://albertobsd.dev/uploads/1616428067_bd1fc052-9441-4cbb-9bd1-d2e393489e18.jpg FAQ Q: Why the Progress is not displayed? R: The speed depent of the number of target publickeys if you load 1000 publickeys, it will take some more time, the speed is only displayed when at least one thread finish one of his cycles Q: Can we faster this code with Gpu? R: Well yes, but the BSGS algo use RAM, only high end video cards have a lot of RAM, for GPU is better to use Kangaroo Q: How long will take the scan the 120 bit range? R: Human brain usually can't handle big numbers, the 120 bit space have 664613997892457936451903530140172287 (six hundred sixty four decillion...) and we speed is about 1000000000000 (one trillion or one terakey/s) the spected time acording with your speed is: Code: Puzzle 120 @ 1 Terakeys/s : 21074771622667996 years Q: Why should i keep using brute force tools? R: You should not, but people hope in luck. Q: Is avaible for Windows? R: Natively no, but you can install the ubuntu shell for windows and compile it from there Q: It have dependencies? R: Just libgmp for BigIntegers install it with Code: apt-get install libgmp3-dev Q: Why your program use alot of RAM? R: Actuallly i keep in RAM two things (Bloomfilter and a Full bPTable ) im working in one way to remove or reduce the bPTable. Nexts releases
Best regards! Great information to share!! How to use pfile?? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on January 08, 2022, 01:21:16 PM Great information to share!! How to use pfile?? Why quote all the post ?? Why not just to ask that? The pfile is obsolete right now, the new version generate his own files automatically if you use always the -S option. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: adaris on January 15, 2022, 04:08:12 PM Hello. please help me to calculate the probability of winning puzzle 120 in random mode
if i have 20000000001 keysubtract speed 27000000/s what are the chances ? it is more than 0,0002% ? Title: Re: Keyhunt - development requests - bug reports Post by: DeepComplex on January 26, 2022, 10:25:23 PM Hi Albert0bsd,
Any updates on the additional features for Keyhunt? Regards, Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on February 24, 2022, 04:54:43 AM is it possible to add an option to search for lost characters in the private key?
For example: Address 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN Private key 5KYZdUEo***3FPrtuX2Qb***nNP5zTd7yyr2S******sBCnWjss or e3b0c44****c1c149afbf4c8996fb****7ae41e4649b934c****991b7852b855 Maybe someone knows similar already existing programs? Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on February 24, 2022, 07:17:41 AM is it possible to add an option to search for lost characters in the private key? For example: Address 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN Private key 5KYZdUEo***3FPrtuX2Qb***nNP5zTd7yyr2S******sBCnWjss or e3b0c44****c1c149afbf4c8996fb****7ae41e4649b934c****991b7852b855 Maybe someone knows similar already existing programs? If you have missing characters in WIF, decoding to private key (hex) is not obvious. The most probably the example your show is incorrect. For restoring WIF, you have several programs, I will mention mine (https://github.com/PawelGorny/WifSolver) where you may specify "gaps" and characters which you want to try there. For restoring private key with gaps, I do not know any program, but if you have serious case to solve, I may write something new. All depends on number of missing characters. 12 like in your example is already a serious amount of work. Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on February 25, 2022, 07:27:13 AM I'm just interested in a tool with which you can iterate over the missing characters of the private key. I wonder how fast this can be done knowing the hexadecimal key with the missing characters and the address or hash160. Now I found a program that selects 7 characters ~ 1 hour. Perhaps the creator of the keyhunt knows faster algorithms.
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 01, 2022, 06:04:58 PM Any updates on the additional features for Keyhunt? Not yet sorry. is it possible to add an option to search for lost characters in the private key? I've thinking in this for a while, but i think that it will be a better option make new program for that. Since there are different cases for every kind of places where the missing are (together or not) ending, beggining middle, publickey available or not, it is a lot of work. All depends on number of missing characters. 12 like in your example is already a serious amount of work. I agree with that 12 missing characters is a lot of work. And more if there are in different part of the key. Private key 5KYZdUEo***3FPrtuX2Qb***nNP5zTd7yyr2S******sBCnWjss or 58^12 = 1449225352009601191936 e3b0c44****c1c149afbf4c8996fb****7ae41e4649b934c****991b7852b855 16^12 = 281474976710656 The second key is more solvable that the first one. By the way that kind of examples are rare to be found and most of then are not real. Perhaps the creator of the keyhunt knows faster algorithms. With the publickey avaiable for this example we can use BSGS to do this task but we need some changes becasuse we need to do the calculate the differents ranges for each different change in the most significan bytes. To solve the your hexadecimal key example is only a 48 bits problem. because 16^12 = 2^48 = 281474976710656 If we do the last 2 missing bytes with BSGS the problem can be reduced to only a 32 bits of forcebrute, this problem can be done/solve in some hours CPU with the correct code. Edit I found in a way to solve this (Hexadecimal key) in less than one hour, we can divide it in 2 parts a hashtable/bloomfilter of 2^24 of precalculated keys, and 24 bits of forcebrute with some math operations with publickey. Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on March 02, 2022, 09:02:32 PM I gave this key as an example, in my case there are more unknown characters.
I correctly understood that everything that you wrote about the division of the private key and the use of the BSGS is only subject to a known public key? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 02, 2022, 09:17:45 PM I correctly understood that everything that you wrote about the division of the private key and the use of the BSGS is only subject to a known public key? Yes, all those things I wrote before are only possible with the public key. Without it there are not shortcuts or math tricks. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on March 02, 2022, 10:52:41 PM Any updates on the additional features for Keyhunt? Perhaps the creator of the keyhunt knows faster algorithms. Edit I found in a way to solve this (Hexadecimal key) in less than one hour, we can divide it in 2 parts a hashtable/bloomfilter of 2^24 of precalculated keys, and 24 bits of forcebrute with some math operations with publickey. I wanted to know 2^24 precalculated keys, is that the maximum precalculated keys that would fit in the hashtable/bloomfilter or could you add more than that? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 02, 2022, 11:04:09 PM I wanted to know 2^24 precalculated keys, is that the maximum precalculated keys that would fit in the hashtable/bloomfilter or could you add more than that? The only limit is the RAM, near 28-29 bits per element in the bloom filter and some 10 bytes per item in an Array to do binary search, this is near to 14 bytes per item in total. I say 24 bits of precalculated data and 24 for cracking because the way that the missing characters are distributed in the user example: Code: e3b0c44****c1c149afbf4c8996fb****7ae41e4649b934c****991b7852b855 My idea is precalculate this part: **7ae41e4649b934c****991b7852b855 and just brute force the second. if all the missing characters were together then it can be solved with BSGS in seconds Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on March 03, 2022, 08:25:59 AM My idea is precalculate this part: **7ae41e4649b934c****991b7852b855 and just brute force the second. I think PrivatePerson is referring to that topic: https://bitcointalk.org/index.php?topic=5385235.0 For sure any gap is a complication and I think brute-forcing the key from puzzle requires a dedicated program, relying on existing solutions requires too many additional assumptions. Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on March 03, 2022, 04:07:44 PM I think PrivatePerson is referring to that topic... Over time, the number of unknown characters will decrease.Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 03, 2022, 04:15:05 PM I think PrivatePerson is referring to that topic: https://bitcointalk.org/index.php?topic=5385235.0 Wow i never heard about it, 30 missing characters and no publickey. 16^30 = 1329227995784915872903807060280344576 That is 120 bits complexity, and there is no publickey available. Please Forget that puzzle is infeasible. We still can't solve Puzzle 64 bits (this is 16 missing characters) For sure any gap is a complication and I think brute-forcing the key from puzzle requires a dedicated program, relying on existing solutions requires too many additional assumptions. I agree with that, that kind of missing distribution require a specialized program. Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on March 07, 2022, 01:54:51 PM Where or who has the BSGS that can search for multiple public keys?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 07, 2022, 05:57:15 PM Where or who has the BSGS that can search for multiple public keys? Check my tweet: https://twitter.com/albertobsd/status/1491653063882383362 I tested One million of publickey with a speed of 40 Gigakeys/s with only 4threads and 22 Gigabytes of RAM used Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on March 08, 2022, 02:47:29 PM Where or who has the BSGS that can search for multiple public keys? Check my tweet: https://twitter.com/albertobsd/status/1491653063882383362 I tested One million of publickey with a speed of 40 Gigakeys/s with only 4threads and 22 Gigabytes of RAM used Oh so you already had the bsgs that could search multiple keys. I have 2 questions if my keys is 0 is it still generating keys or what? I know about using a lot keys slows the speed down Is the search range for BSGS n/2 right? and not like xpoint mode when you have to search the whole range? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 08, 2022, 06:32:53 PM Is the search range for BSGS n/2 right? and not like xpoint mode when you have to search the whole range? The range is the range that you specify with the -r from:to parameter or the bit range with -b bit I have 2 questions if my keys is 0 is it still generating keys or what? I know about using a lot keys slows the speed down The program should work fine the problem with the speed of 0 keys/s is because the number of key already scanned only get update when the BSGS process end one cycle complete with all the publickeys depending of your CPU speed, RAM bus, and number of publickey it may take a lot of time in some cases but the speed should be good. Recomendations: - Don't use SWAP memory - Don't use Virtualized OS - Don't use windows version Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on March 09, 2022, 07:49:11 AM My idea is precalculate this part: **7ae41e4649b934c****991b7852b855 and just brute force the second. if all the missing characters were together then it can be solved with BSGS in seconds Can you explain (maybe there are ready-made solutions): 1. How to split the private key into parts and brute through it in parts? 2. How to brute a private key with missing characters together? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 09, 2022, 04:37:57 PM 1. How to split the private key into parts and brute through it in parts? I will explain this one using only privatekeys. But remember that those calculations depend only if you already have the TARGET PUBLICKEY. if you don't have the publickey this example doesn't apply. Lets to asume that we have the key like you example: Code: e3b0c44****c1c149afbf4c8996fb****7ae41e4649b934c****991b7852b855 We divide it in two parts, most significative bytes and less significative bytes. Part 1 less significative bytes: Code: **7ae41e4649b934c****991b7852b855 We calculate and store the publickeys from Code: 007ae41e4649b934c0000991b7852b855 Code: ff7ae41e4649b934cffff991b7852b855 In this example is 2^24 publickeys (16777216 publickey) this can be done in seconds, this part is the precalculated data it can be more but all depend of how much memory do you have. now the second part: Code: e3b0c44****c1c149afbf4c8996fb** This part must be brute force from Code: e3b0c440000c1c149afbf4c8996fb00 to Code: e3b0c44ffffc1c149afbf4c8996fbff We need to add the remaining bytes filled as ZERO Example: Code: e3b0c440000c1c149afbf4c8996fb00000000000000000000000000000000000 We need to calculate each of those public key, this is again 2^24 public keys to be calculate. For EACH of those "TEMP PUBLICKEY" values we need to do a Public keys subtraction Code: NEW PUBLICKEY = TARGET PUBLICKEY - TEMP PUBLICKEY Now we need to compare the NEW PUBLICKEY against our precalcualted data if there is a match then we only need to concatenate or Add our partials privatekey to get the real one. Example, lets to say that the TARGET PRIVATEKEY is e3b0c441234c1c149afbf4c8996fb56ab7ae41e4649b934ccdef991b7852b855 In that case in some point our subtraction will be something like this: Code: ab7ae41e4649b934ccdef991b7852b855 = e3b0c441234c1c149afbf4c8996fb56ab7ae41e4649b934ccdef991b7852b855 - e3b0c441234c1c149afbf4c8996fb56000000000000000000000000000000000 If there is a match our privatekey will be: Code: ab7ae41e4649b934ccdef991b7852b855 + e3b0c441234c1c149afbf4c8996fb56000000000000000000000000000000000 maybe there are ready-made solutions NO, there is no public program that do that actually, because those examples of missing characters are unlikely to happen. 2. How to brute a private key with missing characters together? Is exactly the same but with the advantage that we can use BSGS at full capacity Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on March 10, 2022, 03:21:25 PM How many keys do you have to go through to solve puzzle #120 with BSGS, is it 2^60?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 10, 2022, 09:15:51 PM Yes in a perfect bsgs that is the amount:
(2^120)^(1/2) = 1152921504606846976 = 2^60 But just make the calculations how many memory is necessary to store 2^60 of precalculated data using 20 bytes per item in the bloom filter and hashtable: 20971520 Terabytes of RAM And that is only the first part (Baby steps) we need to iterate over the other half 2^60 to make subtractions of the publickey with our current range (Giant step). Title: Re: Keyhunt - development requests - bug reports Post by: mausuv on March 18, 2022, 05:42:54 PM Yes in a perfect bsgs that is the amount: (2^120)^(1/2) = 1152921504606846976 = 2^60 But just make the calculations how many memory is necessary to store 2^60 of precalculated data using 20 bytes per item in the bloom filter and hashtable: 20971520 Terabytes of RAM And that is only the first part (Baby steps) we need to iterate over the other half 2^60 to make subtractions of the publickey with our current range (Giant step). test.txt Code: ./keyhunt -m bsgs -f 120 -r 7357a4501ddfe92f46681b20a0:d576e7357a4501ddff92f46681b20ff hi guys, how to run my test.txt because, every time i copy past and Run ./keyhunt small update please,once range complete open my test.txt and run the next range understand my problom ,sorry i speak little english so, please tell how to run one by one my custom range>>>my test.txt any python method to run ./keyhunt <test.txt> Title: Re: Keyhunt - development requests - bug reports Post by: Alpaste on April 11, 2022, 08:57:31 PM Hello Albert0bsd,
a probably stupid question, but is it actually possible to mine Bitcoin using BSGS algorithm? If not possible, why not? much regards! Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 11, 2022, 11:29:23 PM a probably stupid question, but is it actually possible to mine Bitcoin using BSGS algorithm? If not possible, why not? Is not possible. Because Mining for bitcoin is a proof of work with sha256. BSGS is only an algorithm for computing discrete logarithms on elliptic curve. If you want to know more about it please READ the next two links: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on April 15, 2022, 03:49:52 PM albert0bsd, would it be better to use a .bin than a .blm to store the public keys?
That shouldn't effect the overall speed. Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on April 15, 2022, 10:34:02 PM I tested via Windows 10 and all modes work. Code and exe files are on github. Thank you so much Hey WanderingPhilospher , how do You run Your version on win 10? , using standard command promp in Win gives missing libraries errors, complete Linux noob here btw ??? Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on April 15, 2022, 11:58:59 PM I tested via Windows 10 and all modes work. Code and exe files are on github. Thank you so much Hey WanderingPhilospher , how do You run Your version on win 10? , using standard command promp in Win gives missing libraries errors, complete Linux noob here btw ??? Try this one instead doesn't give errors https://github.com/XopMC/keyhunt-win Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on April 16, 2022, 11:45:15 AM I tested via Windows 10 and all modes work. Code and exe files are on github. Thank you so much Hey WanderingPhilospher , how do You run Your version on win 10? , using standard command promp in Win gives missing libraries errors, complete Linux noob here btw ??? Try this one instead doesn't give errors https://github.com/XopMC/keyhunt-win Thanks!!! Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on April 17, 2022, 08:34:25 PM Code: [+] Version 0.2.211222 SSE Server Edition ,modify Dusky Kam 3,compiled by @XopMC for t.me/brythbit, developed by AlbertoBSD, developed by AlbertoBSD In random mode, how often does the range change ? Can we set the parameter somehow ? Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on April 18, 2022, 02:28:06 PM Code: [+] Version 0.2.211222 SSE Server Edition ,modify Dusky Kam 3,compiled by @XopMC for t.me/brythbit, developed by AlbertoBSD, developed by AlbertoBSD In random mode, how often does the range change ? Can we set the parameter somehow ? Every second it hashes its random Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on May 08, 2022, 05:01:13 PM Hello albert0bsd,
Did you see the new challenge/puzzle that is worth 500 Bitcoins? it's called wif500. I It's a challenge where a wallpaper has been burned so it misses the first 12 letters of the WIF private key. The address has 500 BTC in total. Can you please give us your opinion about this puzzle? is it real? is it possible to solve it by any chance? is this a scam? What kind of coding/program does it need so it can be solved? (since the beginning of the private key that it's missing) if it's real can you please develop something to get the first 12 letters of the WIF? (even by trying with luck i believe in luck and it's big money 20 millions euros so yeah,,) regards,, Challenge/puzzle link: https://github.com/phrutis/wif500 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 09, 2022, 02:02:00 AM Hello albert0bsd, Did you see the new challenge/puzzle that is worth 500 Bitcoins? it's called wif500. I It's a challenge where a wallpaper has been burned so it misses the first 12 letters of the WIF private key. The address has 500 BTC in total. Can you please give us your opinion about this puzzle? is it real? is it possible to solve it by any chance? is this a scam? What kind of coding/program does it need so it can be solved? (since the beginning of the private key that it's missing) if it's real can you please develop something to get the first 12 letters of the WIF? (even by trying with luck i believe in luck and it's big money 20 millions euros so yeah,,) regards,, Challenge/puzzle link: https://github.com/phrutis/wif500 Is fake Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on May 10, 2022, 07:45:40 PM This is very true. this challenge is so suspicious actually because why in hell does he publish a closed source program?
maybe if someone finds the key it encrypt it so no one can unlock it except him? (assuming if it's real) Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 11, 2022, 12:23:16 AM This is very true. this challenge is so suspicious actually because why in hell does he publish a closed source program? Yes, that is exactly why...but he says that if you read the github.maybe if someone finds the key it encrypt it so no one can unlock it except him? (assuming if it's real) If he did not encrypt (I imagine he shifted target key, sub or add), then anyone could run the unran/free ranges and claim (if there is actually a prize) all of the BTC. Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on May 11, 2022, 06:35:45 AM I think all tools should be open-source code for transparent
it is dangerous to use tools not show code may use GPU for calculating some hidden when using it for user use all tools should block internet access on that tools before using or unplug wifi and use it offline Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on May 11, 2022, 09:33:41 PM Yes exactly.
Well i actually suspect that the creator of the ''challenge'' has claimed that he lost 500 bitcoins and want us to search for him for the remaining 12 private key characters, where in reality we might actually be searching for something else,,,,, like for puzzle 64's private key!! he might actually have lied to us and to anyone who is searching and using his closed-program they might just be searching for puzzle 64 private key for him instead of the claimed 500 bitcoins private key.... Could be that case, that we fell in trap and he is letting us search for puzzle 64 instead? That's why he is using a closed-program, so we can't notice that we're searching for something else rather than the 500 BTC's key. that is my suspecting only. I can be wrong though. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 11, 2022, 10:24:24 PM Yes exactly. Def not for #64 or #120...not enough ranges covered and not enough firepower, for long enough.Well i actually suspect that the creator of the ''challenge'' has claimed that he lost 500 bitcoins and want us to search for him for the remaining 12 private key characters, where in reality we might actually be searching for something else,,,,, like for puzzle 64's private key!! he might actually have lied to us and to anyone who is searching and using his closed-program they might just be searching for puzzle 64 private key for him instead of the claimed 500 bitcoins private key.... Could be that case, that we fell in trap and he is letting us search for puzzle 64 instead? That's why he is using a closed-program, so we can't notice that we're searching for something else rather than the 500 BTC's key. that is my suspecting only. I can be wrong though. I used a closed source for the #64 pool b/c we had 15-20 people working on it and if I would have left it open source, someone could have tweaked the code and if they found the key, kept it for themselves. I wonder if the puzzle is real and if the letters and numbers have been deciphered correctly. It took me 10 minutes to get the second address correctly and still did not decipher it's wif, even though all characters are present LOL! Title: Re: Keyhunt - development requests - bug reports Post by: math09183 on May 12, 2022, 10:40:21 AM I think there is nothing extra, as phrutis is too stupid to develop any software. He is just a regular russian
In that case he took WifSolveCuda, hardcoded ranges and removed printing data to the screen. WIF is obviously fake, known for months, but as long as russians waste their time and electricity on that, I am fine. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 12, 2022, 01:05:43 PM Please guys stay on keyhunt topic, avoid any comment of those fake wifs
Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on May 13, 2022, 10:16:20 AM Hey albert0bsd,
I assume that in BSGS mode there no no such option as random changed key after a given key value searched? Something like in VanitySearch there is -r as for random but also a value after how many searched keys the key is changed Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on May 13, 2022, 01:14:01 PM Please guys stay on keyhunt topic, avoid any comment of those fake wifs Hi, albert0bsd I would like to understand BSGS, Can you help to explain some methods? (I can study in detail more) I understand kangaroos (a little some part) and understand some entropy or scalar for the Elliptic curve convert private key to public key a lot of bitcoin and cryptography I do not yet understand clear Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 13, 2022, 07:19:45 PM Imagine that you have one Single operation to check if some Publickey P(x) is between some fixed range lets to say from 1 to 1M such operation will be like:
Code: if 1 <= P(x) <= 1M That operation doesn't exist because Public keys are hidden numbers they hide the x value (Private key) So, what happened if you have the Cache of the first million keys, you only need to have a function that let you know if some publickey is inside of one array Code: if is_publickey_in_array(P(x),array) to be computationally efficient, that function need to be fast O(1), There are a lot of Data structures that can do that, Hashtables, maps, bloomfilters etc, or some combinations between them. What BSGS Do? The first step is try to translate the P(x) to the keyspace between 1 to 1M (This amount can be changed this depends of the available memory), this operation is done by one single subtraction. Lets to say that the value of x is 100123987 Code: P(100123987) = 03992723319651c25a1e3dc624af41a8625a90c3c455f806a4a2b385175750b211 If we check for the function that value of P(123987) is in the array is_publickey_in_array(P(x),array) then the the result will be that we found the key, you only need to find what of those Million of values is your key and then just do some additions to recover the original KEY. For the previous example imagine that you start from 1 to reach 100M you only need 100 Point Subtractions and 100 checks in the arrays, so instead of bruteforce that publickey 100 Million times you only need 100 basic operations that is why bsgs is some fast This is a basic example, the real BSGS need some extra considerations like work with Perfect squares numbers, and also will be better if we work with Base 2 numbers like 2^Y numbers This is an example with One million of publickeys in cache, now imagine what you can do with with some Billions of keys in your cache. you can read more of BSGS in https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ I assume that in BSGS mode there no no such option as random changed key after a given key value searched? The -R option enable the random search, every time that one thread do a search it chose a different random number, this is EVERY single cycle one random number is chossen. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: CoinMagus on May 14, 2022, 08:03:18 PM I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man.
Code: root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on May 14, 2022, 08:30:28 PM I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man. Code: root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode. Title: Re: Keyhunt - development requests - bug reports Post by: CoinMagus on May 15, 2022, 12:25:11 AM Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode. I don't quite understand what you are trying to convey. We're already looking for a ^120-bit range, how come in BSGS mode you detect a ^120-bit field as ^60-bits? Also, loading 2 billion 700 million points in BSGS mode will not be efficient. Searching for a point with the -R option will take much longer. Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on May 15, 2022, 02:24:40 AM Thank you albert0bsd
I will try to read and make understand Did BSGS have code in python so I can read the code and run a test it to make understand? Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 15, 2022, 07:23:32 AM I can't believe it, there are 2 billion 700 million points and I watch in amazement that it can't find it. Hey Alberto, I appreciate your work, but we're not going to find the private key this way, man. Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?!Code: root@os:/mnt/keyhunt# ./keyhunt -t 8 -m xpoint -f 200.txt -r 800000000000000000000000000000:80000FFFFFFFFFFFFFFFFFFFFFFFFF -I 0x10000000000000000000000000 -n 0x80000 -R -q Also, how long did it take for the program to load all of those xpoints before it started working? Title: Re: Keyhunt - development requests - bug reports Post by: CoinMagus on May 15, 2022, 08:32:47 AM Wow! Impressive; 2,700,000,001 unique xpoints?!?! How long did that take to create and what is the size of that file? How much RAM does your system have lol?! Also, how long did it take for the program to load all of those xpoints before it started working? I don't remember exactly, but on average: It took 5-6 hours to generate the file with keysubtructer. Code: -rw-r--r-- 1 root root 180900000067 May 12 23:20 200.txt Booting with keyhunt took about 3 hours. Code: /0/4 processor Intel(R) Xeon(R) Platinum 8370C CPU @ 2 Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on May 18, 2022, 03:50:25 PM Try BSGS mode instead of xpoint mode because in xpoint mode the search space is 2^120 not 2^60. Most likely you won't find anything in xpoint mode. I don't quite understand what you are trying to convey. We're already looking for a ^120-bit range, how come in BSGS mode you detect a ^120-bit field as ^60-bits? Also, loading 2 billion 700 million points in BSGS mode will not be efficient. Searching for a point with the -R option will take much longer. Using xpoint mode is the slowest way to find a collision, 2^120/2^31 so of course you're not going to find anything. Use BSGS mode instead 2^60/2^31. You have to search the whole range in xpoint mode vs BSGS mode. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on May 19, 2022, 07:43:37 PM hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong.
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 20, 2022, 01:14:28 AM hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong. Interesting question, but to me, it's not as easy as one or the other. It's not black and white. With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach. Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on May 25, 2022, 05:29:00 PM hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong. Interesting question, but to me, it's not as easy as one or the other. It's not black and white. With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach. And albert0bsd your inputs are needed here. :) Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 26, 2022, 06:44:58 AM hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong. Interesting question, but to me, it's not as easy as one or the other. It's not black and white. With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach. And albert0bsd your inputs are needed here. :) But you can find any and all keys in a 2^255 keyspace. So realistically, 128.5 group ops at DP 0, 2^98.5 group ops at DP 30, 2^88.5 group ops at DP 40...as you can see, it is exponentially faster searching for a pubkey versus possibly searching a 2^160 space for a possible collision. Title: Re: Keyhunt - development requests - bug reports Post by: asicprince on May 31, 2022, 10:31:42 AM sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks
Title: Re: Keyhunt - development requests - bug reports Post by: NotATether on May 31, 2022, 01:06:58 PM sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS. Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support). It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS. Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on May 31, 2022, 01:53:50 PM MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS. Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support). It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS. I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer). The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong. Use Java ;^) Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 31, 2022, 03:53:09 PM MacOS compiles Objective-C code and not C/C++ so you won't even be able to compile the source on MacOS. Brute-forcing software is generally not written for MacOS because (i) Macs are expensive, (ii) Apple makes it really difficult to run MacOS VMs on PCs, and (iii) Ever since NVIDIA drivers stopped being made for Macs, there is a lack of interest for coding this type of software on this platform, as OpenCL is generally less efficient than NVIDIA's CUDA (which only NVIDIA cards support). It's a shame, because it's absolutely good hardware but its wasted on a trash (from a compatibility point of view) OS. I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer). The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong. Use Java ;^) Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on June 01, 2022, 03:01:18 PM sr for noob question, but can somebody guide me how to run this code on MacOS or pls suggest me another powerful code which can use with MacOS. I wanna try my luck with my MBP M1max 64gb RAM. I almost have no experience in programming/code, learnt myself and I can use python code but not C/C++. thanks 1. You can use Parallels Desktop to install linux os.2. Try https://brew.sh/ Title: Re: Keyhunt - development requests - bug reports Post by: NotATether on June 02, 2022, 07:52:06 AM I cannot agree with you (at least partially). OS is not far from a typical linux and very often any technical question could be answered from Linux point of view (Linux related answer). The bigger problem I see (and unfortunately it is his case) is M1 processor. I case of x86 architecture, most of the code could be used without any bigger change, but as they recently made a switch to M1, I suspect he will have problems with running soft which was not written for that. For example any asm methods would be wrong. Use Java ;^) I don't think there are any packages for talking to GPUs [At least there weren't the last time I read the big Java reference book], so it would only be good for multi-threaded CPU stuff. Then again, maybe there is an OpenCL package somewhere for this, but how would such a thing be implemented in a cross-platform way? Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on June 02, 2022, 02:21:14 PM I don't think there are any packages for talking to GPUs [At least there weren't the last time I read the big Java reference book], so it would only be good for multi-threaded CPU stuff. There is jcuda http://javagl.de/jcuda.org/ I have seen some videos and examples, it looks promising, but I did not use it yet, as I decided to go to fully c project. Apple provide Rosetta which could run x86_64 application[1]. Some benchmark on Apple M1 report it has decent performance[2], so why bother re-write Keyhunt code on java? IMO it's more practical to find way to compile Keyhunt on Mac environment instead. It was not my intention, it was just a general remark about the solution which works on any platform. Using pure java it is very difficult to have a performance comparable with a good c program. Let's forget about any ideas for rewriting keyhunt! Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on June 03, 2022, 08:43:00 PM I tested via Windows 10 and all modes work. Code and exe files are on github. Thank you so much Hey WanderingPhilospher , how do You run Your version on win 10? , using standard command promp in Win gives missing libraries errors, complete Linux noob here btw ??? Try this one instead doesn't give errors https://github.com/XopMC/keyhunt-win Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 04, 2022, 06:32:38 PM Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC If you have Linux compile it by yourself and post here the error if it persist. Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on June 06, 2022, 09:32:38 AM Cannot run using -n 0x400000000000 -k 8192 i got 256Gb RAM on one of the servers and it gives an error , im using the compiled server edition from XopMC If you have Linux compile it by yourself and post here the error if it persist. Hey albert0bsd, below is the error, im using the compiled Windows version Code: C:\Users\Administrator\Desktop\keyhunt-win-KeyHunt0.2.211222ServerEdition\keyhunt-win-KeyHunt0.2.211222ServerEdition>keyhunt.exe -m bsgs -f 120.txt -b 120 -R -n 0x400000000000 -k 8192 -q -t 38 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 07, 2022, 04:41:10 AM I don't support to windows version, sorry, please use Linux
Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on June 07, 2022, 06:14:55 AM Hey albert0bsd, below is the error, im using the compiled Windows version Using cygwin? If you do not have access to "pure" linux, I think it is better to try WSL - https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux - for me it works flawlessly. And it is your choice to install debian or ubuntu. which version etc. Title: Re: Keyhunt - development requests - bug reports Post by: psychoid on June 07, 2022, 09:08:50 AM My apologies for such a dumb question, but could someone explain is there a benefit to running "-k" K factor of 4096 vs 2048? because in the end the matrix size is 16x16=256 bits or I'm just too dumb to understand it. and how big is the difference?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 07, 2022, 12:12:46 PM Yes the WSL is the best option to work with keyhunt in windows, that is what I use in my laptop.
My apologies for such a dumb question, but could someone explain is there a benefit to running "-k" K factor of 4096 vs 2048? because in the end the matrix size is 16x16=256 bits or I'm just too dumb to understand it. and how big is the difference? Matrix size??? I think that you are mixing concept from others programs, there are no matrix size on keyhunt. Doubling the size of the K factor also double the speed and the memory usage. Regards Title: Re: Keyhunt - development requests - bug reports Post by: DeepComplex on June 11, 2022, 08:38:25 PM Albert0bsd,
Any updates for keyhunt? Regards, Title: Re: Keyhunt - development requests - bug reports Post by: Spawnx on June 13, 2022, 11:41:43 AM What im doing wrong albert0bsd ?
Code: marcin@S2600GZ:~/Pulpit/keyhunt$ make Im running Code: Linux S2600GZ 5.13.0-48-generic #54~20.04.1-Ubuntu SMP Thu Jun 2 23:37:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Nvm. I had to install build essentials Code: sudo apt install build-essential and make works now Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on June 19, 2022, 05:58:46 PM What does this means, Divide by 0! ?
Title: Re: Keyhunt - development requests - bug reports Post by: JanEmil on June 24, 2022, 05:36:24 PM Looking forward to Windows code.
Title: Re: Keyhunt - development requests - bug reports Post by: nomadsena on June 26, 2022, 03:54:40 AM hi albert0bsd, a small question. when the BSGS is searching for private key from public key, the key range is 2^256 unlike the other bruteforce methods that hash the private key to get ripemd 160 and check balance, in which case the key space is 2^160. if that is true this method is useful to solve only when the key space is know like the puzzle transaction otherwise regular bruteforce methods better because the key range is 2^160. correct me if I am wrong. Interesting question, but to me, it's not as easy as one or the other. It's not black and white. With ripemd160; what 2^160 range would you search? There are (roughly) 2^96, 2^160 ranges. Let's say you search the entire first 2^160 range, 0 to 2^160; you may not find the key you are looking for but instead you may find multiple collisions of the same keys within that range (not the key you are looking for). Now you search the next 2^160 range, 2^160-2^161, the key may not be in there. But if you stopped with the first range, let's say you found it in the first 2^160 range and only searched 50% of the keys before you found it, so you brute forced 2^159 keys to find it. With BSGS your search time would/could be reduced, depending on your hardware setup. I know with Kangaroo, to search for a key in the 2^256 range, you would roughly have to "search" through roughly 2^129 (group operations)....which is 2^30 times smaller than brute force approach. And albert0bsd your inputs are needed here. :) But you can find any and all keys in a 2^255 keyspace. So realistically, 128.5 group ops at DP 0, 2^98.5 group ops at DP 30, 2^88.5 group ops at DP 40...as you can see, it is exponentially faster searching for a pubkey versus possibly searching a 2^160 space for a possible collision. Too technical for me :) I don't fully understand BSGS. simple question how many private keys can a bsgs find for a given publickey if range is not specified. I simply want to know can it find collisions. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 28, 2022, 08:25:52 PM Looking forward to Windows code. For windows you can run it with WSL enable it and install ubuntu available from the windows store. What does this means, Divide by 0! ? Maybe there are some division by 0, can you provide the command line that show you that error? Any updates for keyhunt? Not yet, sorry Regards! Title: Re: Keyhunt - development requests - bug reports Post by: fxsniper on July 31, 2022, 07:34:51 AM Hi, albert0bsd
Can you help to develop tools like this I post on BitCrack thread? https://bitcointalk.org/index.php?topic=4453897.msg60659772#msg60659772 Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on September 10, 2022, 11:33:28 AM Code: No. |=========PRIVATE KEY IN HEX (if it was found and known)========== |===========WALLET ADDRESS===========| ===============UPPER RANGE LIMIT================ | ===================COMPRESSED PUBLIC KEY IN HEX=================== | ==SOLVED DATE== Title: Re: Keyhunt - development requests - bug reports Post by: tandang2 on September 10, 2022, 12:35:19 PM how to install on android with termux, always error' when build, or make install
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 10, 2022, 01:41:02 PM how to install on android with termux, always error' when build, or make install The current version of keyhunt is not compatible with termux. Please use it on computer desktop or laptop Title: Re: Keyhunt - development requests - bug reports Post by: tandang2 on September 15, 2022, 01:05:18 AM how to install on android with termux, always error' when build, or make install The current version of keyhunt is not compatible with termux. Please use it on computer desktop or laptop I use on laptop and my phone, in phone with termux and then install Ubuntu, is work man but i have a question,i found a bitcoin address, and i have public keys compressed, is it possible to hack with public key compressed, but I don't know in what bit this address is? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 15, 2022, 04:47:24 AM but i have a question,i found a bitcoin address, and i have public keys compressed, is it possible to hack with public key compressed, but I don't know in what bit this address is? Even knowing the bit range is not possible do that, proof of it is the puzzle 120. Title: Re: Keyhunt - development requests - bug reports Post by: psychoid on September 15, 2022, 06:45:08 PM Hi Alberto,
Let's say that the average GPU has 8GB of RAM (and some up to 24GB+). Is it possible to make keyhunt compatible with GPU or do you think It's not worth it? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 16, 2022, 03:25:19 AM Is it possible to make keyhunt compatible with GPU or do you think It's not worth it? My keyhunt right now is NOT compatible for GPU. There are some projects with BSGS for GPU you can found those on github. Also you can use Kangaroo it, don't depend of Memory in GPU. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on November 15, 2022, 07:24:01 AM you can use the bPfile.c to generate your .bin file ( this is the baby step table) Code: ./bPfile 1048576000 Pfile.bin This process can take some time, please be patient, maybe some hour depent of your speed. Once that the file is already created, execute: Code: albertobsd $ ./keyhunt -m bsgs -f 120.txt -r 800000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -t 4 -k 250 -R -p ./bPfile.bin -k 250 is new factor of speed, 250 use some more of 17 GB of RAM. But the speed will be huge: Quote Total 155574970875904000 keys in 180 seconds: 864305393755022 keys/s 864 Terakeys/s Best regards! Hello Alberto. I cannot find bPfile, where is this located? I have searched all the subfolders but nothing found. How can we create the .bin files ? And can you explain please how the switch -S works in detail and when we can/should use it or not? Thank you in advance. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 16, 2022, 02:52:57 AM Hello Alberto. I cannot find bPfile, where is this located? I have searched all the subfolders but nothing found. How can we create the .bin files ? And can you explain please how the switch -S works in detail and when we can/should use it or not? Thank you in advance. That Pfile is now obsolete, the new way to speed up the booting process for the mode BSGS is with the option "-S" only available in the las version in github. This -S parameter Store and Read the Bloom Filter File and the Array Table. Those files will be always the same unless you change the parameters in -n and -k Regards! Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on November 16, 2022, 06:19:59 AM Great! thanks for your reply.
Say I have hardware1 and run with -k 1024 and -S Can I copy the created files from -S and move them to hardware2 and run there again with -k 1024 and -S ? Will that work? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 16, 2022, 10:25:22 AM Great! thanks for your reply. Say I have hardware1 and run with -k 1024 and -S Can I copy the created files from -S and move them to hardware2 and run there again with -k 1024 and -S ? Will that work? Yes you can! those files don't change between system. Title: Re: Keyhunt - development requests - bug reports Post by: bigvito19 on November 18, 2022, 09:53:50 PM What's the difference between n and k values?
Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on November 21, 2022, 01:27:41 PM Is it possible to make keyhunt compatible with GPU or do you think It's not worth it? My keyhunt right now is NOT compatible for GPU. There are some projects with BSGS for GPU you can found those on github. Also you can use Kangaroo it, don't depend of Memory in GPU. Regards! Hi Alberto et all. Can you suggest a certain github repository for a working BSGS tool that works with CUDA and provides better performance ? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 21, 2022, 03:17:53 PM I just search for BSGS cuda and some repository appears it is written in PureBasic.
About the performance you need to test it, I don't have GPU to test those programs. But yes, the performance will be 100 times superior to bsgs on CPU. What's the difference between n and k values? N is the size of the giant step K is a multiplier of N So the real Giant Step is N*K To understand BSGS please read: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ Title: Re: Keyhunt - development requests - bug reports Post by: arulbero on November 24, 2022, 07:45:10 PM How do you compute the speed?
If you search a 2^40 interval in 1 s you compute 1 Terakeys/s ? How long it takes to scan a 2^64 interval (with 1 thread)? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 25, 2022, 03:43:20 AM How do you compute the speed? If you search a 2^40 interval in 1 s you compute 1 Terakeys/s ? How long it takes to scan a 2^64 interval (with 1 thread)? According to your premise 2^40 interval (1,099,511,627,776 keys) in 1 Second yes is more of less @ 1 Terakey/s (1,000,000,000,000 ) To compute 2^64 we only need 2^24 times the time of (2^40) this is like 16,777,216 seconds or 4660 hours. But why limit the speed to 1 Terakey per second? The next is keyhunt with 8GB of RAM with a single thread: Code: albertobsd:~/keyhunt$ ./keyhunt -m bsgs -f tests/120.txt -b 120 -q -s 1 -R -S -k 512 -t 1 That is 4.5 Petakeys per second this will solve 64 bits in 4,094 Seconds 2^64 = 18,446,744,073,709,551,616 keys bewteen 4505007002254049 keys/ s = 4064 Seconds, near 68 minutes In my laptop i use to get 20 Petakeys/s with 8 threads and 8 GB of RAM, yes i know it is not lineal but some CPU intructions are shared per Physical core BY THE WAY: I write some post about your speed time ago: https://bitcoin.albertobsd.dev/2021/12/puzzle-70-one-sigle-thread.html In that post I show a test solving the puzzle 70 with a single thread and near 32GB of RAM it took me 9 hrs to solve it Please check it. Thanks! And with some math and probabilistic tricks i manage to solve 75 bits in 8 hrs: https://twitter.com/albertobsd/status/1465540963128987651 But actually the time should be less because in that screenshot half of the time was used to generate the Bloom filter and creat the auxiliar files. Title: Re: Keyhunt - development requests - bug reports Post by: arulbero on November 25, 2022, 08:31:45 AM ..... That is 4.5 Petakeys per second this will solve 64 bits in 4,094 Seconds ... In that post I show a test solving the puzzle 70 with a single thread and near 32GB of RAM it took me 9 hrs to solve it Ok, thanks for the answer. On my current laptop (i7-12700H + 16GB), with my software, I can scan an entire 2^60 range in less than 2 minutes (116 seconds), using 8 GB. To scan the entire 2^60 range, we need to compaire 2^29 baby steps against 2^30 giant steps. I create a table for baby steps: 2^29 elements (64 bits each: 32 bits for the private key + 32 bits for the x-coordinate) -> total 2^35 bit -> 2^32 bytes -> 4 GB; I use 8 GB of Ram for the table (the double) to minimize collisions (half table is empty). Then I compute 2^30 giant steps. My program doesn't write / read on ssd. It takes 120 seconds to compute (2^29 bs + 2^30 gs) , about 30 seconds for the table and 90 seconds to compute 2^30 elements and check in the table. The speed to create the keys is about 2^24 keys/s, the check against the table increase the time by 50%. To work in higher range the program needs to create multiple table; for example, to cover an entire 2^64 range, the program splits the 2^31 baby steps in 4 table of 2^29 elements. Each table is compared against 2^32 giant steps. So it computes: 4 * (2^29 bs + 2^32 gs) = about 16 the time to explore a 2^60 range (2^29 bs + 2^30 gs), then 32 minutes. If I had the double of ram, I would need to compute only 2 * (2^30 bs + 2^32 gs) = about 8 the time to resolve a 2^60 range (2^29 bs + 2^30 gs) : 2minutes * 8 = 16 minutes. In a small range, it seems the my program is faster than yours, on higher range the viceversa. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 25, 2022, 12:52:46 PM In a small range, it seems the my program is faster than yours, on higher range the viceversa. Yes I notice the same, this is really interesting I should check your code to see if i can learn something to boost the current speeds. Good job! Title: Re: Keyhunt - development requests - bug reports Post by: andiu9999 on January 03, 2023, 11:09:09 PM Hi, where i can find the keyhunt cuda exe for test it on windows , i tried but i found only simple keyhunt.exe and i want to try for puzzle #66 , i tried this
Code: keyhunt.exe -m bsgs -f tests/120.txt -b 120 -R -k 256 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on January 04, 2023, 01:45:23 AM BSGS mode is only for publickeys. That is why you get that speed.
For puzzle 66 is not possible yet because we don't have the publickey, with the publickey it will be solved in some 5-8 minutes in CPU. I don't know anything about keyhunt-cuda, i think that program don't have BSGS mode but i don't know becuase i never use it. BTW, NEVER run executables files from untrusted sources. My recomendation is always compile the programs from source code from the Original developer. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: shlomogold on January 10, 2023, 09:52:20 PM To get the best results out of keyhunt, what exactly do you need - powerful CPU, RAM, what else?
What would be the best hardware combination (the one you can buy in store for relatively reasonable amount of money and not some Google supercomputer) to get it to the maximum? Epyc, Threadripper, i9? Anything else? Title: Re: Keyhunt - development requests - bug reports Post by: opeael2 on January 17, 2023, 06:05:59 PM On github I found that '' Almost all bitcoin addresses with a balance are in the 254-256 BITs range. ''
Is This True ? Best range is -b 256 ? Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on January 17, 2023, 06:10:35 PM Yes, the 256-bit range would be best. As long as you could bring some countless light years of patience ;D
Title: Re: Keyhunt - development requests - bug reports Post by: opeael2 on January 17, 2023, 08:40:07 PM Yes, the 256-bit range would be best. As long as you could bring some countless light years of patience ;D i know it take milions years heh but it is good range ? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on January 18, 2023, 04:50:29 PM i know it take milions years heh but it is good range ? Half of the keys are in that range (actually is the half of the whole range) Title: Re: Keyhunt - development requests - bug reports Post by: Lolo54 on January 20, 2023, 06:48:44 AM hello albert did you manage to adapt keyhunt for a GPU version ? which should be faster
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on January 20, 2023, 12:27:52 PM hello albert did you manage to adapt keyhunt for a GPU version ? which should be faster No. However, depending on what you want to use, BSGS, Search for private keys, Kangaroo, etc. there are existing programs that incorporate GPUs. Example, BSGS = BSGS Cuda; Kangaroo = Kangaroo by JLP. For searching for private keys, there are many GPU options.Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on January 20, 2023, 12:29:03 PM There is also KeyHunt-Cuda available, but it's not from Alberto as far as I know
Title: Re: Keyhunt - development requests - bug reports Post by: Lolo54 on January 20, 2023, 06:02:14 PM hello albert did you manage to adapt keyhunt for a GPU version ? which should be faster No. However, depending on what you want to use, BSGS, Search for private keys, Kangaroo, etc. there are existing programs that incorporate GPUs. Example, BSGS = BSGS Cuda; Kangaroo = Kangaroo by JLP. For searching for private keys, there are many GPU options.https://github.com/Etayson/BSGS-cuda but it doesn't offer random and read incoming file in sequential not random. On the other hand, on a single PubKey search, its speed can reach 2 ExaKey/s VS 82 PetaKey/s (KeyHunt) for me for the same search. Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on February 09, 2023, 10:23:11 AM This is probably a stupid question but:
Is it possible to use Baby-step giant-step algorithm to mine Bitcoin? Like is it possible? Since this algorithm runs in peta/keys, we can use this for mining and easily bruteforce 19 bits and get to find a correct hash for the blockheader and get easy 100k euros. If not possbile, why not? Thanks Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on February 09, 2023, 10:33:19 AM This (https://learnmeabitcoin.com/) is a good place to start to satisfy your question(s)
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on February 11, 2023, 02:43:25 PM This is probably a stupid question but: Is it possible to use Baby-step giant-step algorithm to mine Bitcoin? Like is it possible? Since this algorithm runs in peta/keys, we can use this for mining and easily bruteforce 19 bits and get to find a correct hash for the blockheader and get easy 100k euros. If not possbile, why not? Thanks No is not possible, because mining is just bruteforcing the sha256 until get some zeros in the begging of the resulting hash, it can't have any math shortcut. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on February 11, 2023, 03:49:26 PM This is probably a stupid question but: As albert0bsd said, they are not the same.Is it possible to use Baby-step giant-step algorithm to mine Bitcoin? Like is it possible? Since this algorithm runs in peta/keys, we can use this for mining and easily bruteforce 19 bits and get to find a correct hash for the blockheader and get easy 100k euros. If not possbile, why not? Thanks But I wanted to figure out how you figured, "for mining and easily bruteforce 19 bits..."?? 19 Bits? 19 bits would only be 4 leading zeros. The latest block is 00000000000000000006b68d2acbb26adbe3f0ffe653ec08cb3469b3729dda59; that is 19 leading zeros or 76 bits. Big difference. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on February 16, 2023, 04:11:59 AM On github I found that '' Almost all bitcoin addresses with a balance are in the 254-256 BITs range. '' Is This True ? Best range is -b 256 ? It is a probabilistic distribution bit 256 is the Half of the whole key space, bit 255 is a quater and bit 254 is have a 12.5% of the whole range, if you add those values it is 50% + 25% + 12.5% that is 87.5% Title: Re: Keyhunt - development requests - bug reports Post by: digaran on February 16, 2023, 06:03:24 AM On github I found that '' Almost all bitcoin addresses with a balance are in the 254-256 BITs range. '' Is This True ? Best range is -b 256 ? It is a probabilistic distribution bit 256 is the Half of the whole key space, bit 255 is a quater and bit 254 is have a 12.5% of the whole range, if you add those values it is 50% + 25% + 12.5% that is 87.5% Title: Re: Keyhunt - development requests - bug reports Post by: Ovixx on February 16, 2023, 07:55:33 AM On github I found that '' Almost all bitcoin addresses with a balance are in the 254-256 BITs range. '' Is This True ? Best range is -b 256 ? It is a probabilistic distribution bit 256 is the Half of the whole key space, bit 255 is a quater and bit 254 is have a 12.5% of the whole range, if you add those values it is 50% + 25% + 12.5% that is 87.5% Bit Range 254 from : 0x2000000000000000000000000000000000000000000000000000000000000000 to : 0x4000000000000000000000000000000000000000000000000000000000000000 DEC: 14474011154664524427946373126085988481658748083205070504932198000989141204992 -total keys Bit Range 255 from : 0x4000000000000000000000000000000000000000000000000000000000000000 to : 0x8000000000000000000000000000000000000000000000000000000000000000 DEC: 28948022309329048855892746252171976963317496166410141009864396001978282409984 -total keys Bit Range 256 from : 0x8000000000000000000000000000000000000000000000000000000000000000 to : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 DEC: 57896044618658097711785492504343953926634992332820282019728792003956564819968 -total keys #254+#255+@256= 101318078082651670995624611882601919371611236582435493534525386006923988434944 -total keys :o Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on February 20, 2023, 06:15:31 PM Hi everyone.
I just want to say a very thank you to the persons who donate to my address, this last 14/Feb somebody just gave me e about 3000 USD (https://www.blockchain.com/explorer/addresses/btc/1Coffee1jV4gB5gaXfHgSHDz9xx9QSECVW), I really don't expected that this days Because lately I have not been very active, besides that I have been a little unmotivated Anyway, as I wrote in my github page https://github.com/albertobsd/keyhunt#donations Quote All the donations will be use only for two things: Native Windows version with 0 external dependencies. Get an affordable desktop computer with decent GPU, not highend, just to start the GPU version. I will try to cashout those donations to my local currency in the next months, i need to figure it how to do it without lossing anything in taxes or fees. Once that i cash that money i will try to buy a desktop computer to work in some updates that i've thinking, also the start to work in a GPU version. I actually don't know who was that person, to the person who donate that without notifyme if you want please send me a signed message with that addess just send you any update in the code. Again thanks. Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on February 20, 2023, 06:33:16 PM I was not the donator, but I want to express --> you deserve it! ;) keep up the the good work and your YT content
Title: Re: Keyhunt - development requests - bug reports Post by: dextronomous on February 20, 2023, 07:00:48 PM Hi there man, keep it up, good works on you always,
wish it was me who donated. you deserve big time. greets Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on February 26, 2023, 04:30:10 PM Awesome! Thanks for the donator. We wish to get a GPU version of this awesome machine keyhunt with a powerful speed! <3
Goodluck to all! Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on March 03, 2023, 08:18:44 AM I am so happy that you were abe to cash out! I hope you can now buy a GPU ;D ;D
Stay safe Luis! Title: Re: Keyhunt - development requests - bug reports Post by: digaran on March 03, 2023, 06:01:32 PM Regards! I would like to suggest that you should keep your identity hidden from the public, after all you are working on something which has a potential of endangering billions of dollars investments.Title: Re: Keyhunt - development requests - bug reports Post by: NotATether on March 07, 2023, 07:31:02 AM Regards! I would like to suggest that you should keep your identity hidden from the public, after all you are working on something which has a potential of endangering billions of dollars investments.No longer possible after the spat between him and MikeJ_NPC (go to the reputation board for details on that - I won't provide any commentary here). First name should be fine, but I would leave it at that. I don't want anyone to get robbed after all. I would definitely avoid revealing street address or even the name of the city however. It helps a lot. Edit: Alberto I just used your keymath program to implement a multithreaded key division program in C++, thank you very much for the work that made it possible (and to GMP for having a modpow function). Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on March 07, 2023, 10:28:23 AM No longer possible after the spat between him and MikeJ_NPC (go to the reputation board for details on that - I won't provide any commentary here). First name should be fine, but I would leave it at that. I don't want anyone to get robbed after all. I would definitely avoid revealing street address or even the name of the city however. It helps a lot. Albert0bsd doesn't even have huge amount of bitcoin available on his wallet... Why should be he scared? Even for people who threaten him, they are just probably kids behind the screens. There is nothing to be worried of. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 07, 2023, 12:01:02 PM which has a potential of endangering billions of dollars investments. I did my program for puzzles and I recommend to everyone stay in puzzles. I need to add a disclaimer in the github repository I would definitely avoid revealing street address or even the name of the city however. It helps a lot. Yes i know that now, in the bad way... :( There is nothing to be worried of. Thank you, yes there is nothing to be worried because I didn't anything. By my mental health i prefer not talk about that topic anymore. By the way, i just found a way to double the current speed of keyhunt in BSGS mode, it need a lot of changes in the code i will work in that soon. Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on March 07, 2023, 08:12:27 PM Thank you, yes there is nothing to be worried because I didn't anything. Exactly. Wow, that's awesome!! Thank you so much Alberto! You are one of the few geniuses left that are still active programming new things. Can i ask you, how long did it take to you to be this good at C/C++? How did you practice? A little tips would be so good for us, because we also want to be like you ;D Maybe if we manage to make BSGS a little bit more faster, added GPU to it, we could probably hit puzzle #125 with small chances. Who knows. It's luck in the end using Random. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 12, 2023, 03:03:49 PM Can i ask you, how long did it take to you to be this good at C/C++? How did you practice? A little tips would be so good for us I learn to develop C, twenty years ago,. But some of those years I didn't develop or practice anything. I just learn some others computer languages. So I only have some 5-6 years of experience in that language. About tips, learn to do algorithms and flowchars for computer programming. Search for the regional and mundial ICPC problem set and solve it in less than a 24 hrs (Those algorithm problems are made to be solve in 3-4 hrs). I am just an average programmer, well that is what I think, i have some problems finding a good job, maybe I am part of those who knows something well enough to know all things that I don't know, aka dunning kruger effect Title: Re: Keyhunt - development requests - bug reports Post by: NotATether on March 12, 2023, 05:14:00 PM Can i ask you, how long did it take to you to be this good at C/C++? How did you practice? A little tips would be so good for us I learn to develop C, twenty years ago,. But some of those years I didn't develop or practice anything. I just learn some others computer languages. So I only have some 5-6 years of experience in that language. About tips, learn to do algorithms and flowchars for computer programming. Search for the regional and mundial ICPC problem set and solve it in less than a 24 hrs (Those algorithm problems are made to be solve in 3-4 hrs). I am not a genius, I am just an average programmer, well that is what I think, i have some problems finding a good job, maybe I am part of those who knows something well enough to know all things that I don't know, aka dunning kruger effect That amount of experience is enough to make you a professional (for context, I have about half that amount), but it seems that CUDA is becoming something of an Achilles heel for me, not because of the lack of hardware or anything but because the GPU chip is so fundamentally different from the CPU. Title: Re: Keyhunt - development requests - bug reports Post by: digaran on March 14, 2023, 02:05:37 AM OMG, Alberto guess what? I just discovered a new formula to attack 3 targets at the same time, there is a way to break ECC, SHA256- and RIPEMD-160 in one try, here is the procedure:
We perform *RIP-160 on public keys, and save the resulting addresses or just their hashes, and then we go after finding just one of them and when we find that one, we'll have a SHA-256 and a RIP-160 collision, but unfortunately that would break the ECC as well. Though in order to demonstrate how serious this attack could be, for the involved parties in development to see and think about the solution, we need to do this with all our forces combined. So to everyone let's pool our shitty hardware together in order to prove our point, who is with me? Lol. *= we should call it that, "Rest In Peace" soldier from now on because we are here.🤣 Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on March 15, 2023, 09:26:39 AM OMG, Alberto guess what? I just discovered a new formula to attack 3 targets at the same time, there is a way to break ECC, SHA256- and RIPEMD-160 in one try, here is the procedure: We perform *RIP-160 on public keys, and save the resulting addresses or just their hashes, and then we go after finding just one of them and when we find that one, we'll have a SHA-256 and a RIP-160 collision, but unfortunately that would break the ECC as well. Though in order to demonstrate how serious this attack could be, for the involved parties in development to see and think about the solution, we need to do this with all our forces combined. So to everyone let's pool our shitty hardware together in order to prove our point, who is with me? Lol. lol I seriously didn't understand anything. What are you talking about? Please don't join this forum if you're drunk. Also, i think you have a little knowledge about how Bitcoin works Thank you Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 18, 2023, 02:35:38 PM Also, i think you have a little knowledge about how Bitcoin works He knows more or less what he is talking about. I think that method will be some inefficient, if you already have the publickeys i think that is better homologate the search to an only one Kind of search, all by Xpoint or rmd160 or addresses Current search for address is this: Code: Publickeys->address->(search here) What he proposes is something like: Code: Publickeys->(search here)->rmd160->(search here)->address->(search here) But if you already have the publickets of your target then is more easy: Code: Publickeys->(search here by xpoint or BSGS) Transform your publickeys to rmd160 search Code: Publickeys->rmd160->(search here by rmd hash) Title: Re: Keyhunt - development requests - bug reports Post by: digaran on April 17, 2023, 05:17:29 AM Before I lose my mind, can someone please tell me, why is generating public keys and comparing them with target can reach Tk/s, but adding just a sha256 and a rmd160 could reduce the speed to Mk/s? I thought EC calculation was the hardest part of key generation process, is it not?
If I could reach Tk/s speed, it would be a giant leap for my research, is there any windows version? Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on April 17, 2023, 07:53:10 AM Dear albert0bsd, We need as soon as possible a GPU version of Keyhunt :'( puzzle 125 stands at 12.5 bitcoins now! This is a LOT OF money!
With as less as the lowest puzzle,(66), i can finally actually buy home now :D Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 17, 2023, 11:52:06 AM Before I lose my mind, can someone please tell me, why is generating public keys and comparing them with target can reach Tk/s, but adding just a sha256 and a rmd160 could reduce the speed to Mk/s? I thought EC calculation was the hardest part of key generation process, is it not? The difference is that with publickey you can apply Bsgs algorithm (you can do arithmetic operations with the publickey that are directly linked with the privatekey) And the problem with hashes is that you can't do those operations ( well you can add them or Subtract them but the result is not linked to anything not publickey or privatekey). About windows version i recommend to use it on the WSL environment. Title: Re: Keyhunt - development requests - bug reports Post by: digaran on April 19, 2023, 06:35:06 PM Guys how do I store a few GB of public keys/data in compressed format and when I have done it, do I need a tool to be able to read such data?
Because notepad becomes unresponsive when we load it with even less than a GB. I'd appreciate if anyone can help. Regards ~ dig. Title: Re: Keyhunt - development requests - bug reports Post by: lostrelic on April 19, 2023, 06:56:19 PM Guys how do I store a few GB of public keys/data in compressed format and when I have done it, do I need a tool to be able to read such data? Because notepad becomes unresponsive when we load it with even less than a GB. I'd appreciate if anyone can help. Regards ~ dig. Emeditor Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 27, 2023, 05:03:06 AM Can use it for get ecdsa K value to recover Private key ? Why you quoted all my post? Anyway your question is not specific, what are you trying to do? I know what are you talking about but do you know what are you trying to achieve? It is some special case? Title: Re: Keyhunt - development requests - bug reports Post by: hhhhugi on April 27, 2023, 12:06:17 PM Dear albert0bsd,
Which GPU do you recommend on Keyhunt-Cuda? Do you have information about benchmarking result on latest 3090, 4090 or Tesla 32gb cards? I want to open this thread to talk about the tool that i develop Keyhunt (https://github.com/albertobsd/keyhunt) available on github. https://github.com/albertobsd/keyhunt (https://github.com/albertobsd/keyhunt) Telegram group (https://t.me/keyhunters) Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed. To try to find the privatekey from the 120 puzzle you need to add this publickey "uncompress" to a txt file: How to use
120.txt Code: 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 you can run the tool agains that file: Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R output Code: [+] Version 0.1.20210321 K*BSGS Speed: 1 Terakeys/s Well in that example (same in github) we can reach 1Terakeys/s with one thread. Wan to more speed? use the "-k value" param to boots the speed Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R -k 20 Output: Code: [+] Version 0.1.20210321 K*BSGS Speed: ~23 Terekeys/s Tips
Do you still want to more speed? Well Use more RAM, the -k 128 will use some 2.5 GB of RAM This file will take some minutes for the value -k 128, but the speed worth it! Code: ./keyhunt -m bsgs -f 120.txt -b 120 -R -k 128 -p ./bPfile.bin Output: Code: [+] Version 0.1.20210321 K*BSGS Speed: ~146 Terakeys/s one single thread OK at this point maybe you want to use ALL your RAM memory to solve the puzzle 120, just a bigger -k value I already tested it with some 24 GB used with -k 1024 and I get 1.16 Petakeys/s per thread. Using the same configuration with 4 threads I get 4.5 Petakeys/s total Image: https://albertobsd.dev/uploads/1616428067_bd1fc052-9441-4cbb-9bd1-d2e393489e18.jpg FAQ Q: Why the Progress is not displayed? R: The speed depent of the number of target publickeys if you load 1000 publickeys, it will take some more time, the speed is only displayed when at least one thread finish one of his cycles Q: Can we faster this code with Gpu? R: Well yes, but the BSGS algo use RAM, only high end video cards have a lot of RAM, for GPU is better to use Kangaroo Q: How long will take the scan the 120 bit range? R: Human brain usually can't handle big numbers, the 120 bit space have 664613997892457936451903530140172287 (six hundred sixty four decillion...) and we speed is about 1000000000000 (one trillion or one terakey/s) the spected time acording with your speed is: Code: Puzzle 120 @ 1 Terakeys/s : 21074771622667996 years Q: Why should i keep using brute force tools? R: You should not, but people hope in luck. Q: Is avaible for Windows? R: Natively no, but you can install the ubuntu shell for windows and compile it from there Q: It have dependencies? R: Just libgmp for BigIntegers install it with Code: apt-get install libgmp3-dev Q: Why your program use alot of RAM? R: Actuallly i keep in RAM two things (Bloomfilter and a Full bPTable ) im working in one way to remove or reduce the bPTable. Nexts releases
Best regards! Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 27, 2023, 12:44:03 PM Dear albert0bsd, Which GPU do you recommend on Keyhunt-Cuda? Do you have information about benchmarking result on latest 3090, 4090 or Tesla 32gb cards? I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys. Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on April 27, 2023, 01:06:44 PM I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys. interesting. Can you provide some more detailled information and explain how to reproduce this issue ? Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on April 27, 2023, 01:34:57 PM I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys. interesting. Can you provide some more detailled information and explain how to reproduce this issue ? Do tell albert0bsd, thank you! Title: Re: Keyhunt - development requests - bug reports Post by: 7isce on April 28, 2023, 07:25:03 AM Maybe albert0bsd refer to bug of using -m address (single, NOT -m addresses ) which will miss the key.
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 28, 2023, 01:23:30 PM Maybe albert0bsd refer to bug of using -m address (single, NOT -m addresses ) which will miss the key. Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter https://github.com/jvirkki/libbloom/issues/20 But the developer update it some year before that, i solve by my own implementation. I notify to KV but he didn't solve as far i can remember So for small list of address it work fime, but for bigger lists it can fail. I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision. Look the original code in https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57 With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons. the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions. Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on April 28, 2023, 01:28:35 PM as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 28, 2023, 01:30:15 PM as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ? Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on April 28, 2023, 04:26:24 PM as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ? Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there. That’s a large number of addresses! I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 28, 2023, 04:59:52 PM Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above? Yes the bug exists, but the behaivor of it is unexpected if you see this PoC: https://github.com/jvirkki/libbloom/issues/20 Code: Items 4194304 bloom filter bytes 7537997 Why more items in the bloom lead to a lower number of bytes? Look carefully: Items 268435456 bloom filter bytes 482431785 Items 536870912 bloom filter bytes 427992657 Items 1073741824 bloom filter bytes 319114402 Items 2147483648 bloom filter bytes 101357891 That’s a large number of addresses! Yes it is, I've seeing people making such amount of list with keysubtract or similar custom tools I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address. The bug is only present above a 2^30 list and the hebaivor is unexpected it may hit or not but it need to be tested. Title: Re: Keyhunt - development requests - bug reports Post by: kknd on May 01, 2023, 11:12:00 PM 1 Ekeys/s (1021708069969158067 keys/s)
1.021.708.069.969.158.067 keys/s 128gb + 16 AMD Ryzen 7 5800X http://kknd.com.br/etc/keyhunt.png Code: ubuntu@:~/kknd/keyhunt$ ./keyhunt -m bsgs -f 125.pub -b 125 -R -q -S -n 0x400000000000 -k 4096 -t 15 Code: Architecture: x86_64 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 01, 2023, 11:46:21 PM 1 Ekeys/s (1021708069969158067 keys/s) 1.021.708.069.969.158.067 keys/s 128gb + 16 AMD Ryzen 7 5800X :) Nice config, I really wish you good luck, you will need it BTW Guys i already update some features in the main branch of my keyhunt repository, here some of the highlighs:
Things pending TO-DO in keyhunt (in order)
best regards Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on May 02, 2023, 06:58:55 AM
Things pending TO-DO in keyhunt (in order)
best regards Thank you for your efforts and work. Indeed a GPU and a pool update would be a powerful combine update... Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on May 02, 2023, 07:59:26 AM
Alberto, what is your plan, any timeline? Do you need help with that? Let me know, maybe we could work together on your software. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 02, 2023, 11:01:43 PM Alberto, what is your plan, any timeline? Do you need help with that? Let me know, maybe we could work together on your software. Hi PawGo, nice to read you. Actually i haven't a timeline for it, but the plan is that list in that order, at least i hope that. Let me finish with this increment BSGS speed thing and the Legacy version and then i will let you know to work for it Thanks Title: Re: Keyhunt - development requests - bug reports Post by: BS0D on May 04, 2023, 04:28:11 PM Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times.
Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on May 04, 2023, 04:37:04 PM Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter https://github.com/jvirkki/libbloom/issues/20 But the developer update it some year before that, i solve by my own implementation. I notify to KV but he didn't solve as far i can remember What or who do you mean by KV ?So for small list of address it work fime, but for bigger lists it can fail. Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there. Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above? That’s a large number of addresses! I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address. Yes the bug exists, but the behaivor of it is unexpected if you see this PoC: https://github.com/jvirkki/libbloom/issues/20 Code: Items 4194304 bloom filter bytes 7537997 Why more items in the bloom lead to a lower number of bytes? Look carefully: Items 268435456 bloom filter bytes 482431785 Items 536870912 bloom filter bytes 427992657 Items 1073741824 bloom filter bytes 319114402 Items 2147483648 bloom filter bytes 101357891 If understood correctly the mismatch occurs after 536870912 items, so up to 536,870,912 (2^29) there are no issues and errors in KeyHunt-Cuda implementation by Qalander or Manyu, can anyone confirm this? I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision. Look the original code in https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57 With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons. the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions. @albert0bsd if I read between the lines correctly, there seems to be something bothering you about the versions of KeyHunt-Cuda available on github (I'm thinking of the versions of Qalander and/or Manyu). I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. But that's just my guess. At least I read out that you have no interest in a cooperation with them. Nevertheless, thank you very much for your work so far and for sharing your programs with the community. Hats off and keep it up! Out of pure curiosity and personal interest in a working KeyHunt-Cuda version, I'd like to ask you: for what reasons haven't you designed a CUDA-enabled version yet? Working with CPU is completely behind for the purposes after all, GPUs simply have the highest power and performance. Or did you design a KeyHunt-Cuda version in the meantime and I missed it and didn't notice? Am curious and look forward to your answer. I would be very interested in a multi-GPU CUDA capable KeyHunt versio that comes with a fully functional bloom filter and can handle not only p2pkh legacy (compressed and uncompressed) but also p2sh and bech32 addresses. That would be gigantic. But I know, that's not a wishful thinking and surely needs a lot of work. Does anyone know if something like this already exists ? I am looking forward to your feedback. Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 04, 2023, 04:50:00 PM Quote What or who do you mean by KV ? KV was the first to build Keyhunt-cuda.Quote If understood correctly the mismatch occurs after 536870912 items, so up to 536,870,912 (2^29) there are no issues and errors in KeyHunt-Cuda implementation by Qalander or Manyu, can anyone confirm this? My own version, a mod to the original/last KV version, works fine with 2^28 xpoints/addresses; cannot confirm with 2^29 xpoints/addresses.Quote I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. KV, really just borrowed the name, KeyHunt. It does implement a bloom filter, but that is no secret/special code. The rest of the original keyhunt-cuda was heavily based off of JLP's VanitySearch, with the addition of Ethereum addresses.Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on May 04, 2023, 04:51:09 PM What does KV abbreviation mean? Can you point me to his github repository ?
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on May 04, 2023, 04:57:53 PM What does KV abbreviation mean? Can you point me to his github repository ? Was his name I believe; he changed his username.Brilliant programmer as is albert0bsd! I will message you his github. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 04, 2023, 07:01:29 PM Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times. I will check that... thanks to rememberme this instrucctions i need to verify what i can do with them. What does KV abbreviation mean? Can you point me to his github repository ? kanhavishva https://github.com/secp8x32 @albert0bsd if I read between the lines correctly, there seems to be something bothering you about the versions of KeyHunt-Cuda available on github (I'm thinking of the versions of Qalander and/or Manyu). I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. But that's just my guess. At least I read out that you have no interest in a cooperation with them. Nevertheless, thank you very much for your work so far and for sharing your programs with the community. Hats off and keep it up! WHO? i never heard about them and actually i don't care much... Out of pure curiosity and personal interest in a working KeyHunt-Cuda version, I'd like to ask you: for what reasons haven't you designed a CUDA-enabled version yet? Working with CPU is completely behind for the purposes after all, GPUs simply have the highest power and performance. Or did you design a KeyHunt-Cuda version in the meantime and I missed it and didn't notice? Am curious and look forward to your answer. My project start like a proof of concept program for myself, i was learning all the things about the elliptic curve at the same time that i develop it. it start with some small code with Libgmp and then I start to add some extra functions, here and there. The main reason that i haven't designed it for CUDA... or GPU is because I HAVEN'T ONE So, I moved from using libgmp to the same libsecp256k1 code that JLP uses in his BSGS implementation. I only used a part of his code and made some small tweaks to make it work with my initial approach. Right now, I think my BSGS implementation is the fastest one you can get for CPU, and I'm hoping to double its speed again soon. My C code style is somekind old, maybe some other developers also notice it, but is what actually know by self learning it. I just want to say that if everyone only focuses on developing for GPUs just because they're faster, they might miss out on some cool speed hacks and math shortcuts that can be really helpful for people like me who don't have top-of-the-line hardware yet. Title: Re: Keyhunt - development requests - bug reports Post by: digaran on May 05, 2023, 01:30:23 PM @Op, you were going to buy a laptop with a GPU, what happened? Anyways, how come you have no GPU but have CPU? AFAIK, there are no CPU only systems for years, maybe I'm wrong though.
Title: Re: Keyhunt - development requests - bug reports Post by: PawGo on May 05, 2023, 02:41:26 PM I just want to say that if everyone only focuses on developing for GPUs just because they're faster, they might miss out on some cool speed hacks and math shortcuts that can be really helpful for people like me who don't have top-of-the-line hardware yet. I fully support that. I think developers should work on slow computers (at least slower than average user's computer), it would force them to improve their code without relying on the latest/fastest hardware. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 05, 2023, 04:58:55 PM @Op, you were going to buy a laptop with a GPU I am going to buy a desktop computer wiht some GPU (not a fancy one) but a decent GPU. When? I hope this month, I haven't had much time lately as I've been pretty busy. What happened? Oh, you know, life just happened. I've got some other things to do and going on besides this crypto community, so I had to prioritize those for a bit. Anyways, how come you have no GPU but have CPU? The only good computer I have isn't actually mine. I borrowed it from someone else, but unfortunately, it doesn't have a decent GPU. AFAIK, there are no CPU only systems for years, maybe I'm wrong though. well the laptop that i borrowed, comes with some Intel basic GPU if that is what you mean... But common guys, i understand you and got your point, every one want to hit a puzzle with their powerful GPUs that is OK, that is why i going to develop it for GPU and also i want to create the poolclient and server for my program... I am not rich to buy all those fancy hardware, regardless there is some asshole user out there who think that I somehow magically received some coins from him. I fully support that. I think developers should work on slow computers (at least slower than average user's computer), it would force them to improve their code without relying on the latest/fastest hardware. Agree, that is my point. Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on May 05, 2023, 08:51:21 PM Guys leave Alberto alone and let him take and manage his time freely.... Alberto, we won't pressure you, take your time and develop freely whatever & whenever you want.
Title: Re: Keyhunt - development requests - bug reports Post by: psychoid on May 16, 2023, 09:28:36 AM Hi Alberto,
everything worked, but after a reinstall (on Virtual box), it didn't anymore. process hangs on "bP points" step however, it uses 100% CPU and 64gb~ of RAM. Do you know what could be wrong? I use Ubuntu 18.04, here is the output: Code: git clone https://github.com/albertobsd/keyhunt.git Legacy version: Code: [+] Version 0.2.230507 Satoshi Quest (legacy), developed by AlbertoBSD Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 16, 2023, 11:18:41 AM Hi Alberto, everything worked, but after a reinstall (on Virtual box), it didn't anymore. process hangs on "bP points" step however, it uses 100% CPU and 64gb~ of RAM. Do you know what could be wrong? I use Ubuntu 18.04, here is the output: How much RAM do you have? I mean real RAM not virtualized Title: Re: Keyhunt - development requests - bug reports Post by: psychoid on May 16, 2023, 02:12:00 PM Hi Alberto, everything worked, but after a reinstall (on Virtual box), it didn't anymore. process hangs on "bP points" step however, it uses 100% CPU and 64gb~ of RAM. Do you know what could be wrong? I use Ubuntu 18.04, here is the output: How much RAM do you have? I mean real RAM not virtualized 128GB p.s. full restart & reinstall on Ubuntu 20.04. seems like everything is working just fine. Code: ubuntu@keyhunt:~$ git clone https://github.com/albertobsd/keyhunt.git I'm not sure what was wrong with Ubuntu 18.04. My apologies for wasted time Title: Re: Keyhunt - development requests - bug reports Post by: DenisR5 on May 19, 2023, 10:43:36 AM Hello! Launched Keyhunt. Tell me, please, how can I understand that the key is found and where can I view it?
Sincerely! $ ./keyhunt -m bsgs -f tests/125.txt -b 125 -R -k 256 -q -t 8 -s 10 -S
Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on May 19, 2023, 11:36:28 AM Where did you download the tool, RTFM ?
Title: Re: Keyhunt - development requests - bug reports Post by: DenisR5 on May 19, 2023, 01:34:39 PM https://github.com/albertobsd/keyhunt
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 19, 2023, 01:35:26 PM Hello! Launched Keyhunt. Tell me, please, how can I understand that the key is found and where can I view it? Sincerely! Read the FAQ https://github.com/albertobsd/keyhunt#faq Title: Re: Keyhunt - development requests - bug reports Post by: DenisR5 on May 19, 2023, 01:48:16 PM I don't currently have a file called KEYFOUNDKEYFOUND.txt
Will this file be created automatically when the private key is found? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 19, 2023, 01:54:56 PM I don't currently have a file called KEYFOUNDKEYFOUND.txt Will this file be created automatically when the private key is found? Yes it wll be created automatically Title: Re: Keyhunt - development requests - bug reports Post by: DenisR5 on May 19, 2023, 02:09:54 PM Thank you for your help!!!
Title: Re: Keyhunt - development requests - bug reports Post by: DenisR5 on May 19, 2023, 02:48:06 PM Tell me more: after stopping and restarting the program, it starts to sort through the keys again, or how is the previous search result saved?
Title: Re: Keyhunt - development requests - bug reports Post by: kknd on May 19, 2023, 04:38:36 PM g0g0g0
Code: ubuntu@AWS:~/kknd/keyhunt$ ./keyhunt -m bsgs -f 125.pub -b 125 -R -q -S -n 0x400000000000 -k 4096 -t 15 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 19, 2023, 09:30:41 PM Hi guys i just update the double speed version for BSGS: Version 0.2.230519
Also the legacy version was already on github from somo days ago (Now it works again on termux android and maybe another processor) I setup a small dashboard for my self to keep track what features i am working on, you can see that in the link: https://trello.com/b/GXBPiBCM/keyhunt Things pending TO-DO in keyhunt (in order)
Tell me more: after stopping and restarting the program, it starts to sort through the keys again, or how is the previous search result saved? There is no saved mode yet, but in random the probability of scan the te same rage twice is almost the same that find one key. In any case That feature is on my TO-DO list, check the dashboard above, i don't know when i will add it, i hope soon. Title: Re: Keyhunt - development requests - bug reports Post by: venom4464 on May 20, 2023, 12:44:24 AM Hi guys i just update the double speed version for BSGS: Version 0.2.230519 Great, waiting Windows version.Also the legacy version was already on github from somo days ago (Now it works again on termux android and maybe another processor) I setup a small dashboard for my self to keep track what features i am working on, you can see that in the link: https://trello.com/b/GXBPiBCM/keyhunt Things pending TO-DO in keyhunt (in order)
Tell me more: after stopping and restarting the program, it starts to sort through the keys again, or how is the previous search result saved? There is no saved mode yet, but in random the probability of scan the te same rage twice is almost the same that find one key. In any case That feature is on my TO-DO list, check the dashboard above, i don't know when i will add it, i hope soon. Title: Re: Keyhunt - development requests - bug reports Post by: digaran on May 20, 2023, 06:54:45 AM On android? So we can run keyhunt on our phones?
Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on May 20, 2023, 09:03:05 AM I'm looking forward to the GPU feature, which will certainly have the biggest impact on speed and efficiency. Thank you so much for your great work Albert0
Title: Re: Keyhunt - development requests - bug reports Post by: digaran on May 20, 2023, 09:52:58 AM Still no words about the system you were supposed to buy with a few grands you received as a donation a couple of months ago? Maybe you live far far away from civilization, that's why it has taken you so long!
~regards.😉 Title: Re: Keyhunt - development requests - bug reports Post by: PrivatePerson on May 22, 2023, 07:08:51 PM Is it possible to use the same pb table for 50 bit range and for 70 bit range?
Or under each range and a public key the new table is necessary? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 22, 2023, 08:10:00 PM Is it possible to use the same pb table for 50 bit range and for 70 bit range? Or under each range and a public key the new table is necessary? Is the same baby table for all the ranges Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 01, 2023, 04:54:23 AM Still no words about the system you were supposed to buy with a few grands you received as a donation a couple of months ago? Maybe you live far far away from civilization, that's why it has taken you so long! ~regards.😉 I'm going to go for the computer tomorrow, they already assembled it. I hope start the developing for GPU ASAP Guys i release some kind of server for BSGS if some of you want to test it. I did some separate readme for it BSGSD.md (https://github.com/albertobsd/keyhunt/blob/main/BSGSD.md) I hope you like it Title: Re: Keyhunt - development requests - bug reports Post by: kalos15btc on June 04, 2023, 12:56:13 PM Still no words about the system you were supposed to buy with a few grands you received as a donation a couple of months ago? Maybe you live far far away from civilization, that's why it has taken you so long! ~regards.😉 I'm going to go for the computer tomorrow, they already assembled it. I hope start the developing for GPU ASAP Guys i release some kind of server for BSGS if some of you want to test it. I did some separate readme for it BSGSD.md (https://github.com/albertobsd/keyhunt/blob/main/BSGSD.md) I hope you like it thank you for you effort, but i didnt understand hwo the server and client work, im using keyhunt windows, and i want to try the serve, i have a question is , if i scan bsgs with the server it wont scan the same ranges again ? it means always new ranges ? and if there is a tuto on windows how to install and run the server with bsgs thank you ? Title: Re: Keyhunt - development requests - bug reports Post by: tgfx on June 05, 2023, 04:58:43 PM thank you for you effort, but i didnt understand hwo the server and client work, im using keyhunt windows, and i want to try the serve, i have a question is , if i scan bsgs with the server it wont scan the same ranges again ? it means always new ranges ? and if there is a tuto on windows how to install and run the server with bsgs thank you ? In Windows, you can install the Linux environment. Use PowerShell write wsl --install and run.https://learn.microsoft.com/en-us/windows/wsl/basic-commands Title: Re: Keyhunt - development requests - bug reports Post by: tgfx on June 05, 2023, 05:10:26 PM another question haunts me, about the two modes:
- - normal search over the entire 66 range (./keyhunt -m rmd160 -f tests/66.rdb 66 -l compress -R -q) - - or still bsgs by public key (./keyhunt -m bsgs -f tests/125.txt -b 125 -q -s 10 -R) on the one hand, the 66 range is less than (total) 73786976294838206463 and the 125th is already 42535295865117307932921825928971026431 it turns out 66 I can take the number of possible keys and divide by the speed, then I will understand how much I need to search for the key. but on the other hand, the public key search algorithm is not a simple search, how to estimate how many possible steps in bsgs? Title: Re: Keyhunt - development requests - bug reports Post by: JDScreesh on July 09, 2023, 10:38:41 AM Hello there again :)
Congratulations to the solver (or solvers) of the puzzle #125 ;) 12.5 BTC is an excellent prize :) Now, the destination address is the same as the puzzle #120 (https://bitaps.com/3Emiwzxme7Mrj4d89uqohXNncnRM15YESs (https://bitaps.com/3Emiwzxme7Mrj4d89uqohXNncnRM15YESs)) That make me think a lot of thinks :D Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 10, 2023, 11:12:55 AM Hello guys, noob here, sorry:
Why don't we have a 66.pub file? So I can use BSGS? This is my command line, and outputs, does this look good? Is it a good speed? Code: $ ./keyhunt -m address -f tests/66.txt -b 66 -t 128 -S If I stop it does it continue where it left? What is the data_8cf4f3dc.dat file for? Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 10, 2023, 11:17:16 AM another question haunts me, about the two modes: - - normal search over the entire 66 range (./keyhunt -m rmd160 -f tests/66.rdb 66 -l compress -R -q) - - or still bsgs by public key (./keyhunt -m bsgs -f tests/125.txt -b 125 -q -s 10 -R) on the one hand, the 66 range is less than (total) 73786976294838206463 and the 125th is already 42535295865117307932921825928971026431 it turns out 66 I can take the number of possible keys and divide by the speed, then I will understand how much I need to search for the key. but on the other hand, the public key search algorithm is not a simple search, how to estimate how many possible steps in bsgs? Where did you get that 66.rdb? Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on July 10, 2023, 11:22:53 AM You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed
Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 10, 2023, 11:36:57 AM You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed I see, thanks for explaining. What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other? Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit? Title: Re: Keyhunt - development requests - bug reports Post by: digaran on July 10, 2023, 11:59:50 AM You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed I see, thanks for explaining. What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other? Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit? Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 10, 2023, 12:17:23 PM You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed I see, thanks for explaining. What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other? Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit? Where can I find these public key puzzles? Sorry, very new in this. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on July 10, 2023, 01:16:58 PM Where can I find these public key puzzles? Sorry, very new in this. Not all puzzles have it available only those that have some Output transaction. Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 10, 2023, 01:30:43 PM Where can I find these public key puzzles? Sorry, very new in this. Not all puzzles have it available only those that have some Output transaction. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on July 10, 2023, 05:53:11 PM Any output transaction? Aren't the new transaction scripts protocols avoiding exposing public keys at all? I had the idea that only in very old transactions outputs could you find public keys. Yes any output Transaction expose the Publickey (a set of data TX script, R,S and "P" where P is the publickey ), I've not checked new Transaactions but all need to expose publickey, if the publickeys is not there maybe there is enough information to calculate the possible Keys (a set of data TX script, R,S and V, where V is some byte that can calculate the P value, just like the Ethereum network), but that is beyond of this topic. Title: Re: Keyhunt - development requests - bug reports Post by: Ovixx on July 11, 2023, 09:26:41 AM Where can I find these public key puzzles? Sorry, very new in this. #130:::::#160 Code: 03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 Title: Re: Keyhunt - development requests - bug reports Post by: kewa07 on July 13, 2023, 05:44:31 PM Tell me how to use eth mode, when reading addresses from a file, it does not find the necessary addresses when searching, and why is the speed so low?
are there any other programs that work with address databases for ethereum? Thank you. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on July 13, 2023, 08:37:34 PM There is an example of the address format in the documentation, please check it.
About the speed, the hashing process for eth it is more slow than the process for Bitcoin. Also there are some calculations that can't be avoided for eth, and those calcs can be avoided for Bitcoin address then it will be more slow for eth than bitcoin Title: Re: Keyhunt - development requests - bug reports Post by: NonFungibleUser on July 14, 2023, 06:20:44 PM Alberto: https://github.com/albertobsd/keyhunt/issues/241
Also, any hints how I can make this faster? Code: ./keyhunt -m rmd160 -f tests/unsolvedpuzzles.rmd -r 20000000000000000:ffffffffffffffffffffffffffffffffffffffff -l compress -s 5 -S -q -c btc -k 2048 -t 128 -S Title: Re: Keyhunt - development requests - bug reports Post by: nomachine on July 16, 2023, 01:42:38 PM Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times. It is happen to be using a xmrig on the same machine as Keyhunt.Is it possible to boost command from here increase the number of keys per second on AMD EPYC https://raw.githubusercontent.com/xmrig/xmrig/dev/scripts/randomx_boost.sh I have strange results. ;D Title: Re: Keyhunt - development requests - bug reports Post by: kewa07 on July 18, 2023, 01:24:48 PM There is an example of the address format in the documentation, please check it. About the speed, the hashing process for eth it is more slow than the process for Bitcoin. Also there are some calculations that can't be avoided for eth, and those calcs can be avoided for Bitcoin address then it will be more slow for eth than bitcoin Thank you Is it possible to change the search step, for example, not 00001 - 00002 - 00003, but 01000 - 02000 - 03000 ??? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on July 18, 2023, 09:54:36 PM Is it possible to change the search step, for example, not 00001 - 00002 - 00003, but 01000 - 02000 - 03000 ??? Not yet. About the xmrig I never heard about it, I think that it can't be used for this purposes Title: Re: Keyhunt - development requests - bug reports Post by: Redcoinn on July 18, 2023, 10:02:26 PM The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks
Title: Re: Keyhunt - development requests - bug reports Post by: BS0D on July 19, 2023, 12:47:47 PM Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times. It is happen to be using a xmrig on the same machine as Keyhunt.Is it possible to boost command from here increase the number of keys per second on AMD EPYC https://raw.githubusercontent.com/xmrig/xmrig/dev/scripts/randomx_boost.sh I have strange results. ;D Title: Re: Keyhunt - development requests - bug reports Post by: whanau on September 03, 2023, 12:33:28 AM Just been watching the threads go by in random mode.
I notice that the first byte never seems to go below 0x7f. usually OxB -0xF range. is it just me? or perhaps the way the display is set. my command : ./keyhunt -m bsgs -f file.txt -R -k 128 -S -t 30 some samples, I realize it is random but I have been watching for 1/2 hour or so and this is typical.
Thanks for an excellent program Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 03, 2023, 02:18:44 AM Just been watching the threads go by in random mode. I notice that the first byte never seems to go below 0x7f. usually OxB -0xF range. is it just me? or perhaps the way the display is set. Hi thank to point this, it is not exactly an issue, Keyhunt just needs a little guidance from you if you want to target a specific range. Let me explain how you can do this effectively. Keyhunt by default, it searches exclusively on bit 256, to avoid this limitation, you can specify the range you're interested in using the '-r' option. Code: -r 1:fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 In the code above, '-r' allows you to set a range, and the numbers following it define the range. By specifying the range you want to target, you can make Keyhunt work exactly as you need it to. Just a personal question, what are you looking in the 256 bit range? Usually keyhunters only target the lastest avaiable puzzle in this case puzzle 130 with -b 130 you can specify the exact range of that puzzle. Publickey: Code: 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 Code: ./keyhunt -m bsgs -f file.txt -R -k 128 -S -t 8 -M -b 130 If you have any more questions or need further clarification, feel free to ask. Happy hunting! Title: Re: Keyhunt - development requests - bug reports Post by: whanau on September 03, 2023, 07:54:13 PM Hello Alberto thanks for the reply.
>>what are you looking in the 256 bit range? Puzzle 256. I will try -r 256. I use the PC as a heater in my office as a lottery function when it is cold. ;D using -r 256 indeed the range is much more random, 0x10 seen. so my observation would only seem to be with the default range. Thanks for the reply Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on September 04, 2023, 04:49:44 AM puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range.
RipeMD-160 bit ;) Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on September 04, 2023, 09:55:47 AM puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range. Wrong. Puzzles are within 1-256bits, don't forget that he is mentioning the word Lottery, so he should be probably trying to randomly bruteforce some old shit dead 256bit key, probably a key from Satoshis keys with BSGS, and it should obviously be in the 256 bits range, thats why he called it as "puzzle256". Ofc the chances are unbelieveably low, but it still counts as a Lottery as he said. Alberto, What are your thougts? Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on September 04, 2023, 10:39:15 AM puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range. Wrong. Puzzles are within 1-256bits, don't forget that he is mentioning the word Lottery, so he should be probably trying to randomly bruteforce some old shit dead 256bit key, probably a key from Satoshis keys with BSGS, and it should obviously be in the 256 bits range, thats why he called it as "puzzle256". Ofc the chances are unbelieveably low, but it still counts as a Lottery as he said. Alberto, What are your thougts? @GR Sasa: you should go ahead and read the nature of Bitcoin addresses. Bitcoin addresses have the security of 2^160 and that is due to the RIPE-MD 160 hash algorithm being involved. Therefore the creator of the puzzle moved at 11th July 2017 all funds (https://www.blockchain.com/explorer/transactions/btc/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164) from the initially created puzzles 161-256 to the puzzles 1-160. Before transferring those amounts he informed and posted here on bitcointalk forum (https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941). There are no puzzles 161-256 to solve. Your reward is 0.00 Title: Re: Keyhunt - development requests - bug reports Post by: digaran on September 04, 2023, 12:18:17 PM Rmd-160 hash security is 80 bits AFAIK. IDK though, I might be wrong. Isn't keyhunt the same as any other brute force application when it comes to addresses/rmd160 hashes? I just can't understand the speed rates posted on this thread, peta keys/s , exa keys /s? I mean with exa keys/s per 1 PC, one could use 500 PCs with some extra EC math tricks to grind several puzzles in a month. Either nobody is able to properly use these tricks, or those capable are not aware of such tricks.
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on September 04, 2023, 12:31:25 PM Rmd-160 hash security is 80 bits AFAIK. Firstly, yes, there is some truth to the idea that address collisions can happen, but it's not quite as straightforward as it may seem. Let's through the lens of the Birthday Paradox. According to Birthday paradox is possible to find a collision aproximatly near the first squared_root of (2^160), Now, that might sound like a lot, and it is! But here's the twist – this collision could involve any address with or without any cryptocurrency balance. To really make this work, you'd need a substantial log or database of the previous 2^80 addresses. Now, you might be wondering about the likelihood of this collision involving some famous wallet addresses like '1Feex...' or '11111...'. Well, it's incredibly unlikely. Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on September 04, 2023, 02:07:16 PM creator of the puzzle moved at 11th July 2017 all funds[/url] from the initially created puzzles 161-256 to the puzzles 1-160. Before transferring those amounts he informed and posted here on bitcointalk forum (https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941). That is correct, that he moved the funds from 161-256 to 1-160, but I'm sorry to disappoint you, but you are still wrong. The guy meant that he is solving a key from 256 bits, meaning its the old dead key.. Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on September 04, 2023, 04:28:37 PM :D :D :D
Title: Re: Keyhunt - development requests - bug reports Post by: MrlostinBTC on November 03, 2023, 10:29:23 PM BSGS Dual CPU support? Running 2x intel gold 6148 40 threads each 256gig ram.
At 40 threads I get 15 Exa keys/s At 80 threads I get 6-12 Exa keys/s All threads are fully loaded when 80 is requested. Bottle neck somewhere? I am still fine with 40, but 80 would be nice. Thank you for all the great work Alberto! Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 03, 2023, 10:37:36 PM Maybe it is something related to the Operating system thread administration. Can you try some 78 or 79 threads instead?
Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases. Title: Re: Keyhunt - development requests - bug reports Post by: MrlostinBTC on November 03, 2023, 10:43:36 PM Maybe it is something related to the Operating system thread administration. Can you try some 78 or 79 threads instead? Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases. Ubuntu 23.04 I have tried 78, 50, 55 all the same results. Anything over 40 decreases the speed by half with twice the threads. Maybe a Kernel issue? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on November 03, 2023, 11:24:48 PM Uhmm, I think that 40 is the limit :'(
https://talkimg.com/images/2023/11/03/tQ7nP.jpeg If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html It is 20 cores so it it's only 40 threads max. I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that. Title: Re: Keyhunt - development requests - bug reports Post by: MrlostinBTC on November 03, 2023, 11:37:30 PM Uhmm, I think that 40 is the limit :'( https://talkimg.com/images/2023/11/03/tQ7nP.jpeg If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html It is 20 cores so it it's only 40 threads max. I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that. 2 cpus at 40 threads, 80 total. CPU info shows 80 possible. Ubuntu shows 80 threads. But you may be correct. Strange as bios reports 40 however its not clear if its reporting for 1 cpu or 2. Again thank you for all the hard work! Title: Re: Keyhunt - development requests - bug reports Post by: MrlostinBTC on November 05, 2023, 01:22:44 PM I figured it out. But not sure what was going on. I reinstalled ubuntu from usb, started fresh. Bsgs is now holding 18 exa keys/s stable. All 80 cpu threads loaded around 50-60 percent. Appears my ram can now not keep up. But the speed drop out is gone.
Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on November 07, 2023, 09:39:24 AM Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s Title: Re: Keyhunt - development requests - bug reports Post by: 1qaz on November 07, 2023, 10:16:40 PM Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s 18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach P.s. https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png (https://ibb.co/pfR0VDp) Title: Re: Keyhunt - development requests - bug reports Post by: MrlostinBTC on November 17, 2023, 12:10:53 AM Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s Just uped my ram to 512 gig 51 Exa keys/s My rig will hold up to 2 terrabtes of ram. Just $$$ Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s 18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach P.s. https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png (https://ibb.co/pfR0VDp) Still a chance, and this is what this puzzle is about. Are you suggesting I stop searching? Btw I will also be donating to Alberto if I find any. Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on November 17, 2023, 04:19:39 PM Well if your setup uses a lot of electricity or if it's overheating, then it's best to stop searching.
Title: Re: Keyhunt - development requests - bug reports Post by: ttdclient on December 12, 2023, 08:33:11 PM Hello I run the ttdsales 66 bit pool and am trying out your software for the purpose of consideration of making a 130 bit pool.
compiling was a breeze I like the options you have built in. I am mostly just interested in the BSGS mode and particularly interested in setups with massive amounts of ram. My test rig is a dual cpu 2697 v2 with 512GB ram for a total of 24 cores and 48 logical processors. keyhunt -m bsgs -f tests/130.txt -b 130 -R -k 8192 -q -t 40 -s 10 -S Code: [+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD I can not for the life of me get it to use more ram. Increasing k value or n value is causing error bloom_init keyhunt -m bsgs -f tests/130.txt -b 130 -R -k 16384 -q -t 40 -s 10 -S
keyhunt -m bsgs -f tests/130.txt -b 130 -R -k 8192 -q -t 40 -s 10 -S -n 0x200000000000 [E] M value is not divisible by 1024 not sure why that error is happening keyhunt -m bsgs -f tests/130.txt -b 130 -R -k 8192 -q -t 40 -s 10 -S -n 0x400000000000
same as before. pretty sure if I can make it take advantage of 4 times the ram I can get 4 times the speed. Anyway I appreciate the help and understanding you can provide. Chris Title: Re: Keyhunt - development requests - bug reports Post by: cryptocool on December 21, 2023, 06:50:29 PM Quote Hi 1qaz, It seems the memory is 1 TB. Can I please know what CPUs are being used in the screen shot ? Thanks! Title: Re: Keyhunt - development requests - bug reports Post by: ljf2238 on December 26, 2023, 04:44:36 AM hi albert0bsd,
I found keyhunt wont stop even out of range , I test ./keyhunt -m address -f tests/1to32.txt -r 1:FFFF it seems the hunter wont stop and keep running .... Hit! Private Key: 1ba534 pubkey: 031a746c78f72754e0be046186df8a20cdce5c79b2eda76013c647af08d306e49e Address 14oFNXucftsHiUMY8uctg6N487riuyXs4h rmd160 29a78213caa9eea824acf08022ab9dfc83414f56 Hit! Private Key: 2de40f pubkey: 023ed96b524db5ff4fe007ce730366052b7c511dc566227d929070b9ce917abb43 Address 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv rmd160 7ff45303774ef7a52fffd8011981034b258cb86b Hit! Private Key: 556e52 pubkey: 03f82710361b8b81bdedb16994f30c80db522450a93e8e87eeb07f7903cf28d04b Address 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac rmd160 d0a79df189fe1ad5c306cc70497b358415da579e ^C if its possible split puzzle job in many pieces just like miner workers in mining pool? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on December 26, 2023, 05:03:42 AM hi albert0bsd, I found keyhunt wont stop even out of range , I test ./keyhunt -m address -f tests/1to32.txt -r 1:FFFF it seems the hunter wont stop and keep running .... Default subrange per thread is 0x100000000 if you want it to to stop in the given range reduce the subrange N value per thread. Add -n 0x400 1024 is the minimum value so please increment your range -n to a minimum of 24 bits this is 0x1000000 or -r 1:1000000 -n 0x400 Title: Re: Keyhunt - development requests - bug reports Post by: GTX1060x2 on January 11, 2024, 08:05:10 AM Hello Alberto!
Do you have plans to add a BrainWallet search mode by dictionary or mask? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on January 11, 2024, 04:04:13 PM Do you have plans to add a BrainWallet search mode by dictionary or mask? No, sorry that is outside of the scope of this tool, the only thing that is near of that is the minikey option. But I have no plans to add any of that, it include no dictionary search, no hexadecimal key check, no brain wallet. If you want to do brain wallet search use brainflayer that tools is good and its already developed. Title: Re: Keyhunt - development requests - bug reports Post by: Banyduge on January 15, 2024, 09:46:31 AM The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks
Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on January 15, 2024, 09:52:49 AM The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks Your contribution makes no sense, there is neither any information or added value nor any question. Are you a person who mainly posts anything (for whatever reason) or one of the countless bots that are up to mischief? You registered today (https://bitcointalk.org/index.php?action=profile;u=3603415) and spreading (https://bitcointalk.org/index.php?action=profile;u=3603415;sa=showPosts) around, a rogue who thinks evil. Summarize your questions or statements so that they make sense or save yourself the post. Thank you Title: Re: Keyhunt - development requests - bug reports Post by: coinchaser1 on January 15, 2024, 12:00:31 PM Do you have plans to add a BrainWallet search mode by dictionary or mask? No, sorry that is outside of the scope of this tool, the only thing that is near of that is the minikey option. But I have no plans to add any of that, it include no dictionary search, no hexadecimal key check, no brain wallet. If you want to do brain wallet search use brainflayer that tools is good and its already developed. Hi Alberto, I'd like to be able to specify a range for the ripemd160 scan, with the ability to scan either forwards or backwards in that range. Is this possible at the moment? thanks cc Title: Re: Keyhunt - development requests - bug reports Post by: GR Sasa on January 16, 2024, 10:52:03 AM The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks Your contribution makes no sense, there is neither any information or added value nor any question. Are you a person who mainly posts anything (for whatever reason) or one of the countless bots that are up to mischief? You registered today (https://bitcointalk.org/index.php?action=profile;u=3603415) and spreading (https://bitcointalk.org/index.php?action=profile;u=3603415;sa=showPosts) around, a rogue who thinks evil. Summarize your questions or statements so that they make sense or save yourself the post. Thank you That's probably Digaran, lmao Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on January 16, 2024, 11:52:12 AM The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks Your contribution makes no sense, there is neither any information or added value nor any question. Are you a person who mainly posts anything (for whatever reason) or one of the countless bots that are up to mischief? You registered today (https://bitcointalk.org/index.php?action=profile;u=3603415) and spreading (https://bitcointalk.org/index.php?action=profile;u=3603415;sa=showPosts) around, a rogue who thinks evil. Summarize your questions or statements so that they make sense or save yourself the post. Thank you That's probably Digaran, lmao No, not this time. The user is not connected to it, at least not according to the database records and metadata available and its artificial intelligent analysis. 8) but still far too much garbage posted in the forum. Title: Re: Keyhunt - development requests - bug reports Post by: De_Freedom on January 17, 2024, 11:37:22 AM Hello, I tried to calculate (using AI help) and I get that at 48 exa keys per second the range will be completed shortly. Where is the mistake?
(2^130 - 1) - 2^129 2^130 is 340282366920938463463374607431768211456 Subtracting 1 gives us: 340282366920938463463374607431768211455 2^129 is 170141183460469231731687303715884105728 Subtracting the start from the end: 340282366920938463463374607431768211455 - 170141183460469231731687303715884105728 = 170,141,183,460,469,231,731,687,303,715,884,105,727 Total keys / Keys scanned per second 170,141,183,460,469,231,731,687,303,715,884,105,727 / 48,000,000,000,000,000,000 = 3,542 seconds Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s 18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach P.s. https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png (https://ibb.co/pfR0VDp) Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on January 17, 2024, 01:50:39 PM Hello, I tried to calculate (using AI help) and I get that at 48 exa keys per second the range will be completed shortly. Where is the mistake? (2^130 - 1) - 2^129 2^130 is 340282366920938463463374607431768211456 Subtracting 1 gives us: 340282366920938463463374607431768211455 2^129 is 170141183460469231731687303715884105728 Subtracting the start from the end: 340282366920938463463374607431768211455 - 170141183460469231731687303715884105728 = 170,141,183,460,469,231,731,687,303,715,884,105,727 Total keys / Keys scanned per second 170,141,183,460,469,231,731,687,303,715,884,105,727 / 48,000,000,000,000,000,000 = 3,542 seconds Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s 18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach P.s. https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png (https://ibb.co/pfR0VDp) Your calculator is broke lol. (2^129/48000000000000000000) / 86400 (seconds in one day) = 164,102,221,701,841 days to scan entire range. Also, 2^129 = 680564733841876926926749214863536422912, not 170141183460469231731687303715884105727 as you stated. But even with your numbers: (170141183460469231731687303715884105728/48000000000000000000) / 86400 = 41,025,555,425,460 days. Title: Re: Keyhunt - development requests - bug reports Post by: De_Freedom on January 17, 2024, 02:02:31 PM Thanks WanderingPhilospher. But oh my god, we stand no chance to crack 130 puzzle any time soon.
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on January 23, 2024, 05:39:11 AM What's the largest baby step file someone has created for BSGS?
More than 1 Billion, anyone? Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on January 23, 2024, 05:00:13 PM Sorry, why try to solve puzzle 130 and not 66? ???
Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on January 23, 2024, 08:51:43 PM Sorry, why try to solve puzzle 130 and not 66? ??? Double the reward with the same number of operations; depending on which program you use.Also, you can't use BSGS for #66. Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on January 27, 2024, 08:09:31 AM Has anyone looked for a mathematical solution?
This seems to respond to a form of polynomial function of degree n, where n is the position of the term in the sequence, such that the same sequence of the addresses found is obtained: 1,3,7,8,15,31,4C,E0... Title: Re: Keyhunt - development requests - bug reports Post by: andiu9999 on January 28, 2024, 11:57:27 PM hi i need a bit help if i run this
Code: ./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024ce5d77df7fff -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e the program still search after 40 trillions, if the range is smaller it stop when range ends Code: ./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024a9fc3e750000 -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e what i should do ? to modify the n ? Title: Re: Keyhunt - development requests - bug reports Post by: WanderingPhilospher on January 29, 2024, 01:12:12 PM hi i need a bit help if i run this Code: ./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024ce5d77df7fff -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e the program still search after 40 trillions, if the range is smaller it stop when range ends Code: ./keyhunt -m vanity -f tests/66.txt -r 34024a9fc3e150000:34024a9fc3e750000 -l compress -q -s 10 -v 13zb1hQbWVs -t 8 -n 0x400 -e what i should do ? to modify the n ? You should use VanitySearch to find it, however, finding matching 10 characters will take awhile. Especially if only using CPU. Also, there is no guarantee that the prefix you are looking for is even in those ranges. Title: Re: Keyhunt - development requests - bug reports Post by: paschok81 on February 24, 2024, 03:45:54 PM Bsgs is now holding 18 exa keys/s stable. Running a program to searches 18 exa keys/s is impressive! I have 16 GB and Core i7, and get only 70 Peta key/s 18 ExKeys/s this is a drop in the ocean, the range is huge, brute force is currently not the best choice for solving the puzzle. Even if random is not a very good idea, you need to look for another approach P.s. https://i.ibb.co/pfR0VDp/2023-11-08-00-14-18.png (https://ibb.co/pfR0VDp) Please tell me what CPU you have? Title: Re: Keyhunt - development requests - bug reports Post by: adaris on February 28, 2024, 02:58:00 PM Is it possible to adapt an ASIC miner to this program as a coprocessor because it has higher speed?
Or perhaps use MicroRNG is a hardware (true) random number generator? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on February 29, 2024, 03:54:26 AM Is it possible to adapt an ASIC miner to this program as a coprocessor because it has higher speed? No, its no possible to use them. Or perhaps use MicroRNG is a hardware (true) random number generator? In linux it use urandom to get random numbers, i did some test before and the performance is almost the same, there is not much advantage to use the CPU RNG to do that, even the libssl RNG is faster than it. If the OS have enough entropy even 256 bits of good entropy is enough to generate Random numbers for an eternity see : https://www.2uo.de/myths-about-urandom/ Title: Re: Keyhunt - development requests - bug reports Post by: De_Freedom on March 01, 2024, 12:25:36 PM I have tried Vanity search with range specified and it has found address that is out of range:
Code: ./keyhunt -m vanity -f tests/van.txt -l compress -R -b 66 -e -s 10 -q -t 32 -n 0x400000000000 Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 01, 2024, 12:30:19 PM I have tried Vanity search with range specified and it has found address that is out of range: Code: ./keyhunt -m vanity -f tests/van.txt -l compress -R -b 66 -e -s 10 -q -t 32 -n 0x400000000000 Remove -e, by the way don't use vanity for puzzle search Title: Re: Keyhunt - development requests - bug reports Post by: De_Freedom on March 01, 2024, 01:03:33 PM Thanks, regarding vanity, speed is slightly better for me than address mode.
Title: Re: Keyhunt - development requests - bug reports Post by: whanau on March 04, 2024, 01:45:23 AM Bug?
Hi Alberto, I am using Version 0.2.230519 on Ubuntu. In xpoint mode, with an uncompressed public key, the program does not find the private key the public key file is one long string, no breaks 04bdba1effbf6af786dca1da26cc2261021f95d56f245298c0b87a40e1fa9a0cbc05e798c4be089 a47da2ec0d2869c0e394ccf75eb4fcc01321e2f2a67a7cbbb7d (key10) Result ./keyhunt -m xpoint -f testkey.txt -n 65536 -t 4
What am I doing wrong? Thank you Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 04, 2024, 02:06:59 PM Bug? Where in the command do you set the range? ::) ::) ::) :P Title: Re: Keyhunt - development requests - bug reports Post by: GTX1060x2 on March 04, 2024, 03:31:06 PM Code: ./keyhunt -m vanity -l compress -r 30000000000000000:3ffffffffffffffff -R -v 13zb1hQ -n 0x6000000 -q -s 10 -t4 Title: Re: Keyhunt - development requests - bug reports Post by: whanau on March 04, 2024, 05:27:40 PM Bug? Where in the command do you set the range? ::) ::) ::) :P In the post: Range -- from : 0x1 -- to : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 also I tried ./keyhunt -m xpoint -f testkey.txt -r 1:100
Thank you for your help Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 04, 2024, 06:00:44 PM In the post: Range -- from : 0x1 -- to : 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 And what you expected? found the key in seconds? Genius...... That is the whole range if there is a program to found a key in seconds the bitcoin and all alt-coins will worth ZERO Please don't ask stupid questions here Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 04, 2024, 07:26:37 PM Code: ./keyhunt -m vanity -l compress -r 30000000000000000:3ffffffffffffffff -R -v 13zb1hQ -n 0x6000000 -q -s 10 -t4 The first number in the range is greater than the second, it seems that this caused abnormal operation. Strange ??? Title: Re: Keyhunt - development requests - bug reports Post by: Ra al Ghul on March 05, 2024, 01:58:08 AM Alberto is a Legend would love to meet him one day :)
Title: Re: Keyhunt - development requests - bug reports Post by: satashi_nokamato on March 05, 2024, 07:59:28 AM Code: ./keyhunt -m vanity -l compress -r 30000000000000000:3ffffffffffffffff -R -v 13zb1hQ -n 0x6000000 -q -s 10 -t4 The first number in the range is greater than the second, it seems that this caused abnormal operation. Strange ??? Code: 0x000000000000000000000000000000000000000000000003b4ad4aeb57a1d1cc Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 05, 2024, 04:05:40 PM
Seconds yes that key is outside of the range because keythunt for address/rmd160/xpoint search on both sides of the curve it do this because if I only seach for one side of the curve the performance would be lesst than the half of it ( It will have less than the half of the current speed ). It think on this like a feature not a bug... so please use more than 15 characers for your vanity search.
Seconds yes that key is outside of the range because keythunt for address/rmd160/xpoint search on both sides of the curve it do this because if I only seach for one side of the curve the performance would be lesst than the half of it ( It will have less than the half of the current speed ). It think on this like a feature not a bug... so please use more than 15 characers for your vanity search. Alberto is a Legend would love to meet him one day :) Its not a big deal, I am just another random guy with regular life problems Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 01:18:08 PM Ok, I installed Keyhunt on Bodhi Linux 7.0 copied file 130.txt from folder test to folder keyhunt and executed ./keyhunt -m bsgs -f 130.txt -b 130 -R
When it finds the key, will it create a file with the found key in the keyhunt folder ? Like the file VANITYKEYFOUND.txt in the keyhunt folder ? Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 05:56:07 PM Ok, I installed Keyhunt on Bodhi Linux 7.0 copied file 130.txt from folder test to folder keyhunt and executed ./keyhunt -m bsgs -f 130.txt -b 130 -R When it finds the key, will it create a file with the found key in the keyhunt folder ? Like the file VANITYKEYFOUND.txt in the keyhunt folder ? ./keyhunt -m bsgs -f 130.txt -b 130 -R You're going to need luck ::) The VANITYKEYFOUND.txt file is generated only when the hunter finds a key in vanity mode. Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 07:36:59 PM Ok, I installed Keyhunt on Bodhi Linux 7.0 copied file 130.txt from folder test to folder keyhunt and executed ./keyhunt -m bsgs -f 130.txt -b 130 -R When it finds the key, will it create a file with the found key in the keyhunt folder ? Like the file VANITYKEYFOUND.txt in the keyhunt folder ? ./keyhunt -m bsgs -f 130.txt -b 130 -R You're going to need luck ::) The VANITYKEYFOUND.txt file is generated only when the hunter finds a key in vanity mode. Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on March 08, 2024, 07:54:08 PM RTFM ?
do a test with lower key and see what happens? Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 08:25:16 PM Ok, I installed Keyhunt on Bodhi Linux 7.0 copied file 130.txt from folder test to folder keyhunt and executed ./keyhunt -m bsgs -f 130.txt -b 130 -R When it finds the key, will it create a file with the found key in the keyhunt folder ? Like the file VANITYKEYFOUND.txt in the keyhunt folder ? ./keyhunt -m bsgs -f 130.txt -b 130 -R You're going to need luck ::) The VANITYKEYFOUND.txt file is generated only when the hunter finds a key in vanity mode. ./keyhunt -m vanity -r AB958105:C52F1A9F -R -v 1FRoHA9xew -l compress -t 4 -e -n 0x400 Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 08:50:49 PM Ok, I installed Keyhunt on Bodhi Linux 7.0 copied file 130.txt from folder test to folder keyhunt and executed ./keyhunt -m bsgs -f 130.txt -b 130 -R When it finds the key, will it create a file with the found key in the keyhunt folder ? Like the file VANITYKEYFOUND.txt in the keyhunt folder ? ./keyhunt -m bsgs -f 130.txt -b 130 -R You're going to need luck ::) The VANITYKEYFOUND.txt file is generated only when the hunter finds a key in vanity mode. ./keyhunt -m vanity -r AB958105:C52F1A9F -R -v 1FRoHA9xew -l compress -t 4 -e -n 0x400 BTW: your vanity code found 32. I can see it in the file VANITYKEYFOUND.txt :) RTFM ? Found it !do a test with lower key and see what happens? "FAQ Where the privatekeys will be saved? R: In a file called KEYFOUNDKEYFOUND.txt" Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 09:15:26 PM RTFM ? Found it !do a test with lower key and see what happens? "FAQ Where the privatekeys will be saved? R: In a file called KEYFOUNDKEYFOUND.txt" Exact. KEYFOUNDKEYFOUND.tx what did you find? the puzzle 130? ;D Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 09:19:56 PM RTFM ? Found it !do a test with lower key and see what happens? "FAQ Where the privatekeys will be saved? R: In a file called KEYFOUNDKEYFOUND.txt" Exact. KEYFOUNDKEYFOUND.tx what did you find? the puzzle 130? ;D Give me a code to do a test with lower key. Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 09:35:05 PM RTFM ? Found it !do a test with lower key and see what happens? "FAQ Where the privatekeys will be saved? R: In a file called KEYFOUNDKEYFOUND.txt" Exact. KEYFOUNDKEYFOUND.tx what did you find? the puzzle 130? ;D Give me a code to do a test with lower key. There is no such thing as that, if you want to narrow the range you should look at (2^130)-(2^129) or 680564733841876926926749214863536422913, the lucky number can be randomly anywhere in that range. The problem is that 0.0000000001% of the range is 68056473384187692692674921486. There are still more grains of sand there than there are on all the beaches in the world combined. :'( Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 10:17:42 PM Ok, I made a 65.txt file in folder keyhunt and used this code
./keyhunt -m bsgs -f 65.txt -r 1a830000000000000 It found the puzzel 65 privatkey right away. I can see it in the file KEYFOUNDKEYFOUND.txt :) Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 10:49:35 PM Ok, I made a 65.txt file in folder keyhunt and used this code ./keyhunt -m bsgs -f 65.txt -r 1a830000000000000 It found the puzzel 65 privatkey right away. I can see it in the file KEYFOUNDKEYFOUND.txt :) brilliant! Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 08, 2024, 11:03:13 PM Ok, I made a 65.txt file in folder keyhunt and used this code ./keyhunt -m bsgs -f 65.txt -r 1a830000000000000 It found the puzzel 65 privatkey right away. I can see it in the file KEYFOUNDKEYFOUND.txt :) brilliant! ./keyhunt -m vanity -r AB958105:C52F1A9F -R -v 1FRoHA9xew -l compress -t 4 -e -n 0x400 Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 08, 2024, 11:25:35 PM Ok, I made a 65.txt file in folder keyhunt and used this code ./keyhunt -m bsgs -f 65.txt -r 1a830000000000000 It found the puzzel 65 privatkey right away. I can see it in the file KEYFOUNDKEYFOUND.txt :) brilliant! ./keyhunt -m vanity -r AB958105:C52F1A9F -R -v 1FRoHA9xew -l compress -t 4 -e -n 0x400 It is intended for custom addresses like 1Magni1 but the rest of the public address is not known Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on March 09, 2024, 04:26:28 PM What do you expect, you run a program find a key and getting a millionair ? RTFM! No pain no gain. This is nothing for "From Zero To Hero" fanboys. Do your maths. RTFM.
Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 09, 2024, 09:36:40 PM What do you expect, you run a program find a key and getting a millionair ? RTFM! No pain no gain. This is nothing for "From Zero To Hero" fanboys. Do your maths. RTFM. Take it easy. I am a Newbie getting to know Keyhunt. I am at 5 Petakeys/s right now. So what if I get the millions? what's it to you?Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 10, 2024, 12:42:44 AM What do you expect, you run a program find a key and getting a millionair ? RTFM! No pain no gain. This is nothing for "From Zero To Hero" fanboys. Do your maths. RTFM. Take it easy. I am a Newbie getting to know Keyhunt. I am at 5 Petakeys/s right now. So what if I get the millions? what's it to you?What are you hunting puzzle 130 or 66? What range are you scanning? Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 10, 2024, 01:22:04 AM 5 Petakeys wow! I am trying out 7 Petakeys/s now and think I need some more RAM :)What are you hunting puzzle 130 or 66? What range are you scanning? For now puzzle 130. I have BitCrack running for puzzle 66 on a another computer. I am trying out different ranges, it's not easy to decide what range. I have to read some more about what ranges are more probable than others ? do you have any suggestions what or where to read ? links ? Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 10, 2024, 01:36:56 AM 5 Petakeys wow! I am trying out 7 Petakeys/s now and think I need some more RAM :)What are you hunting puzzle 130 or 66? What range are you scanning? For now puzzle 130. I have BitCrack running for puzzle 66 on a another computer. I am trying out different ranges, it's not easy to decide what range. I have to read some more about what ranges are more probable than others ? do you have any suggestions what or where to read ? links ? 5 Petakeys wow! I am trying out 7 Petakeys/s now and think I need some more RAM :)What are you hunting puzzle 130 or 66? What range are you scanning? For now puzzle 130. I have BitCrack running for puzzle 66 on a another computer. I am trying out different ranges, it's not easy to decide what range. I have to read some more about what ranges are more probable than others ? do you have any suggestions what or where to read ? links ? I dare to predict that puzzle 66 is at ~72% of its range. ;D Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 10, 2024, 03:08:07 PM Personally I believe that whoever made the puzzles did not use a random method, I think the location of the known puzzles in relation to their rank demonstrates this. A while ago I did a linear regression study and I was surprised by the result. I expected the average difference between the predicted and actual location to be approximately 50%, which is what is expected for a linear regression prediction on random data, however the average is 27.81% I dare to predict that puzzle 66 is at ~72% of its range. ;D 💩💩💩 Bullshit! The author already said that it was the result of a random keys padding with bits to match the expected range. Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on March 10, 2024, 06:10:01 PM hi ALBERTO;
For N value in Keyhunt Program Example: Nx100000000 = 4294967296 keys Does it mean that it scans every 4294967296 key sequentially? Is it true ? It selects a random key and scans 4294967296 wallets sequentially, and then it selects a random key again and scans 4294967296 wallets sequentially. Did I understand correctly? Does it work like this? Keyhunt N value? Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on March 10, 2024, 07:52:56 PM I dare to predict that puzzle 66 is at ~72% of its range. ;D Ok I'll try that. I to think it's somewhere around there ;)I now got 67 Pkeys/s hunting Puzzle 130 and 40 Mkeys/s on Puzzle 66 I need a new computer to get 1 or 2 Ekeys/s like this guy, https://bitcointalk.org/index.php?topic=5322040.msg62268526#msg62268526 Title: Re: Keyhunt - development requests - bug reports Post by: ccinet on March 10, 2024, 09:30:56 PM I dare to predict that puzzle 66 is at ~72% of its range. ;D I now got 67 Pkeys/s hunting Puzzle 130 and 40 Mkeys/s on Puzzle 66Ok I'll try that. I to think it's somewhere around there ;) Hey if you find something don't forget about me ;D 1DvdiYvRr7pzHsYRJiXYdroQNZUqKxLAzf I need a new computer to get 1 or 2 Ekeys/s like this guy, https://bitcointalk.org/index.php?topic=5322040.msg62268526#msg62268526 With bsgs mode it is only a matter of ram to reach those speeds, I don't see it as easy with puzzle 66. Anyway, I don't think those who solved 120 and 125 have done a full range scan or used a single computer, it would be interesting to know what program and what values they used, but obviously this must be confidential information. Unfortunately I have the problem that I like numbers and I understand magnitudes, and honestly every time I see the infinity that we face I want to look for my weapon!! ha ha ::) Personally I believe that whoever made the puzzles did not use a random method, I think the location of the known puzzles in relation to their rank demonstrates this. A while ago I did a linear regression study and I was surprised by the result. I expected the average difference between the predicted and actual location to be approximately 50%, which is what is expected for a linear regression prediction on random data, however the average is 27.81% I dare to predict that puzzle 66 is at ~72% of its range. ;D 💩💩💩 Bullshit! The author already said that it was the result of a random keys padding with bits to match the expected range. Hello Alberto. However, is the author willing to provide more information? I don't think so, otherwise I would have exposed more public keys. What it has done is increase the incentive so that more people hit the security. After all, what does the author want to prove? I imagine that the security of bitcoin... Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 10, 2024, 10:21:12 PM what does the author want to prove? I imagine that the security of bitcoin... Yes he want to prove the bitcoint security in his own words: I am the creator. You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all. I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully. A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community. Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting! Now please if you want to continue the discution of that topic please use that "Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it" Topic, not this, this only for Keyhunt related issues. Any new post that is not keyhunt will be reported as Offtopic or SPAM hi ALBERTO; For N value in Keyhunt Program Example: Nx100000000 = 4294967296 keys Does it mean that it scans every 4294967296 key sequentially? Is it true ? It selects a random key and scans 4294967296 wallets sequentially, and then it selects a random key again and scans 4294967296 wallets sequentially. Did I understand correctly? Does it work like this? Keyhunt N value? Yes it is exactly like you describe above Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on March 16, 2024, 03:24:31 PM hello alberto
In keyhunt addresses mode, we can change the -n value as we wish and perform sequential random searches of any size we want. However, in keyhunt bsgs mode, since this -n value works together with the k value, we cannot exceed a certain number. What can we do for this? Example: N 100000000000= It scans 17592186044416 keys sequentially and then randomly selects a range again and scans wallets up to 17592186044416 sequentially. Is it possible to increase this number? After scanning 1000000000000000000 wallets, I want to choose a random range again and scan 1000000000000000000 wallets sequentially. I hope I was able to explain. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 16, 2024, 04:10:19 PM hello alberto In keyhunt addresses mode, we can change the -n value as we wish and perform sequential random searches of any size we want. However, in keyhunt bsgs mode, since this -n value works together with the k value, we cannot exceed a certain number. What can we do for this? Example: N 100000000000= It scans 17592186044416 keys sequentially and then randomly selects a range again and scans wallets up to 17592186044416 sequentially. Is it possible to increase this number? After scanning 1000000000000000000 wallets, I want to choose a random range again and scan 1000000000000000000 wallets sequentially. I hope I was able to explain. I don't see what is the problem here, just use the number that you want. Did you already tried? Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on March 16, 2024, 06:01:47 PM hello alberto In keyhunt addresses mode, we can change the -n value as we wish and perform sequential random searches of any size we want. However, in keyhunt bsgs mode, since this -n value works together with the k value, we cannot exceed a certain number. What can we do for this? Example: N 100000000000= It scans 17592186044416 keys sequentially and then randomly selects a range again and scans wallets up to 17592186044416 sequentially. Is it possible to increase this number? After scanning 1000000000000000000 wallets, I want to choose a random range again and scan 1000000000000000000 wallets sequentially. I hope I was able to explain. I don't see what is the problem here, just use the number that you want. Did you already tried? For Keyhunt bsgs mod I want to set -N to a high value but the program freezes because there is not enough RAM. So for 16 GB ram K max = 1024 N max = 100000000000 I want to increase the N value but I can't. For example, the value of N I want to do 400000000000000 but the computer freezes. Cannot run High N value on low system Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 16, 2024, 06:06:42 PM OK, i got you, yes the limit is the ram.
Then why no you just select your specific range and run it sequentially even with the small N it should works? Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on March 16, 2024, 07:09:24 PM OK, i got you, yes the limit is the ram. Then why no you just select your specific range and run it sequentially even with the small N it should works? So I wanted to ask if there is a solution, my friend. My computer scans 17592186044416 wallets in order, then selects a random order again and scans 17592186044416 wallets in order. I just asked if we can increase the number of wallets scanned. I want it to scan 100000000000000000 wallets in order, then choose a random order again, and then scan 100000000000000000 wallets again. But since the amount of RAM is not enough, I wanted to ask you. Thank you for your answers. This program is amazing. I hope we will see new versions in the future. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 16, 2024, 07:29:24 PM So I wanted to ask if there is a solution I already told you a possible work around, select a specific range of the number of keys that you want to scan and do it sequentially instead of random. If that doesn't work for you then nothing will work for you, MAKE YOUR OWN TESTS. Title: Re: Keyhunt - development requests - bug reports Post by: GTX1060x2 on March 18, 2024, 09:35:38 AM If anyone is using keyhunt on an AMD processor, try compiling it with AOCC.
I got a +13% performance increase on Zen2 architecture compared to GCC-12, 13 and 14. It would be interesting to see tests on Zen4 architecture. https://www.amd.com/en/developer/aocc.html Title: Re: Keyhunt - development requests - bug reports Post by: Lugh1Man on March 20, 2024, 05:37:23 PM Hi all, Alberto,
Has anyone done tests of KeyHunt (and shared the results) with very large amount of ram - say 512GB - 1TB? I'm thinking of doing this myself to at least document the speed gains (relationship between the n and k values, and the speed reported). To my understanding, adding more ram will significantly increase the speed because you can use a higher n and k values. I believe adding more RAM is much more beneficial to adding more CPU power, but of course both are important. Edit: I'm talking about BSGS mode, of course. Please delete this if it's off-topic for this thread. Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 20, 2024, 06:00:59 PM Please delete this if it's off-topic for this thread. it is not a off-topic. Yes there are some users who use up to 1TB of ram, as far i remember those get some tens of Exakeys/s but it is not enough for high bit puzzles Title: Re: Keyhunt - development requests - bug reports Post by: tkredbaron on March 23, 2024, 09:12:33 PM hey Alberto,
thanks for your outstanding work what about the idea run key hunter on bitminer/antminer hardware? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 24, 2024, 12:50:39 AM what about the idea run key hunter on bitminer/antminer hardware? That is not possible Miner Hardware only is capable to do sha256. And key hunt process need sha256, rmd160, eliptic curve operations and some other math operations. Title: Re: Keyhunt - development requests - bug reports Post by: FlleOWA on March 28, 2024, 08:20:09 AM There are 2 processors installed on the motherboard. The program only works with one. I specify all cores, but only one processor is used. The program can't work with multiple processors?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 28, 2024, 11:29:08 AM There are 2 processors installed on the motherboard. The program only works with one. I specify all cores, but only one processor is used. The program can't work with multiple processors? That depend of the Operating System. It is not related the program. Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 28, 2024, 08:38:46 PM Thanks to Alberto for this nice tool
I tried to test my speed with puzzle 120 which you put on github for test and thats working. But when i try to start scan puzzle 130 the processing stuck in 0% I changed the -k from 256 to 128 now thats working... in windows -k 256 worked Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 28, 2024, 09:07:36 PM I tried to test my speed with puzzle 120 which you put on github for test and thats working. But when i try to start scan puzzle 130 the processing stuck in 0% I changed the -k from 256 to 128 now thats working... in windows -k 256 worked The issue may be some configuration of the WSL enviroment sometimes it is capped at a certain percentage of the Host RAM please check: https://www.aleksandrhovhannisyan.com/blog/limiting-memory-usage-in-wsl-2/ Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 28, 2024, 09:30:40 PM I tried to test my speed with puzzle 120 which you put on github for test and thats working. But when i try to start scan puzzle 130 the processing stuck in 0% I changed the -k from 256 to 128 now thats working... in windows -k 256 worked The issue may be some configuration of the WSL enviroment sometimes it is capped at a certain percentage of the Host RAM please check: https://www.aleksandrhovhannisyan.com/blog/limiting-memory-usage-in-wsl-2/ Thank you Alberto, the problem fixed now. now , random mode is more useful or sequential mode? is it good that we start at beginning of range or start from 10% or more of range? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 28, 2024, 10:05:36 PM Thank you Alberto, the problem fixed now. now , random mode is more useful or sequential mode? is it good that we start at beginning of range or start from 10% or more of range? That depend of your target, for small ranges sequential is good, but for largest ranges random is the best choice. Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 29, 2024, 06:43:50 AM Thank you Alberto, the problem fixed now. now , random mode is more useful or sequential mode? is it good that we start at beginning of range or start from 10% or more of range? That depend of your target, for small ranges sequential is good, but for largest ranges random is the best choice. May please explain alittle how random mode working? is it different every time we start random? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 29, 2024, 12:48:30 PM May please explain alittle how random mode working? is it different every time we start random? It is always random, check your self with the -M option Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 30, 2024, 08:33:07 PM i have a server with 8 cores and 16gb Ram
Im using -t 8 -k 1024, the speed is 115 pkeys/s. should I still using random mode or with this speed its good to use sequential mode? is there any recommended command with this server for faster speed? Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 30, 2024, 09:33:15 PM is there any recommended command with this server for faster speed? I have no idea, btw the speed is not good, to be honest with you not even some hundreds exakeys are enough for this. Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 30, 2024, 09:43:16 PM how much is your speed with your pc Alberto?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on March 30, 2024, 10:50:30 PM how much is your speed with your pc Alberto? My speed is no important, I get 1 Exakeys/s as far i can remember. Title: Re: Keyhunt - development requests - bug reports Post by: AliBah on March 31, 2024, 12:56:04 AM how much is your speed with your pc Alberto? My speed is no important, I get 1 Exakeys/s as far i can remember. If i asked its because i want to buy new pc and need your advice for choose hardwares. Title: Re: Keyhunt - development requests - bug reports Post by: _Counselor on April 03, 2024, 08:30:24 PM Hi, Alberto.
xpoint mode does not work at full possible speed, because FLAGSEARCH has default value of 2 (SEARCH_BOTH); then at thread_process you have following condition: Code: calculate_y = FLAGSEARCH == SEARCH_UNCOMPRESS || FLAGSEARCH == SEARCH_BOTH || FLAGCRYPTO == CRYPTO_ETH; Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 03, 2024, 09:42:58 PM Hi, Alberto. xpoint mode does not work at full possible speed, because FLAGSEARCH has default value of 2 (SEARCH_BOTH); then at thread_process you have following condition: Code: calculate_y = FLAGSEARCH == SEARCH_UNCOMPRESS || FLAGSEARCH == SEARCH_BOTH || FLAGCRYPTO == CRYPTO_ETH; Hi, thank you very much to point to this, yes you are right with this it is not working at full speed. A big facepalm for me. I will correct it ASAP and update the code. Maybe i should use separate functions for those modes to also avoid unnecesary switch-case opcions. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: cryptoperson678 on April 07, 2024, 04:56:27 PM Say, I'm willing to randomly waste electricity on one of the puzzles using keyhunt in bsgs random mode. Is there a way to somehow store progress with the goal to not check already scanned keys/ranges...
Currently I am using this command keyhunt -m bsgs -f tests/130.txt -b 130 -R -n 0x100000000000 -k 2048 -q -t 8 -s 10 -S Any input would be appreciated. Also, does anyone have comments on the params I'm running? I have 64GB of RAM, however if I set k to 4096 I start to swap for a couple of Gigabytes, with k = 2048 the RAM is filled only to half, is there a way to use around 60GB of RAM to realize the full potential of my setup? Title: Re: Keyhunt - development requests - bug reports Post by: _ic0nic_ on April 11, 2024, 02:54:48 AM ??? ??? ???
I'm fairly new to the internal functionalities (which I'm trying to figure out as I go lol). So, I've gone thru the demo shown in the readme but when I ran the command, I get the error: Code: $ time ./keyhunt -m bsgs -t 6 -f tests/in.txt -r 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff -n 0x1000000000000000 -M -s 0 I am on a macbook (I should've invested in a dam hp laptop or something, but oh well) and it's the legacy version. I used the same file and same command prompt as shown in the readme so I don't know what the problem could be. Thanks in advance though, if a solution arises. :) Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 11, 2024, 09:54:35 AM Thank you for report this I will check it ASAP
Title: Re: Keyhunt - development requests - bug reports Post by: kosiosl on April 12, 2024, 07:31:26 AM Hey community!
Does anyone knows how to search ETH ADDRESS with prefix? Something like that ./KeyHunt -g --gpui 0 --gpux 256,256 -m address --coin eth -r 1 0x1ffb. The code only accept a whole ETH ADDRESS for searching. Title: Re: Keyhunt - development requests - bug reports Post by: Ovixx on April 12, 2024, 07:43:46 AM ??? ??? ??? I'm fairly new to the internal functionalities (which I'm trying to figure out as I go lol). So, I've gone thru the demo shown in the readme but when I ran the command, I get the error: Code: $ time ./keyhunt -m bsgs -t 6 -f tests/in.txt -r 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff -n 0x1000000000000000 -M -s 0 I am on a macbook (I should've invested in a dam hp laptop or something, but oh well) and it's the legacy version. I used the same file and same command prompt as shown in the readme so I don't know what the problem could be. Thanks in advance though, if a solution arises. :) It works for me on WSL. Check if the public keys in the in.txt file are valid. Code: ovidiu@#########:~/keyhunt$ time ./keyhunt -m bsgs -t 6 -f tests/in.txt -r 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff -n 0x1000000000000000 -M -s 0 Title: Re: Keyhunt - development requests - bug reports Post by: Airfin Same on April 12, 2024, 07:36:53 PM I want to open this thread to talk about the tool that i develop Keyhunt (https://github.com/albertobsd/keyhunt) available on github. https://github.com/albertobsd/keyhunt (https://github.com/albertobsd/keyhunt) Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed. Current Version 0.2.230430 Satoshi Quest Lastest changes on development branch (https://github.com/albertobsd/keyhunt/tree/development) How to use Download and build Run againts puzzle 66 (addres mode) 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so (https://mempool.space/address/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so) 6.6 BTC Code: ./keyhunt -m address -f tests/66.txt -b 66 -l compress -R -q -s 10 You need to add -t numberThreads to get better speed Run againts Puzzle 130 (bsgs mode) 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua (https://mempool.space/address/1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua) 13 BTC Code: ./keyhunt -m bsgs -f tests/130.txt -b 130 -q -s 10 -R You need to add -t numberThreads and -k factor to get better speed Best regards! hi albert0bsd i want to try keyhunt is there a compiled copy of keyhunt to work on windows Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 12, 2024, 08:36:55 PM hi albert0bsd i want to try keyhunt is there a compiled copy of keyhunt to work on windows There are some but I don't recommend run any of them. Try it from WSL it will work better Title: Re: Keyhunt - development requests - bug reports Post by: _ic0nic_ on April 13, 2024, 02:54:46 AM ??? ??? ??? I'm fairly new to the internal functionalities (which I'm trying to figure out as I go lol). So, I've gone thru the demo shown in the readme but when I ran the command, I get the error: Code: $ time ./keyhunt -m bsgs -t 6 -f tests/in.txt -r 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff -n 0x1000000000000000 -M -s 0 I am on a macbook (I should've invested in a dam hp laptop or something, but oh well) and it's the legacy version. I used the same file and same command prompt as shown in the readme so I don't know what the problem could be. Thanks in advance though, if a solution arises. :) It works for me on WSL. Check if the public keys in the in.txt file are valid. Code: ovidiu@#########:~/keyhunt$ time ./keyhunt -m bsgs -t 6 -f tests/in.txt -r 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5effffffffffffffff -n 0x1000000000000000 -M -s 0 I believe it's because you aren't using the legacy version :) I'm guessing you compiled with Code: make Code: make legacy Then again, I am running all of this off of the macbook terminal... Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on April 14, 2024, 04:01:44 PM What about endomorphism?
I can use it 130 bit puzzle ? BSGS If I add -e . It is advantage? Some say I can use it in puzzles, some say I can't use it in puzzles. What is the situation? Which one is right ? Is it useful when searching for 130 bit puzzles in bsgs? My brother, when searching for 130 puzzles in keyhunt bsgs mode, it gets faster when you add the -e command. Do you think it is good to use this? Some people say it cannot be used in puzzles, some say it can be used. What is the certainty on this matter? After all, the range of puzzle 130 is clear. Would it be useful to use the -e command? Title: Re: Keyhunt - development requests - bug reports Post by: satashi_nokamato on April 15, 2024, 12:46:54 PM Do you even know what endomorphism is? There are a few 256 bit scalars and when you multiply your public key by them, the results will have the same y coordinates as your public key. So if you are using -e, you will end up with a 256 bit result.
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on April 15, 2024, 09:21:48 PM What about endomorphism? I can use it 130 bit puzzle ? BSGS If I add -e . It is advantage? Endomorphism doesn't work with BSGS https://talkimg.com/images/2024/04/15/jI35m.png It is written in the documentation, it is not clear? Title: Re: Keyhunt - development requests - bug reports Post by: coinchief228 on April 16, 2024, 06:46:40 PM Thanks for the amazing program! Question about BSGS modes -- does K have to be a power of 2? Could you use something like -k 1536 and still get correct results? I have enough RAM to run with a K of 1024 but not 2048 so I was looking to run in the middle.
Or perhaps I could still run with 1024 but adjust the value of N instead? Title: Re: Keyhunt - development requests - bug reports Post by: Xboksss on April 21, 2024, 03:56:56 PM Base key: 97bbe7a6eebb0cd453fbc80b038c226f1492d40889327e
What is it? Maybe someone can give me a hint. Title: Re: Keyhunt - development requests - bug reports Post by: anjilite7 on May 02, 2024, 08:10:56 PM how big the difference between speed in Cygwin and WSL versions of Keyhunt?
Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 03, 2024, 11:49:04 AM Base key: 97bbe7a6eebb0cd453fbc80b038c226f1492d40889327e What is it? Maybe someone can give me a hint. Is not obvious? well if not it is the key range that is beginning to be scanned how big the difference between speed in Cygwin and WSL versions of Keyhunt? In my opinion WSL is faster. But just do your own test. Title: Re: Keyhunt - development requests - bug reports Post by: seanzhau on May 06, 2024, 12:30:44 PM How to view blm files？What info is stored in tbl file?
Code: # ./keyhunt -m bsgs -f tests/130.txt -6 -b 130 -k 4096 -q -t 64 -S Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 06, 2024, 12:52:41 PM How to view blm files？What info is stored in tbl file? To be honest you dont need view them, they contain thee bloom filter data, it is a probabilistic datastructure that use an array of bits to store collision of hashed data, if you see that bit array it will like a random data without any sense to the human brain. if you want to learn about them, check this video https://www.youtube.com/watch?v=-jiOPKt7avE Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on May 06, 2024, 01:32:36 PM if you want to learn about them, check this video https://www.youtube.com/watch?v=-jiOPKt7avE ... and https://www.geeksforgeeks.org/bloom-filters-introduction-and-python-implementation/ https://en.wikipedia.org/wiki/Bloom_filter https://systemdesign.one/bloom-filters-explained/ Example / Tutorial: https://llimllib.github.io/bloomfilter-tutorial/ Title: Re: Keyhunt - development requests - bug reports Post by: nomachine on May 15, 2024, 01:45:51 PM If anyone is using keyhunt on an AMD processor, try compiling it with AOCC. I got a +13% performance increase on Zen2 architecture compared to GCC-12, 13 and 14. It would be interesting to see tests on Zen4 architecture. https://www.amd.com/en/developer/aocc.html I have a zillion errors when compiling with Clang . Need to remove all Intel Intrinsics (__builtin_ia32_) in code . These intrinsics are specific to Intel processors and are not compatible with AMD processors. Title: Re: Keyhunt - development requests - bug reports Post by: AndrewWeb on May 20, 2024, 10:05:12 AM How to view blm files？What info is stored in tbl file? Code: # ./keyhunt -m bsgs -f tests/130.txt -6 -b 130 -k 4096 -q -t 64 -S 32-Core (64-Thread) Processor with 64 GB RAM = 2 Exa Keys Per Second Title: Re: Keyhunt - development requests - bug reports Post by: davidk111 on May 20, 2024, 04:38:16 PM Sorry if this is posted in wrong thread. Started using keyhunt a couple weeks ago.
My question is if I was lucky enough to ever get one of the bitcoin private keys how do you use it to get into the wallet? Is there a certain wallet you download to enter the key and get in or ???? I searched but only thing I found was something on downloading the electrum bitcoin wallet and using that but when I downloaded and checked that out the string they tell you to put in before the key depending on the first couple of characters of the wallet address does not match up at all with the characters of wallet 66 or that matter with most if not all the other wallets unless I am missing something obvious. Any help would be appreciated Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on May 20, 2024, 04:51:03 PM My question is if I was lucky enough to ever get one of the bitcoin private keys how do you use it to get into the wallet? If you are asking this I sugest to you stop using keyhunt right now and start reading the basics about this: https://github.com/bitcoinbook/bitcoinbook About the wallets you can use some light wallets like Electrum Also Sparrow wallet is Good (I personally prefer this one) Remember it cost nothing ask in google or even those AI bots like chatgpt, those are a really good staring point. Title: Re: Keyhunt - development requests - bug reports Post by: cnk1220 on June 14, 2024, 11:53:29 AM Hi everyone.
First, sorry by my english. Ok, i wanna to understand about the very comments that say when public key puzzle 66 show up, that will be cracked and will use the private key to redirect the transaction. If that is true, and I get about the hugeness of range that possible 256bits, my question is, why then the people don't use that algoritm, for example, to crack the "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f" pubkey from satoshi or any other known public key with huge btc amount? Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on June 14, 2024, 01:03:40 PM Hi everyone. First, sorry by my english. Ok, i wanna to understand about the very comments that say when public key puzzle 66 show up, that will be cracked and will use the private key to redirect the transaction. If that is true, and I get about the hugeness of range that possible 256bits, my question is, why then the people don't use that algoritm, for example, to crack the "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f" pubkey from satoshi or any other known public key with huge btc amount? Once the puzzle reveals 66 pubkeys, it is solved within seconds because the scanning range is small. BUT even if a 256-bit wallet has a pubkey, it is impossible to decrypt it because the scanning range is incredibly large. While 1 graphics card is enough to solve puzzle 66 in seconds A large number of graphics cards are required to decrypt a 256-bit wallet. millions, billions, trillions, I hope you understand. Title: Re: Keyhunt - development requests - bug reports Post by: cnk1220 on June 14, 2024, 01:09:28 PM Hi everyone. First, sorry by my english. Ok, i wanna to understand about the very comments that say when public key puzzle 66 show up, that will be cracked and will use the private key to redirect the transaction. If that is true, and I get about the hugeness of range that possible 256bits, my question is, why then the people don't use that algoritm, for example, to crack the "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f" pubkey from satoshi or any other known public key with huge btc amount? Once the puzzle reveals 66 pubkeys, it is solved within seconds because the scanning range is small. BUT even if a 256-bit wallet has a pubkey, it is impossible to decrypt it because the scanning range is incredibly large. While 1 graphics card is enough to solve puzzle 66 in seconds A large number of graphics cards are required to decrypt a 256-bit wallet. millions, billions, trillions, I hope you understand. So, try to solve, any of this low bits puzzle, 66,67,68 ... is useless, cause there are many bots watching this addresses for their public key right? If so, why still people discussing about it anyway? And second, why didn't it with puzzle 64? Title: Re: Keyhunt - development requests - bug reports Post by: Baskentliia on June 14, 2024, 01:21:42 PM Hi everyone. First, sorry by my english. Ok, i wanna to understand about the very comments that say when public key puzzle 66 show up, that will be cracked and will use the private key to redirect the transaction. If that is true, and I get about the hugeness of range that possible 256bits, my question is, why then the people don't use that algoritm, for example, to crack the "04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef3 8c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f" pubkey from satoshi or any other known public key with huge btc amount? Once the puzzle reveals 66 pubkeys, it is solved within seconds because the scanning range is small. BUT even if a 256-bit wallet has a pubkey, it is impossible to decrypt it because the scanning range is incredibly large. While 1 graphics card is enough to solve puzzle 66 in seconds A large number of graphics cards are required to decrypt a 256-bit wallet. millions, billions, trillions, I hope you understand. So, try to solve, any of this low bits puzzle, 66,67,68 ... is useless, cause there are many bots watching this addresses for their public key right? If so, why still people discussing about it anyway? And second, why didn't it with puzzle 64? Yes, bots are waiting in wait. The moment a sucker waits for puzzle number 66 and sends the transaction to the network, Pubkey will appear and bots will steal it within seconds. puzzle 64 reward was 0.64 and bitcoin value was low then also software bots were not that advanced. Currently the reward is 6.6 BTC and bots are waiting in ambush Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 15, 2024, 03:23:16 AM If so, why still people discussing about it anyway? Because always it's possible (with enough hash rate)mine a block with your private Transaction on it, ( yourself or a miner ) Title: Re: Keyhunt - development requests - bug reports Post by: citb0in on June 15, 2024, 08:06:37 AM Because always it's possible (with enough hash rate)mine a block with your private Transaction on it, ( yourself or a miner ) yeah, you need just some tons of hashpower, better some Exahashes/sec and a lot of patience :D Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 15, 2024, 03:39:08 PM I just understand a little of Portuguese. I Only know Spanish and English.
Alberto, eu estava mesmo pensando nisso, sobre eu mesmo minerar o bloco, mas dai daria mais trabalho, pelo hashrate necessário. Mas dai a minha dúvida. Supondo que tivesse poder pra minerar, o processo não seria: 1 - Colocar a transação na mempool; 2 - Minerar o bloco? It is not necessary to broadcast the transaction before mining the block. Once that miners found a valid hash for their private block, they need to broadcast their full block data, only at that time the transaction will be public. (We are talking of private transactions that are only public once that they are already inside of a mined block). Obviously that need to be a Custom miner software You need to learn the full mining process, you need to know about the merkle trees and how block headers need to be build: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12_mining.adoc#constructing-the-block-header Title: Re: Keyhunt - development requests - bug reports Post by: benjaniah on June 23, 2024, 07:55:09 PM I've been using Keyhunt for a long time. It's a great program.
Are there any plans to incorporate an option to also search segwit, native segwit, and taproot addresses simultaneously along with the current legacy compressed/uncompressed addresses? For example, if you wanted to use Keyhunt, in address mode, to do random searching in the full keyspace against Loyce Club's funded wallet list. ./keyhunt -m address -f tests/Bitcoin_addresses_LATEST.txt -l all -R -t 32 -s 10 (where "-l all" would be compressed, uncompressed, segwit, native segwit, taproot) I know people say it's pointless but it'd be fun to try. Title: Re: Keyhunt - development requests - bug reports Post by: Viniciof on June 25, 2024, 06:49:59 PM Hello,
I have been testing and playing with keyhunt, very impressive and fast. Recently, I tested bsgsd sever and it also is pretty fast: time echo "0365ec2994b8cc0a20d40dd69edfe55ca32a54bcbbaa6b0ddcff36049301a54579 4000000000000000:8000000000000000" | nc -v localhost 8080 Ncat: Version 7.80 Ncat: Connected to 127.0.0.1:8080. 7cce5efdaccf6808Ncat: 101 bytes sent, 16 bytes received in 2.95 seconds. real 0m2.961s user 0m0.022s sys 0m0.004s I know printing to screen will cause lost of speed but, is there any way I can check exactly how many keys/s are running in bagsd? With debug or something similar to what keyhunt shows, just for testing. I was able to run bsgsd from a little shell scrip so I can handle some specific ranges without restarting bsgsd each time (it takes half an hour for server to startup), after that, I could get 5E. Will be any speed improvement in the future for bsgsd or bsgs key generator? albert0bsd, thanks for all your work!!! Title: Re: Keyhunt - development requests - bug reports Post by: albert0bsd on June 26, 2024, 02:42:41 AM I tested bsgsd sever and it also is pretty fast Nice, not much people test it because not much knows that the server exists ::) I know printing to screen will cause lost of speed but, is there any way I can check exactly how many keys/s are running in bsgsd? To keep the best performance in the server i should recommend not to look for this on the server side. Instead of it i should recommend to this on client side, in the BSGSD.md file i post a small python client, since performance is not required on client python fit perfectly for this situation, you can send small chunks of work to the server something like 50 to 55 bits of subrange and edit the client output to print the speed: Code: # Loop for sending and receiving messages In that code you need to set the sub-range value, this require to know what are you doing but you can get more or less the speed that you are getting in each time. I hope this workaround fit your needs because to be honest i don't see any necessary to print the speed on the server side, it was made to attend clients without the need to be in front the same terminal. Will be any speed improvement in the future for bsgsd or bsgs key generator? For CPU i doubt it, I already did a lot of improvements compared against the BSGS of JLP i think that i realdy reach the CPU speed limit. The only possible improvement will be implement another faster storage for the Baby table and bloom filters or the use of GPU (It need to rewrite all the code) albert0bsd, thanks for all your work!!! Thanks, you're more than welcome. Regards! Title: Re: Keyhunt - development requests - bug reports Post by: Viniciof on June 26, 2024, 10:37:39 PM Thanks for the answer and help, I'm just a newbie but could play around a little bit!
Title: Re: Keyhunt - development requests - bug reports Post by: Ovixx on June 28, 2024, 08:56:17 AM Hello Alberto. I built a new computer with better performance than the old one, in order to establish a higher value of the K factor. I have 192 GB DDR5 memory and Intel i9-14900K CPU. After I installed Windows 11, I installed the keyhunt application on WSL, but any of the K value I put, it gives me an error when saving the *.blm file. I ask you for advice to solve the problem. I tried from K = 8192, 4096 I went down to K = 256 and in vain. The problem is not from the value of K. I mention that I have enough free space, 1.28TB on a Samsung PRO SSD with 7000 MB read/write. Thank you in advance!
Code: ovix@DESKTOP-Z790:~/keyhunt$ ./keyhunt -t 2 -m bsgs -f tests/130.txt -r 200000000000000000000000000000000:3ffffffffffffffffffffffffffffffff -q -s 10 -S -k 256 -R |
