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

GTX 770 = price ~$80-90
GTX 980 = price ~$150-160
GTX 1060 = price ~$240-260
GTX 1070Ti = price ~$280-300
GT 640 = price ~$10-15

Tesla V100 16GB - 1570-1600 Mkey/s = price ~$10000

How could you manage this? Are you really sure in 120 Mkey/sec with GTX 770? This card GTX 770 cost not so much, and in comparison with GTX 1080ti you can need 3 cards GTX 770 and for the the same (or more) Key/sec rate. But the cost will be 2 times less.

Table update with bitcrack key/rate per sec:

Thanks for making this table, i've just tested one of my kids' GTX 770 2GB card and its capable of doing 120MKey/sec

Maybe you can split equally the search range among threads ...

Thak you! Nice job :-) By the way, can you explain why do you need 10 Ntimeit? It actually finds the key from the 1st time, and the 2nd, 3d, etc finds the same key (for #32 as i tested). So, what is the reason for doing the same 10 times?

And also, can you confirm that in this Kangaroo method the luck also is important (for high order pubkeys)?

origin link
https://fe57.org/forum/thread.php?board=4&thema=1#1

Let's!

I will conduct a lot of tests and update this post.
Last update at Oct 09 2019, edit#34

#################
Notice, about power, it is the same

2¹²³ == 2^(123) == 2**(123) == pow(2,123) == pow2(123) == 1<<123
sqrt(2) == 2^1/2 == 2**0.5

2¹²³ - only this forum, outside of quote/code tags
2** - its python specific
pow() - popularity in many programm langs
2^ - classic old standart math text format, so i use it in 99%, not beautiful but it works

here x^y is math text format of power as x^y and not bit operation xor as [x xor y], do not confuse!
#################
# gmpy2

When I ported the code to coincurve lib, I was surprised to find that gmpy2 is faster.
Until this moment, I have not seen an implementation faster than in coincurve, my respect!
1core i5-2540 python37x64 win7x64
(with python27x64 -10%)
(on linux +20% and more!)

how to install gmpy2 on windows
 1) download file .whl from https://www.lfd.uci.edu/~gohlke/pythonlibs/
 2) put to root dir of python
 3) install
Python27>python -m pip install gmpy2-2.0.8-cp27-cp27m-win_amd64.whl
Python37>python -m pip install gmpy2-2.0.8-cp37-cp37m-win_amd64.whl

#################
# speed cpu


https://bitcointalksearch.org/topic/m.51796187
https://imgur.com/a/f3zTmTa
thank you, it helped a lot

i imagine how j2002ba2 read topic and thinks


#################

why not use endomorphism for pollard-rho?
point after multiplying by beta is enough pseudo random?
if I'm right, this will be a new superfast method to calculate pollard-rho at the cost of 1M per 1 point
didn’t it occur to anyone before me, I need to test

#################

to be continued..

hahaha cool.  i made some tweaks to BitCrack so i can set whatever starting points i want.  I have it count to FFFF and restart with a new batch of points.  it writes everything it has tried to a file.  It has not picked the same random 3 bytes yet, nor has any scan overlapped any ranges posted here.  i will be lazy and wait until it does before coding anything to prevent that.

These are the constant numbers. They are always the same for bitcoin.

if I want to look for any other bitcoin key (I guess it takes a very long time), I do not need to change these lines? Only lines 168-176 and 178?

Just want to add that you should increase -p in multiples of 512

experiments. I think you need to gradually increase the parameter -b. You can also raise the parameter -p (this uses the memory of your card).try for example like this  -b 80 -t 512 -p 4000 or  -b 88 -t 256 -p 4500 or  -b 60 -t 512 -p 6000  etc. change the parameters and...experiments....experiments....experiments....

Can you please tell your configuration for 1080ti? (b, t, p and any other relevant info). What CUDA do you use? (9.2 or the newest 10.1).
I tried on the week to test 1080ti (Gigabyte Gaming OC 11Gb) and received thr result 150 Mkey/sec (as another guy posted earlier) with -b 56 -t 512 -p 2048.

This is the easiest part   All these integers are determined by bitcoin mathematics in ECDSA. Gx and Gy are x, y coordinates of the base point (G) which is used to produce private key. Modulo is the mod of the field (like border). Order is the order of the fiels, i.e the total number of points of ECDSA curve.

Let's discuss the Pollard's kangaroo script from 57fe since it is not possible to register on its forum. Has anyone managed to increase the speed above 150k? And who understands, explain what the lines mean 5-8:

modulo = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
order  = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8




If I understand correctly, then there is a new version with Upgrade to Visual Studio 2019 / CUDA 10.1, but it is not in releases
https://github.com/brichard19/BitCrack

Who knows for bitcrack is it important to have Visual Studio 2017 and CUDA Toolkit 9.2? Will it work with Visual Studio 2019 and CUDA Toolkit 10.1 (newest vesrions)?

yeah... being the one that claims this and the following wallets requires some luck (besides GPU power) , but sticking to a plan is never a bad idea  

This looks like a suggestion I've made a while ago 

Distributed Random Brute Force

I don't have the GPU power to make any progress with sequential brute force.
I also found, by experiment, that guessing random numbers can take much longer.

So, to maximize the fun, I am doing both. 
I distribute the scan over the 20-3F keyspace, pick 3 random bytes, and brute force the rest.

My ranges look like this: (where XXXXXX is 3 random bytes)

[20-3F][XXXXXX]00000000 - [20-3F][XXXXXX]FFFFFFFF

My old card can try fifteen 3-byte randoms per scan, every 13 hours, at 44Mkey/s.  Plus about 2 million really random randoms with the leftover starting points.

What does that get me?

15 random blocks of 4.3 billion keys in each of 32 sub-ranges [20-3F] per scan = 2 trillion.  4T/day.  Pffft.

so, every 26-hour day, scanning the following:
128 B keys in 20XXXXXX00000000-20XXXXXXFFFFFFFF
128 B keys in 21XXXXXX00000000-21XXXXXXFFFFFFFF
128 B keys in 22XXXXXX00000000-22XXXXXXFFFFFFFF
.
.
.
128 B keys in 3DXXXXXX00000000-3DXXXXXXFFFFFFFF
128 B keys in 3EXXXXXX00000000-3EXXXXXXFFFFFFFF
128 B keys in 3FXXXXXX00000000-3FXXXXXXFFFFFFFF


i just need to get lucky with 3 bytes.  how hard can that be?
or, get lucky with 2 bytes, but wait a week to find out.  that shouldn't take much more than 65535 weeks.

i was testing bitcrack in random...it will never find nothing as i decided...  he was looking to find 1 add in 3mlrd range ...6 hours)) lol