Pollard's kangaroo ECDLP solver

[NotATether]

Question, i have say 1000 keys in my config, does it crack them all simultaneously?

Yes (if for loop iteration counts as simultaneous Only the GPU truly cracks the keys simultaneously up to a certain number at once)

Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?

Its currently

0
FFFFFFFFFFFFFFFFFFFFFFFFF

Yeah that looks about right, if it doesn't work, pad them with zeros on the left until they are 64 characters long each.

Sorry for the newbie questions, this is for a school project, so help would be appreciated.

  That's very cool, first time I saw one interested in discrete log solvers.

[Bobermart]

Question, i have say 1000 keys in my config, does it crack them all simultaneously?

Yes (if for loop iteration counts as simultaneous Only the GPU truly cracks the keys simultaneously up to a certain number at once)

Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?

Its currently

0
FFFFFFFFFFFFFFFFFFFFFFFFF

Yeah that looks about right, if it doesn't work, pad them with zeros on the left until they are 64 characters long each.

Sorry for the newbie questions, this is for a school project, so help would be appreciated.

  That's very cool, first time I saw one interested in discrete log solvers.

Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how  do i program it to crack that, or is it just automatic?

By using

0
FFFFFFFFFFFFFFFFFFFFFFFFF

will that check the entire keyspace of a standard 128bit key?

[fxsniper]

Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how  do i program it to crack that, or is it just automatic?

By using

0
FFFFFFFFFFFFFFFFFFFFFFFFF

will that check the entire keyspace of a standard 128bit key?

Can you code?

for very high 128bit key, or 256bit key you need to upgrade or find the way works better and smart than current kangaroo for reduce time use find key

now puzzle 120 bits keys still un solve

[NotATether]

Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how  do i program it to crack that, or is it just automatic?

By using

0
FFFFFFFFFFFFFFFFFFFFFFFFF

will that check the entire keyspace of a standard 128bit key?

The size to search in (and the keys which can be cracked) is determined by (end range - start range), second - first line.

Any range bigger than 125 bits currently isn't possible. The range variable itself has 126 bits free but there is some operation I can't recall right now that's done on it which limits the range to 125 bits.

I'm working on a patch to fix this. I have no ETA for it though, but I would like to get it ready within a week or two.


EDIT: Wheee, I have to play GPU availability roulette again, this sucks 

[Bobermart]

Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how  do i program it to crack that, or is it just automatic?

By using

0
FFFFFFFFFFFFFFFFFFFFFFFFF

will that check the entire keyspace of a standard 128bit key?

The size to search in (and the keys which can be cracked) is determined by (end range - start range), second - first line.

Any range bigger than 125 bits currently isn't possible. The range variable itself has 126 bits free but there is some operation I can't recall right now that's done on it which limits the range to 125 bits.

I'm working on a patch to fix this. I have no ETA for it though, but I would like to get it ready within a week or two.

Excellent! i look forward to this, i would donate for this.


So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?

[NotATether]

So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?

I am not aware of any wallet software (Bitcoin Core or otherwise) that used anything other than 256-bit keys.

At one point in time, people made private keys out of so called "brain wallets" which are just random strings SHA256'ed into a hash that generated public and private keys. [Some people even used public base58 addresses as input to SHA256.]

[WanderingPhilospher]

Question, i have say 1000 keys in my config, does it crack them all simultaneously?

Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?

Its currently

0
FFFFFFFFFFFFFFFFFFFFFFFFF




Sorry for the newbie questions, this is for a school project, so help would be appreciated.

If you have 1000 keys in your input file, and you don't know if they exist in the range or not, you will have to use the -m option or the program will search for the first key from now until infinity times infinity...

[fxsniper]

So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?

I am not aware of any wallet software (Bitcoin Core or otherwise) that used anything other than 256-bit keys.

At one point in time, people made private keys out of so called "brain wallets" which are just random strings SHA256'ed into a hash that generated public and private keys. [Some people even used public base58 addresses as input to SHA256.]

Right
and I try already  bitcoin original  from alpha version  bitcoin-nov08.tgz bitcoin-0.1.0.rar bitcoin-0.1.3.rar

all are 256 bits from 2009  (2008 develop) everything 256 bits

very good for over thinking bitcoin address

if develop fit use, may be bitcoin are hack done already

all real money bitcoin use 256 bit

have only Brainwallet have problem for human crack

[CrunchyF]

Hello everybody,

I am newly interested in the resolution of puzzle # 120 (119 bits private key)
pubkey : 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 (hash 160: 17s2b9ksz5y7abUm92PCTzK8jEl5y7abUm92PCTzK8jEl5y7abUm92cHZK8jElc).
a short calculation shows the difficulty of it with the excellent (probably the most optimised) GPU  solver from Jean-Luc Pons.


