|
I got another question, so what type of gpu's work with kangaroo?
Is Geforce and Nvidia the same thing?
|
|
|
|
I got a question about about how to set the gpu to use kangaroo.
What does this mean GPUEngine: CudaGetDeviceCount CUDA driver version is insufficient for CUDA runtime version
and what is the cmd line to use the gpu?
It means you are using a driver that will not run with the CUDA props/runtime that the program was compiled with. Update your Geoforce Driver. Do you know which driver version you are using? What card(s) are you using? -gpu tells the program to use a gpu. If you have more than one then you would use something like -gpu -gpuId 0,1,2,3 (for however many cards you have on the system/want to use) I have AMD Radeon R4 Graphics |
|
|
|
|
I got a question about about how to set the gpu to use kangaroo.
What does this mean GPUEngine: CudaGetDeviceCount CUDA driver version is insufficient for CUDA runtime version
and what is the cmd line to use the gpu?
|
|
|
|
Looks like it works for subtraction too.I suppose that to chain a bunch of multiplications at once I could use 8 blocks with the lower 31 bits used, and the remainder of bits I need to have 256 math go in the highest block since I don't have to worry about overflow, and that'll let me do 1 multiplication without a carry. For 2 multiplications I'd use the lower 30 bits, for 4 I'd use 29 and so on. This'll allow me to mix many additions/subtractions and multiplications at once and go without carrying for a while. How is this coming along? |
|
|
|
Are kangaroo collisions in the same herd a bad thing? My program ( https://github.com/ZenulAbidin/Kangaroo-256) was doing that until I changed the hash table index calculation to use & HASHMASK instead of % HASHMASK. To my understanding, they don't slow down the search - that happens when your DP size is too small for your search range and initial points are lost - but it just keeps going on forever without colliding the private key in the hash table. Can you make an windows version of this too? |
|
|
|
|
It will take a good while for the remaining bits of this puzzle to get solve.
|
|
|
|
#120 ( 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT )
800000000000000000000000000000
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630
puzzle # 120 very long time yesterday from now 1 night 2 kangaroo write save work file to 1GB and 4GB now I close for works You must be using one helluva low -d setting to run up a 1 and 4GB file with one GPU. Look at estimated RAM, do you have enough space to save it all and then to merge at your current -d setting? Of course it will take a long if you're using a low -d setting. |
|
|
|
This is just not true. The RAM consumed/used is not dependent on the bits being search...it comes down to your DP setting and how often you save the work file. I don't see your settings/flags when starting the program but you are using a very low -d setting or that plus using a long save to file time.
I can see now that searching a 256-bit interval will become feasible if we use 128+ bits of DP mask  Seems like some good news pertaining with kangaroo. |
|
|
|
This is just not true. The RAM consumed/used is not dependent on the bits being search...it comes down to your DP setting and how often you save the work file. I don't see your settings/flags when starting the program but you are using a very low -d setting or that plus using a long save to file time.
I can see now that searching a 256-bit interval will become feasible if we use 128+ bits of DP mask How feasible are you talking? So you are working on searching 256-bit interval using 128 + bits of DP mask too? |
|
|
|
Where in the warping cyberspace is "PRIx64" defined?  Kangaroo.cpp, line 169, function SetDP(int size) [I think that's the name of it off the top of my head] ::printf("DP size: %d [0x%" PRIx64 "]\n",dpSize,dMask);This is ostensibly supposed to be the Unix format code for a 64-bit hex number, but it's not defined anywhere in the program. Could it be in a standard header file? I have to change it to 256-bit (4 64-bit format codes strung together) because I wound up having to increase the DP size to 256 bits as well because I didn't feel like having ANOTHER field just for a truncated lowest-64 bits of the kangaroo position, especially when said field is shoved inside Int.bits64[3] of a 128-bit kangaroo and all the code references that. There are 2 more occurrences of this which you can see with https://github.com/JeanLucPons/Kangaroo/search?q=PRIx64&type=Could you help to fork update to version 256bit (for use up to #160 puzzle)? may be work better than limited to fit 120 bits JeanLucPons still on forum, Can possible to update? or may be limited because of have some problem technic when use work with high bits or not? How can we know what happen with higher bits or large range ?
I'm currently working on increasing the maximum range - when that's done I'll release the code so you guys can test this for yourselves. I think he is trying to do that now |
|
|
|
if scan all it use a time too much
Depent of your speed, i made some calculations based on the speed, the time is for scan all the range in that bit space: Puzzle 120 @ 1 Terakeys/s : 21074771622667996 years
Puzzle 120 @ 1 Petakeys/s : 21074771622667 years
Puzzle 120 @ 1 Exakeys/s : 21074771622 years
Puzzle 120 @ 1 Zettakeys/s : 21074771 years
Puzzle 120 @ 1 Yottakeys/s : 21074 years
Puzzle 160 @ 1 Terakeys/s : 23171956451847141650870193314 years
Puzzle 160 @ 1 Petakeys/s : 23171956451847141650870193 years
Puzzle 160 @ 1 Exakeys/s : 23171956451847141650870 years
Puzzle 160 @ 1 Zettakeys/s : 23171956451847141650 years
Puzzle 160 @ 1 Yottakeys/s : 23171956451847141 years
Puzzle 256 @ 1 Terakeys/s : 1835871531540401373407708412745559168131740612197318060720 years
Puzzle 256 @ 1 Petakeys/s : 1835871531540401373407708412745559168131740612197318060 years
Puzzle 256 @ 1 Exakeys/s : 1835871531540401373407708412745559168131740612197318 years
Puzzle 256 @ 1 Zettakeys/s : 1835871531540401373407708412745559168131740612197 years
Puzzle 256 @ 1 Yottakeys/s : 1835871531540401373407708412745559168131740612 years
Is this speed based upon bitcrack or kangaroo? |
|
|
|
Everyone just about knows of that old version of kangaroo with python already. We are on the new version of kangaroo that uses distinguished points (DP) method now. |
|
|
|
hi there andzhig,
could you make it so it searches the address starting with 16 only or show and search only the 64th range with the same way
you already beautifully described and explained thanks a lot sir.
Maybe with vanitygen. |
|
|
|
Anyone have any idea use pubkey to calculate keyspace?
To do brute force all area of keyspace in range it is not good idea?
Kangaroo so far is the only way to calculate keyspace with pubkey. Brute forcing all area of the keyspace is a bad idea and a waste of time. Do you know about distinguished point (DP) method with kangaroo? |
|
|
|
now I try to looking way to reduce keyspace for search because high bits it is too much large area to search
if can fine right keyspace may be helpful to working search
Do you think you can try to look for a way to reduce keyspace search for kangaroo too? |
|
|
|
|
You don't brute force them, it will take too long to do. No you can't use an asic machine either.
|
|
|
|
2. What is the simple mathematical problem? Finding private key if someone reuse k value?
What is that? Is it similar to this: https://allprivatekeys.com/random-vulnerabilityThen don't worry. Last month I've checked all of bitcoin addresses for this and found like 1000 addresses with this vulnerability and only 3 with balances. All 3 <500 sats. So, you won't find anything new... Might as well go after addresses with exposed public keys then. |
|
|
|
for using Kangaroo.exe example puzzle 64 bits still very large
if using 8000000000000000 to fffffffffffffff may be too much large
but if use split rank to very small size example 8000000000000000 to 800000004190AB00 (and next each 10000000000000)
I test some address by using rank not so far from private key, Kangaroo work very fast.
What recommend for Kangaroo.exe search by fast?
No it wouldn't with kangaroo if the public key for #64 was exposed it would be 2^32 or 2^33 search range, can be solved in an hour or less. |
|
|
|
Hi, WanderingPhilospher or anyone reference with puzzle thread (update) https://bitcointalk.org/index.php?topic=5218972.0should be setup in.txt like this right? Done I do correct? publickey can be use both compressed and uncompressed right? in.txt 40000000 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE00 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 0233709EB11E0D4439A729F21C2C443DEDB727528229713F0065721BA8FA46F00E 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 02145D2611C823A396EF6712CE0F712F09B9B4F3135E3E0AA3230FB9B6D08D1E16 031F6A332D3C5C4F2DE2378C012F429CD109BA07D69690C6C701B6BB87860D6640 03AFDDA497369E219A2C1C369954A930E4D3740968E5E4352475BCFFCE3140DAE5 03137807790EA7DC6E97901C2BC87411F45ED74A5629315C4E4B03A0A102250C49 035CD1854CAE45391CA4EC428CC7E6C7D9984424B954209A8EEA197B9E364C05F6 02E0A8B039282FAF6FE0FD769CFBC4B6B4CF8758BA68220EAC420E32B91DDFA673 Yes, your setup is correct and you can use both compressed and uncompressed public keys. |
|
|
|
|
Show Posts
