BitCrack - A tool for brute-forcing private keys - page 56.

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: chrysophylax on March 22, 2021, 08:26:53 AM

Quote from: WanderingPhilospher on March 22, 2021, 07:57:59 AM

Quote

Really? ...

Do you have the links to the faster ones?

The groundwork was laid a long time ago.

https://github.com/Telariust/VanitySearch-bitcrack

Faster, with multi gpu support. Take existing code and make the tweaks one wants/needs. Much easier to understand and tweak vs bitcrack, IMO. Pool operator can verify that it is faster as well. It also supports the newer cards, 30xx series.

Which pool are you looking at/working with?

#crysx

http://ttdsales.com/64bit/login.php
Agreed about pools/software/code.
I'd prefer a pool for BSGS attacking the puzzle addresses with known pubkeys; but I am a shade tree coder. I can follow code and make some tweaks here and there to try and get what I want the program to do.

chrysophylax

legendary

Activity: 2912

Merit: 1091

--- ChainWorks Industries ---

Quote from: WanderingPhilospher on March 22, 2021, 07:57:59 AM

Quote

Really? ...

Do you have the links to the faster ones?

The groundwork was laid a long time ago.

https://github.com/Telariust/VanitySearch-bitcrack

Faster, with multi gpu support. Take existing code and make the tweaks one wants/needs. Much easier to understand and tweak vs bitcrack, IMO. Pool operator can verify that it is faster as well. It also supports the newer cards, 30xx series.

Ah Yes ...

I have seen this. Never looked too far into it or used it though. A lot of forks out there Tongue

Pools are great in such a space as this, but the issue is that unless code is available for dissemination and Fine Tooth Combing, then it is difficult to 'assume' that the owners of pool are honest and equitable. Trust required. The complete opposit of what Crypto was but for in the first place Wink

Which pool are you looking at/working with?

#crysx

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote

Really? ...

Do you have the links to the faster ones?

The groundwork was laid a long time ago.

https://github.com/Telariust/VanitySearch-bitcrack

Faster, with multi gpu support. Take existing code and make the tweaks one wants/needs. Much easier to understand and tweak vs bitcrack, IMO. Pool operator can verify that it is faster as well. It also supports the newer cards, 30xx series.

chrysophylax

legendary

Activity: 2912

Merit: 1091

--- ChainWorks Industries ---

Quote from: WanderingPhilospher on March 22, 2021, 07:08:13 AM

Quote from: sp_ on March 22, 2021, 02:19:08 AM

The total ethereum hashrate is today 457.14TH and most of the hashing is done by gpu's.
Lets assume that each gpu hash in average around 30MHASH (gtx 1070ti, rx 570, rx 580)

That is a total of 15 238 000 gpu's hashing.

Let's assume that I added multicard support and stratum pool support to the bitcrack sp-mod and people redirect
their hashing power to crack the puzzle transaction.

The bitcoin puzzletransaction is worth ($1 900 000)
https://privatekeys.pw/puzzles/bitcoin-puzzle-tx
Puzzle #64 (64-65 bit)

2^64 / (400MKEYS * 15 238 000)= 3 026 seconds.

Puzzle #64 would be solved in 50 minutes
Puzzle #65 would be solved in 100 minutes.
Puzzle #66 would be solved in 200 minutes.
Puzzle #67 would be solved in 400 minutes.
...

Since the program scan the whole range of keys, the mining pool can also check if there are other private keys in the scanrange with money in the balance and payout to the miners.

Yeah I already pitched that idea months ago, with the same concept.
Multi-card already exist with faster hash rate. Bitcrack is like stone age, can't even support newest cards.
If you have the skill set, maybe work on multicard support first.
Also, pool exist for #64 but trying to get people to stay with it is the problem. Everyone thinks they can crack it on their own with 1 or 2 GPUs

And a solid OpenCL needs to be developed. Brichard19 has the knowledge; I've used his Kangaroo program using OpenCL and it is the only program out there that fully utilizes the power of the newer cards plus all the old cards and AMD cards.

Really? ...

Do you have the links to the faster ones?

Also - be VERY careful with those that purport to be doing this as a 'showing of muscles' in the development department, especially those with a history of ripping people off in the past. All it takes is a component of code in the 'private/compiled' software that is currently being distributed to report back and alert immediately to the creator of that 'Private' code so that he moves all funds for himself.

Greed plays a VERY big part in this arena, so be very aware of those that look like they are doing things FOR the community, when history has show they have done nothing more than make themselves rich off other peoples back.

As far as GPUFarms are concerned, there is a simpler way to 'mine' these systems, but it takes a complex matter of coding to achieve it, which requires 'real' coding genius.

#crysx

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: sp_ on March 22, 2021, 02:19:08 AM

The total ethereum hashrate is today 457.14TH and most of the hashing is done by gpu's.
Lets assume that each gpu hash in average around 30MHASH (gtx 1070ti, rx 570, rx 580)

That is a total of 15 238 000 gpu's hashing.

Let's assume that I added multicard support and stratum pool support to the bitcrack sp-mod and people redirect
their hashing power to crack the puzzle transaction.

The bitcoin puzzletransaction is worth ($1 900 000)
https://privatekeys.pw/puzzles/bitcoin-puzzle-tx
Puzzle #64 (64-65 bit)

2^64 / (400MKEYS * 15 238 000)= 3 026 seconds.

Puzzle #64 would be solved in 50 minutes
Puzzle #65 would be solved in 100 minutes.
Puzzle #66 would be solved in 200 minutes.
Puzzle #67 would be solved in 400 minutes.
...

Since the program scan the whole range of keys, the mining pool can also check if there are other private keys in the scanrange with money in the balance and payout to the miners.

Yeah I already pitched that idea months ago, with the same concept.
Multi-card already exist with faster hash rate. Bitcrack is like stone age, can't even support newest cards.
If you have the skill set, maybe work on multicard support first.
Also, pool exist for #64 but trying to get people to stay with it is the problem. Everyone thinks they can crack it on their own with 1 or 2 GPUs

And a solid OpenCL needs to be developed. Brichard19 has the knowledge; I've used his Kangaroo program using OpenCL and it is the only program out there that fully utilizes the power of the newer cards plus all the old cards and AMD cards.

sp_

legendary

Activity: 2926

Merit: 1087

Team Black developer

Quote from: NotATether on March 22, 2021, 06:03:05 AM

Each of the GPUs are only going to get $8.02 assuming (ridiculously) that all cards have the same key rate. The fact that they don't means that even the fastest cards can only really expect to get $12 out of #64 (unless you're the pool owner where you get a generous 1% commission) and that's why I think that stratum wasn't added to Bitcrack earlier.

The miner get payed by how many keys he finds. Remember we search all the keys in a given interval. A 1000 gpu farm will find more keys than a single gpu. The miningpool will have Double key protection. When a privatekey is found, the reward is split between the miners based on the valid keycount in the interval. Every key is not sent to the pool, so the keycount will be estimated according to the difficulty and valid shares.

sp_

legendary

Activity: 2926

Merit: 1087

Team Black developer

Bitcracking could perhaps run in parallell with etherhash for free. Just like the Claymore dual miner. Computing the ripe-160 hashes is basicly free. The gpu is stuck while waiting for the random memory accesses in ETHash and can perform compute operations in parallell for a cost of a few more watts.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: fxsniper on March 22, 2021, 05:09:21 AM

and some problem
1. mining can get profits 100% from rewards sure better than do bitcrack
2. profits from puzzle not enough for all people on pool

Each of the GPUs are only going to get $8.02 assuming (ridiculously) that all cards have the same key rate. The fact that they don't means that even the fastest cards can only really expect to get $12 out of #64 (unless you're the pool owner where you get a generous 1% commission) and that's why I think that stratum wasn't added to Bitcrack earlier.

fxsniper

member

Activity: 406

Merit: 47

Quote from: sp_ on March 22, 2021, 02:19:08 AM

The total ethereum hashrate is today 457.14TH and most of the hashing is done by gpu's.
Lets assume that each gpu hash in average around 30MHASH (gtx 1070ti, rx 570, rx 580)

That is a total of 15 238 000 gpu's hashing.

Let's assume that I added multicard support and stratum pool support to the bitcrack sp-mod and people redirect
their hashing power to crack the puzzle transaction.

The bitcoin puzzletransaction is worth ($1 900 000)
https://privatekeys.pw/puzzles/bitcoin-puzzle-tx
Puzzle #64 (64-65 bit)

2^64 / (400MKEYS * 15 238 000)= 3 026 seconds.

Puzzle #64 would be solved in 50 minutes
Puzzle #65 would be solved in 100 minutes.
Puzzle #66 would be solved in 200 minutes.
Puzzle #67 would be solved in 400 minutes.
...

Since the program scan the whole range of keys, the mining pool can also check if there are other private keys in the scanrange with money in the balance and payout to the miners.

you mean compare with now Ethereum power hash mine is use GPU card for mining

How many Workers require for can get 457.14TH ?

and some problem
1. mining can get profits 100% from rewards sure better than do bitcrack
2. profits from puzzle not enough for all people on pool

sp_

legendary

Activity: 2926

Merit: 1087

Team Black developer

The total ethereum hashrate is today 457.14TH and most of the hashing is done by gpu's.
Lets assume that each gpu hash in average around 30MHASH (gtx 1070ti, rx 570, rx 580)