n=2*sqrt(0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFF-0x40000000000000000000000000000)

best_GPU_card_speed=4*10**9 #(I read that RTX3090 can achieve around 4Giga Keys /s with Kangaroo ECDLP SOLVER)
excepted_days=n/best_GPU_card_power/86400

so ... around 833 excepted days! 

if u consider a rent of gpu cloud at the minimal price (around 1000$ per week for 8x3090) u can expected to resolve it in 100 days (about 15 weeks)
15*1000=15000$ (very rentable in comparison of 60000$/BTC market price) (1.2*60000 72000$ on wallet) 

But u forget that
-that someone else can be faster than u,
-u can be unlucky because the Kangaroo Lambda algorithm is a probabilistic algorithm.
-Bitcoin price can dip while u are in!

Are my calculation are correct?

Have u heard of an implementation of SEC256K1 addition on FPGA or ASIC (ASIC miner have only optimised implementation for sha256)?

Regards

Fanch

[BASE16]

Have u heard of an implementation of SEC256K1 addition on FPGA or ASIC (ASIC miner have only optimised implementation for sha256)?

Regards

Fanch

ASIC == Application Specific Integrated Circuit.

It's baked specifically for one task (SHA256) and can not be easily made to do something else.

Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how  do i program it to crack that, or is it just automatic?

By using

0
FFFFFFFFFFFFFFFFFFFFFFFFF

will that check the entire keyspace of a standard 128bit key?

You can do zero padding like this: 000000000000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFF

But realize that it's a large number: 1267650600228229401496703205375

[_Counselor]

Are my calculation are correct?

To solve #120 you need about 2^60.5 group operations.
If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve.
2^28.5 seconds is ~4393 days
4393 days / 8 GPUs = ~549 days to solve.

There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)

[CrunchyF]

To solve #120 you need about 2^60.5 group operations.
If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve.
2^28.5 seconds is ~4393 days
4393 days / 8 GPUs = ~549 days to solve.

There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)

Ok thanks for the correction so the average cost will be

549/7 *1000 about 78000 $ (not profitable ;( )

ASIC == Application Specific Integrated Circuit.

It's baked specifically for one task (SHA256) and can not be easily made to do something else.

Yes I know that but i want to know if it feasible to develop such of "specific circuit" by a man or in team in is garage ( )for a relative low cost  ?

this study gives diagrams for implementing SECP256K1 addition/multiplication/modular inversion on 256bits integers on a FPGA.

https://cse.iitkgp.ac.in/~debdeep/osscrypto/psec/downloads/PSEC-KEM_prime.pdf

But i dont know what sort of performance it can have on FPGA (op/s) ?
If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU??
Maybe is it possible to "convert" this diagram to develop an ASIC.?

[BASE16]

To solve #120 you need about 2^60.5 group operations.
If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve.
2^28.5 seconds is ~4393 days
4393 days / 8 GPUs = ~549 days to solve.

There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)

Ok thanks for the correction so the average cost will be

