Thank's Telariust!
It will take time but i could try to implement the kangaroo method myself in c#,
to learn if it would be possible to detect a parallelism for the average usage of sqr(2^(bit-2)) operations, when halfing x values of the searchspace,
unless you can confirm from your experience that there is no such behaviour detectable?

Currently it's just like you would guess in a keyspace of 1024 that the privatekey is greater than 512...
BUT...
If it is possible to find a privatekey less than 512 in less than 150% of sqr(2^(bit-1)) it should be an average overall speedgain.

My current idea to achieve that would be with the cost of an extra wild, when pushing the searchspace to point Infinity.
This wild point could just be the negation point of the orginal point without or with offset.
Cause i don't see ECPoint subtraction implemented in your script, you can use addition:
therefore the ECPoint offset calculation to wrap the space arround Infinity should be G.Multiply(ORDER-SpaceL-(SpaceL/2)).

Thank's

Yes, this was my point.
I first thought that there is a parallel behaviour, cause the script was finding the publickey when changing y value only, and we could use it to only make sqr(2^(bit-2)) operations,
unitil i found a completely different pubkey from another space.
You don't have to set from 8:... bitspace it also works with orginal keyspace

It's not a bug i guess...i am cleary not an expert in this matter , but that's what i think:
It seems logical, it will just take longer on average to find the key.
The average jumpsize should be calculated from the searchspace.
When you search for exampe puplic key from 37 bit within 40 bit the average jumpsize should be bigger and the opposite when searching 43bit pubkey within  40 bit.

It's strange, that when you change only the y value of the key, you will find the orginal publickey with privatekey, but not the one you changed.

seems like you need to change your settings too

I deleted my posts to avoid any confusions.

Now i better understand how kangaroo jumping works, i didn't even know that it is possible to find a publickey which is not in the space we are searching for.
That's why it finds the publickey when you just change Y.
I thought that when a tame kangaroo jumps out of space, a new tame and wild kangaroo would be set within the space to start jumping again.

As my suggestion, it would be the same if you just set the searchspace for from 2^(bit-1) > (2^(bit)-1) to (2^(bit-1) + 2^(bit-2)) > (2(bit)-1).
You would have a 50% chance to find the key in sqr(2^(bit-2)).
In my tests it must have been luck to find the keys not in that 50%chance in less time than average.
The only benefit i see by pushing the space with the middle to Infinity point, would be if a X value match could be detected when a wildkangaroo starts in negative mirrored space. That would possible be a rarely case by the time it catches up to the positive space where all tame kangaroos would start.

Exactly that was the plan > wraping the space W with the middle of the space to point infinity.
So that actually all x values get halfed.
I thought possibly that when a wild kangaroo jumps, a jump from the tame kangaroo in the negative space in the different direction could also lead to the same result in less time(cause it would be the same distance).
The key is definitely to find in the space(bit-2), however if you say regarding the kangaroo method, that there is no speed gain, the method is useless.
i have to test #35. i would not understand if the key is not findable. like #50 if the key is on the negative side it will find the privatekey and publickey on the positiv side,there will be just no publickey match> Watch it in the console im not sure if gets to the result.txt
Thanks for testing!  

Here is another example of #40

#40 sqr(2^(bit-1))
python pollard-kangaroo-multi.py 40
//privkey = 1003651412950


#40 sqr(2^(bit-2))
python pollard-kangaroo-multi.py 8:3FFFFFFFFF 028dfd0e801ed8d495b6a0b68b38fba4f32d7423af363c717cca6c2ebd1e11a399
//privkey = 179017692118

Addfactor: 824633720832
//result1 = 1003651412950 true

i changed the settings to allow newbie messages

The publickeys for #64 and #66 are not revealed. There has to be an outgoing transaction to be able to get the publickey.
We only have the public keys of numbers ending with 5 and 0.

1. Create ECPoint "p" from 03f46f41027bbf44fafd6b059091b900dad41e6845b2241dc3254c7cdd3c5a16c6
2. Calculate subtraction space "sub"= (2^(bit-1)) + (2^(bit-2));
3. Create ECPoint from sub "subP" = G.Multiply(sub);
4. Create ECPoint new "newP" = p.Subtract(subP);
5. Create compressed publicKey string "newPK" = newP.GetEncoded(True).ToString();
6. Calculate your "newkeySpaceU" value = (2^(bit-2))-1
7. Convert newkeySpaceU from decimal to hexadecimal string= newKeySpace.ToString("X");
8. Use pollard-kangaroo-multi.py 8:newkeySpaceU newPubkey
    (Correctly keySpace L should be always 0, by default 8 is minimum)
9. Convert your result prvkey output from hexadecimal to BigInteger "res"
10.Calculate "offset1" = res + sub and calculate "offset2" = ((Order -res) + sub)%Order
11. Generate new ECPOINT "offset1P" and "offset2P" = G.Multiply(offset1) and G.Multiply(offset2)
12. Compare "offset1P" to "p" = if(p.Equals(offset1P)) offset1 is my prvkey; else offset2 is my privkey
 

The idea is of course to only make sqr(2^(bit-2)) operations.

for #50:

python pollard-kangaroo-multi.py 50 03f46f41027bbf44fafd6b059091b900dad41e6845b2241dc3254c7cdd3c5a16c6

should be equivalent to

python pollard-kangaroo-multi.py  8:FFFFFFFFFFFF 02bc9d041a4839d3bef61e319cd02d3b177292ccb79ed27c1bf6043ab0ec635bfd

(8 is by default minimum bit using pollard-kangaroo-multi.py)

edit: sorry was the wrong pubkey for #50 in first place

I posted a solution to test in BurtW's thread.
If there are no concerns regarding the Pollard Kangaroo method and they confirm it, i will post the new table with publickeys to search for in this thread.

Hi there,
i always thought the puzzle transaction was made by LBC, actually came here cause i saw some publickeys where revealed.
Congrats to #105! Seems like 57fe is winning the race.
Can we expect from 57fe and j2002ba2 that they share their scripts involving GPU ECPoint math when #110 or #115 is found?

I'm impressed how fast the kangaroo method is, tested the python script from 57fe, the modified multicore from Telariust and read BurtW c#.
As a c# developer i was playing a lot with eliptic curve points, when i wanted to learn about bitcoin and about it's security.
Back then i never thought about the the security when you would know that a public key is in a specific space...

I developed a method the last day which is easy to implement within your scripts and halfs the searchtime per space.
Looking forward to post it in BurtW's thread later if somebody is interested.
if the table from j2002ba2 is correct using 4x V100:
#110 > 90 days > 45 days
#115 > 1 year  147 days > 256 days

What i don't understand is why the creator of the puzzle revealed the publickeys to +5 from 2^160...
Correctly there should be 161 to 255 also rewarded when dealing with such.