That is a total of 15 238 000 gpu's hashing.

Let's assume that I added multicard support and stratum pool support to the bitcrack sp-mod and people redirect
their hashing power to crack the puzzle transaction.

The bitcoin puzzletransaction is worth ($1 900 000)
https://privatekeys.pw/puzzles/bitcoin-puzzle-tx
Puzzle #64 (64-65 bit)

2^64 / (400MKEYS * 15 238 000)= 3 026 seconds.

Puzzle #64 would be solved in 50 minutes
Puzzle #65 would be solved in 100 minutes.
Puzzle #66 would be solved in 200 minutes.
Puzzle #67 would be solved in 400 minutes.
...

Since the program scan the whole range of keys, the mining pool can also check if there are other private keys in the scanrange with money in the balance and payout to the miners.

fxsniper

member

Activity: 406

Merit: 47

Quote from: A-Bolt on March 16, 2021, 03:52:35 PM

Quote from: fxsniper on March 16, 2021, 02:47:04 AM

Can anyone help to fix about random function can not using large number
problem random.Next not work with 9223372036854775808 to 18446744073709551616

random.Next(9223372036854775808, 18446744073709551616)

Code:

UInt64 Base = 0x7FFFFFFFFFFFFFFF;

var random = new Random();

UInt64 high32Rnd = (UInt64)random.Next();
UInt64 low32Rnd = (UInt64)random.Next();

UInt64 rnd64 = (high32Rnd << 32) | low32Rnd;
rnd64 >>= 1;
rnd64 += Base;

Console.WriteLine(rnd64);

Hi, A-Bolt

I use this code for puzzle #64 it is works

and for puzzle # 120-#160 how can I change it to can use with puzzle #160
UInt64 can not use with very high bits puzzle #120 and #160

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: sp_ on March 21, 2021, 06:48:15 AM

#2 released

Added support for compute 5.0 and compute 7.5
~20% faster generation of starting points
~1% kernel speedup

https://github.com/sp-hash/Bitcrack/releases/

So clearly if this supports compute 7.5 then it won't make a misaligned address on those Roll Eyes

I will post my results here if it works.

Quote from: Markzuberg64 on March 21, 2021, 02:29:32 PM

No sir , this question is not related to bitcrack real use of key searching and i am looking to write sequential keypairs to file and not addresses , i.e. K and k*G . I saw that vanitygen and bitcracks are fast enough , so i am looking for ways to use these for my purpose or suggestions are welcome if using fastecdsa or other libraries directly from a c program will be faster . I believe it wont be .

Instead of trying to store all the k*G numbers (which is clearly impossible with current commodity storage sizes) why don't you just store all keypairs 2^n and 2^n * G [n is an integer], in other words powers of two?

They are extremely easy to generate since you just have to use successive point doubling, and any private key between G and 2^256*G can be generated fairly quickly by adding points that are powers of two (by looking at the integer multiplier). This is what VanitySearch does when it computes public keys, it makes a jump table with all of these powers of 2 Gs and then looks up the point in a hashtable using the factor as an index.

fxsniper

member

Activity: 406

Merit: 47

Quote from: Markzuberg64 on March 21, 2021, 02:38:19 PM

Quote from: WanderingPhilospher on March 21, 2021, 02:19:59 PM

Quote from: Markzuberg64 on March 21, 2021, 01:47:20 PM

Is it possible to use this modified version to write all generated keypairs to some file rather than to compare. Or any fast method to write keypairs pvk:pubkey . I had read on different posts that its possible to generate 15 billion of keypairs in under a minute. Is it true ? If yes then is this jut generation or writing to disk is also possible at this speed.

Generation/compare is easy at 15 billion in under a minute; it's the writing to disk that is unachievable at that speed, unless you have a high core count CPU. And even then, I don't know if you could write 15 billion keypairs in under a minute.

Can you guide me how to achieve that. Bitcrack generates hash160 and compares that with bloom . I guess keypair generation is way before that and high speed can be achieved. For writing part i will see what can be done. I think it can be done using your method of server client , in this case it will use high ram machines to generate in chunks and while one machine generate and writes , another one will work on another chunk till first one gets free.

for fast speed I think write to memory first and save one may be better but it require high memory ram, my experience write data to memory still slows same write file
if you want to save file why not use python code generate and save
I guess result is slow same, but try modify one for know from real
one warning you storage will be full very fast
if testing just 100GB and delete
if want to keep recommend to buy minimum 2 TB external storage to keep it
bitcrack generate fast
make sure you computer not working anything may be write to disk like program freeze no respond (work 100% DISK)

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: Markzuberg64 on March 21, 2021, 02:29:32 PM

