Search content
Sort by
Showing 16 of 16 results by atom13
Its easyer to find a Bitcoin Block 
than finding the key here.
than finding the key here.Yes you can try with your 50Mkeys/s
60516 MKeys/s
⭐ Merited by stwenhao (1)
Its easyer to find a Bitcoin Block than finding the key here.
than finding the key here.I have reviewed your code, and I must say I am truly impressed. Your approach is fundamentally different from anything I have seen before. I am a developer myself, but your code seems more like the work of a mathematician, a physicist – or simply an extraordinary talent, a genius, or a scientist.
What impresses me the most is its efficiency: Despite my own optimization attempts, I have never been able to achieve 12.8 GKeys/s on an RTX 4090. And what astonishes me even more – I could not find any references to your method in existing literature or research.
May I ask how you came up with this remarkable approach?
Currently I have about 12.8GKeys/s on 4090. 5090 is a shame, I skip it and wait for next generation.
Perhaps I will make all my sources public when #135 is solved, though I'm not sure, people are not interested in what I do, also I see zero good discussions on this forum about EC, so better I will spend my time for more interesting things
What impresses me the most is its efficiency: Despite my own optimization attempts, I have never been able to achieve 12.8 GKeys/s on an RTX 4090. And what astonishes me even more – I could not find any references to your method in existing literature or research.
May I ask how you came up with this remarkable approach?
Currently I have about 12.8GKeys/s on 4090. 5090 is a shame, I skip it and wait for next generation.
Perhaps I will make all my sources public when #135 is solved, though I'm not sure, people are not interested in what I do, also I see zero good discussions on this forum about EC, so better I will spend my time for more interesting things
I have reviewed your code, and I must say I am truly impressed. Your approach is fundamentally different from anything I have seen before. I am a developer myself, but your code seems more like the work of a mathematician, a physicist – or simply an extraordinary talent, a genius, or a scientist.
What impresses me the most is its efficiency: Despite my own optimization attempts, I have never been able to achieve 12.8 GKeys/s on an RTX 4090. And what astonishes me even more – I could not find any references to your method in existing literature or research.
May I ask how you came up with this remarkable approach?
Currently I have about 12.8GKeys/s on 4090. 5090 is a shame, I skip it and wait for next generation.
Perhaps I will make all my sources public when #135 is solved, though I'm not sure, people are not interested in what I do, also I see zero good discussions on this forum about EC, so better I will spend my time for more interesting things
What impresses me the most is its efficiency: Despite my own optimization attempts, I have never been able to achieve 12.8 GKeys/s on an RTX 4090. And what astonishes me even more – I could not find any references to your method in existing literature or research.
May I ask how you came up with this remarkable approach?
Thank you for taking time to respond!
While I do admire that you had the skills and resources to break three ECDLP problems in a row, judging by your expertise you know very well that everything is a tradeoff when it comes to programming. I still stand by all my previous comments regarding this: cycle handling slows down the jumps. Another way to view this is: even with a very fast optimized cycle-handling kernel such as yours (much faster than some whatever JLP reference fork), it can be made to run faster if we trade the resources for cycle handling to enabling more jumps. The question at the end of the day is: from what point on is it worth it to either have low "K" with slow jumps, or a higher "K" with faster jumps. And yes, I did manage to reach 13.4 G/s on a RTX 5090 without even compiling natively to ccap 12.0, so the question is even more interesting now.
I was more interested about one of your older replies, regarding the fact that an optimized version is not even twice as fast as RCKang, which hinted that maybe somehow you managed to reach 14 Go/s on a RTX 4090, which would have been fascinating, considering that the public version can't reach 8 G/s.
While I do admire that you had the skills and resources to break three ECDLP problems in a row, judging by your expertise you know very well that everything is a tradeoff when it comes to programming. I still stand by all my previous comments regarding this: cycle handling slows down the jumps. Another way to view this is: even with a very fast optimized cycle-handling kernel such as yours (much faster than some whatever JLP reference fork), it can be made to run faster if we trade the resources for cycle handling to enabling more jumps. The question at the end of the day is: from what point on is it worth it to either have low "K" with slow jumps, or a higher "K" with faster jumps. And yes, I did manage to reach 13.4 G/s on a RTX 5090 without even compiling natively to ccap 12.0, so the question is even more interesting now.
I was more interested about one of your older replies, regarding the fact that an optimized version is not even twice as fast as RCKang, which hinted that maybe somehow you managed to reach 14 Go/s on a RTX 4090, which would have been fascinating, considering that the public version can't reach 8 G/s.
Currently I have about 12.8GKeys/s on 4090. 5090 is a shame, I skip it and wait for next generation.
Perhaps I will make all my sources public when #135 is solved, though I'm not sure, people are not interested in what I do, also I see zero good discussions on this forum about EC, so better I will spend my time for more interesting things
Hello, I previously asked you a question about adding the -end search range function, you answered me why you are not satisfied with -range .. I will answer why if I am looking for a 130 puzzle, then -range 84 will search where the zeros are in this example -dp 16 -range 84 -start 33e7665705350000000000000000000000 but nothing more right?) and what I mean is that with the -end function I can break the same 135 puzzle into a dozen or a hundred pieces and search throughout -range 134 but with short distances as an example -range 134 -start 6d9999999999999999999999999999996 -end 7ffffffffffffffffffffffffffff I can calculate the work here, let’s say that I would go through one path in one day and the next day start another path, but only with the start I can’t do this because I don’t know where this path ended if I turn off the program in other words, -end is needed so that you can start with it later) but with -range this is not possible
Your idea sounds senseless for me, but anyway it's open-source so you can modify sources and implement all ideas you have.
Can you confirm that you are using the code from Jean Luc here: https://github.com/JeanLucPons/Kangaroo ?
You can download both sources and compare, my code is not related to JLP's code.
I'm really interested, and for us beginners, it would be super helpful to have a detailed tutorial explaining how you set it up from start to finish
I won't write articles like "step-by-step guide how to crack #135", sorry
And by the way can you send me your BTC
Some people don´t understand how hard is this to crack
If after a jump I get second (cheap) point for almost free, I can calc K without this point.
Yes it's not 100% correct, but it's definitely better than counting it as 1op, showing almost twice speed at almost twice worse K.
But of course this assumption must be mentioned in the method description and I do it.
Also, it depends on a point of view: for example, if cheap point is used for vanity addresses generation, this point should be counted because it's used as a normal point. But for kangaroo jumps - this point should not be counted because only one point is used for next jump and only one point is calculated completely (both X and Y).
Yes it's not 100% correct, but it's definitely better than counting it as 1op, showing almost twice speed at almost twice worse K.
But of course this assumption must be mentioned in the method description and I do it.
Also, it depends on a point of view: for example, if cheap point is used for vanity addresses generation, this point should be counted because it's used as a normal point. But for kangaroo jumps - this point should not be counted because only one point is used for next jump and only one point is calculated completely (both X and Y).
I have a different question, how you transfer the BTC and protect it for the bots? Use you MARA or have you a different way?
Many thanks
Public keys were already known.
Also, best of luck to bots cracking >100-bit ranges before the block is confirmed
Okay you think they can´t cracking over 100 bit ranges? I read that someone stole bit 66 from the finder, thats only possible because is < 100 bit?
If after a jump I get second (cheap) point for almost free, I can calc K without this point.
Yes it's not 100% correct, but it's definitely better than counting it as 1op, showing almost twice speed at almost twice worse K.
But of course this assumption must be mentioned in the method description and I do it.
Also, it depends on a point of view: for example, if cheap point is used for vanity addresses generation, this point should be counted because it's used as a normal point. But for kangaroo jumps - this point should not be counted because only one point is used for next jump and only one point is calculated completely (both X and Y).
Yes it's not 100% correct, but it's definitely better than counting it as 1op, showing almost twice speed at almost twice worse K.
But of course this assumption must be mentioned in the method description and I do it.
Also, it depends on a point of view: for example, if cheap point is used for vanity addresses generation, this point should be counted because it's used as a normal point. But for kangaroo jumps - this point should not be counted because only one point is used for next jump and only one point is calculated completely (both X and Y).
I have a different question, how you transfer the BTC and protect it for the bots? Use you MARA or have you a different way?
Many thanks
I had time again and was able to continue taking tests.
I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
Please, it is better to send the command line you are / were using. That way someone can take a better look at everything. Maybe you forgot to use the correct subtract amount, wrong key, etc. Could be anything, could be nothing, but it's the first thing to look at.I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
Here is for Bit 85, i can´t find the key:
./rckangaroo -dp 16 -range 84 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
./rckangaroo -dp 16 -range 84 -start 11720c4f018d51b8000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
For Bit 70 i always find the key, doesn´t matter which -start i use (only two see below):
./rckangaroo -dp 16 -range 69 -start 200000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 100000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 300000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 340000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349B84B6431A6C4EF0 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
with this -start offset can´t find the key:
./rckangaroo -dp 16 -range 69 -start 0 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349B84B6431A6C4EF1 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 85 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
I am running it with -range 84 to see if it solves. Will update.
Edit:
Spoke to soon lol. Here is my result using your command line:
Code:
Solving public key
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000
Solving point: Range 84 bits, DP 16, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 3.062 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 98.133.
GPU 0: allocated 4437 MB, 786432 kangaroos.
GPUs started...
MAIN: Speed: 7904 MKeys/s, Err: 0, DPs: 1181K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 2387K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7868 MKeys/s, Err: 0, DPs: 3591K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 4795K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7859 MKeys/s, Err: 0, DPs: 5976K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 7179K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 8382K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 9563K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 10766K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7845 MKeys/s, Err: 0, DPs: 11970K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 13152K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 14356K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7842 MKeys/s, Err: 0, DPs: 15536K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 16740K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 17942K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7830 MKeys/s, Err: 0, DPs: 19121K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7788 MKeys/s, Err: 0, DPs: 20324K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 21502K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7799 MKeys/s, Err: 0, DPs: 22707K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 23884K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 25089K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 26269K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 27473K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 28652K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 29856K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 31059K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 32238K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 33441K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 34619K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7837 MKeys/s, Err: 0, DPs: 35824K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
MAIN: Speed: 7791 MKeys/s, Err: 0, DPs: 37003K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
Stopping work ...
Point solved, K: 0.552 (with DP and GPU overheads)
PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000
Solving point: Range 84 bits, DP 16, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 3.062 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 98.133.
GPU 0: allocated 4437 MB, 786432 kangaroos.
GPUs started...
MAIN: Speed: 7904 MKeys/s, Err: 0, DPs: 1181K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 2387K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7868 MKeys/s, Err: 0, DPs: 3591K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 4795K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7859 MKeys/s, Err: 0, DPs: 5976K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 7179K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 8382K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 9563K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 10766K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7845 MKeys/s, Err: 0, DPs: 11970K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 13152K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 14356K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7842 MKeys/s, Err: 0, DPs: 15536K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 16740K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 17942K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7830 MKeys/s, Err: 0, DPs: 19121K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7788 MKeys/s, Err: 0, DPs: 20324K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 21502K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7799 MKeys/s, Err: 0, DPs: 22707K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 23884K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 25089K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 26269K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 27473K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 28652K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 29856K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 31059K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 32238K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 33441K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 34619K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7837 MKeys/s, Err: 0, DPs: 35824K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
MAIN: Speed: 7791 MKeys/s, Err: 0, DPs: 37003K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
Stopping work ...
Point solved, K: 0.552 (with DP and GPU overheads)
PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8
So since I solved at both 85 and 84 range, I am not sure what the problem is/was on your end. Your command line args are fine.
I try 85 and 84 but i can´t still find the key. I use Linux CUDA driver/runtime: 12.4/12.0 what use you?
And you find also with 85, but i don´t understand how this works, because:
2^85 = 38685626227668133590597632 -> this is in hex 2000000000000000000000
That mean you Range start by 2000000000000000000000 and + offset 1000000000000000000000 = 3000000000000000000000 this is out of the Range the key is 11720C4F018D51B8CEBBA8
Or i understand something wrong?!
I have solved #85, using -range 85. Try it and see if you find the key.
./rckangaroo -dp 16 -range 85 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
I am running it with -range 84 to see if it solves. Will update.
Edit:
Spoke to soon lol. Here is my result using your command line:
Code:
Solving public key
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000
Solving point: Range 84 bits, DP 16, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 3.062 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 98.133.
GPU 0: allocated 4437 MB, 786432 kangaroos.
GPUs started...
MAIN: Speed: 7904 MKeys/s, Err: 0, DPs: 1181K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 2387K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7868 MKeys/s, Err: 0, DPs: 3591K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 4795K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7859 MKeys/s, Err: 0, DPs: 5976K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 7179K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 8382K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 9563K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 10766K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7845 MKeys/s, Err: 0, DPs: 11970K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 13152K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 14356K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7842 MKeys/s, Err: 0, DPs: 15536K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 16740K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 17942K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7830 MKeys/s, Err: 0, DPs: 19121K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7788 MKeys/s, Err: 0, DPs: 20324K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 21502K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7799 MKeys/s, Err: 0, DPs: 22707K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 23884K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 25089K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 26269K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 27473K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 28652K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 29856K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 31059K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 32238K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 33441K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 34619K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7837 MKeys/s, Err: 0, DPs: 35824K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
MAIN: Speed: 7791 MKeys/s, Err: 0, DPs: 37003K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
Stopping work ...
Point solved, K: 0.552 (with DP and GPU overheads)
PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000
Solving point: Range 84 bits, DP 16, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 3.062 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 98.133.
GPU 0: allocated 4437 MB, 786432 kangaroos.
GPUs started...
MAIN: Speed: 7904 MKeys/s, Err: 0, DPs: 1181K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 2387K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7868 MKeys/s, Err: 0, DPs: 3591K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 4795K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7859 MKeys/s, Err: 0, DPs: 5976K/77175K, Time: 0d:00h:00m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 7179K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 8382K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 9563K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 10766K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7845 MKeys/s, Err: 0, DPs: 11970K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 13152K/77175K, Time: 0d:00h:01m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 14356K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7842 MKeys/s, Err: 0, DPs: 15536K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 16740K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 17942K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7830 MKeys/s, Err: 0, DPs: 19121K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7788 MKeys/s, Err: 0, DPs: 20324K/77175K, Time: 0d:00h:02m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 21502K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7799 MKeys/s, Err: 0, DPs: 22707K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7862 MKeys/s, Err: 0, DPs: 23884K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 25089K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7792 MKeys/s, Err: 0, DPs: 26269K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 27473K/77175K, Time: 0d:00h:03m, Est: 0d:00h:10m
MAIN: Speed: 7822 MKeys/s, Err: 0, DPs: 28652K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 29856K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7834 MKeys/s, Err: 0, DPs: 31059K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 32238K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7828 MKeys/s, Err: 0, DPs: 33441K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7831 MKeys/s, Err: 0, DPs: 34619K/77175K, Time: 0d:00h:04m, Est: 0d:00h:10m
MAIN: Speed: 7837 MKeys/s, Err: 0, DPs: 35824K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
MAIN: Speed: 7791 MKeys/s, Err: 0, DPs: 37003K/77175K, Time: 0d:00h:05m, Est: 0d:00h:10m
Stopping work ...
Point solved, K: 0.552 (with DP and GPU overheads)
PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8
So since I solved at both 85 and 84 range, I am not sure what the problem is/was on your end. Your command line args are fine.
[/quote]
I try 85 and 84 but i can´t still find the key. I use Linux CUDA driver/runtime: 12.4/12.0 what use you?
And you find also with 85, but i don´t understand how this works, because:
2^85 = 38685626227668133590597632 -> this is in hex 2000000000000000000000
That mean you Range start by 2000000000000000000000 and + offset 1000000000000000000000 = 3000000000000000000000 this is out of the Range the key is 11720C4F018D51B8CEBBA8
Or i understand something wrong?!
I had time again and was able to continue taking tests.
I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
Please, it is better to send the command line you are / were using. That way someone can take a better look at everything. Maybe you forgot to use the correct subtract amount, wrong key, etc. Could be anything, could be nothing, but it's the first thing to look at.I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
Here is for Bit 85, i can´t find the key:
./rckangaroo -dp 16 -range 84 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
./rckangaroo -dp 16 -range 84 -start 11720c4f018d51b8000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a
For Bit 70 i always find the key, doesn´t matter which -start i use (only two see below):
./rckangaroo -dp 16 -range 69 -start 200000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 100000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 300000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 340000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349000000000000000 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349B84B6431A6C4EF0 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
with this -start offset can´t find the key:
./rckangaroo -dp 16 -range 69 -start 0 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
./rckangaroo -dp 16 -range 69 -start 349B84B6431A6C4EF1 -pubkey 0290e6900a58d33393bc1097b5aed31f2e4e7cbd3e5466af958665bc0121248483
I had time again and was able to continue taking tests.
I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
I think there is a bug in the tool when solving large bit areas.
I was able to solve bits 70, 75, and 80 without any problems, but from 85 onwards none of the puzzles that had already been solved. For example, I changed values at Bit 85 start, etc. but it was never found. An example, after that i stop -> Err: 0, DPs: 98481K/77175K, Time: 0d:00h:13m/0d:00h:10m
Don't think I'm making a mistake because it solved bit 70, 75, 80. If I had time again I would look at it more intensively, I'm not sure but maybe there is an overflow, .....
Can someone else please test this too??
First I would like to thank the RetiredCoder or (RC). Great work!!!
I'm trying to understand and analyze your code.
I carried out some tests with my 4090 and noticed that e.g. Bit 70 everything works perfectly!
Unfortunately, when I go to bit 130 it looks different, but I'm trying to figure out why there are problems here. Currently I have no idea what the reason(s) are. I'll take a look at the code in a few days. Maybe someone here has the same experiences.
Thanks again :-)
I'm trying to understand and analyze your code.
I carried out some tests with my 4090 and noticed that e.g. Bit 70 everything works perfectly!
Unfortunately, when I go to bit 130 it looks different, but I'm trying to figure out why there are problems here. Currently I have no idea what the reason(s) are. I'll take a look at the code in a few days. Maybe someone here has the same experiences.
Thanks again :-)
You are sure?
Here's a guide to who wants to use Mara, for people who didn't know:
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_2_Creating_a_Raw_Transaction.md
I will also use Mara and will report back here in detail if I ever solve a puzzle in my life :-))
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_2_Creating_a_Raw_Transaction.md
I will also use Mara and will report back here in detail if I ever solve a puzzle in my life :-))
This info is from MARA:
"Is my transaction guaranteed to get mined by Marathon?
No. Once accepted by Marathon, your transaction will compete with other Bitcoin transactions for inclusion into a block. You will receive a personalized link to view your transaction's status."
If I solve 67 I'll try Mara, but the more I look into the topic I believe less in MARA. The question is it the only solution? Or is it hopeless against the BOTs, if so then you shouldn't waste your time/money on 67. But I'm not an expert
"Is my transaction guaranteed to get mined by Marathon?
No. Once accepted by Marathon, your transaction will compete with other Bitcoin transactions for inclusion into a block. You will receive a personalized link to view your transaction's status."
If I solve 67 I'll try Mara, but the more I look into the topic I believe less in MARA. The question is it the only solution? Or is it hopeless against the BOTs, if so then you shouldn't waste your time/money on 67. But I'm not an expert