549/7 *1000 about 78000 $ (not profitable ;( )

ASIC == Application Specific Integrated Circuit.

It's baked specifically for one task (SHA256) and can not be easily made to do something else.

Yes I know that but i want to know if it feasible to develop such of "specific circuit" by a man or in team in is garage ( )for a relative low cost  ?

this study gives diagrams for implementing SECP256K1 addition/multiplication/modular inversion on 256bits integers on a FPGA.

https://cse.iitkgp.ac.in/~debdeep/osscrypto/psec/downloads/PSEC-KEM_prime.pdf

But i dont know what sort of performance it can have on FPGA (op/s) ?
If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU??
Maybe is it possible to "convert" this diagram to develop an ASIC.?

Maybe you can look at it from a different angle then trying to use the same concept that is used for mining and the use of ASIC/FPGA for these tasks.
It does not have to be 256 bit integers, it only has to be 256 bit integers if you are trying to travel to your public point that belongs to your known 256 bit private key.
You will visit a lot of intermediate points, which all correspond to valid bitcoin addresses on your way to bit 256.
It's possible that you visited some point/address at for example bit 122 that had 100 BTC in it, but you will never know it if you don't look for it and just skip it and discard the data.
But make sure that you understand that the nearest public point, if you are not trying to solve a known 256 bit key, is not 256 bits away but just one bit away since it is K+1 or Q+1G.
So that is 1 bit and not 256 bits.
Make sure you understand this so that you can use it to optimize your ideas, when it comes to collisions it can also be modified from SECP256K1 to SECP1K1 so realize that its not always 256 or an average of 128 point calculations there is a difference between talking about a specific point, and talking about any point.
A specific point will need to go through the entire loop of 256 bits, but any point is just any point on which you can throw any number of *G's.
For example if the (first) last bit of your private key is a 1 then this will rule out the entire key space below that number and it's only one step to get into that range, not 256 or 128.

[Stroncow]

I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?

[_Counselor]

I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?

This is impossible, all known ECDLP algorithms works with public key. Without knowing the public key, the only possible option to find out the private key is bruteforce.

[bigvito19]

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.

[CrunchyF]

Maybe you can look at it from a different angle then trying to use the same concept that is used for mining and the use of ASIC/FPGA for these tasks.
It does not have to be 256 bit integers, it only has to be 256 bit integers if you are trying to travel to your public point that belongs to your known 256 bit private key.
You will visit a lot of intermediate points, which all correspond to valid bitcoin addresses on your way to bit 256.
It's possible that you visited some point/address at for example bit 122 that had 100 BTC in it, but you will never know it if you don't look for it and just skip it and discard the data.
But make sure that you understand that the nearest public point, if you are not trying to solve a known 256 bit key, is not 256 bits away but just one bit away since it is K+1 or Q+1G.
So that is 1 bit and not 256 bits.
Make sure you understand this so that you can use it to optimize your ideas, when it comes to collisions it can also be modified from SECP256K1 to SECP1K1 so realize that its not always 256 or an average of 128 point calculations there is a difference between talking about a specific point, and talking about any point.
A specific point will need to go through the entire loop of 256 bits, but any point is just any point on which you can throw any number of *G's.
For example if the (first) last bit of your private key is a 1 then this will rule out the entire key space below that number and it's only one step to get into that range, not 256 or 128

Sorry but i'm not sure to fully understand what you said about bits (1 vs 256).
I understand about the kangaroo algorithm that it forces you to perform a group addition at every jumps of every kangaroo of the herd (wild or tame)
in affine coordinate you have to calculate the next jump with this function (whatever the range size)

X(i+1)=X(i)+deterministic_random_walk[G,2G,4G...]

m = (y1 - y2) * inverse_mod(x - xG,P)
xQ = pow(m,2,P) - x1 - xG
yQ = y1 + m * (xQ - x1)
Q = (xQ %P -yQ %P)

knowing that P is about 2^256, you cannot reduce the size of the integers used in this function
below 256bits because the result coordinate of point Q will be (about randomly) between
(x,y) = ([1 -- 2^256],[1 -- 2^256])
and u need all this information to compute the next point (whatever DP bits used)

it is this costly addition function that i want to implement in my hypothetical ASICs of FPGA's chips (parrellised).

Storing the X coordinates (masked with DP) of every jump  (calculate with the dedicated devices) in a hash table could be achieved with a centralized computer with a lot of ram.

[NotATether]

I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?

If any transaction has been made to the address then it's public key will be exposed on the blockchain and you can inspect it's value inside the public script using a block explorer.

If not, which is the case here, then it means that you're trying to solve an address with no bitcoins inside (a purely academic problem) and you need to use BitCrack instead, which does work with RIPEMD160.

But i dont know what sort of performance it can have on FPGA (op/s) ?
If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU??
Maybe is it possible to "convert" this diagram to develop an ASIC.?

AWS has some rentable FPGAs, but it'll be incredibly hard finding an FPGA developer.

knowing that P is about 2^256, you cannot reduce the size of the integers used in this function
below 256bits because the result coordinate of point Q will be (about randomly) between
(x,y) = ([1 -- 2^256],[1 -- 2^256])
and u need all this information to compute the next point (whatever DP bits used)

it is this costly addition function that i want to implement in my hypothetical ASICs of FPGA's chips (parrellised).

Storing the X coordinates (masked with DP) of every jump  (calculate with the dedicated devices) in a hash table could be achieved with a centralized computer with a lot of ram.

Fortunately the jump distance can be reduced to, well, as low as you want.

Part of the costly addition is deriving Y from X, which slows down the number of keys that can be solved. Given that nobody fills up their DP table it makes sense to cache Y as well in the DP table (which btw can be reduced to a vector if we stop using the entire lower qword of X as the dp  and also test its NOT in collision tests )

[CrunchyF]

AWS has some rentable FPGAs, but it'll be incredibly hard finding an FPGA developer.

Ok thanks i' don't know that, (amazon EC2 F1 on AWS)

I made some search about FPGA performance on secp256k1 operations.

https://github.com/ZcashFoundation/zcash-fpga/blob/master/zcash_fpga_design_doc_v1.4.2.pdf

this paper (from Zcash fondation) presents some benchmarks of a well optimised group operation on secp256k1 implementating on an AWS FPGA (Zcash has the same curve than bitcoin).

Point addition is "only" about (1.9M op/s).
maybe it is possible to optimise it for the kangaroo algorithm but we are far away from the Giga op / s with the latest GPU.

 

[NotATether]

Quick someone give me sample start and end range with public keys, I think my 256-bit extension mod is done but I need to test it.