Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 29.

COBRAS

member

Activity: 873

Merit: 22

$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk

Quote from: ? on November 10, 2024, 11:19:05 AM

Quote from: citb0in on November 10, 2024, 07:32:59 AM

so he solved 120, 125 and 130. Where are the privkeys for them, I don't see them? What's the reason for not sharing them ?

Because these addresses still have some altcoins, so I want to post them as mini-puzzles for fun

120 is already in public after first mini-puzzle.
To stop useless discussions:

Address: 1PXAyUB8ZoH3WD8n5zoAthYjN15yN5CVq5
Message: RetiredCoder is a winner for 120,125,130
Signature: ILsD3ydVDKulUbTykvnPl8RNwPeBKqw58rv+ftq0HRxbWyzIbgl29Wup6uTahQ7xkKUG/LAUJLF8xcBxc2FDUU8=

Address: 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua
Message: RetiredCoder is a winner for 120,125,130
Signature: IN6XCSv7fAIUioJ7T4ti2x4YmnOcd4FXmd9eb7Na6IofP0+ji8uxdhVEb6vG++vO77t9BS7KnOE2s6Sme38NT0I=

Cool ! Congratulations 👏

Bro, bib you use any "trick" - not standart method ? )))

Then you will solve 135 ?)

I was send 5 merit your "carma".))

ps I realy not understand how it possible Cry

?

Activity: -

Merit: -

Quote from: citb0in on November 10, 2024, 07:32:59 AM

so he solved 120, 125 and 130. Where are the privkeys for them, I don't see them? What's the reason for not sharing them ?

Because these addresses still have some altcoins, so I want to post them as mini-puzzles for fun

120 is already in public after first mini-puzzle.
To stop useless discussions:

Address: 1PXAyUB8ZoH3WD8n5zoAthYjN15yN5CVq5
Message: RetiredCoder is a winner for 120,125,130
Signature: ILsD3ydVDKulUbTykvnPl8RNwPeBKqw58rv+ftq0HRxbWyzIbgl29Wup6uTahQ7xkKUG/LAUJLF8xcBxc2FDUU8=

Address: 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua
Message: RetiredCoder is a winner for 120,125,130
Signature: IN6XCSv7fAIUioJ7T4ti2x4YmnOcd4FXmd9eb7Na6IofP0+ji8uxdhVEb6vG++vO77t9BS7KnOE2s6Sme38NT0I=

WanderingPhilospher

full member

Activity: 1232

Merit: 242

Shooters Shoot...

Quote from: ?? on ??

Quote from: WanderingPhilospher on November 09, 2024, 10:18:00 AM

Quote

Imagine a 10-band highway, and you have 1000 cars, and they all need to go from point A to point B before moving from point B to point C.

Yeah, I don't understand this. But it's ok, I don't need to. I don't understand how the speed is tied to this...the same would be true for the fastest of fastest kangaroos, using the fastest of fastest CPUs.

I know that more but slower kangaroos, will solve faster than less, but faster kangaroos, when dealing with higher bit ranges. Speed versus "efficiency / optimization" (DP overhead) are two different things in my opinion.

The highway is the on-chip registers, the parking lot is the GPU memory.

On-chip registers are insanely more times faster than reading and writing data from and into GPU memory, which is what the JLP kernel is all about. The loops are also in the bad order if what we care for are the jumps, not the kangaroos.

Maybe you wouldn't agree on this, but it is a really bad idea to dump millions of kangaroos into memory and read/jump/store them, to achieve the same efficiency as less kangaroos with a correct average jump size. Why? Because you can have a much much better efficiency by using fewer, faster kangaroos, and have the same results, but much faster.

The lower DP overhead because of fewer number of kangaroos - that is just an extra bonus, not an targeted optimization.

Stop comparing one program to JLPs program.

I am saying, given the same program, even one that you feel you have optimized in whatever way, if I run a single CPU versus a single GPU, which will find the key faster, in say, an 80 bit range.

To clarify again, your program CPU versus your program GPU.

I don't use JLPs Kangaroo program any longer, so you can stop referring to it when answering my questions of less/faster versus more/slower kangaroos/threads.

Anonymous User

newbie

Activity: 30

Merit: 0

Name:   sneeky777
Posts:   7
Activity:   7
Merit:   0
Position:   Newbie
Date Registered:   October 14, 2024, 06:45:06 PM
Last Active:   October 16, 2024, 01:06:08 AM

As you can clearly see this is a dummy ID that Retired Coder created to solve his own mini puzzle

kTimesG

member

Activity: 165

Merit: 26

Quote from: Anonymous User on November 10, 2024, 09:53:26 AM

