Free high performance tool for fast scanning random Bitcoin, Bitcoin Cash, Bitcoin SV, Litecoin, Dogecoin, Dash, Zcash (and many more) private keys and finding addresses with balance. The main goal is to generate as fast as possible (Bitcoin/Altcoin) addresses using the JVM combined with OpenCL and check if the address (RIPEMD160 hash) was used/not used before. This includes possible hash collisions.

Copyright (c) 2017-2024 Bernard Ladenthin.

• Java 21 or newer. Java 8, 11, 17 is not supported anymore.

1. Download the binary (jar) from https://github.com/bernardladenthin/BitcoinAddressFinder/releases
2. Download and extract the light database from https://github.com/bernardladenthin/BitcoinAddressFinder#use-my-prepared-database
3. Download a configuration set like
4. https://github.com/bernardladenthin/BitcoinAddressFinder/blob/main/examples/logbackConfiguration.xml
5. https://github.com/bernardladenthin/BitcoinAddressFinder/blob/main/examples/config_Find_1OpenCLDevice.js
6. https://github.com/bernardladenthin/BitcoinAddressFinder/blob/main/examples/run_Find_1OpenCLDevice.bat
7. Put all in one directory like the following structure

• Downloads
  • lmdb
    • data.mdb
    • lock.mdb
  • bitcoinaddressfinder-1.3.0-SNAPSHOT-jar-with-dependencies.jar
  • logbackConfiguration.xml
  • config_Find_1OpenCLDevice.js
  • run_Find_1OpenCLDevice.bat

5. Run the file run_Find_1OpenCLDevice.bat

• Support blockchain addresses which are based on secp256k1.
• Unit tested (trusted) open source which can be compiled easily from yourself.
• Vanitygen of bitcoin addresses using regex pattern.
• Runs completely offline. No internet required or used. You can run it in a bunker with an electric generator somewhere in nowhere and nobody knows it.
• No synchronisation necessary to run multiple instances. Random numbers are used and a search organization is not necessary. Just start on multiple computers.
• Check with a high performance database containing addresses if generated address are already in use.
• Portable, plattform independend, runs on JVM.
• Generate uncompressed and compressed keys at once.
• EC-Key generation via
  • Multiple CPU Threads
  • Multiple OpenCL devices (optional)

The addresses will be inserted in a high performance database LMDB. The database can be used to check if a generated addresses is ever used.

The importer read multiple txt/text files containing the following addresses in arbitrary order. Each line can contain a different format.

• P2PKH
  • bitcoin
  • bitcoin cash
  • bitcoin gold
  • blackcoin
  • dash
  • digibyte
  • dogecoin
  • feathercoin
  • litecoin
  • litecoin cash
  • namecoin
  • novacoin
  • reddcoin
  • vertcoin
  • ZCash
• P2WPKH
  • bitcoin Bech32

Useful txt/text file provider:

• http://blockdata.loyce.club/alladdresses/
• https://blockchair.com/dumps

The exporter writes all addresses in different formats:

• HexHash: The hash160 will be written encoded in hex without the amount. Optimal viewing with a viewer with a fixed width (e.g. HxD).
• FixedWidthBase58BitcoinAddress: The addresses will be written with a fixed width and without the amount. Optimal viewing with a viewer with a fixed width (e.g. HxD).
• DynamicWidthBase58BitcoinAddressWithAmount: The addresses will be written with amount.

I am in the process of preparing databases filled with numerous Bitcoin and altcoin addresses (refer to the Import Support section for more information). The sources of this information are confidential; however, you have the permission to extract any and all addresses. Should there be any information you find lacking or have questions about, do not hesitate to ask.

• Light (5.25 GiB), Last update: March 22, 2024
  • Contains Bitcoin addresses whith amount and many altcoin addresses with amount.
  • Static amount of 0 is used to allow best compression.
  • Unique entries: 119509048
  • Mapsize: 5376 MiB
  • Time to create the database: ~9 hours
  • Link (3.3 GiB zip archive): http://ladenthin.net/lmdb_light.zip
  • Link extracted addresses as txt (2.1 GiB zip archive); open with HxD, set 42 bytes each line: http://ladenthin.net/LMDBToAddressFile_Light_HexHash.zip

• Full (55.0 GiB), Last update: March 22, 2024
  • Contains all Bitcoin addresses which are ever used and many altcoin addresses with and without amount.
  • Static amount of 0 is used to allow best compression.
  • Unique entries: 1251129601
  • Mapsize: 56048 MiB
  • Time to create the database: ~54 hours
  • Link (29.7 GiB zip archive): http://ladenthin.net/lmdb_full.zip
  • Link extracted addresses as txt (21.2 GiB zip archive); open with HxD, set 42 bytes each line: http://ladenthin.net/LMDBToAddressFile_Full_HexHash.zip

• https://github.com/Pymmdrza/Rich-Address-Wallet
• https://github.com/mycroft/chainstate
• https://github.com/graymauser/btcposbal2csv
• https://blockchair.com/dumps
• https://balances.crypto-nerdz.org/

Attention: Do not use this software in a productive, non safe environment. A safe environment might be a dedicated computer with an air gap / disconnected network. A side-channel attack is possible and the software is optimized for performance and not constant-time. You may use a paper wallet for created vanity keys.

