BitCrack - A tool for brute-forcing private keys

[Markzuberg64]

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.

[1714887328]

1714887328

[1714887328]

1714887328

[1714887328]

1714887328

[WanderingPhilospher]

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

[fxsniper]

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)

[NotATether]

#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  I will post my results here if it works.

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]

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

[sp_]

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]

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

[NotATether]

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.

[sp_]

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.

[sp_]

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.

[WanderingPhilospher]

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.

[chrysophylax]

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]

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]

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

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

Which pool are you looking at/working with?

#crysx

[WanderingPhilospher]

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.

[fxsniper]

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.

pool scan already 1 Quadrillion from all 9 Quadrillion
but pool not have much for active user
I think pool need more active user

[chrysophylax]

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.

I am not a coder - just tinker ...

I have coders working/helping in a team. They are the REAL professionals in this space, not me. I am however the idea and deal maker. The owner and the visionary behind all that has been built thus far. Always looking and listening and always taking on board advice from the professionals that do the work and code that I need.

In saying this though, I know nothing of a pool system that crunches these keys. If I did, I would have one setup a long time ago - all open source.

I guess the difference is that when you trust the pool operator/owner, then that is the point of failure, but also the strength if that person is solid.

There are ways to increase the compute power by levels of magnitude, and I know what some of those are, but need the coders to do the coding to bring these things to life. I guess when I am more serious about committing resources to such a project, I will look for more of those type of coders. Till then, is there any Pool Software at all that could be setup for complete transaprency of what is being done?

#crysx

[WanderingPhilospher]

Till then, is there any Pool Software at all that could be setup for complete transaprency of what is being done?

Easy to setup, open source

https://github.com/Etayson/BC_server-client

Even has checks and balances of "fake" shares/submits by creating a key in each range that is checked/verified. Same as other pool.

There are ways to increase the compute power by levels of magnitude, and I know what some of those are, but need the coders to do the coding to bring these things to life.

Interested in ideas...always.

[chrysophylax]

Till then, is there any Pool Software at all that could be setup for complete transaprency of what is being done?

Easy to setup, open source

https://github.com/Etayson/BC_server-client

Even has checks and balances of "fake" shares/submits by creating a key in each range that is checked/verified. Same as other pool.

There are ways to increase the compute power by levels of magnitude, and I know what some of those are, but need the coders to do the coding to bring these things to life.

Interested in ideas...always.

Thanks ...

Will have a look at this over the coming week.

As for connection - Skype is the best way to get me. Alternately, the CWI Discord Server in the Details Page of the Main CWI BCTThread in my Sig.

Skype - chrysophylax69

#crysx

[NotATether]

Seems like I missed quite a discussion going on here  

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.

Yeah I didn't mean to imply that everyone's going to be paying a fixed reward, people are actually less likely to mine [keys? I like that phrase  ] at pools that'll only give them a fixed amount of money.

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.

One of my wild fantasies is to learn OpenCL to make a version of the Kangaroo Int class that runs on AMD cards. Sadly for now it remains a fantasy as I got my hands tied with what I'm now going to call "Kangaroo-256", and I'm already learning CUDA the hard way - through trial and error. I don't expect OpenCL to be any different.

Before this I didn't think Telariust VanitySearch-Bitcrack combo was legit, or at the very least I thought it was some rudimentary mishmash whose sum was less than the parts. Nice to know I have something else to open up my eyes to as well.

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.

Definitely not me that's for sure. I know this is not an accusation at me obviously

Actually y'all can take a stab at what I'm working on at https://gitea.datahoarding.agency/ZenulAbidin/Kangaroo-256 on my own git server and not on github cause this is still alpha and I didn't feel like pushing broken code to Github.

This'll eventually hit github when it's completely finished.

I have some other commits beyond this at local particularly on the GPU side of things but I'm not quite done with them yet (there is a nasty segfault I have to debug).

I think it's a step in the right direction.