Topic: Pollard's kangaroo ECDLP solver - page 70. (Read 60698 times)

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.

Seems like some good news pertaining with kangaroo.

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.

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?

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.

Ok thanks for the correction so the average cost will be

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


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

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)

ASIC == Application Specific Integrated Circuit.

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


You can do zero padding like this: 000000000000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFF

But realize that it's a large number: 1267650600228229401496703205375

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

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

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

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

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


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

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 

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

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?

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


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



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

recommend use sample file   puzzle32.txt

https://github.com/JeanLucPons/Kangaroo/blob/master/puzzle32.txt


more testing file

for longer test

puzzle #65  = 3-10 minute up to you CPU or GPU

command  puzzle65.bat

GPU

puzzle65.txt

capital same

try this

example puzzle #40


puzzle40.txt



command  puzzle40.bat


then check fiel   result40.txt

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.