Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

1 to 0 ratio so far for random unknowns is 1027 to 1053.
#66 adds 65 more bits, so 2145 total.
Let's assume # 66 adds 65 more zeros and no 1s. Ratio would be 1027 to 1118.
Confidence interval for [1027 ... 1118] successes in 2045 trials with p = 1/2 is 95%.
In other words, even if puzzle 66 is full of zeros and the fixed 1, it's still in the 95% expectation range, so it would only be an anomaly from other perspectives.
If confidence range would be really low, we can suspect that the unknowns don't follow a uniform chance to appear, so there is manipulation (e.g. a hidden pattern).

Unfortunately naturally occurring randomness looks like patterns, until you simulate 10.000 times and you realize each one has completely different results over time. Sometimes the cumulative/average/whatever probabilities will go down, sometimes they will jump all over the place, intersect, don't intersect, swap places, dance with each other, or go into opposite extremes (and then return to the other side, or maybe not). An yes, this happens when you use a maximum entropy source, e.g. actual unpredictable noise. It will behave "strange" each time.

So yeah, there is a pattern, it's called randomness. What can we do about it? Let's pretend to assume that the 1 and 0 frequencies should approach an uniform distribution (central limit theorem). This will only happen when we have an infinite number of samples. Until that point, anything is possible within the confidence range, because of binomial distribution of limited number of samples. So #66 can be full of 0, full of 1, or any other combination, and it would still be completely normal within 95% accuracy.

Otherwise, filling out randomness on top of randomness by any pattern or set of patterns has the problem that it can be done in 2^n ways.
Even if assuming that we need to have an equal amount of 0 and 1 still means to check comb(65, 32) possibilities, which is a ***load of candidates itself, as it's the peak of the distribution.

Tell that to the linear regression

[Baskentliia]

Hello everyone, why do you think Puzzle 66 has not been found yet?
In April 2023, the reward was increased 10 times, but it still has not been found. What do you think is the reason?
Although many amateur people from all over the world searched, it could not be found.
Doesn't anyone have a chance?
Or is puzzle 66 somewhere outside this range?
What are your thoughts?

[albert0bsd]

Hello everyone, why do you think Puzzle 66 has not been found yet?
In April 2023, the reward was increased 10 times, but it still has not been found. What do you think is the reason?
Although many amateur people from all over the world searched, it could not be found.
Doesn't anyone have a chance?
Or is puzzle 66 somewhere outside this range?
What are your thoughts?

it was not found because the 66 bit space is absurdly big for regular brute force

It is simple, every extra bit increate the difficulty by a factor of TWO

Puzzle 63 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4 was redeem in June 2019
Puzzle 64 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN was reddem in September 2022

Puzzle 66 range is 4 times bigger than puzzle 64 make your own stimations

Puzzle 65 doesn't count because it was solved with the publickey with kangaro

Or is puzzle 66 somewhere outside this range?

No, all solved puzzles were in their respectives ranges, so please STOP spreading this shit.

[citb0in]

are you kidding ?

[shelby0930]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

[citb0in]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

it starts with 3. Good luck

[shelby0930]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

it starts with 3. Good luck

how do you say this ? is there a certain way to know if it starts from 3 ?

[albert0bsd]

how do you say this ? is there a certain way to know if it starts from 3 ?

There is not correct answer until the puzzle its solved it can be 2 or 3
Look:

Code:

>>> hex(2**129)
'0x200000000000000000000000000000000'
>>> hex(2**130)
'0x400000000000000000000000000000000'

[citb0in]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

it starts with 3. Good luck

how do you say this ? is there a certain way to know if it starts from 3 ?

of course there is. But I am not allowed to tell you the details.

[shelby0930]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

it starts with 3. Good luck

how do you say this ? is there a certain way to know if it starts from 3 ?

of course there is. But I am not allowed to tell you the details.

A Mathematical way ?

[nomachine]

Hello everyone, why do you think Puzzle 66 has not been found yet?
What are your thoughts?

To find a 66-bit number within 10 days with regular brute force, you would need to check approximately 200 giga/hashes - addresses per second.  It doesn't matter if it's an even or odd number.


Look here average PRNGs speed
https://developer.nvidia.com/gpugems/gpugems3/part-vi-gpu-computing/chapter-37-efficient-random-number-generation-and-application


And we need PRNGs Average Time:  0.000000000002  seconds to solve Puzzle 66  

And then all other parts of the script no slower than this.

It's not a programming language problem.

There is no hardware on Earth that could reach this speed.

For 256-bit number a Type III civilization is a needed to solve this. A million years ahead of us.

[satashi_nokamato]

can anyone tell me if the puzzle 130 starts from 2 or 3 ?  since the range is 0x200000000000000000000000000000000 and 0x3ffffffffffffffffffffffffffffffff can anyone tell me if its private key starts from 2 or 3 ?

Try this to figure it out, multiply puzzle #130 by 4 then subtract the result from this key

Code:

0x0000000000000000000000000000001000000000000000000000000000000000
Public_key=
02e4f3fb0176af85d65ff99ff9198c36091f48e86503681e3e6686fd5053231e11

Then divide the result by 4 and subtract add the result to puzzle key, you should see

Code:

0x0000000000000000000000000000000400000000000000000000000000000000
Public_key=
037564539e85d56f8537d6619e1f5c5aa78d2a3de0889d1d4ee8dbcb5729b62026

The reason why that is happening  is because it starts with 3.

[albert0bsd]

Try this to figure it out, multiply puzzle #130 by 4 then subtract the result from this key

Code:

0x0000000000000000000000000000001000000000000000000000000000000000
Public_key=
02e4f3fb0176af85d65ff99ff9198c36091f48e86503681e3e6686fd5053231e11

