 Show Posts
|
|
Pages: « 1 [2]
|
Yes, you could. I implemented a total key counter in mine. It would print to file, total # of keys, that way, even if power went out, I'd have a good starting point.
If you do it this way, make sure you keep/know start and end range. You then need to take total keys ran, divide by the number of threads (grid size) and then take that number and add it to your initial/last start AND end range.
Example:
If you had a start range of 0 and an end range of 1000000 (keep it small for this purpose) and your grid size was 10x10. The program says you have ran/checked 10,000 keys total.
Take 10,000 (total keys) and divide by 10x10=100 (grid size); 10,000 / 100 = 100. So each gpu thread checked 100 keys.
So for your next batch file, you would have a start/end range of 100:1000100.
If you only change the start range by 100, then you are overlapping/possibly missing keys checked on the other threads. If you stop and think about it, or do the math, it'll make sense.
Your first thread checked 0-100 (now on second run it should start at 100 and be on the hook to check up to 10,100); the last thread checked 990,000-990,100. If you don't adjust the end range as well, your last thread will now be checking 999,900 instead of starting where it left off at 990,100.
Lol, again, if you do the math you'll understand. Hope it made some sense.
That's actually a very good explanation, really appreciate it man! |
|
|
|
Yeah, I was testing different grids for my card the other day, within the reasonable bounds, keeping it a small multiple of the original grid. After a while I decided to play with it a bit and increased the grid by larger factors, thus arriving at numbers like 18000 and 32000. They are not arbitrary. I thought the program wouldn't even initiate. For my surprise not only it ran but it had increased speeds. Then it came to mind that it was probably jumping over a bunch of keys.  It was too good to be true. I was getting a constant 5GK/s with sudden peaks to 9GK/s every few seconds running sequential X-Point mode with a grid-size like --gpux 36000x512 against #130. Raise it much further than that and the speed will keep dropping to 0.00 MK/s for a few seconds during the entire search. Anyways, if going for random mode I guess this issue could be overlooked? One can have more threads thus searching faster, the trade-off being skipping some keys... About this other flaw [in a scenario where the grid-size is not causing it to skip keys] could I avoid it by updating the lower range in my .bat file to be the last key shown in the counter before terminating the session, instead of using continue.bat? Thanks! |
|
|
|
I definitely got ahead of myself.  I ran X-Point mode using --gpux 32000,512 against 20 keys spread over the 2^40 range and only 2 of those keys were being found. Same with --gpux 18000,512 and anything in between. In the end only with --gpux 1024,512 the program was able to find all 20 keys without skipping. I'll run 2^50 next against more keys to see if this effect gets mitigated as the space increases. Haven't checked Address mode or Hash160 mode yet. |
|
|
|
|
Hey there, thanks for your reply. Much appreciated.
So if it can pass the 2^40 test without skipping any keys can I deem it safe?
So far no problems with 2^35, 2^38, 2^39, 2^40.
--gpux 32000,512
|
|
|
|
|
While running some performance tests with Rotor-Cuda I've noticed that when I assign a monstruous grid-size for my GPU, I can get more speed.
If I set it like this --gpux 18000,512 I get a steady 4.62 GK/s peaking at 6.90 GK/s for a few seconds.
Can this cause any problems, like skipping keys during the search? If so, can anyone recommend a good grid-size for a 3080ti?
Thanks in advance!
|
|
|
|
So I'm messing with Puzzle #130 and JLP's Pollard Kangaroo ECDLP Solver using a RTX 2070. When I first launch it, this is the speed I get: [1553.87 MK/s][GPU 1459.12 MK/s] After a few seconds running at that speed it will slowly decrease until it reaches this speed, where it stays for the rest of the operation: [1209.19 MK/s][GPU 1134.42 MK/s] Does anyone know why this is happening? Thanks in advance!  Because statistics are wrong until all threads loads kangaroos. Wait about 10-15 seconds to get right numbers. Oh, this makes total sense. Thank you for your quick and concise answer! |
|
|
|
So I'm messing with Puzzle #130 and JLP's Pollard Kangaroo ECDLP Solver using a RTX 2070. When I first launch it, this is the speed I get: [1553.87 MK/s][GPU 1459.12 MK/s] After a few seconds running at that speed it will slowly decrease until it reaches this speed, where it stays for the rest of the operation: [1209.19 MK/s][GPU 1134.42 MK/s] Does anyone know why this is happening? Thanks in advance! |
|
|
|
understood. Thank you for clarification @ecdsa123
I just ran a successful test with a 129bit key and it worked like a charm.
One more question related to Kangaroo program. Let's say I run Kangaroo and search for a 145bit key. I run it for 1 hour and then quit it because no key was found. Then I re-execute exactly the same command. Will the program iterate through the same values as it did on run first or is it theoretically possible that the 2nd run will find a key? My question basically is: does it behave like VanitySearch where it's theoretically possible to find a match each second regardless of what happened in the history and which range was scanned. Or does it behave more like BitCrack which searches in linear mode ?
I have the same doubt! |
|
|
|
7 hex characters is 28 bits... if the program is printing the r points in encoded form (all beginning with 03 or 02?) then that would be 20 bits.
Assuming 28 bits there is a 50% probability of a 28 bit collision if you look at 2^14 = 16384 r values. So if your total number of inputs is greater than that then it would be unlikely for there to NOT be a match. Even if you have far fewer, it's just not that unlikely for there to be a short collision like that.
You can go look at a birthday probability calculator-- whats the probability that at least two people out of $INPUTS people share a 'birthday' in a year with 2^28 (268435456) days.
It wouldn't concern me to find such a match.
Hello and thanks for your reply!  I assume the program did not print the R points in encoded form then, as they would all begin with a random Hex character. At first I was afraid this could mean a bias in the nonce, but based on the replies to this post I now think this is well withing reasonability. I'm not quite there yet with all the technical stuff, but I'm working on it. Again, thanks for your reply and for all the info provided. |
|
|
|
|
Alright then! Thanks a lot for all the info you provided, I really appreciate it!
|
|
|
|
Were the matching characters all zeroes? There are some known weak values that do that.
Also, do you mean 7 hex characters, or 7 bytes (14 hex characters) matching? 7 hex characters would be a quite common coincidence, and there would in theory be one collision in 8000 random signatures due to the birthday paradox, though it's interesting that you managed to hit one unless you have a big number of signatures.
7 bytes would be much more rare, and I see a few collisions in the total blockchain up to around 2019, which is expected due to the birthday paradox, but managing to hit a collision within a narrow number of signatures created by yourself would be exceptional.
I meant 7 hex characters, not bytes. And they were not just zeroes. So we can consider it being a somewhat expected occurrence? |
|
|
|
My instinct says that you messed up and aren't actually looking at the actual R values. Even close related and biased nonces would have wildly different R values, having R that partially matches like that is a 1 in 72057594037927936 chance.
Hello and thanks for your reply.  I've used this tool for my paranoid endeavors [ https://github.com/iceland2k14/rsz ]. Each txid gave me a list of every input index' R, S, Z values + Pubkey. That was how I've spotted it. |
|
|
|
Hello fellow Bitcoiners. This is my first post here, I've been lurking for a while now and I've finally decided to create my account to engage here in the forum. I really like it here, you guys are awesome. So, I've heard about the reused R value scenario and decided to check my past transactions to see if I could have been compromised at some point, and so I've noticed something rather peculiar. There was this one transaction from 2017, from a Legacy address I've used a couple of times, in which two input indexes had their respective R values sharing the first 7 characters. They were identical up to the 7th character, then afterwards it seemed to get random  [no patterns were found in the respective S and Z values]. Needless to say I immediately moved the funds out of that address, which was not much anyways. I'm not going to share specific details 'cause it could expose some of the addresses I'm still using to hodl my dust. I would like to know tho if this could be an indication of a biased nonce, and if this could have been exploited somehow to gain access to my funds, had some malicious entity spotted this in time to take any action. I think that's it for my first post. Stay awesome and stay safe! |
|
|
|
|
