hi there zielar, was and guess we are all waiting for your exact statistics,
and was wondering could we enable some more stats inside kangaroo like current sampled or checked collisions,
at long waiting times these could help maybe somewhat to skip time, like smilies or so or a percentage counter,
or anything extra then current like some advancement inside kang. would be delightfull.
greets.
Topic: Pollard's kangaroo ECDLP solver - page 98. (Read 55599 times)
-snip-
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
Did you implement the feedback from server to clients? If no - that means that the clients continue to perform "useless work" moving the dead "zombi" kangaroos:
If you have let's say 100 different machines working independent, you reproduce only the dead kangaroos found within one machine only (machine 1 reproduce dead kangaroos only found by itself). After merging all these 100 files on the server, the server finds a lot of dead kangaroos however does not send back signal to clients to reproduce them. Clients continue working with that "zombi" because they do not have feedback from the server. That also means that during the next merging the server will receive again the same kangaroos, the server will kill them again, but the "zombies" will continue their jumps on client side. And so on.
This could cause the very inefficient work for wider ranges like #115 or more.
I don't have any implementations that are not in the latest version of Kangaroo. As a curiosity I will add that so far - I still have NO dead kangaroos!
-snip-
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
Did you implement the feedback from server to clients? If no - that means that the clients continue to perform "useless work" moving the dead "zombi" kangaroos:
If you have let's say 100 different machines working independent, you reproduce only the dead kangaroos found within one machine only (machine 1 reproduce dead kangaroos only found by itself). After merging all these 100 files on the server, the server finds a lot of dead kangaroos however does not send back signal to clients to reproduce them. Clients continue working with that "zombi" because they do not have feedback from the server. That also means that during the next merging the server will receive again the same kangaroos, the server will kill them again, but the "zombies" will continue their jumps on client side. And so on.
This could cause the very inefficient work for wider ranges like #115 or more.
range
anyway they had agreemnet, and cant think beyond thier creation+GPU's
-snip-
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
Did you implement the feedback from server to clients? If no - that means that the clients continue to perform "useless work" moving the dead "zombi" kangaroos:
If you have let's say 100 different machines working independent, you reproduce only the dead kangaroos found within one machine only (machine 1 reproduce dead kangaroos only found by itself). After merging all these 100 files on the server, the server finds a lot of dead kangaroos however does not send back signal to clients to reproduce them. Clients continue working with that "zombi" because they do not have feedback from the server. That also means that during the next merging the server will receive again the same kangaroos, the server will kill them again, but the "zombies" will continue their jumps on client side. And so on.
This could cause the very inefficient work for wider ranges like #115 or more.
To recap (and to return in topic):
#115 -> 114 bit
steps needed to have 50% chance of a collision: about (114/2)+1 = 58 bit -> 2^58
DP = 25
steps performed: 2**25 * 2**33.14 = 2**58.14, then you are close to the result?
I expect a result at any time. You had to add ~ 5% tolerance limit due to inconsistency in ~ 00.05% files, so in my case from 2 ^ 33.167 gives 52%. I have already crossed 2 ^ 33.18 just so it is exactly as you wrote :-)
Any news?
It may take more time finding #115 than finding #120 ...
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
To recap (and to return in topic):
#115 -> 114 bit
steps needed to have 50% chance of a collision: about (114/2)+1 = 58 bit -> 2^58
DP = 25
steps performed: 2**25 * 2**33.14 = 2**58.14, then you are close to the result?
I expect a result at any time. You had to add ~ 5% tolerance limit due to inconsistency in ~ 00.05% files, so in my case from 2 ^ 33.167 gives 52%. I have already crossed 2 ^ 33.18 just so it is exactly as you wrote :-)
Any news?
It may take more time finding #115 than finding #120 ...
Quote from: WanderingPhilospher
[/quote
[/quote
A dead kangaroo means there was a collision inside the same herd, either two wilds or two tames collided. The program automatically replaces the dead kangaroo with another kangaroo. so no worries.
Thank you for your reply. How to use this information - about dead kangaroo ? I have only 1 pubkey from 10 with kabgaroo - dead kangaroo ? And I was stop calclulation pubkey with dead kangaroo because max operation count was max.
What i need to do for pubey with dead kangaroo ? - make more bytes search range or ? ? ?
Thx.
1 dead kangaroo is nothing, really.
If pubkey isn't in the range you were searching, then yes, I'd search a different range. If it's a small enough range, use BSGS to make sure the pubkey isn't in the range.
Quote from: WanderingPhilospher
[/quote
[/quote
A dead kangaroo means there was a collision inside the same herd, either two wilds or two tames collided. The program automatically replaces the dead kangaroo with another kangaroo. so no worries.
Thank you for your reply. How to use this information - about dead kangaroo ? I have only 1 pubkey from 10 with kabgaroo - dead kangaroo ? And I was stop calclulation pubkey with dead kangaroo because max operation count was max.
What i need to do for pubey with dead kangaroo ? - make more bytes search range or ? ? ?
Thx.
Thanks for the help. I was able to compile a file for your clients. The program helped fix the extension as needed bat and txt. I started it after 3 minutes at 1050 and got an answer in 65save.txt, but I could not read everything there in hieroglyphs. Help explain how further please.
download and install emeditorright click file and open with emeditor, there is all option and format for open file
Thanks for the help. I was able to compile a file for your clients. The program helped fix the extension as needed bat and txt. I started it after 3 minutes at 1050 and got an answer in 65save.txt, but I could not read everything there in hieroglyphs. Help explain how further please.
Hello everybody! I have a question? On Windows7, the 65save.txt file opens and there are hieroglyphs. Is this a file with save.work right? On Windows7, everyone has a file that opens with hieroglyphs. I tried to open the file with different programs with transcoding, the result is incomprehensible. If you have Windows 10 there are no such problems? And does the Kangaroo.exe program work differently? If there are Russian-speaking users, dismount [email protected]. I sorted it out in mining on my 1050Ti, but here it’s kind of complicated on Windows7 so far.
These are files that are written and recognized by the program that created them. You can see the same hieroglyphs by opening e.g. a picture or music in a notepad.
Hello everybody! I have a question? On Windows7, the 65save.txt file opens and there are hieroglyphs. Is this a file with save.work right? On Windows7, everyone has a file that opens with hieroglyphs. I tried to open the file with different programs with transcoding, the result is incomprehensible. If you have Windows 10 there are no such problems? And does the Kangaroo.exe program work differently? If there are Russian-speaking users, dismount [email protected]. I sorted it out in mining on my 1050Ti, but here it’s kind of complicated on Windows7 so far.
Help someone. Kangaroo not found dead kangaroo and privkeys. Were is a problem ? What can help to fined privkey ? In 10 pubkeys I have one with dead kangaroo ? Pubkey with dead kandagoo moree good then pubkey without kangaroo ? What to do 
?
Thx
A dead kangaroo means there was a collision inside the same herd, either two wilds or two tames collided. The program automatically replaces the dead kangaroo with another kangaroo. so no worries. ?Thx
Help someone. Kangaroo not found dead kangaroo and privkeys. Were is a problem ? What can help to fined privkey ? In 10 pubkeys I have one with dead kangaroo ? Pubkey with dead kandagoo moree good then pubkey without kangaroo ? What to do ?
Thx
?Thx
-snip-
mean 789.789 is value can u div pubkey by above value ?
Can`t and nobody can`t. devider must be integer not float. all pubkeys Q=k*G, where k - integer.mean 789.789 is value can u div pubkey by above value ?
Sorry for continuing an off topic discussion, but:
Of course you can divide by 789.789 if you want.
because 789.789=789789/1000 , which doesn't have decimals in it AND you can divide and multiply by scalar numbers.
Don't know why would anyone want to divide by 789.789, but it s possible
Sorry. Move talk about calculator to enother thread !!!
-snip-
mean 789.789 is value can u div pubkey by above value ?
Can`t and nobody can`t. devider must be integer not float. all pubkeys Q=k*G, where k - integer.mean 789.789 is value can u div pubkey by above value ?
Sorry for continuing an off topic discussion, but:
Of course you can divide by 789.789 if you want.
because 789.789=789789/1000 , which doesn't have decimals in it AND you can divide and multiply by scalar numbers.
Don't know why would anyone want to divide by 789.789, but it s possible
@mrxtraf
In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
That is, you can’t divide the public key by 10?In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
Give me any public key from which you know the private key, I will divide it by 10. And I will give in return the result in the form of a public key. And you yourself divide the private key by 10, get the public key from it and compare.
The multiplication (and division, which is multiplication with the inverse) is by scalar only. You cannot multiply two public keys without solving ECDLP first. And if you somehow can, then all coins are belong to you.
mrxtraf is saying they can "divide" the public key by 10 by multiplying the public key by the multiplicative inverse of 10 mod n.
apply your algo and show me pubkey div by 789 for
03D041CF467F485A96AB21EC0E1E1E26A344B28A12244320C4BDE48C123653D88F
Sure.
The inverse of 789 mod n = 90549707299650307447836879278023370272751301850683416988678562304583910826370
Multiply your public key by that and you get:
035776B3684B6A5E9A6307AA53C3D484AABB90244E6371405C114CF8910A9A3BD0
Multiplying that point by 789 will result in the original public key. In otherwords, 789 * 90549707299650307447836879278023370272751301850683416988678562304583910826370 = 1 (mod n).
Are you guys still discussing the off-topic things?
It was said several times, that there is no division for public points. Our brains want to visualize the division process and we only imagine integers. But group field works under different principles.
The only thing we can do - is to multiply by the inverse scalar. That's it. But we still just multiplying a public point by the integer number, and divide it.
For every integer x we can find inverse y which is such a number where x*y%order = 1, where order if the order of the group.
No inverse exist for 0, and for order itself.
Easy explanation for the group of 7 elements (let's say week days from Monday to Sunday):
If you multiply Wednesday by 4, you will receive Friday (3*4%7 = 12%7 = 5)
For division, we also make multiplication by the inverse scalar. Here is the list of inverse scalars for every number:
inverse(1) = 1
inverse(2) = 4
inverse(3) = 5
inverse(4) = 2
inverse(5) = 3
inverse(6) = 6
inverse(7) does not exist
Now if you want to "divide" Friday by 4, you should multiply it by inverse(4) = 2. So, we have 5*2%7 = 10%7 = 3
You can see that equation is correct as it was in the 1st example (where we multiplied Wednesday by 4).
You should never divide 5 by 4 and imagine number 1.25, and so on. It is not correct.
All the elements in the group is a wheel, and repeating after reaching the order.
So, if we divide some number x by k within the group with finite order, we are searching such a number y, which will give us x if we multiply it by k: y * k = x
In order to find it, we calculate inverse k'=(1/k), and make the multiplication: y = x * (1/k)
It was said several times, that there is no division for public points. Our brains want to visualize the division process and we only imagine integers. But group field works under different principles.
The only thing we can do - is to multiply by the inverse scalar. That's it. But we still just multiplying a public point by the integer number, and divide it.
For every integer x we can find inverse y which is such a number where x*y%order = 1, where order if the order of the group.
No inverse exist for 0, and for order itself.
Easy explanation for the group of 7 elements (let's say week days from Monday to Sunday):
If you multiply Wednesday by 4, you will receive Friday (3*4%7 = 12%7 = 5)
For division, we also make multiplication by the inverse scalar. Here is the list of inverse scalars for every number:
inverse(1) = 1
inverse(2) = 4
inverse(3) = 5
inverse(4) = 2
inverse(5) = 3
inverse(6) = 6
inverse(7) does not exist
Now if you want to "divide" Friday by 4, you should multiply it by inverse(4) = 2. So, we have 5*2%7 = 10%7 = 3
You can see that equation is correct as it was in the 1st example (where we multiplied Wednesday by 4).
You should never divide 5 by 4 and imagine number 1.25, and so on. It is not correct.
All the elements in the group is a wheel, and repeating after reaching the order.
So, if we divide some number x by k within the group with finite order, we are searching such a number y, which will give us x if we multiply it by k: y * k = x
In order to find it, we calculate inverse k'=(1/k), and make the multiplication: y = x * (1/k)
-snip-
so each and every digit have value, and i can div them in integar and float too actual low then 1 is called is fractional point,and i can play with each and every point
each representation K like positive or negative or fraction is allways positive integer from 1 to n.so each and every digit have value, and i can div them in integar and float too actual low then 1 is called is fractional point,and i can play with each and every point
if you say me positive integer representation of 789.789 i can easy devide any pub key by this valus. Here no problem to do this.
Like two fingers on the asphalt.
K * 1000 = NK
f(NK / 1000) = MK
-snip-
so each and every digit have value, and i can div them in integar and float too actual low then 1 is called is fractional point,and i can play with each and every point
each representation K like positive or negative or fraction is allways positive integer from 1 to n.so each and every digit have value, and i can div them in integar and float too actual low then 1 is called is fractional point,and i can play with each and every point
if you say me positive integer representation of 789.789 i can easy devide any pub key by this valus. Here no problem to do this.
Jump to: