@JeanLuc can you explain structure DP that send client to server
Each DP has 40 bytes length.

Edit: solved int128_t X;      int128_t D;      uint64_t h;
It is not easy))

dp.h - it is 18bit hash(hope i think correct)
dp.x and dp.d - it is understand for what
but for what need dp.kIdx when sending DP?

DP count is most important. You are running at DP 25, so it will take 2^57 (whatever expected group ops is for 115) - 2^25 (your DP setting) so roughly you want your DP count up to 2^32 to be getting close to solving.

I have files for DP 30.  So I need to get close to 2^27 to be getting close to solving. 2^57(expected ops) - 2^30(my DP setting) = 2^27 DP count .

Doing some tests with your job :
~780MKs on 2060 ( core +120, PL60 )
~950MKs on 2070 ( core +120, PL60 )

Only needed few changes in my tool to run your version, thanks !

You think so? I was using the math that was explained to me...I'm not an expert like some here, but I've seen it been said that way several times.
How long say you, or better yet, how many DPs do I need? 2^what?

@WanderingPhilospher

what happens when I want to merge dp30 files and dp 25 file it takes only the lower dp or not?

if you have 5 DPs=31 and 4 DPs=25 when merge you will get 9 DPs=25.(ofcourse if points different)
in this case droping from 31 to 25 you will need again find 64 times more new points (2^(31-25))

Ygrid is the second coordinate of the GPU thread array.
It affects performance. This is very useful for linear algebra because you can use thread coordinates to make fast matrix calculus.
In our case, this is just used to tune performance.

I was in weekend, Yesterday was also a day off in France, I restart the work today. I also have professional work to perform but I will continue to make update on github when I can for everybody. I will try to integrate ASAP the mods from  PatatasFritas and the support of -ws for the client mode. News from AndrewBrz who is progressing well with the OpenCL kernel.

Zielar solved #110 with official 1.8 and 1.9alpha for merging.

Thanks.


There is a way to reuse the same DP's set in a different range.

If you have DPs in range [1,...,2^109] and you need DPs in [1,...,2^114], it is enough to

transform [1, ..., 2^114] into [1/32, 2*1/32, 3*1/32, ....,  2^114 *1 32 = 2^109] (a 'contraction')

where 1/32 means 32^-1 mod N. There are always 2^114 elements,  and the public key P becomes P'= 1/32 * P and lies in the same interval.

You can see [1/32, 2*1/32, 3*1/32, ....,  2^114 *1 32 = 2^109] as the set of the private keys respect of G,
or the same points set can be represented as [1,...,2^114]', the set of the private keys respect of G' = 1/32 * G

In this way the DPs are spread uniformly in the interval [1, ..., 2^114]'. The private key of each DP respect of G' is the previous private key * 32.

You have to modify the jumps too, instead of +r*G you have to perform +r*G', where G' = (1/32) * G.

Then you will find the private key k' of P' respect of G', that is the same private key k of P respect of G.

Basically so far we have used only the 'translation' of the interval, but we can use a 'expansion/contraction' too.

That 2^27 figure assumes the average walk length is 2^30. The GPU works by doing many slow walks in parallel e.g. 60 million walks that do 20 iterations per second. At that rate, it will take 2^30 20 seconds = 1.7 years before any of the walks are 2^30. Your DP count is going to be a few powers of 2 higher than 27.

This is impossible. Kangaroo works with elliptic curve operations (ECDSA) and no need to hash anything.
ASIC was designed for hash calculations. ASIC works only with algorithms designed by the producer: SHA-256, Scrypt, Cryptonight, Ethash, Blake, X11. Different models have different set of algorithms.

For Kangaroo algorithm only the elliptic curve operations are required (i.e. transformation of the private key to the public key, operations with the points such as additions, subtractions and multiplications). ASICS does not support it.