Author

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

member
Activity: 245
Merit: 17

...snip...

goto step 2 and repeat.

each cycle will take 16*10min = 160 min if you have one GPU.

This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL
    

I like the idea of including randomness in the process. Because in the end you don't have to search any repeating patterns if consequently followed (0101, 1f1f).
It is possible in theory these patterns appear but very unlikely in practice.

I thought about ignoring ranges completely and just generate random starting offsets for each GPU working point. This would raise the factor of luck by a magnitude but make inclusion of deterministic methods harder.

You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...


jr. member
Activity: 38
Merit: 18
o great translate.google, come and help me)

According to the author, the puzzle addresses are formed from truncated leading zeros of a hierarchical deterministic wallet. This means that the distribution is close to the ideal random, as far as hmac_sha512 is good, that is, very much.

There is no magic formula.  As the author of the puzzle stated the addresses were selected randomly.  Random = no formula, got it?  Continue to waste your time looking but you will never find it.

Alas, blockheads constantly try to solve "something" in this, usually by trying to spot a pattern in walls of digits in every possible notation, missing the point that brute-forcing the private keys is only possible option, and there is no other possible approach. Looks like many humans are not only bad in comprehending extremely large numbers, they also fail to understand what word "random" means.

Lol. I remind you once again that the private key does not result from any algorithm. It's located at 2 ^ 59 and only this rule applies here.

why are you trying so hard to find a pattern where there are none?
this is not even "exactly a puzzle", i think you are misled by the choice of words by the starter. all these numbers you are trying to find a pattern for are chosen using a cryptographically secure pseudorandom number generator which has no pattern, if it did then it would have never been "secure" and should be considered broken.

Stop! Randomness does not mean the absence of patterns. What do you know about game theory?)

Do you have a formula or anything close? What exactly do your calculations mean? I'll appreciate some explanations!

Yes, i have.

I know it's been said already but to those of you who are posting these giant walls of numbers and analysis you're wasting your time. The only way these wallets will be cracked is by brute force. If you manage to find a flaw in the process used to generate random addresses you'd be much better off focusing on a larger payout. That being said, if you do manage to come up with a solid theory but lack the capacity to test a certain keyspace, post it here. I'll run it for you and even let you sweep the wallet yourself if you prove to be correct. The conjecture is ugly to try to read here and generally irrelevant nonsense.

Ok) let's start


More than a year I have been watching this topic. But no one has described many obvious things.


What random factors affect search?


1) Classic factor 50%: on average we will find prvkey by sorting around 50% of the range.
(example, its stat print vanity-gen, where search vanity address)


2) The classical theory of probability, as the average distribution.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
Parts with less prvkeys have a higher probability of finding a prvkey in the next puzzle.
In the theory of games, when the casino guarantees that all possible options will fall out approximately equal to the number of times.
+50% prob

3) The classical theory of probability, as in time.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
The lowest probability will be in the part in which prvkey was found the previous time.
In game theory, this is known as the "double up game".
+50%prob

Code:
C:\php-5.6.32>php _puzzle2prob.php
[002]{.........................$........................} 2.0%
[003]{.....................................$............} 4.0%
[004]{$.................................................} 5.9%
[005]{...............$..................................} 7.8%
[006]{..........................$.......................} 9.6%
[007]{.........$........................................}11.4%
[008]{.....................................$............} 9.6%
[009]{.........................................$........}14.9%
[010]{$.................................................}11.4%
[011]{......$...........................................}18.3%
[012]{...............$..................................}13.2%
[013]{.............$....................................}21.5%
[014]{..............$...................................}23.1%
[015]{...............................$..................}24.6%
[016]{............................$.....................}26.1%
[017]{.......................$..........................}27.6%
[018]{.........................$........................}27.6%
[019]{..................$...............................}30.5%
[020]{................................$.................}31.9%
[021]{....................................$.............}33.2%
[022]{.....................$............................}34.6%
[023]{................$.................................}35.9%
[024]{....................................$.............} 5.9%
[025]{................................................$.}38.4%
[026]{...............................$..................}19.9%
[027]{.................................$................}40.9%
[028]{..................................$...............}42.1%
[029]{........................$.........................}43.2%
[030]{..............................................$...}44.4%
[031]{...............................................$..}45.5%
[032]{......................$...........................}46.6%
[033]{.................................$................}11.4%
[034]{................................$.................}24.6%
[035]{........$.........................................}49.7%
[036]{...........$......................................}50.7%
[037]{......................$...........................} 9.6%
[038]{...$..............................................}52.7%
[039]{........$.........................................} 7.8%
[040]{.........................................$........}46.6%
[041]{................$.................................}30.5%
[042]{...............$..................................}45.5%
[043]{..................................$...............}26.1%
[044]{.....................................$............}51.7%
[045]{......$...........................................}49.7%
[046]{.......................$..........................}44.4%
[047]{...................................$..............}60.6%
[048]{.................$................................}61.3%
[049]{......................$...........................}21.5%
[050]{....$.............................................}62.9%
[051]{.........................................$........}19.9%
[052]{...........................................$......}64.3%
[053]{.........................$........................}50.7%
[054]{.....$............................................}65.8%
[055]{.................................$................}35.9%
[056]{...........$......................................}33.2%
[057]{.............................................$....}67.8%
[058]{...................$..............................}68.4%
[059]{.........................................$........}14.9%
[060]{................................................$.}50.7%
[___]{__________________________________________________}
[N50]{67742137477176633261752351776775413253777072715507}
[N25]{|5|3|2|5|7|4|6|3|4|4|4|4|4|7|7|5|2|4|5|7|4|4|3|2|9}
[N10]{|4   |5   |5   |4   |3   |7   |3   |6   |3   |5   }
[N 5]{|4        |4        |5        |5        |4        }
[N 2]{|4                       |5                       }

The graph is built for Nmax = 50 for convenience (as the well-known prvkey is a little over 50 and a lot less than 100)
Below - the theory of probability as an average distribution, from 0 to 9 points, for N = 50,25,10,5,2.
On the side, the theory of probability, as in time, is indicated in% (it does not matter in principle, it can be expressed in points of 0-9, etc.).

It will be enough just to add a code taking into account these probabilities to the pool in order to start searching from them and find the average faster.


4) The paradox of birthdays as a hash function ripemd160
The most useless case for us, since the simplification to 2 ^ 80 is still too great.

5) The paradox of birthdays, as recurring characters in the password (prvkey).
This is much more interesting.
And this affects 99% of the existing id / password generators / token-csrf and so on.
(Andzhig constantly writes about this, he just doesn't know what it is called, the "collective unconscious" lol)
Take the known prvkeys in base10 and analyze how often repetitions occur in them.

Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
[ Puzzle Analyzer ]
[~] Analyse...
[+] success
[i] Origin keys:
 [3]
 [7]
 [8]
 [21]
 [49]
 [76]
 [224] /2=1
 [467]
 [514]
 [1155] /2=2
 [2683]
 [5216]
 [10544] /2=1
 [26867] /2=1
 [51510] /2=2
 [95823]
 [198669] /2=2
 [357535] /3=1/2=1
 [863317] /2=1
 [1811764] /3=1
 [3007503] /3=1/2=1
 [5598802] /2=2
 [14428676] /2=2
 [33185509] /2=2
 [54538862] /2=2
 [111949941] /4=1/3=1/2=1
 [227634408] /2=2
 [400708894] /3=1/2=2
 [1033162084] /2=3
 [2102388551] /2=4
 [3093472814] /2=2
 [7137437912] /3=1/2=2
 [14133072157] /3=1/2=2
 [20112871792] /3=2/2=1
 [42387769980] /2=3
 [100251560595] /4=1/3=1/2=1
 [146971536592] /2=4
 [323724968937] /3=1/2=3
 [1003651412950] /3=2/2=1
 [1458252205147] /3=2/2=2
 [2895374552463] /3=1/2=3
 [7409811047825] /2=5
 [15404761757071] /4=1/3=1/2=3
 [19996463086597] /4=1/3=1
 [51408670348612] /2=5
 [119666659114170] /5=1/4=1/2=1
 [191206974700443] /3=2/2=3
 [409118905032525] /3=2/2=3
 [611140496167764] /4=2/3=1/2=1
 [2058769515153876] /4=1/2=4
 [4216495639600700] /4=1/3=1/2=2
 [6763683971478124] /3=2/2=4
 [9974455244496708] /5=1/3=1/2=2
 [30045390491869460] /4=1/3=2/2=2
 [44218742292676576] /4=1/3=3
 [138245758910846506] /3=2/2=4
 [199976667976342048] /4=2/3=1/2=1
 [525070384258266266] /4=2/3=1/2=2
 [1135041350219496420] /4=1/3=2/2=4
[x] EXIT.

For
  [9974455244496708] /5=1/3=1/2=2
means one 5x repeat, one 3x repeat, two 2x repeat

What part of the whole range will be set /5=1/3=1/2=2 repetitions?
Unfortunately, I am not strong in combinatorics to create a universal formula for calculating any large ranges.
But we can empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10 ^ 18 (~ 2 ^ 60)
(prvkey consists of "1234567890" and a length of 18)

Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
(str = "1234567890" and length = 18)
[range^order] 10^18 = ~2^60
[range] 10
[order] 18

[~] Generate Passwords...
[pairs/pcs] pairs=9482; avg=9.5; /0=0.0%/1=0.0%/2=0.0%/3=0.0%/4=0.0%/5=0.0%/6=0.0%/7=0.0%/8=14.2%/9=39.0%/10=33.5%/11=11.2%/12=1.9%/13=0.2%/../13;
  - 9482 repetitions found in 1000 random prvkeys
  - prvkey c less than 7 or more than 13 by any repetitions - rare or absent
  - in 39.0% prvkeys 9 any repetitions were found, in 35% there are 10 any repetitions, ..
[pairN/pairs] pairs=9482; /2=29.9%/3=35.0%/4=22.3%/5=9.9%/6=2.5%/7=0.4%/../7;
  - 9482 make up 29.9% 2x repeats, 35% 3x, 22% 4x, ..
[pairN/pcs] pcs=1000; /2=283.4%/3=165.7%/4=70.6%/5=23.5%/6=4.8%/7=0.6%/../7;
  - in each prvkey found 2-3 2x repeat, 1-2 3x, 0-1 4x, ..
  - in 235 prvkey 5x repetition found, in 48 prvkey 6x repetition found, ..

Then, to narrow the search range to 39.0%, we could only check prvkeys with 9 any repetitions. (/9=39.0%/)
These 9 any repetitions will form two 2x and one 3x (/2=283.4%/3=165.7%/)
or
Then, to narrow the search range to 33.5%, we could only check prvkeys with 9 any repetitions. (/10=33.5%/)
These 10 any repetitions form two 3x and one 4x (/3=165.7%/4=70.6%/)

It is necessary to remake the program generator (BitCrack / Vanity) from a naive increment to a smart one.
But there is a problem. The increment does not require resources at all, and smart generation will require so many resources that we will spend a lot more on generating the prvkey candidate than on calculating ecdsa pubkey.
Especially, it is expensive for the GPU, where every extra IF () leads to a loss of concurrency of simultaneous calculations.

What to do?
If BitCrack counts 250Mh / s (gtx1070), then for 1 hour, 250,000,000 * 3,600 = 9 * 10^11. Round up to 10^12
0000001000000000000 (=10^12)
1152921000000000000 (~ 2^60)
2305843000000000000 (~ 2^61)
Let's drop 1-12 first and last 19 bits - we can control 6 bits with a minimum step of about 1 hour of operation of 1 video card.
We can generate a new task, excluding ranges without repetitions.

What part of the whole range will be set /2=1 repetitions?
Empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10^6
(prvkey consists of "1234567890" and a length of 6)

Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
(str = "1234567890" and length = 6)
[range^order] 10^6 = ~2^20
[range] 10
[order] 6

[~] Generate Passwords...
[pairs/pcs] pairs=1283; avg=1.3; /0=16.1%/1=45.9%/2=31.7%/3=6.2%/4=0.1%/../4;
[pairN/pairs] pairs=1283; /2=74.0%/3=23.5%/4=2.1%/5=0.3%/../5;
[pairN/pcs] pcs=1000; /2=95.0%/3=15.1%/4=0.9%/5=0.1%/../5;

Then, to narrow the search range to 45.9%, we could only check prvkeys with 1 repetition. (/1=45.9%/)
This 1 repetition will form one 2x (/2=95.0%/)

It will be enough just to add a code that takes into account these repetitions into the pool in order to start searching from them and find them faster.
+45.9% prob


6) The paradox of birthdays as an average prvkey distribution.

with what probability the limit of characters in this post will be reached?) I will not risk and I will write continuation in the following.
(I'm not sure that due to the status of the user I can do it immediately and quickly, wait)
to be continued

jr. member
Activity: 34
Merit: 5

...snip...

goto step 2 and repeat.

each cycle will take 16*10min = 160 min if you have one GPU.

This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL
    

I like the idea of including randomness in the process. Because in the end you don't have to search any repeating patterns if consequently followed (0101, 1f1f).
It is possible in theory these patterns appear but very unlikely in practice.

I thought about ignoring ranges completely and just generate random starting offsets for each GPU working point. This would raise the factor of luck by a magnitude but make inclusion of deterministic methods harder.
newbie
Activity: 37
Merit: 0

https://imgur.com/9V8vq4O
1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!


Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.


I know!! was trying to pass some optimism on to the hunters: D

I'm scanning address 61;)

Good luck Smiley

So, speaking of case 61:

In my case, what I do is mix randomness with full range scan. I keep the range small enough to get reasonable waiting time (say 10 min) .
This is an example:

1) generate all possibles 5 bits number: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 

2) pick a random 5 hex digit number (20bit) : for instance CADE9
we have now 16 possibles header for our key

10CADE9
11CADE9
12CADE9
13CADE9
14CADE9
15CADE9
16CADE9
17CADE9
18CADE9
19CADE9
1ACADE9
1BCADE9
1CCADE9
1DCADE9
1ECADE9
1FCADE9

3) call 16 instances of Bitcrack fully scanning following 16 ranges

10CADE9000000000:10CADE9FFFFFFFFF
11CADE9000000000:11CADE9FFFFFFFFF
12CADE9000000000:12CADE9FFFFFFFFF
13CADE9000000000:13CADE9FFFFFFFFF
14CADE9000000000:14CADE9FFFFFFFFF
15CADE9000000000:15CADE9FFFFFFFFF
16CADE9000000000:16CADE9FFFFFFFFF
17CADE9000000000:17CADE9FFFFFFFFF
18CADE9000000000:18CADE9FFFFFFFFF
19CADE9000000000:19CADE9FFFFFFFFF
1ACADE9000000000:1ACADE9FFFFFFFFF
1BCADE9000000000:1BCADE9FFFFFFFFF
1CCADE9000000000:1CCADE9FFFFFFFFF
1DCADE9000000000:1DCADE9FFFFFFFFF
1ECADE9000000000:1ECADE9FFFFFFFFF
1FCADE9000000000:1FCADE9FFFFFFFFF
 
goto step 2 and repeat.

each cycle will take 16*10min = 160 min if you have one GPU.

This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL
   


 

Cool!! nice tip!!!
I'll try
jr. member
Activity: 34
Merit: 5

I know!! was trying to pass some optimism on to the hunters: D

I'm scanning address 61;)

That is a good idea. Feel free to post your keyspaces for us to check.

@Bajula, sure Smiley.
member
Activity: 245
Merit: 17


1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!


Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.


I know!! was trying to pass some optimism on to the hunters: D

I'm scanning address 61;)

Good luck Smiley

So, speaking of case 61:

In my case, what I do is mix randomness with full range scan. I keep the range small enough to get reasonable waiting time (say 10 min) .
This is an example:

1) generate all possibles 5 bits number: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  

2) pick a random 5 hex digit number (20bit) : for instance CADE9
we have now 16 possibles header for our key

10CADE9
11CADE9
12CADE9
13CADE9
14CADE9
15CADE9
16CADE9
17CADE9
18CADE9
19CADE9
1ACADE9
1BCADE9
1CCADE9
1DCADE9
1ECADE9
1FCADE9

3) call 16 instances of Bitcrack fully scanning following 16 ranges

10CADE9000000000:10CADE9FFFFFFFFF
11CADE9000000000:11CADE9FFFFFFFFF
12CADE9000000000:12CADE9FFFFFFFFF
13CADE9000000000:13CADE9FFFFFFFFF
14CADE9000000000:14CADE9FFFFFFFFF
15CADE9000000000:15CADE9FFFFFFFFF
16CADE9000000000:16CADE9FFFFFFFFF
17CADE9000000000:17CADE9FFFFFFFFF
18CADE9000000000:18CADE9FFFFFFFFF
19CADE9000000000:19CADE9FFFFFFFFF
1ACADE9000000000:1ACADE9FFFFFFFFF
1BCADE9000000000:1BCADE9FFFFFFFFF
1CCADE9000000000:1CCADE9FFFFFFFFF
1DCADE9000000000:1DCADE9FFFFFFFFF
1ECADE9000000000:1ECADE9FFFFFFFFF
1FCADE9000000000:1FCADE9FFFFFFFFF
 
goto step 2 and repeat.

each cycle will take 16*10min = 160 min if you have one GPU.

This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL
    
a random 5 hex digit is one of 1,048,575  if you get it right, you have the key in 160 min with only one GPU Wink
 

 
member
Activity: 166
Merit: 16


1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!


Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.


If you don't mind, I'm going to totally steal that and use it in conversation -  lucky256
I'm still snickering over that.
newbie
Activity: 37
Merit: 0

https://imgur.com/9V8vq4O
1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!


Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.


I know!! was trying to pass some optimism on to the hunters: D

I'm scanning address 61;)
jr. member
Activity: 34
Merit: 5


1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!


Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.
jr. member
Activity: 34
Merit: 5

in this script, pubkeys, where from you get pubkeys ?

In general you get the pubkeys from a transaction that has been sent from the target address (spent).

For puzzle key #60:
https://www.blockchain.com/btc/tx/6c08747ecd15904128c3f15f3bf47f6f365405da2661f17eb5119008807cee3e

ScriptSig: PUSHDATA(72)[3045022100b0d935af1a8b20186c2cd3e43dddb391d85acbfab890f025e683bc0da2534de702200b7816d64a59579da5328fbfd7ddd34b19ad864915fe2474338e53d04131257f01]
PUSHDATA(33)0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d

Compressed public key in red: 0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d

You can convert between compressed and uncompressed public key here:
https://iancoleman.io/bitcoin-key-compression/

But better use python and use bitcoin library. E.g.:

Code:
import bitcoin as b
pubkey = b.decode_pubkey("0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d")
print("X:", hex(pubkey[0]), "Y:", hex(pubkey[1]))

Just research little on your own from here.

newbie
Activity: 37
Merit: 0
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
  


Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

True

with -c -u  you get half the speed Smiley !
Never tried it, because most of non empty BTC addresses are compressed Wink


83Mkey/s now!!!

:-D

try with one target

bc.exe -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF  -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB


https://imgur.com/9V8vq4O
1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   Grin Grin Grin

you are awesome!
thank you so much guys!!!
member
Activity: 245
Merit: 17
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 


Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

True

with -c -u  you get half the speed Smiley !
Never tried it, because most of non empty BTC addresses are compressed Wink


83Mkey/s now!!!

:-D

try with one target

bc.exe -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF  -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
newbie
Activity: 37
Merit: 0
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 


Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

True

with -c -u  you get half the speed Smiley !
Never tried it, because most of non empty BTC addresses are compressed Wink


83Mkey/s now!!!

:-D
member
Activity: 330
Merit: 34
@zielar: it is possible, I used the baby step giant step algorithm to retrieve the key #60 in about 80 seconds. And I have 32 GB ram.

space search for each key of the puzzle transaction:

key #1 : from 1 to 1   (2^0 -> 2^1 - 1)
key #2 : from 2 to 3   (2^1 -> 2^2 - 1)
key #3 : from 4 to 7   (2^2 -> 2^3 - 1)
key #4 : from 8 to 15 (2^3 -> 2^4 - 1)
....
key #60: from 2^59 to 2^60 - 1

Let's say for semplicity that our space search in this case is 2^60 (actually is only half, 2^59).

P is the public key, we want to find the private key k. If G is the generator of the curve, the private key k is the number :

k*G = P

baby-step-giant-step (--> http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/):

you create two lists, the first one (the baby steps list) in a hash table stored in the Ram and the second one (the giant steps list) dynamic:

a) (baby steps list): each baby step is equal to 1 (the distance between 2 consecutive elements is 1*G) and we store all these public keys: (0G), 1*G, 2*G, 3*G, 4*G, 5*G, ..., 2^30*G (because sqrt(2^60) = 2^30) in a hash table

b) (giant steps list): each giant step is equal to the sqrt(space size), in our case sqrt(2^60) = 2^30, namely the distance between 2 elements is 2^30*G . We generate on fly this list:

P, P - 2^30*G, P - 2*2^30*G,  P - 3*2^30*G,  P - 4*2^30*G,  P - 5*2^30*G, .....,  P - (2^30 - 1)*2^30*G

and we check if there is a element in the giant-steps list equal to an element in the baby-steps list.

If for example  P - 5*2^30*G = 1000*G, then P = 5*2^30*G + 1000*G

--> P = (5*2^30 + 1000) * G  --> private key k = (5*2^30 + 1000)


2 lists, 2^30 elements * 2^30 elements = 2^60 comparisons without doing 2^60 operations, this is the trick.

Hash table: 2^30 entries, each entry has the coordinate x of the public key (256 bit) + the number of the private key (max 32 bit). I'm using only the first 32 bits of the x instead of 256 bits (there are only few false collisions looking at the first 32 bits and I check these collisions), then I need to store (32 + 32) * 2^30 bit, 2^36 bit, 8 GByte. The hash table actually has to have the double of the number of the keys in the baby steps list (to avoid collisions between two different "x" that share the same 32 bits), so I need at least 16 GByte.

With some other optimizations (the search space is actually 2^59 and not 2^60 + other properties of the secp256k1 curve), I can run the program.

When the search space is greater than 60 bit, let's say 62 bit, I can't store all the 2^31 public keys of the baby steps list at once in the Ram, then I split 2^31 in 2 lists of 2^30 elements, A e B, then first I check the entire giant steps list against the list A, and if there is no match, I generate the list B and I generate again the giant steps list.

in this script, pubkeys, where from you get pubkeys ?
member
Activity: 245
Merit: 17
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 


Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

True

with -c -u  you get half the speed Smiley !
Never tried it, because most of non empty BTC addresses are compressed Wink
jr. member
Activity: 34
Merit: 5
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 


Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed
member
Activity: 245
Merit: 17
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 
newbie
Activity: 37
Merit: 0
What memory size are your rx480?


4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s
member
Activity: 245
Merit: 17
What memory size are your rx480?
newbie
Activity: 37
Merit: 0

5 years pass quickly :-D LOL
i have 40Mkeys per gpu(Is there any way to improve?)


Good speed increase if you only want to target the #61 puzzle address.

  • Only -c
  • Only one target: 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
  • Make sure to use latest BitCrack version from github. There have been good speed improvements to the OpenCL version recently
  • Check your settings. For Cuda I have better performance with more threads (~512) instead of high processes

GL HF
One target or 45000 target won't change much.

Try this


bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 2048


now 50Mkey/s
Jump to: