Are you saying that you are changing the value of Generator (G) and it is not working?

https://github.com/RetiredC/RCKangaroo/blob/main/Ec.cpp#L113-L114

Bitcoin uses secp256k1, so the G should be what is defined to be: https://en.bitcoin.it/wiki/Secp256k1

G point is the following:
(compressed form): 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
(uncompressed form): 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C 4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

Hey mjojo,

I created a table using what I recommended to do, to play around with DP values.

https://i.ibb.co/MV9M9yk/DP-values.png

You can see the values of using different DPs.

This thread is a great opportunity to learn how Bitcoin works and use Kangaroos to solve ECDLP but in the end people are only interested in asking for money.

I am doing a project based on yours, RetiredCoder, where I have created the following:
- Lib: Where all the logic is and it is a library available to different executables.
- Worker: Connect to a Dpserver, receives a job and is responsible for sending points to the dpserver
- Dpserver: Receives the points and processes them.

Additionally I have created the following:
- GitHub Actions to validate that it can be compiled on Windows/Ubuntu
- Added CMake to generate the solution on Windows/Ubuntu
- Unit and performance tests to validate different solutions.

Maybe in a few months I will share it with the community, in the meantime I will continue learning since it seems like a great opportunity.

Hi tmar777,

You should learn a bit about how programming works with CUDA (Compute Unified Device Architecture) and how RetiredCoder has implemented it in his code.

In CUDA, you work with the following:
* Kernel: name of a function run by CUDA on the GPU.
* Thread: CUDA will run many threads in parallel on the GPU. Each thread executes the kernel.
* Blocks: Threads are grouped into blocks, a programming abstraction. Currently a thread block can contain up to 1024 threads.
* Grid: contains thread blocks.

If we focus on the software that RetiredCoder has shared on GitHub (https://github.com/RetiredC/RCKangaroo):

There are currently 4 Kernels:
* KernelGen: Runs once at the beginning this kernel calculates start points of kangs
* KernelA: this kernel performs main jumps
* KernelB: this kernel counts distances and detects loops Size>2
* KernelC: this kernel performs single jump3 for looped kangs

Then KernelA, KernelB and KernelC are run in a loop where if we ignore KernelGen (since it is only run once at the start) in percentages of time it would be something like this:
* KernelA: 90%
* KernelB: 4%
* KernelC: 1%

So, you have to understand that the executable that is run will run on the CPU and then in CUDA the Kernels will run on the GPU.

Answering your questions:
1) This problem does NOT require much CPU. This problem is computationally intensive on the GPU. Imagine that it needed 400x RTX 4090 to be able to complete the 129-bit puzzle.
2) To understand DPs and how they affect. First you need to know what a DP is: Distinguished points: a point is a distinguished point if its representation exhibits a certain bit pattern, e.g., has the top 20 bits equal to zero.

You have to know that you have a number of X kangaroos that make Y jumps every second.

Now if we use a DP of Z bits, that means that depending on the Z, that will be the average chance that a kangaroo will find a point that has that DP.

The higher the Z, the harder it will be to find that DP.

Now I recommend that for you to learn better in a practical way, you play with if I use a very low DP, what happens to the memory? How many points do I store?
Same if I use a very high DP.

3) When running any software, these are the metrics (there are more, but these could be the main ones) that one should look at:
* CPU usage
* Disk usage (disk I/O: input/output operations).
* RAM usage

With this you have a view of what is happening with the application you are running. In this case, and as I already told you, it is an application that uses CUDA, that is, it makes use of the GPU, therefore, you should analyze:
* GPU index (starts from 0)
* GPU name
* GPU temperature
* GPU memory usage (Used / Total). Here you can see how different memories are used
* Using CUDA Cores and SMs

You can use `nvidia-smi` or other tools like:
* https://github.com/XuehaiPan/nvitop
* https://github.com/Syllo/nvtop
* NVIDIA Nsight Compute (https://developer.nvidia.com/nsight-compute)

To sum up: the important thing is not the RAM or memory usage that the GPU uses, but the amount of work that it is processing in the kernels.

I hope it has helped you and if you have any questions, I am here to help you.

Hey atom13,

You need to learn a bit of how a Bitcoin Address is generated and in which ranges are we talking.

Generate private key:
1. Private key is 256 random bits.
2. Prepend version number.
3. Append compression flag.
4. Append checksum. Checksum is the first 4 bytes of double sha256 hash of whatever is being checkedsum'ed.
5. Base58 encoded data is easier to read and manage.

Generate public key:
6. Multiply the private key by the elliptic curve generator point to get the public key. The public key is a point on the elliptic curve and has x and y coordinates.
7. Use parity of y coordinate and full x coordinate to represent the public key.
8. Hash public key twice. This obfuscates the public key and shortens it.
9. Prepend version (version number is different than in step 2)
10. Append checksum (same method as step 4)
11. After another base58 encoding, we have our public address

This page will help you a bit to understand the process behind it: https://royalforkblog.github.io/2014/08/11/graphical-address-generator/

The problem with bots is in the ranges where it is fast to calculate the private key given a public key (not the same as a public address).

Moreover, puzzles 135, 140, 145, 150, 155 and 160 have the public key known, but nobody has taken the public key. That is due to the range they are in.

The problem is in puzzles 67, 68, ... where the public key is not yet available (but the public address is). The moment you send the transaction to send Bitcoin from that puzzle to a wallet of yours is when you can get the public key (it is in Mempool).

Public keys can be found inside the ScriptPubKey or ScriptSig of raw transactions.

I hope this helps you a bit to understand the process behind it. If you have any questions, feel free to ask. I will be glad to help you.

Executing the puzzle #85 on RTX 4060


I compare the number of operations with JLP:


Quick comparison, its using the half of the RAM used with the same DP and less operations

Thanks for sharing your repositories and source code.

Great job!

Hey bestie1549,

I grouped all information found in this repository:

https://github.com/AlberTajuelo/bitcoin-0.2-image-puzzle

Here you have the original image with all the clock numbers with a line on it:

https://github.com/AlberTajuelo/bitcoin-0.2-image-puzzle/blob/master/images/original-clock.png

And remember about the bitcoin transaction, it occurred on May 10, 2020 at 8:00 AM UTC but this puzzle first time was shared in reddit it was created on October 8, 2020 (https://www.reddit.com/user/stsh_n/comments/j79zvj/bitcoin_puzzle_2000/).