Yes you're right. I will fix this.
Thanks for the useful work, I will take your mods (work on windows ?) and apd it to the official release.

ok thanks.
Note that the count in the work files are inaccurate due to the counting granularity especially when using GPUs.
The good value to take in consideration is the DP count and the total number of iteration is ~DPcount*2^dpbit if all work files that has been merged have the same dpbit.

no or 0x01...0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

You can do without shifting, the shift is done only once at the beginning. Of course, if in one case you shit and in one case you do no shift all will be incompatible.

Anyway, I'm working on the merger to reduce memory consumption.
I added the plot of probability of success:

The plot does not take into consideration the DP overhead.
In his first try, zielar had a setup which create a very large overhead (too much kangaroos). An overhead more than 2 times bigger than the expected number of op, so he didn't manage to get something.
I helped him a bit yesterday to have a clean setup.
If all is going well, he will reach 50% probability Saturday evening (UTC+2).
Unfortunately no news from him since yesterday

Yes, right. There is a trade-off between time and memory. Zielar said he had enough memory.
Due to overhead the graph should be shifted to the right.

Jean_Luc, by the way, i read one article and it leads to twitter of a guy trying to brute the specific range. The article says he is bruteforcing all the bitcoin wallets, however as i read his tweet and saw the screenshot - I found your GPU solver. It is absolutely your program (Count, Deads and SaveWork). And he is running kangaroos for the specific range, probably #110 

EDIT:
https://twitter.com/MasterChangz/status/1264653806916124672

The program shifts the range to 0, and also shifts the Public Key.

Example for puzzle key #110:
We know that public key is (pk110): 0309976ba5570966bf889196b7fdf5a0f9a1e9ab340556ec29f8bb60599616167d
And we also know that it is in the range [2^109 ... 2^110-1]

The GPU Solver shifts the range by 2^109 to the left, and making the search in the range [2^109 - 2^109 ... 2^110-1 - 2^109] which is [0 ... 2^109 - 1]
So, all the tames are generated within this range from 0 to 2^109-1.

As for wilds, they are generated not from the original public key pk110, but from another point: pk110 - 2^109 * G
This shifted point is pk110s: 02e2cec18b0aa6c9fe69f2dfd7b253594957a1840a3506cb17b4d80d1bd8c37d25

All the DPs in hashtable are within the range [0 ... 2^109-1]: for tame with have distance Td in this range and x-coordinate related to it, for wild we have distance Wd which is +/- [0 ... 2^108] and x-coordinate related to pk110s + Wd * G
All the wild points in hash table are also related to the shifted public key.

PS. Actually instead of solving pk110 within the range [2^109 ... 2^110-1] the program solves the key pk110s within the range [0 ... 2^109-1]

Because the Tame Kangaroos are dependent only on the interval size, while the Wild Kangaroos are dependent on the interval size and the public key. We want to keep the algorithm as generic as possible, and also the ability to reuse the Tame Kangaroos for multiple key searches.

As relating to the Wild Kangaroos, [working_public_key] = [(original_public_key) - (beginning_range)*(secp256k1_generator_point)].
[distinguished_point] = [(+-traveled_distance)*(secp256k1_generator_point)] + [working_public key]

You will need to add back the (beginning_range) when there’s a collision to solve for the (original_public_key).

Can you help make it clear to me

So the tames work from range 0...meaning 0x0 to 0x3FFFFFFFFFFFFFFFFFFFFFFFFFFFF  (for pubkey 110)?