Bitcoin Forum
May 10, 2024, 01:39:57 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 »
821  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?

Code:
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?
822  Bitcoin / Project Development / keysubtracter - test - development requests - bug reports on: September 18, 2021, 07:40:45 PM
Github page: https://github.com/albertobsd/keysubtracter

I 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:

Code:
./keysubtracter -p 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 -n 100 -b 120

Output
Code:
03f1d41da8acf0506f3bf7140b5629dd33a5cf546133479530cd8065e335a97666 # - 13292279957849158729038070602803446
022ec3a210bcb8ef6cf7b703b39539a83dc0c1318ccdb42daf48db2f0742971239 # + 13292279957849158729038070602803446
02b70ae2dcb442548570313f652b91ca093a3acac3a2441cb64614e8195505b6b8 # - 26584559915698317458076141205606892
0367dabeef20a6a8b7b5555b162cc8c8489e3134dcec624fe028573c34dbbf20f6 # + 26584559915698317458076141205606892
02a1d21298779f888cd8169f9ed59e4383219cdadbdb342ba886034ef9013b89be # - 39876839873547476187114211808410338
02ae015703cbaee9570dc648d7bce78ac7cb438630e09d69eef4f1208655e1027d # + 39876839873547476187114211808410338
(Output omitted)

but what that mean:

Code:
./keysubtracter -p <publickey to be substracted> -n <number of requested keys> -b  <bit range>

Output:
Code:
New Publickey 1 # offset from original publickey
New Publickey 2 # offset from original publickey
...

Windows version thanks to WanderingPhilospher

https://github.com/WanderingPhilosopher/Windows-KeySubtractor
823  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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
824  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!
825  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: September 09, 2021, 01:39:34 PM
Hi albert0bsd,
have any progress about the program?

Sorry there is no progress yet.
826  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

Code:
./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.
Code:
./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

Code:
./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... ? Smiley

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

827  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 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!
828  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: April 13, 2021, 03:35:13 PM
On android use termux with the Iceland scripts in python, also with keyhunt you can work in android with some trillions of keys/s in bsgs mode
829  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: April 13, 2021, 01:52:24 AM
without this last part it is not working, what should be written there,
there is 1 warning,
about this line,.

         sscanf(&seed[2 * i], "%02X", &my1ch);


Warning   C4477   'sscanf' : format string '%02X' requires an argument of type 'unsigned int *', but variadic argument 1 has type 'unsigned char *'   VanitySearch vanity.cpp   322   

thanks

That is Ok, C can work with correctly if you want remove the warning you can write this:

Code:
sscanf(&seed[2 * i], "%02X",(unsigned int *)( &my1ch)); 
830  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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) 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!
831  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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

I hope you like it.

Best regards!
832  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle (3,350.00 BTC's ) on: April 07, 2021, 01:37:01 PM
I tried to solve the first and the second signature respectively
dU = (1 - s2-1e2 + s1-1e1) * (s2-1r2 - s1-1r1)-1 (mod n)

Any one can help me please.....

This fake puzzle is not solvable.
833  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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?


  • processing 19495846/214Can't read the file seen you have less items that the amount needed
  • processing 19964144/2147483648 bP points : 0%

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
834  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports on: March 31, 2021, 09:04:43 AM
Hello Thank you for making this code public. I really like it. Smiley

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.  Smiley

Sorry no, -k is only for mode bsgs, i will add it in the readme.

best regards!
835  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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!
836  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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.


837  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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
to: 0x800000000000000000100000000000

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

  • Added 0 points from file
Something is wrong with your input file, it doesn't have any valid data, yes is one bug, i need to solve it.

Edit Already Solved: Commit a0a60ede57890c5f46e711628f52de2d7becd270
 
Best regards!
838  Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports 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!
839  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: March 09, 2021, 06:00:43 PM
Yes that is rigth Kangaroo is the fastest one. I'm still learning the Pollard rho algorimth.
840  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: March 09, 2021, 05:48:23 PM
Is this speed based upon bitcrack or kangaroo?

Is just based on the speed that you get with any of those programs.

I just divide the Total of keys in each range between the speed by seconds.

By example the 120 bit space have 664613997892457936451903530140172287 total keys. Just divide that amount between you current speed the result are the seconds tha you will take, divide that bewteen 31536000 to get the numbers of years.

Is not based in my program or anything is just math.

Please if im wrong tellme, im open mind.

My program just reach some 1 to 8 petekeys/s in highend server and that is no hype.

Best regards!
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!