Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
Why and how do you change the G? If you change the generator all the results will be incorrect for secp256k1 curve, maybe you mean to use a stride of 2, in order to skip 1 key between each jump, or skip 2, well if you try that you will see that you are just skipping for example 33% of the range as well as reducing the probability of finding your target by 33%.
But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.
Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉
I am pretty much interested in generating these offsets as explained here, when you speaking of RAM sizes I can get as much as 5 Ekeys/s on BSGS with a good amount of thread too.
We need to know how to start and the BSGS is just an example to give you the understanding of the available RAM.
what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?