[ARCHIVE] Bitcoin challenge discusion - page 20.

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: JDScreesh on September 08, 2019, 07:40:05 AM

I'm trying with the Pollard Kangaroo script. Let's see how much it'll take Cheesy

Isn't it inaccurate for higher bit counts?

[bits] 2^62 (warn: too big!)

It's also very slow, at least for lower bits (3+ hours to crack 50 bits). BSGS cracked 50 bits in 94 seconds, but it needs exponentially growing amounts of memory.

JDScreesh

jr. member

Activity: 47

Merit: 13

Quote from: almightyruler on September 08, 2019, 07:28:54 AM

Quote from: JDScreesh on September 08, 2019, 06:10:07 AM

Congratulations to the winner who had found the #62

I wonder which was the privkey Cheesy

Pubkey is 03231a67e424caf7d01a00d5cd49b0464942255b8e48766f96602bdfa4ea14fea8

I'm going to try cracking it with baby step giant step, but I think I'm right at the edge of memory that my compiler can allocate for the table. Trying it anyway.

Hopefully the person who claimed the prize is just waiting for several confirms before revealing the details. Or they're asleep

Great! Thanks for your help.

I'm trying with the Pollard Kangaroo script. Let's see how much it'll take Cheesy

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: JDScreesh on September 08, 2019, 06:10:07 AM

Congratulations to the winner who had found the #62

I wonder which was the privkey Cheesy

Pubkey is 03231a67e424caf7d01a00d5cd49b0464942255b8e48766f96602bdfa4ea14fea8

I'm going to try cracking it with baby step giant step, but I think I'm right at the edge of memory that my compiler can allocate for the table. Trying it anyway.

Hopefully the person who claimed the prize is just waiting for several confirms before revealing the details. Or they're asleep

bulleteyedk

jr. member

Activity: 85

Merit: 1

ahh yes i also see the #62 wallet have been emptied, really exited to know the priv. key hex value, as to know how close i was hitting it Grin

congrats to who ever hit it

JDScreesh

jr. member

Activity: 47

Merit: 13

Congratulations to the winner who had found the #62

I wonder which was the privkey Cheesy

Daltonik

legendary

Activity: 2604

Merit: 1504

Quote from: zielar on September 07, 2019, 06:50:15 PM

My new =>STABLE<= record on BitCrack :-)

NV Tesla || The unstable setting showed me 1615, but it jumps from 1585 every reading. ||

Great, overclocked card? and what values for -b -t -p did you use, I did not get more than 1250 Mkey/s

almightyruler

legendary

Activity: 2268

Merit: 1092

Quote from: almightyruler on September 06, 2019, 09:48:31 PM

I wrote a script to benchmark bit sizes from 16 to 50 bits:

bits avgjump avgtime ----------------------------- [...] 48 | 60846064 | 828.8 sec 49 | 127443507 | 1706.6 sec 50 | ...

The tests for 50 bits are still going, but so far the results for 5 runs are:

50 | 1071642261 | 16920.6 sec

49 = 127 443 507 jumps
50 = 1 071 642 261 jumps

Why does the work suddenly increase (by a factor of about 8 to 10, depending on time or jumps) when going from 49 to 50 bits? I notice the code warns "too big" if bits > 50

zielar

full member

Activity: 282

Merit: 114

My new =>STABLE<= record on BitCrack :-)

NV Tesla || The unstable setting showed me 1615, but it jumps from 1585 every reading. ||

Firebox

jr. member

Activity: 59

Merit: 3

Quote from: racminer on September 07, 2019, 10:05:47 AM

Quote from: Firebox on September 07, 2019, 09:45:37 AM

Well known 57fe's python script runs using only one core - that's the fact. I have added this code in very beginning of the code the following part of the code:

Code:

import multiprocessing as mp
import psutil
def spawn():
    procs = list()
    n_cpus = psutil.cpu_count()
    for cpu in range(n_cpus):
        affinity = [cpu]
        d = dict(affinity=affinity)
        p = mp.Process(target=run_child, kwargs=d)
        p.start()
        procs.append(p)
    for p in procs:
        p.join()
        print('joined')

def run_child(affinity):
    proc = psutil.Process()  # get self pid
    print('PID: {pid}'.format(pid=proc.pid))
    aff = proc.cpu_affinity()
    print('Affinity before: {aff}'.format(aff=aff))
    proc.cpu_affinity(affinity)
    aff = proc.cpu_affinity()
    print('Affinity after: {aff}'.format(aff=aff))

and supposed that that the scrips will use all cores and it actually does, but the speed drops down to ~60k h/s.
Can any one help to understand why it is? And how to improve the speed of this script?

This header alone in not enough to make the reste of the code work with more than one core !

Also
n_cpus = psutil.cpu_count() will probably give you the number of logical cores which is usually twice the number of physical cores (depends on what is your CPU).

you might try :
n_cpus = psutil.cpu_count() >> 1
in principal, you'll get more speed per core

What cpu do you have?

Thanks, mate. It really did give a little more speed -> ~100k h/s. That what script shows. Maybe that is the speed per core? If yes then it's quite cool ))
Here is my benchmark addr #50:

PS I have CPU QuadCore Intel Core i7-6700HQ, 2500 MHz (25 x 100).

-------

Strange, but if I change to n_cpus = 3 it gives speed ~150k... Why?

-------

Is it possible to edit a number of threads per core?

racminer

member

Activity: 245

Merit: 17

Quote from: Firebox on September 07, 2019, 09:45:37 AM

Well known 57fe's python script runs using only one core - that's the fact. I have added this code in very beginning of the code the following part of the code:

Code:

import multiprocessing as mp
import psutil
def spawn():
    procs = list()
    n_cpus = psutil.cpu_count()
    for cpu in range(n_cpus):
        affinity = [cpu]
        d = dict(affinity=affinity)
        p = mp.Process(target=run_child, kwargs=d)
        p.start()
        procs.append(p)
    for p in procs:
        p.join()
        print('joined')

def run_child(affinity):
    proc = psutil.Process()  # get self pid
    print('PID: {pid}'.format(pid=proc.pid))
    aff = proc.cpu_affinity()
    print('Affinity before: {aff}'.format(aff=aff))
    proc.cpu_affinity(affinity)
    aff = proc.cpu_affinity()
    print('Affinity after: {aff}'.format(aff=aff))

and supposed that that the scrips will use all cores and it actually does, but the speed drops down to ~60k h/s.
Can any one help to understand why it is? And how to improve the speed of this script?

This header alone in not enough to make the reste of the code work with more than one core !

Also
n_cpus = psutil.cpu_count() will probably give you the number of logical cores which is usually twice the number of physical cores (depends on what is your CPU).

you might try :
n_cpus = psutil.cpu_count() >> 1
in principal, you'll get more speed per core

What cpu do you have?

Firebox

jr. member

Activity: 59

Merit: 3

Well known 57fe's python script runs using only one core - that's the fact. I have added this code in very beginning of the code the following part of the code:

Code:

import multiprocessing as mp
import psutil
def spawn():
    procs = list()
    n_cpus = psutil.cpu_count()
    for cpu in range(n_cpus):
        affinity = [cpu]
        d = dict(affinity=affinity)
        p = mp.Process(target=run_child, kwargs=d)
        p.start()
        procs.append(p)
    for p in procs:
        p.join()
        print('joined')

def run_child(affinity):
    proc = psutil.Process()  # get self pid
    print('PID: {pid}'.format(pid=proc.pid))
    aff = proc.cpu_affinity()
    print('Affinity before: {aff}'.format(aff=aff))
    proc.cpu_affinity(affinity)
    aff = proc.cpu_affinity()
    print('Affinity after: {aff}'.format(aff=aff))

and supposed that that the scrips will use all cores and it actually does, but the speed drops down to ~60k h/s.
Can any one help to understand why it is? And how to improve the speed of this script?

almightyruler

legendary

Activity: 2268

Merit: 1092

For those of you that are interested in experimenting or benchmarking, this version of the code has an interesting feature: if you specify bits (but not the pubkey) on the commandline, it will generate a random privkey/pubkey pair, and then it uses the pubkey only to derive the privkey. It also verifies that the result matches the original privkey. Note you need the coincurve module installed.

https://bitcointalksearch.org/topic/m.52318676

I wrote a script to benchmark bit sizes from 16 to 50 bits:

bits avgjump avgtime ----------------------------- 16 | 2222 | 0.0 sec 17 | 685 | 0.0 sec 18 | 1410 | 0.0 sec 19 | 1760 | 0.0 sec 20 | 2471 | 0.0 sec 21 | 11794 | 0.1 sec 22 | 33504 | 0.4 sec 23 | 5848 | 0.1 sec 24 | 33151 | 0.4 sec 25 | 115165 | 1.3 sec 26 | 32936 | 0.4 sec 27 | 21554 | 0.2 sec 28 | 65202 | 0.8 sec 29 | 95825 | 1.1 sec 30 | 83395 | 1.0 sec 31 | 118533 | 1.3 sec 32 | 298726 | 3.4 sec 33 | 1494556 | 16.5 sec 34 | 922811 | 10.2 sec 35 | 3500772 | 40.1 sec 36 | 530865 | 6.1 sec 37 | 874350 | 10.2 sec 38 | 2391518 | 27.8 sec 39 | 1733346 | 19.8 sec 40 | 26815651 | 294.5 sec 41 | 5564319 | 58.2 sec 42 | 6209964 | 64.7 sec 43 | 44672620 | 483.5 sec 44 | 8790286 | 96.7 sec 45 | 77312665 | 1045.7 sec 46 | 34559558 | 478.5 sec 47 | 24016039 | 329.6 sec 48 | 60846064 | 828.8 sec 49 | 127443507 | 1706.6 sec 50 | ...