Then divide the result by 4 and subtract the result from puzzle key, you should see

Code:

0x0000000000000000000000000000000300000000000000000000000000000000
Public_key=
0238381dbe2e509f228ba93363f2451f08fd845cb351d954be18e2b8edd23809fa

The reason why that is happening  is because it starts with 3.

There is a flag in your logic if you don't see it, then it is a disappointment

[kTimesG]

To find a 66-bit number within 10 days with regular brute force, you would need to check approximately 200 giga/hashes - addresses per second.

Wrong. First of all, #66 is a 65-bit problem. Bit 66 is always 1. Computationally it can be discarded, just like all the known 0 bits.

Code:

>>> n=2**65
>>> time_in_s = 10 * 86400
>>> n/time_in_s/1024/1024/1024
39768.2157037037
>>> hashes_per_s = 200 * 2**30
>>> n / hashes_per_s / 86400
1988.4107851851852

10 days to find requires 38 TH/s (7% of total current Bitcoin network hash rate)
200GH/s requires 1988 days.

Now, a "hash" means "obtain some EC point for which k is known + SHA + RIPE + check match".  No one said those are zero-overhead operations.

I'd dare to assert that #130 will be found before #66.  I have some theoretical and practical thoughts that make me conjunct that puzzles 135 to 160 will also be found before #66, in absence of any surplus proved bit of information we don't yet know (not non-sense).

[BD Technical]

I don't know why but I'm smelling a big scam. Because a newbie that offer more than 12 000€ to solve a following of numbers this is strange...

I feel the same way because no one will give you such a big big prize or big money for this small thing.  Because if it is not iskam, if it is not iskam, someone is so big or so.  No one will show big offers.  Maybe this is his new plan to increase Setar's ID or to take merit in his ID with their fake news. In that case, I will say whether anyone got this offer by participating.  Please reply me.
 If not, this post is to the moderator.  I will be forced to report because I don't think of anything other than harassing people like this Iskam post. You and I brother are right. It is Islam. I have seen it for a long time but I have seen it for so long.

[WanderingPhilospher]

To find a 66-bit number within 10 days with regular brute force, you would need to check approximately 200 giga/hashes - addresses per second.

Wrong. First of all, #66 is a 65-bit problem. Bit 66 is always 1. Computationally it can be discarded, just like all the known 0 bits.

Code:

>>> n=2**65
>>> time_in_s = 10 * 86400
>>> n/time_in_s/1024/1024/1024
39768.2157037037
>>> hashes_per_s = 200 * 2**30
>>> n / hashes_per_s / 86400
1988.4107851851852

10 days to find requires 38 TH/s (7% of total current Bitcoin network hash rate)
200GH/s requires 1988 days.

Now, a "hash" means "obtain some EC point for which k is known + SHA + RIPE + check match".  No one said those are zero-overhead operations.

I'd dare to assert that #130 will be found before #66.  I have some theoretical and practical thoughts that make me conjunct that puzzles 135 to 160 will also be found before #66, in absence of any surplus proved bit of information we don't yet know (not non-sense).

I would say that if someone has been working on #130 since #125 was found then yes, it will be found, or should be found before #66, but I don't agree that #135 and higher will be found before #66.  There are 2 main pools out there and one is already at 11%, for #66. But I know of others who have 'solo' pools/work, working on #66 as well. The one pool just offered a bonus for the key finder, so I imagine as the % of completion gets higher, more single card users will join in, hoping to grab that bonus. But we shall see.

For #135, 135 / 2 + 1.05 = 68.55 ops needed to find key using Kangaroo algo, so 2^68.55 ops. #66 = max 2^65 ops.

It will be an interesting race between #66 and those #135 and higher.

[kTimesG]

I would say that if someone has been working on #130 since #125 was found then yes, it will be found, or should be found before #66, but I don't agree that #135 and higher will be found before #66.

For #135, 135 / 2 + 1.05 = 68.55 ops needed to find key using Kangaroo algo, so 2^68.55 ops. #66 = max 2^65 ops.

It will be an interesting race between #66 and those #135 and higher.

That is assuming pollard kang remains best time reduction algo in the next, say, 100 years. Look, we all have beliefs. I believe cracking both SHA and RIPE of an insanely big number is far less likely than screwing around with EC properties until O(sqrt(n)) goes down in some way or another. We shall see.

[WanderingPhilospher]

I would say that if someone has been working on #130 since #125 was found then yes, it will be found, or should be found before #66, but I don't agree that #135 and higher will be found before #66.

For #135, 135 / 2 + 1.05 = 68.55 ops needed to find key using Kangaroo algo, so 2^68.55 ops. #66 = max 2^65 ops.

It will be an interesting race between #66 and those #135 and higher.

That is assuming pollard kang remains best time reduction algo in the next, say, 100 years. Look, we all have beliefs. I believe cracking both SHA and RIPE of an insanely big number is far less likely than screwing around with EC properties until O(sqrt(n)) goes down in some way or another. We shall see.

Ok, but 100 years? #66 will be solved before then 😉

It’ll be an interesting arms race…and that’s only if a group of people are interested in finding the remaining addresses. I have a hunch, they will.

[kenshiro12241]

this might be a dumb question, but i want to ask that is the range of private keys which have P2PKH addresses, i searched for a answer and i found that it is between 2^96 - 2^97

[albert0bsd]

this might be a dumb question, but i want to ask that is the range of private keys which have P2PKH addresses, i searched for a answer and i found that it is between 2^96 - 2^97

the range is:
from : 1
to : 115792089237316195423570985008687907852837564279074904382605163141518161494337

or in hexadecimal:

from : 0x1
to : 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

That is the full range, but theorically any range of 2^160 keys can have altmost all the P2PKH addresses