The fact that he’s hesitant to sign a message to prove he solved puzzle #125 and #130 clearly suggests he’s not being truthful. Plus, if you look at the mini-puzzle he started, it seems suspicious. The user "sneeky777," who solved the mini-puzzle, appears to be Retired Coder himself using a secondary ID. The ID "sneeky777" registered on the same day, October 14th, when Retired Coder posted the mini-puzzle.

https://bitcointalksearch.org/topic/--5513047

He was truthful at least regarding #120. IDK about whether he solved his own mini puzzle, but that challenge was really easy to solve, if I knew what he really meant by it I would have solved it a few hours before the other user, since it was basically something like 20 lines of Python code. I was already checking millions of Bitcoin Cash balances by the time it got solved, instead of simply comparing some public key.

But for 125 and 130 it would cost hundreds of thousands of $ to even pay for the electricity required to solve, no matter how well the program or algorithm is optimized. So he likely has access to a grid, or the keys were known and this is all a big joke on all of us.

Anonymous User

newbie

Activity: 30

Merit: 0

Quote from: WanderingPhilospher

Quote

I solved #120, #125 and #130 for now

I still do not believe you solved these, or was the first to solve 120. You could easily sign a message for 125 and 130 to prove this. Maybe you did and I missed it? Or are you still waiting for your merit points to be "bumped" up before doing so?

The fact that he’s hesitant to sign a message to prove he solved puzzle #125 and #130 clearly suggests he’s not being truthful. Plus, if you look at the mini-puzzle he started, it seems suspicious. The user "sneeky777," who solved the mini-puzzle, appears to be Retired Coder himself using a secondary ID. The ID "sneeky777" registered on the same day, October 14th, when Retired Coder posted the mini-puzzle.

https://bitcointalksearch.org/topic/--5513047

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: kTimesG on November 09, 2024, 03:41:48 PM

My kernel does an insane amount of number of jumps per each kernel call, without any need to read and write useless information to global memory, except the initial and final landing spots, and potential found DPs metadata. And this only requires a very low amount of actual GPU memory.

This is a really good information tank you for sharing.

Quote from: citb0in on November 10, 2024, 07:32:59 AM

so he solved 120, 125 and 130. Where are the privkeys for them, I don't see them? What's the reason for not sharing them ?

He said that he is going to release the 125 key in some other mini-puzzle.

Quote from: ? on November 09, 2024, 10:26:51 AM

But yes I will start mini-puzzle for #125 as promised.

right here.

Quote from: WanderingPhilospher on November 09, 2024, 10:18:00 AM

I know that more but slower kangaroos, will solve faster than less, but faster kangaroos, when dealing with higher bit ranges. Speed versus "efficiency / optimization" (DP overhead) are two different things in my opinion.

Thanks for sharing, since I am learning the kangaroo algorithm all this kind of comments are good for me.

Quote from: WanderingPhilospher on November 09, 2024, 10:18:00 AM

Quote

I solved #120, #125 and #130 for now

I still do not believe you solved these, or was the first to solve 120. You could easily sign a message for 125 and 130 to prove this. Maybe you did and I missed it? Or are you still waiting for your merit points to be "bumped" up before doing so?

Agree a signed message should be good because it don't disclose anything and solver prove that him solve them.

Anonymous User

newbie

Activity: 30

Merit: 0

You misunderstood what I said.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: Anonymous User on November 09, 2024, 09:11:40 AM

Retired Coder shared the private key for puzzle #120 after a year, and in the thread below, he clearly mentions he has 20 PC of the RTX 4090(maybe he's lying).

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

If you look at the timing of puzzles #125 and #130, there’s just a two-month gap between them. So, do you still believe that in just two months, Retired Coder created a 1TB distinguished points table with 20 GPUs and also solved puzzle #130?

so he solved 120, 125 and 130. Where are the privkeys for them, I don't see them? What's the reason for not sharing them ?

b0dre

newbie

Activity: 22

Merit: 1

Quote from: kTimesG on November 09, 2024, 03:41:48 PM

Quote from: Etar on November 09, 2024, 02:21:01 PM

Quote from: ?? on ??

On-chip registers are insanely more times faster than reading and writing data from and into GPU memory, which is what the JLP kernel is all about. The loops are also in the bad order if what we care for are the jumps, not the kangaroos.

Maybe you wouldn't agree on this, but it is a really bad idea to dump millions of kangaroos into memory and read/jump/store them, to achieve the same efficiency as less kangaroos with a correct average jump size. Why? Because you can have a much much better efficiency by using fewer, faster kangaroos, and have the same results, but much faster.

