Author

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

full member
Activity: 282
Merit: 114
Contests and puzzles are always interesting. But I, as a regular user, would like to get a greater guarantee of payment in case of winning. It will be very unpleasant to waste your time, and then, get nothing.

What would you like to guarantee in the world of cryptocurrencies? That is the fact that the one who has the private key - the means belong to him. Anyway, wait ... I have a guarantee for you ...

https://blockchair.com/bitcoin/outputs?q=transaction_id(56857085)&s=index(asc)#
full member
Activity: 602
Merit: 100
Contests and puzzles are always interesting. But I, as a regular user, would like to get a greater guarantee of payment in case of winning. It will be very unpleasant to waste your time, and then, get nothing.
member
Activity: 245
Merit: 17
It is still called "the 32 BTC prize"  but the prize is really more than 100 BTC ... 
member
Activity: 245
Merit: 17
There is nothing "hacked" so far. The Distributed Pollard Kangaroo algorithm is known since 2000.

Let's get some numbers for the 90 bit challenge:

BitCrack runs at about 715 MKeys/s on Tesla V100 - look here.
If we remove hash160, the rate would be 1430 Mj/s. Mj here stands for million kangaroo jumps.
The algorithm has expected run time 2*sqrt(b-a) jumps, here b-a = 289.
This gives expected running time of 09:39:55.
Looks quite fast.
Of course this is just a probability, if lucky, the time goes down to 3-4 hours, or not lucky, then time doubles to 18-20 hours.
Or really unlucky, with triple the expected run time - 1 day 04:59:47.
Since the algorithm scales linearly, one could use multiple V100, let's say 8, resulting in expected time 01:12:29.
The price for 8x V100 in google cloud is $15/hour.

Someone having 20x RX 480, each running BitCrack at 107 MKeys/s.
Using the same assumptions that would give 214 Mj/s each, for a total of 4280 Mj/s.
Please note, that for complex code AMD OpenCL compiler is very, very bad, and the system might crash, or even worse, bug the computations.
Assuming 150W per RX 480, the system would consume 3kW.

|------+-------------+---------+---+-----------------+-------------|
|      |     8x Tesla V100     |   |         20x RX 480            |
| bits +-------------+---------+---+-----------------+-------------|
|      |    time     |  price  |   |       time      |    power    |
|------+-------------+---------+---+-----------------+-------------|
|   90 |    01:12:29 |     $18 |   |        03:13:45 |     9.7 kWh |
|   95 |    06:50:04 |    $103 |   |        18:16:05 |    54.8 kWh |
|  100 | 1d 14:39:43 |    $580 |   |     4d 07:20:24 |   310.0 kWh |
|  105 | 9d 02:42:22 |   $3281 |   |    24d 08:34:45 |  1753.7 kWh |
|  110 |   51 days   |  $18558 |   |   137 days      |  9920.6 kWh |
|  115 |  291 days   | $104979 |   | 2 years 49 days | 56119.6 kWh |
|------+-------------+---------+---+-----------------+-------------|

Of course these numbers could easily double when unlucky.
And someone else could solve it before, then it's all a loss.


REad this

You forgot to add that these calculations concern the execution of the script using the POLLARD KANGAROS method which has nothing to do with the BitCrack key search method. The implemented / ready solution to finding a key using the POLLARD KANGAROS method is not available anywhere, so it is only in the possession of people (I suspect that countable on the fingers of one hand) who wrote it themselves. Being in the possession of this solution - running it on any computer will be a million percent more profitable than any computer equipment of modern times. BitCrack for every next address needs 2x more time to scan the entire scope. For my example - # 64 will occupy with my equipment (over 100x TESLA) - full six months, so presenting the table information about breaking # 115 through the eight GPU in two hundred days is firstly - misleading, and second - a perfect example on what difference we talk between BitCrack and Pollard Kangaros (which is the only one that can refer to this table [I do not know - I do not have {so I do not check}] whether it is reflected in reality)


taking this as a reference : " # 64 will occupy with my equipment (over 100x TESLA) - full six months"

we can draw the rule (estimated for over 100xTESLA):
case #64 0.50  year
case #65 1.00  year
case #66 2.00  years

case #n  2^(n-65)  years

member
Activity: 245
Merit: 17
TRUE

I just re-posted that for the personne who asked about AWS.
full member
Activity: 282
Merit: 114
There is nothing "hacked" so far. The Distributed Pollard Kangaroo algorithm is known since 2000.

Let's get some numbers for the 90 bit challenge:

BitCrack runs at about 715 MKeys/s on Tesla V100 - look here.
If we remove hash160, the rate would be 1430 Mj/s. Mj here stands for million kangaroo jumps.
The algorithm has expected run time 2*sqrt(b-a) jumps, here b-a = 289.
This gives expected running time of 09:39:55.
Looks quite fast.
Of course this is just a probability, if lucky, the time goes down to 3-4 hours, or not lucky, then time doubles to 18-20 hours.
Or really unlucky, with triple the expected run time - 1 day 04:59:47.
Since the algorithm scales linearly, one could use multiple V100, let's say 8, resulting in expected time 01:12:29.
The price for 8x V100 in google cloud is $15/hour.

Someone having 20x RX 480, each running BitCrack at 107 MKeys/s.
Using the same assumptions that would give 214 Mj/s each, for a total of 4280 Mj/s.
Please note, that for complex code AMD OpenCL compiler is very, very bad, and the system might crash, or even worse, bug the computations.
Assuming 150W per RX 480, the system would consume 3kW.

|------+-------------+---------+---+-----------------+-------------|
|      |     8x Tesla V100     |   |         20x RX 480            |
| bits +-------------+---------+---+-----------------+-------------|
|      |    time     |  price  |   |       time      |    power    |
|------+-------------+---------+---+-----------------+-------------|
|   90 |    01:12:29 |     $18 |   |        03:13:45 |     9.7 kWh |
|   95 |    06:50:04 |    $103 |   |        18:16:05 |    54.8 kWh |
|  100 | 1d 14:39:43 |    $580 |   |     4d 07:20:24 |   310.0 kWh |
|  105 | 9d 02:42:22 |   $3281 |   |    24d 08:34:45 |  1753.7 kWh |
|  110 |   51 days   |  $18558 |   |   137 days      |  9920.6 kWh |
|  115 |  291 days   | $104979 |   | 2 years 49 days | 56119.6 kWh |
|------+-------------+---------+---+-----------------+-------------|

Of course these numbers could easily double when unlucky.
And someone else could solve it before, then it's all a loss.


REad this

You forgot to add that these calculations concern the execution of the script using the POLLARD KANGAROS method which has nothing to do with the BitCrack key search method. The implemented / ready solution to finding a key using the POLLARD KANGAROS method is not available anywhere, so it is only in the possession of people (I suspect that countable on the fingers of one hand) who wrote it themselves. Being in the possession of this solution - running it on any computer will be a million percent more profitable than any computer equipment of modern times. BitCrack for every next address needs 2x more time to scan the entire scope. For my example - # 64 will occupy with my equipment (over 100x TESLA) - full six months, so presenting the table information about breaking # 115 through the eight GPU in two hundred days is firstly - misleading, and second - a perfect example on what difference we talk between BitCrack and Pollard Kangaros (which is the only one that can refer to this table [I do not know - I do not have {so I do not check}] whether it is reflected in reality)
full member
Activity: 282
Merit: 114
Using any cloud in cryptocurrency topics is:
1. Reluctantly tolerated by them
2. Unprofitable (at this level regarding this topic)
member
Activity: 245
Merit: 17
There is nothing "hacked" so far. The Distributed Pollard Kangaroo algorithm is known since 2000.

Let's get some numbers for the 90 bit challenge:

BitCrack runs at about 715 MKeys/s on Tesla V100 - look here.
If we remove hash160, the rate would be 1430 Mj/s. Mj here stands for million kangaroo jumps.
The algorithm has expected run time 2*sqrt(b-a) jumps, here b-a = 289.
This gives expected running time of 09:39:55.
Looks quite fast.
Of course this is just a probability, if lucky, the time goes down to 3-4 hours, or not lucky, then time doubles to 18-20 hours.
Or really unlucky, with triple the expected run time - 1 day 04:59:47.
Since the algorithm scales linearly, one could use multiple V100, let's say 8, resulting in expected time 01:12:29.
The price for 8x V100 in google cloud is $15/hour.

Someone having 20x RX 480, each running BitCrack at 107 MKeys/s.
Using the same assumptions that would give 214 Mj/s each, for a total of 4280 Mj/s.
Please note, that for complex code AMD OpenCL compiler is very, very bad, and the system might crash, or even worse, bug the computations.
Assuming 150W per RX 480, the system would consume 3kW.

|------+-------------+---------+---+-----------------+-------------|
|      |     8x Tesla V100     |   |         20x RX 480            |
| bits +-------------+---------+---+-----------------+-------------|
|      |    time     |  price  |   |       time      |    power    |
|------+-------------+---------+---+-----------------+-------------|
|   90 |    01:12:29 |     $18 |   |        03:13:45 |     9.7 kWh |
|   95 |    06:50:04 |    $103 |   |        18:16:05 |    54.8 kWh |
|  100 | 1d 14:39:43 |    $580 |   |     4d 07:20:24 |   310.0 kWh |
|  105 | 9d 02:42:22 |   $3281 |   |    24d 08:34:45 |  1753.7 kWh |
|  110 |   51 days   |  $18558 |   |   137 days      |  9920.6 kWh |
|  115 |  291 days   | $104979 |   | 2 years 49 days | 56119.6 kWh |
|------+-------------+---------+---+-----------------+-------------|

Of course these numbers could easily double when unlucky.
And someone else could solve it before, then it's all a loss.


REad this
newbie
Activity: 7
Merit: 0
This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? Cheesy

I am the creator.

You are quite right, 161-256 are silly.  I honestly just did not think of this.  What is especially embarrassing, is this did not occur to me once, in two years.  By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity.  I will spend from 161-256 to the unsolved parts, as you suggest.  In addition, I intend to add further funds.  My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key).  Probably in the next few weeks.  At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology.  The "large bitcoin collider" is especially innovative and interesting!

Just a reminder for those who joined us here lately ...

This guy, saatoshi_rising, is certainly the creator since he moved the range  161-256 as promised on July 11th 2017
 

Thnx, by the way has anyone tried using AWS for this?
member
Activity: 245
Merit: 17
This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? Cheesy

I am the creator.

You are quite right, 161-256 are silly.  I honestly just did not think of this.  What is especially embarrassing, is this did not occur to me once, in two years.  By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity.  I will spend from 161-256 to the unsolved parts, as you suggest.  In addition, I intend to add further funds.  My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key).  Probably in the next few weeks.  At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology.  The "large bitcoin collider" is especially innovative and interesting!

Just a reminder for those who joined us here lately ...

This guy, saatoshi_rising, is certainly the creator since he moved the range  161-256 as promised on July 11th 2017
 
newbie
Activity: 7
Merit: 0
I've got a question.
Are we sure that the numbers are 100% random? I mean can there be a way of predicting exactly what the next key is or just it's range of values?

Yes. The numbers are 100% random.
This knowledge comes directly from the creator.
Does that mean that even predicting the region in 2^n is considered luck or is there a pattern in region changes?