Quote from: NotATether on March 15, 2021, 01:56:31 AM

Quote from: Markzuberg64 on March 15, 2021, 01:46:10 AM

Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once , till then next batch will find its space in memory to be written again.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.

No sir , this question is not related to bitcrack real use of key searching and i am looking to write sequential keypairs to file and not addresses , i.e. K and k*G . I saw that vanitygen and bitcracks are fast enough , so i am looking for ways to use these for my purpose or suggestions are welcome if using fastecdsa or other libraries directly from a c program will be faster . I believe it wont be .

So you are merely wanting to store private keys and their corresponding public keys, correct? In the same file or separate files?
combined file:
combined.txt
private key public key

separate files:
privfile1.txt
private key
pubfile 1.txt
public key

Markzuberg64

jr. member

Activity: 35

Merit: 2

Quote from: WanderingPhilospher on March 21, 2021, 02:19:59 PM

Quote from: Markzuberg64 on March 21, 2021, 01:47:20 PM

Is it possible to use this modified version to write all generated keypairs to some file rather than to compare. Or any fast method to write keypairs pvk:pubkey . I had read on different posts that its possible to generate 15 billion of keypairs in under a minute. Is it true ? If yes then is this jut generation or writing to disk is also possible at this speed.

Generation/compare is easy at 15 billion in under a minute; it's the writing to disk that is unachievable at that speed, unless you have a high core count CPU. And even then, I don't know if you could write 15 billion keypairs in under a minute.

Can you guide me how to achieve that. Bitcrack generates hash160 and compares that with bloom . I guess keypair generation is way before that and high speed can be achieved. For writing part i will see what can be done. I think it can be done using your method of server client , in this case it will use high ram machines to generate in chunks and while one machine generate and writes , another one will work on another chunk till first one gets free.

Markzuberg64

jr. member

Activity: 35

Merit: 2

Quote from: NotATether on March 15, 2021, 01:56:31 AM

Quote from: Markzuberg64 on March 15, 2021, 01:46:10 AM

Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once , till then next batch will find its space in memory to be written again.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.

No sir , this question is not related to bitcrack real use of key searching and i am looking to write sequential keypairs to file and not addresses , i.e. K and k*G . I saw that vanitygen and bitcracks are fast enough , so i am looking for ways to use these for my purpose or suggestions are welcome if using fastecdsa or other libraries directly from a c program will be faster . I believe it wont be .

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: Markzuberg64 on March 21, 2021, 01:47:20 PM

Is it possible to use this modified version to write all generated keypairs to some file rather than to compare. Or any fast method to write keypairs pvk:pubkey . I had read on different posts that its possible to generate 15 billion of keypairs in under a minute. Is it true ? If yes then is this jut generation or writing to disk is also possible at this speed.

Generation/compare is easy at 15 billion in under a minute; it's the writing to disk that is unachievable at that speed, unless you have a high core count CPU. And even then, I don't know if you could write 15 billion keypairs in under a minute.

Markzuberg64

jr. member

Activity: 35

Merit: 2

Is it possible to use this modified version to write all generated keypairs to some file rather than to compare. Or any fast method to write keypairs pvk:pubkey . I had read on different posts that its possible to generate 15 billion of keypairs in under a minute. Is it true ? If yes then is this jut generation or writing to disk is also possible at this speed.

fxsniper

member

Activity: 406

Merit: 47

Quote from: sp_ on March 21, 2021, 08:36:10 AM

Quote from: _Counselor on March 21, 2021, 07:59:47 AM

V100 -b 80 -t 512 -p 2800 ~1575Mkey
P100 -b 112 -t 512 -p 2000 ~580Mkey

try to run without the -b and -t parameter. My exe will autotune to a good launchconfig.

With sp-mod #2 I get

1070: 370 MKey
1070ti: 404Mkey
1080ti: 600Mkey
Titanx pascal: 560Mkey

my 1050: 11-50 Mkey just a little toy

but I think make it faster is not answer puzzle challenge
make it fast 10Gigkey still use million year to scan
puzzle need algorithm to calculate
but make it faster is good to prepare for next algorithm

sp_

legendary

Activity: 2926

Merit: 1087

Team Black developer

Quote from: _Counselor on March 21, 2021, 07:59:47 AM

V100 -b 80 -t 512 -p 2800 ~1575Mkey
P100 -b 112 -t 512 -p 2000 ~580Mkey

try to run without the -b and -t parameter. My exe will autotune to a good launchconfig.

With sp-mod #2 I get

1070: 370 MKey
1070ti: 404Mkey
1080ti: 600Mkey
Titanx pascal: 560Mkey

Topic: BitCrack - A tool for brute-forcing private keys - page 56. (Read 76850 times)