Let's say instead of 128 kangaroos, we launch 4 kangaroos per thread. In this case, each kangaroo makes, say, 32 jumps.
To get real coordinates after inverse batch, you need to store x,y,z coordinates of 32 points for each kangaroo somewhere.
I don't understand how you store at least 128 x,y,z coordinates in registers. You'll have to use global memory. Shared memory won't fit all this.
Can you explain a little?

Why would you ever need 128 coordinates to be stored, if you only have 4 kangaroos jumping at the same time?

My kernel does an insane amount of number of jumps per each kernel call, without any need to read and write useless information to global memory, except the initial and final landing spots, and potential found DPs metadata. And this only requires a very low amount of actual GPU memory.

I am looking to find the optimal config for kangaroo in:
Start:804E83B7000000000000000000000000
Stop :804E83B7FFFFFFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 1
Range width: 2^96
Jump Avg distance: 2^48.04
Number of kangaroos: 2^24.00
Suggested DP: 21
Expected operations: 2^49.11

any idea?

kTimesG

member

Activity: 165

Merit: 26

Quote from: Etar on November 09, 2024, 02:21:01 PM

Quote from: ?? on ??

On-chip registers are insanely more times faster than reading and writing data from and into GPU memory, which is what the JLP kernel is all about. The loops are also in the bad order if what we care for are the jumps, not the kangaroos.

Maybe you wouldn't agree on this, but it is a really bad idea to dump millions of kangaroos into memory and read/jump/store them, to achieve the same efficiency as less kangaroos with a correct average jump size. Why? Because you can have a much much better efficiency by using fewer, faster kangaroos, and have the same results, but much faster.

Let's say instead of 128 kangaroos, we launch 4 kangaroos per thread. In this case, each kangaroo makes, say, 32 jumps.
To get real coordinates after inverse batch, you need to store x,y,z coordinates of 32 points for each kangaroo somewhere.
I don't understand how you store at least 128 x,y,z coordinates in registers. You'll have to use global memory. Shared memory won't fit all this.
Can you explain a little?

Why would you ever need 128 coordinates to be stored, if you only have 4 kangaroos jumping at the same time?

My kernel does an insane amount of number of jumps per each kernel call, without any need to read and write useless information to global memory, except the initial and final landing spots, and potential found DPs metadata. And this only requires a very low amount of actual GPU memory.

Etar

sr. member

Activity: 652

Merit: 316

Quote from: ?? on ??

On-chip registers are insanely more times faster than reading and writing data from and into GPU memory, which is what the JLP kernel is all about. The loops are also in the bad order if what we care for are the jumps, not the kangaroos.

Maybe you wouldn't agree on this, but it is a really bad idea to dump millions of kangaroos into memory and read/jump/store them, to achieve the same efficiency as less kangaroos with a correct average jump size. Why? Because you can have a much much better efficiency by using fewer, faster kangaroos, and have the same results, but much faster.

Let's say instead of 128 kangaroos, we launch 4 kangaroos per thread. In this case, each kangaroo makes, say, 32 jumps.
To get real coordinates after inverse batch, you need to store x,y,z coordinates of 32 points for each kangaroo somewhere.
I don't understand how you store at least 128 x,y,z coordinates in registers. You'll have to use global memory. Shared memory won't fit all this.
Can you explain a little?

?

Activity: -

Merit: -

Quote from: WanderingPhilospher on November 09, 2024, 10:18:00 AM

I still do not believe you solved these, or was the first to solve 120. You could easily sign a message for 125 and 130 to prove this. Maybe you did and I missed it? Or are you still waiting for your merit points to be "bumped" up before doing so?

I don't see any reasons to prove something, I don't care Cheesy

But yes I will start mini-puzzle for #125 as promised.

WanderingPhilospher

full member

Activity: 1232

Merit: 242

Shooters Shoot...

For DP overhead, it was discussed in JLP's Kangaroo thread.
His program tries to give a user the best DP to use, that will create the least amount of overhead.
The issue comes when you have multiple machines, like if you are using the server, it does not account for this, but I am pretty sure, it was discussed on how to come up with a more "optimal" DP, to decrease DP overhead, based on how many kangaroos are expected to be used.

Quote

Imagine a 10-band highway, and you have 1000 cars, and they all need to go from point A to point B before moving from point B to point C.

Yeah, I don't understand this. But it's ok, I don't need to. I don't understand how the speed is tied to this...the same would be true for the fastest of fastest kangaroos, using the fastest of fastest CPUs.

I know that more but slower kangaroos, will solve faster than less, but faster kangaroos, when dealing with higher bit ranges. Speed versus "efficiency / optimization" (DP overhead) are two different things in my opinion.

Quote

I solved #120, #125 and #130 for now

I still do not believe you solved these, or was the first to solve 120. You could easily sign a message for 125 and 130 to prove this. Maybe you did and I missed it? Or are you still waiting for your merit points to be "bumped" up before doing so?

nomachine

member

Activity: 503

Merit: 38

Quote from: Anonymous User on November 09, 2024, 09:11:40 AM

20 GPUs solved puzzle #130?

I also do something similar to this. 20 GPUs are not enough. This speed is impossible. It must be a three-digit number of graphics cards, even if you change the BIOS for the GPUs and use a different CUDA kernel. Grin

Anonymous User

newbie

Activity: 30

Merit: 0

Quote from: GR Sasa on November 09, 2024, 08:49:37 AM

I have the feeling that RetiredCoder is the creator of the puzzles himself.

No, he’s not the creator of this puzzle. The creator removed puzzle #120 to make the total prize 1000 BTC. Retired Coder shared the private key for puzzle #120 after a year, and in the thread below, he clearly mentions he has 20 PC of the RTX 4090(maybe he's lying).

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

If you look at the timing of puzzles #125 and #130, there’s just a two-month gap between them. So, do you still believe that in just two months, Retired Coder created a 1TB distinguished points table with 20 GPUs and also solved puzzle #130?

GR Sasa

member

Activity: 194

Merit: 14

I have the feeling that RetiredCoder is the creator of the puzzles himself.

?

Activity: -

Merit: -

Quote from: Akito S. M. Hosana on November 09, 2024, 07:53:08 AM

Quote from: ?? on ??

I won't post its source, but soon I will post some software for K (examining K*sqrt required ops) - from classic 2.1 to best 1.23 so people who are interested can learn some things.
I solved #120, #125 and #130 for now, for 130 DB with DP was about 1TB.
About big DP overhead in JLP you can check my old posts, I'm glad that it's super easy for you to make less number but faster kangaroos to reduce this overhead Grin

How do you managed and accessed the DP database efficiently, given its 1TB size. Did you employ any specific data structures or caching strategies to minimize access time?

You mentioned achieving a reduction in the required operations from classic 2.1 to best 1.23 in K * sqrt terms. Could you explain what methods or optimizations contributed most to this efficiency? How did you implement these changes in your software?

When transitioning from JLP's code to your custom implementation, what metrics did you use to benchmark efficiency improvements? Were there any specific areas where you saw the most significant speed gains?

Most answers in sources here: https://bitcointalksearch.org/topic/solving-ecdlp-with-kangaroos-part-1-2-rckangaroo-5517607
About DB - I stored it in RAM directly

Akito S. M. Hosana

jr. member

Activity: 42

Merit: 0

Quote from: ?? on ??

I won't post its source, but soon I will post some software for K (examining K*sqrt required ops) - from classic 2.1 to best 1.23 so people who are interested can learn some things.
I solved #120, #125 and #130 for now, for 130 DB with DP was about 1TB.
About big DP overhead in JLP you can check my old posts, I'm glad that it's super easy for you to make less number but faster kangaroos to reduce this overhead Grin

How do you managed and accessed the DP database efficiently, given its 1TB size. Did you employ any specific data structures or caching strategies to minimize access time?

You mentioned achieving a reduction in the required operations from classic 2.1 to best 1.23 in K * sqrt terms. Could you explain what methods or optimizations contributed most to this efficiency? How did you implement these changes in your software?

When transitioning from JLP's code to your custom implementation, what metrics did you use to benchmark efficiency improvements? Were there any specific areas where you saw the most significant speed gains?

Kelvin555

newbie

Activity: 8

Merit: 0

Quote from: gygy on November 08, 2024, 04:18:17 PM

Quote from: damiankopacz87 on November 08, 2024, 02:16:55 PM

Hi,

As far as I have studied bitcoin, it's highly impossible for this addresses to came from one deterministic wallet. Please, correct me if I am wrong. Creating deterministic wallet You have no influence on final shape of priv keys so Yo can not made them,1bit, 2bit, 3bit etc.

BR
Damian

You can have a deterministic wallet and get the first 160 address. Get those private keys, mask them for you need (flip ones and zeros as you wish), and create addresses for these modified private keys.

I think these keys are from a deterministic wallet but not just 256 keys, he created like 20000 keys or more, puzzle 65 private key might be the 10000th key masked down, 66 private key the 1500th key masked down and 67 the 7600th key masked down. Just in any case some people might use the keys to derive the seed, they will always fail cause the keys are not in order the way it was generated. He said he spent two years creating this challenge, if he just generated 256 keys and masked them down, it would not take 48 hours.

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 29. (Read 245726 times)