(Remember, these are based on randomly generated privkeys, not the puzzle transactions)

I would expect a lot of noise at low bit lengths, but even once there's a lot more work done each run, there's still some large variations (eg #44 versus #45)

The server is fairly heavily loaded so the average jumps is probably a better metric than time period, but even then it's not very useful since the number of jumps varies so much from run to run. I thought it may still be interesting to post the results.

brainless

member

Activity: 330

Merit: 34

Quote from: PietCoin97 on September 06, 2019, 11:58:42 AM

Can you add multithreading to this code ?

time is not for multithreading, time is for cuda

PietCoin97

jr. member

Activity: 91

Merit: 3

Can you add multithreading to this code ?

racminer

member

Activity: 245

Merit: 17

Firebox

jr. member

Activity: 59

Merit: 3

Quote from: brainless on September 06, 2019, 10:51:16 AM

Quote from: Firebox on September 06, 2019, 09:48:09 AM

Quote from: brainless on September 06, 2019, 09:30:47 AM

python 2.py 03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 0xaf55fc59c335c8e0000000000 0xaf55fc59c335c8f0000000000 3
P-table prepared
tame and wild herds are prepared
220012.055 h/s
229034.780 h/s
total time: 11.90 sec
SOLVED: AF55FC59C335C8EC67ED24826

('Hops:', 2691957)

Very narrow range was choosen, that's why so fast. Try at least this one:
03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 cccccccccccccccccccccccb5 e666666666666666666666647 8
(addr #100 ragne 30% -> 40%, as the PKEY is located at ~37% position)

---------

Your speed is impressive ))). Could you share your script? Or it was unchanged?

unchanged
if i run 2 script in 2 difrent folder speed for each script is
220012.055 h/s
229034.780 h/s
if only 1 script run, speed is 238000 h/s

What is your CPU and what is CPU locks do you use (if any)?

brainless

member

Activity: 330

Merit: 34

Quote from: Firebox on September 06, 2019, 09:48:09 AM

Quote from: brainless on September 06, 2019, 09:30:47 AM

python 2.py 03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 0xaf55fc59c335c8e0000000000 0xaf55fc59c335c8f0000000000 3
P-table prepared
tame and wild herds are prepared
220012.055 h/s
229034.780 h/s
total time: 11.90 sec
SOLVED: AF55FC59C335C8EC67ED24826

('Hops:', 2691957)

Very narrow range was choosen, that's why so fast. Try at least this one:
03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 cccccccccccccccccccccccb5 e666666666666666666666647 8
(addr #100 ragne 30% -> 40%, as the PKEY is located at ~37% position)

---------

Your speed is impressive ))). Could you share your script? Or it was unchanged?

unchanged
if i run 2 script in 2 difrent folder speed for each script is
220012.055 h/s
229034.780 h/s
if only 1 script run, speed is 238000 h/s

blueteam09

full member

Activity: 664

Merit: 100

📱 CARTESI 📱 INFRASTRUCTURE FOR SCA

I am excited to read your article. I was inquisitive and wanted to participate in this challenge. But after I read the comments from different people. I realise that this is harder than I imagined, we can't search manually. This is only suitable for coders because they can create bots with alternative human tasks.

Firebox

jr. member

Activity: 59

Merit: 3

Quote from: brainless on September 06, 2019, 09:30:47 AM

python 2.py 03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 0xaf55fc59c335c8e0000000000 0xaf55fc59c335c8f0000000000 3
P-table prepared
tame and wild herds are prepared
220012.055 h/s
229034.780 h/s
total time: 11.90 sec
SOLVED: AF55FC59C335C8EC67ED24826

('Hops:', 2691957)

Very narrow range was choosen, that's why so fast. Try at least this one:
03d2063d40402f030d4cc71331468827aa41a8a09bd6fd801ba77fb64f8e67e617 cccccccccccccccccccccccb5 e666666666666666666666647 8
(addr #100 ragne 30% -> 40%, as the PKEY is located at ~37% position)

---------

Your speed is impressive ))). Could you share your script? Or it was unchanged?

brainless

member

Activity: 330

Merit: 34

Topic: [ARCHIVE] Bitcoin challenge discusion - page 20. (Read 29427 times)