Bitcoin Forum
October 21, 2020, 02:31:35 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 »
1  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: September 10, 2020, 06:13:48 PM
when --count is coming ?

developer is missing, hope he is enjoying cracked address and now forget his community Smiley
2  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: September 09, 2020, 09:57:13 AM
No it's a brainless application.
You need fast indexing of the targets and a more directional approach.
Filter off the dust and the file will be ~120 Megs.
In it's current state it's just a heater and it's not going to find anything, not now not ever.

bro hope you have car, which one model/year you have ?
3  Bitcoin / Development & Technical Discussion / Re: BitCrack - A tool for brute-forcing private keys on: September 08, 2020, 01:20:48 PM
currently bitcrack running features like if stride is 100
count+stride+count+stride = 1+100+1+100 = total 202
looking update with new switch --count as define by user ( --count 200) and stride 100 ( user count is checking keys)
user-count + stride + user-count+ stride + user- count = 300+100+300+100+300 = total 1100

addons if --keyspace is 1:3000, new switch --loop --count 2000 --stride 100
user-count + stride + user-count+ stride + user- count = 2000+100+2000(its reach at end but still countin in loop from 1(startkey))+100+2000 continue loop
--count will be keys need to be check and stride
hope this feature will make bitcrack more effective and attractive
Thankx
4  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 26, 2020, 06:57:12 PM
hi @BitCrack
Will you consider releasing a server-client version of bitcrack  ?

Yes, I have been working on it for a little while.

Great news  Roll Eyes

don't forget to merge this https://github.com/brichard19/BitCrack/issues/256 if it is not already done.
And thanks a lot.
anyone have study bitcrack codes, and have commands in hand to modifiy/add/update some features
if yes, then these feature, work fast then kangaroo for find 120 puzzle, pls check and update us all community

--stride 1000:52000
where 1000 key check, and 52000 key bypass(no check)
--loop 500
count total keys of --keyspace * 500 = total keys
example 1 to 100 + 1 to 100 + 1 to 100
cuurent stride work only fixed like --stride 1:52000  or 1:123456

Brichard19 refuse to further work at bitcrack
I'm trying to follow what you are saying/wanting the program to do.

It checks 1000 keys, and then skips 52000 keys?
I didn't know the current stride function could be used as --stride1:52000; I only used --stride and a single number. But I do know the stride function is broken when you try to use it with the continue function. If you use a number higher than 9, say --stride 11 with --continue, it works first time around but changes the stride second time around. It doesn't parse/calculate numbers above 10(A) correctly.
actual func is --stride 52000, 52000 define by user, its skip 52000 and check 1 key, as i think its fixed inside first key and next key,
in program by default only 1 is fixed for check, should be create func for check keys define by user
and loop function

i design reverse kangaroo inside bitcrack, mean i created pubkeys inside bit range, as per kangaroo jump
and checking and skips calculation will find solution in loop, in this senerio, no need highest rams, and hdd spaces, and no dead kangaroo, and by default save/continuous func save your work just 1 click


5  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 26, 2020, 01:26:04 PM
hi @BitCrack
Will you consider releasing a server-client version of bitcrack  ?

Yes, I have been working on it for a little while.

Great news  Roll Eyes

don't forget to merge this https://github.com/brichard19/BitCrack/issues/256 if it is not already done.
And thanks a lot.
anyone have study bitcrack codes, and have commands in hand to modifiy/add/update some features
if yes, then these feature, work fast then kangaroo for find 120 puzzle, pls check and update us all community

--stride 1000:52000
where 1000 key check, and 52000 key bypass(no check)
--loop 500
count total keys of --keyspace * 500 = total keys
example 1 to 100 + 1 to 100 + 1 to 100
cuurent stride work only fixed like --stride 1:52000  or 1:123456

Brichard19 refuse to further work at bitcrack
6  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 22, 2020, 06:52:04 PM
You are using a too small DP, too much DPs enter in the HashTable and slow down the search.
The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.

Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
if i am not wrong,
you win 115bit puzzle in 13 days, and you count 120 puzzle is more hard as 32 time
its mean 13 x 32 = 416 days you need to win or ?
7  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 21, 2020, 09:02:47 PM
Quote
MY SOFT NOT FINED LIKE YOU, LOOOK AT THIS SH.... 10 MINUTES AND NO RESULT !!!

Code:
[code]
.EXe -t 0 -gpu -g 136,256,136,256 -gpuId 0,1 -o result.txt
 test40.txt


angaroo v2.0
Start:1
Stop :FFFFFFFFFF
Keys :1
Number of CPU thread: 0
Range width: 2^40
Jump Avg distance: 2^19.97
Number of kangaroos: 2^23.09
Suggested DP: -3
Expected operations: 2^21.40
Expected RAM: 857.8MB
DP size: 64 [0xFFFFFFFFFFFFFFFF]
GPU: GPU #1 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#1: creating kangaroos...
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(136x256) (347.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^22.09 kangaroos [13.3s]
SolveKeyGPU Thread GPU#1: 2^22.09 kangaroos [14.6s]
[1324.32 MK/s][GPU 1190.21 MK/s][Count 2^32.39][Dead 0][04s (Avg 00s)][2.0/4.0MB
[1942.10 MK/s][GPU 1807.99 MK/s][Count 2^33.35][Dead 0][08s (Avg 00s)][2.0/4.0MB
[1903.15 MK/s][GPU 1813.75 MK/s][Count 2^33.88][Dead 0][12s (Avg 00s)][2.0/4.0MB
[1718.04 MK/s][GPU 1662.16 MK/s][Count 2^34.34][Dead 0][17s (Avg 00s)][2.0/4.0MB
[
[1391.96 MK/s][GPU 1391.96 MK/s][Count 2^39.73][Dead 0][12:31 (Avg 00s)][2.0/4.0
[1390.44 MK/s][GPU 1390.44 MK/s][Count 2^39.74][Dead 0][12:36 (Avg 00s)][2.0/4.0
[1395.04 MK/s][GPU 1395.04 MK/s][b][Count 2^39.75][Dead 0][12:40 (Avg 00s)][2.0/4.0[/b]
MB]  ^CЗaвepшить выпoлнeниe пaкeтнoгo фaйлa [Y(дa)/N(нeт)]?

[/code]

Bro, whot version you use ?

What is your command line settings ?


HELP PLEASE BRO Huh? !!!!
I ran the test on the latest version, Windows. I posted my bat file above - but just Kangaroo -t 4 -dp 12 rangetest.txt (CPU only)
edit: something isn't right with your version or something. With all that GPU power you have in this small range, if it's not finding, you would have 43 billion dead kangaroos. dp of negative 3?? never seen a negative number

maybe probelms in his Suggested DP: -3
try use -d 12 in your command
8  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 21, 2020, 12:03:38 PM
Kangaroo -t 0 -d 14 -gpu -gpuId 1 -ws -w 65save.txt -wi 30 -o 64save.txt 65.txt
pause (did as they wrote, after launching the bat file it starts and it says “click any button” in the working window, everything closes after clicking) What should I do to fix the error Huh??
for window

click start, then click in searchbar then type   cmd
click commamd prompt
when black winodw of command prompt apear, go to your folder where your kangaroo files, then run your program commands

9  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 20, 2020, 03:36:50 AM
Sorry me for offtop.

Can someone share me compiled Ubuntu 16. CUDA 10 version of Kangaroo ? Very needed. Try compile latest from GitHub but get trebles.

in PM if someone can this doing.


Code:


 make gpu=1 ccap=20 all
cd obj &&       mkdir -p SECPK1
g++ -DWITHGPU -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -I. -I/usr/local/cuda-10.0/include -o obj/SECPK1/IntGroup.o -c SECPK1/IntGroup.cpp
SECPK1/IntGroup.cpp: In constructor 'IntGroup::IntGroup(int)':
[b]SECPK1/IntGroup.cpp:24:42: error: 'malloc' was not declared in this scope[/b]
   subp = (Int *)malloc(size * sizeof(Int));
                                          ^
SECPK1/IntGroup.cpp: In destructor 'IntGroup::~IntGroup()':
[b]SECPK1/IntGroup.cpp:28:12: error: 'free' was not declared in this scope[/b]
   free(subp);
            ^
Makefile:80: recipe for target 'obj/SECPK1/IntGroup.o' failed
make: *** [obj/SECPK1/IntGroup.o] Error 1



Huh??
Your gpu model ?
10  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 07:05:21 PM
-snip-
for you 1000 pubkeys in 54 bit range total time for check ?
i don`t know how many time was spent for test but calc say that need average time 2^ 3.8s  for 1 Pub with 20Mop/s on CPU

in short i can say for check 1000 keys from 54 bit, your actual work close to 74/75/76 bit range
and it should be 54 bit total keys x 1000, and get your bit range for real work should be,
btw you all are working in opposite direction, you are trying to change resource like dp, G etc, and in my view most fast way is reverse corresponding pubkey, leave all dp files of 115 as its, and just try my 80 pubkeys for 115 bit already generated dp file, and it will save 80% work and time instead to shift dp/G into 120 bit
Etar i will give you experiment in other downbit range, in PM mode, then u will come to know whats difrence
11  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 06:45:25 PM
-snip-
Etar
if i am not wrong
you have 49 bit 1000 pubkeys
you shift dp file to 54 bit
and you have this info
" Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 "
if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange
76 bit = 75557863725914323419135
54 bit = 18014398509481983
distance = 4194303 for 1000 pub key
and for 1 pubkey = 419.4303
and for 32*g = 134217.72
in short you used tooo much time as compare to equal 76 bit work
hope u understand
2^37.93 for ALL pubkeys
for 1 pubkeys average op is 2^27.98
And i didn`t have 1000pubkeys in 49bit range. I solve 1 keys and convert work file to range 54bit.
In 54bit i solve 1000pubkeys
run any random pubkey for 76 bit, and see you need these 2^37.93 for finish
for you 1000 pubkeys in 54 bit range total time for check ?
12  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 06:39:10 PM
-snip-
Etar
if i am not wrong
you have 49 bit 1000 pubkeys
you shift dp file to 54 bit
and you have this info
" Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 "
if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange
76 bit = 75557863725914323419135
54 bit = 18014398509481983
distance = 4194303 for 1000 pub key
and for 1 pubkey = 419.4303
and for 32*g = 134217.72
in short you used tooo much time as compare to equal 76 bit work
hope u understand
2^37.93 for ALL pubkeys
for 1 pubkeys average op is 2^27.98
And i didn`t have 1000pubkeys in 49bit range. I solve 1 keys and convert work file to range 54bit.
In 54bit i solve 1000pubkeys
run any random pubkey for 76 bit, and see you need these 2^37.93 for finish
13  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 18, 2020, 06:30:51 PM
-snip-
The gain (- 5,4%) is little, how many DPs have you generated for the key in 49 bit?
-snip-
DP Count  : 240568 2^17.876 in 49bit workfile. i have source file and converted file. I can share if you want to verify DPs. But each DP after multiplication was verifed with G' and x-coordinate correct.
Code:
DP bits   : 8
Start     : 40000000000000
Stop      : 7FFFFFFFFFFFFF
Key       : 025C396BA4347253BBAAFFAC6D4F9BA092847B27F2599EB2EB225DDA54F9964190
Count     : 0 2^-inf
Time      : 00s
DP Size   : 9.3/30.6MB
DP Count  : 240568 2^17.876
HT Max    : 8 [@ 01D30E]
HT Min    : 0 [@ 000001]
HT Avg    : 0.92
HT SDev   : 0.95
-snip-
"Total op was 261530636052 = 2^37.93" this for 1000 pubkey or only one ?
For 1000 pubkeys

-snip-

Etar, this is a CPU or GPU version ?
Test done on CPU
Etar
if i am not wrong
you have 49 bit 1000 pubkeys
you shift dp file to 54 bit
and you have this info
" Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 "
if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange
76 bit = 75557863725914323419135
54 bit = 18014398509481983
distance = 4194303 for 1000 pub key
and for 1 pubkey = 419.4303
and for 32*g = 134217.72
in short you used tooo much time as compare to equal 76 bit work
hope u understand

14  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 17, 2020, 04:18:35 PM
It is necessary to use same jumps otherwise path are incompatible.
And the mean has also to be controlled.
Implementing changing of G is rather an heavy task so I would like to have at least an estimation of the loss due to the fact that all paths of new DP will have all points multiple of 32.
We will probably also use DP28 or DP27 for #120
finally you agree, to go back at normal work for 120 as worked for 115, no implements, no changes, no new developments, HuhHuh
15  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 17, 2020, 02:50:58 PM
Jumps (the points) are the same, only their private keys are different;

So in practical, I let the old #115 DP as they are and for the new search #120 I use inv(32)*G instead of G ?

yes above is 1 point, and you need 2.5 points (25dp) in search
so if i generate 80 (2.5 per point) coresponding pubkeys, that could save more 80% time saving
those 80 keys only need to search in old 115bit save.work file
but i know u r hesitate to multipubkeys
so better use inv(32)*G instead of G with 1 pubeky
more over
for 25dp, you can go more downbit to 25bit down, final bit range would be 95bit, but with 2.5m corresponding pubkeys
can you imagine, where you can stand in finding solution ( time and resources )
16  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 17, 2020, 02:44:41 PM
Jumps (the points) are the same, only their private keys are different;

So in practical, I let the old #115 DP as they are and for the new search #120 I use inv(32)*G instead of G ?

yes above is 1 point, and you need 2.5 points (25dp) in search
so if i generate 80 (2.5 per point) coresponding pubkeys, that could save more 80% time saving
those 80 keys only need to search in old 115bit save.work file
but i know u r hesitate to multipubkeys
so better use inv(32)*G instead of G with 1 pubeky
17  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 17, 2020, 02:23:10 PM
Hi,
I don't understand well how this can work ?
If you change G, the path will also differ as jumps are a function of the X value.

Jumps (the points) are the same, only their private keys are different;

instead of using, for example, 2543*G as jump, you use (2543*32)*G', where G' = inv(32)*G

in this way the points are the same and the paths are the same. The same interval

A = [1G, 2G...., (2^114 - 1)*G]

can be viewed as

B = [32*G', 2*32*G'...., 32*(2^114 - 1)*G']

and this interval is a subset of the interval

C = [1*G', 2*G', 3*G',...., (2^119 - 1)*G']

Note that C has the same number of elements of

D = [1*G, 2*G, ...., (2^119 - 1)*G]

but C != D.

To recap:  

A = B, A subset C
A subset D

What is the difference? Why using C instead of D?

The advantage is that the old DPs, that lie in A = B, lie in C too, but now they are uniformly spread out in C, while the same points are not uniformly spread out in D.

Now, P lies in the interval D, not in C, but P' = inv(32)*P does, and the private key of P' respect to G' is the same as the private key of P respect to G.

-----------------------------------------------------
Note:

C is not the original interval D = [0*G, 2*G, ...., (2^119 - 1)*G], C is a 'contraction' of D, on other hand the very original interval (where the real public key P lies) is E = [2^119 *G, ..., (2^120 - 1)*G].

Usually you shift E to D and P to P' = P - 2^119*G; note that it is like you changed G to G' = G - 2^119G.

Now I suggest to add another move:

move D to C and P' to P'' = inv(32)*P' ; I call this move a 'contraction', because I divide G by 32.

Actually you r saying upword in multiple mode
And i said long time ago downside multiple mode.

Upside *32 mean u still stand 1 part of 32 part
And down side u r stand for 32/1
So i know this stage of multiple pub keys you have 90% work n time savings.
Hope u will not understand. Other jean luc will leave everything and rush to develop multipub key search ver .
Bc after long junps in thinking he will come to this stage in last
Example i said
2 x 100 = 200
But he listening
2+2+2 till 200
2+3 till 200
2x2 x2 till 200

Hope u all moving slowly to multiple keys or multiple bits
But dont try to understand my words. As its from brainless
18  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 16, 2020, 02:06:58 PM
If we attack #64, we will try all priv key one by one, compute the HASH160 until we get a match.
With few mods, the vanitySearch engine can do that. Kangaroo is not usefull here.
For one by one bitcrack could work too. Even peoples created group pool for find 64. Like client server sharing
19  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 16, 2020, 01:27:38 PM
Yes thanks for this tip Smiley
I'm building a map to compute with accuracy the DP overhead as I didn't yet managed to get the correct analytical expression but only the 2 asymptote (0 and infinity)
Tomorrow I will also investigate how long would it take with the VanitySearch engine optimized for V100 to solve #64.
Then we will make our choice on attacking #64 or #120.

private key for 115 ?
20  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: June 16, 2020, 12:27:30 PM

You have computed about 2^58.36 steps. And you know now the private keys of 2^33.36 DPs in the [1, 2^114 - 1] interval (why you said [2^114,2^115-1]? you know only one public key P in [2^114, 2^115 - 1] range, all the public keys/points you have computed lie in [1, 2^114 - 1])


Yes you're right.
I ve forgotten that the start range was shifted to zero. shame on me Smiley
It will help to solve #120. Wink

my Question you misunderstand
example i have 2 pubkeys in 115bit range, 1 key found, for 2nd key how i can use that work file for find in less time, ??
Pages: [1] 2 3 4 5 6 7 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!