Find personal vanity addresses and check if addresses already exists in the lmdb can be used together.

A key range can be defined (e.g. 64-bit) whereas the first (e.g. 192-bit (256-bit - 64-bit)) are zeroed. This can be used to creaty keys in a specific range to find keys in a known range (e.g. Bitcoin Puzzle Transaction). This can be also used to proof that the software works.

To increase the performance of the EC-key generation OpenCL can be used. A common secret is transfered to the OpenCL device with a fixed grid size. Each OpenCL thread creates a different EC-Key because it add its thread-id to the secret. Therefore a range of EC-keys for a fixed grid size is created at once and will be transfered back to the main memory. The CPU is now able to hash the x,y coordinate of the EC-key to create (Bitcoin/Altcoin) addresses. The CPU doesn't spend most of its time for EC-key generation and can be used more efficient for hashing and database lookups.

The OpenCL mode has a Built-in self-test (BIST) to compare the OpenCL results with CPU based EC-Key generation. This allows an end user to verify it's OpenCL device is working properly.

The effective keys / s using uncompressed and compressed keys. OpenCL creates uncompressed keys only. A compressed key can be deduced easily from the uncompressed key.

It's impossible to find collisions, isn't it? Please find the answear for vulnerability questions somewhere else:

• https://crypto.stackexchange.com/questions/33821/how-to-deal-with-collisions-in-bitcoin-addresses
• https://crypto.stackexchange.com/questions/47809/why-havent-any-sha-256-collisions-been-found-yet
• https://github.com/treyyoder/bitcoin-wallet-finder#results
• https://github.com/Frankenmint/PKGenerator_Checker#instructions
• https://github.com/Xefrok/BitBruteForce-Wallet#requeriments

• The LBC is optimized to find keys for the Bitcoin Puzzle Transaction. It require communication to a server, doesn't support altcoin and pattern matching.
• https://privatekeys.pw/scanner/bitcoin
• https://allprivatekeys.com/get-lucky
• https://allprivatekeys.com/vanity-address
• https://github.com/treyyoder/bitcoin-wallet-finder
• https://github.com/albertobsd/keyhunt
• https://github.com/mvrc42/bitp0wn
• https://github.com/JeanLucPons/BTCCollider
• https://github.com/JeanLucPons/VanitySearch
• https://github.com/JamieAcharya/Bitcoin-Private-Key-Finder
• https://github.com/mingfunwong/all-bitcoin-private-key
• https://github.com/Frankenmint/PKGenerator_Checker
• https://github.com/Henshall/BitcoinPrivateKeyHunter
• https://github.com/Xefrok/BitBruteForce-Wallet
• https://github.com/Isaacdelly/Plutus
• https://github.com/Noname400/Hunt-to-Mnemonic
• https://github.com/Py-Project/Bitcoin-wallet-cracker

An export of the full database can be used to predict private keys with deep learning. A funny idea: https://github.com/DRSZL/BitcoinTensorFlowPrivateKeyPrediction

If you have a laptop like HP ZBook G3/G4/G5 "hybrid graphics" mode is very slow because of the shared memory. Please select in the BIOS "discrete graphics".

• Refactor the entire key generation infrastructure to support a key provider. This provider should be configurable to supply private keys from various sources, such as Random, Secrets File, Key Range, and others. All consumers should retrieve keys from this provider.

• Key generation within a specific key range. See #27 Wished from themaster:

"privateKeyStartHex" : "0000000000000000000000000000000000000000000000037e26d5b1f3afe216"
"privateKeyEndHex" : "0000000000000000000000000000000000000000000000037e26d5b1ffffffff"

Wished from Ulugbek:

// Search started from given address. Would be nice if it can save last position...
"sequentalSearch" : true,
"startAddress" : xxxxxxxx,

// Random search with batches, here 100000. I,e. some random number is found and after 100000 sequental addresses should be checked.
"searchAsBatches" : true,
"searchBatchQuantity" : 100000,


// Random search within Address Space, with batches, here 100000.
"searchAsBatches" : true,
"searchAddressStart" : xxxxxxx,
"searchAddressEnd" : xxxxxxxy,
"searchBatchQuantity" : 100000

• Incomplete Seed-Phrase as Private KeyProvider. Wished from @mirasu See #38
• Socket KeyProvider for independend KeyProvider via byte protocol
  • Ideas might be a screen recorder and use the visible screen downscaled as 256 bit input
• KeyProvider must get the grid size to increment properly on incremental based Producer
• ExecutableKeyProvider gets data from stdout

This software should not be configured and used to find (Bitcoin/Altcoin) address hash (RIPEMD-160) collisions and use (steal) credit from third-party (Bitcoin/Altcoin) addresses. This mode might be allowed to recover lost private keys of your own public addresses only.

Another mostly legal use case is a check if the (Bitcoin/Altcoin) addresses hash (RIPEMD-160) is already in use to prevent yourself from a known hash (RIPEMD-160) collision and double use.

Some configurations are not allowed in some countries (definitely not complete):

• Germany: § 202c Vorbereiten des Ausspähens und Abfangens von Daten
• United States of America (USA): Computer Fraud and Abuse Act (CFAA)

It is licensed under the Apache License, Version 2.0. See LICENSE for the full license text. Some subprojects have a different license.