BitCrack - A tool for brute-forcing private keys

[NotATether]

Huh? It simply means you don't have 10.2 loaded on your machine. No hackery needed. Just download 10.2

Or change the reference to whichever CUDA you are running. 10.0, 10.1, 11.0, 11.1, etc. Not sure it will compile with the 11s though.

Why should I have to download another CUDA version when I already have 11.2? BTW I managed to get it working on Linux CUDA 11.2 so I don't see how Windows should be any different.

I hate how the solution properties are extracted out to a separate file that I can't even find though. 

[1714472052]

1714472052

[1714472052]

1714472052

[1714472052]

1714472052

[1714472052]

1714472052

[1714472052]

1714472052

[1714472052]

1714472052

[jacky19790729]

Huh? It simply means you don't have 10.2 loaded on your machine. No hackery needed. Just download 10.2

Or change the reference to whichever CUDA you are running. 10.0, 10.1, 11.0, 11.1, etc. Not sure it will compile with the 11s though.

Why should I have to download another CUDA version when I already have 11.2? BTW I managed to get it working on Linux CUDA 11.2 so I don't see how Windows should be any different.

I hate how the solution properties are extracted out to a separate file that I can't even find though. 

Google  "NVIDIA GPU Computing Toolkit" then download from nvidia
You need install v8.0,  v10.2, v11.2  if you want to compile  Kangaroo/Bitcrack/VanitySearch 
VC_CUDA8/Kangaroo.sln
VC_CUDA10/Kangaroo.sln
VC_CUDA102/Kangaroo.sln

[NotATether]

Google  "NVIDIA GPU Computing Toolkit" then download from nvidia
You need install v8.0,  v10.2, v11.2  if you want to compile  Kangaroo/Bitcrack/VanitySearch 
VC_CUDA8/Kangaroo.sln
VC_CUDA10/Kangaroo.sln
VC_CUDA102/Kangaroo.sln

See this is what I want to fix. Having to download three different CUDA versions just to compile Bitcrack is absurd, when you consider that only one of them is needed.

I wonder if the 8.0 and 10.2 versions are only used in the debug mode or 32-bit configurations? Who even runs 32-bit Bitcrack anymore NVIDIA drivers only run on 64-bit Windows now and so having 32-bit targets just sounds redundant to me.

[renedx]

We already incurred a speed penalty just to make it work for RTX cards and the last thing everyone needs is a even slower program just to get it to run on Linux.

Then you are doing something wrong.
My first RTX 3060 card has arrived and I will make a fix in bitcrack sp-mod #6 (windows) with fullspeed wine support.
spminer #2 for vertcoin has already been released with rtx 3060 support. Mine fullspeed on x1 riser cables and latest drivers without NVIDIA blocking you.  

Any updates?

[zahid888]

We already incurred a speed penalty just to make it work for RTX cards and the last thing everyone needs is a even slower program just to get it to run on Linux.

Then you are doing something wrong.
My first RTX 3060 card has arrived and I will make a fix in bitcrack sp-mod #6 (windows) with fullspeed wine support.
spminer #2 for vertcoin has already been released with rtx 3060 support. Mine fullspeed on x1 riser cables and latest drivers without NVIDIA blocking you.  

Any updates?

??

[btc-room101]

We already incurred a speed penalty just to make it work for RTX cards and the last thing everyone needs is a even slower program just to get it to run on Linux.

Then you are doing something wrong.
My first RTX 3060 card has arrived and I will make a fix in bitcrack sp-mod #6 (windows) with fullspeed wine support.
spminer #2 for vertcoin has already been released with rtx 3060 support. Mine fullspeed on x1 riser cables and latest drivers without NVIDIA blocking you. 

Any updates?

??

My RTX-3070's are doing over 2,000M/sec for cracking btc private keys and matching known valuable addresses using bloom filters. Same algo's on Gtx-1060 is about 200MB/sec

On a rack of 4 RTx-3070's, I'm seeing 10,000M/sec, using 32gb bloom filter with from 300M addresses (H160), my false positive is 10^-30

I only use linux

The main thing is to put the bloom-filter inside of bitcrack, so your not just looking for one public-key, and/or address, but your testing all 300M in parallel on every cycle ( here 10,000M/sec ), so the probablity of a hit in the secp256k1 space 2^256, or 10^76 is reasonable

Keep the bloom filter on its own M.2 drive on MOBO, have 4tb sata for hex-files, and private key database ( you need to be able to map your found hex160 )

I have two racks one using gtx-1060's the other Rtx-3070's, which I picked up last summer for $500/each, now they're +$1,000 if you can find them. CPU needs 64GB, I'm running amd threadripper with 32 core, this is not a game for windows.

Real problem here is setting up the bloom-filter, orginal model in brainflayer was 512MB, which only allows about 15M addresses, before false-positive goes astro. Solution is to cascade 4gb junks in series, as most shared memory models only allow 4gb chunks, 3 years ago using open-gl I had the bloom filters on the GPU ( gtx-1070 ), but you can only have 2gb chunks, and its actually faster to do blocks of 2048 private-keys, and then have each gpu core pass them back to threads all running cpu cores on the shared bloom-filter. With 300M valid btc  addresses, you really need a 32gb bloom filter. None of this stuff is online, you must roll your own.

that is a goog question. is it possible to speed that up, comparing two list with millions of lines?

If you sort the file and use binary search to look for each item in your list then your runtime becomes O(log2(n)) for each  for each entry and so you're going to have a maximum of O(NumberOfAddresses*log2(n)) as your worst case runtime. It's really not slow, that's about 30 units of time to search for an address in a list with 1,000,000,000 lines in it.

Actually fitting all that into memory is going to be a problem though. There are some algorithms I read in a Knuth book about on-disk sorting but they're very old and I think they may have to be adapted for hard disks instead of tapes.

You can't search for a h160 address in a 300gb file, you must map the file to binary. Then the file will be 10gb, and it just takes a second to yes/no whether that h160 is in the list of 300M addresses.

Early brainflay github had a tool called 'binchk' using xed ( linux ) you convert the 300gb file to uniq-hex, and get the .bin file, use binchk

Brainflayer needed to use this because the 512mb bloom-filter they use, only allowed about 10M addresses before false-positive went astro, with the binchk you can take the false positives and very if any of them are real postive.

The bloom-filter is super fast, can work on GPU, but the false-positive is high.

No point in using binary search on text, just use the model described.

Today when I scrape the blockchain, I get about 300M addresses, but after you do the "sort -u", it will be slightly less, but you also need to run a client on the memory pool, to constantly add the new addresses to the bloom-filter.

If you comparing lists with 300M lines of hex, and/or search its much better to use bloom-filters and binary search combined, drops the 2+ hour search to seconds.

[moderator's note: consecutive posts merged]

[WanderingPhilospher]

that is a goog question. is it possible to speed that up, comparing two list with millions of lines?

If you sort the file and use binary search to look for each item in your list then your runtime becomes O(log2(n)) for each  for each entry and so you're going to have a maximum of O(NumberOfAddresses*log2(n)) as your worst case runtime. It's really not slow, that's about 30 units of time to search for an address in a list with 1,000,000,000 lines in it.

Actually fitting all that into memory is going to be a problem though. There are some algorithms I read in a Knuth book about on-disk sorting but they're very old and I think they may have to be adapted for hard disks instead of tapes.

You can't search for a h160 address in a 300gb file, you must map the file to binary. Then the file will be 10gb, and it just takes a second to yes/no whether that h160 is in the list of 300M addresses.

Early brainflay github had a tool called 'binchk' using xed ( linux ) you convert the 300gb file to uniq-hex, and get the .bin file, use binchk

Brainflayer needed to use this because the 512mb bloom-filter they use, only allowed about 10M addresses before false-positive went astro, with the binchk you can take the false positives and very if any of them are real postive.

The bloom-filter is super fast, can work on GPU, but the false-positive is high.

No point in using binary search on text, just use the model described.

Today when I scrape the blockchain, I get about 300M addresses, but after you do the "sort -u", it will be slightly less, but you also need to run a client on the memory pool, to constantly add the new addresses to the bloom-filter.

If you comparing lists with 300M lines of hex, and/or search its much better to use bloom-filters and binary search combined, drops the 2+ hour search to seconds.

So you are storing and searching 300 Million addresses? How many of those have a balance? Are you just looking for a H160 collision?  Curious to know why you are doing what you are doing; doesn't seem like the typical trying to find balances.

[Jdiksliqppxoxo]

Bitcrack worked some time with ./clBitCrack -c -u -i ./addresses -o ./found.txt --keyspace $somekeyspace:+$anotherkeyspace -b 48 -t 128 -p 400

Now I have in found.txt string with "15addr... PrivKey PubKey". 15addr... i found in addresses file. Private key I converted to base58check and got another one than i found in file found.txt. It's 1PKSP... or 1JREjy... Tried both compressed and uncompressed. PubKey in found.txt looks very strange 020000000000000000000000000000000000000000000000000000000000000000.

Why I have in found.txt file Private key for another address? o_O Why pubkey so strange?

clbitcrack, amd card.

./clBitCrack -i testkeys --keyspace mykeyspace:keyspace+somekeyspace --compression both  (testkeys is only 1JREjyd.... address)
found same PrivKey as in found.txt file, but another PubKey

Somebody got same strange results?

upd:
I think maybe it is a bloom filter collision...

[DKril]

Wow! Amazing I like know more and I have equally successfully developed a tool to help you recover your btc funds be it lost or stolen in any way and also help you transform non spendable funds into Spendable and many other interesting features. Checkout https://www.bestbitcoinprivatekeyrecovery.org

[zahid888]

Burn More https://blockchain.com/btc/payment_request?address=14ZZZUFCSjwmeewom7UrHcprHTUNcWTpcE&amount=100&message=Burn MoreWhy people are burning Bitcoins

[btc-room101]

that is a goog question. is it possible to speed that up, comparing two list with millions of lines?

If you sort the file and use binary search to look for each item in your list then your runtime becomes O(log2(n)) for each  for each entry and so you're going to have a maximum of O(NumberOfAddresses*log2(n)) as your worst case runtime. It's really not slow, that's about 30 units of time to search for an address in a list with 1,000,000,000 lines in it.

Actually fitting all that into memory is going to be a problem though. There are some algorithms I read in a Knuth book about on-disk sorting but they're very old and I think they may have to be adapted for hard disks instead of tapes.

You can't search for a h160 address in a 300gb file, you must map the file to binary. Then the file will be 10gb, and it just takes a second to yes/no whether that h160 is in the list of 300M addresses.

Early brainflay github had a tool called 'binchk' using xed ( linux ) you convert the 300gb file to uniq-hex, and get the .bin file, use binchk

Brainflayer needed to use this because the 512mb bloom-filter they use, only allowed about 10M addresses before false-positive went astro, with the binchk you can take the false positives and very if any of them are real postive.

The bloom-filter is super fast, can work on GPU, but the false-positive is high.

No point in using binary search on text, just use the model described.

Today when I scrape the blockchain, I get about 300M addresses, but after you do the "sort -u", it will be slightly less, but you also need to run a client on the memory pool, to constantly add the new addresses to the bloom-filter.

If you comparing lists with 300M lines of hex, and/or search its much better to use bloom-filters and binary search combined, drops the 2+ hour search to seconds.

So you are storing and searching 300 Million addresses? How many of those have a balance? Are you just looking for a H160 collision?  Curious to know why you are doing what you are doing; doesn't seem like the typical trying to find balances.

I'm seeing 10,000MB-sec rate of addr-priv compare on a rack of 4 rtx-3070, check 300M all at once, means I'm running 30*10^20/sec addr-priv key compares,  birthday problems says 50% prob in a field of 2^128

You hit lots of addresses with value, problem is most addresses have 0.05 or less, and the number of addresses over 1 is 1,000's, and the number of addresses with say 0.5 or more is probably 10,000, the odds of finding 1/10,000 in 1/10^38 is rather nil

You can find dust, but I don't do this for money, I dont' even have an exchange account, I'm just doing this for commutational-fun

I think if you 'scale' that is, if somebody has a GPU farm, and they re-purpose dozens of GPU racks to this, they could probably find the majority of value quite quickly.

The problem is there are only a few thousand super high-value addressses left, 5 years ago there were 1,000's of satoshi virgin 50+ btc public-keys, today there less than 900 and dropping monthly, so somebody is trading out these addresses, and it ain't satoshi

...

To answer your question my god, nobody is storing 300M addresses, learn what a bloom-filter is & does, its a way of compressing 300M address ( 300GB hex-text file ) into a 16GB binary file that can say/no in nano-seconds rather than hours

It's really frustrating on this forum because most people don't bother to learn, and the moderators censor anything that rises the minions; The majority of legacy bitcoin-core is dedicated to status-quo, so sure they'll all just get old & die, thank god for young people. "They" don't want anybody to know the real, the entire BTC paradigm is lies, on lies, and anybody that say's the emperor has no clothes is silenced.  Too many vested interests, how is this any different than the people who run the Federal Reserve Bank???

[WanderingPhilospher]

To answer your question my god, nobody is storing 300M addresses, learn what a bloom-filter is & does, its a way of compressing 300M address ( 300GB hex-text file ) into a 16GB binary file that can say/no in nano-seconds rather than hours

Didn't mean for you to go all political. Was asking a question...I didn't ask how they were stored, just if you were storing them, regardless of binary, compressed, etc. I don't need a bloom filter to search all addresses with a balance. A simple python script running random keys can check the 24 million addresses, in less than a nano-second, all at same time.  A simple python script stores the addresses and can check 1000s of keys per second and compare each key to the 24 million addresses, on a single CPU thread.  Bitcrack and Vanity can do the same, though their MKey/s rate drops; python's does not. So using a bloom, is it really "special"?  Especially for running/checking against ghost and dust addresses? Oh yeah, your commutational-fun.


And I believe there are quite a few more than 900 50+ BTC "virgin" addresses still out there.  But I wish you luck in your fun.

[NotATether]

~

Any updates?

??

I hate making excuses but just when I was ready to work on VS project files for my fork today I learned that my Windows box is being serviced for the next few hours. So looks like a no-go for now. Resolved

Now I'm getting cuda.h not found after updating the props names in the vcxproj files... I need to put my custom include directory inside its search path somehow.

Wow! Amazing I like know more and I have equally successfully developed a tool to help you recover your btc funds be it lost or stolen in any way and also help you transform non spendable funds into Spendable and many other interesting features. Checkout https://www. no bestbitcoinprivatekeyrecovery backlinks .org

Your contains tidbits like this on the front page:

Bitcoin dust attack is performed by sending $1 to any wallet you wanna sweep away it entire funds. A dust doesn’t requires a specific coin state,a dust is send to non-spendable funds as-well as confirmed or unconfirmed bitcoins.

private key is an encrypted alphanumeric code that permits access to your bitcoin or cryptocurrency holdings. It is the only true way of proving that you are the owner.

Eh?   This looks more like a phishing attempt than a real cracker.

Brainflayer needed to use this because the 512mb bloom-filter they use, only allowed about 10M addresses before false-positive went astro, with the binchk you can take the false positives and very if any of them are real postive.

I'm trying to find relation between the bloom filter size and max number of addresses for a tolerable FP rate because being able to use more than 512MB memory would be handy.

Real problem here is setting up the bloom-filter, orginal model in brainflayer was 512MB, which only allows about 15M addresses, before false-positive goes astro. Solution is to cascade 4gb junks in series, as most shared memory models only allow 4gb chunks, 3 years ago using open-gl I had the bloom filters on the GPU ( gtx-1070 ), but you can only have 2gb chunks, and its actually faster to do blocks of 2048 private-keys, and then have each gpu core pass them back to threads all running cpu cores on the shared bloom-filter. With 300M valid btc  addresses, you really need a 32gb bloom filter. None of this stuff is online, you must roll your own.

Yeah, when you're working in parallel with multiple GPUs each device memory is separated from each other and so you have to split the bloom filter accordingly, so you don't offload that part of the code to CPU. And then compressing the R160 hashes down to binary dramatically speeds up the initialization time by avoiding reading several dozen GB and is what makes large bloom filters practical in the first place.

We can actually reserve most of the memory for the bloom filters, and the array of addresses themselves can be placed in host memory because finding a match doesn't happen very often, it'll only be used for output and logging anyway.

[BHWallet]

Why don't you fork the existing repository? Then it will be easier to see what you have changed.

My repo is forked from https://github.com/BoGnY/BitCrack/

BoGnY's the one who added random mode and updated the CUDA VS props to 10.2. He also added the memory vectorization stuff (I think that's where my speed boost is coming from).

All the commits between 786ea361 and c3121cf6 are his changes https://github.com/ZenulAbidin/BitCrack-3000/compare/786ea361..c3121cf6 , everything after c3121cf6 are my changes.

Please upload compiled exe, I'm having problems with openCL, thx

Also, have you fixed the stride option?

[zahid888]

Address:  1MVRjUctcb3sRTDcyDpn7fggdFkdMApvvZ     Dec:  165033644524273768307     Hex:  8f24d494f216d9773
AddreIs:  1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

Address:  1MVSM7UVQsf5E7D1kGqR7g8JFp3ABrQvvZ     Dec:  240558293154646159895     Hex:  d0a6abd1778f77217
AddreIs:  1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

Address:  16jcRHV7HxMB6NQWUX3U3Ef4VgTiZn2XQN     Dec:  85835904429154821725      Hex:  4a736644cda26e65d
AddreIs:  16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

Address:  1MV4H2nVajL65MtmsMctQGVvvo7rLKAvvZ     Dec:  102938117123567770991     Hex:  5948da82265cfdd6f
AddreIs:  1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

Address:  13zndWQ4ZcnZH9dBEHpDjUfN8m3nbvq5so     Dec:  169607331192411636050     Hex:  931c64919f1b9c152
AddreIs:  13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

Address:  1BYQv4ScdgbeUhBGQUP75de5bjXeaFTdW9     Dec:  113451942910014718036     Hex:  6267644fb85530054
AddreIs:  1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9

Address:  13zfJmXxZJTCv8TpkiUgVfNWtL1iUEJ5so     Dec:  152866838231780983465     Hex:  849741b72d66882a9
AddreIs:  13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

Address:  16jH5ADC2B8RzpGbtJzX3m2TbkVFZnjXQN     Dec:  74634585985448366257      Hex:  40bc35085d4ff50b1
AddreIs:  16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

Address:  1BYAYH7WTUYoZLrBUTPtLqZqzvXYhZzdW9     Dec:  274348818725057147740     Hex:  edf5acd116f11335c
AddreIs:  1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9

Address:  1BYttrtQA3Zsu46STLa4CnqGSTE1QVddW9     Dec:  126433864629863105965     Hex:  6da9f52016ad0c5ad
AddreIs:  1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9

Address:  1MVBGdbXfqAuUGnSKma3usarNXgQw8jvvZ     Dec:  71847522591485806617      Hex:  3e515ad21e95d4819
AddreIs:  1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

Address:  16jnxmExCd3R2HMgq5iUe3BPTGHx8XzXQN     Dec:  50839530351450494269      Hex:  2c18a4b7ec9e5953d
AddreIs:  16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

Address:  1BYECfoB9QktQPTooY2obZ45ZujTaLdW9      Dec:  94446020718149362758      Hex:  51eb3ab725a79e446
AddreIs:  1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9

Address:  16jFsFphfpCxnfZfBebUJonireUDdP2XQN     Dec:  224654018819515632568     Hex:  c2db367d92d264bb8
AddreIs:  16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

[sp_]

I am making bitcrack for ethereum is this something the community want to support?

[sp_]

So.. when your sp-mod #6 will arrive ?? hope very soon we will get rid of that message (Error: misaligned address).

I have given you a faster program. Your job is to opensource a fix, and then I might build another exe

[zahid888]

So.. when your sp-mod #6 will arrive ?? hope very soon we will get rid of that message (Error: misaligned address).

I have given you a faster program. Your job is to opensource a fix, and then I might build another exe

It all goes over my head but i will try, It would be better if you make exe. Thanks

[fxsniper]

if anyone use python code for brute force recommend to use bitCrack version have RANDOM options (use -r )

bitCrack random version it is very fast more than python code

I try python is very slow,  I looking for python for GPU use (numba or other python use GPU but not found never have anyone code bitcoin generate address on GPU)

[NotATether]

So.. when your sp-mod #6 will arrive ?? hope very soon we will get rid of that message (Error: misaligned address).

I have given you a faster program. Your job is to opensource a fix, and then I might build another exe

It all goes over my head but i will try, It would be better if you make exe. Thanks

...Meanwhile in my VS workspace, I managed to get the .cu files to compile but .h and .cpp files are still bailing out - I probably need to add the include paths to Visual C/C++ object properties (why doesn't CUDA installer do this by default?  )

On a side note, the CUDA Installer also installs headers for OpenCL in the same folder, but I unloaded the clBitcrack projects so I don't worry about updating include dirs for that set of projects for now.