This is known ... Each subsequent address is in the range of one higher than the previous one, i.e. if address # 58 was in 2 ^ 57 then # 59 is in 2 ^ 58. This is the only rule that takes place here and also comes from the creator.
So it's not really a puzzle, just a race. Making a pool would speed things up but then dividing the prize would be a problem, ok got it
full member
Activity: 282
Merit: 114
I've got a question.
Are we sure that the numbers are 100% random? I mean can there be a way of predicting exactly what the next key is or just it's range of values?

Yes. The numbers are 100% random.
This knowledge comes directly from the creator.
Does that mean that even predicting the region in 2^n is considered luck or is there a pattern in region changes?

This is known ... Each subsequent address is in the range of one higher than the previous one, i.e. if address #58 was in 2 ^ 57 then #59 is in 2 ^ 58.
2^n-1
n = number of wallet in this puzzles. (now the lowest prize is in #62)
This is the only rule that takes place here and also comes from the creator.
newbie
Activity: 7
Merit: 0
I've got a question.
Are we sure that the numbers are 100% random? I mean can there be a way of predicting exactly what the next key is or just it's range of values?

Yes. The numbers are 100% random.
This knowledge comes directly from the creator.
Does that mean that even predicting the region in 2^n is considered luck or is there a pattern in region changes?
full member
Activity: 282
Merit: 114
I've got a question.
Are we sure that the numbers are 100% random? I mean can there be a way of predicting exactly what the next key is or just it's range of values?

Yes. The numbers are 100% random.
This knowledge comes directly from the creator.
newbie
Activity: 7
Merit: 0
I've got a question.
Are we sure that the numbers are 100% random? I mean can there be a way of predicting exactly what the next key is or just it's range of values?
member
Activity: 174
Merit: 12
Can someone calculate 60-63% key range for 62 bit key?

If full range 62 key:
Hex: 0x2000000000000000 - 0x3FFFFFFFFFFFFFFF
Dec: 2305843009213693952 - 4611686018427387903

that:
2305843009213693952 + 60% = 3689348814741910528  0x3333333333333400
2305843009213693952 + 63% = 3758524105018320896  0x3428F5C28F5C2800

0x3333333333333400 - 0x3428F5C28F5C2800

Yes or no?

/translated google/
jr. member
Activity: 59
Merit: 3

Interesting observation. I wonder if it's related to the method the puzzle creator used to create the keys:

There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty)
IMHO I think it is. Even if the creator of the puzzle didn't do it purposly the software he used most probably was adjusted to generate the most complicated keys within the each given range.
Sorry, but I think your math is actually wrong. You are using the range 1..2^bit to calculate the occurrence in the range, but you should be using the range 1..(2^bit - 2^(bit-1)). That would explain why all your results are occurring at > 50% of the range.
Ok. For example #60
60 | 0xFC07A1825367BBE | 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su | 1152921504606846975 | 98.5% | 1135041350219496382
1135041350219496382 is how many percents out of full range 1152921504606846975 under your calcs?
I was also wrong on part of my response. The range I stated (1..(2^bit - 2^(bit-1))) is the right cardinality (number of values), but the values given by that range are wrong. The range should be 2^(bit-1) .. 2^bit.

Not completely sure about the math, but I think the percentile for bit 60 using this range is
Code:
(1135041350219496382 - 2^59) / 2^60 = .48 = 48%
I've got your point, man. You mean the position of the hit number within the range 59->60. I was calculation the position of the hit number within the full range between 0->60.
Anyhow, both of this way maybe usefull to find any dependencies between the hit numbers. This is actually what I'm doing, I'm searching any common, let's call it coefficient, that can be used to narrow the search range for the hit number.
I understand that creator mentioned already that numbers were generated randomly, but I wanna try )). I believe that if any software was used to get this numbers there was definetly an algorythm used.
sr. member
Activity: 459
Merit: 251
Can someone calculate 60-63% key range for 62 bit key?
newbie
Activity: 18
Merit: 1
member
Activity: 259
Merit: 47
2Babi Ngetot Try calculate not real privat key. Example pkey+1, pkey+2, pkey+3 and etc.
Jump to: