Topic: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== - page 10. (Read 57113 times)

I have already commented under another thread. This is a telltale sign of a successful lattice attack on the Bitcoin wallet to reveal private keys and then transferring out the funds to deterministically generated wallets having similar public keys/addresses.

Hi are you willing to share Your code / github? Or it is some secret sauce ?

It's a good idea however, there are only 2 pools that I know of and one is shady, and had some bad ranges/math of total ranges needed to search.

I wouldn't trust anything from that certain pool.

Hi everyone,
I have an idea that could greatly speed up puzzle 66 and all the others with little expenditure of energy.

How many pools are there?

 
So pools are the solution because unity is strength!

So why not share among all pools the shared intervals?

Let me explain further....

The idea would be to provide a central server or hosting where to store all the ranges that each pool has scanned.

The update would not be in real time, for security issues, but new records would be updated once a day after 24 hours from the scann of the range.

The requirement for each pool to access the data, is to ensure a minimum number of daily ranges (example: 10000 ranges per day).

Then it would be a matter of adding to the various pool programs an extra parameter in range selection, i.e., whether or not to include ranges from shared pools in the scan.

Of course, ranges scanned from other pools would not automatically be reported as done, because we do not have absolute certainty that they have been completed, only free ones would be given priority.

And there would also be no need to divide the prize between pools, each going their own way.

Doing so would drastically reduce search time.
What do you think

sorry for my English, I am using a translator

That's actually very interesting. Could you share your raw files with these mods applied? 

I've tried it on my own files but I can't get it to recompile afterwards, throws a bunch of errors.

Also you've mentioned that you are using Vladimir's version of Rotor, try using Phrutis' version. I think it's a little bit faster.

Thanks!!

I'm searching puzzle66 by address.
This is max speed for now.
Tryin to figure out how to reduce memory usage and fit entire app to GPU L2 cache.
Looks like reducing GRP_SIZE helps, but a lot of kernel calls then. Probably need to return back STEP_SIZE which was removed from rotor-cuda and vanitysearch have it.
Experimenting...

Ok, then yes, that is a version that can be used for this challenge.

Better? I'm not sure, a lot of forks out there but I don't think anyone has improved upon it.

In your example, what card are you using and are you searching x point or address?

Speed before my mods was about 6.38 Gk/s.
I think I used this one:
https://github.com/Vladimir855/Rotor-Cuda

Is any better version available?

Thanks.

What was the speed before and which version of Rotor-cuda are you using?
One checks symmetry/endos, etc. one does not.
The one that checks endos, is not good for the puzzle and the speed is misleading.

There is some tips to speed-up keyhunt-cuda (rotor-cuda):

Apply this then you need less grid size, like 4096x512 will be enough for 4090:

https://bitcointalksearch.org/topic/m.63526413

Also change this:

__device__ __noinline__ void CheckHashSEARCH_MODE_SA(uint64_t* px, uint64_t* py, int32_t incr, uint32_t* hash160, uint32_t* out)
{
   switch (mode) {
   case SEARCH_COMPRESSED:
      CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      break;
   case SEARCH_UNCOMPRESSED:
      CheckHashUnCompSEARCH_MODE_SA(px, py, incr, hash160, out);
      break;
   case SEARCH_BOTH:
      CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      CheckHashUnCompSEARCH_MODE_SA(px, py, incr, hash160, out);
      break;
   }
}

to this because doing switch-case in kernel is very bad idea:

__device__ __noinline__ void CheckHashSEARCH_MODE_SA(uint64_t* px, uint64_t* py, int32_t incr, uint32_t* hash160, uint32_t* out)
{
   
   CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      
}

also maxFound can be completely removed to search puzzle, because we need only one return result anyway

Rotor-cuda speed with this mods:

  [00:17:10] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.453247 %] [R: 0] [T: 6,412,923,043,840 (43 bit)] [F: 0]
  [00:17:11] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.500549 %] [R: 0] [T: 6,421,244,542,976 (43 bit)] [F: 0]
  [00:17:12] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.547852 %] [R: 0] [T: 6,429,566,042,112 (43 bit)] [F: 0]
  [00:17:13] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.595154 %] [R: 0] [T: 6,437,887,541,248 (43 bit)] [F: 0]
  [00:17:15] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.642456 %] [R: 0] [T: 6,446,209,040,384 (43 bit)] [F: 0]
  [00:17:16] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.689758 %] [R: 0] [T: 6,454,530,539,520 (43 bit)] [F: 0]
  [00:17:17] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.737061 %] [R: 0] [T: 6,462,852,038,656 (43 bit)] [F: 0]
  [00:17:18] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.784363 %] [R: 0] [T: 6,471,173,537,792 (43 bit)] [F: 0]
  [00:17:20] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.831665 %] [R: 0] [T: 6,479,495,036,928 (43 bit)] [F: 0]
  [00:17:21] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.878967 %] [R: 0] [T: 6,487,816,536,064 (43 bit)] [F: 0]


Thanks.

Meehn... Seems like this is a game for programmers?🤦🏾‍♂️😁 I'm outta here I guess

He can't lol.

Really, what do you mean?

How is 0x10492A658E39638E5 the first value for the 66 bit range?

Maybe I am misreading your statement(s).

NO. excusema

Hi fecell .. can you please explain more why values less "100000100100100101010011001011000111000111001011000111000111001011" will fail .. thanks and regards

No, i mean I can reduce a generator range to skip not random values, so time to bruteforce reduced too.

For example, 23 bit key to test (python 3.11 + ice_secp256k1.dll).
with secret algo:
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
10.363348245620728 s

with usual range (2^22 ... 2^23-1)
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
16.832353353500366 s

with big values, like 66 bit, a lot of values just skiped as NOT random binary values, because cant be randomly generated by author (by wallet software).
for example, first value for 66-bit range is 100000100100100101010011001011000111000111001011000111000111001011, all values less is fail.
this value give generator as first value applyed with random's rules

anyway, pure python not a good instrument to get result. wanna use numba cuda.jit, but still learning how to.

Thanks. I had some thoughts about this program optimization also.

1. It uses global device memory access even if searching by one key. Why it can't fit searched bitcoin address ripemd160 hash, public key incremental function and ripemd160(sha256) functions in cache?
2. As I understand it executes kernel from cpu thread several times on range. Why don't do it just one time for entire range supplied to kernel.
3. ripemd160(sha256) using Tensor cores?

The continue option was an option in rotorcuda that would save how many keys searched and grid size and readjust the range on a restart.
It had flaws, as in sometimes it would not adjust correctly, or the total keys searched line would be blank.

The maxFound option was the max keys the program could find in a single kernel call. I don't remember that being in keyhuntcuda or rotorcuda but more of the vanitysearch/forks of vanitysearch.

Hello. What is continue option? What bug exactly? Also, can somebody explain me what maxFound option is and how it used in code? Thanks.

That's actually a very good explanation, really appreciate it man!

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.