Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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

[ccinet]

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

+100!
log2(0)=2^0
log2(115792089237316195423570985008687907852837564279074904382605163141518161494337)=2^256

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

What is your source to indicate that?

[vneos]

I have a question, which is faster, generating the public key and then calculating the hash160 by adding and subtracting the private key, compared to calculating the hash160 by adding and subtracting the public key?

For example, I already know the public key of private key 1, to calculate the hash160 address of private key 2, is it faster to generate the public key and then generate the hash160 address by private key 2, or is it faster to calculate the hash160 by adding 1 to the public key of private key 1?

[NotATether]

Has anyone managed to find #64 and #125 (again) to get their private keys?