|
801
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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! |
|
|
|
|
802
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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. |
|
|
|
|
803
|
Bitcoin / Bitcoin Discussion / Re: How 63 bit puzzle a other low puzzles were solved?
|
on: October 13, 2021, 06:37:33 PM
|
|
Yes that is right i read that history some months ago he do it with the JLP Kangaroo codes.
But he don't solve the puzzle 64 he said that it will take some 6 months with his 248 Gkeys/s in that moment and that puzzle not worth the time or effort. With that computer power is better mining than solve puzzles.
|
|
|
|
|
804
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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  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?Keyhunt Solving the 63 bit puzzle, just testingRegards! |
|
|
|
|
806
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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 |
|
|
|
|
807
|
Bitcoin / Bitcoin Discussion / Re: How 63 bit puzzle a other low puzzles were solved?
|
on: October 11, 2021, 03:09:00 PM
|
Ok, thanks let me time to read all the 80 Pages of that topic. Have you shown the calculations for BSGS or Kangaroo?
is the Speed in keys/seconds and nothing more, i know that kangaroo solve the keys by the birthday paradox but i understand that it need the public key to do that no? the BSGS speed depend of memory, right now my version of bsgs can reach some Petakeys/s and yes it solve all those puzzles in seconds or minutes, but of course this is only possible with the publickey. So if those programs need the publickey to have such ridiculous speed, how those puzzles were solved without having the publickey, well i going to read all the the topic thanks! I will try to put here a decent summary for that Regards! |
|
|
|
|
808
|
Bitcoin / Bitcoin Discussion / How 63 bit puzzle a other low puzzles were solved?
|
on: October 11, 2021, 01:09:01 PM
|
Hi, i search about it but i didn't find anything specific. So that is the question: How 63 bit puzzle a other low puzzles were solved?I did not mean which script or program was used, i mean what hardware was used? also ask if it was luck? Previous puzzles where solved time ago. Here are my calculations about the time to scan All the range of each puzzle. Puzzle 61 @ 1 Megakeys/s (10^6): 36558 years
Puzzle 61 @ 1 Gigakeys/s (10^9): 36 years
Puzzle 62 @ 1 Megakeys/s (10^6): 73117 years
Puzzle 62 @ 1 Gigakeys/s (10^9): 73 years
Puzzle 63 @ 1 Megakeys/s (10^6): 146235 years
Puzzle 63 @ 1 Gigakeys/s (10^9): 146 years
Puzzle 64 @ 1 Megakeys/s (10^6): 292471 years
Puzzle 64 @ 1 Gigakeys/s (10^9): 292 years Please if im wrong in those calculations let me know. Here are the private keys 13C96A3742F64906 puzzle 61 363D541EB611ABEE puzzle 62 7CCE5EFDACCF6808 puzzle 63 By example the puzzle 63 the privatekey is near of the end of the range, so if you have some hardware to search at 100 Gkeys/s it will take 1.4 years, lets to say that you are searching it in random mode and you have luck at 25% of the range that is 4.2 months and only if you have those 100 Gkeys/s. Somebody know the history of how much time and hardware they use?
AnsweredSumary Addresses from 1 to 50 puzzles were solved simultaneous by an uknow person/group Addresses from 51 to 54 puzzles were solved by the the LBC project with variable speed from some 190 trillion keys per day Addresses from 55 to 58 puzzles were solved by a Unknow person/group Addresses from 59 to 63 puzzles were solved by Zielar with a speed of 248 Gkeys/s with bitcrack There are interesting things in that Topic Zielar talk about 0 costs of the electricity for him: https://bitcointalk.org/index.php?topic=1306983.1140Speed of 248 GKeys/s are written here: https://bitcointalk.org/index.php?topic=1306983.msg51808347#msg51808347He use upto 100 GPUs Tesla https://bitcointalk.org/index.php?topic=1306983.msg51848002#msg51848002But in some previous post he only talk about 4 or 8 GPUs seems that he manage to get access to 100 GPUs at 0 cost for him That is all that i want to know. Regards! |
|
|
|
|
809
|
Bitcoin / Project Development / Re: ecctools - a small collection of tools written in C
|
on: September 24, 2021, 07:39:36 AM
|
I know this is hobby project, but you might want to check https://keybase.io/warp as reference if you plan to improve it's security. Interesting i saw that it use scrypt and pbkdf2. s1 = scrypt(key=(passphrase||0x1), salt=(salt||0x1), N=218, r=8, p=1, dkLen=32)
s2 = pbkdf2(key=(passphrase||0x2), salt=(salt||0x2), c=216, dkLen=32, prf=HMAC_SHA256)
keypair = generate_bitcoin_keypair(s1 ⊕ s2)
I will implement that, one to generate those address and another to forcebrute them. |
|
|
|
|
810
|
Bitcoin / Project Development / Re: ecctools - a small collection of tools written in C
|
on: September 23, 2021, 05:08:09 AM
|
add in the title something like (for Linux users only)  Well, yes i usually develop for linux, but the code can be running on windows through the ubuntu shell. Also with Mingw64. I was able to compile under Windows using Mingw64!!  That is what i'm talking about Thanks! 1. For rehashaddress, what hash algorithm do you use?
for now only sha256, but i will add some extra options. 2. Looking at README.md, looks like this tool only support legacy address (address with prefix 1), is it true?
Yes that is true for now, i will plan to add some extra kind of address but i'm still learning and testing it. 3. You might want to mention version of C (and other dependency/utility), so other people (and yourself in the future) could save some time.
Excellent yes, i will add it in the readme, some times I forget that most users doesn't know linux, also i forget that most user never read the readme LOL I will add it, also to the readme in github. Thanks! |
|
|
|
|
811
|
Bitcoin / Project Development / ecctools - a small collection of tools written in C
|
on: September 22, 2021, 08:29:19 AM
|
I made a new repository in github ecctoolsThis is a small collection of tools that i've made in the past months, most of those tools only do one or two things, those task are or were useful for me in some moments. Tool lists: List of tools in this repository - keygen
- sharedsecret
- rehashaddress
- calculatefromkey
- calculatefrompublickey
- keydivision
- keymath
- modmath
- addr2rmd
I will be updating this list when i add some new codes I start this topic just to seek ideas, improvements, bug reports, requests. Regards! |
|
|
|
|
812
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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.
|
|
|
|
|
814
|
Bitcoin / Project Development / Re: keysubtracter - test - development requests - bug reports
|
on: September 20, 2021, 05:54:40 AM
|
How many bits does it subtract it by?
03f1d41da8acf0506f3bf7140b5629dd33a5cf546133479530cd8065e335a97666 # - 13292279957849158729038070602803446
022ec3a210bcb8ef6cf7b703b39539a83dc0c1318ccdb42daf48db2f0742971239 # + 13292279957849158729038070602803446
02b70ae2dcb442548570313f652b91ca093a3acac3a2441cb64614e8195505b6b8 # - 26584559915698317458076141205606892
0367dabeef20a6a8b7b5555b162cc8c8489e3134dcec624fe028573c34dbbf20f6 # + 26584559915698317458076141205606892
02a1d21298779f888cd8169f9ed59e4383219cdadbdb342ba886034ef9013b89be # - 39876839873547476187114211808410338
02ae015703cbaee9570dc648d7bce78ac7cb438630e09d69eef4f1208655e1027d # + 39876839873547476187114211808410338
(Output omitted)
If you see the number after the # char, is that the number that is being substracted or added to the original given publickey. I am not sure if I understand the reason to add and compare.
It makes total sense to subtract from the 120bit key and compare it with a smaller range.
Yes you are totally right, my logic in the first version was was the next: - if the target publickey was at the middle of the range, the subtracted keys will land from the beginning of the bit range up to the end of the same bit range.
- if the target publickey was at the begging of the range, the subtracted keys will land in the first half of the bit range and the other half will land in the previous bit range
- but if the target publickey was at the end of the range, the subtracted keys will land in the last half of the bit range and the other half will land in the next bit range
- Obviously those are perfect cases, but the reality is that we don't know where is the target publickey, so my orignal idea was just increase the probability to have near a subtracted key in anywhere in the selected keyspace
But I repeat you are right i will add the option of select only make a subtract or addition. Also think in the next one: - if you are working with targets in the 256 bit space, any addition may end in a lower bit space due to cyclical behavior of the eliptic curve
I know you mainly build for Linux but wasn't sure if this was something you have seen/experienced before.
Yes i see that error before, is some re-declaration of that G variable (gmpecc.c load the gmpecc.h but also keysubtracter is loading that header file, i manage avoid that with the Makefile), maybe adding some header directive like #prama once can be useful , but i don't know if it can work for you. Are you using the command "make" in Mingw64 ? If not, can you add the command that you are using to compile it? |
|
|
|
|
815
|
Bitcoin / Project Development / keysubtracter - test - development requests - bug reports
|
on: September 18, 2021, 07:40:45 PM
|
Github page: https://github.com/albertobsd/keysubtracterI publish this code on github in April 5, but i never update it until now, this is a small tool to make some substracted publickeys, address or hashes rmd160 from a target publickey. This can be useful to increment our chances of hit some privatekey of the puzzles. For example to make 100 copies of the puzzle 120 you need to execute the next command: ./keysubtracter -p 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 -n 100 -b 120 Output 03f1d41da8acf0506f3bf7140b5629dd33a5cf546133479530cd8065e335a97666 # - 13292279957849158729038070602803446
022ec3a210bcb8ef6cf7b703b39539a83dc0c1318ccdb42daf48db2f0742971239 # + 13292279957849158729038070602803446
02b70ae2dcb442548570313f652b91ca093a3acac3a2441cb64614e8195505b6b8 # - 26584559915698317458076141205606892
0367dabeef20a6a8b7b5555b162cc8c8489e3134dcec624fe028573c34dbbf20f6 # + 26584559915698317458076141205606892
02a1d21298779f888cd8169f9ed59e4383219cdadbdb342ba886034ef9013b89be # - 39876839873547476187114211808410338
02ae015703cbaee9570dc648d7bce78ac7cb438630e09d69eef4f1208655e1027d # + 39876839873547476187114211808410338
(Output omitted)
but what that mean: ./keysubtracter -p <publickey to be substracted> -n <number of requested keys> -b <bit range> Output: New Publickey 1 # offset from original publickey
New Publickey 2 # offset from original publickey
...
Windows version thanks to WanderingPhilospherhttps://github.com/WanderingPhilosopher/Windows-KeySubtractor |
|
|
|
|
817
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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? - Added 116697 points from file[/b]
Because you add 100K publickeys, that is why it take some time in update the speed counter. Best regards! |
|
|
|
|
819
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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 ./bPfile 3355443200 bPfile.bin The file is 90 GB and the process continues, how do I calculate the final file size and creation time? each bP item is 32 bytes in disk. In RAM is about ~24 Bytes 2. A 100 GB file was created. ./keyhunt -m bsgs -f 50bit.txt -b 50 -R -k 800 -t 12 I don't notice any performance gain from bPfile.bin. 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 ./keyhunt -m bsgs -f 1-63.txt -R -t 12 -r 0000000000000001:8000000000000000 -k 800 File 1-63 contains public keys 1 through 63 of the puzzle bits. 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/b58decThis 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 |
|
|
|
|
820
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
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 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! |
|
|
|
|
Show Posts
