Skip to content
An automated bitcoin wallet collider that brute forces random wallet addresses
Branch: master
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
LICENSE update Jan 27, 2019 update TODO - memory error Aug 18, 2019 fix tab error Jun 22, 2019
requirements.txt convert database back into a set Feb 8, 2019

Plutus Bitcoin Brute Forcer

A Bitcoin wallet collider that brute forces random wallet addresses

Like This Project? Give It A Star


Python 3.6 or higher

Python modules listed in the requirements.txt

Minimum RAM requirements


$ git clone plutus

$ cd plutus && pip3 install -r requirements.txt

Quick Start

$ python3

Proof Of Concept

A private key is a secret number that allows Bitcoins to be spent. If a wallet has Bitcoins in it, then the private key will allow a person to control the wallet and spend whatever balance the wallet has. So this program attempts to find Bitcoin private keys that correlate to wallets with positive balances. However, because it is impossible to know which private keys control wallets with money and which private keys control empty wallets, we have to randomly look at every possible private key that exists and hope to find one that has a balance.

This program is essentially a brute forcing algorithm. It continuously generates random Bitcoin private keys, converts the private keys into their respective wallet addresses, then checks the balance of the addresses. If a wallet with a balance is found, then the private key, public key and wallet address are saved to the text file plutus.txt on the user's hard drive. The ultimate goal is to randomly find a wallet with a balance out of the 2160 possible wallets in existence.

How It Works

Private keys are generated randomly to create a 32 byte hexidecimal string using the cryptographically secure os.urandom() function.

The private keys are converted into their respective public keys using the starkbank-ecdsa Python module. Then the public keys are converted into their Bitcoin wallet addresses using the binascii and hashlib standard libraries.

A pre-calculated database of every P2PKH Bitcoin address with a positive balance is included in this project. The generated address is searched within the database, and if it is found that the address has a balance, then the private key, public key and wallet address are saved to the text file plutus.txt on the user's hard drive.

This program also utilizes multiprocessing through the multiprocessing.Process() function in order to make concurrent calculations.


It takes 0.0032457721 seconds for this progam to brute force a single Bitcoin address.

However, through multiprocessing.Process() a concurrent process is created for every CPU your computer has. So this program can brute force addresses at a speed of 0.0032457721 ÷ cpu_count() seconds.

Database FAQ

An offline database is used to find the balance of generated Bitcoin addresses. Visit /database for information.

Expected Output

Every time this program checks the balance of a generated address, it will print the result to the user. If an empty wallet is found, then the wallet address will be printed to the terminal. An example is:


However, if a wallet with a balance is found, then all necessary information about the wallet will be saved to the text file plutus.txt. An example is:

hex private key: 5A4F3F1CAB44848B2C2C515AE74E9CC487A9982C9DD695810230EA48B1DCEADD
WIF private key: 5JW4RCAXDbocFLK9bxqw5cbQwuSn86fpbmz2HhT9nvKMTh68hjm
public key: 04393B30BC950F358326062FF28D194A5B28751C1FF2562C02CA4DFB2A864DE63280CC140D0D540EA1A5711D1E519C842684F42445C41CB501B7EA00361699C320
address: 1Kz2CTvjzkZ3p2BQb5x5DX6GEoHX2jFS45

Memory Consumption

This program uses approximately 2GB of RAM per CPU. Because this program uses multiprocessing, some data gets shared between threads making it difficult to accurately measure RAM usage.


The memory consumption stack trace was made by using mprof to monitor this program brute force 10,000 addresses on a 4 logical processor machine with 8GB of RAM. As a result, 4 child processes were created, each consuming 2100MiB of RAM (~2GB).

Recent Improvements & TODO

  • Fixed typos/formatting

  • Update database

  • Pickle loader

  • Try to fix Memory Error

Create an issue so I can add more stuff to improve

You can’t perform that action at this time.