After quick look at kangaroo code, looks like there is 3-bits of 128-bit value used for something. So, it actually really 125-bit max. I can be wrong and I think only JLP can answer 100%.

Sorry, but I can't find 100% official answer that it will work on 128-bit range.
125-bit will work, 129-bit (#130 puzzle) no, as stated in readme.
Some speculation that it can work with 126, 127 and 128-bit ranges.
But I need 100% to know so. I think developer of this program should know this 100%.
Thanks.

It will be nice to know from this program developer if kangaroo can work with 128-bit range?
Or it absolute maximum 125-bit as stated in the readme?
So, splitting in half #130 puzzle will help? It will be exactly two 128-bit ranges then.
Thanks.

How much RAM needed for BSGS algorithm to solve 130-bit puzzle?

Just found the way how to do it...
So, we're definitely f....d...
66 puzzle is waste of electricity now.
Thanks.

Can somebody who say double-spend is possible with RBF-disabled make a video to actually proof this. This is a simple test, which I tried several times on my own addresses and I have always negative results.

Yes.

64 puzzle was solved 2022-09-10 then we had 3090 maximum.
Now we have 4090 which is 2x faster.
Next year we'll have 5090 which probably even 2x faster then 4090.

66 puzzle exactly have 4x more difficulty then 64 puzzle.
So next year solving 66 with 5090 will be the same probability as solving 64 with 3090 in 2022.

I think GPU_GRP_SIZE should be small as possible to fit SM L1 cache, because it used most frequently.
2048 in KeyHuntCuda (rotorcuda) is too big and huge global memory pressure because of this.
As I understand more NB_RUN = less kernel calls from CPU code. It doing NB_RUNs of GPU_GRP_SIZE.

I'm using Nsight Compute and GPU-Z sensors data to experiment with different values.

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...

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.

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://bitcointalk.org/index.php?topic=5244940.msg63526413#msg63526413

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.

Hello. If search key range for a key by different search methods simultaneously is it will change probability theory expected value? Thanks.

What do you think about this mod:

If add this:

  err = cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync);
  if (err != cudaSuccess) {
      printf("GPUEngine: %s\n", cudaGetErrorString(err));
      return;
  }

after this:

  err = cudaSetDevice(gpuId);
  if(err != cudaSuccess) {
    printf("GPUEngine: %s\n",cudaGetErrorString(err));
    return;
  }

in GPUEngine constructor

then you don't need this (this is bad by design just do nothing for 1ms and GPU just idling):

 // Use cudaMemcpyAsync to avoid default spin wait of cudaMemcpy wich takes 100% CPU
 cudaEvent_t evt;
 cudaEventCreate(&evt);
 cudaMemcpyAsync(outputItemPinned,outputItem,4,cudaMemcpyDeviceToHost,0);
 cudaEventRecord(evt,0);
 while(cudaEventQuery(evt) == cudaErrorNotReady) {
   // Sleep 1 ms to free the CPU
   Timer::SleepMillis(1);
 }
 cudaEventDestroy(evt);

and you can use:

gpu->Launch(gpuFound, true);

and it will be no spinwait cpu usage because of cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync) set

Thanks.

How to change receiver address on second RBF transaction? What wallet have this function?

It was a hype about NFTs on ethereum blockchain. What happened after it? A lot of people loose money on it and nobody using this now.
Now it on bitcoin blockchain... Strange thinking by bitcoin team I think... To make miners happy?

But if address balance is low attacker cannot make a transaction, because address balance should be more than current transaction fee...

If I did it right then 1PbL9QGg5fqRHmFXEBNBkey6Atp6SkWnFw address should have stuck transaction now.

After what time it will be usually dropped from mempool if not processed?

Yes. I'll find puzzle 66 in a next few months and I don't want to be my money be stolen on transaction

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

I'm interested. I can do.
Do I need to place some low free transaction with RBF off with 100usd on it and say everybody a private key? Yes?
And we'll see if transaction can be modified with RBF flag off? Yes?